Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

[Alan Bateman]

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