Re: Java compiler version

2013-02-26 Thread Gary Gregory
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 wrote: > In general I agree with your points. However, I don't think we can get rid > of all the reflection. Thr

Re: Java compiler version

2013-02-26 Thread Ralph Goers
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 ev

Re: Java compiler version

2013-02-26 Thread Jacob Kjome
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 definit

Re: Java compiler version

2013-02-26 Thread Gary Gregory
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 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 worke

Re: Java compiler version

2013-02-26 Thread Scott Deboy
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 wrote: > No - I am actually using the Java 6 compiler and it is allowing >

Re: Java compiler version

2013-02-26 Thread Ralph Goers
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 specif

Re: Java compiler version

2013-02-26 Thread Jacob Kjome
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

Re: Java compiler version

2013-02-26 Thread Gary Gregory
+1. Let's make Java 6 the requirement. Gary On Feb 26, 2013, at 2:25, Ralph Goers 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 set

Re: Java compiler version

2013-02-26 Thread Christian Grobmeier
Java 5 is legacy, and its the perfect time to switch jdk versions without major bumps. Let's go for Java 6. Cheers Christian On Tue, Feb 26, 2013 at 8:24 AM, Ralph Goers wrote: > Remko found a bug in AbstractStringLayout where the code actually requires > Java 6 to compile although it should ru

Java compiler version

2013-02-25 Thread Ralph Goers
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.