Re: tutorial on using Cleaner-based finalization

[Peter Levart]

Hi Rick,

Allow me to join the discussion...

On 05/04/2017 04:21 AM, Rick Hillegas wrote:

Thanks, Roger. That is a helpful example.

Derby is a component which can be quiesced and unloaded on 
resource-constrained platforms, then re-loaded when resources free up. 
Unloading means garbage collecting all the classloaders created by the 
component so that, at the end, not a single scrap of Derby code 
remains loaded. Has the Cleaner pattern been tested under these kinds 
of conditions? Can you point me at a Cleaner-based library which 
successfully unloads and reloads itself without leaking classloaders?


Can you point me to a place in Derby code where you are currently using 
finalize() method for your purpose and I'll try to show you how to 
convert this to Cleaner API...


I'm surprised that you actually need finalize() in Derby. Isn't this 
pure Java code? Usually finalize() is needed in situations where there's 
some non-Java resource which has to be cleaned-up when all the 
references to some Java object that represents it are gone. I'm curious 
what you need to clean in a pure Java library.


Regards, Peter



Thanks,
-Rick


On 5/3/17 9:04 AM, Roger Riggs wrote:

Hi Rick,

The general nature of changes to use the Cleaner involve factoring 
out the cleanup
code from the object being cleaned, though in many cases it does not 
require restructuring.
For example, if an object holds a reference to a network socket that 
needs to be closed
when the object is collected the socket.close() can called by the 
cleaner:


   Cleaner cleaner = ...;
   final Socket socket = ...;
   Object obj = ...;

   cleaner.register(obj, () -> {
   try {
   socket.close();
} catch (IOException ioe) { // ignore}
   });


Creating a cleaner starts a thread that does the work so you'll want 
to decide

how to share it across the uses or to use than one.

Using lambdas for the cleaner functions is very lightweight but be 
careful to avoid
the using bound variables in the lambda body because they implicitly 
retain
a reference to the enclosing instance which will prevent the instance 
from becoming unreferences.


If there are more specific cases of interest let me know,

Regards, Roger


On 5/2/2017 10:08 PM, Rick Hillegas wrote:
When I compile Apache Derby using JDK 9 build 167, I see several 
instances of the following warning:


   warning: [deprecation] finalize() in Object has been deprecated

The javadoc for java.lang.Object.finalize() suggests that affected 
classes should migrate their finalization to a coding pattern based 
on the newly introduced java.lang.ref.Cleaner class. I am hesitant 
to try my hand at this without more guidance. Can you point me at a 
tutorial or list of best practices for implementing Cleaner-based 
finalization?


Thanks,
-Rick

Re: RFR: Update tables in java.base to be HTML5-friendly.

[Martin Buchholz]

Jonathan Gibbons for  "css style czar"!

---

I checked the tables at
http://cr.openjdk.java.net/~jjg/8179479-8179592/api/java/util/concurrent/BlockingDeque.html
They look perfectly fine, although I feel a twinge of
non-collapsed-border-nostalgia.

---

Yes, "striped" is a much better name than "altrows".  "striped-tables" as
you suggest may be better.  Choose your names carefully - we can't change
them in the future.

---

w3.org doc seems to suggest we should only be defining table styles with
borders.

https://www.w3.org/TR/html5/tabular-data.html#attr-table-border

"""Tables should not be used as layout aids. """

"""User agents, especially those that do table analysis on arbitrary
content, are encouraged to find heuristics to determine which tables
actually contain data and which are merely being used for layout. """

RFR 8178912, Throw away sample tests

[Felix Yang]

Hi there,

   please review following change to remove tests for several samples, 
which have been removed in "JEP 298: Remove Demos and Samples".


Webrev: http://cr.openjdk.java.net/~xiaofeya/8178912/webrev.00/

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

Corresponding JEP: https://bugs.openjdk.java.net/browse/JDK-8164813

Thanks,

Felix

Re: RFR 8179566: Add additional jaxws messages to be translated

[Leo Jiang]

===  Copy from David's email
That endorsed part is problem. It is valid in JDK-8 but not in 9. Following message is my proposed solution. It would 
fit JDK-8 and 9.
JAX-WS 2.1 API is loaded from {0}, But JAX-WS runtime requires JAX-WS 2.2 API. Use the standard override mechanism to 
load JAX-WS 2.2 API


Do you think that this solution is OK?
===

Thanks,
Leo


On 05/04/2017 05:14 AM, Mandy Chung wrote:



On May 3, 2017, at 1:35 PM, Alan Bateman  wrote:

On 03/05/2017 19:58, Lance Andersen wrote:


+
+runtime.modeler.addressing.responses.nosuchmethod = JAX-WS 2.1 API is loaded 
from {0}, But JAX-WS runtime requires JAX-WS 2.2 or newer API. \
+  Use the standard override mechanism to load JAX-WS 2.2 or newer API.
\ No newline at end of file


"Use the standard override mechanism". I wonder if this meant to say the "endorsed 
standards override mechanism". In any case, it feels like a message for when JAX-WS is running 
on an older release. Do you know if that is true?



Since this resource bundle is for JDK 9, it should say “upgradeable module 
path” instead. But is this message intended for older release and is it ever 
used for JDK 9?

Mandy

Re: tutorial on using Cleaner-based finalization

[Rick Hillegas]

Thanks, Roger. That is a helpful example.

Derby is a component which can be quiesced and unloaded on 
resource-constrained platforms, then re-loaded when resources free up. 
Unloading means garbage collecting all the classloaders created by the 
component so that, at the end, not a single scrap of Derby code remains 
loaded. Has the Cleaner pattern been tested under these kinds of 
conditions? Can you point me at a Cleaner-based library which 
successfully unloads and reloads itself without leaking classloaders?


Thanks,
-Rick


On 5/3/17 9:04 AM, Roger Riggs wrote:

Hi Rick,

The general nature of changes to use the Cleaner involve factoring out 
the cleanup
code from the object being cleaned, though in many cases it does not 
require restructuring.
For example, if an object holds a reference to a network socket that 
needs to be closed
when the object is collected the socket.close() can called by the 
cleaner:


   Cleaner cleaner = ...;
   final Socket socket = ...;
   Object obj = ...;

   cleaner.register(obj, () -> {
   try {
   socket.close();
} catch (IOException ioe) { // ignore}
   });


Creating a cleaner starts a thread that does the work so you'll want 
to decide

how to share it across the uses or to use than one.

Using lambdas for the cleaner functions is very lightweight but be 
careful to avoid
the using bound variables in the lambda body because they implicitly 
retain
a reference to the enclosing instance which will prevent the instance 
from becoming unreferences.


If there are more specific cases of interest let me know,

Regards, Roger


On 5/2/2017 10:08 PM, Rick Hillegas wrote:
When I compile Apache Derby using JDK 9 build 167, I see several 
instances of the following warning:


   warning: [deprecation] finalize() in Object has been deprecated

The javadoc for java.lang.Object.finalize() suggests that affected 
classes should migrate their finalization to a coding pattern based 
on the newly introduced java.lang.ref.Cleaner class. I am hesitant to 
try my hand at this without more guidance. Can you point me at a 
tutorial or list of best practices for implementing Cleaner-based 
finalization?


Thanks,
-Rick

Re: RFR: Update tables in java.base to be HTML5-friendly.

[Jonathan Gibbons]

With my javadoc-tool-developer hat on, I'd like to get out of the 
business of jdk-style-owner, or at least identify that as a distinct 
hat. :-)


Kumar has identified a problem with the styles as currently defined ... 
you cannot easily embed a table with a default style inside a table with 
an explicit style ... which suggests the need for a third named style 
for "no borders".  (And yes, we have nested tables in some places.).


Although we disagree with your comment "THIS IS JAVA" (no it's not, it's 
HTML and CSS) the point is noted. How about the following names, with 
appropriate comments to come in the style sheet:


1. 
it does what it says, but long term, I see this being 
deprecated in favor of other styles ... there are places where a style 
with no borders is in use now, but when you add in captions, some amount 
of bordering would be better.


2. 
simple collapsed borders around each cell

3. 
previously called altrows.

How about longer names, specific to tables, like "borderless-table", 
"plain-table", "striped-table"? That would make it easier to have named 
styles for other constructs, although we will need to keep a balance 
between a proliferation of named styles and too much inline style.


All of this would be so much better with sufficient definitions for all 
the styles used by javadoc to allow adventurous and creative folk to use 
modified stylesheets for their own API. But not this week.


By the way, I forgot to mention in my original email, there is a copy of 
the API docs showing the proposed changes, available here:


http://cr.openjdk.java.net/~jjg/8179479-8179592/api/java.base-summary.html

-- Jon




On 05/03/2017 05:46 PM, Martin Buchholz wrote:
Jon, I am happy for you to own the html5 style for the entire javadoc; 
consistency wins; my comments are only suggestions and I'm no html or 
css expert.


On Wed, May 3, 2017 at 5:03 PM, Jonathan Gibbons 
mailto:jonathan.gibb...@oracle.com>> wrote:




On 05/03/2017 04:39 PM, Martin Buchholz wrote:

Thanks, Jon.

For the Deque/Queue tables
- * 
+ * 
I expected that we would modify these to

which rendered alright and is compliant (although "border" is a
weird boolean) and makes the "border intent" clear to humans and
to browsers.

THIS IS JAVA, so I'd prefer more verbose meaningful names for
these style classes ... hmmm ... class="contrasting_rows" ?  To
me, "plain" is suggestive of no borders at all.

Can we have some guidance comments in stylesheet.css explaining
when to use the different classes?



Martin,

If you are specifically requesting that the tables in Deque/Queue
use "" then I will do as you request, but I note
that the "plain" style does more than just  `border="1"`. It
adjusts the caption font and the margins above and below the
table. Given that the JSR166 doc comments actually use the
 tag reasonably, the presentation with the non-default
font seemed "better".

That being said, prior to doing this work, I did some analysis on
the tables coming from doc comments.  There are about 484 
with 70 different variants of the opening  tag.  Therefore,
there was a secondary goal to simplify the many different visual
appearances created using inline styles.

How strongly do you feel about the names?  As I said at the end of
the email, I would like to do a more complete cleanup of javadoc
support for stylesheets in a subsequent release. This would
involve separating the stylesheet for the HTML generated by the
doclet from a stylesheet provided to accompany the doc comments,
and would clean up the name space and write a moderately formal
specification of the styles in those stylesheets.

I can put some comments in the default stylesheet for the time being.

-- Jon

jdk10/jdk10 is broken on 32-bit linux

[David Holmes]

With the latest changes in jdk10/jdk10 we are seeing failures of all 
jtreg agentvm mode tests on 32-bit linux binaries due to socket 
connection failures. And also some OSX failures.


This seems to be have been caused by:

8165437: Evaluate the use of gettimeofday in Networking code

http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/7cdde79d6a46

due to a truncation issue through using long instead of jlong.

I've notified net-dev and will file a P1 bug to either have this fixed 
or backed out.


David
-

Re: RFR: Update tables in java.base to be HTML5-friendly.

[Martin Buchholz]

Jon, I am happy for you to own the html5 style for the entire javadoc;
consistency wins; my comments are only suggestions and I'm no html or css
expert.

On Wed, May 3, 2017 at 5:03 PM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:

>
>
> On 05/03/2017 04:39 PM, Martin Buchholz wrote:
>
> Thanks, Jon.
>
> For the Deque/Queue tables
>
> - * 
> + * 
>
> I expected that we would modify these to
> 
> which rendered alright and is compliant (although "border" is a weird
> boolean) and makes the "border intent" clear to humans and to browsers.
>
> THIS IS JAVA, so I'd prefer more verbose meaningful names for these style
> classes ... hmmm ... class="contrasting_rows" ?  To me, "plain" is
> suggestive of no borders at all.
>
> Can we have some guidance comments in stylesheet.css explaining when to
> use the different classes?
>
>
> Martin,
>
> If you are specifically requesting that the tables in Deque/Queue use
> "" then I will do as you request, but I note that the
> "plain" style does more than just  `border="1"`. It adjusts the caption
> font and the margins above and below the table. Given that the JSR166 doc
> comments actually use the  tag reasonably, the presentation with
> the non-default font seemed "better".
>
> That being said, prior to doing this work, I did some analysis on the
> tables coming from doc comments.  There are about 484  with 70
> different variants of the opening  tag.  Therefore, there was a
> secondary goal to simplify the many different visual appearances created
> using inline styles.
>
> How strongly do you feel about the names?  As I said at the end of the
> email, I would like to do a more complete cleanup of javadoc support for
> stylesheets in a subsequent release. This would involve separating the
> stylesheet for the HTML generated by the doclet from a stylesheet provided
> to accompany the doc comments, and would clean up the name space and write
> a moderately formal specification of the styles in those stylesheets.
>
> I can put some comments in the default stylesheet for the time being.
>
> -- Jon
>

Re: RFR: Update tables in java.base to be HTML5-friendly.

[Jonathan Gibbons]

On 05/03/2017 04:39 PM, Martin Buchholz wrote:

Thanks, Jon.

For the Deque/Queue tables
- * 
+ * 
I expected that we would modify these to

which rendered alright and is compliant (although "border" is a weird 
boolean) and makes the "border intent" clear to humans and to browsers.


THIS IS JAVA, so I'd prefer more verbose meaningful names for these 
style classes ... hmmm ... class="contrasting_rows" ?  To me, "plain" 
is suggestive of no borders at all.


Can we have some guidance comments in stylesheet.css explaining when 
to use the different classes?




Martin,

If you are specifically requesting that the tables in Deque/Queue use 
"" then I will do as you request, but I note that the 
"plain" style does more than just  `border="1"`. It adjusts the caption 
font and the margins above and below the table. Given that the JSR166 
doc comments actually use the  tag reasonably, the presentation 
with the non-default font seemed "better".


That being said, prior to doing this work, I did some analysis on the 
tables coming from doc comments.  There are about 484  with 70 
different variants of the opening  tag.  Therefore, there was a 
secondary goal to simplify the many different visual appearances created 
using inline styles.


How strongly do you feel about the names?  As I said at the end of the 
email, I would like to do a more complete cleanup of javadoc support for 
stylesheets in a subsequent release. This would involve separating the 
stylesheet for the HTML generated by the doclet from a stylesheet 
provided to accompany the doc comments, and would clean up the name 
space and write a moderately formal specification of the styles in those 
stylesheets.


I can put some comments in the default stylesheet for the time being.

-- Jon

Re: RFR: Update tables in java.base to be HTML5-friendly.

[Martin Buchholz]

Thanks, Jon.

For the Deque/Queue tables

- * 
+ * 

I expected that we would modify these to

which rendered alright and is compliant (although "border" is a weird
boolean) and makes the "border intent" clear to humans and to browsers.

THIS IS JAVA, so I'd prefer more verbose meaningful names for these style
classes ... hmmm ... class="contrasting_rows" ?  To me, "plain" is
suggestive of no borders at all.

Can we have some guidance comments in stylesheet.css explaining when to use
the different classes?

Re: RFR: Update tables in java.base to be HTML5-friendly.

[Joseph D. Darcy]

Hi Jon,

The changes in the java.lang and java.math packages look fine.

Cheers,

-Joe

On 5/3/2017 3:06 PM, Jonathan Gibbons wrote:

This is a review request for two co-dependent fixes.

JDK-8179592: Update tables in java.base to be HTML 5-friendly.
JDK-8179479: Add new styles to enable HTML 5 tables

In doc comments, some of the HTML 4.01 attributes for tables are no 
longer available in HTML 5, and CSS should be used instead.
To this end, some updates have been made to the main/default 
stylesheet used by javadoc, to define two new CSS classes for tables.


The new classes are:

Just puts plain borders around each cell, with no background 
coloring.



Horizontal borders are not used between cells in the table body; 
instead, alternating backgrounds are used to help distinguish the 
separate rows.


In addition, there is still the default

No borders.

These styles are in the langtools webrev, here:
http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/

The changes to the doc comments in java.base are in the jdk webrev, here:
http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/

summary vs. 

   The ARIA recommendations are to use the summary attribute or 
 tag ... but the summary attribute is no longer allowed in 
HTML 5.  In general, the text that has been provided for a summary is 
not suitable for direct use as a caption. The temporary workaround is 
to use a caption that is not displayed. In time, the appropriate API 
owners should update the use of these undisplayed table captions, to 
modify the text of the caption and make the caption displayed (by 
removing style="display:none").


Doc comments were changed in files in the following packages:

java.io
java.lang
java.lang.invoke
java.lang.reflect
java.math
java.net
java.nio.channels
java.nio.charset
java.nio.file
java.nio.file.attribute
java.nio.file.spi
java.security
java.security.cert
java.text
java.time.chrono
java.time.format
java.time.temporal
java.util
java.util.concurrent
java.util.regex
java.util.spi
javax.net.ssl

The intent is that the only changes in this webrev are to the HTML 5 
markup. There should be no significant changes to the text in any doc 
comment.


The decision to add the styles to the default stylesheet at this late 
stage in the release is not taken lightly, and is seen as a temporary 
measure. JDK-8177283 is a wishlist enhancement for updates to javadoc 
support of stylesheets, which includes the desire to move JDK-specific 
styles to a JDK-specific stylesheet.


This review is primarily about continuing the ongoing effort to make 
our docs be HTML 5 compliant. I would prefer not to get into extended 
discussions about which style class to use for each table, and what 
the exact definition of the styleclasses should be at this time.  But 
appropriate review feedback is obviously welcome.


-- Jon

RFR: Update tables in java.base to be HTML5-friendly.

[Jonathan Gibbons]

This is a review request for two co-dependent fixes.

JDK-8179592: Update tables in java.base to be HTML 5-friendly.
JDK-8179479: Add new styles to enable HTML 5 tables

In doc comments, some of the HTML 4.01 attributes for tables are no 
longer available in HTML 5, and CSS should be used instead.
To this end, some updates have been made to the main/default stylesheet 
used by javadoc, to define two new CSS classes for tables.


The new classes are:

Just puts plain borders around each cell, with no background coloring.


Horizontal borders are not used between cells in the table body; 
instead, alternating backgrounds are used to help distinguish the 
separate rows.


In addition, there is still the default

No borders.

These styles are in the langtools webrev, here:
http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/

The changes to the doc comments in java.base are in the jdk webrev, here:
http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/

summary vs. 

   The ARIA recommendations are to use the summary attribute or 
 tag ... but the summary attribute is no longer allowed in HTML 
5.  In general, the text that has been provided for a summary is not 
suitable for direct use as a caption. The temporary workaround is to use 
a caption that is not displayed. In time, the appropriate API owners 
should update the use of these undisplayed table captions, to modify the 
text of the caption and make the caption displayed (by removing 
style="display:none").


Doc comments were changed in files in the following packages:

java.io
java.lang
java.lang.invoke
java.lang.reflect
java.math
java.net
java.nio.channels
java.nio.charset
java.nio.file
java.nio.file.attribute
java.nio.file.spi
java.security
java.security.cert
java.text
java.time.chrono
java.time.format
java.time.temporal
java.util
java.util.concurrent
java.util.regex
java.util.spi
javax.net.ssl

The intent is that the only changes in this webrev are to the HTML 5 
markup. There should be no significant changes to the text in any doc 
comment.


The decision to add the styles to the default stylesheet at this late 
stage in the release is not taken lightly, and is seen as a temporary 
measure. JDK-8177283 is a wishlist enhancement for updates to javadoc 
support of stylesheets, which includes the desire to move JDK-specific 
styles to a JDK-specific stylesheet.


This review is primarily about continuing the ongoing effort to make our 
docs be HTML 5 compliant. I would prefer not to get into extended 
discussions about which style class to use for each table, and what the 
exact definition of the styleclasses should be at this time.  But 
appropriate review feedback is obviously welcome.


-- Jon

RFR 8150681 Update JAR specification for multi-release jar files

[Paul Sandoz]

Hi,

Please review an update to the JAR “specification” (in the loose sense of the 
term):

- first, it has been moved from a closed repository into the idk repository 
(same shared location as the recently introduced serialisation specification) 
and converted to markdown:

  
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown/webrev/ 


(This also includes a new attribute Launcher-Agent-Class, a Jigsaw related 
change to better support Java agents.)

For comparison, the HTML version online is here:

  http://download.java.net/java/jdk9/docs/technotes/guides/jar/jar.html 


- second i have added sections on multi-release JAR files:

  
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown-with-mr-jar/webrev/
 


this is based against the first patch so the changes can be easily viewed.


I expect some further editing of this specification to add further links to 
module related stuff and tidy up existing links to tools etc.

Thanks,
Paul.

Re: RFR 8179566: Add additional jaxws messages to be translated

[Mandy Chung]

> On May 3, 2017, at 1:35 PM, Alan Bateman  wrote:
> 
> On 03/05/2017 19:58, Lance Andersen wrote:
> 
>> +
>> +runtime.modeler.addressing.responses.nosuchmethod = JAX-WS 2.1 API is 
>> loaded from {0}, But JAX-WS runtime requires JAX-WS 2.2 or newer API. \
>> +  Use the standard override mechanism to load JAX-WS 2.2 or newer API.
>> \ No newline at end of file
>> 
> "Use the standard override mechanism". I wonder if this meant to say the 
> "endorsed standards override mechanism". In any case, it feels like a message 
> for when JAX-WS is running on an older release. Do you know if that is true?
> 

Since this resource bundle is for JDK 9, it should say “upgradeable module 
path” instead. But is this message intended for older release and is it ever 
used for JDK 9?

Mandy

Re: RFR 8179566: Add additional jaxws messages to be translated

[Alan Bateman]

On 03/05/2017 19:58, Lance Andersen wrote:


+
+runtime.modeler.addressing.responses.nosuchmethod = JAX-WS 2.1 API is loaded 
from {0}, But JAX-WS runtime requires JAX-WS 2.2 or newer API. \
+  Use the standard override mechanism to load JAX-WS 2.2 or newer API.
\ No newline at end of file

"Use the standard override mechanism". I wonder if this meant to say the 
"endorsed standards override mechanism". In any case, it feels like a 
message for when JAX-WS is running on an older release. Do you know if 
that is true?


-Alan

RE: AppCDS in OpenJDK?

[Ramana, Deepak]

Thanks Jiangli

Regards,
Deepak

From: Jiangli Zhou [mailto:jiangli.z...@oracle.com]
Sent: Tuesday, May 02, 2017 5:50 PM
To: Ramana, Deepak
Cc: core-libs-dev@openjdk.java.net
Subject: Re: AppCDS in OpenJDK?

Hi Deepak,

In JDK 8u40, AppCDS is an experimental (i.e can not be used in production) 
feature and is not available in OpenJDK. Following is related info from release 
notes for 
8u40:

*  Application Class Data Sharing (AppCDS):
*  Application Class Data 
Sharing
 (AppCDS) extends CDS (see Class Data 
Sharing)
 to enable you to place classes from the standard extensions directories and 
the application class path in the shared archive. This is an experimental 
feature and not licensed for commercial use. See the -XX:+UseAppCDS option in 
the java launcher tool page.

Regards,

Jiangli

On May 1, 2017, at 12:16 PM, Ramana, Deepak 
mailto:deepak.ram...@anthem.com>> wrote:

Hello,

I am not sure if this is the right forum to ask this question. Apologies in 
advance, if this is not the correct place.

We want to use the AppCDS feature that is available in the commercial release 
of Java 8 update 40.

Is this feature available in OpenJDK? If so, can we use this in production for 
commercial use ?

Regards,
Deepak

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information or may otherwise be protected by law. Any
unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message and any attachment thereto.


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information or may otherwise be protected by law. Any
unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message and any attachment thereto.

RFR 8179566: Add additional jaxws messages to be translated

[Lance Andersen]

Hi all,

Please review the following resources properties file update for jaxws.  See 
https://bugs.openjdk.java.net/browse/JDK-8179566 
 for more info

Best
Lance

$ hg diff
diff -r 1c610f1b4097 
src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ 
b/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties
   Wed May 03 14:53:54 2017 -0400
@@ -0,0 +1,6 @@
+wrapperTask.needEndorsed=\
+You are running on JDK6 or newer which comes with JAX-WS {0} API, but this 
tool requires JAX-WS {1} or newer API. Use \
+the standard override mechanism. 
+
+runtime.modeler.addressing.responses.nosuchmethod = JAX-WS 2.1 API is loaded 
from {0}, But JAX-WS runtime requires JAX-WS 2.2 or newer API. \
+  Use the standard override mechanism to load JAX-WS 2.2 or newer API.
\ No newline at end of file
ljanders-mac:resources ljanders$ 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

[Bill Shannon]

Shouldn't the version information be in the manifest for the jar file containing
the classes, accessed via java.lang.Package?

Roman Grigoriadi wrote on 05/ 3/17 09:49 AM:
> Hi,
>
> you can find new web rev here:
> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/01/
> 
>
> Previous review comments are addressed. 
>
>> The change to version.properties reminds me to ask if there is anything in
>> the jaxws repo to indicate the version of the JAX-* components? It's often
>> difficult to determine what bits are in the JDK vs. the upstream project.
>
> Version as in our Maven project is 2.3.0-SNAPSHOT for JAX-WS at the time we
> are syncing. Subcomponents (SAAJ, JAXB mainly) are promoted, for example 
> in 
> jdk/jaxws/src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties
> There is:
> # for JDK integration - include version in source zip
> jaxb.jdk.version=2.3.0-b170412.1723
>
> We can add another version.properties file with versions of all JAX-*
> components. We may also change version from 2.3.0-SNAPSHOT to something unique
> like 2.3.0-bXX. before sync and put it to maven promoted repo.
>
> Roman
>
>
>> On 12 Mar 2017, at 16:14, Alan Bateman > > wrote:
>>
>>
>>
>> On 12/03/2017 14:39, Roman Grigoriadi wrote:
>>> Hi,
>>>
>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176508
>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/
>>> 
>>>
>> I skimmed the changes and have a few comments (I'm sure Lance or someone else
>> will do a more detailed review).
>>
>> In JAXBContext then "must be open to the java.xml.bind module" should be
>> "must be open to at least the java.xml.bind module" so as to cover the case
>> that the package is opened unconditionally or to java.xml.bind and other
>> modules. In addition, include "at least" makes it consistent with other
>> wording that we have agreed for other areas.
>>
>> In MailcapCommandMap then the following doesn't seem right for the class
>> description:
>>
>>  59  * (Where java.home is the value of the "java.home" System 
>> property
>>  60  * and conf is the directory named "conf" if it exists,
>>  61  * otherwise the directory named "lib"; the "conf" directory was
>>  62  * introduced in JDK 1.9.)
>>
>> It might be simpler to just have javadoc specify that it attepts to locate
>> the `mailcap` file in the Java run-time image and then add an @implNote with
>> the details as to where it looks for specific runtime releases.
>>
>> I see the new source file ModuleUtil is using java.util.StringTokenizer. It's
>> use in new code has been discouraged for many years and maybe this could
>> start out using String.split rather than the legacy class.
>>
>> The change to version.properties reminds me to ask if there is anything in
>> the jaxws repo to indicate the version of the JAX-* components? It's often
>> difficult to determine what bits are in the JDK vs. the upstream project.
>>
>> -Alan
>

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

[Roman Grigoriadi]

Hi,

you can find new web rev here:
http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/01/ 


Previous review comments are addressed. 

> The change to version.properties reminds me to ask if there is anything in 
> the jaxws repo to indicate the version of the JAX-* components? It's often 
> difficult to determine what bits are in the JDK vs. the upstream project.


Version as in our Maven project is 2.3.0-SNAPSHOT for JAX-WS at the time we are 
syncing. Subcomponents (SAAJ, JAXB mainly) are promoted, for example 
in 
jdk/jaxws/src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties
There is:
# for JDK integration - include version in source zip
jaxb.jdk.version=2.3.0-b170412.1723

We can add another version.properties file with versions of all JAX-* 
components. We may also change version from 2.3.0-SNAPSHOT to something unique 
like 2.3.0-bXX. before sync and put it to maven promoted repo.

Roman


> On 12 Mar 2017, at 16:14, Alan Bateman  wrote:
> 
> 
> 
> On 12/03/2017 14:39, Roman Grigoriadi wrote:
>> Hi,
>> 
>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176508
>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/
>> 
> I skimmed the changes and have a few comments (I'm sure Lance or someone else 
> will do a more detailed review).
> 
> In JAXBContext then "must be open to the java.xml.bind module" should be 
> "must be open to at least the java.xml.bind module" so as to cover the case 
> that the package is opened unconditionally or to java.xml.bind and other 
> modules. In addition, include "at least" makes it consistent with other 
> wording that we have agreed for other areas.
> 
> In MailcapCommandMap then the following doesn't seem right for the class 
> description:
> 
>  59  * (Where java.home is the value of the "java.home" System property
>  60  * and conf is the directory named "conf" if it exists,
>  61  * otherwise the directory named "lib"; the "conf" directory was
>  62  * introduced in JDK 1.9.)
> 
> It might be simpler to just have javadoc specify that it attepts to locate 
> the `mailcap` file in the Java run-time image and then add an @implNote with 
> the details as to where it looks for specific runtime releases.
> 
> I see the new source file ModuleUtil is using java.util.StringTokenizer. It's 
> use in new code has been discouraged for many years and maybe this could 
> start out using String.split rather than the legacy class.
> 
> The change to version.properties reminds me to ask if there is anything in 
> the jaxws repo to indicate the version of the JAX-* components? It's often 
> difficult to determine what bits are in the JDK vs. the upstream project.
> 
> -Alan

Re: RFR: 8078267 - Add test to verify that a module based JDBC driver via the service-provider loading mechanism

[Lance Andersen]

Hi Daniel,

Thank you for the info.  I do plan on adding some additional tests using these 
modules.I did run into some challenges with 
testng/jtreg/modules/TEST.properties that I am trying to sort out overall 
before I do that.  

Best
Lance
> On May 3, 2017, at 10:05 AM, Daniel Fuchs  wrote:
> 
> Hi Lance,
> 
> Are you planning to use these modules in other tests?
> I'm asking because you're using the @library tag to compile them.
> If you want to encapsulate a module inside a test (without resorting
> to @library) then you can do so with the following layout and
> following @build line:
> 
> /test//mytest/MyDriverTest.java
> /test//mytest/mymodule/module-info.java
> /test//mytest/mymodule/x/y/Z.java
> 
> @build mymodule/x.y.Z MyDriverTest
> 
> hope this helps,
> 
> -- daniel
> 
> On 03/05/2017 01:49, Lance Andersen wrote:
>> Hi Joe,
>> 
>>> On May 2, 2017, at 8:34 PM, huizhe wang  wrote:
>>> 
>>> Hi Lance,
>>> 
>>> In DriverManagerModuleTests,  at line 83, did you mean to assign the result 
>>> of DM::getDriver to d2 although an Exception is expected?
>> I must have accidentally deleted that  and never noticed it due to the 
>> SQLException being thrown.
>> 
>> I will add it prior to pushing.
>> 
>>> 
>>> Otherwise, the patch looks good to me.
>> 
>> Thank you
>> 
>> Best
>> Lance
>>> 
>>> Best,
>>> Joe
>>> 
>>> On 5/2/2017 11:33 AM, Lance Andersen wrote:
 Hi all,
 
 The above issue adds a  test  to verify that a module based JDBC driver 
 works via the service-provider loading mechanism.
 
 The webrev can be found at 
 http://cr.openjdk.java.net/~lancea/8078267/webrev.00/index.html 
 
 
 Best
 Lance
 
  
 
 Lance Andersen| 
 Principal Member of Technical Staff | +1.781.442.2037
 Oracle Java Engineering
 1 Network Drive
 Burlington, MA 01803
 lance.ander...@oracle.com 
 
 
 
>>> 
>> 
>> 
>>  
>> 
>> Lance Andersen| 
>> Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> lance.ander...@oracle.com 
>> 
>> 
>> 
> 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: tutorial on using Cleaner-based finalization

[Roger Riggs]

Hi Rick,

The general nature of changes to use the Cleaner involve factoring out 
the cleanup
code from the object being cleaned, though in many cases it does not 
require restructuring.
For example, if an object holds a reference to a network socket that 
needs to be closed

when the object is collected the socket.close() can called by the cleaner:

   Cleaner cleaner = ...;
   final Socket socket = ...;
   Object obj = ...;

   cleaner.register(obj, () -> {
   try {
   socket.close();
} catch (IOException ioe) { // ignore}
   });


Creating a cleaner starts a thread that does the work so you'll want to 
decide

how to share it across the uses or to use than one.

Using lambdas for the cleaner functions is very lightweight but be 
careful to avoid

the using bound variables in the lambda body because they implicitly retain
a reference to the enclosing instance which will prevent the instance 
from becoming unreferences.


If there are more specific cases of interest let me know,

Regards, Roger


On 5/2/2017 10:08 PM, Rick Hillegas wrote:
When I compile Apache Derby using JDK 9 build 167, I see several 
instances of the following warning:


   warning: [deprecation] finalize() in Object has been deprecated

The javadoc for java.lang.Object.finalize() suggests that affected 
classes should migrate their finalization to a coding pattern based on 
the newly introduced java.lang.ref.Cleaner class. I am hesitant to try 
my hand at this without more guidance. Can you point me at a tutorial 
or list of best practices for implementing Cleaner-based finalization?


Thanks,
-Rick

Re: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows

[Roger Riggs]

Hi Amy,

Ok, fine as is.


My point was that there are now 2 exceptions in the log, one of which is 
an artifact of
the test only to provide the message and useful information is spread 
across those two exceptions.
There is no information lost but there is redundant information that has 
to be evaluated.


Roger


On 5/3/2017 12:18 AM, Amy Lu wrote:

Thank you Pavel, Paul, Roger and Daniel for your reviewing.

On 5/3/17 5:02 AM, Roger Riggs wrote:
But ": Must throw ClassCastException for parameter which is not 
Comparable."

in Empty navigableMap is much more useful.

And wrapping exceptions in exceptions makes debugging much harder, 
because
it requires unwrapping the context and figuring out what the test was 
trying to

do and which was the relevant source line.


As the message and exception trace are all kept, it won't make 
debugging harder.


For example for EmptyNavigableMap.java:

No exception case:
assertThrowsCCE(
() -> {},
description + ": Must throw ClassCastException for 
parameter which is not Comparable.");


The output:

test 
EmptyNavigableMap.testSubMap("emptyNavigableMap().descendingMap().descendingMap()", 
{}): failure
java.lang.AssertionError: 
emptyNavigableMap().descendingMap().descendingMap(): Must throw 
ClassCastException for parameter which is not Comparable.

Expected ClassCastException to be thrown, but nothing was thrown
at EmptyNavigableMap.assertThrows(EmptyNavigableMap.java:76)
at EmptyNavigableMap.assertThrowsCCE(EmptyNavigableMap.java:82)
at EmptyNavigableMap.testSubMap(EmptyNavigableMap.java:227)
...
Caused by: java.lang.AssertionError: Expected ClassCastException to be 
thrown, but nothing was thrown

at org.testng.Assert.expectThrows(Assert.java:1018)
at org.testng.Assert.assertThrows(Assert.java:989)
at EmptyNavigableMap.assertThrows(EmptyNavigableMap.java:74)
... 17 more

Wrong exception case:
assertThrowsCCE(
() -> {
throw new NullPointerException();
},
description + ": Must throw ClassCastException for 
parameter which is not Comparable.");


The output:

test 
EmptyNavigableMap.testSubMap("emptyNavigableMap().descendingMap().descendingMap()", 
{}): failure
java.lang.AssertionError: 
emptyNavigableMap().descendingMap().descendingMap(): Must throw 
ClassCastException for parameter which is not Comparable.
Expected ClassCastException to be thrown, but NullPointerException was 
thrown

at EmptyNavigableMap.assertThrows(EmptyNavigableMap.java:76)
at EmptyNavigableMap.assertThrowsCCE(EmptyNavigableMap.java:82)
at EmptyNavigableMap.testSubMap(EmptyNavigableMap.java:227)
...
Caused by: java.lang.AssertionError: Expected ClassCastException to be 
thrown, but NullPointerException was thrown

at org.testng.Assert.expectThrows(Assert.java:1013)
at org.testng.Assert.assertThrows(Assert.java:989)
at EmptyNavigableMap.assertThrows(EmptyNavigableMap.java:74)
... 17 more




I should probably try to file a bug against TestNG.assertThrows to 
add a variant with
a message. Many/most of the TestNG asserts have variants with messages. 


Good point!

- java/util/Map/Defaults.java:167  The {}'s around the lambda value 
are not necessary (like 166).

I'll remove it when push.

Thanks,
Amy

Re: RFR: 8078267 - Add test to verify that a module based JDBC driver via the service-provider loading mechanism

[Daniel Fuchs]

Hi Lance,

Are you planning to use these modules in other tests?
I'm asking because you're using the @library tag to compile them.
If you want to encapsulate a module inside a test (without resorting
to @library) then you can do so with the following layout and
following @build line:

/test//mytest/MyDriverTest.java
/test//mytest/mymodule/module-info.java
/test//mytest/mymodule/x/y/Z.java

@build mymodule/x.y.Z MyDriverTest

hope this helps,

-- daniel

On 03/05/2017 01:49, Lance Andersen wrote:

Hi Joe,


On May 2, 2017, at 8:34 PM, huizhe wang  wrote:

Hi Lance,

In DriverManagerModuleTests,  at line 83, did you mean to assign the result of 
DM::getDriver to d2 although an Exception is expected?

I must have accidentally deleted that  and never noticed it due to the 
SQLException being thrown.

I will add it prior to pushing.



Otherwise, the patch looks good to me.


Thank you

Best
Lance


Best,
Joe

On 5/2/2017 11:33 AM, Lance Andersen wrote:

Hi all,

The above issue adds a  test  to verify that a module based JDBC driver works 
via the service-provider loading mechanism.

The webrev can be found at 
http://cr.openjdk.java.net/~lancea/8078267/webrev.00/index.html 


Best
Lance
 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 







 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 

Re: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows

[Daniel Fuchs]

On 03/05/2017 05:19, Amy Lu wrote:

On 5/3/17 12:53 AM, Daniel Fuchs wrote:

Is that why you decided to drop the description?


I tried best to keep the useful message, EmptyNavigableMap
EmptyNavigableSet are examples. For Map/Defaults.java, most cases'
message are test's description and/or "should throw NPE", such
information already in the output.


The only exception is for testReplaceAllNoNullReplacement, the message
" should not allow replacement with null value"
for case
map.replaceAll((k,v) -> null)
is dropped. I just think that it might not worth with extra function for
just this one usage only.

I’ll make this message as a one-line comment when push.


OK. When the messages are not informative I guess it's OK
to drop them. Though as others have expressed it would be
good to have an Assert.assertThrows methods that takes
an additional string as argument!

best regards,

-- daniel



Thanks,
Amy



best regards

-- daniel

On 02/05/2017 10:19, Amy Lu wrote:

Please review this test-only change.

Some java/util tests use a function executeAndCatch which essentially
asserts that an exception is thrown, while some other tests use
assertThrows for doing the same work. For both cases, with jtreg
upgraded to testng 6.9.5 (CODETOOLS-7901639), test can then leverage
TestNG Assert.assertThrows

Please review the patch to update executeAndCatch and assertThrows to
Assert.assertThrows for java/util testng tests.

bug: https://bugs.openjdk.java.net/browse/JDK-8023897
webrev: http://cr.openjdk.java.net/~amlu/8023897/webrev.00/

Thanks,
Amy

Re: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke

[Peter Levart]

Hi Mandy,

On 05/02/2017 11:27 PM, Mandy Chung wrote:

Hi Peter,

Looking at it again, you are right that no need to skip inflation. The 
change
is simplified.   I have verified with and without 
-Dsun.reflect.noInflation=true.


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



Looks good. The following line is not needed now in ReflectionFactory 
(but is harmless):


 182 boolean noInflation = ReflectionFactory.noInflation;

Regards, Peter



thanks
Mandy

On May 2, 2017, at 1:17 PM, Peter Levart > wrote:



On 05/02/2017 06:56 PM, Mandy Chung wrote:

On May 2, 2017, at 3:14 AM, Peter Levart  wrote:

I don't quite understand the need for bypassing the inflation of native into 
generated method accessor

The VM native reflection implementation does not know about this alternate 
`reflected$XXX` mechanism.  No VM change in this patch and so we ensure this be 
called via the generated bytecode for Method::invoke rather than going through 
the VM native reflection which reduces startup overhead.


I don't think VM native reflection implementation needs to know 
anything about this alternate `reflected$XXX` mechanism. The 
NativeMethodAccessorImpl is constructed with the Method argument. In 
case of `reflected$XXX` mechanism, it is given the alternate Method 
object that points to the alternate method, so 
NativeMethodAccessorImpl.invoke0 is called with this alternate Method 
object. It is like reflecting over the alternate method itself, isn't it?


Am I missing something?


Is DelegatingMethodAccessorImpl/NativeMethodAccessorImpl combo not treated 
correctly (i.e. skipped) by the Reflection.getCallerClass(), while generated 
MethodAccessorImpl subclass is?

As this case is forced not to go through VM reflection support, unless I miss 
something, DelegatingMethodAccessorImpl/NativeMethodAccessorImpl has no need to 
be changed.  I will double check with the VM runtime team.


I was asking because I suspected that this might be the reason for 
skipping DelegatingMethodAccessorImpl/NativeMethodAccessorImpl. But 
if it is not the reason (and anyway it would be a bug because other 
@CallerSensitive methods would behave erratically if this was the 
case), then I still don't see a reason for skipping 
DelegatingMethodAccessorImpl/NativeMethodAccessorImpl and proceeding 
directly with generated method accessor.


Regards, Peter


Mandy