Re: RFR: 8047724: @since tag cleanup in jaxws
On 30/06/2014 02:30, Henry Jen wrote: Ping. Cheers, Henry Henry - the code in the jaxws repository is maintained upstream. If you change it in the jaxws repository then the changes will likely get overridden at the next sync-up. I'd suggest working with Miroslav (cc'ed) to get the changes pushed upstream first. -Alan.
Re: Long valueOf instead of new Long
Hi Otávio, About Andrej, is it not possible add two people in Contributed-by: tag? Thanks! But it's not needed. It's your contribution. I just help to review the changes. Best regards, Andrej Golovnin
Re: Streams and Spliterator characteristics confusion
On Jun 28, 2014, at 5:40 PM, Kasper Nielsen kaspe...@gmail.com wrote:
s.distinct().spliterator() - Spliterator.DISTINCT = true
but limiting the number of distinct elements makes the stream non distinct
s.distinct().limit(10).spliterator() - Spliterator.DISTINCT = false
I don't observe that (see program below).
Right, that was an error on my part.
But still, I think some there are some cases where the flag should be
maintained.
For example, I think following the following program should print 4 'true'
values but it only prints 1.
Especially the second one puzzles me, invoking distinct() makes it
non-distinct?
static IntStream s() {
return StreamSupport.intStream(Spliterators.spliterator(new int[] { 12, 34
}, Spliterator.DISTINCT), false);
}
public static void main(String[] args) {
System.out.println(s().spliterator().hasCharacteristics(Spliterator.DISTINCT));
System.out.println(s().distinct().spliterator().hasCharacteristics(Spliterator.DISTINCT));
System.out.println(s().boxed().spliterator().hasCharacteristics(Spliterator.DISTINCT));
System.out.println(s().asDoubleStream().spliterator().hasCharacteristics(Spliterator.DISTINCT));
}
The second is a good example as to why this is an implementation detail, here
is the implementation (some may want to close their eyes!):
public final IntStream distinct() {
// While functional and quick to implement, this approach is not very
efficient.
// An efficient version requires an int-specific map/set implementation.
return boxed().distinct().mapToInt(i - i);
}
We could work out how to inject back in distinct but since the spliterator is
intended as an escape hatch i did not think it worth the effort.
Note if the latter source was a a long stream it would not be able to inject
DISTINCT because not all long values can be represented precisely as double
values.
I am trying to implement the stream interfaces and I want to make sure that
my implementation have similar behaviour as the default implementation in
java.util.stream. The interoperability between streams and
Spliterator.characteristics is the only thing I'm having serious issues with.
I feel the current state is more a result of how streams are implemented at
the moment then as part of a public API.
I think something like a table with non-terminal stream operations as rows
and characteristics as columns. Where each cell was either: cleared, set
or maintained would make sense.
We deliberately did not specify this aspect, the implementation could change
and we don't want to unduly constrain it based on an escape-hatch (it's not the
common case). Implementations can decide to what extent the quality is of that
escape-hatch spliterator. For your implementation you are free to provide
better quality escape-hatch spliterators.
I think we should clarify the documentation on BaseStream.spliterator() to say
something like:
The characteristics of the returned spliterator need not correlate with
characteristics of the stream source
and those inferred from intermediate operations proceeding this terminal
operation.
https://bugs.openjdk.java.net/browse/JDK-8048689
I have also logged the following issues :
Spliterator.NONNULL
https://bugs.openjdk.java.net/browse/JDK-8048690
~ORDERED SORTED
https://bugs.openjdk.java.net/browse/JDK-8048691
Thanks,
Paul.
Re: Long valueOf instead of new Long
I've updated the webrev. It includes all the changes we've discussed so far
plus these:
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/macosx/classes/sun/font/CStrike.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/solaris/classes/java/util/prefs/FileSystemPreferences.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/solaris/classes/sun/awt/X11/XFocusProxyWindow.java.sdiff.html
Andrej, about the 0L - Long0 change. I think it's not necessary since this
case is *maybe* different from others. There's even a comment on it:
// Should never happen... but stay safe all the same.
//
else return 0L;
Anyway at a runtime 0L and Long0 will be the same object. So don't worry about
that.
I think we're almost ready to go.
Thanks,
-Pavel
On 28 Jun 2014, at 00:09, Otávio Gonçalves de Santana otavioj...@java.net
wrote:
I found more two unnecessary valueOf.
About Andrej, is it not possible add two people in Contributed-by: tag?
diff -r d02b062bc827
src/share/classes/com/sun/tools/example/debug/tty/Commands.java
--- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Fri Jun
13 11:21:30 2014 -0700
+++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Fri Jun
27 20:06:28 2014 -0300
@@ -935,7 +935,7 @@
try {
methodInfo = loc.sourceName() +
MessageOutput.format(line number,
- new Object [] {new
Long(lineNumber)});
+ new Object [] {lineNumber});
} catch (AbsentInformationException e) {
methodInfo = MessageOutput.format(unknown);
}
@@ -946,7 +946,7 @@
meth.declaringType().name(),
meth.name(),
methodInfo,
- new Long(pc)});
+ pc});
} else {
MessageOutput.println(stack frame dump,
new Object [] {new Integer(frameNumber +
1),
On Fri, Jun 27, 2014 at 5:16 PM, Andrej Golovnin andrej.golov...@gmail.com
wrote:
Hi Pavel,
I'm not sure what the style guide for the source code says, but
there is a space between the cast operator and the field name in
src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java (line 881):
@Override
public Long getSnmpOutGenErrs() {
-return new Long(snmpOutGenErrs);
+return (long) snmpOutGenErrs;
}
In all other changes there is no space after the cast operator.
Also, I removed one useless creation of a Long object here:
(line 191):
http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/sun/security/krb5/internal/KerberosTime.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.02/src/share/classes/sun/security/krb5/internal/KerberosTime.java.sdiff.html
And I have found one more :-) in KerberosTime.java:
252 public int getSeconds() {
253 Long temp_long = kerberosTime / 1000L;
254 return temp_long.intValue();
255 }
This can be changed to:
252 public int getSeconds() {
253 long temp_long = kerberosTime / 1000L;
254 return (int) temp_long;
255 }
I wonder if we should leave a cast to int here:
(line 383):
http://cr.openjdk.java.net/~prappo/8048267/webrev.01/src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java.sdiff.html
http://cr.openjdk.java.net/~prappo/8048267/webrev.02/src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java.sdiff.html
Well it's probably nothing to worry about, but strictly speaking this
changes the behaviour. Before the change, long was truncated to fit int.
And now it's not.
I would not change the behavior now. I think it is better to file a new issue
and change
it in a separate commit. Having this change in a separate commit may simplify
tracking
this change back in case it would cause some problems (I don't believe it).
And in the new issue you may provide better description for
Re: RFR: 8037948: Improve documentation for org.w3c.dom package
On Jun 30, 2014, at 3:22 PM, huizhe wang huizhe.w...@oracle.com wrote: On 6/30/2014 12:20 PM, Lance Andersen wrote: Looks OK Joe, noticed the @since changed as well? Thanks for review. Yes. The support for DOM L3 was since JDK 1.5. Previously this package file mentioned only DOM L2. OK, thank you. Just seemed strange that the overall version was changed as I suspect L3 is compatible with L2. I might have just indicated that L3 was added in 1.5 as the support was initially in 1.4 I believe. I have no strong preference though -Joe Best Lance On Jun 30, 2014, at 3:17 PM, huizhe wang huizhe.w...@oracle.com wrote: Hi, This is a quick fix for a broken link in org.w3c.dom package. Also included is removal of unnecessary (and bad) link to jaxp api in a catalog class. Please review. http://cr.openjdk.java.net/~joehw/jdk9/8037948/webrev/ Thanks, Joe Mail Attachment.gif 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: RFR: 8037948: Improve documentation for org.w3c.dom package
On 06/30/2014 12:26 PM, Lance Andersen wrote: On Jun 30, 2014, at 3:22 PM, huizhe wang huizhe.w...@oracle.com wrote: On 6/30/2014 12:20 PM, Lance Andersen wrote: Looks OK Joe, noticed the @since changed as well? Thanks for review. Yes. The support for DOM L3 was since JDK 1.5. Previously this package file mentioned only DOM L2. OK, thank you. Just seemed strange that the overall version was changed as I suspect L3 is compatible with L2. I might have just indicated that L3 was added in 1.5 as the support was initially in 1.4 I believe. I have no strong preference though I agree with Lance here, the package itself is included in JDK since 1.4. In case classes under this package is not properly labeled with @since tag, they will be considered has the same @since as package.html, then that would be really misleading. Cheers, Henry
Re: RFR: 8037948: Improve documentation for org.w3c.dom package
On 6/30/2014 1:16 PM, Lance @ Oracle wrote: Hi joe, Should be a comma at the end of line 8 before the and on line 9 comma added. Looks ok otherwise I committed the change. Thanks again Lance and Henry! -Joe Best Lance http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| Principal Member of Technical Staff | +1.781.442.2037 tel:+1.781.442.2037 Oracle Java Engineering 1 Network Drive x-apple-data-detectors://34/0 Burlington, MA 01803 x-apple-data-detectors://34/0 lance.ander...@oracle.com mailto:lance.ander...@oracle.com Sent from my iPad On Jun 30, 2014, at 4:07 PM, huizhe wang huizhe.w...@oracle.com mailto:huizhe.w...@oracle.com wrote: That makes sense. I changed @since back to 1.4 and added L2 in the description: http://cr.openjdk.java.net/~joehw/jdk9/8037948/webrev/ http://cr.openjdk.java.net/%7Ejoehw/jdk9/8037948/webrev/ Thanks, Joe On 6/30/2014 12:35 PM, Henry Jen wrote: On 06/30/2014 12:26 PM, Lance Andersen wrote: On Jun 30, 2014, at 3:22 PM, huizhe wang huizhe.w...@oracle.com mailto:huizhe.w...@oracle.com wrote: On 6/30/2014 12:20 PM, Lance Andersen wrote: Looks OK Joe, noticed the @since changed as well? Thanks for review. Yes. The support for DOM L3 was since JDK 1.5. Previously this package file mentioned only DOM L2. OK, thank you. Just seemed strange that the overall version was changed as I suspect L3 is compatible with L2. I might have just indicated that L3 was added in 1.5 as the support was initially in 1.4 I believe. I have no strong preference though I agree with Lance here, the package itself is included in JDK since 1.4. In case classes under this package is not properly labeled with @since tag, they will be considered has the same @since as package.html, then that would be really misleading. Cheers, Henry
RFR: 8023276: Java SE should include the full DOM API from JAXP
Hi, Three packages are missing from the DOM API documentation in JAXP: org.w3c.dom.views org.w3c.dom.ranges org.w3c.dom.traversal We added org.w3c.dom.views in JAXP 1.6 and fixed JDK-8006843. But since we were too close to the deadline for JAXP 1.6 MR, we left the other two packages for JDK 9. CCC has been approved for this addition. Please review. http://cr.openjdk.java.net/~joehw/jdk9/8023276/webrev/ Thanks, Joe
Re: RFR 8047737 Move array component mirror to instance of java/lang/Class
On Jun 30, 2014, at 1:06 PM, Coleen Phillimore coleen.phillim...@oracle.com
wrote:
On 6/30/14, 3:50 PM, Christian Thalinger wrote:
private Class(ClassLoader loader) {
// Initialize final field for classLoader. The initialization
value of non-null
// prevents future JIT optimizations from assuming this final field
is null.
classLoader = loader;
+componentType = null;
}
Are we worried about the same optimization?
I don't know if I was justified in worrying about the optimization in the
first place. Since getComponentType() is conditional, I wasn't worried.
But it should be consistent. Maybe I should revert the classLoader
constructor change, now that I fixed all the tests not to care. What do
people think?
+ compute_optional_offset(_component_mirror_offset,
+ klass_oop, vmSymbols::componentType_name(),
+ vmSymbols::class_signature());
Is there a followup cleanup to make it non-optional? Or, are you waiting
for JPRT to be able to push hotspot and jdk changes together?
Yes, please look at the _full webrev. That has the non-optional changes in
it and the follow on changes to remove getComponentType as an intrinsic in C2
(will file new RFE). I really would like a compiler person to comment on it.
Sorry, I missed that. Yes, the compiler changes look good.
Thanks so much,
Coleen
On Jun 30, 2014, at 5:42 AM, Coleen Phillimore
coleen.phillim...@oracle.com wrote:
On 6/30/14, 1:55 AM, David Holmes wrote:
Hi Coleen,
Your webrev links are to internal locations.
Sorry, I cut/pasted the wrong links. They are:
http://cr.openjdk.java.net/~coleenp/8047737_jdk/
http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
and the full version
http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
Thank you for pointing this out David.
Coleen
David
On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
Summary: Add field in java.lang.Class for componentType to simplify oop
processing and intrinsics in JVM
This is part of ongoing work to clean up oop pointers in the metadata
and simplify the interface between the JDK j.l.C and the JVM. There's a
performance benefit at the end of all of this if we can remove all oop
pointers from metadata. mirror in Klass is the only one left after
this full change.
See bug https://bugs.openjdk.java.net/browse/JDK-8047737
There are a couple steps to this change because Hotspot testing is done
with promoted JDKs. The first step is this webrev:
http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
When the JDK is promoted, the code to remove
ArrayKlass::_component_mirror will be changed under a new bug id.
http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
Finally, a compatibility request and licensee notification will occur to
remove the function JVM_GetComponentType.
Performance testing was done that shows no difference in performance.
The isArray() call is a compiler intrinsic which is now called instead
of getComponentType, which was recognized as a compiler intrinsic.
JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
tests were performed on both the change requested (1st one) and the full
change.
hotspot NSK tests were run on the hotspot-only change with a promoted JDK.
Please send your comments.
Thanks,
Coleen
Re: RFR: 8023276: Java SE should include the full DOM API from JAXP
On 6/30/14 2:32 PM, huizhe wang wrote: Hi, Three packages are missing from the DOM API documentation in JAXP: org.w3c.dom.views org.w3c.dom.ranges org.w3c.dom.traversal We added org.w3c.dom.views in JAXP 1.6 and fixed JDK-8006843. But since we were too close to the deadline for JAXP 1.6 MR, we left the other two packages for JDK 9. CCC has been approved for this addition. Please review. http://cr.openjdk.java.net/~joehw/jdk9/8023276/webrev/ thumbs up. Mandy
Re: RFR: 8023276: Java SE should include the full DOM API from JAXP
Thanks Mandy, Lance. The changeset is pushed. -Joe On 6/30/2014 5:02 PM, Mandy Chung wrote: On 6/30/14 2:32 PM, huizhe wang wrote: Hi, Three packages are missing from the DOM API documentation in JAXP: org.w3c.dom.views org.w3c.dom.ranges org.w3c.dom.traversal We added org.w3c.dom.views in JAXP 1.6 and fixed JDK-8006843. But since we were too close to the deadline for JAXP 1.6 MR, we left the other two packages for JDK 9. CCC has been approved for this addition. Please review. http://cr.openjdk.java.net/~joehw/jdk9/8023276/webrev/ thumbs up. Mandy
Re: RFR 8048840: File.createTempFile has uninformative failure message
Oops - forgot to run jtreg. Make that:
diff --git a/src/share/classes/java/io/File.java
b/src/share/classes/java/io/File.java
--- a/src/share/classes/java/io/File.java
+++ b/src/share/classes/java/io/File.java
@@ -1998,7 +1998,8 @@
throws IOException
{
if (prefix.length() 3)
-throw new IllegalArgumentException(Prefix string too short);
+throw new IllegalArgumentException(Prefix string too short:
+
+ prefix);
if (suffix == null)
suffix = .tmp;
diff --git a/test/java/io/File/NulFile.java b/test/java/io/File/NulFile.java
--- a/test/java/io/File/NulFile.java
+++ b/test/java/io/File/NulFile.java
@@ -602,7 +602,8 @@
try {
File.createTempFile(prefix, suffix, directory);
} catch (IllegalArgumentException ex) {
-if (Prefix string too short.equals(ex.getMessage()))
+String s = ex.getMessage();
+if (s != null s.startsWith(Prefix string too short))
exceptionThrown = true;
} catch (IOException ioe) {
System.err.println(IOException happens in
testCreateTempFile);
On Mon, Jun 30, 2014 at 6:05 PM, Jeremy Manson jeremyman...@google.com
wrote:
Hi folks,
We had a couple of complaints about this from our users, and it is a
pretty trivial fix, so I'm throwing this out as a potential patch. I
filed JDK-8048840:
diff --git a/src/share/classes/java/io/File.java
b/src/share/classes/java/io/File.java
--- a/src/share/classes/java/io/File.java
+++ b/src/share/classes/java/io/File.java
@@ -1998,7 +1998,8 @@
throws IOException
{
if (prefix.length() 3)
-throw new IllegalArgumentException(Prefix string too short);
+throw new IllegalArgumentException(Prefix string too short:
+
+ prefix);
if (suffix == null)
suffix = .tmp;
Jeremy
Re: RFR 8048840: File.createTempFile has uninformative failure message
Hello,
Do you think this fixes the complaints? I can imagine that or ~ is
used, and including this in the exception does not really help. Prefix
string too short, must be 3 characters would be my choice, but I wonder if
the restriction is very usefull anyway?
Bernd
Am 01.07.2014 03:17 schrieb Jeremy Manson jeremyman...@google.com:
Hi folks,
We had a couple of complaints about this from our users, and it is a pretty
trivial fix, so I'm throwing this out as a potential patch. I
filed JDK-8048840:
diff --git a/src/share/classes/java/io/File.java
b/src/share/classes/java/io/File.java
--- a/src/share/classes/java/io/File.java
+++ b/src/share/classes/java/io/File.java
@@ -1998,7 +1998,8 @@
throws IOException
{
if (prefix.length() 3)
-throw new IllegalArgumentException(Prefix string too short);
+throw new IllegalArgumentException(Prefix string too short:
+
+ prefix);
if (suffix == null)
suffix = .tmp;
Jeremy
Re: RFR 8047737 Move array component mirror to instance of java/lang/Class
On Jun 30, 2014, at 5:50 PM, Coleen Phillimore coleen.phillim...@oracle.com
wrote:
On 6/30/14, 3:50 PM, Christian Thalinger wrote:
private Class(ClassLoader loader) {
// Initialize final field for classLoader. The initialization
value of non-null
// prevents future JIT optimizations from assuming this final field
is null.
classLoader = loader;
+componentType = null;
}
Are we worried about the same optimization?
Hi, I've decided to make them consistent and add another parameter to the
Class constructor.
http://cr.openjdk.java.net/~coleenp/8047737_jdk_2/
Thanks.
Thanks,
Coleen
+ compute_optional_offset(_component_mirror_offset,
+ klass_oop, vmSymbols::componentType_name(),
+ vmSymbols::class_signature());
Is there a followup cleanup to make it non-optional? Or, are you waiting
for JPRT to be able to push hotspot and jdk changes together?
On Jun 30, 2014, at 5:42 AM, Coleen Phillimore coleen.phillim...@oracle.com
mailto:coleen.phillim...@oracle.com wrote:
On 6/30/14, 1:55 AM, David Holmes wrote:
Hi Coleen,
Your webrev links are to internal locations.
Sorry, I cut/pasted the wrong links. They are:
http://cr.openjdk.java.net/~coleenp/8047737_jdk/
http://cr.openjdk.java.net/%7Ecoleenp/8047737_jdk/
http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
and the full version
http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
Thank you for pointing this out David.
Coleen
David
On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
Summary: Add field in java.lang.Class for componentType to simplify oop
processing and intrinsics in JVM
This is part of ongoing work to clean up oop pointers in the metadata
and simplify the interface between the JDK j.l.C and the JVM. There's a
performance benefit at the end of all of this if we can remove all oop
pointers from metadata. mirror in Klass is the only one left after
this full change.
See bug https://bugs.openjdk.java.net/browse/JDK-8047737
There are a couple steps to this change because Hotspot testing is done
with promoted JDKs. The first step is this webrev:
http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
When the JDK is promoted, the code to remove
ArrayKlass::_component_mirror will be changed under a new bug id.
http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
Finally, a compatibility request and licensee notification will occur to
remove the function JVM_GetComponentType.
Performance testing was done that shows no difference in performance.
The isArray() call is a compiler intrinsic which is now called instead
of getComponentType, which was recognized as a compiler intrinsic.
JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
tests were performed on both the change requested (1st one) and the full
change.
hotspot NSK tests were run on the hotspot-only change with a promoted JDK.
Please send your comments.
Thanks,
Coleen
