Note that it's possible to change the boot classpath to include Java 1.6 API
using a Java 1.5 compiler and compile the classes just fine. I recommend
against overloading the meaning of the "source" compiler flag to refer to Java
API rather than the language features it is narrowly meant to refer to.
Jake
On Thu, 29 Sep 2011 11:55:21 -0700
"ralph.goers @dslextreme.com" <[email protected]> wrote:
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]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
