If it isn't a deal breaker, I'd say keep Java 5 support..if that changes in the future, it changes..at least folks would have a version of log4j2 that worked on Java5.
Scott On Tue, Feb 26, 2013 at 11:48 AM, Ralph Goers <ralph.go...@dslextreme.com>wrote: > 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 <ralph.go...@dslextreme.com> 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: log4j-dev-unsubscr...@logging.apache.org > >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > >
