Hi,
On Tue, Aug 4, 2015 at 3:48 PM, wrote:
> As part of the overall modularization effort [1] we're going to
> encapsulate most of the JDK's internal APIs within the modules that
> define and use them so that, by default, they are not accessible to
> code outside the JDK.
>
> This change will im
2015/8/4 12:07 -0700, Simon Nash :
> mark.reinh...@oracle.com wrote:
>> 2015/8/4 11:34 -0700, si...@cjnash.com:
>>> Thanks for this. In the list of broad categories, one is missing:
>>>
>>> x Those which are required to enable application code to work around
>>> bugs in the JDK such as leaked ob
mark.reinh...@oracle.com wrote:
2015/8/4 11:34 -0700, si...@cjnash.com:
Thanks for this. In the list of broad categories, one is missing:
x Those which are required to enable application code to work around
bugs in the JDK such as leaked objects.
That could be an awfully broad category.
2015/8/4 11:34 -0700, si...@cjnash.com:
> Thanks for this. In the list of broad categories, one is missing:
>
> x Those which are required to enable application code to work around
> bugs in the JDK such as leaked objects.
That could be an awfully broad category. Do you have some specific
Mark,
Thanks for this. In the list of broad categories, one is missing:
x Those which are required to enable application code to work around
bugs in the JDK such as leaked objects.
When do you expect to be able to publish a detailed proposal for how the
"last resort" mechanism will work?
Hey Mark, Martijn,
First of all a more official way than twitter: I really appreciate this step,
it is the perfect way. Unsafe has to disappear but with a good migration path
and I think this compromise will achieve exactly that.
I’ll compile the list in a more readable format over the next day
+1 to this - it's a really good compromise. Christoph from Hazelcast (and
some other folks from popular projects that use Unsafe) have been compiling
a list of use cases and a gap analysis of sorts. I'll let him respond here
with the gory details to add to the JEP.
Cheers,
Martijn
On Tuesday, 4
Hi Mark,
Thanks. This looks like a solid plan. It will put us on track to get rid of the
internal API usage without making it needlessly dificult for people to adopt
JDK 9.
Regards,
Jeroen
> -Original Message-
> From: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] On Behalf
>
As part of the overall modularization effort [1] we're going to
encapsulate most of the JDK's internal APIs within the modules that
define and use them so that, by default, they are not accessible to
code outside the JDK.
This change will improve the integrity of the platform, since many of
these
