Re: RFR(XXXS): 8186613: remove ClassFileInstaller from jdk/test/lib/testlibrary

[Ivan Gerasimov]

On 8/23/17 8:58 PM, Igor Ignatyev wrote:

http://cr.openjdk.java.net/~iignatyev//8186613/webrev.00/index.html

58 lines changed: 0 ins; 57 del; 1 mod; 64 unchg

Hi all,

could you please review this tiny patch which removes ClassFileInstaller from 
jdk/test/lib/testlibrary and updates the tests to use ClassFileInstaller from 
/test/lib?

webrev: http://cr.openjdk.java.net/~iignatyev//8186613/webrev.00/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8186613
testing: tests which use ClassFileInstaller


Looks good!

With kind regards,
Ivan


Thanks,
-- Igor
  





--
With kind regards,
Ivan Gerasimov

RFR(XXXS): 8186613: remove ClassFileInstaller from jdk/test/lib/testlibrary

[Igor Ignatyev]

http://cr.openjdk.java.net/~iignatyev//8186613/webrev.00/index.html
> 58 lines changed: 0 ins; 57 del; 1 mod; 64 unchg

Hi all,

could you please review this tiny patch which removes ClassFileInstaller from 
jdk/test/lib/testlibrary and updates the tests to use ClassFileInstaller from 
/test/lib?

webrev: http://cr.openjdk.java.net/~iignatyev//8186613/webrev.00/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8186613
testing: tests which use ClassFileInstaller

Thanks,
-- Igor
 

Re: RFR JDK-8186142: ZipPath.{starts, ends}With(nonZipPath) throws an exception, but should return false

[Martin Buchholz]

Looks good.

I would rename pme to something like mismatchedProviders

On Wed, Aug 23, 2017 at 6:05 PM, Xueming Shen 
wrote:

> Hi
>
> Please help review the change for JDK-8186142.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8186142
> Webrev: http://cr.openjdk.java.net/~sherman/8186142/webrev/
>
> Thanks,
> Sherman
>

RFR JDK-8186142: ZipPath.{starts,ends}With(nonZipPath) throws an exception, but should return false

[Xueming Shen]

Hi

Please help review the change for JDK-8186142.

Issue: https://bugs.openjdk.java.net/browse/JDK-8186142
Webrev: http://cr.openjdk.java.net/~sherman/8186142/webrev/

Thanks,
Sherman

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

[mandy chung]

On 8/23/17 4:02 PM, Jonathan Gibbons wrote:

Removed ArrayDeque from patch.
Updated webrev and API

Webrev: http://cr.openjdk.java.net/~jjg/8186684/webrev.01/index.html
API: http://cr.openjdk.java.net/~jjg/8186684/api.01/overview-summary.html


src/java.base/share/classes/java/lang/module/Configuration.java

- * resolution or resolution with service 
binding.

+ * resolution or resolution with
+ * service 
binding.


This link is still broken (should be 
java/lang/module/Configuration.html) Does javadoc detect it?


I also like the javadoc enhancement providing a way to reference a 
specified id other than a class member.


Other changes look okay.

Mandy

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

[Jonathan Gibbons]

Removed ArrayDeque from patch.
Updated webrev and API

Webrev: http://cr.openjdk.java.net/~jjg/8186684/webrev.01/index.html
API: http://cr.openjdk.java.net/~jjg/8186684/api.01/overview-summary.html

-- Jon

On 08/23/2017 03:29 PM, Martin Buchholz wrote:
Jon, please just drop ArrayDeque.  We'll fix it separately by renaming 
the private add method.


On Wed, Aug 23, 2017 at 3:17 PM, Jonathan Gibbons 
> wrote:



On 08/23/2017 03:12 PM, Martin Buchholz wrote:



On Wed, Aug 23, 2017 at 3:04 PM, Jonathan Gibbons
> wrote:


Although it is not immediately clear in the webrev, the
underlying characteristic of all places where I had to add an
empty arg list is that there was a private field of the same
name in scope.


I took a closer look at ArrayDeque.  I see no field named "add",
but I do see

 static final int add(int i, int distance, int modulus) {

which should probably be renamed anyways, (although overloading
on arity ought to be safe!  )

So add() would still have been ambiguous, since there are two
methods matching?


Yes, the error in question was reported as:

docs/api/java/util/ArrayDeque.html:715: id not found:
add-int-int-int-

indicating that "{@link #add}" had matched the method you noted. 
Although the method exists, it was not documented because it is

not a public or protected method: hence the broken link.  If we
had run javadoc with -package option, that link would have been
OK, although there would likely have been a gazillion other errors!

-- Jon

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

[Martin Buchholz]

On Wed, Aug 23, 2017 at 3:37 PM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:

> Martin,
>
> Understood.
>
> Do you want to file a followup JBS issue, or shall I?
>

It'll just arrive as part of the next jsr166 integration; train is already
en route.

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

[Jonathan Gibbons]

Martin,

Understood.

Do you want to file a followup JBS issue, or shall I?

-- Jon

On 08/23/2017 03:29 PM, Martin Buchholz wrote:
Jon, please just drop ArrayDeque.  We'll fix it separately by renaming 
the private add method.


On Wed, Aug 23, 2017 at 3:17 PM, Jonathan Gibbons 
> wrote:



On 08/23/2017 03:12 PM, Martin Buchholz wrote:



On Wed, Aug 23, 2017 at 3:04 PM, Jonathan Gibbons
> wrote:


Although it is not immediately clear in the webrev, the
underlying characteristic of all places where I had to add an
empty arg list is that there was a private field of the same
name in scope.


I took a closer look at ArrayDeque.  I see no field named "add",
but I do see

 static final int add(int i, int distance, int modulus) {

which should probably be renamed anyways, (although overloading
on arity ought to be safe!  )

So add() would still have been ambiguous, since there are two
methods matching?


Yes, the error in question was reported as:

docs/api/java/util/ArrayDeque.html:715: id not found:
add-int-int-int-

indicating that "{@link #add}" had matched the method you noted. 
Although the method exists, it was not documented because it is

not a public or protected method: hence the broken link.  If we
had run javadoc with -package option, that link would have been
OK, although there would likely have been a gazillion other errors!

-- Jon

Re: RFR: 8186500: StringConcatFactory.makeConcatWithConstants throws AssertionError when recipe contains non-String constants

[Claes Redestad]

On 2017-08-23 18:35, Aleksey Shipilev wrote:

Sure, mind if I defer that to a future RFE, though?:-)

Oh, c'mon, that should be a simple change:)  And it makes the patch (that we 
would have to backport
some day) more readable!


Ok then:

http://cr.openjdk.java.net/~redestad/8186500/jdk.04/

/Claes

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

[Martin Buchholz]

Jon, please just drop ArrayDeque.  We'll fix it separately by renaming the
private add method.

On Wed, Aug 23, 2017 at 3:17 PM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:

>
> On 08/23/2017 03:12 PM, Martin Buchholz wrote:
>
>
>
> On Wed, Aug 23, 2017 at 3:04 PM, Jonathan Gibbons <
> jonathan.gibb...@oracle.com> wrote:
>
>>
>> Although it is not immediately clear in the webrev, the underlying
>> characteristic of all places where I had to add an empty arg list is that
>> there was a private field of the same name in scope.
>>
>
> I took a closer look at ArrayDeque.  I see no field named "add", but I do
> see
>
>  static final int add(int i, int distance, int modulus) {
>
> which should probably be renamed anyways, (although overloading on arity
> ought to be safe!  )
>
> So add() would still have been ambiguous, since there are two methods
> matching?
>
>
> Yes, the error in question was reported as:
>
> docs/api/java/util/ArrayDeque.html:715: id not found: add-int-int-int-
>
> indicating that "{@link #add}" had matched the method you noted.  Although
> the method exists, it was not documented because it is not a public or
> protected method: hence the broken link.  If we had run javadoc with
> -package option, that link would have been OK, although there would likely
> have been a gazillion other errors!
>
> -- Jon
>

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

[Jonathan Gibbons]

On 08/23/2017 03:16 PM, Martin Buchholz wrote:



On Wed, Aug 23, 2017 at 3:04 PM, Jonathan Gibbons 
> wrote:



javadoc is at fault for not giving the warning, and if we fixed
the tool first, we would just get the warnings, and would still
have to fix the comments.


Yeah, but you get synergy - fixing the warnings gives you confidence 
that you've implemented the tool correctly, and using the tool gives 
you confidence you've fixed the code properly.


Understood, but as you've noted with ArrayQueue, there's enough synergy 
to go around when we start generating the warnings.  Right now, I'm 
getting synergy with the "link checker" in a new "doccheck" utility, 
coming soon to a CodeTools near you ;-)


-- Jon

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

[Jonathan Gibbons]

On 08/23/2017 03:12 PM, Martin Buchholz wrote:



On Wed, Aug 23, 2017 at 3:04 PM, Jonathan Gibbons 
> wrote:



Although it is not immediately clear in the webrev, the underlying
characteristic of all places where I had to add an empty arg list
is that there was a private field of the same name in scope.


I took a closer look at ArrayDeque.  I see no field named "add", but I 
do see


 static final int add(int i, int distance, int modulus) {

which should probably be renamed anyways, (although overloading on 
arity ought to be safe!  )


So add() would still have been ambiguous, since there are two methods 
matching?


Yes, the error in question was reported as:

docs/api/java/util/ArrayDeque.html:715: id not found: add-int-int-int-

indicating that "{@link #add}" had matched the method you noted. 
Although the method exists, it was not documented because it is not a 
public or protected method: hence the broken link.  If we had run 
javadoc with -package option, that link would have been OK, although 
there would likely have been a gazillion other errors!


-- Jon

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

[Martin Buchholz]

On Wed, Aug 23, 2017 at 3:04 PM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:

>
> javadoc is at fault for not giving the warning, and if we fixed the tool
> first, we would just get the warnings, and would still have to fix the
> comments.
>

Yeah, but you get synergy - fixing the warnings gives you confidence that
you've implemented the tool correctly, and using the tool gives you
confidence you've fixed the code properly.

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

[Martin Buchholz]

On Wed, Aug 23, 2017 at 3:04 PM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:

>
> Although it is not immediately clear in the webrev, the underlying
> characteristic of all places where I had to add an empty arg list is that
> there was a private field of the same name in scope.
>

I took a closer look at ArrayDeque.  I see no field named "add", but I do
see

 static final int add(int i, int distance, int modulus) {

which should probably be renamed anyways, (although overloading on arity
ought to be safe!  )

So add() would still have been ambiguous, since there are two methods
matching?

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

[Jonathan Gibbons]

Hi Martin,


On 08/23/2017 02:41 PM, Martin Buchholz wrote:

I would be inclined to "fix the tool first" if it's not too hard.


Both should be fixed. Going back in time, the spec has long said:
http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#specifyingname

   If any method or constructor is entered as a name with no
   parentheses, such as |getValue|, and if there is no field with the
   same name, the Javadoc tool will correctly create a link to it, but
   will print a warning message reminding you to add the parentheses
   and arguments. If this method is overloaded, the Javadoc tool will
   link to the first method its search encounters, which is unspecified.

So, the implication is that since forever, the doc comment should have 
used an arg list. I also note, with regret, that that text was lost from 
the latest version of the spec, and that needs to be fixed.


javadoc is at fault for not giving the warning, and if we fixed the tool 
first, we would just get the warnings, and would still have to fix the 
comments.
I note that javadoc specifies that the behavior is partially 
unspecified, which is another reason to fix the doc comments.
I think that there is an issue as to how the lookup should behave when a 
candidate is not being documented.  i.e. #parent when parent is a 
private field and a public method.  How does this interact with the 
-public and -private command line options?




---
Shouldn't the below have a proper arglist?

Consider instead
{@link #add(Object) add(E)}


Good catch/suggestion. Thanks.



Consider fixing the javadoc tool so that one can actually write {@link 
#add(E)}


Yeah, another enhancement.  Not today: this is just about fixing broken 
links.



--- old/src/java.base/share/classes/java/util/ArrayDeque.java   2017-08-23 
11:36:43.286955464 -0700
+++ new/src/java.base/share/classes/java/util/ArrayDeque.java   2017-08-23 
11:36:43.070945993 -0700
@@ -293,7 +293,7 @@
  /**
   * Inserts the specified element at the end of this deque.
   *
- * This method is equivalent to {@link #add}.
+ * This method is equivalent to {@link #add()}.
   *
   * @param e the element to add
   * @throws NullPointerException if the specified element is null
What about all the other ArrayDeque methods below:

./ArrayDeque.java:296: * This method is equivalent to {@link #add}.
./ArrayDeque.java:483: * This method is equivalent to {@link 
#addLast}.
./ArrayDeque.java:497: * This method is equivalent to {@link 
#offerLast}.
./ArrayDeque.java:513: * This method is equivalent to {@link 
#removeFirst}.
./ArrayDeque.java:527: * This method is equivalent to {@link 
#pollFirst}.
./ArrayDeque.java:541: * This method is equivalent to {@link 
#getFirst}.
./ArrayDeque.java:554: * This method is equivalent to {@link 
#peekFirst}.
./ArrayDeque.java:569: * This method is equivalent to {@link 
#addFirst}.
./ArrayDeque.java:582: * This method is equivalent to {@link 
#removeFirst()}.


I was specifically fixing broken links (see the list in the JBS issue), 
not doing a general cleanup of all references to methods that needed arg 
lists. That cleanup will need to happen when we fix the tool to generate 
the warnings it promises.


Although it is not immediately clear in the webrev, the underlying 
characteristic of all places where I had to add an empty arg list is 
that there was a private field of the same name in scope.


-- Jon

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

[Lance Andersen]

Hi Jon

The changes provided  look reasonable
> On Aug 23, 2017, at 5:15 PM, Jonathan Gibbons  
> wrote:
> 
> Please review a reasonably simple patch to fix most of the broken links in 
> the API docs for java.base module.
> All the fixes are in the small "typo" category, and so should not materially 
> affect the specification.
> 
> I've provided a copy of the API, in case folk want to test the updated links. 
>  The affected files are in the following packages:
> 
>   java.lang
>   java.lang.invoke
>   java.lang.module
>   java.net
>   java.nio.channels.spi
>   java.nio.file
>   java.nio.file.attribute
>   java.util
>   java.util.concurrent
>   java.util.jar
>   java.util.stream
>   java.util.zip
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8186684
> Webrev: http://cr.openjdk.java.net/~jjg/8186684/webrev.00/index.html
> API: http://cr.openjdk.java.net/~jjg/8186684/api.00/overview-summary.html
> 
> Here are some notes on the files that have been modified:
> 
> In many cases, the problem was a combination of a number of factors:
> 1. The doc comments did not use an arg list when {@link}ing to a method.
> 2. javadoc is supposed to give a warning when an arg list is omitted, but 
> does not
> 3. javadoc will sometimes choose to link to a private member, even when it is 
> not being
>documented, when better alternatives exist.  For example, javadoc will
>currently prefer to link {@link #parent}  to "private Object parent;" 
> instead of
>"public Object Parent();}
> javadoc needs to be fixed, but so too should the doc comments.
> 
> This applies to the following files:
> 
>   src/java.base/share/classes/java/lang/BootstrapMethodError.java
>   src/java.base/share/classes/java/lang/ModuleLayer.java
>   src/java.base/share/classes/java/lang/ProcessBuilder.java
>   src/java.base/share/classes/java/lang/invoke/MethodHandle.java
>   src/java.base/share/classes/java/lang/invoke/VarHandle.java
>   src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
>   src/java.base/share/classes/java/nio/file/FileSystems.java
>   src/java.base/share/classes/java/nio/file/attribute/AclEntry.java
>   src/java.base/share/classes/java/util/ArrayDeque.java
> 
> 
> In this file, in the absence of an explicit arg list, javadoc ended up linking
> #dropArgumentsToMatch to a private method with the right name.
> The fix is to specify the arg list.
> 
>   src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> 
> 
> There's another category of errors, related to the use of relative links in
>   The problem occurs when such links are used in text
> that may appear in different contexts. There are currently two scenarios
> in which this occurs.
> 1. In the "first sentence" of a description ... the first sentence may be
> copied to appear in summary tables in other pages.
> 2. In descriptions that will be copied into other pages using {@inheritDoc}.
> In both cases, the relative link may be OK when appearing in its original
> context, but may become broken when used in other contexts.
> javadoc has never claimed to "fix up" such constructs, although it
> would be a good Enhancement for it to do so, or to provide a way of
> achieving the same effect. The solution, for now, is to use a reference
> that will worth wherever the text is evaluated. Right now, the suggested form
> is   .
> It's clunky, but it works.
> 
> This applies to the following files:
> 
>   src/java.base/share/classes/java/lang/module/Configuration.java
>   src/java.base/share/classes/java/util/Collection.java
> 
> This file has an explicit @see to a private method.  The reference is deleted.
> 
>   src/java.base/share/classes/java/net/URLStreamHandler.java
> 
> An anchor is replaced. It used to exist, and somewhere along the line, it got 
> removed,
> causing broken links.
> 
>   
> src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java
>   src/java.base/share/classes/java/nio/channels/spi/AbstractSelector.java
> 
> 
> This file had a case-mismatch between the definition and reference of the 
> link.
> This was tolerated in HTML 4.01, but not allowed in HTML5.
> 
>   src/java.base/share/classes/java/util/Calendar.java
> 
> An explicit arg list has to be supplied for a constructor to prevent javadoc 
> from
> using a private/undocumented one. There were two to choose from ... a general
> one, and one that defaulted some args. I linked to the more general one.
> 
>   src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
> 
> 
> javadoc has vacillated in recent releases on the anchor name to use for a
> package's description. We've settled on "package.description". Some files
> needed to be fixed up.
> 
>   src/java.base/share/classes/java/util/jar/package-info.java
>   src/java.base/share/classes/java/util/zip/Deflater.java
>   src/java.base/share/classes/java/util/zip/Inflater.java
> 
> In this case, although the anchor name did not exist it was close to one
> 

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

[Brian Burkhalter]

The changes in these packages look good.

Brian

On Aug 23, 2017, at 2:15 PM, Jonathan Gibbons  
wrote:

>   java.nio.channels.spi
>   java.nio.file
>   java.nio.file.attribute

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

[Martin Buchholz]

I would be inclined to "fix the tool first" if it's not too hard.

---
Shouldn't the below have a proper arglist?

Consider instead
{@link #add(Object) add(E)}

Consider fixing the javadoc tool so that one can actually write {@link
#add(E)}

--- old/src/java.base/share/classes/java/util/ArrayDeque.java   2017-08-23
11:36:43.286955464 -0700
+++ new/src/java.base/share/classes/java/util/ArrayDeque.java   2017-08-23
11:36:43.070945993 -0700
@@ -293,7 +293,7 @@
 /**
  * Inserts the specified element at the end of this deque.
  *
- * This method is equivalent to {@link #add}.
+ * This method is equivalent to {@link #add()}.
  *
  * @param e the element to add
  * @throws NullPointerException if the specified element is null

What about all the other ArrayDeque methods below:

./ArrayDeque.java:296: * This method is equivalent to {@link #add}.
./ArrayDeque.java:483: * This method is equivalent to {@link
#addLast}.
./ArrayDeque.java:497: * This method is equivalent to {@link
#offerLast}.
./ArrayDeque.java:513: * This method is equivalent to {@link
#removeFirst}.
./ArrayDeque.java:527: * This method is equivalent to {@link
#pollFirst}.
./ArrayDeque.java:541: * This method is equivalent to {@link
#getFirst}.
./ArrayDeque.java:554: * This method is equivalent to {@link
#peekFirst}.
./ArrayDeque.java:569: * This method is equivalent to {@link
#addFirst}.
./ArrayDeque.java:582: * This method is equivalent to {@link
#removeFirst()}.

Re: RFR: JDK-8186684: Fix broken links in java.base API docs

[Xueming Shen]

   src/java.base/share/classes/java/util/jar/package-info.java
   src/java.base/share/classes/java/util/zip/Deflater.java
   src/java.base/share/classes/java/util/zip/Inflater.java

looks good.

On 8/23/17, 2:15 PM, Jonathan Gibbons wrote:
Please review a reasonably simple patch to fix most of the broken 
links in the API docs for java.base module.
All the fixes are in the small "typo" category, and so should not 
materially affect the specification.


I've provided a copy of the API, in case folk want to test the updated 
links.  The affected files are in the following packages:


   java.lang
   java.lang.invoke
   java.lang.module
   java.net
   java.nio.channels.spi
   java.nio.file
   java.nio.file.attribute
   java.util
   java.util.concurrent
   java.util.jar
   java.util.stream
   java.util.zip

JBS: https://bugs.openjdk.java.net/browse/JDK-8186684
Webrev: http://cr.openjdk.java.net/~jjg/8186684/webrev.00/index.html
API: http://cr.openjdk.java.net/~jjg/8186684/api.00/overview-summary.html

Here are some notes on the files that have been modified:

In many cases, the problem was a combination of a number of factors:
1. The doc comments did not use an arg list when {@link}ing to a method.
2. javadoc is supposed to give a warning when an arg list is omitted, 
but does not
3. javadoc will sometimes choose to link to a private member, even 
when it is not being
documented, when better alternatives exist.  For example, javadoc 
will
currently prefer to link {@link #parent}  to "private Object 
parent;" instead of

"public Object Parent();}
javadoc needs to be fixed, but so too should the doc comments.

This applies to the following files:

   src/java.base/share/classes/java/lang/BootstrapMethodError.java
   src/java.base/share/classes/java/lang/ModuleLayer.java
   src/java.base/share/classes/java/lang/ProcessBuilder.java
   src/java.base/share/classes/java/lang/invoke/MethodHandle.java
   src/java.base/share/classes/java/lang/invoke/VarHandle.java
   src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
   src/java.base/share/classes/java/nio/file/FileSystems.java
   src/java.base/share/classes/java/nio/file/attribute/AclEntry.java
   src/java.base/share/classes/java/util/ArrayDeque.java


In this file, in the absence of an explicit arg list, javadoc ended up 
linking

#dropArgumentsToMatch to a private method with the right name.
The fix is to specify the arg list.

   src/java.base/share/classes/java/lang/invoke/MethodHandles.java


There's another category of errors, related to the use of relative 
links in

  The problem occurs when such links are used in text
that may appear in different contexts. There are currently two scenarios
in which this occurs.
1. In the "first sentence" of a description ... the first sentence may be
copied to appear in summary tables in other pages.
2. In descriptions that will be copied into other pages using 
{@inheritDoc}.

In both cases, the relative link may be OK when appearing in its original
context, but may become broken when used in other contexts.
javadoc has never claimed to "fix up" such constructs, although it
would be a good Enhancement for it to do so, or to provide a way of
achieving the same effect. The solution, for now, is to use a reference
that will worth wherever the text is evaluated. Right now, the 
suggested form

is .
It's clunky, but it works.

This applies to the following files:

   src/java.base/share/classes/java/lang/module/Configuration.java
   src/java.base/share/classes/java/util/Collection.java

This file has an explicit @see to a private method.  The reference is 
deleted.


   src/java.base/share/classes/java/net/URLStreamHandler.java

An anchor is replaced. It used to exist, and somewhere along the line, 
it got removed,

causing broken links.

   
src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java
   
src/java.base/share/classes/java/nio/channels/spi/AbstractSelector.java



This file had a case-mismatch between the definition and reference of 
the link.

This was tolerated in HTML 4.01, but not allowed in HTML5.

   src/java.base/share/classes/java/util/Calendar.java

An explicit arg list has to be supplied for a constructor to prevent 
javadoc from
using a private/undocumented one. There were two to choose from ... a 
general

one, and one that defaulted some args. I linked to the more general one.

   
src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java



javadoc has vacillated in recent releases on the anchor name to use for a
package's description. We've settled on "package.description". Some files
needed to be fixed up.

   src/java.base/share/classes/java/util/jar/package-info.java
   src/java.base/share/classes/java/util/zip/Deflater.java
   src/java.base/share/classes/java/util/zip/Inflater.java

In this case, although the anchor name did not exist it was close to one
that did, suggesting a typo, but the text of the link suggested a 

Re: Manifest Add-Exports vs. command line --add-exports

[Tom Hood]

On Wed, Aug 23, 2017 at 6:36 AM, Alan Bateman 
wrote:

> On 22/08/2017 01:49, Tom Hood wrote:
>
>> Thanks, Mandy.  I was beginning to think my followup question might have
>> gotten lost and I was considering a new post.
>>
>> I'm unable to get --illegal-access=permits to work for our webstart app by
>> setting it in the Java Control Panel with the 9+181 build.  It appears
>> webstart crashes when I do this.  I tried enabling tracing & logging from
>> the Java Control Panel "Advanced" tab, but couldn't find anything left
>> behind.
>>
> The value is "permit" (not "permits"). Just mentioning in case this is a
> simple typo here. Also it would be good to confirm that that "crashes"
> means it aborts with an error message rather than a hard crash.
>

Thanks.  It was just the typo you pointed out.

I attempted to launch our app from firefox and didn't get any feedback with
the typo there.  I didn't try running javaws from the command line.  Maybe
it outputs something informative in that case.


>
>
>> Setting a long list of --add-exports in the Java Control Panel *does* work
>> for our webstart app with the 9+181 build.  However, I don't believe this
>> is going to work for our customer who has 1000's of geographically
>> distributed users.  We have next to zero control over how/when system
>> administrators perform the java installations.  Likewise, asking all those
>> users to manually add the options themselves is too much to ask of them.
>> I
>> predict many complaints and calls to our help desk that our app doesn't
>> work with Java 9.
>>
>> Any chance of adding a more webstart-friendly "JEP260 last resort" for
>> Java
>> 9 ?  Our vendors need more time to remove dependencies from their
>> libraries.  I'm concerned that as we proceed in testing our app with Java
>> 9
>> that the list of JEP260-override options will grow.  For example, the
>> --add-opens was added due to an illegal setAccessible(true) reflection
>> call.
>>
> The CLI options to export or open packages can be specified in JNLP file,
> you shouldn't need to ask user to add them via the control panel. You can
> predicate on the Java SE version too, i.e.
>   
>

The issue is the limit on the *number* of args we can have in the
java-vm-args.  If you exceed the limit, the webstart app fails to launch
and displays a popup window with the text "too many args to run".

We need so many --add-exports and --add-opens that it's possible we won't
be able to fit them all in there.  At the moment, we are just under the
limit and I'm hoping further testing of our app doesn't push us over the
edge by revealing more --add-opens, for example.

I can't shrink the list of args by using --illegal-access=permit, because
that is disallowed in the jnlp.  I think I saw some correspondence from you
indicating you intentionally wanted the jnlp to explicitly list what was
needed.  Unfortunately, that won't work if you have too many to list.

Any chance you could change Java 9 to allow --illegal-access=permit in the
jnlp or alternatively increase the number of args allowed?


>
> Have you submitted bugs to the JAI project about its usages of sun.* APIs?
>


-Alan
>

No I haven't and I'm not sure how, although I didn't try to find a link to
submit bugs to it.

I'm getting the impression the JAI plugin for ImageIO was taken over by
https://github.com/jai-imageio/jai-imageio-core.  I was about to give that
one a try instead of the one I got from Oracle:  http://www.oracle.com/
technetwork/java/javasebusiness/downloads/java-
archive-downloads-java-client-419417.html

If you know I'm headed in the wrong direction with that, please let me know.

Thanks,
-- Tom

RFR: JDK-8186684: Fix broken links in java.base API docs

[Jonathan Gibbons]

Please review a reasonably simple patch to fix most of the broken links 
in the API docs for java.base module.
All the fixes are in the small "typo" category, and so should not 
materially affect the specification.


I've provided a copy of the API, in case folk want to test the updated 
links.  The affected files are in the following packages:


   java.lang
   java.lang.invoke
   java.lang.module
   java.net
   java.nio.channels.spi
   java.nio.file
   java.nio.file.attribute
   java.util
   java.util.concurrent
   java.util.jar
   java.util.stream
   java.util.zip

JBS: https://bugs.openjdk.java.net/browse/JDK-8186684
Webrev: http://cr.openjdk.java.net/~jjg/8186684/webrev.00/index.html
API: http://cr.openjdk.java.net/~jjg/8186684/api.00/overview-summary.html

Here are some notes on the files that have been modified:

In many cases, the problem was a combination of a number of factors:
1. The doc comments did not use an arg list when {@link}ing to a method.
2. javadoc is supposed to give a warning when an arg list is omitted, 
but does not
3. javadoc will sometimes choose to link to a private member, even when 
it is not being

documented, when better alternatives exist.  For example, javadoc will
currently prefer to link {@link #parent}  to "private Object 
parent;" instead of

"public Object Parent();}
javadoc needs to be fixed, but so too should the doc comments.

This applies to the following files:

   src/java.base/share/classes/java/lang/BootstrapMethodError.java
   src/java.base/share/classes/java/lang/ModuleLayer.java
   src/java.base/share/classes/java/lang/ProcessBuilder.java
   src/java.base/share/classes/java/lang/invoke/MethodHandle.java
   src/java.base/share/classes/java/lang/invoke/VarHandle.java
   src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
   src/java.base/share/classes/java/nio/file/FileSystems.java
   src/java.base/share/classes/java/nio/file/attribute/AclEntry.java
   src/java.base/share/classes/java/util/ArrayDeque.java


In this file, in the absence of an explicit arg list, javadoc ended up 
linking

#dropArgumentsToMatch to a private method with the right name.
The fix is to specify the arg list.

   src/java.base/share/classes/java/lang/invoke/MethodHandles.java


There's another category of errors, related to the use of relative links in
  The problem occurs when such links are used in text
that may appear in different contexts. There are currently two scenarios
in which this occurs.
1. In the "first sentence" of a description ... the first sentence may be
copied to appear in summary tables in other pages.
2. In descriptions that will be copied into other pages using {@inheritDoc}.
In both cases, the relative link may be OK when appearing in its original
context, but may become broken when used in other contexts.
javadoc has never claimed to "fix up" such constructs, although it
would be a good Enhancement for it to do so, or to provide a way of
achieving the same effect. The solution, for now, is to use a reference
that will worth wherever the text is evaluated. Right now, the suggested 
form

is   .
It's clunky, but it works.

This applies to the following files:

   src/java.base/share/classes/java/lang/module/Configuration.java
   src/java.base/share/classes/java/util/Collection.java

This file has an explicit @see to a private method.  The reference is 
deleted.


   src/java.base/share/classes/java/net/URLStreamHandler.java

An anchor is replaced. It used to exist, and somewhere along the line, 
it got removed,

causing broken links.

   
src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java
   src/java.base/share/classes/java/nio/channels/spi/AbstractSelector.java


This file had a case-mismatch between the definition and reference of 
the link.

This was tolerated in HTML 4.01, but not allowed in HTML5.

   src/java.base/share/classes/java/util/Calendar.java

An explicit arg list has to be supplied for a constructor to prevent 
javadoc from
using a private/undocumented one. There were two to choose from ... a 
general

one, and one that defaulted some args. I linked to the more general one.

   src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java


javadoc has vacillated in recent releases on the anchor name to use for a
package's description. We've settled on "package.description". Some files
needed to be fixed up.

   src/java.base/share/classes/java/util/jar/package-info.java
   src/java.base/share/classes/java/util/zip/Deflater.java
   src/java.base/share/classes/java/util/zip/Inflater.java

In this case, although the anchor name did not exist it was close to one
that did, suggesting a typo, but the text of the link suggested a different
anchor. Paul recommened the choice here:

   src/java.base/share/classes/java/util/stream/package-info.java

Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be exited by java

[Adam Farley8]

Hi Thomas,

First, thank you for your time. :)

The exit hook you recommend sounds like a fine workaround, though I 
suggest a return code would make a better long term solution.

Especially if the exit hook might be broken. :)

I don't think we can expect new JNI users to be familiar with the exit 
hook, and having Java designed to use the nuclear option (exit(0)) for a 
mere help option seems like overkill.

>From what you're saying, I think you're agreeing that it's better to pass 
a negative return code than call exit(#) and catch it, so that the VM can 
shut down "cleanly" instead of being suddenly terminated by a random chunk 
of internal c code.

Does this sound correct?

Best Regards

Adam Farley

P.S I should note that, if we agree to go ahead with the negative return 
code, we'll need to modify java.c to ignore it. IMO: Help options should 
only return negative return codes to JNI callers, not java executable 
users.




From:   Thomas Stüfe 
To: Adam Farley8 
Cc: Java Core Libs 
Date:   23/08/2017 18:45
Subject:Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM 
can be exited by java



Hi Adam,

would the JNI exit hook not solve your problem (JavaVMOption "exit")? One 
could use it to intercept any exit(2) calls.

However, I am not sure it always fires, and if it does not, whether this 
should be considered a bug. The official JNI documentation is pretty 
sparse (
http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html
). 

Another thing, even if one catches ::exit(), if the VM creation failed the 
process can be in an undefined state, because I am not sure we clean up 
orderly for every error exit. So, e.g., signal handlers may still be 
installed etc.

Kind Regards, Thomas 




On Wed, Aug 23, 2017 at 5:54 PM, Adam Farley8  
wrote:
Hi All,

Problem: Several of Java's "c" files call exit(0) if you pass certain
command-line options to JNI_CreateJavaVM, which can terminate the C++ code
JNI users use to initialise the JVM.

Example: If you write some C++ code that calls JNI_CreateJavaVM, and uses
the option "-agentlib:jdwp=help", Java's c files will print the needed
help output and call exit(0).

Result: Your C++ code is terminated on this line, and a return code of 0
is produced.

Issues:

Issue 1: The exit(0) prevents your code from doing anything useful after
the JNI_CreateJavaVM call.
Issue 2: The exit(0) indicates to anything monitoring your C++ code that
your code exited normally, even though it was terminated mid-way-through.
Issue 3: This return code is useless to us, as a 0 can indicate the VM
started correctly, or it can indicate the VM was terminated due to one or
more of these command-line options.
Issue 4: Of the other JNI return values (JNI_OK, JNI_ERR, etc) none of
them appear to cover this scenario.


Proposed solutions:

PS1: We should amend the JNI specification to include a "JNI_SILENT_EXIT"
return code, so the C++ code knows a VM was not created, but that it isn't
an error.
PS2: We should identify a list of the command-line options that produce
this behaviour via the JNI. (not all of the "help" options are recognised
by the JNI interface. E.g. -version and -help produce a JNI_ERR and an
"Option not recognised" message)
PS3: We should replace these annoying exit(0) calls with code that returns
"JNI_SILENT_EXIT", so the C++ code has a chance to finish.


Best Regards

Adam Farley
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be exited by java

[Thomas Stüfe]

Hi Adam,

would the JNI exit hook not solve your problem (JavaVMOption "exit")? One
could use it to intercept any exit(2) calls.

However, I am not sure it always fires, and if it does not, whether this
should be considered a bug. The official JNI documentation is pretty sparse
(
http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html
).

Another thing, even if one catches ::exit(), if the VM creation failed the
process can be in an undefined state, because I am not sure we clean up
orderly for every error exit. So, e.g., signal handlers may still be
installed etc.

Kind Regards, Thomas




On Wed, Aug 23, 2017 at 5:54 PM, Adam Farley8 
wrote:

> Hi All,
>
> Problem: Several of Java's "c" files call exit(0) if you pass certain
> command-line options to JNI_CreateJavaVM, which can terminate the C++ code
> JNI users use to initialise the JVM.
>
> Example: If you write some C++ code that calls JNI_CreateJavaVM, and uses
> the option "-agentlib:jdwp=help", Java's c files will print the needed
> help output and call exit(0).
>
> Result: Your C++ code is terminated on this line, and a return code of 0
> is produced.
>
> Issues:
>
> Issue 1: The exit(0) prevents your code from doing anything useful after
> the JNI_CreateJavaVM call.
> Issue 2: The exit(0) indicates to anything monitoring your C++ code that
> your code exited normally, even though it was terminated mid-way-through.
> Issue 3: This return code is useless to us, as a 0 can indicate the VM
> started correctly, or it can indicate the VM was terminated due to one or
> more of these command-line options.
> Issue 4: Of the other JNI return values (JNI_OK, JNI_ERR, etc) none of
> them appear to cover this scenario.
>
>
> Proposed solutions:
>
> PS1: We should amend the JNI specification to include a "JNI_SILENT_EXIT"
> return code, so the C++ code knows a VM was not created, but that it isn't
> an error.
> PS2: We should identify a list of the command-line options that produce
> this behaviour via the JNI. (not all of the "help" options are recognised
> by the JNI interface. E.g. -version and -help produce a JNI_ERR and an
> "Option not recognised" message)
> PS3: We should replace these annoying exit(0) calls with code that returns
> "JNI_SILENT_EXIT", so the C++ code has a chance to finish.
>
>
> Best Regards
>
> Adam Farley
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>

Re: RFR: 8186500: StringConcatFactory.makeConcatWithConstants throws AssertionError when recipe contains non-String constants

[Aleksey Shipilev]

On 08/23/2017 06:31 PM, Claes Redestad wrote:
> 
> 
> On 08/23/2017 06:31 PM, Aleksey Shipilev wrote:
>> On 08/23/2017 06:26 PM, Claes Redestad wrote:
>>> On 08/23/2017 06:08 PM, Aleksey Shipilev wrote:
332 Object value = Objects.requireNonNull(cnst);
333 if (!value.getClass().isPrimitive()) {
334 this.value = String.valueOf(cnst);
335 } else {
336 this.value = value;
337 }

 ...so that value is always String after this?
>>> Right. Which works, and I'm not sure we really lose much this way. Nothing 
>>> on the
>>> code generated by javac, only theoretical performance points on other code. 
>>> Keep
>>> it simple for now and just do String.valueOf in RecipeElement always?
>> Yes, and I'd probably cascade this through the code: make 
>> RecipeElement.value String-typed, make
>> RecipeElement.getValue() return String, remove all excess String 
>> conversions, voila? This also makes
>> the code simpler to understand.
> 
> Sure, mind if I defer that to a future RFE, though? :-)

Oh, c'mon, that should be a simple change :) And it makes the patch (that we 
would have to backport
some day) more readable!

-Aleksey

Re: RFR: 8186500: StringConcatFactory.makeConcatWithConstants throws AssertionError when recipe contains non-String constants

[Claes Redestad]

On 08/23/2017 06:31 PM, Aleksey Shipilev wrote:

On 08/23/2017 06:26 PM, Claes Redestad wrote:

On 08/23/2017 06:08 PM, Aleksey Shipilev wrote:

   332 Object value = Objects.requireNonNull(cnst);
   333 if (!value.getClass().isPrimitive()) {
   334 this.value = String.valueOf(cnst);
   335 } else {
   336 this.value = value;
   337 }

...so that value is always String after this?

Right. Which works, and I'm not sure we really lose much this way. Nothing on 
the
code generated by javac, only theoretical performance points on other code. Keep
it simple for now and just do String.valueOf in RecipeElement always?

Yes, and I'd probably cascade this through the code: make RecipeElement.value 
String-typed, make
RecipeElement.getValue() return String, remove all excess String conversions, 
voila? This also makes
the code simpler to understand.


Sure, mind if I defer that to a future RFE, though? :-)

/Claes

Re: RFR: 8186500: StringConcatFactory.makeConcatWithConstants throws AssertionError when recipe contains non-String constants

[Aleksey Shipilev]

On 08/23/2017 06:26 PM, Claes Redestad wrote:
> On 08/23/2017 06:08 PM, Aleksey Shipilev wrote:
>>   332 Object value = Objects.requireNonNull(cnst);
>>   333 if (!value.getClass().isPrimitive()) {
>>   334 this.value = String.valueOf(cnst);
>>   335 } else {
>>   336 this.value = value;
>>   337 }
>>
>> ...so that value is always String after this?
> 
> Right. Which works, and I'm not sure we really lose much this way. Nothing on 
> the
> code generated by javac, only theoretical performance points on other code. 
> Keep
> it simple for now and just do String.valueOf in RecipeElement always?

Yes, and I'd probably cascade this through the code: make RecipeElement.value 
String-typed, make
RecipeElement.getValue() return String, remove all excess String conversions, 
voila? This also makes
the code simpler to understand.

Thanks,
-Aleksey

Re: RFR: 8186500: StringConcatFactory.makeConcatWithConstants throws AssertionError when recipe contains non-String constants

[Claes Redestad]

On 08/23/2017 06:08 PM, Aleksey Shipilev wrote:

On 08/23/2017 01:52 PM, Claes Redestad wrote:

What I wasn't sure about is *when* the String.valueOf should happen, but as
makeConcatWithConstants specify "If necessary, the factory would call toString 
to
perform a one-time String conversion" then I think we could (should?) do this at
our earliest convenience, which might even be in the RecipeElement construction:

Yes, I don't see why not.


http://cr.openjdk.java.net/~redestad/8186500/jdk.02/

Hm!

  *) Seems that due to cnst being an (autoboxed) reference, isPrimitive is 
always false on this path?


Ouch...


  332 Object value = Objects.requireNonNull(cnst);
  333 if (!value.getClass().isPrimitive()) {
  334 this.value = String.valueOf(cnst);
  335 } else {
  336 this.value = value;
  337 }

...so that value is always String after this?


Right. Which works, and I'm not sure we really lose much this way. 
Nothing on the
code generated by javac, only theoretical performance points on other 
code. Keep

it simple for now and just do String.valueOf in RecipeElement always?


...and that avoids String conversion on RecipeElement.getValue() paths 
completely?


We could still do String.valueOf on the other end to make sure (as this
is a no-op on Strings):

http://cr.openjdk.java.net/~redestad/8186500/jdk.03

Thanks!

/Claes

Re: RFR 8173715: Remove Flat Profiler

[Gerard Ziemski]

Thank you David.

Do I need a second reviewer here?


cheers
 
> On Aug 22, 2017, at 9:15 PM, David Holmes  wrote:
> 
> Hi Gerard,
> 
> On 23/08/2017 3:41 AM, Gerard Ziemski wrote:
>> hi all,
>> The FlatProfiler (i.e. -Xprof) has been deprecated in jdk9, and now it’s the 
>> time to remove the code and obsolete the -Xprof flag.
>> issue:  https://bugs.openjdk.java.net/browse/JDK-8173715
>> webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev2_jdk/
> 
> These changes seem okay to me - though I believe the man page files are 
> slated for removal anyway.
> 
> Thanks,
> David

Re: RFR: 8186500: StringConcatFactory.makeConcatWithConstants throws AssertionError when recipe contains non-String constants

[Aleksey Shipilev]

On 08/23/2017 01:52 PM, Claes Redestad wrote:
> What I wasn't sure about is *when* the String.valueOf should happen, but as
> makeConcatWithConstants specify "If necessary, the factory would call 
> toString to
> perform a one-time String conversion" then I think we could (should?) do this 
> at
> our earliest convenience, which might even be in the RecipeElement 
> construction:

Yes, I don't see why not.

> http://cr.openjdk.java.net/~redestad/8186500/jdk.02/

Hm!

 *) Seems that due to cnst being an (autoboxed) reference, isPrimitive is 
always false on this path?

 332 Object value = Objects.requireNonNull(cnst);
 333 if (!value.getClass().isPrimitive()) {
 334 this.value = String.valueOf(cnst);
 335 } else {
 336 this.value = value;
 337 }

...so that value is always String after this?
...and that avoids String conversion on RecipeElement.getValue() paths 
completely?

 *) If not, these are replaceable with String.valueOf:

 937 String s = (cnst != null) ? cnst.toString() : 
"null";
...
 998 String s = (cnst != null) ? cnst.toString() : 
"null";


> Reworked the test to be easier to add constant types. Null constants are 
> specified
> to throw NPE, so the test now checks that (this might be a needlessly strict 
> thing
> to specify, but changing the method specification is out of scope here, I 
> think).

Ah, good! I was not completely reckless with "null" checking after all!

Thanks,
-Aleksey

[BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be exited by java

[Adam Farley8]

Hi All,

Problem: Several of Java's "c" files call exit(0) if you pass certain 
command-line options to JNI_CreateJavaVM, which can terminate the C++ code 
JNI users use to initialise the JVM.

Example: If you write some C++ code that calls JNI_CreateJavaVM, and uses 
the option "-agentlib:jdwp=help", Java's c files will print the needed 
help output and call exit(0).

Result: Your C++ code is terminated on this line, and a return code of 0 
is produced.

Issues:

Issue 1: The exit(0) prevents your code from doing anything useful after 
the JNI_CreateJavaVM call.
Issue 2: The exit(0) indicates to anything monitoring your C++ code that 
your code exited normally, even though it was terminated mid-way-through.
Issue 3: This return code is useless to us, as a 0 can indicate the VM 
started correctly, or it can indicate the VM was terminated due to one or 
more of these command-line options.
Issue 4: Of the other JNI return values (JNI_OK, JNI_ERR, etc) none of 
them appear to cover this scenario.


Proposed solutions: 

PS1: We should amend the JNI specification to include a "JNI_SILENT_EXIT" 
return code, so the C++ code knows a VM was not created, but that it isn't 
an error.
PS2: We should identify a list of the command-line options that produce 
this behaviour via the JNI. (not all of the "help" options are recognised 
by the JNI interface. E.g. -version and -help produce a JNI_ERR and an 
"Option not recognised" message)
PS3: We should replace these annoying exit(0) calls with code that returns 
"JNI_SILENT_EXIT", so the C++ code has a chance to finish.


Best Regards

Adam Farley
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: Manifest Add-Exports vs. command line --add-exports

[mandy chung]

On 8/23/17 6:36 AM, Alan Bateman wrote:

On 22/08/2017 01:49, Tom Hood wrote:

Thanks, Mandy.  I was beginning to think my followup question might have
gotten lost and I was considering a new post.

I'm unable to get --illegal-access=permits to work for our webstart 
app by

setting it in the Java Control Panel with the 9+181 build.  It appears
webstart crashes when I do this.  I tried enabling tracing & logging 
from

the Java Control Panel "Advanced" tab, but couldn't find anything left
behind.
The value is "permit" (not "permits"). Just mentioning in case this is 
a simple typo here. Also it would be good to confirm that that 
"crashes" means it aborts with an error message rather than a hard crash.




Thanks for catching the typo.

Mandy

Re: Manifest Add-Exports vs. command line --add-exports

[Alan Bateman]

On 22/08/2017 01:49, Tom Hood wrote:

Thanks, Mandy.  I was beginning to think my followup question might have
gotten lost and I was considering a new post.

I'm unable to get --illegal-access=permits to work for our webstart app by
setting it in the Java Control Panel with the 9+181 build.  It appears
webstart crashes when I do this.  I tried enabling tracing & logging from
the Java Control Panel "Advanced" tab, but couldn't find anything left
behind.
The value is "permit" (not "permits"). Just mentioning in case this is a 
simple typo here. Also it would be good to confirm that that "crashes" 
means it aborts with an error message rather than a hard crash.




Setting a long list of --add-exports in the Java Control Panel *does* work
for our webstart app with the 9+181 build.  However, I don't believe this
is going to work for our customer who has 1000's of geographically
distributed users.  We have next to zero control over how/when system
administrators perform the java installations.  Likewise, asking all those
users to manually add the options themselves is too much to ask of them.  I
predict many complaints and calls to our help desk that our app doesn't
work with Java 9.

Any chance of adding a more webstart-friendly "JEP260 last resort" for Java
9 ?  Our vendors need more time to remove dependencies from their
libraries.  I'm concerned that as we proceed in testing our app with Java 9
that the list of JEP260-override options will grow.  For example, the
--add-opens was added due to an illegal setAccessible(true) reflection call.
The CLI options to export or open packages can be specified in JNLP 
file, you shouldn't need to ask user to add them via the control panel. 
You can predicate on the Java SE version too, i.e.

  

Have you submitted bugs to the JAI project about its usages of sun.* APIs?

-Alan

Re: RFR: 8186500: StringConcatFactory.makeConcatWithConstants throws AssertionError when recipe contains non-String constants

[Claes Redestad]

Right,

the Wrapper.* code appears to work fine, but makeConcatWithConstants has
pre-existing issues with non-primitive, non-String constants.

What I wasn't sure about is *when* the String.valueOf should happen, but as
makeConcatWithConstants specify "If necessary, the factory would call 
toString to
perform a one-time String conversion" then I think we could (should?) do 
this at
our earliest convenience, which might even be in the RecipeElement 
construction:


http://cr.openjdk.java.net/~redestad/8186500/jdk.02/

Reworked the test to be easier to add constant types. Null constants are 
specified
to throw NPE, so the test now checks that (this might be a needlessly 
strict thing
to specify, but changing the method specification is out of scope here, 
I think).


WDYT?

/Claes

On 08/22/2017 08:49 PM, Aleksey Shipilev wrote:

On 08/22/2017 07:10 PM, Claes Redestad wrote:

On 2017-08-22 18:34, Aleksey Shipilev wrote:

http://cr.openjdk.java.net/~redestad/8186500/jdk.01/

Still think testing for {null, Class, MethodHandle, MethodType} would cover 
more interesting corner
cases.

Do you mean as constant arguments? And what should happen in each of these 
cases?

As Remi says, should be equivalent to String.valueOf().

null: should be converted to "null"
{Class, MH, MT}: should be equivalent to Class::toString

My concern is that we have to check the new code, e.g. Wrapper.* does not barf 
when we pass
something non-primitive, non-String there.

Thanks,
-Aleksey