Re: RFC: System.console().encoding()

[Dawid Weiss]

+1 for adding a public Console.encoding(). I remember needing it as
well, the current hacks are very ugly.

Dawid

On Thu, Sep 15, 2016 at 8:42 AM, Aleksey Shipilev  wrote:
> Hi,
>
> Claes pointed out that our own reflective hacks to figure out console
> encoding do not work anymore [1]. But, we need the console encoding for
> reliably printing on the console from within different sources. Note
> that you would normally just use System.console() and its PrintWriter,
> but reality is a bit more complicated, and sometimes you need to write
> the plain char stream directly into the byte[]-accepting methods,
> encoding on your own.
>
> So, my question: should we, in the light of extended Jigsaw-solving
> crunch, provide the public Console.encoding() method that would return
> the console charset?
>
> Thanks,
> -Aleksey
>
> [1]
> http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html
>

RFC: System.console().encoding()

[Aleksey Shipilev]

Hi,

Claes pointed out that our own reflective hacks to figure out console
encoding do not work anymore [1]. But, we need the console encoding for
reliably printing on the console from within different sources. Note
that you would normally just use System.console() and its PrintWriter,
but reality is a bit more complicated, and sometimes you need to write
the plain char stream directly into the byte[]-accepting methods,
encoding on your own.

So, my question: should we, in the light of extended Jigsaw-solving
crunch, provide the public Console.encoding() method that would return
the console charset?

Thanks,
-Aleksey

[1]
http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html

Fwd: Reg - Sub Process creation from java takes more time

[Manjunath SV]

Hi All,

I am Manjunath, We are facing below issue in Java application.

Issue Details :-

Java application has a thread pool of size 30, When it receives Job message
 from JMS, It creates around 200+ jobs and submit into thread
pool,initially 30 threads creates shell script process very quick, later
process creation time gradually increases (5-9 mins).


Java application invokes shell script, Below is the code.

process = Runtime.getRuntime().exec(new String[] { script_name,
param1, param2, param3,param4 });

int response = process.waitFor();

Shell script :-

#!/bin/ksh
linux-command  -un $1 -pw $2  -f batch.txt < $3 > $4 2>&1

We redirected command output and errors to a file.

First job execution after application restart takes just 15 sec, later job
execution takes around 15 mins, some times 40 mins also.

We are using java 1.8.0_92.

Please advise on this.

Thanks in advance.

Regards,
Manjunath

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

[Steve Drach]

The most recent webrev is http://cr.openjdk.java.net/~sdrach/8153654/webrev.11/ 


Comments inline

>> The latest web revs.  Answers to questions in-line below:
>> 
>> http://cr.openjdk.java.net/~sdrach/8153654/webrev.10/
>> 
>> http://cr.openjdk.java.net/~sdrach/8153654/webrev.jdk/
> 
> This looks pretty good. My main comment is in VersionHelper (see below).
> 
> ClassFileReader.java
> 
> 337 String[] msg = {"err.multirelease.option.exists", 
> f.getName()};
> 389 String[] msg = 
> {"err.multirelease.jar.malformed”,
> 390 jarfile.getName(), rn
> 391 };
> 
> `msg` is not used.  These lines can be removed.

Done

> 
> line 81-95: this wants to add to VersionHelper if it’s a versioned entry.  I 
> suggest to move this to VersionHelper, something like this and replace the 
> add method.

I did essentially the same thing, but not exactly the same.

> 
> public static void addIfVersionedEntry(Path jarfile, String realEntryName, 
> String className) {
>if (realEntryName.startsWith(META_INF_VERSIONS)) {
>int len = META_INF_VERSIONS.length();
>int n = realEntryName.indexOf('/', len);
>if (n > 0) {
>String version = realEntryName.substring(len, n);
>assert (Integer.parseInt(version) > 8);
> 
>String v = versionMap.get(className);
>if (v != null && !v.equals(version)) {
>// name associated with a different ClassFile
>throw new 
> MultiReleaseException("err.multirelease.version.associated", className,
>v, version);
>}
>versionMap.put(className, version);
>} else {
>throw new MultiReleaseException("err.multirelease.jar.malformed",
>jarfile.toString(), realEntryName);
>}
>}
> }
> 
> I prefer to call String::length rather than hardcoding the length.

OK

>  I don’t see why VersionHelper caches ClassFile.  

A JarEntry (base) name has a one to many relationship with versions.  This 
implies the class name also has a one to many relationship with versions.  But 
a ClassFile (derived from the contents of the JarEntry) has a one to one 
relationship with version.  We desire a one to one
relationship for className to version and one way to assure that is to create 
two maps as I now have done.  I think the code is more obvious  now, at least I 
hope it is.

> I think it can cache a map from class name to the version for now.  We may 
> have to handle duplicated classes in more than one modular jar (it’s not 
> exported and should be allowed).  We could file a separate issue to look into 
> later.
> 
> This needs a CCC for the new --multi-release option.

That’s next.

> 
> Mandy

RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

[Patrick Reinhart]

Hi Jonathan,

Here are your changes in a webrev:

http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 


-Patrick

> Am 13.09.2016 um 14:45 schrieb Patrick Reinhart :
> 
> Hi  Jonathan,
> 
> On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote:
>> Hi Patrick,
>> Thank you very much for the offer to hold my patch for me!
> 
> No problem.
> 
>> Is it common practice to send patches to others using PGP?
> 
> No, this is my personal setting.
> 
>> Kind regards,
>> Jonathan
>> On 12 September 2016 at 21:08, Patrick Reinhart  wrote:
>>> Hi Jonathan,
>>> As I just also wanted to help some more clean-up in the JDKs final phase, I
>>> could offer you to hold that patch. Just send it to me and I will prepare
>>> the webrev for you….
>>> -Patrick
> 
> -Patrick

Re: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

[Joe Wang]

Thanks again, Daniel!

Joe

On 9/14/16, 12:25 PM, Daniel Fuchs wrote:

On 14/09/16 20:09, Joe Wang wrote:

Hi Daniel, Roger,

Thanks for the review!

The webrev is updated as we discussed. The deprecation message is in the
main interface classes but stresses that the entire application under
the resolver package and the util class (XMLCatalogResolver.java) are
deprecated and subject to removal in a future release.

http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/


This looks good to me Joe!
Thanks for the detailed explanations.

+1

-- daniel




As you noted, there's an internal usage in jaxws/jaxb. Aleksej and I
have worked together to get the standalone updated with the new Catalog
API. The JDK integration will happen soon.

The deprecation is not technically necessary for an internal API. Even
without the JDK 9 encapsulation, the compiler has always produced a
warning that the internal API is subject to change/removal, and should
not be directly referenced. Unfortunately, this particular one is in a
awkward situation. It was integrated along with jaxp from the Apache
library without a public API. Internal and external users are therefore
taken it as if it's okay to use. The encapsulation could be viewed
similarly as the existing compiler warning. The deprecation message
therefore serves as an enforcement that it is indeed in the plan to be
removed.

Best,
Joe

On 9/14/16, 10:15 AM, Roger Riggs wrote:

Hi,

I don't see there is much point in deprecating an API that is not
exported.
It doesn't show up in the javadoc and the compiler overrides with
-addexports would already be needed.

The internal uses should be updated but that should not be a reason to
put off warning other
consumers that a transition to another API is needed.  One of the
purposes of @deprecated is to start
a very slow/long process moving.

$.02, Roger


On 9/14/2016 5:11 AM, Daniel Fuchs wrote:

Hi Joe,

As much as I would like to support removing obsolete
classes, I wonder if the forRemoval=true is a bit
premature.

I see that for instance,
com.sun.org.apache.xml.internal.resolver.Catalog
seems to be still used at many places in our code base.

It would be more convincing if we could first make our
own codebase stop using these classes: then we could
be confident that forRemoval=true is the better choice!

best regards,

-- daniel

On 14/09/16 05:48, Joe Wang wrote:

Hi,

Please review the deprecation of the internal Catalog API.

JBS: https://bugs.openjdk.java.net/browse/JDK-8165784
webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/

Thanks,
Joe

Re: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

[Daniel Fuchs]

On 14/09/16 20:09, Joe Wang wrote:

Hi Daniel, Roger,

Thanks for the review!

The webrev is updated as we discussed. The deprecation message is in the
main interface classes but stresses that the entire application under
the resolver package and the util class (XMLCatalogResolver.java) are
deprecated and subject to removal in a future release.

http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/


This looks good to me Joe!
Thanks for the detailed explanations.

+1

-- daniel




As you noted, there's an internal usage in jaxws/jaxb. Aleksej and I
have worked together to get the standalone updated with the new Catalog
API. The JDK integration will happen soon.

The deprecation is not technically necessary for an internal API. Even
without the JDK 9 encapsulation, the compiler has always produced a
warning that the internal API is subject to change/removal, and should
not be directly referenced. Unfortunately, this particular one is in a
awkward situation. It was integrated along with jaxp from the Apache
library without a public API. Internal and external users are therefore
taken it as if it's okay to use. The encapsulation could be viewed
similarly as the existing compiler warning. The deprecation message
therefore serves as an enforcement that it is indeed in the plan to be
removed.

Best,
Joe

On 9/14/16, 10:15 AM, Roger Riggs wrote:

Hi,

I don't see there is much point in deprecating an API that is not
exported.
It doesn't show up in the javadoc and the compiler overrides with
-addexports would already be needed.

The internal uses should be updated but that should not be a reason to
put off warning other
consumers that a transition to another API is needed.  One of the
purposes of @deprecated is to start
a very slow/long process moving.

$.02, Roger


On 9/14/2016 5:11 AM, Daniel Fuchs wrote:

Hi Joe,

As much as I would like to support removing obsolete
classes, I wonder if the forRemoval=true is a bit
premature.

I see that for instance,
com.sun.org.apache.xml.internal.resolver.Catalog
seems to be still used at many places in our code base.

It would be more convincing if we could first make our
own codebase stop using these classes: then we could
be confident that forRemoval=true is the better choice!

best regards,

-- daniel

On 14/09/16 05:48, Joe Wang wrote:

Hi,

Please review the deprecation of the internal Catalog API.

JBS: https://bugs.openjdk.java.net/browse/JDK-8165784
webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/

Thanks,
Joe

Re: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

[Joe Wang]

Hi Daniel, Roger,

Thanks for the review!

The webrev is updated as we discussed. The deprecation message is in the 
main interface classes but stresses that the entire application under 
the resolver package and the util class (XMLCatalogResolver.java) are 
deprecated and subject to removal in a future release.


http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/


As you noted, there's an internal usage in jaxws/jaxb. Aleksej and I 
have worked together to get the standalone updated with the new Catalog 
API. The JDK integration will happen soon.


The deprecation is not technically necessary for an internal API. Even 
without the JDK 9 encapsulation, the compiler has always produced a 
warning that the internal API is subject to change/removal, and should 
not be directly referenced. Unfortunately, this particular one is in a 
awkward situation. It was integrated along with jaxp from the Apache 
library without a public API. Internal and external users are therefore 
taken it as if it's okay to use. The encapsulation could be viewed 
similarly as the existing compiler warning. The deprecation message 
therefore serves as an enforcement that it is indeed in the plan to be 
removed.


Best,
Joe

On 9/14/16, 10:15 AM, Roger Riggs wrote:

Hi,

I don't see there is much point in deprecating an API that is not 
exported.
It doesn't show up in the javadoc and the compiler overrides with 
-addexports would already be needed.


The internal uses should be updated but that should not be a reason to 
put off warning other
consumers that a transition to another API is needed.  One of the 
purposes of @deprecated is to start

a very slow/long process moving.

$.02, Roger


On 9/14/2016 5:11 AM, Daniel Fuchs wrote:

Hi Joe,

As much as I would like to support removing obsolete
classes, I wonder if the forRemoval=true is a bit
premature.

I see that for instance, 
com.sun.org.apache.xml.internal.resolver.Catalog

seems to be still used at many places in our code base.

It would be more convincing if we could first make our
own codebase stop using these classes: then we could
be confident that forRemoval=true is the better choice!

best regards,

-- daniel

On 14/09/16 05:48, Joe Wang wrote:

Hi,

Please review the deprecation of the internal Catalog API.

JBS: https://bugs.openjdk.java.net/browse/JDK-8165784
webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/

Thanks,
Joe

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

[Mandy Chung]

> On Sep 13, 2016, at 5:52 PM, Steve Drach  wrote:
> 
> The latest web revs.  Answers to questions in-line below:
> 
> http://cr.openjdk.java.net/~sdrach/8153654/webrev.10/
> 
> http://cr.openjdk.java.net/~sdrach/8153654/webrev.jdk/

This looks pretty good. My main comment is in VersionHelper (see below).

ClassFileReader.java

 337 String[] msg = {"err.multirelease.option.exists", 
f.getName()};
 389 String[] msg = 
{"err.multirelease.jar.malformed”,
 390 jarfile.getName(), rn
 391 };

`msg` is not used.  These lines can be removed.

line 81-95: this wants to add to VersionHelper if it’s a versioned entry.  I 
suggest to move this to VersionHelper, something like this and replace the add 
method.

public static void addIfVersionedEntry(Path jarfile, String realEntryName, 
String className) {
if (realEntryName.startsWith(META_INF_VERSIONS)) {
int len = META_INF_VERSIONS.length();
int n = realEntryName.indexOf('/', len);
if (n > 0) {
String version = realEntryName.substring(len, n);
assert (Integer.parseInt(version) > 8);

String v = versionMap.get(className);
if (v != null && !v.equals(version)) {
// name associated with a different ClassFile
throw new 
MultiReleaseException("err.multirelease.version.associated", className,
v, version);
}
versionMap.put(className, version);
} else {
throw new MultiReleaseException("err.multirelease.jar.malformed",
jarfile.toString(), realEntryName);
}
}
}

I prefer to call String::length rather than hardcoding the length.  I don’t see 
why VersionHelper caches ClassFile.  I think it can cache a map from class name 
to the version for now.  We may have to handle duplicated classes in more than 
one modular jar (it’s not exported and should be allowed).  We could file a 
separate issue to look into later.

This needs a CCC for the new --multi-release option.

Mandy

Re: JDK 9 RFR of JDK-8166054: Problem list JarURLConnectionUseCaches.java until JDK-8165988 is fixed

[Rob McKenna]

Sorry Joe,

This passed just fine in jprt. I'll change it to othervm now. (I only noticed 
this problem on 8 last night)

-Rob

On 14/09/16 06:09, Daniel Fuchs wrote:
> Hi Joe,
> 
> Looks good to me!
> 
> -- daniel
> 
> On 14/09/16 18:07, joe darcy wrote:
> >Hello,
> >
> >Until JDK-8165988 is fixed, the test
> >
> >sun/net/www/protocol/jar/JarURLConnectionUseCaches.java
> >
> >should be problem listed on windows. Please review the patch below.
> >
> >Thanks,
> >
> >-Joe
> >
> >--- a/test/ProblemList.txtWed Sep 14 07:37:15 2016 -0700
> >+++ b/test/ProblemList.txtWed Sep 14 10:03:29 2016 -0700
> >@@ -159,7 +159,6 @@
> >
> > # jdk_net
> >
> >-
> > java/net/MulticastSocket/NoLoopbackPackets.java 7122846 macosx-all
> > java/net/MulticastSocket/SetLoopbackMode.java 7122846 macosx-all
> >
> >@@ -173,6 +172,8 @@
> > java/net/httpclient/http2/ErrorTest.java 8158127 solaris-all,windows-all
> > java/net/httpclient/http2/TLSConnection.java 8157482 macosx-all
> >
> >+sun/net/www/protocol/jar/JarURLConnectionUseCaches.java 8165988
> >windows-all
> >+
> > 
> >
> >
> > # jdk_nio
> >
> 

Re: RFR: 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information

[Kumar Srinivasan]

Henry,

Thanks for taking care of this, if the VM team is happy with it.
I am good, consider me as reviewer.

Thanks
Kumar


Well, comments about -Xcomp and -Xusealtsigs doesn’t seem to require a change, 
are we good on this webrev?

Let me know if there is anything need to change, otherwise, I would need 
official +1 from reviewers. :)

Cheers,
Henry

On September 8, 2016 at 10:39:13 PM, Alan Bateman (alan.bate...@oracle.com) 
wrote:
  
  
On 08/09/2016 20:52, Henry Jen wrote:

Hi,

Please review a trivial fix for bug 8042148 at following URL:
Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8042148/webrev/
Bug: https://bugs.openjdk.java.net/browse/JDK-8042148



The ordering/re-wording looks okay, just surprised to see -Xcomp added
(I realize the `java -X` output has listed -Xint and -Xmixed for a long
time).
  
-Alan
  

Re: RFR(s): 4285505: deprecate java.lang.Compiler

[Stuart Marks]

Hi Kris,

Based on your email earlier in this thread, it seemed like you didn't object to 
deprecating j.l.Compiler in Java 9. Since the other respondents were already in 
favor, I've already pushed the changeset. (Sorry.) As things stand, the 
changeset is in the jdk9/dev forest, but it's not in any promoted JDK 9 builds.


If we were to proceed with this as it stands, then the API change in Java SE 9 
visible to programs will merely be the addition of the following annotation to 
java.lang.Compiler:


@Deprecated(since="9", forRemoval=true)

Existing binaries use j.l.Compiler will continue to run, and existing sources 
that use it can still compile, though they will get compilation warnings. The 
earliest release in which java.lang.Compiler would actually be absent is Java SE 
10. There is currently no schedule or project for SE 10, but I would guess that 
it wouldn't ship anytime before mid-2018.


If removal in this time frame is really a problem for Azul, then I suppose this 
deprecation can be revisited and possibly changed in Java SE 9.


But I'm hard pressed to see what value is actually being added by 
java.lang.Compiler that can't be done better by a platform-specific API. You 
mentioned the command() method:


public staticObject   command(Object 
  any)

Anything that uses this API is platform-specific. Even if it avoids 
platform-specific types, for example by using String arrays, the values it 
passes and returns are unavoidably platform-specific. Users of this API would be 
better served by using a platform-specific API. Can't Azul create one and 
migrate to it?


s'marks



On 9/13/16 5:09 PM, Krystal Mok wrote:

Hi OpenJDK developers,

Replying on behalf of Azul Systems:

java.lang.Compiler is an integral part of the current Java SE spec, and is 
currently being used by multiple independent Java SE implementations of that 
spec in a spec-conforming way (Azul Zing, Azul Vega, and IBM J9 being concrete 
exampleS). Before deprecation, a proposed replacement for Java SE 9 would need 
to be vetted to make sure that is satisfies the needs of current 
implementations. While JEP165 is a start in that direction, it appears to be 
very HotSpot specific, and is not written in a specification form (e.g. there 
is no "If no compiler is available, these methods do nothing." mention).


For example, Azul Zing’s ReadyNow feature makes use of the java.lang.Compiler 
API to allow applications to pass directives down to the VM, in a similar 
spirit to what IBM J9 does with the API. We continuously evolve and enrich the 
commands we support in the API, e.g. in the “Object command(Object)” method, 
and it would be potentially problematic for us to lose the current API without 
having a flexible replacement in the Java SE spec.


As such, we suggest that for the time being, java.lang.Compiler should be 
neither depracated nor removed in Java SE 9. As a practical spec'ed 
replacement is proposed that will cover the needs of implementations currently 
using java.lang.Compiler, this can change. Perhaps in the Java SE 10 timeframe.


Thanks,
Kris (OpenJDK username: kmo)

On Wed, Sep 7, 2016 at 1:52 PM, Stuart Marks > wrote:


Hi all,

Please review this small patch to deprecate java.lang.Compiler for removal.

Thanks,

s'marks

# HG changeset patch
# User smarks
# Date 1473281459 25200
#  Wed Sep 07 13:50:59 2016 -0700
# Node ID e520c4e6970c079573bad20c6b1eba8d5794b34d
# Parent  76ba1b74f268f1acc4847e242a2cfcd29880418c
4285505: deprecate java.lang.Compiler
Reviewed-by: XXX

diff -r 76ba1b74f268 -r e520c4e6970c
src/java.base/share/classes/java/lang/Compiler.java
--- a/src/java.base/share/classes/java/lang/Compiler.java  Tue Sep 06
16:08:54 2016 -0700
+++ b/src/java.base/share/classes/java/lang/Compiler.java  Wed Sep 07
13:50:59 2016 -0700
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1995, 2016, Oracle and/or its affiliates. All rights
reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -29,21 +29,18 @@
  * The {@code Compiler} class is provided to support Java-to-native-code
  * compilers and related services. By design, the {@code Compiler} class 
does
  * nothing; it serves as a placeholder for a JIT compiler implementation.
+ * If no compiler is available, these methods do nothing.
  *
- *  When the Java Virtual Machine first starts, it determines if the
system
- * property {@code java.compiler} exists. (System properties are accessible
- * through {@link System#getProperty(String)} and {@link
- * System#getProperty(String, String)}.  If so, it is assumed to be the
name of
- * a library (with a platform-dependent exact location and type)

Re: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

[Roger Riggs]

Hi,

I don't see there is much point in deprecating an API that is not exported.
It doesn't show up in the javadoc and the compiler overrides with 
-addexports would already be needed.


The internal uses should be updated but that should not be a reason to 
put off warning other
consumers that a transition to another API is needed.  One of the 
purposes of @deprecated is to start

a very slow/long process moving.

$.02, Roger


On 9/14/2016 5:11 AM, Daniel Fuchs wrote:

Hi Joe,

As much as I would like to support removing obsolete
classes, I wonder if the forRemoval=true is a bit
premature.

I see that for instance, com.sun.org.apache.xml.internal.resolver.Catalog
seems to be still used at many places in our code base.

It would be more convincing if we could first make our
own codebase stop using these classes: then we could
be confident that forRemoval=true is the better choice!

best regards,

-- daniel

On 14/09/16 05:48, Joe Wang wrote:

Hi,

Please review the deprecation of the internal Catalog API.

JBS: https://bugs.openjdk.java.net/browse/JDK-8165784
webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/

Thanks,
Joe

Re: JDK 9 RFR of JDK-8166054: Problem list JarURLConnectionUseCaches.java until JDK-8165988 is fixed

[Daniel Fuchs]

Hi Joe,

Looks good to me!

-- daniel

On 14/09/16 18:07, joe darcy wrote:

Hello,

Until JDK-8165988 is fixed, the test

sun/net/www/protocol/jar/JarURLConnectionUseCaches.java

should be problem listed on windows. Please review the patch below.

Thanks,

-Joe

--- a/test/ProblemList.txtWed Sep 14 07:37:15 2016 -0700
+++ b/test/ProblemList.txtWed Sep 14 10:03:29 2016 -0700
@@ -159,7 +159,6 @@

 # jdk_net

-
 java/net/MulticastSocket/NoLoopbackPackets.java 7122846 macosx-all
 java/net/MulticastSocket/SetLoopbackMode.java 7122846 macosx-all

@@ -173,6 +172,8 @@
 java/net/httpclient/http2/ErrorTest.java 8158127 solaris-all,windows-all
 java/net/httpclient/http2/TLSConnection.java 8157482 macosx-all

+sun/net/www/protocol/jar/JarURLConnectionUseCaches.java 8165988
windows-all
+
 


 # jdk_nio

JDK 9 RFR of JDK-8166054: Problem list JarURLConnectionUseCaches.java until JDK-8165988 is fixed

[joe darcy]

Hello,

Until JDK-8165988 is fixed, the test

sun/net/www/protocol/jar/JarURLConnectionUseCaches.java

should be problem listed on windows. Please review the patch below.

Thanks,

-Joe

--- a/test/ProblemList.txtWed Sep 14 07:37:15 2016 -0700
+++ b/test/ProblemList.txtWed Sep 14 10:03:29 2016 -0700
@@ -159,7 +159,6 @@

 # jdk_net

-
 java/net/MulticastSocket/NoLoopbackPackets.java 7122846 macosx-all
 java/net/MulticastSocket/SetLoopbackMode.java 7122846 macosx-all

@@ -173,6 +172,8 @@
 java/net/httpclient/http2/ErrorTest.java 8158127 solaris-all,windows-all
 java/net/httpclient/http2/TLSConnection.java 8157482 macosx-all

+sun/net/www/protocol/jar/JarURLConnectionUseCaches.java 8165988 windows-all
+
 

 # jdk_nio

Re: Review Request: JDK-8157464: StackWalker.getCallerClass() is not

[Brent Christian]

Thanks, Mandy - sounds fine.
webrev.03 all looks good to me.

-Brent
On 09/13/2016 05:04 PM, Mandy Chung wrote:

Yes that’s one option.

JVM_STACKWALK_FILL_CLASS_REFS_ONLY is not necessarily used to get caller class.  For 
example, AccessControlContext is interested in protection domains.  We could build a 
specialized impl class to walk the stack fetching Class only whereas 
getCallerClass will stop walking after a few top frames.   So a different bit will 
enable future experiment.  Having said that, the assert should be reverted and minor 
adjustment:

@@ -140,6 +143,13 @@
fill_stackframe(stackFrame, method, bci);
  } else {
assert (use_frames_array(mode) == false, "Bad mode for get caller 
class");
+  if (get_caller_class(mode) && index == start_index && 
method->caller_sensitive()) {
+ResourceMark rm(THREAD);
+THROW_MSG_0(vmSymbols::java_lang_UnsupportedOperationException(),
+  err_msg("StackWalker::getCallerClass called from @CallerSensitive %s 
method",
+  method->name_and_sig_as_C_string()));
+  }
+

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.03/

Mandy


On Sep 13, 2016, at 4:09 PM, Brent Christian  wrote:

Hi, Mandy

Is a new JVM_STACKWALK_GET_CALLER_CLASS bit needed in jvm.h?  AFAICT, 
JVM_STACKWALK_FILL_CLASS_REFS_ONLY is already only set for the getCallerClass() 
case.

Could the new get_caller_class() instead check if 
JVM_STACKWALK_FILL_CLASS_REFS_ONLY is set?  (Yes, this would be a third 
function checking the same thing, along with need_method_info() and 
use_frames_array()...)

-Brent
On 09/13/2016 03:18 PM, Mandy Chung wrote:

Hi Daniel,

StackWalker::getCallerClass is a convenient method to find the caller class and 
is specified to skip the hidden frames (that’s the caller we are interested 
in).   Since StackWalker only asks VM to fill in classes, the library can’t 
tell if it’s an anonymous class or not.

Your question prompts me to revise the patch and simply skip the hidden frame 
if this stack walk is to lookup caller class to match the specification.  I 
think this is a better fix:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.02/

We may re-examine this in the future if getCallerClass should get MemberName 
like the walk method such that we can determine if it’s a hidden frame and the 
performance difference.

Mandy


On Sep 13, 2016, at 11:54 AM, Daniel Fuchs  wrote:

Hi Mandy,

This looks good to me.
But I wonder about these 5 lines - isn't this introducing a change
of behavior if the caller is an anonymous class?

149   InstanceKlass* ik = method->method_holder();
150   if (ik->is_anonymous()) {
151 // use the host class as the caller class
152 ik = ik->host_klass();
153   }

What is the reason for returning the host class instead?

best regards,

-- daniel

On 13/09/16 19:24, Mandy Chung wrote:

Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.01

This revises the proposal posted some time ago [1].

StackWalker::getCallerClass is a convenient method to find the caller class. It 
will return the invoker of the MethodHandle and java.lang.reflect.Method for 
the method calling StackWalker::getCallerClass, as it’s currently specified.

This issue is related to MethodHandle for @CallerSensitive method.  It behaves 
as if the caller is the lookup class and in the current implementation, the 
actual caller class is not the lookup class but a generated class.

One intended usage of StackWalker::getCallerClass is to be called by library 
code acting as an agent that calls @CallerSensitive method on behalf of the 
true caller and typically it will call an appropriate method with the 
appropriate parameter (e.g. ResourceBundle.getBundle(String, ClassLoader).

Given that StackWalker::getCallerClass is not expected to be used by any @CS 
method, this patch proposes to catch and throw an exception if 
StackWalker::getCallerClass is called by a @CS method.  This will allow time to 
revisit this when such need is identified.

thanks
Mandy
[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042345.html

Re: RFR: 8042148: Ensure that the java launcher help is consistent with the manpage where they report common information

[Henry Jen]

Well, comments about -Xcomp and -Xusealtsigs doesn’t seem to require a change, 
are we good on this webrev?

Let me know if there is anything need to change, otherwise, I would need 
official +1 from reviewers. :)

Cheers,
Henry

On September 8, 2016 at 10:39:13 PM, Alan Bateman (alan.bate...@oracle.com) 
wrote:
>  
>  
> On 08/09/2016 20:52, Henry Jen wrote:
> > Hi,
> >
> > Please review a trivial fix for bug 8042148 at following URL:
> > Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8042148/webrev/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8042148
> >
> >
> The ordering/re-wording looks okay, just surprised to see -Xcomp added
> (I realize the `java -X` output has listed -Xint and -Xmixed for a long
> time).
>  
> -Alan
>  

Re: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files

[Naoto Sato]

+1

Naoto

On 9/14/16 6:50 AM, Roger Riggs wrote:

+1

On 9/14/2016 2:34 AM, Thomas Stüfe wrote:

Hi all,

thanks for the reviews. Here is version two:

http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/


Only cosmetic changes:
- made code pre-c99 compatible
- consistently use dirent64
- fix indentation in ifs
- removed blank between malloc and cast

Kind Regards, Thomas



On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu
mailto:masayoshi.oku...@oracle.com>> wrote:

Looks good to me. Thank you for fixing this bug!

Masayoshi



On 9/13/2016 11:49 PM, Thomas Stüfe wrote:

Hi Christoph, thanks for your review! Yes, I can remove the blank.

Kind Regards, Thomas

On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph
mailto:christoph.lan...@sap.com>

wrote:
Hi Thomas,

your change looks good. I'm also forwarding this to
i18n-dev as issues in
TimeZone implementation are mostly handled there.

One remark: Can you take the opportunity to also remove
the blank between
the cast and malloc in line 150: "(struct dirent64 *)
malloc..."?

Unfortunately I'm no reviewer, so you still need an
official review.

Best regards
Christoph

-Original Message-
From: core-libs-dev
[mailto:core-libs-dev-boun...@openjdk.java.net
] On

Behalf

Of Thomas Stüfe
Sent: Dienstag, 13. September 2016 12:54
To: Java Core Libs mailto:core-libs-dev@openjdk.java.net>>
Subject: RFR(xs): 8165936: Potential Heap buffer
overflow when seaching
timezone info files

Dear all,

please take a look at this small change:

Bug: https://bugs.openjdk.java.net/browse/JDK-8165936

Webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8165936-


Potential-Heap-buffer-

overflow-when-seaching-timezone-info-files/webrev.00/webrev/

readdir_r is used to iterate over the content of a
system directory, but
the buffer passed to it is too small: Its size should
include the size of
the dirent structure itself (minus the d_name member).

The fix also now checks the return code of pathconf(),
and if pathconf()
returns an error, falls back to the NAME_MAX compile
time constant.
Finally, it imposes a minimum size for the buffer,
because on older

System

V systems NAME_MAX may be surprisingly small and
readdir_r will not check
the output buffer size. I think it is better to err on
the safe side

here.

Kind Regards, Thomas

Re: RFR 9: 8155760 Implement Serialization Filtering

[Roger Riggs]

Hi Chris,

Thanks for the review and comments...

On 9/14/2016 5:46 AM, Chris Hegarty wrote:

On 08/09/16 20:09, Roger Riggs wrote:

Please review updates to the Serialization filtering API and
implementation:
  - The ObjectInputFilter pattern based filters support matching on
module names as well as package and class names.
  - Rename of system property and java.security property for
configurable filters.  (jdk.serialFilter)
  - ObjectInputFilter clarifications about the values passed to the 
filter

  - Javadoc editorial improvements
  - Clarification of SerializablePermission description of targets

  - More tests

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/


This looks very good Roger, just a few comments:

1) The pattern separator in the java.security file should be ';'
   Right?
   925 #jdk.serialFilter=pattern,pattern

Good catch, will fix

   ^^^

2) A question on the expected usage. During the initialization of
   OIS the process-wide filter is cached in an instance field,
   'serialFilter'. A subsequent change to the process-wide filter
   will not affect the OIS instance. I think this is ok, just
   checking the expected usage, as the example in the OIF class
   description reads the process-wide filter ever time. Maybe
   the example should be changed slightly to not promote this type
   of usage? Maybe just remove the call to getSerialFilter?
The process-wide filter is set-once, so it can't change. 
(ObjectInputFilter.setSerialFilter())

The caching in OIS as a final field allows some optimizations;
Client code as in the example could do the same for performance reasons.



3) Are third-party OIS implementations required, or expected, to
   "callback" to the filter? The spec, of course, would appear to
   allow it, but not require it? Just wondering if this is required,
   or not, as it is not clear to me.

Practically, I don't think it can be required; but is encouraged.

Thanks, Roger




-Chris.



SpecDiff:
http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html

Javadoc (subset)
http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html 



http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html 



http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html 




Thanks, Roger

Re: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files

[Roger Riggs]

+1

On 9/14/2016 2:34 AM, Thomas Stüfe wrote:

Hi all,

thanks for the reviews. Here is version two:

http://cr.openjdk.java.net/~stuefe/webrevs/8165936-Potential-Heap-buffer-overflow-when-seaching-timezone-info-files/webrev.01/webrev/ 



Only cosmetic changes:
- made code pre-c99 compatible
- consistently use dirent64
- fix indentation in ifs
- removed blank between malloc and cast

Kind Regards, Thomas



On Tue, Sep 13, 2016 at 5:25 PM, Masayoshi Okutsu 
mailto:masayoshi.oku...@oracle.com>> wrote:


Looks good to me. Thank you for fixing this bug!

Masayoshi



On 9/13/2016 11:49 PM, Thomas Stüfe wrote:

Hi Christoph, thanks for your review! Yes, I can remove the blank.

Kind Regards, Thomas

On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph
mailto:christoph.lan...@sap.com>

wrote:
Hi Thomas,

your change looks good. I'm also forwarding this to
i18n-dev as issues in
TimeZone implementation are mostly handled there.

One remark: Can you take the opportunity to also remove
the blank between
the cast and malloc in line 150: "(struct dirent64 *)
malloc..."?

Unfortunately I'm no reviewer, so you still need an
official review.

Best regards
Christoph

-Original Message-
From: core-libs-dev
[mailto:core-libs-dev-boun...@openjdk.java.net
] On

Behalf

Of Thomas Stüfe
Sent: Dienstag, 13. September 2016 12:54
To: Java Core Libs mailto:core-libs-dev@openjdk.java.net>>
Subject: RFR(xs): 8165936: Potential Heap buffer
overflow when seaching
timezone info files

Dear all,

please take a look at this small change:

Bug: https://bugs.openjdk.java.net/browse/JDK-8165936

Webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8165936-


Potential-Heap-buffer-

overflow-when-seaching-timezone-info-files/webrev.00/webrev/

readdir_r is used to iterate over the content of a
system directory, but
the buffer passed to it is too small: Its size should
include the size of
the dirent structure itself (minus the d_name member).

The fix also now checks the return code of pathconf(),
and if pathconf()
returns an error, falls back to the NAME_MAX compile
time constant.
Finally, it imposes a minimum size for the buffer,
because on older

System

V systems NAME_MAX may be surprisingly small and
readdir_r will not check
the output buffer size. I think it is better to err on
the safe side

here.

Kind Regards, Thomas

MethodHandle loop body parameters and Stream.reduce accumulator parameters are not in the same order

[Remi Forax]

Hi everybody,
i've just found that the parameters of the body (a MethodHandle) of 
MethodHandles.countedLoop (both overloads) and iteratedLoop are not in the same 
order as the accumulator in methods Stream.reduce, given that they conceptually 
represent the same thing, i think the first two parameters of body should be 
swapped in countedLoop and iteratedLoop.

in Stream:
 U reduce(U identity,
 BiFunction accumulator,
 BinaryOperator combiner)
 so this is equivalent to value = accumulator(value, element)

In MethodHandles:
   MethodHandle iteratedLoop(MethodHandle iterator,
 MethodHandle init,
 MethodHandle body)
  with value = body(element, value, iterable)
it should be
  value = body(value, element, iterable).

Same things for 
   MethodHandle countedLoop(MethodHandle start,
MethodHandle end,
MethodHandle init,
MethodHandle body)  
  it should be
value = body(value, index, array); 
  instead of
value = body(index, value, array);

the other loop combinators do not be to be changed.

cheers,
Rémi

Re: RFR(s): 4285505: deprecate java.lang.Compiler

[Remi Forax]

Hi Krys,
why do you need a public API to send the profile to the JIT compiler ?

Rémi

- Mail original -
> De: "Krystal Mok" 
> À: "Stuart Marks" 
> Cc: "core-libs-dev" 
> Envoyé: Mercredi 14 Septembre 2016 02:09:54
> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler

> Hi OpenJDK developers,
> 
> Replying on behalf of Azul Systems:
> 
> java.lang.Compiler is an integral part of the current Java SE spec, and is
> currently being used by multiple independent Java SE implementations of
> that spec in a spec-conforming way (Azul Zing, Azul Vega, and IBM J9 being
> concrete exampleS). Before deprecation, a proposed replacement for Java SE
> 9 would need to be vetted to make sure that is satisfies the needs of
> current implementations. While JEP165 is a start in that direction, it
> appears to be very HotSpot specific, and is not written in a specification
> form (e.g. there is no "If no compiler is available, these methods do
> nothing." mention).
> 
> For example, Azul Zing’s ReadyNow feature makes use of the
> java.lang.Compiler API to allow applications to pass directives down to the
> VM, in a similar spirit to what IBM J9 does with the API. We continuously
> evolve and enrich the commands we support in the API, e.g. in the “Object
> command(Object)” method, and it would be potentially problematic for us to
> lose the current API without having a flexible replacement in the Java SE
> spec.
> 
> As such, we suggest that for the time being, java.lang.Compiler should be
> neither depracated nor removed in Java SE 9. As a practical spec'ed
> replacement is proposed that will cover the needs of implementations
> currently using java.lang.Compiler, this can change. Perhaps in the Java SE
> 10 timeframe.
> 
> Thanks,
> Kris (OpenJDK username: kmo)
> 
> On Wed, Sep 7, 2016 at 1:52 PM, Stuart Marks 
> wrote:
> 
>> Hi all,
>>
>> Please review this small patch to deprecate java.lang.Compiler for removal.
>>
>> Thanks,
>>
>> s'marks
>>
>> # HG changeset patch
>> # User smarks
>> # Date 1473281459 25200
>> #  Wed Sep 07 13:50:59 2016 -0700
>> # Node ID e520c4e6970c079573bad20c6b1eba8d5794b34d
>> # Parent  76ba1b74f268f1acc4847e242a2cfcd29880418c
>> 4285505: deprecate java.lang.Compiler
>> Reviewed-by: XXX
>>
>> diff -r 76ba1b74f268 -r e520c4e6970c src/java.base/share/classes/ja
>> va/lang/Compiler.java
>> --- a/src/java.base/share/classes/java/lang/Compiler.java   Tue Sep
>> 06 16:08:54 2016 -0700
>> +++ b/src/java.base/share/classes/java/lang/Compiler.java   Wed Sep
>> 07 13:50:59 2016 -0700
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1995, 2016, Oracle and/or its affiliates. All rights
>> reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -29,21 +29,18 @@
>>   * The {@code Compiler} class is provided to support Java-to-native-code
>>   * compilers and related services. By design, the {@code Compiler} class
>> does
>>   * nothing; it serves as a placeholder for a JIT compiler implementation.
>> + * If no compiler is available, these methods do nothing.
>>   *
>> - *  When the Java Virtual Machine first starts, it determines if the
>> system
>> - * property {@code java.compiler} exists. (System properties are
>> accessible
>> - * through {@link System#getProperty(String)} and {@link
>> - * System#getProperty(String, String)}.  If so, it is assumed to be the
>> name of
>> - * a library (with a platform-dependent exact location and type); {@link
>> - * System#loadLibrary} is called to load that library. If this loading
>> - * succeeds, the function named {@code java_lang_Compiler_start()} in that
>> - * library is called.
>> - *
>> - *  If no compiler is available, these methods do nothing.
>> + * @deprecated JIT compilers and their technologies vary too widely to
>> + * be controlled effectively by a standardized interface. As such, many
>> + * JIT compiler implementations ignore this interface, and are instead
>> + * controllable by implementation-specific mechanisms such as command-line
>> + * options. This class is subject to removal in a future version of Java
>> SE.
>>   *
>>   * @author  Frank Yellin
>>   * @since   1.0
>>   */
>> +@Deprecated(since="9", forRemoval=true)
>>  public final class Compiler  {
>>  private Compiler() {}   // don't make instances
>>

Re: RFR 9: 8165261: RMI API to export an object with a serialization filter

[Daniel Fuchs]

Hi Roger,

On 13/09/16 20:10, Roger Riggs wrote:

Hi Daniel,

Thanks for the review and comments...
Webrev updated in place.



Looks good to me!

best regards,

-- daniel

Re: RFR 9: 8165261: RMI API to export an object with a serialization filter

[Chris Hegarty]

On 12/09/16 21:42, Roger Riggs wrote:

Please review an update to enable serialization filtering for exported
RMI objects.

Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-rmi-filter-8165261/


This looks good to me Roger.

-Chris.

Re: RFR 9: 8155760 Implement Serialization Filtering

[Chris Hegarty]

On 08/09/16 20:09, Roger Riggs wrote:

Please review updates to the Serialization filtering API and
implementation:
  - The ObjectInputFilter pattern based filters support matching on
module names as well as package and class names.
  - Rename of system property and java.security property for
configurable filters.  (jdk.serialFilter)
  - ObjectInputFilter clarifications about the values passed to the filter
  - Javadoc editorial improvements
  - Clarification of SerializablePermission description of targets

  - More tests

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/


This looks very good Roger, just a few comments:

1) The pattern separator in the java.security file should be ';'
   Right?
   925 #jdk.serialFilter=pattern,pattern
   ^^^

2) A question on the excepted usage. During the initialization of
   OIS the process-wide filter is cached in an instance field,
   'serialFilter'. A subsequent change to the process-wide filter
   will not affect the OIS instance. I think this is ok, just
   checking the expected usage, as the example in the OIF class
   description reads the process-wide filter ever time. Maybe
   the example should be changed slightly to no promote this type
   of usage? Maybe just remove the call to getSerialFilter?

3) Are third-party OIS implementations required, or expected, to
   "callback" to the filter? The spec, of course, would appear to
   allow it, but not require it? Just wondering if this is required,
   or not, as it is not clear to me.

-Chris.



SpecDiff:
http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html

Javadoc (subset)
http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html

http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html

http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html


Thanks, Roger

Re: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

[Daniel Fuchs]

Hi Joe,

As much as I would like to support removing obsolete
classes, I wonder if the forRemoval=true is a bit
premature.

I see that for instance, com.sun.org.apache.xml.internal.resolver.Catalog
seems to be still used at many places in our code base.

It would be more convincing if we could first make our
own codebase stop using these classes: then we could
be confident that forRemoval=true is the better choice!

best regards,

-- daniel

On 14/09/16 05:48, Joe Wang wrote:

Hi,

Please review the deprecation of the internal Catalog API.

JBS: https://bugs.openjdk.java.net/browse/JDK-8165784
webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/

Thanks,
Joe

Re: Review Request: JDK-8157464: StackWalker.getCallerClass() is not

[Daniel Fuchs]

Hi Mandy,

webrev.03 looks good to me!

best regards,

-- daniel

On 14/09/16 01:04, Mandy Chung wrote:

Yes that’s one option.

JVM_STACKWALK_FILL_CLASS_REFS_ONLY is not necessarily used to get caller class.  For 
example, AccessControlContext is interested in protection domains.  We could build a 
specialized impl class to walk the stack fetching Class only whereas 
getCallerClass will stop walking after a few top frames.   So a different bit will 
enable future experiment.  Having said that, the assert should be reverted and minor 
adjustment:

@@ -140,6 +143,13 @@
   fill_stackframe(stackFrame, method, bci);
 } else {
   assert (use_frames_array(mode) == false, "Bad mode for get caller 
class");
+  if (get_caller_class(mode) && index == start_index && 
method->caller_sensitive()) {
+ResourceMark rm(THREAD);
+THROW_MSG_0(vmSymbols::java_lang_UnsupportedOperationException(),
+  err_msg("StackWalker::getCallerClass called from @CallerSensitive %s 
method",
+  method->name_and_sig_as_C_string()));
+  }
+

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157464/webrev.03/

Mandy

Re: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

[Daniel Fuchs]

Hi Joe,

I will review it in more details but here is an early feedback:

  66  * href="http://download.java.net/java/jdk9/docs/api/javax/xml/catalog/package-summary.html";>

  67  * new public API.

The following should work (it did in the past, might be worth
checking that it still does):

 * {@linkplain javax.xml.catalog new public API}

and should avoid putting in absolute hyperlinks that might become
obsolete.

best regards

-- daniel

On 14/09/16 05:48, Joe Wang wrote:

Hi,

Please review the deprecation of the internal Catalog API.

JBS: https://bugs.openjdk.java.net/browse/JDK-8165784
webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/

Thanks,
Joe