Well, that is true as far as the Java Language spec goes. However, there is now a class that will only compile if JDK 1.6 is available as the classes are new to that release. So yes, even though the source code is 1.5 compatible it still would be good to let people know that they have to use JDK 1.6 to compile.
Ralph On Thu, Sep 29, 2011 at 9:42 AM, Jacob Kjome <[email protected]> wrote: > > Why would you need source=1.6? The only binary incompatibility between 1.5 > and 1.6 that I'm aware of is that in 1.6 you can use @Override for > overridden methods of an interface where 1.5 you can't. What is it about > Java 1.6 that you require it for compilation? If it's just API, then you > can still use source=1.5. > > Jake > > > On Wed, 28 Sep 2011 23:29:16 -0700 > Ralph Goers <[email protected]> wrote: > >> >> On Sep 19, 2011, at 1:44 AM, Joern Huxhorn wrote: >> >> >>> On 19.09.2011, at 09:36, Ralph Goers wrote: >>> >>> >>>> On Sep 18, 2011, at 4:56 PM, Joern Huxhorn wrote: >>>> >>>> >>>>> On 19.09.2011, at 01:29, Ralph Goers wrote: >>>>> >>>>> >>>>>> On Sep 18, 2011, at 3:01 PM, Joern Huxhorn wrote: >>>>>> >>>>>> Sorry, I was confused and mixed something up... >>>>>>> >>>>>>> I *planned* to implement a thread-specific sequence number but never >>>>>>> did so. I also considered logging the ThreadGroup-hierarchy but didn't >>>>>>> do >>>>>>> so, yet, because of the expected performance impact. >>>>>>> >>>>>>> Which reminds me, completely off-topic, of another idea concerning a >>>>>>> custom Message implementation: >>>>>>> A ThreadDumpMessage that would not get any parameter at all and would >>>>>>> consist of a ThreadDump if it is actually logged, including the >>>>>>> ThreadGroup >>>>>>> info etc.. >>>>>>> This would have helped me immensely in the past. Instead, I had to >>>>>>> trigger thread dumps via SIG_QUIT at a random points of execution. >>>>>>> >>>>>>> Such a Message wouldn't be used in production under normal >>>>>>> circumstances but could be enabled in case of strange concurrency >>>>>>> issues... >>>>>>> >>>>>> >>>>>> I added it, but as I said, I wish I knew how to include the locks. >>>>>> FWIW, I could have used this 2 days ago when we were trying to debug >>>>>> just such a concurrency issue. >>>>>> >>>>>> >>>>> I think http://download.oracle.com/**javase/6/docs/api/java/lang/** >>>>> management/ThreadMXBean.html<http://download.oracle.com/javase/6/docs/api/java/lang/management/ThreadMXBean.html>could >>>>> be what you are looking for. Haven't given it a try, yet. >>>>> >>>> >>>> Unfortunately, all the good lock information was added in 1.6. >>>> >>>> >>> Yes, it is calling for some reflection magic. >>> You'd have to reimplement LockInfo and MonitorInfo, though... >>> >> >> I believe I've solved this with the minimum amount of reflection. However, >> it now requires that Log4j 2 be compiled with Java 6. It should still be >> able to run on Java 5. I tried to declare that in the compiler plugin but it >> throws an exception if source = 1.6 and target = 1.5. I believe the enforcer >> plugin would do it though. >> >> Ralph >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> log4j-dev-unsubscribe@logging.**apache.org<[email protected]> >> For additional commands, e-mail: >> [email protected].**org<[email protected]> >> >> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > log4j-dev-unsubscribe@logging.**apache.org<[email protected]> > For additional commands, e-mail: > [email protected].**org<[email protected]> > >
