> On Dec 7, 2015, at 12:37 AM, Alan Bateman wrote:
>
> To your question, then there is an argument for a
> ClassLoader::getPlatformClassLoader or some such method that you have
> visibility to all platform/Java SE types.
OK, how will this happen?
Alan
Thanks Alan, will check out Alex's talk.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Alan Bateman
Sent: 08/12/2015 12:01:27 am
To: Peter Firmstone ; jigsaw-dev
Subject: Re: RMIClassLoaderSPI, was: Re: getting a basic class l
On 07/12/2015 13:13, Peter Firmstone wrote:
Just a quick one, now that all modules have URI annotations, is there a tool or
utility to find the correct ClassLoader during deserialisation and
unmarshalling with RMI?
We've got our own RFC3986 compliant URLClassLoader, that overrides CodeSource
Thanks,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Alan Bateman
Sent: 07/12/2015 06:37:55 pm
To: Alan Snyder ; jigsaw-dev
Subject: Re: getting a basic class loader
On 06/12/2015 20:25, Alan Snyder wrote:
> I have been told [
On 06/12/2015 20:25, Alan Snyder wrote:
I have been told [1] that doing something like String.class.getClassLoader() is
a good way to get a value that can specified as the parent of a custom class
loader when my goal for the custom class loader is to exclude
application-specific classes (e.g.
I have been told [1] that doing something like String.class.getClassLoader() is
a good way to get a value that can specified as the parent of a custom class
loader when my goal for the custom class loader is to exclude
application-specific classes (e.g. from the classpath).
Is this the best way
