> On Fri, 12 Oct 2012 01:39:25 PM Lone_Wolf wrote:
>> I've been running svn builds compiled for java7 for some time now and
>> noticed the log increased a lot with wanrings, npes etc after playing a
>> while.
>
> Which is to be expected with intrusive AI changes afoot. FWIW, the
> current
> state is that:
>
> - I can reliably run a single case of my standard 7-AIs-to-1700 test
> game/s
> and it will complete without a total crash
> - I can usually run a single game without seeing caught AI exceptions in
> the
> logs
> - I can *not* usually run an overnight run of 20+ test games without
> seeing
> caught AI exceptions in the logs. This is where I am working ATM, hunting
> down and fixing the exceptions one by one.
> - The efficiency of the AI transport code continues to improve. Every
> crash
> fixed helps.
> - However, there remain cases where the AI does something lame. For
> example
> ATM there are mysterious cases where it aborts a delivery when it is
> already
> underway. I have an evil piece of emacs-lisp that reads FreeCol log files
> and
> threads each AI mission, so you can step through exactly what steps were
> taken. Every time I run this, and examine the resulting TransportMissions
> in
> turn, I get further before finding a case where a poor choice was made.
> One day I hope to get all the way through the log.
> - Save/restore `works' only in the sense of not crashing utterly. AIGoods
> remain problematic, but then again, they were known broken before I
> started
> kicking the AI, and at least now there should be enough logging to track
> down
> where they are going astray. This is next on the list after I can run
> overnight tests without exceptions, or perhaps, when I can run overnight
> tests
> without exceptions, these bugs will have been fixed.
> - AI-only games are not that realistic, games involving humans are to be
> expected to throw up other bug categories
> - There are some new warnings being generated (`Can not claim
> transportable'
> IIRC) that are turning out to be mostly harmless. A review of the logging
> is
> the last thing to do.
Ok, that makes clearer where i should look for and that if there is
corruption over time, the warnings/NPEs still are useful.
>
>> I ran
>>
>> find . -type f -exec grep -l 'SuppressWarnings' {} \;
>> from the src/net/sf/freecol folder and found many files where
>> SuppressWarnings is used.
>
> grep -r src/net/sf/freecol/server/ai -e Suppress
> => 7 "unused" cases, all for the class Logger. These are expected.
> No new warning suppressions have been added in the destabilizing AI
> changes.
>
>> further analysis showed there are 3 kinds of warnings that are
>> suppressed :
>>
>> A. @SuppressWarnings("static-access")
>
> This looks odd, and removing it does not generate compiler warnings for
> me,
> so I removed it, and a couple of now incorrect "unused"s in svn.10209.
> Folks,
> feel free to revert if your compiler whines about this.
>
no compiler whine with jdk7 with rev 10210
>> B. @SuppressWarnings("unused")
>
> We have a convention in FreeCol that every class is allowed to grow a
> Logger.
> At any point in time, some are in use, some are not, and when they are not
> the
> warning is suppressed. The overhead of unused loggers is minor
> and harmless We could probably do this more elegantly, but there are far
> worse problems. IMHO of course, as I use logging a lot and encourage it.
>
Understood and agreed
>> C. @SuppressWarnings("unchecked")
>
> Here you have a point. In an ideal perfectly type-secure codebase we
> would
> not have any of these. FreeCol is not (yet) such a codebase, nor is that
> a
> realistic goal ATM while we are at least claiming to be able to build
> FreeCol
> on Java5, 6 and 7. There are several core classes that are now type-
> qualifiable in 7 which were not in 5, which annoys Java7 compilers.
>
>> The SuppressWarnings don't seem to come with many explanation why they
>> are
>> used.
>
> The (right) compiler will explain category C cases if you remove the
> warning
> suppressions:-).
>
>> Personally i feel using SuppressWarnings hides problems in the code that
>> need to be taken care of, not hidden.
>
> Patches welcome to fix the category C cases. The patched code should
> compile
> without warnings in Java5,6 and 7 environments. I had a brief crack at
> this a
> while back without success. Good luck!
>
>> Are there disadvantages to removing/commenting out the SuppressWarnings
>> ?
>
> Does `mpope gets annoyed by compile time warnings' count:-)? I compile
> FreeCol a lot, and stepping though repeated warnings is tedious, so I
> either
> fix them if I can, suppress them if appropriate, or complain about them on
> this
> list. AFAICT ATM the FreeCol codebase only contains suppressed warnings
> that
> are harmless (B) or I can not fix (C).
>
> Cheers,
> Mike Pope
>
>
I can install jdk6 alongside jdk7, so can test for compiler warnings from
those 2 .
java 5 however only is available as the old oracle jre5 / jdk5 , doubt it
can coexist with openjdk 6/7 .
Debian stable now has jdk6 as default, the only java5 packages i see there
are for their *BSD ports.
Oracle has recently switched to openjdk7 downloads as default choice, and
jdk8 is scheduled for 2013.
Is java5 compatibility really needed ?
Ant does give a decent explanation of the warning, and websearch tends to
give enough details about the cause.
Solving them however is much harder, but i've already seen that not all
unchecked warnings have the same cause.
I'll do some more detailed analysis of the warnings.
LW
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Freecol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freecol-developers
