On 16/07/2019 14:48, Claes Redestad wrote:
Hi,
refactored to use a BootLoader::loadLibrary API that is only visible
within the java.base module:
http://cr.openjdk.java.net/~redestad/8227587/open.03/
I've retained the bridge to ClassLoader::loadLibrary for performance,
but without any magic or
On 7/17/19 3:25 AM, Claes Redestad wrote:
Hi Peter,
On 2019-07-17 10:29, Peter Levart wrote:
Hi Claes,
Am I reading correct that package-private
ClassLoader.loadLibrary(Class fromClass, String name, boolean
isAbsolute) wouldn't need to consult SecurityManager wasn't it for
accessing syst
Hi Peter,
On 2019-07-17 10:29, Peter Levart wrote:
Hi Claes,
Am I reading correct that package-private
ClassLoader.loadLibrary(Class fromClass, String name, boolean
isAbsolute) wouldn't need to consult SecurityManager wasn't it for
accessing system properties in private ClassLoader.initializ
Hi Claes,
Am I reading correct that package-private
ClassLoader.loadLibrary(Class fromClass, String name, boolean
isAbsolute) wouldn't need to consult SecurityManager wasn't it for
accessing system properties in private ClassLoader.initializePath(String
propName). So perhaps if the two calls
On 7/16/19 6:48 AM, Claes Redestad wrote:
Hi,
refactored to use a BootLoader::loadLibrary API that is only visible
within the java.base module:
http://cr.openjdk.java.net/~redestad/8227587/open.03/
Looks good.
Nit: in JavaLangAccess
321 void loadLibrary(Class klass, String librar
> On 16 Jul 2019, at 14:48, Claes Redestad wrote:
>
> Hi,
>
> refactored to use a BootLoader::loadLibrary API that is only visible
> within the java.base module:
>
> http://cr.openjdk.java.net/~redestad/8227587/open.03/
I think that this is good Claes. Reviewed.
-Chris.
Hi,
refactored to use a BootLoader::loadLibrary API that is only visible
within the java.base module:
http://cr.openjdk.java.net/~redestad/8227587/open.03/
I've retained the bridge to ClassLoader::loadLibrary for performance,
but without any magic or privilege escalation involved. Moving sys_pa
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
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 interna
Hi Claes,
JavaLangAccess.java:
316: Add @param tag
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.
I expect most of the files
14 matches
Mail list logo
