Just to recap what we discussed offline:
We could introduce BootLoader::loadLibrary to load a system native
library for boot loader. sys_path and systemNativeLibraries in
ClassLoader implementation are solely for boot loader and it seems
cleaner for BootLoader to handle loading of system native
Claes,
Thanks for exploring this. I would like to see if we can avoid introducing
an internal @CS method (keep @CSM only for public APIs will help security
analysis).
There are other alternatives to improve the footprint performance.
One idea is java.base and java.desktop each has its own util
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 assertio
Hi,
Regarding all the touches on the desktop module
1) awt-dev isn't the only list, you should have included swing-dev and
2d-dev at least
2) I am wondering what client testing you propose to do to verify this ?
3) I've spent spare time over a number of months trying to decrease
unnecessary co
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 m
