On 13.10.2012 12:27, Lone_Wolf wrote:
>> 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 .
>
Of course it can. Just bung it in /usr/share or wherever you want it,
and you are set. You need to set up your environment to make ant use it,
if that's what you want. I did that for years, before I upgraded to
(Oracle) JDK 1.6.
> 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 ?
>
Linux users always have more or less up-to-date software. Even Debian
has versions that are only two to three years old. However, I would not
be surprised to hear that many, many Windows users still have Java 5
installed. After all, 25% of them still use Windows XP. And the
situation on the Mac is too difficult for me to understand (and seems to
change a lot, too).
However, if you have any statistics showing that the market share of
Java 1.5 has declined below 10% or so, then I see no reason why we
should not move to 1.6. That would certainly provide some benefits, such
as better font support and good-bye woodstox.
> 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
>
Regards
Michael
------------------------------------------------------------------------------
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
