>> Perhaps, this is more a case for Eclipse devs to tweak up their code helper. >> :) > I think they may have a problem with their type inferencing, yes.
I checked Eclipse bugzilla. It should be fixed in the current (Eclipse Neon) release. > Be glad you did not have to read the pure Java 8 Streams version! I have read the specs. Had no problem with understanding, but being primarily a sysadmin and not a developer, I decided there are some things in the world that I just do not need to know. :D > [1] There are still several compiler warnings that we explicitly suppress (@SuppressWarnings). It would be really nice to clean them up, but I fear all the easy ones are done. The code assistant in IDE also found some pieces in dead code (basically some unreachable if somewhere and such). I could look into it, or if more desirable, would take some bug to solve. Fiisch 2016-05-06 0:16 GMT+02:00 Michael T. Pope <mp...@computer.org>: > On Thu, 5 May 2016 12:47:37 +0200 > Petr Fišer <pries...@gmail.com> wrote: >> Keeping the convention is definitelly a valid reason and I would >> rather use another IDE than make you to break code style. > > That is good of you, but I think it is the wrong policy. Eclipse may be > at fault here, but I do not think a coding convention should be allowed to > throw up barriers to tool use. I would like to see FreeCol not throw any > sort of (major:-)[1] warning with *any* credible tool. > >> Perhaps, this is more a case for Eclipse devs to tweak up their code helper. >> :) > > I think they may have a problem with their type inferencing, yes. > >> The main thought behind the patch was to ease development for others >> and Eclipse was a good choice. > > Agreed. > >> What do you use? > > Emacs + javac. If I want more warnings[1] I use findbugs, and I have > registered FreeCol for the free coverity scans. Those two tools have > prompted some race condition cleanups, but there is a lot of noise. > >> In Eclipse, the rewrite git.e1d318a looks okay for the IDE. > > Excellent. I think that is the right way to resolve these difficulties. > >> I must admit, this version is more readable than mine or the original one. > > The new routines in CollectionUtils are still evolving. I admit > "transform" can be a bit obscure until you have used it 20 times, which > FreeCol does, easily. Be glad you did not have to read the pure Java 8 > Streams version! > > Cheers, > Mike Pope > > [1] There are still several compiler warnings that we explicitly > suppress (@SuppressWarnings). It would be really nice to clean them up, > but I fear all the easy ones are done. ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
