Hi,
I'm dropping the java.desktop changes, and Mandy has asked me to explore
options that does not add a new @CallerSensitive entry point, even to a
strongly encapsulated API like JavaLangAccess
Easiest of these is to explicitly provide the class context we're
calling from - with proper assertions. This is marginally more
performant due avoiding the Reflection.getCallerClass, but slightly less
convenient.
http://cr.openjdk.java.net/~redestad/8227587/open.01/
/Claes
On 2019-07-12 15:27, Roger Riggs wrote:
Hi Claes,
Looks fine.
Thanks for the updates, Roger
On 7/11/19 10:39 AM, Claes Redestad wrote:
Hi Roger,
On 2019-07-11 16:10, Roger Riggs wrote:
Hi Claes,
JavaLangAccess.java:
316: Add @param tag
done.
System.java: 2282, 2287
Runtime.loadLibrary0 makes a second check for a security manager.
Is there any potential gain by calling ClassLoader.loadLibrary directly?
None of the internal uses would have a separatorChar.
Most of the gain comes from not having to load one-off PA classes or
lambdas, but of course avoiding the indexOf and a few indirections are
marginally helpful to startup. We should at least assert that the
library names are sane, though.
I expect most of the files need a copyright update.
The script in <repo>/make/scripts/update_copyright_year.sh should do
the work for modified files.
Fixed copyrights and updated in place:
http://cr.openjdk.java.net/~redestad/8227587/open.00
Thanks!
/Claes
