Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-16 Thread alexander stepanov 

Please note also that a couple of new files were touched:

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html


On 15.04.2015 19:12, alexander stepanov wrote:

Hello Joe,

The copyright changes were reverted.

Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/

(code/code replaced with {@code}, removed unnecessary /p, 
used @literal tag).


Thanks,
Alexander


On 13.04.2015 21:19, huizhe wang wrote:


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while 
cleaning docs) I was asked to do that, other times - not to do 
that. Our internal policy seemingly assigns to change the 2nd date 
every time the sources were touched (but that may be a question of 
ambiguous interpretation).


But of course I can easily revert these changes if you're totally 
sure it should be done.


This has always been confusing. Some areas insist on updating the 
copyright dates, others don't. AFAIK, it has always been optional. I 
think the original assumption was that the update_copyright_year 
script (in the top-level repo) be run periodically to do bulk 
updates. Unfortunately that script doesn't seem to be run very often 
now and this strengthens the case to update the dates on a 
continuous basis. I have not come across the argument that html tidy 
tasks that don't change the javadoc should not update the copyright 
date. The general topic probably should move to jdk9-dev and get 
this decided once and documented in the developer guide.


I think the key question to ask is: is this the code I can claim 
Copyright with? To me, format, code style, html tags and other minor 
changes, these are not code changes one can claim copyright with.


The date of a Copyright establishes how far back the claim is made. 
In case where the work is substantially revised, a new Copyright 
claim is established, which is what the 2nd year is about.


In this case, esp. for the JAXP API (e.g. javax.xml.datatype), I'd 
like to see the years maintained because those are the years the API 
was designed and modified. The tidy warnings change did not change 
the API.


-Joe



-Alan

Places we should use the new ByteBuffer intrinsics

2015-04-16 Thread Andrew Haley 
We discussed where we should be using the new Unsafe unaligned
intrinsics.

I found these:

ByteBufferAs$Type$Buffer.  These use slow bytewise accesses,
and should be converted.

DirectByteBuffer.  This probes for unaligned memory support
and uses byte-by-byte accesses if it isn't available.  We
should probably convert it after doing some performance
measurements.

sun.security.provider.ByteArrayAccess.  This uses a lot of
hand-carved custom code to handle data which largely
duplicates that now in Unsafe, but big-endian platforms (and
little-endian ones which don't support unaligned accesses)
always use byte-by-byte accesses for unaligned data.  Again,
we should probably convert it after doing some performance
measurements.

Andrew.

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-16 Thread alexander stepanov 

I'm sorry, two extra files touched -
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MimetypesFileTypeMap.java.udiff.html

Hopefully that's all for this bug...

Thanks,
Alexander

On 16.04.2015 15:48, alexander stepanov wrote:

Please note also that a couple of new files were touched:

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 



On 15.04.2015 19:12, alexander stepanov wrote:

Hello Joe,

The copyright changes were reverted.

Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/

(code/code replaced with {@code}, removed unnecessary /p, 
used @literal tag).


Thanks,
Alexander


On 13.04.2015 21:19, huizhe wang wrote:


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while 
cleaning docs) I was asked to do that, other times - not to do 
that. Our internal policy seemingly assigns to change the 2nd date 
every time the sources were touched (but that may be a question of 
ambiguous interpretation).


But of course I can easily revert these changes if you're totally 
sure it should be done.


This has always been confusing. Some areas insist on updating the 
copyright dates, others don't. AFAIK, it has always been optional. 
I think the original assumption was that the update_copyright_year 
script (in the top-level repo) be run periodically to do bulk 
updates. Unfortunately that script doesn't seem to be run very 
often now and this strengthens the case to update the dates on a 
continuous basis. I have not come across the argument that html 
tidy tasks that don't change the javadoc should not update the 
copyright date. The general topic probably should move to jdk9-dev 
and get this decided once and documented in the developer guide.


I think the key question to ask is: is this the code I can claim 
Copyright with? To me, format, code style, html tags and other minor 
changes, these are not code changes one can claim copyright with.


The date of a Copyright establishes how far back the claim is made. 
In case where the work is substantially revised, a new Copyright 
claim is established, which is what the 2nd year is about.


In this case, esp. for the JAXP API (e.g. javax.xml.datatype), I'd 
like to see the years maintained because those are the years the API 
was designed and modified. The tidy warnings change did not change 
the API.


-Joe



-Alan

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-16 Thread alexander stepanov 

Hello Joe,

Thanks!

 as I mentioned, pre/pre is needed for the code snippet.
Oh, yes, that was that was forgotten.

 BTW, have you compiled
Yes; some javadoc errors were fixed as well

 and verified the Javadoc after the changes?
Only briefly. So as the above example shows I have to look it over once 
again (at least for files where the changes weren't trivial); will do that.


 Please note that for the JAXWS, you may need to check with JAXWS/Miran
Yes, I'll contact him, thanks.

Regards,
Alexander

On 16.04.2015 19:57, huizhe wang wrote:

Hi Alexander,

Looks very good. Thanks for making all the changes!

Please note that for the JAXWS, you may need to check with JAXWS/Miran 
(miroslav@oracle.com). Changes to JAXWS generally goes into the 
standalone first. They do periodic integration.


For the jaxp portion:
--- old/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-16 13:50:25.249473095 +0400
+++ new/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-16 13:50:25.161473099 +0400


@@ -725,37 +725,37 @@

  *
- * @return the relationship between codethis/code 
codeDuration/codeand codeduration/code parameter as
+ * @return the relationship between {@code this} {@code 
Duration}and {@code duration} parameter as


[jw] I saw in a few cases where two @code tags are next to each other, 
you may do a s/} {@code//g to combine them. A space is also missing 
before 'and': e.g. {@code Duration} and.



--- 
old/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java 
2015-04-16 13:50:28.197472963 +0400
+++ 
new/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java 
2015-04-16 13:50:28.105472967 +0400


@@ -542,7 +543,7 @@
* If the number of characters actually copied is less than the 
length, then there is no more text.
* Otherwise, subsequent calls need to be made until all text has 
been retrieved. For example:

*
-   *code
+   * {@code
* int length = 1024;
* char[] myBuffer = new char[ length ];
*
@@ -553,7 +554,7 @@
*   if (nCopied  length)
*   break;
* }
-   * /code
+   * }

[jw] as I mentioned, pre/pre is needed for the code snippet.


BTW, have you compiled and verified the Javadoc after the changes?

Thanks,
Joe

On 4/16/2015 7:07 AM, alexander stepanov wrote:

I'm sorry, two extra files touched -
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MimetypesFileTypeMap.java.udiff.html 



Hopefully that's all for this bug...

Thanks,
Alexander

On 16.04.2015 15:48, alexander stepanov wrote:

Please note also that a couple of new files were touched:

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 



On 15.04.2015 19:12, alexander stepanov wrote:

Hello Joe,

The copyright changes were reverted.

Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/

(code/code replaced with {@code}, removed unnecessary 
/p, used @literal tag).


Thanks,
Alexander


On 13.04.2015 21:19, huizhe wang wrote:


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while 
cleaning docs) I was asked to do that, other times - not to do 
that. Our internal policy seemingly assigns to change the 2nd 
date every time the sources were touched (but that may be a 
question of ambiguous interpretation).


But of course I can easily revert these changes if you're 
totally sure it should be done.


This has always been confusing. Some areas insist on updating the 
copyright dates, others don't. AFAIK, it has always been 
optional. I think the original assumption was that the 
update_copyright_year script (in the top-level repo) be run 
periodically to do bulk updates. Unfortunately that script 
doesn't seem to be run very often now and this strengthens the 
case to update the dates on a continuous basis. I have not come 
across the argument that html tidy tasks that don't change the 
javadoc should not update the copyright date. The general topic 
probably should move to jdk9-dev and get this decided once and 
documented in the developer guide.


I think the key question to ask

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-16 Thread alexander stepanov 

Hello Lance,

Thanks.

Regards,
Alexander

On 16.04.2015 19:58, Lance Andersen wrote:

Hi Alexander,

These seem to be OK

Best
Lance
On Apr 16, 2015, at 10:07 AM, alexander stepanov 
alexander.v.stepa...@oracle.com 
mailto:alexander.v.stepa...@oracle.com wrote:



I'm sorry, two extra files touched -
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MimetypesFileTypeMap.java.udiff.html

Hopefully that's all for this bug...

Thanks,
Alexander

On 16.04.2015 15:48, alexander stepanov wrote:

Please note also that a couple of new files were touched:

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 



On 15.04.2015 19:12, alexander stepanov wrote:

Hello Joe,

The copyright changes were reverted.

Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/

(code/code replaced with {@code}, removed unnecessary 
/p, used @literal tag).


Thanks,
Alexander


On 13.04.2015 21:19, huizhe wang wrote:


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while 
cleaning docs) I was asked to do that, other times - not to do 
that. Our internal policy seemingly assigns to change the 2nd 
date every time the sources were touched (but that may be a 
question of ambiguous interpretation).


But of course I can easily revert these changes if you're 
totally sure it should be done.


This has always been confusing. Some areas insist on updating the 
copyright dates, others don't. AFAIK, it has always been 
optional. I think the original assumption was that the 
update_copyright_year script (in the top-level repo) be run 
periodically to do bulk updates. Unfortunately that script 
doesn't seem to be run very often now and this strengthens the 
case to update the dates on a continuous basis. I have not come 
across the argument that html tidy tasks that don't change the 
javadoc should not update the copyright date. The general topic 
probably should move to jdk9-dev and get this decided once and 
documented in the developer guide.


I think the key question to ask is: is this the code I can claim 
Copyright with? To me, format, code style, html tags and other 
minor changes, these are not code changes one can claim copyright 
with.


The date of a Copyright establishes how far back the claim is 
made. In case where the work is substantially revised, a new 
Copyright claim is established, which is what the 2nd year is about.


In this case, esp. for the JAXP API (e.g. javax.xml.datatype), I'd 
like to see the years maintained because those are the years the 
API was designed and modified. The tidy warnings change did not 
change the API.


-Joe



-Alan










http://oracle.com/us/design/oracle-email-sig-198324.gif
http://oracle.com/us/design/oracle-email-sig-198324.gifhttp://oracle.com/us/design/oracle-email-sig-198324.gif
http://oracle.com/us/design/oracle-email-sig-198324.gifLance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com mailto:lance.ander...@oracle.com

Re: RFR (JAXP): 8042244 : Re-examine the supportedness of non-SE org.w3c.dom.** API

2015-04-16 Thread Mandy Chung 

On 4/15/15 12:23 PM, huizhe wang wrote:
Please review the change related to the non-SE org.w3c.dom.** API: 
org.w3c.dom.css, org.w3c.dom.html, org.w3c.dom.stylesheets, 
org.w3c.dom.xpath.


They came into Java SE along with the DOM API, but were not part of 
the Java SE and JAXP specification. For css, html and stylesheets, 
there is no implementation in the Java SE,  while for xpath, an 
experimental one. These types should not be exported through the 
java.xml module. Considering that there are references to them, we're 
moving them into a JDK module called jdk.xml.dom. The experimental DOM 
3 XPath thus is no longer available through the DOM API 
(DOMImplementation).


Please review:
JAXP change:
http://cr.openjdk.java.net/~joehw/jdk9/8042244/webrev/

module.xml:
http://cr.openjdk.java.net/~joehw/jdk9/8042244/jdk/webrev/


This looks good.  I reviewed the updated webrev with SUID added in 
XPathException which is the right thing to do.


Thanks for taking on this on.

Mandy

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

2015-04-16 Thread Andrew Haley 
On 02/18/2015 08:59 PM, Vladimir Kozlov wrote:
 The code which eliminates MemBars for scalarized objects was added in jdk8:
 
 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67

Right enough, but it only works with boxed objects.  The
Precedent of the MemBarNode is needed by MemBarNode::Ideal,
and it's checked for:

  // Eliminate volatile MemBars for scalar replaced objects.
  if (can_reshape  req() == (Precedent+1)) {
... think about eliminating the MemBar

So if there's no Precedent, none of the barrier elimination is done.

The only thing that sets the MemBar's Precedent is here:

In parse::do_put_xxx

// Preserve allocation ptr to create precedent edge to it in membar
// generated on exit from constructor.
if (C-eliminate_boxing() 
adr_type-isa_oopptr()  
adr_type-is_oopptr()-is_ptr_to_boxed_value() 
AllocateNode::Ideal_allocation(obj, _gvn) != NULL) {
  set_alloc_with_final(obj);
}

The barrier is created in parse1, and uses alloc_with_final:

  if (method()-is_initializer() 
(wrote_final() ||
   PPC64_ONLY(wrote_volatile() ||)
   (AlwaysSafeConstructors  wrote_fields( {
_exits.insert_mem_bar(Op_MemBarRelease, alloc_with_final());

So, it looks to me as though even the most trivial user-defined
constructors with final fields will never eliminate barriers.

I don't know what the thinking is here.  Why does it matter whether
the type being constructed is a boxed value?

Andrew.

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-16 Thread huizhe wang 

Hi Alexander,

Looks very good. Thanks for making all the changes!

Please note that for the JAXWS, you may need to check with JAXWS/Miran 
(miroslav@oracle.com). Changes to JAXWS generally goes into the 
standalone first. They do periodic integration.


For the jaxp portion:
--- old/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-16 13:50:25.249473095 +0400
+++ new/src/java.xml/share/classes/javax/xml/datatype/Duration.java 
2015-04-16 13:50:25.161473099 +0400


@@ -725,37 +725,37 @@

  *
- * @return the relationship between codethis/code 
codeDuration/codeand codeduration/code parameter as
+ * @return the relationship between {@code this} {@code 
Duration}and {@code duration} parameter as


[jw] I saw in a few cases where two @code tags are next to each other, 
you may do a s/} {@code//g to combine them. A space is also missing 
before 'and': e.g. {@code Duration} and.



--- old/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java 
2015-04-16 13:50:28.197472963 +0400
+++ new/src/java.xml/share/classes/javax/xml/stream/XMLStreamReader.java 
2015-04-16 13:50:28.105472967 +0400


@@ -542,7 +543,7 @@
* If the number of characters actually copied is less than the 
length, then there is no more text.
* Otherwise, subsequent calls need to be made until all text has 
been retrieved. For example:

*
-   *code
+   * {@code
* int length = 1024;
* char[] myBuffer = new char[ length ];
*
@@ -553,7 +554,7 @@
*   if (nCopied  length)
*   break;
* }
-   * /code
+   * }

[jw] as I mentioned, pre/pre is needed for the code snippet.


BTW, have you compiled and verified the Javadoc after the changes?

Thanks,
Joe

On 4/16/2015 7:07 AM, alexander stepanov wrote:

I'm sorry, two extra files touched -
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MimetypesFileTypeMap.java.udiff.html 



Hopefully that's all for this bug...

Thanks,
Alexander

On 16.04.2015 15:48, alexander stepanov wrote:

Please note also that a couple of new files were touched:

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html 

http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 
http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html 



On 15.04.2015 19:12, alexander stepanov wrote:

Hello Joe,

The copyright changes were reverted.

Please review the updated fix:
http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/

(code/code replaced with {@code}, removed unnecessary 
/p, used @literal tag).


Thanks,
Alexander


On 13.04.2015 21:19, huizhe wang wrote:


On 4/13/2015 4:42 AM, Alan Bateman wrote:

On 13/04/2015 12:22, alexander stepanov wrote:

Hello Joe,

Thank you for the notes;

 Copyright year shall not be changed.

That seems to be a bit controversial point; sometimes (while 
cleaning docs) I was asked to do that, other times - not to do 
that. Our internal policy seemingly assigns to change the 2nd 
date every time the sources were touched (but that may be a 
question of ambiguous interpretation).


But of course I can easily revert these changes if you're totally 
sure it should be done.


This has always been confusing. Some areas insist on updating the 
copyright dates, others don't. AFAIK, it has always been optional. 
I think the original assumption was that the update_copyright_year 
script (in the top-level repo) be run periodically to do bulk 
updates. Unfortunately that script doesn't seem to be run very 
often now and this strengthens the case to update the dates on a 
continuous basis. I have not come across the argument that html 
tidy tasks that don't change the javadoc should not update the 
copyright date. The general topic probably should move to jdk9-dev 
and get this decided once and documented in the developer guide.


I think the key question to ask is: is this the code I can claim 
Copyright with? To me, format, code style, html tags and other 
minor changes, these are not code changes one can claim copyright 
with.


The date of a Copyright establishes how far back the claim is made. 
In case where the work is substantially revised, a new Copyright 
claim is established, which is what the 2nd year is about.


In this case, esp. for the JAXP API (e.g. javax.xml.datatype), I'd 
like to see the years maintained because those are the years the 
API was designed and modified. The tidy warnings

Re: RFR [9] 8077332: tidy warnings from javax/xml

2015-04-16 Thread Lance Andersen 
Hi Alexander,

These seem to be OK

Best
Lance
On Apr 16, 2015, at 10:07 AM, alexander stepanov 
alexander.v.stepa...@oracle.com wrote:

 I'm sorry, two extra files touched -
 http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MailcapCommandMap.java.udiff.html
 http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.activation/share/classes/javax/activation/MimetypesFileTypeMap.java.udiff.html
 
 Hopefully that's all for this bug...
 
 Thanks,
 Alexander
 
 On 16.04.2015 15:48, alexander stepanov wrote:
 Please note also that a couple of new files were touched:
 
 http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html
  
 http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java.udiff.html
  
 http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html
  
 http://cr.openjdk.java.net/%7Eavstepan/8077332/webrev.01/jaxws/src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java.udiff.html
  
 
 On 15.04.2015 19:12, alexander stepanov wrote:
 Hello Joe,
 
 The copyright changes were reverted.
 
 Please review the updated fix:
 http://cr.openjdk.java.net/~avstepan/8077332/webrev.01/
 
 (code/code replaced with {@code}, removed unnecessary /p, used 
 @literal tag).
 
 Thanks,
 Alexander
 
 
 On 13.04.2015 21:19, huizhe wang wrote:
 
 On 4/13/2015 4:42 AM, Alan Bateman wrote:
 On 13/04/2015 12:22, alexander stepanov wrote:
 Hello Joe,
 
 Thank you for the notes;
 
  Copyright year shall not be changed.
 
 That seems to be a bit controversial point; sometimes (while cleaning 
 docs) I was asked to do that, other times - not to do that. Our internal 
 policy seemingly assigns to change the 2nd date every time the sources 
 were touched (but that may be a question of ambiguous interpretation).
 
 But of course I can easily revert these changes if you're totally sure 
 it should be done.
 
 This has always been confusing. Some areas insist on updating the 
 copyright dates, others don't. AFAIK, it has always been optional. I 
 think the original assumption was that the update_copyright_year script 
 (in the top-level repo) be run periodically to do bulk updates. 
 Unfortunately that script doesn't seem to be run very often now and this 
 strengthens the case to update the dates on a continuous basis. I have 
 not come across the argument that html tidy tasks that don't change the 
 javadoc should not update the copyright date. The general topic probably 
 should move to jdk9-dev and get this decided once and documented in the 
 developer guide.
 
 I think the key question to ask is: is this the code I can claim Copyright 
 with? To me, format, code style, html tags and other minor changes, these 
 are not code changes one can claim copyright with.
 
 The date of a Copyright establishes how far back the claim is made. In 
 case where the work is substantially revised, a new Copyright claim is 
 established, which is what the 2nd year is about.
 
 In this case, esp. for the JAXP API (e.g. javax.xml.datatype), I'd like to 
 see the years maintained because those are the years the API was designed 
 and modified. The tidy warnings change did not change the API.
 
 -Joe
 
 
 -Alan
 
 
 
 



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 (JAXP): 8042244 : Re-examine the supportedness of non-SE org.w3c.dom.** API

2015-04-16 Thread huizhe wang 

Thanks Mandy!

Joe

On 4/16/2015 9:43 AM, Mandy Chung wrote:

On 4/15/15 12:23 PM, huizhe wang wrote:
Please review the change related to the non-SE org.w3c.dom.** API: 
org.w3c.dom.css, org.w3c.dom.html, org.w3c.dom.stylesheets, 
org.w3c.dom.xpath.


They came into Java SE along with the DOM API, but were not part of 
the Java SE and JAXP specification. For css, html and stylesheets, 
there is no implementation in the Java SE,  while for xpath, an 
experimental one. These types should not be exported through the 
java.xml module. Considering that there are references to them, we're 
moving them into a JDK module called jdk.xml.dom. The experimental 
DOM 3 XPath thus is no longer available through the DOM API 
(DOMImplementation).


Please review:
JAXP change:
http://cr.openjdk.java.net/~joehw/jdk9/8042244/webrev/

module.xml:
http://cr.openjdk.java.net/~joehw/jdk9/8042244/jdk/webrev/


This looks good.  I reviewed the updated webrev with SUID added in 
XPathException which is the right thing to do.


Thanks for taking on this on.

Mandy

Re: Places we should use the new ByteBuffer intrinsics

2015-04-16 Thread Paul Sandoz 

On Apr 16, 2015, at 12:56 PM, Andrew Haley a...@redhat.com wrote:

 We discussed where we should be using the new Unsafe unaligned
 intrinsics.
 
 I found these:
 

They look like good candidates. I did a quick search in the JDK src code 
(usages of getByte/Short/Int/Long) and could not find any others.


   ByteBufferAs$Type$Buffer.  These use slow bytewise accesses,
   and should be converted.
 
DirectByteBuffer.  This probes for unaligned memory support
and uses byte-by-byte accesses if it isn't available.  We
should probably convert it after doing some performance
measurements.
 

That should be a nice cleanup, i would be surprised if it resulted in any 
performance issues but it would be good to check as you say.


sun.security.provider.ByteArrayAccess.  This uses a lot of
hand-carved custom code to handle data which largely
duplicates that now in Unsafe, but big-endian platforms (and
little-endian ones which don't support unaligned accesses)
always use byte-by-byte accesses for unaligned data.  Again,
we should probably convert it after doing some performance
measurements.
 

There is also an assumption in the following comment in 
sun.security.provider.ByteArrayAccess.b2lBig that i presume is no longer 
relevant:

  // In the current HotSpot memory layout, the first element of a
  // byte[] is only 32-bit aligned, not 64-bit.
  // That means we could use getLong() only for offset 4, 12, etc.,
  // which would rarely occur in practice. Instead, we use an
  // optimization that uses getInt() so that it works for offset 0.

Paul.

Re: RFR 9: 8077350 Process API Updates Implementation Review

2015-04-16 Thread Thomas Stüfe 
Hi Roger,

thank you for your answer!

The reason I take an interest is not just theoretical. We (SAP) use our JVM
for our test infrastructure and we had exactly the problem allChildren() is
designed to solve: killing a process tree related to a specific tests
(similar to jtreg tests) in case of errors or hangs. We have test machines
running large workloads of tests in parallel and we reach pid wraparound -
depending on the OS - quite fast.

We solved this by adding process groups to Process.java and we are very
happy with this solution. We are able to quickly kill a whole process tree,
cleanly and completely, without ambiguity or risk to other tests. Of course
we had to add this support as a sideways hack in order to not change the
official Process.java interface. Therefore I was hoping that with JEP 102,
we would get official support for process groups. Unfortunately, seems the
decision is already done and we are too late in the discussion :(

see my other comments inline.

On Sat, Apr 11, 2015 at 8:55 PM, Roger Riggs roger.ri...@oracle.com wrote:

  Hi Thomas,

 Thanks for the comments.

 On 4/11/2015 8:31 AM, Thomas Stüfe wrote:

 Hi Roger,

  I have a question about getChildren() and getAllChildren().

 I assume the point of those functions is to implement point 4 of JEP 102
 (The ability to deal with process trees, in particular some means to
 destroy a process tree.), by returning a collection of PIDs which are the
 children of the process and then killing them?

 Earlier versions included a killProcess tree method but it was recommended
 to leave
 the exact algorithm to kill processes to the caller.


  However, I am not sure that this can be implemented in a safe way, at
 least on UNIX, because - as Martin already pointed out - of PID recycling.
 I do not see how you can prevent allChildren() from returning PIDs which
 may be already reaped and recyled when you use them later. How do you
 prevent that?

 Unless there is an extended time between getting the children and
 destroying them the pids will still be valid.


Why? Child process may be getting reaped the instant you are done reading
it from /proc, and pid may have been recycled by the OS right away and
already pointing to another process when allChildren() returns. If a
process lives about as long as it takes the system to reach a pid
wraparound to the same pid value, its pid could be recycled right after it
is reaped, or? Sure, the longer you wait, the higher the chance of this to
happen, but it may happen right away.

As Martin said, we had those races in the kill() code since a long time,
but children()/allChildren() could make those error more probable, because
now more processes are involved. Especially if you use allChildren to kill
a deep process tree. And there is nothing in the javadoc warning the user
about this scenario. You would just happen from time to time to kill an
unrelated process. Those problems are hard to debug.

The technique of caching the start time can prevent that case; though it
 has AFAIK not been a problem.


How would that work? User should, before issuing the kill, compare start
time of process to kill with cached start time?

 Note even if your coding is bulletproof, that allChildren() will also
 return PIDs of sub processes which are completely unrelated to you and
 Process.java - they could have been forked by some third party native code
 which just happens to run in parallel in the same process. There, you have
 no control about when it gets reaped. It might already have been reaped by
 the time allChildren() returns, and now the same PID got recycled as
 another, unrelated process.

 Of course, the best case is for an application to spawn and manage its own
 processes
 and handle there proper termination.
 The use cases for children/allChildren are focused on
 supervisory/executive functions
 that monitor a running system and can cleanup even in the case of
 unexpected failures.

All management of processes is subject to OS limitations, if the PID were
 from a completely
 different process tree, the ordinary destroy/info functions would not be
 available
 unless the process was running as a privileged os user (same as any other
 native application).


Could you explain this please? If both trees run under the same user, why
should I not be able to kill a process from a different tree?

 If I am right, it would not be sufficient to state There is no guarantee
 that a process is alive. - it may be alive but by now be a different
 process altogether. This makes allChildren() useless for many cases,
 because the returned information may already be obsolete the moment the
 function returns.

 The caching of startTime can remove the ambiguity.



  Of course I may something missing here?

  But if I got all that right and the sole purpose of allChildren() is to
 be able to kill them (or otherwise signal them), why not use process
 groups? Process groups would be the traditional way on POSIX platforms to

Re: Places we should use the new ByteBuffer intrinsics

2015-04-16 Thread Ulf Zibis 


Am 16.04.2015 um 15:25 schrieb Paul Sandoz:

They look like good candidates. I did a quick search in the JDK src code 
(usages of getByte/Short/Int/Long) and could not find any others.


I guess there are plenty of candidates in coders of sun.nio.cs.
Additionally: For some coders it may be reasonable to have get3Bytes() and 
put3Bytes() methods.
At the end it wouldn't make me wonder if we could get rid of the if 
(src.hasArray())-fork.

-Ulf

Re: Places we should use the new ByteBuffer intrinsics

2015-04-16 Thread Ulf Zibis 


Am 16.04.2015 um 15:25 schrieb Paul Sandoz:

They look like good candidates. I did a quick search in the JDK src code 
(usages of getByte/Short/Int/Long) and could not find any others.


I guess there are plenty of candidates in coders of sun.nio.cs.
At the end it wouldn't make me wonder if we could get rid of the if 
(src.hasArray())-fork.

-Ulf

Re: [9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

2015-04-16 Thread Vladimir Ivanov 

Roland, thanks a lot for the review!

Best regards,
Vladimir Ivanov

On 4/15/15 7:43 PM, Roland Westrelin wrote:

  http://cr.openjdk.java.net/~vlivanov/8057967/webrev.01/


That looks good to me.

Roland.

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

2015-04-16 Thread Vladimir Kozlov 
Because that code was added and tested only for boxed objects (goal of 
6934604) - I wanted to avoid wider effects of those changes.


I think we can remove the limitation now in jd9 sources since we have 
enough time to tests it.


Regards,
Vladimir

On 4/16/15 10:07 AM, Andrew Haley wrote:

On 02/18/2015 08:59 PM, Vladimir Kozlov wrote:

The code which eliminates MemBars for scalarized objects was added in jdk8:

http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67


Right enough, but it only works with boxed objects.  The
Precedent of the MemBarNode is needed by MemBarNode::Ideal,
and it's checked for:

   // Eliminate volatile MemBars for scalar replaced objects.
   if (can_reshape  req() == (Precedent+1)) {
 ... think about eliminating the MemBar

So if there's no Precedent, none of the barrier elimination is done.

The only thing that sets the MemBar's Precedent is here:

In parse::do_put_xxx

 // Preserve allocation ptr to create precedent edge to it in membar
 // generated on exit from constructor.
 if (C-eliminate_boxing() 
 adr_type-isa_oopptr()  adr_type-is_oopptr()-is_ptr_to_boxed_value() 

 AllocateNode::Ideal_allocation(obj, _gvn) != NULL) {
   set_alloc_with_final(obj);
 }

The barrier is created in parse1, and uses alloc_with_final:

   if (method()-is_initializer() 
 (wrote_final() ||
PPC64_ONLY(wrote_volatile() ||)
(AlwaysSafeConstructors  wrote_fields( {
 _exits.insert_mem_bar(Op_MemBarRelease, alloc_with_final());

So, it looks to me as though even the most trivial user-defined
constructors with final fields will never eliminate barriers.

I don't know what the thinking is here.  Why does it matter whether
the type being constructed is a boxed value?

Andrew.

JDK 9 RFR of adding missing javadoc to javax.transaction

2015-04-16 Thread joe darcy 

Hello,

While preparing to turn on doclint build warnings on more modules, I 
noticed there are missing javadoc comments on various classes in 
javax.transaction.


Please review the patch below which add in some obvious javadoc.

Thanks,

-Joe

diff -r 488af0e8ee33 
src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java
--- 
a/src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java 
Thu Apr 16 10:44:23 2015 -0700
+++ 
b/src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java 
Thu Apr 16 11:07:12 2015 -0700

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -39,10 +39,17 @@
 @SuppressWarnings(serial) // serialVersionUID 
intentionally omitted
 public class InvalidTransactionException extends 
java.rmi.RemoteException {


+/**
+ * Constructs an {@code InvalidTransactionException}.
+ */
 public InvalidTransactionException() {
 super();
 }

+/**
+ * Constructs an {@code InvalidTransactionException}.
+ * @param msg the detail message
+ */
 public InvalidTransactionException(String msg) {
 super(msg);
 }
diff -r 488af0e8ee33 
src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java
--- 
a/src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java 
Thu Apr 16 10:44:23 2015 -0700
+++ 
b/src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java 
Thu Apr 16 11:07:12 2015 -0700

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -38,10 +38,17 @@
 @SuppressWarnings(serial) // serialVersionUID 
intentionally omitted
 public class TransactionRequiredException extends 
java.rmi.RemoteException {


+/**
+ * Constructs a {@code TransactionRequiredException}.
+ */
 public TransactionRequiredException() {
 super();
 }

+/**
+ * Constructs a {@code TransactionRequiredException}.
+ * @param msg the detail message
+ */
 public TransactionRequiredException(String msg) {
 super(msg);
 }
diff -r 488af0e8ee33 
src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java
--- 
a/src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java 
Thu Apr 16 10:44:23 2015 -0700
+++ 
b/src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java 
Thu Apr 16 11:07:12 2015 -0700

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -41,10 +41,17 @@
 @SuppressWarnings(serial) // serialVersionUID 
intentionally omitted
 public class TransactionRolledbackException extends 
java.rmi.RemoteException {


+/**
+ * Constructs a {@code TransactionRolledbackException}.
+ */
 public TransactionRolledbackException() {
 super();
 }

+/**
+ * Constructs a {@code TransactionRolledbackException}.
+ * @param msg the detail message
+ */
 public TransactionRolledbackException(String msg) {
 super(msg);
 }

Re: JDK 9 RFR of adding missing javadoc to javax.transaction

2015-04-16 Thread Roger Riggs 

Hi Joe,

Looks fine.

Roger


On 4/16/2015 2:08 PM, joe darcy wrote:

Hello,

While preparing to turn on doclint build warnings on more modules, I 
noticed there are missing javadoc comments on various classes in 
javax.transaction.


Please review the patch below which add in some obvious javadoc.

Thanks,

-Joe

diff -r 488af0e8ee33 
src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java
--- 
a/src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java 
Thu Apr 16 10:44:23 2015 -0700
+++ 
b/src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java 
Thu Apr 16 11:07:12 2015 -0700

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -39,10 +39,17 @@
 @SuppressWarnings(serial) // serialVersionUID 
intentionally omitted
 public class InvalidTransactionException extends 
java.rmi.RemoteException {


+/**
+ * Constructs an {@code InvalidTransactionException}.
+ */
 public InvalidTransactionException() {
 super();
 }

+/**
+ * Constructs an {@code InvalidTransactionException}.
+ * @param msg the detail message
+ */
 public InvalidTransactionException(String msg) {
 super(msg);
 }
diff -r 488af0e8ee33 
src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java
--- 
a/src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java 
Thu Apr 16 10:44:23 2015 -0700
+++ 
b/src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java 
Thu Apr 16 11:07:12 2015 -0700

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -38,10 +38,17 @@
 @SuppressWarnings(serial) // serialVersionUID 
intentionally omitted
 public class TransactionRequiredException extends 
java.rmi.RemoteException {


+/**
+ * Constructs a {@code TransactionRequiredException}.
+ */
 public TransactionRequiredException() {
 super();
 }

+/**
+ * Constructs a {@code TransactionRequiredException}.
+ * @param msg the detail message
+ */
 public TransactionRequiredException(String msg) {
 super(msg);
 }
diff -r 488af0e8ee33 
src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java
--- 
a/src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java 
Thu Apr 16 10:44:23 2015 -0700
+++ 
b/src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java 
Thu Apr 16 11:07:12 2015 -0700

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -41,10 +41,17 @@
 @SuppressWarnings(serial) // serialVersionUID 
intentionally omitted
 public class TransactionRolledbackException extends 
java.rmi.RemoteException {


+/**
+ * Constructs a {@code TransactionRolledbackException}.
+ */
 public TransactionRolledbackException() {
 super();
 }

+/**
+ * Constructs a {@code TransactionRolledbackException}.
+ * @param msg the detail message
+ */
 public TransactionRolledbackException(String msg) {
 super(msg);
 }

Re: JDK 9 RFR of adding missing javadoc to javax.transaction

2015-04-16 Thread Lance Andersen 
Hi Joe,

This Looks OK.  I have already had discussions with the Java EE leads about 
adding the SUID and pushing the changes back upstream (and updating other 
classes in upstream javax.transaction as needed.
   
 I will be doing that soon and will push these changes as well.

Best,
Lance
On Apr 16, 2015, at 2:08 PM, joe darcy joe.da...@oracle.com wrote:

 Hello,
 
 While preparing to turn on doclint build warnings on more modules, I noticed 
 there are missing javadoc comments on various classes in javax.transaction.
 
 Please review the patch below which add in some obvious javadoc.
 
 Thanks,
 
 -Joe
 
 diff -r 488af0e8ee33 
 src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java
 --- 
 a/src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java
  Thu Apr 16 10:44:23 2015 -0700
 +++ 
 b/src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java
  Thu Apr 16 11:07:12 2015 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -39,10 +39,17 @@
 @SuppressWarnings(serial) // serialVersionUID intentionally 
 omitted
 public class InvalidTransactionException extends java.rmi.RemoteException {
 
 +/**
 + * Constructs an {@code InvalidTransactionException}.
 + */
 public InvalidTransactionException() {
 super();
 }
 
 +/**
 + * Constructs an {@code InvalidTransactionException}.
 + * @param msg the detail message
 + */
 public InvalidTransactionException(String msg) {
 super(msg);
 }
 diff -r 488af0e8ee33 
 src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java
 --- 
 a/src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java
  Thu Apr 16 10:44:23 2015 -0700
 +++ 
 b/src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java
  Thu Apr 16 11:07:12 2015 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -38,10 +38,17 @@
 @SuppressWarnings(serial) // serialVersionUID intentionally 
 omitted
 public class TransactionRequiredException extends java.rmi.RemoteException {
 
 +/**
 + * Constructs a {@code TransactionRequiredException}.
 + */
 public TransactionRequiredException() {
 super();
 }
 
 +/**
 + * Constructs a {@code TransactionRequiredException}.
 + * @param msg the detail message
 + */
 public TransactionRequiredException(String msg) {
 super(msg);
 }
 diff -r 488af0e8ee33 
 src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java
 --- 
 a/src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java
  Thu Apr 16 10:44:23 2015 -0700
 +++ 
 b/src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java
  Thu Apr 16 11:07:12 2015 -0700
 @@ -1,5 +1,5 @@
 /*
 - * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights 
 reserved.
 + * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights 
 reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
 @@ -41,10 +41,17 @@
 @SuppressWarnings(serial) // serialVersionUID intentionally 
 omitted
 public class TransactionRolledbackException extends java.rmi.RemoteException {
 
 +/**
 + * Constructs a {@code TransactionRolledbackException}.
 + */
 public TransactionRolledbackException() {
 super();
 }
 
 +/**
 + * Constructs a {@code TransactionRolledbackException}.
 + * @param msg the detail message
 + */
 public TransactionRolledbackException(String msg) {
 super(msg);
 }



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 adding missing javadoc to javax.transaction

2015-04-16 Thread joe darcy 

Hi Lance,

On 4/16/2015 11:27 AM, Lance Andersen wrote:

Hi Joe,

This Looks OK.  I have already had discussions with the Java EE leads 
about adding the SUID and pushing the changes back upstream (and 
updating other classes in upstream javax.transaction as needed.

 I will be doing that soon and will push these changes as well.


Thanks for offering to take care of that; cheers,

-Joe



Best,
Lance
On Apr 16, 2015, at 2:08 PM, joe darcy joe.da...@oracle.com 
mailto:joe.da...@oracle.com wrote:



Hello,

While preparing to turn on doclint build warnings on more modules, I 
noticed there are missing javadoc comments on various classes in 
javax.transaction.


Please review the patch below which add in some obvious javadoc.

Thanks,

-Joe

diff -r 488af0e8ee33 
src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java
--- 
a/src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java 
Thu Apr 16 10:44:23 2015 -0700
+++ 
b/src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java 
Thu Apr 16 11:07:12 2015 -0700

@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All 
rights reserved.
+ * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All 
rights reserved.

 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
@@ -39,10 +39,17 @@
@SuppressWarnings(serial) // serialVersionUID 
intentionally omitted
public class InvalidTransactionException extends 
java.rmi.RemoteException {


+/**
+ * Constructs an {@code InvalidTransactionException}.
+ */
public InvalidTransactionException() {
super();
}

+/**
+ * Constructs an {@code InvalidTransactionException}.
+ * @param msg the detail message
+ */
public InvalidTransactionException(String msg) {
super(msg);
}
diff -r 488af0e8ee33 
src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java
--- 
a/src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java 
Thu Apr 16 10:44:23 2015 -0700
+++ 
b/src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java 
Thu Apr 16 11:07:12 2015 -0700

@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All 
rights reserved.
+ * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All 
rights reserved.

 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
@@ -38,10 +38,17 @@
@SuppressWarnings(serial) // serialVersionUID 
intentionally omitted
public class TransactionRequiredException extends 
java.rmi.RemoteException {


+/**
+ * Constructs a {@code TransactionRequiredException}.
+ */
public TransactionRequiredException() {
super();
}

+/**
+ * Constructs a {@code TransactionRequiredException}.
+ * @param msg the detail message
+ */
public TransactionRequiredException(String msg) {
super(msg);
}
diff -r 488af0e8ee33 
src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java
--- 
a/src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java 
Thu Apr 16 10:44:23 2015 -0700
+++ 
b/src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java 
Thu Apr 16 11:07:12 2015 -0700

@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All 
rights reserved.
+ * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All 
rights reserved.

 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
@@ -41,10 +41,17 @@
@SuppressWarnings(serial) // serialVersionUID 
intentionally omitted
public class TransactionRolledbackException extends 
java.rmi.RemoteException {


+/**
+ * Constructs a {@code TransactionRolledbackException}.
+ */
public TransactionRolledbackException() {
super();
}

+/**
+ * Constructs a {@code TransactionRolledbackException}.
+ * @param msg the detail message
+ */
public TransactionRolledbackException(String msg) {
super(msg);
}


http://oracle.com/us/design/oracle-email-sig-198324.gif
http://oracle.com/us/design/oracle-email-sig-198324.gifhttp://oracle.com/us/design/oracle-email-sig-198324.gif
http://oracle.com/us/design/oracle-email-sig-198324.gifLance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com mailto:lance.ander...@oracle.com

Re: JDK 9 RFR of adding missing javadoc to javax.transaction

2015-04-16 Thread Alan Bateman 


This looks okay but I think we should get Lance to check the EE folks 
because this area has a standalone JSR. It came up a few months too with 
the SUID and I think Lance is following up with them on that too.


-Alan


On 16/04/2015 19:08, joe darcy wrote:

Hello,

While preparing to turn on doclint build warnings on more modules, I 
noticed there are missing javadoc comments on various classes in 
javax.transaction.


Please review the patch below which add in some obvious javadoc.

Thanks,

-Joe

diff -r 488af0e8ee33 
src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java
--- 
a/src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java 
Thu Apr 16 10:44:23 2015 -0700
+++ 
b/src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java 
Thu Apr 16 11:07:12 2015 -0700

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -39,10 +39,17 @@
 @SuppressWarnings(serial) // serialVersionUID 
intentionally omitted
 public class InvalidTransactionException extends 
java.rmi.RemoteException {


+/**
+ * Constructs an {@code InvalidTransactionException}.
+ */
 public InvalidTransactionException() {
 super();
 }

+/**
+ * Constructs an {@code InvalidTransactionException}.
+ * @param msg the detail message
+ */
 public InvalidTransactionException(String msg) {
 super(msg);
 }
diff -r 488af0e8ee33 
src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java
--- 
a/src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java 
Thu Apr 16 10:44:23 2015 -0700
+++ 
b/src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java 
Thu Apr 16 11:07:12 2015 -0700

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -38,10 +38,17 @@
 @SuppressWarnings(serial) // serialVersionUID 
intentionally omitted
 public class TransactionRequiredException extends 
java.rmi.RemoteException {


+/**
+ * Constructs a {@code TransactionRequiredException}.
+ */
 public TransactionRequiredException() {
 super();
 }

+/**
+ * Constructs a {@code TransactionRequiredException}.
+ * @param msg the detail message
+ */
 public TransactionRequiredException(String msg) {
 super(msg);
 }
diff -r 488af0e8ee33 
src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java
--- 
a/src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java 
Thu Apr 16 10:44:23 2015 -0700
+++ 
b/src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java 
Thu Apr 16 11:07:12 2015 -0700

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1998, 1999, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -41,10 +41,17 @@
 @SuppressWarnings(serial) // serialVersionUID 
intentionally omitted
 public class TransactionRolledbackException extends 
java.rmi.RemoteException {


+/**
+ * Constructs a {@code TransactionRolledbackException}.
+ */
 public TransactionRolledbackException() {
 super();
 }

+/**
+ * Constructs a {@code TransactionRolledbackException}.
+ * @param msg the detail message
+ */
 public TransactionRolledbackException(String msg) {
 super(msg);
 }