Community
Participate
Working Groups
Build id: I20071120-1300 See also discussion in bug 168604. On the following source code: public class X { public static void foo() { String s = null; s.toString(); String u; } } the batch compiler launched with -warn:null -warn:unused should, according to its documentation, only report one warning. It reports two, as if passed -warn:null -warn:+unused. Entered BatchCompilerTest#156 (inactive) and 157.
I'll fix that in 3.4 cycle, except if someone opposes to it.
Pls double check on consequences to our clients, like releng scripts (Olivier may help there). I agree on the principle, but in practice, this may be creating more troubles than benefits.
Created attachment 84054 [details] Fix + test case I initially thought that this proposal was too hard when barking at people using things like -warn:null,+unused or -warn:null,-unused, but... the former would at best translate into -warn:null,unused, which is more concise hence better, and the latter would equate to -warn:null, and there is no point in using it instead. Hence the current proposal, which does not accept pluses or minuses in a -warn:something,another,yetanother series that does not start with a plus or a minus. Will post to the news to get users' feelings. Olivier, please yell if releng (or others you know of) are badly impacted. Kent, would you please review this patch?
So far no-one protested in the news. Philippe demanded yesterday that I directly got in touch with a few people.
By cc, Andrew, Tim, Tom, would any of you get badly broken if we aligned the implementation with the spec here? If there is any strong supporter of the implementation vs the spec, would he be kind enough to suggest a satisfactory wording for an aligned spec?
Build supports setting warning levels as well as passing custom batch compiler arguments, therefore it is possible that a releng team would pass what effectively was -warn:<custom options> -warn:<build.property warning options> This change could affect any bundle specifying warning levels, however I have no real problem since we are changing to match the docs and (without really thinking about it) I had always personally assumed the build.properties would override everything else. The build.properties option is not surfaced in the UI and would therefore only be used by people who read the docs.
Created attachment 86074 [details] Renumbered test cases
Released for 3.4 M5.
Verified for 3.4M5 using build I20080204-0010
