Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)
Alan Bateman
Alan.Bateman at oracle.com
Tue Jul 30 01:38:36 UTC 2013
On 29/07/2013 15:48, Paul Benedict wrote:
> +1 with Nick. There's no point in submitting a patch unless someone who is
> in charge of Core Libs Dev is willing to first offer technical direction.
> Where does Oracle want to go with the solution? There are no official
> responses -- it's been quiet on their front for sometime. I don't know if
> that means the proposal is being ignored, or there are offline discussions
> happening, or people are enjoying summer vacations, or something else. I
> just don't know.
>
I think several people are on vacation, some people are at the JVM
Language summit, others are probably just busy. I'm sure there will be
further discussion over the next few weeks.
For JDK 8 then I think the use-cases need to be studied to see if it
merits introducing new APIs or not (JDK 8 is past feature complete so it
might be awkward/tight). The Groovy usage seems to be boil down to be
able to distinguish frames associated with Groovy generated classes from
other classes, Mandy has created a bug to look into that. Another one
that has come up is loading resources on behalf of the caller, we
already have a bug open to look at that for at least the purposes of
logging resources.
On 7u40 then the method has not been removed and there is a workaround
to allow existing code using the sun.reflect.Reflection directly to
continue to work. I can't say whether this should be re-visited given
the usages that have come out of the wood work. The timing on this is
tighter given that 7u40 is supposed to be released mid-September.
-Alan
More information about the core-libs-dev
mailing list