Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Received-SPF: pass (nike.apache.org: domain of ralph.goers@dslextreme.com
 designates 209.85.160.51 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1283)
Subject: Re: We have to stop using Reflection#getCallerClass(int)
From: Ralph Goers <ralph.goers@dslextreme.com>
In-Reply-To: <985F9F34-3256-4565-9BC7-1ED61B4F06B4@nicholaswilliams.net>
Date: Wed, 26 Jun 2013 00:10:20 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <F3632647-3541-47E2-A320-D6E9AE6FF448@dslextreme.com>
References: <985F9F34-3256-4565-9BC7-1ED61B4F06B4@nicholaswilliams.net>
To: "Log4J Developers List" <log4j-dev@logging.apache.org>

This won't break Log4j 1.x as it doesn't implement the features that use =
this.  However, I'm pretty sure it will also break Logback.

Ralph

On Jun 25, 2013, at 5:04 PM, Nick Williams wrote:

> As some of you may know, sun.reflect.Reflection#getCallerClass(int) =
was removed in Java 8 (it was replaced with no-arg =
Reflection#getCallerClass(), which uses non-public @CallerSensitive). =
This resulted in LOG4J2-245 [1] (EmptyStackException on Java 8), which =
was resolved with using a backup option =
(SecurityManager#getClassContext()) in the hopes that a replacement =
would be found. I have been actively involved in discussions on the Java =
8 Core Libraries mailing list to replace this behavior with a public API =
in Java 8 [2,3].
>=20
> It has now come to my attention that the changes to =
Reflection#getCallerClass(...) have been back-ported to Java 7 now [4,5] =
(effective 1.7.0_25, released in the last week or so). Since it's a =
non-public API, they're free to do this any time they want, but it will =
cause a nightmare for Log4j users using 1.7.0_25 and higher. Here are =
the exact changes that were made:
>=20
> 1) Added no-arg Reflection#getCallerClass() that uses back-ported =
@CollerSensitive.
> 2) Left Reflection#getCallerClass(int) in place, but it now THROWS an =
UnsupportedOperationException (which is even worse ... the fix for =
LOG4J2-245 won't pick this up and make it work for 1.7.0_25+ users).
> 3) In Java 7 _only_ (won't work for Java 8) users can specify =
jdk.reflect.allowGetCallerClass system property to enable =
Reflection#getCallerClass(int). I submit this will not be an option our =
users are willing to accept, but it is a temporary workaround.
>=20
> Here's hoping they add a public API in Java 8 to make what we're using =
this for easier (I'm pushing as hard as I can), but it looks like Java 7 =
is broke for good. We should probably add in a check so that =
getCallerClass is not used unless Java major version is 6.
>=20
> I do not know how this change will impact Log4j 1.x. Hopefully it =
won't.
>=20
> Nick
>=20
> [1] https://issues.apache.org/jira/browse/LOG4J2-245
> [2] =
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html=

> [3] =
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018353.html=

> [4] =
http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-June/006791.html
> [5] =
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018349.html=

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org