No - I am actually using the Java 6 compiler and it is allowing AbstractStringLayout to reference a method that is in Java 6 but not Java 5. The code is actually testing if the method exists so it won't get an error when running in Java 5 but will use a less efficient method instead. By specifying the source we are documenting that Java 6 is the minimum compiler version we support.
If specifying Java 6 for both source and target is what the majority thinks is best I am OK with that. I actually have no pressing need to support Java 5 for my own purposes. Ralph On Feb 26, 2013, at 11:26 AM, Jacob Kjome wrote: > > All "-source 1.6" does above and beyond 1.5 is allow for using "@Override" > on overridden interface methods, which is nice but not critical; certainly > no reason to switch to Java 6. > > What you actually seem to be proposing to use "-target 1.6" because you wish > to bind to 1.6+ API. This will both prevent compilation with any JDK less > than 1.6 and allow for creating 1.6 compatible binaries under later JDKs. > > If there is API in 1.6 that we simply can't live without to produce a quality > logging implementation, then go for it, since 1.5 is pretty outdated. But if > it's just minor stuff that could be worked around using existing 1.5 API, > there are plenty of users stuck with JDK 1.5 that will be left out of using > Log4j2 for no good reason. > > In any case, the bug is primarily in our release process rather than code. > It is due to the fact that we are generating official release artifacts using > a JDK (6 or 7) later than the specified target JDK (5). While javac > source/target allows for a flexible build system by not forcing everyday > users to install an older JDK in order to generate artifacts compatible with > documented target JDK, project release managers should *****always***** use > the documented target JDK to generate official release artifacts to avoid > accidentally introducing bindings to API that exists in later JDKs, but not > the documented target JDK that the project claims to be compatible with. Had > this been done, this issue would have been caught long before any official > release. > > So, decide on a JDK to target and then actually use that JDK to generate > official release artifacts, rather than some arbitrary later one, and we'll > never run into this issue again. > > > Jake > > On Mon, 25 Feb 2013 23:24:50 -0800 > Ralph Goers <[email protected]> wrote: >> Remko found a bug in AbstractStringLayout where the code actually requires >> Java 6 to compile although it should run fine with Java 5. Does anyone have >> a problem with setting the compile source setting to 1.6 for Log4j 2? That >> is actually what I have been building all the releases with anyway. >> Ralph >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
