Re: New candidate JEP: 403: Strongly Encapsulate JDK Internals

On 3/17/21 10:05 PM, mark.reinh...@oracle.com wrote: > https://openjdk.java.net/jeps/403 > > Summary: Strongly encapsulate all internal elements of the JDK, except > for critical internal APIs such as sun.misc.Unsafe. It will no longer > be possible to relax the strong encapsulation of inte

Re: New candidate JEP: 403: Strongly Encapsulate JDK Internals

On 25/03/2021 10:54, Andrew Haley wrote: : Looking at the JEP, I don't immediately see anything about long-term use of illegal accesses in test code. There are a good many cases where we need to test private and protected classes and fields, for example. Is there a proposal to allow this? I don'

Re: New candidate JEP: 403: Strongly Encapsulate JDK Internals

On Thu, Mar 25, 2021 at 12:26 PM Alan Bateman wrote: > [...] > > More generally, tests for modules, say white box tests that exercise > package private methods, can continue to be compiled and run "as if" > they are part of the module. The Maven/other plugins for testing will > use --patch-module

Re: Add information of which automatic module doesn't the

On Wed, Mar 3, 2021 at 10:10 AM Alan Bateman wrote: > [...] > Thanks, it should include the file path to the JAR file in the message > to make it easy to find the JAR file that can't be used as an automatic > module. I'll create an issue to track that. > Did you create an issue, Alan? If not, I'

Re: Add information of which automatic module doesn't the

I guess the issue was created: https://bugs.openjdk.java.net/browse/JDK-8262944 Em qui., 25 de mar. de 2021 às 11:11, Christian Stein escreveu: > > On Wed, Mar 3, 2021 at 10:10 AM Alan Bateman > wrote: > >> [...] >> Thanks, it should include the file path to the JAR file in the message >> to

Re: Add information of which automatic module doesn't the

On 25/03/2021 14:11, Christian Stein wrote: On Wed, Mar 3, 2021 at 10:10 AM Alan Bateman > wrote: [...] Thanks, it should include the file path to the JAR file in the message to make it easy to find the JAR file that can't be used as an au

Difference of module jdk.xml.dom and module jdk.zipfs

Hi, Besides their names, contents and purposes. (-: So, what's the difference of module jdk.xml.dom and module jdk.zipfs in respect to their visibility(?) at compile and run-time? Suppose, there's a module test.base declared as: module test.base { requires jdk.xml.dom; requires jdk.

Re: Difference of module jdk.xml.dom and module jdk.zipfs

On 25/03/2021 14:59, Christian Stein wrote: Hi, Besides their names, contents and purposes. (-: So, what's the difference of module jdk.xml.dom and module jdk.zipfs in respect to their visibility(?) at compile and run-time? Suppose, there's a module test.base declared as: module test.base