Re: Using non-parallel custom class loaders for Layer configurations

On 09/09/2016 02:05 PM, Mandy Chung wrote: On Sep 9, 2016, at 8:44 AM, David M. Lloyd wrote: On 09/08/2016 06:48 PM, Mandy Chung wrote: On Sep 8, 2016, at 3:29 PM, David M. Lloyd wrote: Would it be possible to include a method like this

Re: JDK9 encapsulation problem

Hi Stephen, I see your problem... On 09/09/2016 07:32 PM, Stephen Felts wrote: This is a general problem with utility programs. This isn't, unlike the sample, something where I can just re-code it to use the public interface. The utility program isn't checking to see what is public and

Re: Using non-parallel custom class loaders for Layer configurations

> On Sep 9, 2016, at 8:44 AM, David M. Lloyd wrote: > > On 09/08/2016 06:48 PM, Mandy Chung wrote: >> >>> On Sep 8, 2016, at 3:29 PM, David M. Lloyd wrote: >>> >>> Would it be possible to include a method like this (pretty old patch I had >>>

RE: JDK9 encapsulation problem

This is a general problem with utility programs.  This isn't, unlike the sample, something where I can just re-code it to use the public interface.  The utility program isn't checking to see what is public and what is not.  It looks up the class and invokes on it, creating or opening the

Re: Using non-parallel custom class loaders for Layer configurations

On 09/09/2016 11:26 AM, Alan Bateman wrote: On 08/09/2016 23:29, David M. Lloyd wrote: Is it not necessary that any class loader in use by a Layer must be parallel-capable? Otherwise it seems like deadlocks could occur in certain situations when there are references that are cyclic with

Re: Using non-parallel custom class loaders for Layer configurations

On 08/09/2016 23:29, David M. Lloyd wrote: Is it not necessary that any class loader in use by a Layer must be parallel-capable? Otherwise it seems like deadlocks could occur in certain situations when there are references that are cyclic with respect to class loaders mapped by the mapping

Re: Java 9 Obfuscators?

On 09/09/2016 16:44, Eric Johnson wrote: Anyone aware of byte-code obfuscators already working with Java 9? How does modularization interact with obfuscation? I haven't seen bytecode obfuscators in many years and don't know if anyone has tried one with 53.0 class files. However, if the tool

Re: Java 9 Obfuscators?

Hi Eric, ASM has a support for obfuscation (ClassRemapper [1]) and the version 6 also support Java 9 (currently the branch ASM_6_FUTURE support the new classfile encoding used by the betas of jdk-9-jigsaw while asm6-alpha [2] support the old classfile encoding currently used by the betas of

Re: JDK 9 configuration options

On 09/09/2016 16:31, Stephen Felts wrote: : 2. With the new argument syntax in JDK 9 build 132, the launcher arguments now match the command line arguments. That’s a big step in the right direction. However, duplicates are a fatal error. So doing export

Re: JDK9 encapsulation problem

Hi Stephen, On 09/09/2016 04:30 PM, Stephen Felts wrote: We have an application that is running into a problem with a utility program. Below is a standalone reproducer. The program does not import the SPI package sun.nio.ch - it isn't aware of it, and SocketChannel.isConnected() is a

Java 9 Obfuscators?

Anyone aware of byte-code obfuscators already working with Java 9? How does modularization interact with obfuscation? Eric.

Re: Using non-parallel custom class loaders for Layer configurations

On 09/08/2016 06:48 PM, Mandy Chung wrote: On Sep 8, 2016, at 3:29 PM, David M. Lloyd wrote: Would it be possible to include a method like this (pretty old patch I had laying around): diff --git a/jdk/src/java.base/share/classes/java/lang/ClassLoader.java

Re: RFR 8163320: JAVA_VERSION in release file should come from java.base module

Looks good. Is there an existing test to check the content of `release` file? It would be good to have a test to sanity test a few properties and its quoted value. Mandy > On Sep 9, 2016, at 6:02 AM, Sundararajan Athijegannathan > wrote: > > Please

JDK 9 configuration options

It’s common in enterprise applications to have multiple frameworks running in the same JVM.  For example, and application server might have Spring or Birt used in the application.  There are even cases where part of one application server might be used as a library running in the same JVM as

Re: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java

On 09/09/2016 15:46, Sundararajan Athijegannathan wrote: Hmm.. how would we know that? A well-known list you mean? Besides, our current tests assume that all "bin" directory commands are derived from standard binary launcher and so satisfy all launcher options like -J- etc. I think you'll need

Re: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java

Hmm.. how would we know that? A well-known list you mean? Besides, our current tests assume that all "bin" directory commands are derived from standard binary launcher and so satisfy all launcher options like -J- etc. -Sundar On 9/9/2016 8:12 PM, Alan Bateman wrote: > On 09/09/2016 14:58,

Re: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java

On 09/09/2016 14:58, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8165772/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8165772 Would it better to skip when the module has launchers in the bin directory? -Alan

JDK9 encapsulation problem

We have an application that is running into a problem with a utility program.  Below is a standalone reproducer.   The program does not import the SPI package sun.nio.ch - it isn't aware of it, and SocketChannel.isConnected() is a public method of a public type. In short, it does not break

Re: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java

+1 > On Sep 9, 2016, at 10:58 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8165772/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8165772 > > Thanks, > > -Sundar >

RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java

Please review http://cr.openjdk.java.net/~sundar/8165772/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8165772 Thanks, -Sundar

RFR 8163320: JAVA_VERSION in release file should come from java.base module

Please review fix for https://bugs.openjdk.java.net/browse/JDK-8163320 jdk repo: http://cr.openjdk.java.net/~sundar/8163320/jdk/ * JAVA_VERSION is derived from module-info of java.base * adding quotes around all 'release' properties top repo: