Move on to Java 6 and remove the dynamic method detection, it's noise IMO. Gary
On Tue, Feb 26, 2013 at 2:53 PM, Scott Deboy <scott.de...@gmail.com> wrote: > 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 >> >> > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
