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
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
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
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
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
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()
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
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
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
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
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
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
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
+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
On 24/03/2016 18:20, Mandy Chung wrote:
Exclude this test until JDK-8152622 is resolved.
Looks okay.
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
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:
> 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:
>
>
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
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
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
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
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
> 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
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
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
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?
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
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
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
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
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
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
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 @@
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.
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
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
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
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
>
>
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
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
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
>
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
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
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
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
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
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
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/
>
49 matches
Mail list logo