Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

Hi Claes, This is a good interesting work to generate BoundMethodHandle$Species_* classes at link time. This will save the class generation time. Instead of Class.forName, you may want to have a class (similar to SystemModules [1]) that will be updated at link time so that BoundMethodHandle

RFR: 8152733: Avoid creating Manifest when checking for Multi-Release attribute

Hi, the integration of the multi-release jar feature[1] caused a number of startup regressions, the primary cause of which was determined to be due to parsing manifests into java.util.jar.Manifest only to check for the Multi-Release attribute. This can be avoided by reusing the logic

Re: RFR: 8073872: Schemagen fails with StackOverflowError if element references containing class

I will look at this for you tomorrow Aleksej Best Lance On Mar 24, 2016, at 7:38 PM, Aleksej Efimov wrote: > Hi, > > Please, help to review the fix for JDK-8073872 [1]. In JDK9 this bug was > fixed as part of sync with upstream JAXWS project [2]. The changes that

RFR: 8073872: Schemagen fails with StackOverflowError if element references containing class

Hi, Please, help to review the fix for JDK-8073872 [1]. In JDK9 this bug was fixed as part of sync with upstream JAXWS project [2]. The changes that fixed stack overflow issue are located in XmlSchemaGenerator class [3]. JDK9 change that needs review is the addition of regression test for

Re: JAXP default implementation and JDK-8152063

Right, that sounds like what I thought you would want: an additional step in the factory-lookup process to try locating a provider through the Layer of the caller if TCCL fails. I think the assumption in the previous discussion was that a new method would be introduced to take a Layer as an

Re: JAXP default implementation and JDK-8152063

This is all for the case where the user is calling e.g. javax.xml.stream.XMLInputFactory#newFactory() with no arguments. We need some way to choose a specific non-JDK default implementation when there is no service loader info on the TCCL. Using the Layer of the caller of the newFactory()

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

Thanks Erik! Webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/8031767/webrev/ -Sherman On 03/24/2016 01:57 PM, Erik Joelsson wrote: Hello, Yes, I believe we still need to, the reason being that configure automatically falls back to bundled if the headers are not

Re: JAXP default implementation and JDK-8152063

So specifying Layer is preferred solution. If a new method is needed however, (similar situation to using the method with ClassLoader), that would mean your users' applications are required to adapt to the new API. Would you expect that would happen or would you still have existing

Re: RFR (JAXP) 8151154: IllegalArgumentException not thrown when wrong syntax value is set for javax.xml.catalog.files

Thanks Lance! On 3/24/2016 1:02 PM, Lance Andersen wrote: Looks OK Joe. Joe and I talked offline about recognizing the test into the existing tests that he has On Mar 24, 2016, at 12:30 PM, huizhe wang > wrote: Hi, The issue was

Re: JAXP default implementation and JDK-8152063

On 03/24/2016 03:54 PM, huizhe wang wrote: In this discussion so far, a) I see that you seemed to have successfully used the method with a class loader as Daniel suggested. I assume that solved the issue reported in JDK-8152063. Am I right, that you no longer have issue with using a proxy? Or

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

Hello, Yes, I believe we still need to, the reason being that configure automatically falls back to bundled if the headers are not available. This is what happened when you initially tried your patch in JPRT. I still think this is a good way for configure to behave in the general case. In

Re: JAXP default implementation and JDK-8152063

In this discussion so far, a) I see that you seemed to have successfully used the method with a class loader as Daniel suggested. I assume that solved the issue reported in JDK-8152063. Am I right, that you no longer have issue with using a proxy? Or b) you do need JAXP's supporting using

Re: RFR (JAXP) 8151154: IllegalArgumentException not thrown when wrong syntax value is set for javax.xml.catalog.files

Looks OK Joe. Joe and I talked offline about recognizing the test into the existing tests that he has On Mar 24, 2016, at 12:30 PM, huizhe wang wrote: > Hi, > > The issue was that the CatalogFeatures builder did not conduct any > verification on inputs. The file

Re: Review request 8152715: Problem list tools/pack200/Pack200Props.java

+1 On Mar 24, 2016, at 2:20 PM, Mandy Chung wrote: > Exclude this test until JDK-8152622 is resolved. > > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -354,6 +354,9 @@ > # 8059906 fails on

Re: Review request 8152715: Problem list tools/pack200/Pack200Props.java

On 24/03/2016 18:20, Mandy Chung wrote: Exclude this test until JDK-8152622 is resolved. Looks okay.

Review request 8152715: Problem list tools/pack200/Pack200Props.java

Exclude this test until JDK-8152622 is resolved. diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -354,6 +354,9 @@ # 8059906 fails on solaris and macosx, 8151901 tools/pack200/Pack200Test.java

Re: RFR 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present.

On 24/03/16 18:40, Mandy Chung wrote: On Mar 24, 2016, at 7:52 AM, Daniel Fuchs wrote: Hi Mandy, Here is the new webrev - I have added comments for the string constants as well as for the permissions passed through to the limited doPrivileged call:

Re: RFR 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present.

> On Mar 24, 2016, at 7:52 AM, Daniel Fuchs wrote: > > Hi Mandy, > > Here is the new webrev - I have added comments for the > string constants as well as for the permissions passed > through to the limited doPrivileged call: > >

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

Erik, I'm not familiar with the jib-profiles.js. So just want to confirm before putting into the webrev. The proposal is to build with system zlib by default for non-windows platforms, without the need of specifying the configuration/build opton --with-zlib=system. Do we still need to update

Re: JAXP default implementation and JDK-8152063

On 24/03/2016 14:57, David M. Lloyd wrote: Does this mean that there will be a difference between upgradeable modules and endorsed APIs under Jigsaw, or will all of JAXP be fixed/locked to the platform including this API? It's not clear that it's feasible to separate the endorsed APIs from

RFR (JAXP) 8151154: IllegalArgumentException not thrown when wrong syntax value is set for javax.xml.catalog.files

Hi, The issue was that the CatalogFeatures builder did not conduct any verification on inputs. The file path verification was done in the CatalogImpl before parsing started. This change added that to where the property was set in the builder, thus some refactoring (moving the verification

Re: JAXP default implementation and JDK-8152063

On 03/24/2016 11:26 AM, Alan Bateman wrote: On 24/03/2016 16:09, David M. Lloyd wrote: : If the Layer of the module of the class calling the newInstance/newFactory/etc. method could somehow be consulted in service resolution decisions, that would definitely solve the problem because our

Re: JAXP default implementation and JDK-8152063

On 24/03/2016 16:09, David M. Lloyd wrote: : If the Layer of the module of the class calling the newInstance/newFactory/etc. method could somehow be consulted in service resolution decisions, that would definitely solve the problem because our container Layers could refer to the default

Re: Review request for 8151571: System/LoggerFinder tests fail after JDK-8149925

> On Mar 23, 2016, at 8:27 AM, Mandy Chung wrote: > > I did consider taking ClassLoader parameter and I don’t like either option. > I was tempted to convert the constructors to factory methods to avoid passing > a ClassLoader or hasTCCL. > This version converts the

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

Hi Kim, On 03/23/2016 09:40 PM, Kim Barrett wrote: I don't think there's any throughput penalty for a long timeout. The proper response to waitForCleanups returning false (assuming the epoch was obtained early and passed as an argument) is OOME. I really doubt the latency for reporting OOME

Re: JAXP default implementation and JDK-8152063

On 03/22/2016 08:59 AM, Daniel Fuchs wrote: Would adding a method that resolves the concrete service implementation against a Layer supplied by the caller be of any help in your scenario? I think I misunderstood this when you asked it. You mean let the Layer have a hand in looking up the

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

On 3/24/16 1:05 AM, Erik Joelsson wrote: Hello, As I wrote in the bug, jdk9/dev currently fails when using --with-zlib=system with the new devkit on Linux. That will need to be fixed first. Has the JDK-8152352 fixed all the problems or there is something other warning missing?

Re: JAXP default implementation and JDK-8152063

On 03/24/2016 09:51 AM, Alan Bateman wrote: On 24/03/2016 14:29, David M. Lloyd wrote: Daniel, I have hacked together a way to use the system class loader (which should be "good enough", I hope), but there is one further problem: org.xml.sax.helpers.XMLReaderFactory does not have a factory

Re: JAXP default implementation and JDK-8152063

On 24/03/2016 14:29, David M. Lloyd wrote: Daniel, I have hacked together a way to use the system class loader (which should be "good enough", I hope), but there is one further problem: org.xml.sax.helpers.XMLReaderFactory does not have a factory method which accepts a class loader like

Re: RFR 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present.

Hi Mandy, Here is the new webrev - I have added comments for the string constants as well as for the permissions passed through to the limited doPrivileged call: http://cr.openjdk.java.net/~dfuchs/webrev_8150840/webrev.02/index.html I hope that it makes it more clear that the

Re: JAXP default implementation and JDK-8152063

On 24/03/16 15:29, David M. Lloyd wrote: Daniel, I have hacked together a way to use the system class loader (which should be "good enough", I hope), but there is one further problem: org.xml.sax.helpers.XMLReaderFactory does not have a factory method which accepts a class loader like the others

Re: JAXP default implementation and JDK-8152063

On 03/23/2016 07:12 AM, David M. Lloyd wrote: On 03/22/2016 08:59 AM, Daniel Fuchs wrote: Hi David, On 22/03/16 13:53, David M. Lloyd wrote: Am I understanding it correctly that you're pointing the system property to a "proxy" as stated in JDK-8152063, not an actual implementation? So it's

RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

Hi, please review this patch which add an enabled-by-default plugin to generate a configurable list of BoundMethodHandle$Species_*-classes using jlink. Bug: https://bugs.openjdk.java.net/browse/JDK-8152641 Webrev: http://cr.openjdk.java.net/~redestad/8152641/webrev.01/ This plugin adds the

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

Hello again. Here is my suggested patch for the jib-profiles.js file. This will enforce system zlib for Oracle builds on Linux, Solaris and Macosx. /Erik diff -r 6da9e0c79eac common/conf/jib-profiles.js --- a/common/conf/jib-profiles.js +++ b/common/conf/jib-profiles.js @@ -241,7 +241,7 @@

Re: RFR: JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants

On 24/03/2016 12:15, Erik Joelsson wrote: New webrev with shorter lines in SocketOptionRegistry.java.template. http://cr.openjdk.java.net/~erikj/8152545/webrev.jdk.02/ This looks good. -Alan.

Re: RFR: JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants

New webrev with shorter lines in SocketOptionRegistry.java.template. http://cr.openjdk.java.net/~erikj/8152545/webrev.jdk.02/ /Erik On 2016-03-24 12:57, Erik Joelsson wrote: On 2016-03-24 12:15, Alan Bateman wrote: On 23/03/2016 16:14, Erik Joelsson wrote: : On 2016-03-23 12:13, Erik

Re: RFR: JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants

On 2016-03-24 12:15, Alan Bateman wrote: On 23/03/2016 16:14, Erik Joelsson wrote: : On 2016-03-23 12:13, Erik Joelsson wrote: There are however 3 that, at least on Linux, are defined as an enum and not constants, which makes them unavailable to the preprocessor. These are: IPPROTO_TCP

Re: RFR: 8152606: java.base no longer needs to export sun.util.logging to java.httpclient

On 24/03/2016 11:36, Daniel Fuchs wrote: Hi, Please find below a patch for: 8152606: java.base no longer needs to export sun.util.logging to java.httpclient This looks fine. -Alan

Re: RFR: 8152606: java.base no longer needs to export sun.util.logging to java.httpclient

Looks good Daniel. -Chris. On 24 Mar 2016, at 11:36, Daniel Fuchs wrote: > Hi, > > Please find below a patch for: > > 8152606: java.base no longer needs to export sun.util.logging > to java.httpclient > https://bugs.openjdk.java.net/browse/JDK-8152606 > >

RFR: 8152606: java.base no longer needs to export sun.util.logging to java.httpclient

Hi, Please find below a patch for: 8152606: java.base no longer needs to export sun.util.logging to java.httpclient https://bugs.openjdk.java.net/browse/JDK-8152606 Now that JDK-8151281 is fixed, java.base module-info.java can be cleaned up to no longer export sun.util.logging to

Re: RFR: JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants

On 23/03/2016 16:14, Erik Joelsson wrote: : On 2016-03-23 12:13, Erik Joelsson wrote: There are however 3 that, at least on Linux, are defined as an enum and not constants, which makes them unavailable to the preprocessor. These are: IPPROTO_TCP = 6 IPPROTO_IP = 0 IPPROTO_PV6 = 41 I would

Re: RFR [9] 8152642: Remove sun.misc.Unsafe dependency from java.lang.reflect.Proxy

Yes, +1. -Aleksey On 03/24/2016 01:51 PM, Chris Hegarty wrote: > Trivially, looks like a minor oversight that inadvertently introduced a > dependency on sun.misc.Unsafe. > > diff --git a/src/java.base/share/classes/java/lang/reflect/Proxy.java >

Re: RFR [9] 8152642: Remove sun.misc.Unsafe dependency from java.lang.reflect.Proxy

This looks fine. Once sun.misc is moved to the jdk.unsupported module then this type of issue will be caught by build time. -Alan On 24/03/2016 10:51, Chris Hegarty wrote: Trivially, looks like a minor oversight that inadvertently introduced a dependency on sun.misc.Unsafe. diff --git

RFR [9] 8152642: Remove sun.misc.Unsafe dependency from java.lang.reflect.Proxy

Trivially, looks like a minor oversight that inadvertently introduced a dependency on sun.misc.Unsafe. diff --git a/src/java.base/share/classes/java/lang/reflect/Proxy.java b/src/java.base/share/classes/java/lang/reflect/Proxy.java --- a/src/java.base/share/classes/java/lang/reflect/Proxy.java

Re: RFR (S) 8150463: StringConcat MH_INLINE_SIZED_EXACT should skip storage initialization

On 03/24/2016 12:19 PM, Chris Hegarty wrote: > On 24 Mar 2016, at 09:15, Peter Levart wrote: >> Looks nice to me, but I'm not a Reviewer. Quite an improvement for longer >> strings. > > +1 Thanks Peter and Chris! Pushed. -Aleksey

Re: RFR (S) 8150463: StringConcat MH_INLINE_SIZED_EXACT should skip storage initialization

On 24 Mar 2016, at 09:15, Peter Levart wrote: > Hi Aleksey, > > Looks nice to me, but I'm not a Reviewer. Quite an improvement for longer > strings. +1 -Chris. > Regards, Peter > > On 03/24/2016 08:31 AM, Aleksey Shipilev wrote: >> On 03/16/2016 11:13 AM, Aleksey

Re: RFR (S) 8150463: StringConcat MH_INLINE_SIZED_EXACT should skip storage initialization

Hi Aleksey, Looks nice to me, but I'm not a Reviewer. Quite an improvement for longer strings. Regards, Peter On 03/24/2016 08:31 AM, Aleksey Shipilev wrote: On 03/16/2016 11:13 AM, Aleksey Shipilev wrote: I'd like to improve our advanced String concat strategy, MH_INLINE_SIZED_EXACT, with

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

Hello, As I wrote in the bug, jdk9/dev currently fails when using --with-zlib=system with the new devkit on Linux. That will need to be fixed first. If the intention of this change is to enforce --with-zlib=system on OracleJDK builds, we should also update the Jib profile definitions for

Re: RFR (S) 8150463: StringConcat MH_INLINE_SIZED_EXACT should skip storage initialization

On 03/16/2016 11:13 AM, Aleksey Shipilev wrote: > I'd like to improve our advanced String concat strategy, > MH_INLINE_SIZED_EXACT, with skipping the storage initialization: > https://bugs.openjdk.java.net/browse/JDK-8150463 > > Webrev: > http://cr.openjdk.java.net/~shade/8150463/webrev.01/ >