On 6/25/13 5:42 PM, Mandy Chung wrote:
On 6/25/13 3:04 PM, David Lloyd wrote:
We have a use case within our security manager implementation that
*can* be solved with the existing getClassContext method, which
returns the whole stack, except we don't *need* the whole stack, just
one specific frame. Maybe SecurityManager is a good place for this API?
Which frame do you need? How do you use it?
Typically it's the frame belonging to whomever called the method on the
class. So it's not a search situation, it's a constant offset.
As an aside, getClassContext returns a Class[]; maybe it should be
changed to Class<?>[] instead.
Ah. I can fix that in my fix for 8007035 [1].
Mandy
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018327.html
--
- DML
On Jun 25, 2013, at 8:35 PM, Mandy Chung <mandy.ch...@oracle.com> wrote:
On 6/25/13 3:50 AM, Peter Levart wrote:
Hi,
I know that @CallerSensitive annotation was introduced to bring some
order to JDK internal plumbings. It's scope was to support JDK
internal usage, so it's use is limited to classes loaded by
bootstrap or extension class-loaders. In JDK-internal code it is
used mainly for implementing security-sensitive decisions. But since
the sun.reflect.Reflection.getCallerClass(int) was public and
unrestricted, it found it's way out into user code, where at least I
know that it is used in two areas:
1 - to locate callers in the whole call-stack so that their location
in class-path can be reported (Log4J is an example)
2 - to locate immediate caller so that some resources associated
with it can be located and used (for example localization data in
GUI applications)
I don't know how wide-spread 1st usecase is, but the 2nd is common,
since it's use enables APIs that need not explicitly pass-in the
calling class in order to locate resources associated with it
(and/or the class-loader of it). So it would be nice to have such
supported API in JDK8 at least.
It's good to know these use cases. We leave the method in 7 update
release so as to allow time for applications to transition and also
determine any use case that the SE API should provide if there is no
replacement for it.
I'm asking here, to hear any arguments against making such API
supported and public. Are there any security or other issues? If
there aren't, what steps should be taken to introduce such API in
the JDK8 timeframe? I'm thinking of a no-arg method, say
j.l.Class.getCaller() and moving @CallerSensitive to a supported
package + enabling it to mark methods in any class (not just system
and ext classes)...
Besides providing a method returning the caller's class, I'd like to
consider what other options we have and different use cases could be
satisfied by different API. For #2, the problem is that the API to
find a resource, it requires to use the ClassLoader with the right
visibility (the caller's class loader). This is similiar to 8013839
: Enhance Logger API for handling of resource bundles [1]. For
example, a static method Class.getResource to use the caller's class
loader to find the given resource might be an alternative?
About the timeframe, the API freeze date [2] is Oct 10. If the API
is simple and small effort (test development, security assessement,
etc), there is chance to get that in for jdk8.
Mandy
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013839
[2]
http://openjdk.java.net/projects/jdk8/milestones#API_Interface_Freeze
--
- DML
