Personally, I am in favor of moving to Java 6. At work, we are talking about how to move to Java 7 from 6 is the most efficient manner...
On Tue, Feb 26, 2013 at 4:54 PM, Ralph Goers <[email protected]>wrote: > In general I agree with your points. However, I don't think we can get rid > of all the reflection. ThrowableProxy specifically includes support for > the enhancements introduced in Java 7. I'm not in favor of setting that to > the minimum version as my employer hasn't moved to that yet and isn't even > talking about it yet. However, supporting the new "suppressed" data was > something I thought was important for users so I added via reflection. The > difference is that I do periodically build and test with Java 7. > > Ralph > > > On Feb 26, 2013, at 1:17 PM, Jacob Kjome wrote: > > > > > Ok, I now understand your point about using "-source 1.6" for > documentation purposes while keeping "-target 1.5" for Java5 compatibility. > If Java5 is what we decide upon to target, and we are intent upon choosing > Java version-specific implementations at runtime, I agree that we should > definitely set "-source 1.6" at a minimum. > > > > Nevertheless, using a later JDK to build than you are targeting opens up > the possibility of unintended Java6 API references leaking into the source. > I realize that's exactly what you intended in this case, and use > reflection to choose the appropriate implementation for the runtime Java > version. But someone else might check in code that doesn't have such a > check. Or you might check it in yourself on accident. And the release > coordinator would never detect it at build time. Only if we ran tests > under Java5 might we catch it at runtime. More likely, we'd have to wait > for some user to report it. > > > > Again, I'm not against targeting Java6 if there's a compelling reason to > do so. I'm against generating release artifacts using a later JDK than we > are targeting. > > > > Bottom line: get rid of the reflection. Either the performance > improvement of the Java6-specific getBytes(Charset) (along with other > Java6-specific API) is compelling enough to use it or we just deal with the > Java5 getBytes(String). The source/target values should be identical and > release Java build version should match the source/target or we risk a > brittle build. > > > > > > Jake > > > > On Tue, 26 Feb 2013 11:48:43 -0800 > > Ralph Goers <[email protected]> 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 <[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] > > > > > > --------------------------------------------------------------------- > > 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] > > -- E-Mail: [email protected] | [email protected] 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
