hg: jdk8/tl: 8011347: JKD-8009824 has broken webrev with some ksh versions

[daniel . fuchs]

Changeset: b95c5c8ee60a
Author:jgish
Date:  2013-04-16 13:25 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/b95c5c8ee60a

8011347: JKD-8009824 has broken webrev with some ksh versions
Reviewed-by: mduigou

! make/scripts/webrev.ksh

Re: Fwd: Latency in starting threads on Mac OS X

[Alan Bateman]

On 17/04/2013 02:27, David Holmes wrote:

:

I don't know specifically what may have changed between 7u5 and 7u6 in 
that regard but I think it would be a hotspot issue more than a 
libraries issue. I know 7u6 was the first version of JDK to fully 
support OS X.
The Mac support went into 7u4 but Oracle builds didn't have all the 
(closed) deployment features until 7u6. Aside from the issues  that you 
pointed out, it probably needs someone to look at it more closely to 
narrow this down a bit.


-Alan

Re: [PATCH] Review Request for 8009258: TEST_BUG: java/io/pathNames/GeneralWin32.java fails intermittently

[Alan Bateman]

On 17/04/2013 07:36, Dan Xu wrote:

:

In the changes, the usages of NIO classes are not necessary. The test 
is against java.io packages, and it is better to keep it clean in case 
it might be used to test old jdk version which does not have NIO.


I briefly looked at it and I think the usage okay is because it just 
makes it easier to check the results and also to keep the directory walk 
from wandering into other parts of the file system. If it changed what 
was being tested then I would agree that it shouldn't be used.


-Alan

hg: jdk8/tl/langtools: 8011181: javac, empty UTF8 entry generated for inner class

[vicente . romero]

Changeset: 49d32c84dfea
Author:vromero
Date:  2013-04-17 11:11 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/49d32c84dfea

8011181: javac, empty UTF8 entry generated for inner class
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
+ test/tools/javac/T8011181/EmptyUTF8ForInnerClassNameTest.java

RFR: 8009681: TEST_BUG: MethodExitReturnValuesTest.java fails with when there are unexpected background threads

[Mikael Auno]

Hi, I'd like some reviews on 
http://cr.openjdk.java.net/~nloodin/8009681/webrev.01/ for JDK-8009681 
(http://bugs.sun.com/view_bug.do?bug_id=8009681).


The issue here is that when MethodExitReturnValuesTest hooks into 
MethodExit events through JDI it uses an exclude list to filter out 
classes from which it is not interested in these events. This is bound 
to break over and over again as new features are added to the JDK. I've 
changed the test to use an include list instead, containing only the 
handful of classes the test is actually interested in.


Thanks,
Mikael

Re: Proxy.isProxyClass scalability

[Peter Levart]

Hi Mandy,

Here's the updated webrev:

https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.02/index.html

This adds TwoLevelWeakCache to the scene with following performance 
compared to other alternatives:


Summary (4 Cores x 2 Threads i7 CPU):

Test Threads  ns/op Original Patch(CL field)  
FlattenedWeakCache  TwoLevelWeakCache
===  ===  == ===  
==  =
Proxy_getProxyClass1 2,403.27   163.70  
206.88 252.89
   4 3,039.01   202.77  
303.38 327.62
   8 5,193.58   314.47  
442.58 510.63


Proxy_isProxyClassTrue 1 95.0210.78   
41.85  42.03
   4 2,266.29
10.80   42.32  42.07
   8 4,782.29
20.53   72.29  69.25


Proxy_isProxyClassFalse1 95.02 1.36
1.36   1.36
   4 2,186.59 
1.361.37   1.40
   8 4,891.15 
2.722.94   2.72


Annotation_equals  1 240.10   152.29  
193.27 200.45
   4 1,864.06   153.81  
195.60 202.45
   8 8,639.20   262.09  
384.72 338.70



As expected, the Proxy.getProxyClass() is yet a little slower than with 
FlattenedWeakCache, but still much faster than original Proxy 
implementation. Another lookup in the ConcurrentHashMap and another 
indirection have a price, but we also get something in return - space.


This is all obtained on latest lambda build (with new segment-less 
ConcurrentHashMap). I also added another ClassLoader to see what happens 
when the 2nd is added to the cache:


# Original Proxy, 32 bit addressing

class proxy size of   delta to
loaders   classes   cachesprev.ln.
      
   0 0   400   400
   1 1   768   368
   1 2   920   152
   1 3  1072   152
   1 4  1224   152
   1 5  1376   152
   1 6  1528   152
   1 7  1680   152
   1 8  1832   152
   1 9  1984   152
   110  2136   152
   211  2456   320
   212  2672   216
   213  2824   152
   214  2976   152
   215  3128   152
   216  3280   152
   217  3432   152
   218  3584   152
   219  3736   152
   220  3888   152

# Original Proxy, 64 bit addressing

class proxy size of   delta to
loaders   classes   cachesprev.ln.
      
   0 0   632   632
   1 1  1216   584
   1 2  1448   232
   1 3  1680   232
   1 4  1912   232
   1 5  2144   232
   1 6  2376   232
   1 7  2608   232
   1 8  2840   232
   1 9  3072   232
   110  3304   232
   211  3832   528
   212  4192   360
   213  4424   232
   214  4656   232
   215  4888   232
   216  5120   232
   217  5352   232
   218  5584   232
   219  5816   232
   220  6048   232

# Patched Proxy (FlattenedWeakCache), 32 bit addressing

class proxy size of   delta to
loaders   classes   cachesprev.ln.
      
   0 0   240   240
   1 1   584   344
   1 2   768   184
   1 3   952   184
   1 4  1136   184
   1 5  1320   184
   1 6  1504   184
   1 7  1688   184
   1 8  1872   184
   1 9  2056   184
   110  2240   184
   211  2424   184
   212  2736   312
   213  2920   184
   214  3104   184
   215  3288   184
   216  3472   184
   217  3656   184
   218  3840   184
   2

Re: RFR: String.join(), StringJoiner additions

[Jim Gish]

I'm going to rip out the  then.  It's an unnecessary burden.
Thanks
   Jim

On 04/16/2013 06:50 PM, Mike Duigou wrote:

On Apr 16 2013, at 08:50 , Alan Bateman wrote:


On 16/04/2013 16:13, Jim Gish wrote:

On 04/15/2013 02:02 PM, Martin Buchholz wrote:

You are fiddling with the javadoc for getChars, which is an independent change.  (I 
am also fiddling with getChars in another ongoing change).  I don't think closing 
html tags for  are required in javadoc.  If you are going to change the 
exception javadoc, then also change @exception to @throws.


The only reason I'm adding  is Alan insisted on it in a previous change I 
proposed :-)


I don't recall the full context but I have got confused by an early build of 
doclint where this was an issue.

 is required by XHTML but not by HTML. doclint was too aggressive about 
this in early builds.

Having  does no harm but it's not required.

Mike


-Alan.


--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com

hg: jdk8/tl/jdk: 12 new changesets

[vincent . x . ryan]

Changeset: 473ed4b94306
Author:vinnie
Date:  2013-04-11 17:57 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/473ed4b94306

7171982: Cipher getParameters() throws RuntimeException: Cannot find SunJCE 
provider
Reviewed-by: vinnie, wetmore
Contributed-by: Tony Scarpino 

! src/share/classes/com/sun/crypto/provider/CipherCore.java
! src/share/classes/com/sun/crypto/provider/CipherWithWrappingSpi.java
! src/share/classes/com/sun/crypto/provider/ConstructKeys.java
! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java
! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java
! src/share/classes/com/sun/crypto/provider/KeyProtector.java
! src/share/classes/com/sun/crypto/provider/PBECipherCore.java
! src/share/classes/com/sun/crypto/provider/PBES1Core.java
! src/share/classes/com/sun/crypto/provider/PBES2Core.java
! src/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java
! src/share/classes/com/sun/crypto/provider/RSACipher.java
! src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java
! src/share/classes/com/sun/crypto/provider/SunJCE.java
+ test/com/sun/crypto/provider/Cipher/UTIL/SunJCEGetInstance.java

Changeset: a6ca7cd399b2
Author:vinnie
Date:  2013-04-11 18:00 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6ca7cd399b2

8001596: Incorrect condition check in PBKDF2KeyImpl.JAVA
Reviewed-by: wetmore
Contributed-by: Tony Scarpino 

! src/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
+ test/com/sun/crypto/provider/Cipher/PBE/NegativeLength.java

Changeset: 747a09471fd9
Author:erikj
Date:  2013-04-11 14:47 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/747a09471fd9

8011812: JDK-8011278 breaks the old build
Reviewed-by: tbell, wetmore

! make/sun/splashscreen/Makefile

Changeset: 793e0072bfd6
Author:wetmore
Date:  2013-04-11 17:29 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/793e0072bfd6

8012056: SunJCEInstance needs to run in it's own vm
Reviewed-by: wetmore
Contributed-by: anthony.scarp...@oracle.com

! test/com/sun/crypto/provider/Cipher/UTIL/SunJCEGetInstance.java

Changeset: d8d037a7569e
Author:xuelei
Date:  2013-04-11 18:57 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8d037a7569e

8011680: Re-integrate AEAD implementation of JSSE
Summary: It is a re-merge of JDK-7030966.
Reviewed-by: wetmore

! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java
! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java
! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java
! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java
+ src/share/classes/sun/security/ssl/Authenticator.java
! src/share/classes/sun/security/ssl/CipherBox.java
! src/share/classes/sun/security/ssl/CipherSuite.java
! src/share/classes/sun/security/ssl/EngineInputRecord.java
! src/share/classes/sun/security/ssl/EngineOutputRecord.java
! src/share/classes/sun/security/ssl/EngineWriter.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/InputRecord.java
! src/share/classes/sun/security/ssl/JsseJce.java
! src/share/classes/sun/security/ssl/MAC.java
! src/share/classes/sun/security/ssl/OutputRecord.java
! src/share/classes/sun/security/ssl/Record.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! test/sun/security/ec/TestEC.java
! test/sun/security/pkcs11/fips/CipherTest.java
! test/sun/security/pkcs11/sslecc/CipherTest.java
! 
test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java
+ test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java
! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java
! test/sun/security/ssl/sanity/interop/CipherTest.java
! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java

Changeset: ea7976ed9bc6
Author:wetmore
Date:  2013-04-11 19:36 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea7976ed9bc6

Merge


Changeset: 0f93bd5cc8d7
Author:wetmore
Date:  2013-04-11 21:03 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f93bd5cc8d7

6425477: Better support for generation of high entropy random numbers
Reviewed-by: xuelei, weijun, mullan

! src/share/classes/java/security/SecureRandom.java
! src/share/classes/sun/security/pkcs11/P11SecureRandom.java
! src/share/classes/sun/security/provider/SecureRandom.java
! src/share/classes/sun/security/provider/SeedGenerator.java
! src/share/classes/sun/security/provider/SunEntries.java
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! src/solaris/classes/sun/security/provider/NativePRNG.java
! src/solaris/classes/sun/security/provid

hg: jdk8/tl/jdk: 8012019: (fc) Thread.interrupt triggers hang in FileChannelImpl.pread (win)

[alan . bateman]

Changeset: 7ded74ffea36
Author:alanb
Date:  2013-04-17 16:11 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ded74ffea36

8012019: (fc) Thread.interrupt triggers hang in FileChannelImpl.pread (win)
Reviewed-by: chegar

! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java
! src/share/classes/sun/nio/ch/IOUtil.java
! src/share/classes/sun/nio/ch/NativeDispatcher.java
! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java
! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java
! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java
+ test/java/nio/channels/FileChannel/InterruptDeadlock.java

RFR: JDK-8005954: JAXP Plugability Layer should use java.util.ServiceLoader

[Daniel Fuchs]

Hi,

These changes correspond to the changes that have been already reviewed
under the umbrella name of JDK-7169894 (which was closed & cloned into
JDK-8005954 for administrative reasons) - re-based on the latest jdk8-tl
forest tip.

So this is basically JDK-7169894, re-based & merged at the tip - with
small additional editorial changes (like e.g. fixing the copyright
years). The merging was not completely trivial - hence the new
RFR.



Previously reviewed changes can be browsed at [1].

best regards,

-- daniel


[1] previously reviewed webrevs

Re: RFR: JDK-8005954: JAXP Plugability Layer should use java.util.ServiceLoader

[Alan Bateman]

On 17/04/2013 16:41, Daniel Fuchs wrote:

Hi,

These changes correspond to the changes that have been already reviewed
under the umbrella name of JDK-7169894 (which was closed & cloned into
JDK-8005954 for administrative reasons) - re-based on the latest jdk8-tl
forest tip.

So this is basically JDK-7169894, re-based & merged at the tip - with
small additional editorial changes (like e.g. fixing the copyright
years). The merging was not completely trivial - hence the new
RFR.



Previously reviewed changes can be browsed at [1].

best regards,

-- daniel
I've skimmed through the new webrev and it looks like the changes that 
we agreed over many iterations back in January. Are there any specific 
areas of the merge that need attention? (I didn't see any).  Overall 
it's very good work and it will be nice to get this in.


-Alan.

Re: RFR: JDK-8005954: JAXP Plugability Layer should use java.util.ServiceLoader

[Daniel Fuchs]

On 4/17/13 6:30 PM, Alan Bateman wrote:

On 17/04/2013 16:41, Daniel Fuchs wrote:

Hi,

These changes correspond to the changes that have been already reviewed
under the umbrella name of JDK-7169894 (which was closed & cloned into
JDK-8005954 for administrative reasons) - re-based on the latest jdk8-tl
forest tip.

So this is basically JDK-7169894, re-based & merged at the tip - with
small additional editorial changes (like e.g. fixing the copyright
years). The merging was not completely trivial - hence the new
RFR.



Previously reviewed changes can be browsed at [1].

best regards,

-- daniel

I've skimmed through the new webrev and it looks like the changes that
we agreed over many iterations back in January. Are there any specific
areas of the merge that need attention? (I didn't see any).  Overall
it's very good work and it will be nice to get this in.


Most of the merge troubles were in the FactoryFinder.java
and XxxxFactoryFinder.java files - the merge was a bit difficult because 
some lines had changes in both parent and child - like

method signature where a  had been added to the return type
in the child and a new argument had been added in the parent.

In transform/FactoryFinder I had removed a boolean from the
newInstance(...) methods - and that caused a merge issue too
which had to be resolved carefully.
(originally requested by Mandy who noticed that the method
 was always called with the same boolean value - and therefore
 did not need that boolean has argument).

Merge in the other files was otherwise trivial.

-- daniel



-Alan.

Request for review of 8009648 Tests fail in -agentvm -concurrency mode

[roger riggs]

As noted in  8009648: Tests fail in -agentvm -concurrency mode
there are several tests that fail in agentvm mode, adding the directories
with the sensitive tests to othervms.dir speeds up testing and the tests 
pass.

Please review.

http://cr.openjdk.java.net/~rriggs/webrev-testconcurrency/

Re: RFR: 8009681: TEST_BUG: MethodExitReturnValuesTest.java fails with when there are unexpected background threads

[serguei.spit...@oracle.com]

Hi Mikael,

It looks good.
Thank you for figuring out how to make it more stable!

BTW, the webrev frames mode does not work.

Thanks,
Serguei

On 4/17/13 6:03 AM, Mikael Auno wrote:
Hi, I'd like some reviews on 
http://cr.openjdk.java.net/~nloodin/8009681/webrev.01/ for JDK-8009681 
(http://bugs.sun.com/view_bug.do?bug_id=8009681).


The issue here is that when MethodExitReturnValuesTest hooks into 
MethodExit events through JDI it uses an exclude list to filter out 
classes from which it is not interested in these events. This is bound 
to break over and over again as new features are added to the JDK. 
I've changed the test to use an include list instead, containing only 
the handful of classes the test is actually interested in.


Thanks,
Mikael

Re: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed

[Joe Darcy]

On 04/14/2013 07:36 PM, Joe Darcy wrote:

On 04/12/2013 07:29 PM, Jason Mehrens wrote:

Joe,
You'll have guard ise.addSuppressed against null.  Looks good otherwise.

private static void initCauseNull() {
  Throwable t1 = new Throwable();
  t1.initCause(null);
  try {
t1.initCause(null);
  } catch(IllegalStateException expect) {
  }
}


Right you are; check added and test updated in:

http://cr.openjdk.java.net/~darcy/8012044.2/

Full patch to Throwable:


[snip]

One more iteration; I've changed the initCause logic to suppress both 
exceptions rather than using one as the cause:


 http://cr.openjdk.java.net/~darcy/8012044.2

Patch to throwable:

--- old/src/share/classes/java/lang/Throwable.java2013-04-14 
19:33:23.0 -0700
+++ new/src/share/classes/java/lang/Throwable.java2013-04-14 
19:33:23.0 -0700

@@ -452,10 +452,15 @@
  * @since  1.4
  */
 public synchronized Throwable initCause(Throwable cause) {
-if (this.cause != this)
-throw new IllegalStateException("Can't overwrite cause");
+if (this.cause != this) {
+IllegalStateException ise =
+new IllegalStateException("Can't overwrite cause", this);
+if (cause != null)
+ise.addSuppressed(cause);
+throw ise;
+}
 if (cause == this)
-throw new IllegalArgumentException("Self-causation not 
permitted");
+throw new IllegalArgumentException("Self-causation not 
permitted", this);

 this.cause = cause;
 return this;
 }
@@ -1039,7 +1044,7 @@
  */
 public final synchronized void addSuppressed(Throwable exception) {
 if (exception == this)
-throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE);
+throw new 
IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception);


 if (exception == null)
 throw new NullPointerException(NULL_CAUSE_MESSAGE);

The suppression mechanism is typically, but not exclusively, used by the 
try-with-resources statement.


Thanks,

-Joe

Re: Request for review of 8009648 Tests fail in -agentvm -concurrency mode

[Alan Bateman]

On 17/04/2013 18:00, roger riggs wrote:

As noted in  8009648: Tests fail in -agentvm -concurrency mode
there are several tests that fail in agentvm mode, adding the directories
with the sensitive tests to othervms.dir speeds up testing and the 
tests pass.

Please review.

http://cr.openjdk.java.net/~rriggs/webrev-testconcurrency/

This looks good and I can sponsor it for you.

-Alan.

Re: [PATCH] Review Request for 8009258: TEST_BUG: java/io/pathNames/GeneralWin32.java fails intermittently

[Dan Xu]

On 04/17/2013 02:15 AM, Alan Bateman wrote:

On 17/04/2013 07:36, Dan Xu wrote:

:

In the changes, the usages of NIO classes are not necessary. The test 
is against java.io packages, and it is better to keep it clean in 
case it might be used to test old jdk version which does not have NIO.


I briefly looked at it and I think the usage okay is because it just 
makes it easier to check the results and also to keep the directory 
walk from wandering into other parts of the file system. If it changed 
what was being tested then I would agree that it shouldn't be used.


-Alan

I see. My thought is that the relative path between baseDir and userDir 
can be calculated inside initTestData() when it constructs the baseDir. 
But I agree it is not an issue here. Thanks!


-Dan

hg: jdk8/tl/jdk: 8010953: Add primitive summary statistics utils

[mike . duigou]

Changeset: d9f9040554d6
Author:mduigou
Date:  2013-04-17 11:39 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d9f9040554d6

8010953: Add primitive summary statistics utils
Reviewed-by: mduigou, dholmes, chegar, darcy
Contributed-by: Brian Goetz 

+ src/share/classes/java/util/DoubleSummaryStatistics.java
+ src/share/classes/java/util/IntSummaryStatistics.java
+ src/share/classes/java/util/LongSummaryStatistics.java

hg: jdk8/tl/jdk: 8004260: dynamic proxy class should have the same Java language access as the proxy interfaces

[mandy . chung]

Changeset: 73e3b474125e
Author:mchung
Date:  2013-04-17 12:04 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/73e3b474125e

8004260: dynamic proxy class should have the same Java language access as the 
proxy interfaces
Reviewed-by: alanb, jrose, jdn

! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/java/lang/reflect/ReflectPermission.java
! src/share/classes/sun/misc/ProxyGenerator.java
! src/share/classes/sun/reflect/annotation/AnnotationParser.java
! src/share/classes/sun/rmi/server/Util.java
! src/share/classes/sun/tracing/ProviderSkeleton.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/NonPublicProxyClass.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/SimpleProxy.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/p/Bar.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/p/Foo.java
! test/java/rmi/server/RMIClassLoader/loadProxyClasses/security.policy

Re: RFR: String.join(), StringJoiner additions

[Mike Duigou]

String::

line 1253: This should use {@code } rather than . I think regular 
spaces are OK as well.   seems inappropriate.

lines 2425/2467: elements may not be null either.

I can tell you (or maybe it's just me) are itching to change :

for (CharSequence cs: elements) {
2477 joiner.add(cs);
2478 }

to:

elements.forEach(joiner::add);

StringJoiner::

-  isn't needed around  as it's already a  you probably 
mean to do 

 {@code 
... 
}

for code samples.

- It would be nice if the empty output generation in three arg constructor 
could be suppressed unless needed. Perhaps a special (not null please!) 
sentinel value?

- Four arg constructor doesn't include emptyOutput in @throws NPE


On Apr 11 2013, at 15:33 , Jim Gish wrote:

> Please review http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/ 
> 
> 
> These are changes that we made in lambda that we're now bringing into JDK8.
> 
> I've made a couple of additions - making StringJoiner final and adding a 
> couple of constructors to set the emptyOutput chars.
> 
> Thanks,
>   Jim
> 
> -- 
> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
> Oracle Java Platform Group | Core Libraries Team
> 35 Network Drive
> Burlington, MA 01803
> jim.g...@oracle.com
> 

RFR: JDK-8011917 (java.util.stream.Collectors)

[Brian Goetz]

Single new source file at:

http://hg.openjdk.java.net/lambda/lambda/jdk/file/76ac19e61df1/src/share/classes/java/util/stream/Collectors.java

Doc at:

http://cr.openjdk.java.net/~briangoetz/JDK-8008682/api/java/util/stream/Collectors.html

for JDK-8011917 (Collectors class in java.util.stream).

(No webrev as there's just one new file.)

hg: jdk8/tl/jdk: 2 new changesets

[coleen . phillimore]

Changeset: 7f9f69729934
Author:coleenp
Date:  2013-04-17 12:50 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7f9f69729934

8009531: Crash when redefining class with annotated method
Summary: Add code to annotated methods and command line flags to the tests to 
verify bug above
Reviewed-by: acorn, sspitsyn, dcubed, dholmes, alanb

! test/java/lang/instrument/RedefineMethodWithAnnotations.sh
! test/java/lang/instrument/RedefineMethodWithAnnotationsTarget.java
! test/java/lang/instrument/RedefineMethodWithAnnotationsTarget_2.java

Changeset: 36f9e357b84b
Author:coleenp
Date:  2013-04-17 15:06 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36f9e357b84b

Merge

hg: jdk8/tl/langtools: 2 new changesets

[lana . steuck]

Changeset: 1f19b84efa6d
Author:lana
Date:  2013-04-16 08:16 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1f19b84efa6d

Merge

- src/share/classes/com/sun/tools/javac/util/CloseableURLClassLoader.java
- test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java
- test/tools/javac/lambda/Intersection01.out
- test/tools/javac/lambda/TargetType01.out

Changeset: 94870c08391c
Author:lana
Date:  2013-04-17 10:31 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/94870c08391c

Merge

hg: jdk8/tl/nashorn: 2 new changesets

[lana . steuck]

Changeset: 35881a9d0fc2
Author:lana
Date:  2013-04-16 08:16 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/35881a9d0fc2

Merge

- test/script/basic/JDK-8017010.js
- test/script/basic/JDK-8017010.js.EXPECTED

Changeset: 44d8612e29b0
Author:lana
Date:  2013-04-17 10:31 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/44d8612e29b0

Merge

hg: jdk8/tl/hotspot: 19 new changesets

[lana . steuck]

Changeset: e437668ced9d
Author:amurillo
Date:  2013-04-11 01:14 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e437668ced9d

8011948: new hotspot build - hs25-b28
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 68fe50d4f1d5
Author:johnc
Date:  2013-04-05 10:20 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/68fe50d4f1d5

8011343: Add new flag for verifying the heap during startup
Summary: Perform verification during VM startup under control of new flag and 
within a VMOperation.
Reviewed-by: stefank, jmasa, brutisso

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/runtime/vm_operations.hpp
- test/gc/TestVerifyBeforeGCDuringStartup.java
+ test/gc/TestVerifyDuringStartup.java

Changeset: 8617e38bb4cb
Author:jmasa
Date:  2013-02-11 10:31 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8617e38bb4cb

8008508: CMS does not correctly reduce heap size after a Full GC
Reviewed-by: johnc, ysr

! 
src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! 
src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/memory/generation.cpp
! src/share/vm/memory/generation.hpp
! src/share/vm/memory/tenuredGeneration.cpp
! src/share/vm/memory/tenuredGeneration.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 83f27710f5f7
Author:brutisso
Date:  2013-04-08 07:49 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/83f27710f5f7

7197666: java -d64 -version core dumps in a box with lots of memory
Summary: Allow task queues to be mmapped instead of malloced on Solaris
Reviewed-by: coleenp, jmasa, johnc, tschatzl

! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/taskqueue.hpp

Changeset: 63f57a8c5283
Author:mgerdin
Date:  2013-04-09 15:32 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/63f57a8c5283

8009808: TEST-BUG : test case is using bash style tests. Default shell for 
jtreg is bourne. thus failure
Summary: Rewrite test to use Java only instead of shell script
Reviewed-by: mgerdin, brutisso
Contributed-by: leonid.mes...@oracle.com

+ test/gc/6941923/Test6941923.java
- test/gc/6941923/test6941923.sh

Changeset: ba42fd5e00e6
Author:mgerdin
Date:  2013-04-10 13:27 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ba42fd5e00e6

8010196: NPG: Internal Error: Metaspace allocation lock -- possible deadlock
Summary: Refactor the CLD dependency list into a separate class. Use an 
ObjectLocker to synchronize additions to the CLD dependency list.
Reviewed-by: stefank, coleenp

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
+ test/gc/metaspace/G1AddMetaspaceDependency.java

Changeset: 7b835924c31c
Author:stefank
Date:  2013-04-10 14:26 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b835924c31c

8011872: Include Bit Map addresses in the hs_err files
Reviewed-by: brutisso, jmasa

! 
src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! 
src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/utilities/bitMap.cpp
! src/share/vm/utilities/bitMap.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 480d934f62a8
Author:mgerdin
Date:  2013-04-11 16:35 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/480d934f62a8

Merge

! src/share/vm/runtime/arguments.cpp
- test/runtime/NMT/AllocTestType.java

Changeset: 705ef39fcaa9
Author:neliasso
Date:  2013-04-05 11:09 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/705ef39fcaa9

8006016: Memory leak at hotspot/src/share/vm/adlc/output_c.cpp
Reviewed-by: kvn, roland
Contributed-by: niclas.adle...@oracle.com

! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp

Changeset: f67065f02409
Author:bharadwaj
Date:  2013-04-08 07:40 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/hotspot/rev

hg: jdk8/tl/jaxws: 2 new changesets

[lana . steuck]

Changeset: a5e7c2f093c9
Author:lana
Date:  2013-04-16 08:11 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/a5e7c2f093c9

Merge

- 
src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/DefaultAuthenticator.java
- 
src/share/jaxws_classes/com/sun/tools/internal/xjc/api/impl/j2s/JAXBModelImpl.java
- 
src/share/jaxws_classes/com/sun/tools/internal/xjc/api/impl/j2s/JavaCompilerImpl.java
- 
src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/OverrideAnnotationOfWriter.java
- 
src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/XmlIsSetWriter.java
- 
src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/ri/XmlLocationWriter.java
- 
src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/output/InPlaceDOMOutput.java
- src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/EnvelopeStyle.java
- 
src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/EnvelopeStyleFeature.java
- 
src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/Databinding.java
- 
src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingFactory.java
- 
src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingMode.java
- 
src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/DatabindingModeFeature.java
- 
src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/databinding/JavaCallInfo.java
- 
src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/ContentType.java
- 
src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/DistributedPropertySet.java
- 
src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/MessageContext.java
- 
src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/MessageContextFactory.java
- 
src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/ws/message/PropertySet.java
- 
src/share/jaxws_classes/com/sun/xml/internal/ws/util/ReadOnlyPropertyException.java
- 
src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/Localizable.java
- 
src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableImpl.java
- 
src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableMessage.java
- 
src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/LocalizableMessageFactory.java
- 
src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/Localizer.java
- 
src/share/jaxws_classes/com/sun/xml/internal/ws/util/localization/NullLocalizable.java

Changeset: ebbd87e3a8b2
Author:lana
Date:  2013-04-17 10:13 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/ebbd87e3a8b2

Merge

hg: jdk8/tl/jdk: 16 new changesets

[lana . steuck]

Changeset: 87c62f03bc07
Author:jgodinez
Date:  2013-03-27 12:42 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/87c62f03bc07

8010005: [parfait] Memory leak in jdk/src/macosx/native/sun/awt/CTextPipe.m
Reviewed-by: bae, prr
Contributed-by: jia-hong.c...@oracle.com

! src/macosx/native/sun/awt/CTextPipe.m

Changeset: 9d4f539e36b6
Author:lana
Date:  2013-04-02 17:03 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d4f539e36b6

Merge

- make/com/sun/servicetag/Makefile
- src/share/classes/com/sun/servicetag/BrowserSupport.java
- src/share/classes/com/sun/servicetag/Installer.java
- src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java
- src/share/classes/com/sun/servicetag/RegistrationData.java
- src/share/classes/com/sun/servicetag/RegistrationDocument.java
- src/share/classes/com/sun/servicetag/Registry.java
- src/share/classes/com/sun/servicetag/ServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisServiceTag.java
- src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java
- src/share/classes/com/sun/servicetag/SunConnection.java
- src/share/classes/com/sun/servicetag/SystemEnvironment.java
- src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java
- src/share/classes/com/sun/servicetag/Util.java
- src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java
- src/share/classes/com/sun/servicetag/package.html
- src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt
- src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties
- src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties
- src/share/classes/com/sun/servicetag/resources/jdk_header.png
- src/share/classes/com/sun/servicetag/resources/product_registration.xsd
- src/share/classes/com/sun/servicetag/resources/register.html
- src/share/classes/com/sun/servicetag/resources/register_ja.html
- src/share/classes/com/sun/servicetag/resources/register_zh_CN.html
- test/com/sun/servicetag/DeleteServiceTag.java
- test/com/sun/servicetag/DuplicateNotFound.java
- test/com/sun/servicetag/FindServiceTags.java
- test/com/sun/servicetag/InstanceUrnCheck.java
- test/com/sun/servicetag/InvalidRegistrationData.java
- test/com/sun/servicetag/InvalidServiceTag.java
- test/com/sun/servicetag/JavaServiceTagTest.java
- test/com/sun/servicetag/JavaServiceTagTest1.java
- test/com/sun/servicetag/NewRegistrationData.java
- test/com/sun/servicetag/SvcTagClient.java
- test/com/sun/servicetag/SystemRegistryTest.java
- test/com/sun/servicetag/TestLoadFromXML.java
- test/com/sun/servicetag/UpdateServiceTagTest.java
- test/com/sun/servicetag/Util.java
- test/com/sun/servicetag/ValidRegistrationData.java
- test/com/sun/servicetag/environ.properties
- test/com/sun/servicetag/missing-environ-field.xml
- test/com/sun/servicetag/newer-registry-version.xml
- test/com/sun/servicetag/registration.xml
- test/com/sun/servicetag/servicetag1.properties
- test/com/sun/servicetag/servicetag2.properties
- test/com/sun/servicetag/servicetag3.properties
- test/com/sun/servicetag/servicetag4.properties
- test/com/sun/servicetag/servicetag5.properties
- test/sun/tools/jstat/gcPermCapacityOutput1.awk
- test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh

Changeset: 2904672aed21
Author:lana
Date:  2013-04-09 14:59 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2904672aed21

Merge


Changeset: 96750ebc769b
Author:denis
Date:  2013-03-27 16:19 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96750ebc769b

7075105: WIN: Provide a way to format HTML on drop
Reviewed-by: uta, serb

! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java
! src/share/classes/java/awt/datatransfer/DataFlavor.java
! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java
! src/share/classes/sun/awt/datatransfer/DataTransferer.java
! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java
! src/solaris/classes/sun/awt/X11/XDataTransferer.java
! src/windows/classes/sun/awt/windows/WDataTransferer.java
+ test/java/awt/datatransfer/HTMLDataFlavors/HTMLDataFlavorTest.java
+ test/java/awt/datatransfer/HTMLDataFlavors/HtmlTransferable.java
+ test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.html
+ test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.java
+ test/java/awt/datatransfer/HTMLDataFlavors/PutAllHtmlFlavorsOnClipboard.java
+ 
test/java/awt/datatransfer/HTMLDataFlavors/PutOnlyAllHtmlFlavorOnClipboard.java
+ 
test/java/awt/datatransfer/HTMLDataFlavors/PutSelectionAndFragmentHtmlFlavorsOnClipboard.java

Changeset: 29570523b6cb
Author:ant
Date:  2013-03-29 16:12 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29570523b6cb

8010375: sun.swing.JLightweightFrame should be implemented for XToolkit
Reviewed-by: anthony

! src/share/classes/sun/sw

Re: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

[Laurent Bourgès]

Jim,

thanks for having some interest for my efforts !
As I got almost no feedback, I felt quite disappointed and was thinking
that improving pisces was not important ...

Here are ductus results and comparison (open office format):
http://jmmc.fr/~bourgesl/share/java2d-pisces/ductus_det.log
http://jmmc.fr/~bourgesl/share/java2d-pisces/compareRef_Patch.ods

   test threads ops Tavg Tmed stdDev rms *Med+Stddev* min max  boulder_17 1
20 73,92% 69,34% 27,98% 69,34% *69,14%* 69,81% 146,89%  boulder_17 2 20
110,86% 110,48% 613,80% 112,01% *125,43%* 94,71% 136,35%  boulder_17 4 20
135,28% 135,86% 226,61% 136,46% *141,85%* 125,14% 111,32%  shp_alllayers_47
1 20 82,25% 82,49% 47,50% 82,48% *82,30%* 82,64% 78,08%  shp_alllayers_47 2
20 115,87% 115,67% 315,45% 115,85% *119,89%* 109,33% 128,71%
shp_alllayers_47 4 20 218,59% 218,76% 169,38% 218,65% *216,45%* 220,17%
206,17%
Ductus vs Patch
   *1* *80,74%*  *2* *120,69%*  *4* *205,92%*
Reminder: Ref vs Patch
   *1* *237,71%*  *2* *271,68%*  *4* *286,15%*

Note: I only have 2 cores + HT on my laptop and do not test with more
threads (64 like andrea).

2013/4/16 Jim Graham 

> If I'm reading this correctly, your patch is faster even for a single
> thread?  That's great news.
>

Not yet, but ductus is now only 20% faster than my patch and 20% and 2x
slower with 2 and 4 threads :
I still hope to beat it applying few more optimizations:
- Renderer.ScanLine iterator / Renderer.endRendering can be improved
- avoid few more array zero fill (reset) if possible
- adding statistics to better set initial array sizes ...
- use SunGraphics2D to hold an hard reference (temporarly) on
RendererContext (to avoid many ThreadLocal.get())
- cache eviction (WeakReference or SoftReference) ?

Why not use divide and conquer (thread pool) to boost single thread
rendering if the machine has more cpu cores ?
It would be helpful if the AATileGenerator has access to SunGraphics2D to
get rendering hints or share variables (cache ...)

For the moment, I did not modify the algorithms itself but I will do it to
enhance clipping (dasher segments / stroker) ...


> One of the problems we've had with replacing Ductus is that it has been
> faster in a single thread situation than the open source versions we've
> created.  One of its drawbacks is that it had been designed to take
> advantage of some AA-accelerating hardware that never came to be.  With the
> accelerator it would have been insanely fast, but hardware went in a
> different direction.  The problem was that this early design goal caused
> the entire library to be built around an abstraction layer that allowed for
> a single "tile producer" internally (because there would be only one -
> insanely fast - hardware chip available) and the software version of the
> abstraction layer thus had a lot of native "static" data structures
> (there's only one of me, right?) that prevented MT access.  It was probably
> solvable, but I'd be happier if someone could come up with a faster
> rasterizer, imagining that there must have been some sort of advancements
> in the nearly 2 decades since the original was written.
>
> If I'm misinterpreting and single thread is still slower than Ductus (or
> if it is still slower on some other platforms), then .
>

Not yet: slower than ductus by 20% but faster than current pisces by 2
times !


> Also, this is with the Java version, right?


Yes, my patch is pure java given as webrev:
http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/


> We got a decent 2x speedup in FX by porting the version of Open Pisces
> that you started with to C code (all except on Linux where we couldn't find
> the right gcc options to make it faster than Hotspot).  So, we have yet to
> investigate a native version in the JDK which might provide even more
> gains...
>

Personally I prefer working on java code as hotspot can perform so much
optimizations for free and no pointers to deal with and more important:
concurrent primitives (thread local, collections) !

Laurent


>
> On 4/15/13 3:01 AM, Laurent Bourgčs wrote:
>
>> Jim, Andrea,
>>
>> I updated MapBench to provide test statistics (avg, median, stddev, rms,
>> med + stddev, min, max) and CSV output (tab separator):
>> http://jmmc.fr/~bourgesl/**share/java2d-pisces/MapBench/
>> 
>> >
>>
>>
>>
>> Here are the results (OpenJDK8 Ref vs Patched):
>> http://jmmc.fr/~bourgesl/**share/java2d-pisces/ref_det.**log
>> http://jmmc.fr/~bourgesl/**share/java2d-pisces/patch_det.**log
>>
>> testthreads ops TavgTmedstdDev  rms
>> Med+Stddev  min max
>> boulder_17  1   20  180,22% 181,08% 1186,01%
>>181,17% 185,92%
>> 176,35%

RE: Code review request for 8012044: Give more information about self-suppression from Throwable.addSuppressed

[Jason Mehrens]

Joe,

The patch at http://cr.openjdk.java.net/~darcy/8012044.3/ looks good to me.  
Thanks for working on this.

Jason
 

> Date: Wed, 17 Apr 2013 10:32:10 -0700
> From: joe.da...@oracle.com
> To: jason_mehr...@hotmail.com
> CC: core-libs-dev@openjdk.java.net; david.hol...@oracle.com
> Subject: Re: Code review request for 8012044: Give more information about 
> self-suppression from Throwable.addSuppressed
>
> On 04/14/2013 07:36 PM, Joe Darcy wrote:
> > On 04/12/2013 07:29 PM, Jason Mehrens wrote:
> >> Joe,
> >> You'll have guard ise.addSuppressed against null. Looks good otherwise.
> >>
> >> private static void initCauseNull() {
> >> Throwable t1 = new Throwable();
> >> t1.initCause(null);
> >> try {
> >> t1.initCause(null);
> >> } catch(IllegalStateException expect) {
> >> }
> >> }
> >
> > Right you are; check added and test updated in:
> >
> > http://cr.openjdk.java.net/~darcy/8012044.2/
> >
> > Full patch to Throwable:
>
> [snip]
>
> One more iteration; I've changed the initCause logic to suppress both
> exceptions rather than using one as the cause:
>
> http://cr.openjdk.java.net/~darcy/8012044.2
>
> Patch to throwable:
>
> --- old/src/share/classes/java/lang/Throwable.java 2013-04-14
> 19:33:23.0 -0700
> +++ new/src/share/classes/java/lang/Throwable.java 2013-04-14
> 19:33:23.0 -0700
> @@ -452,10 +452,15 @@
> * @since 1.4
> */
> public synchronized Throwable initCause(Throwable cause) {
> - if (this.cause != this)
> - throw new IllegalStateException("Can't overwrite cause");
> + if (this.cause != this) {
> + IllegalStateException ise =
> + new IllegalStateException("Can't overwrite cause", this);
> + if (cause != null)
> + ise.addSuppressed(cause);
> + throw ise;
> + }
> if (cause == this)
> - throw new IllegalArgumentException("Self-causation not
> permitted");
> + throw new IllegalArgumentException("Self-causation not
> permitted", this);
> this.cause = cause;
> return this;
> }
> @@ -1039,7 +1044,7 @@
> */
> public final synchronized void addSuppressed(Throwable exception) {
> if (exception == this)
> - throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE);
> + throw new
> IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception);
>
> if (exception == null)
> throw new NullPointerException(NULL_CAUSE_MESSAGE);
>
> The suppression mechanism is typically, but not exclusively, used by the
> try-with-resources statement.
>
> Thanks,
>
> -Joe

Re: [OpenJDK 2D-Dev] sun.java2D.Pisces renderer Performance and Memory enhancements

[Phil Race]

> whereas on Windows / Mac it is client compiler (c1).

For Mac we only have a 64 bit VM which SFAIK should be c2 as well,
yet in that case native was presumably still faster. So its also a matter
of factoring in how good the code is that is generated by the C compiler.

-phil.

On 4/17/2013 1:26 PM, Richard Bair wrote:



Also, this is with the Java version, right? 



Yes, my patch is pure java given as webrev:
http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/ 



We got a decent 2x speedup in FX by porting the version of Open
Pisces that you started with to C code (all except on Linux where
we couldn't find the right gcc options to make it faster than
Hotspot).  So, we have yet to investigate a native version in the
JDK which might provide even more gains… 



Oleg did more analysis on this and it appears the reason hotspot on 
Linux was faster than the C version was because on Linux it is -server 
compiler (c2) whereas on Windows / Mac it is client compiler (c1). 
Possibly using -server on windows / mac would also have hotspot 
beating the C version, although that hasn't been tested.


Richard

Re: Incorrect arguments is passed to sun.misc.Perf#createLong

[Mandy Chung]

Hi Yasumasa,

Thanks for the patch.  I'm going to sponsor your fix for 8011934 and 
will be pushing it shortly.

http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8011934/webrev.00/

Mandy

On 4/10/2013 6:59 PM, Yasu wrote:

Hi Mandy,

On 4:59, Mandy Chung wrote:

Hi Yasumasa,

I'm adding core-libs and bcc serviceability-dev to move this thread 
to core-libs for sun.misc.PerfCounter discussion.


On 4/9/2013 4:50 AM, Yasu wrote:

Hi,

I'm trying to create entry from Java program to hsperfdata through 
sun.misc.PerfCounter .


First of all, sun.misc.PerfCounter is a private API that is not 
supported and may be changed and removed in any future release. I'm 
curious how you create a counter in hsperfdata through 
sun.misc.PerfCounter. The constructor is private.


I've understood that sun.* packages is private API.
I use PerfCounter with reflection API ( setAccessible(true) )  .


However, I cannot watch the updated value in my entry through the 
jstat with interval option.


I guess this cause is that wrong arguments are passed from 
PerfCounter# to Perf#createLong .




Indeed - it's a bug that calls Perf.createLong with the incorrect 
parameters. I have filed a bug (8011934).


Thanks!



Have you signed the OCA [1]?


Yes.
I already sent OCA with my signature.


Thanks,

Yasumasa


Thanks
Mandy
[1] http://openjdk.java.net/contribute/


sun.misc.PerfCounter:
-
private PerfCounter(String name, int type) {
this.name = name;
ByteBuffer bb = perf.createLong(name, U_None, type, 0L);
bb.order(ByteOrder.nativeOrder());
this.lb = bb.asLongBuffer();
}
-

sun.misc.Perf:
-
public native ByteBuffer createLong(String name, int variability,
int units, long value);
-

"type" in constructor of PerfCounter means "variability".
So "type" should be set to 2nd argument in perf.createLong()

perf.createLong() should be called as following:
-
ByteBuffer bb = perf.createLong(name, type, U_None, 0L);
-


I've applied a patch which is attached in this email, it's works fine.


Thanks,

Yasumasa

Re: RFR: String.join(), StringJoiner additions

[Jim Gish]

Here's an update: 
http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/ 



Jim

On 04/17/2013 03:15 PM, Mike Duigou wrote:

String::

line 1253: This should use {@code } rather than . I think regular 
spaces are OK as well.   seems inappropriate.

lines 2425/2467: elements may not be null either.

I can tell you (or maybe it's just me) are itching to change :

for (CharSequence cs: elements) {
2477 joiner.add(cs);
2478 }

to:

elements.forEach(joiner::add);

StringJoiner::

-  isn't needed around  as it's already a  you probably 
mean to do

 {@code
...
}

for code samples.

- It would be nice if the empty output generation in three arg constructor 
could be suppressed unless needed. Perhaps a special (not null please!) 
sentinel value?

- Four arg constructor doesn't include emptyOutput in @throws NPE


On Apr 11 2013, at 15:33 , Jim Gish wrote:


Please review http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/ 


These are changes that we made in lambda that we're now bringing into JDK8.

I've made a couple of additions - making StringJoiner final and adding a couple 
of constructors to set the emptyOutput chars.

Thanks,
   Jim

--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com



--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com

Re: Use of super in type parameters

[Martin Buchholz]

With the coming of lambda, it is more likely that people will be creating
APIs with "not quite correct" generic types, as we are doing in
CompletableFuture.  Which is pretty bad for a feature that is designed
specifically to provide compile time safety.  It would be nice to at least
have an acknowledgment that there is a problem here, even if it will not be
fixed for this release.


On Mon, Apr 15, 2013 at 12:50 PM, Zhong Yu  wrote:

> I have encountered on stackoverflow.com several legit use cases of
> lower bound. And the other day Ali Lahijani raised the question that
> Stream.reduce(BinaryOperator) breaks convariance of Stream, and I
> thought that the root problem is lack of lower bound - the method
> would have had a better signature
> Stream
>  Optional reduce(BinaryOperator accumulator)
> So I don't think there's a lack of use cases for lower bound. (But I
> have no idea how difficult it is to support it)
>
> Zhong Yu
>
>
> On Mon, Apr 15, 2013 at 2:37 PM, Martin Buchholz 
> wrote:
> > CompletableFuture currently has a method like this:
> >
> > public CompletableFuture acceptEither
> > (CompletableFuture other,
> >  Consumer block) {
> > return doAcceptEither(other, block, null);
> > }
> >
> > But that signature is not quite correct (not as general as it could be).
> >  The "correct" signature is
> >
> > public  CompletableFuture acceptEither
> > (CompletableFuture other,
> >  Consumer block) {
> > return doAcceptEither(other, block, null);
> > }
> >
> > but that fails to compile, because type parameters can only be
> constrained
> > by extends, not super.  Is implementing this on the radar?  Angelika
> claims
> > "lower bounds for type parameters make no sense"
> >
> http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#Why%20is%20there%20no%20lower%20bound%20for%20type%20parameters
> > ?
> >
> > but I am finding that hard to believe.  Is she right? For comparison,
>  the
> > equivalent static method can be made to do what we want:
> >
> > public static  CompletableFuture acceptEither
> > (CompletableFuture f,
> >  CompletableFuture other,
> >  Consumer block) {
> > return ...
> > }
>

Re: RFR: String.join(), StringJoiner additions

[Martin Buchholz]

I'm still wondering about whether a joiner utility should support a prefix
and suffix.  The obvious uses for this are collection class toString
methods, but we already know that we can and should implement those with a
single precise char[] construction, so should not use StringJoiner, or at
least not this StringJoiner implementation.  And if we're just talking
about pure convenience, it's hard to beat

"[" + String.join(...) + "]"


On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish  wrote:

> Here's an update: http://cr.openjdk.java.net/~**
> jgish/Bugs-5015163-7172553/<
> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7172553/
> >
>
> Jim
>
>
> On 04/17/2013 03:15 PM, Mike Duigou wrote:
>
>> String::
>>
>> line 1253: This should use {@code } rather than . I think
>> regular spaces are OK as well.   seems inappropriate.
>>
>> lines 2425/2467: elements may not be null either.
>>
>> I can tell you (or maybe it's just me) are itching to change :
>>
>> for (CharSequence cs: elements) {
>> 2477 joiner.add(cs);
>> 2478 }
>>
>> to:
>>
>> elements.forEach(joiner::add);
>>
>> StringJoiner::
>>
>> -  isn't needed around  as it's already a  you
>> probably mean to do
>>
>>  {@code
>> ...
>> }
>>
>> for code samples.
>>
>> - It would be nice if the empty output generation in three arg
>> constructor could be suppressed unless needed. Perhaps a special (not null
>> please!) sentinel value?
>>
>> - Four arg constructor doesn't include emptyOutput in @throws NPE
>>
>>
>> On Apr 11 2013, at 15:33 , Jim Gish wrote:
>>
>>  Please review http://cr.openjdk.java.net/~**jgish/Bugs-5015163-7175206-*
>>> *7172553/<
>>> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7175206-**7172553/
>>> >
>>>
>>> These are changes that we made in lambda that we're now bringing into
>>> JDK8.
>>>
>>> I've made a couple of additions - making StringJoiner final and adding a
>>> couple of constructors to set the emptyOutput chars.
>>>
>>> Thanks,
>>>Jim
>>>
>>> --
>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>>> Oracle Java Platform Group | Core Libraries Team
>>> 35 Network Drive
>>> Burlington, MA 01803
>>> jim.g...@oracle.com
>>>
>>>
> --
> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
> Oracle Java Platform Group | Core Libraries Team
> 35 Network Drive
> Burlington, MA 01803
> jim.g...@oracle.com
>
>

Re: RFR: String.join(), StringJoiner additions

[Jim Gish]

I'm open to this, but am interested in what others have to say, 
especially as it relates to other lambda features coming in.  Bear in 
mind that this is at least the third major round of reviews for these 
changes, the first round being a year ago on lambda-dev, when I first 
submitted them, and then they were distilled some more and greatly 
simplified by Henry Jen.


Thanks,
   Jim

On 04/17/2013 06:07 PM, Martin Buchholz wrote:
I'm still wondering about whether a joiner utility should support a 
prefix and suffix.  The obvious uses for this are collection class 
toString methods, but we already know that we can and should implement 
those with a single precise char[] construction, so should not use 
StringJoiner, or at least not this StringJoiner implementation.  And 
if we're just talking about pure convenience, it's hard to beat


"[" + String.join(...) + "]"


On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish > wrote:


Here's an update:
http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/



Jim


On 04/17/2013 03:15 PM, Mike Duigou wrote:

String::

line 1253: This should use {@code } rather than .
I think regular spaces are OK as well.   seems inappropriate.

lines 2425/2467: elements may not be null either.

I can tell you (or maybe it's just me) are itching to change :

for (CharSequence cs: elements) {
2477 joiner.add(cs);
2478 }

to:

elements.forEach(joiner::add);

StringJoiner::

-  isn't needed around  as it's already a
 you probably mean to do

 {@code
...
}

for code samples.

- It would be nice if the empty output generation in three arg
constructor could be suppressed unless needed. Perhaps a
special (not null please!) sentinel value?

- Four arg constructor doesn't include emptyOutput in @throws NPE


On Apr 11 2013, at 15:33 , Jim Gish wrote:

Please review
http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/



These are changes that we made in lambda that we're now
bringing into JDK8.

I've made a couple of additions - making StringJoiner
final and adding a couple of constructors to set the
emptyOutput chars.

Thanks,
   Jim

-- 
Jim Gish | Consulting Member of Technical Staff |

+1.781.442.0304 
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com 


-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304


Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com 




--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com

RFR: JDK-8012542 (Stream methods on Collection)

[Brian Goetz]

Updated spec for Collection.spliterator; default methods for 
Collection.stream() and parallelStream().  Specialized implementations 
in subtypes will come in a separate putback.


Webrev at:

  http://cr.openjdk.java.net/~briangoetz/JDK-8012542/webrev/

Re: Use of super in type parameters

[Dan Smith]

On Apr 15, 2013, at 1:37 PM, Martin Buchholz  wrote:

> CompletableFuture currently has a method like this:
> 
> public CompletableFuture acceptEither
> (CompletableFuture other,
>  Consumer block) {
> return doAcceptEither(other, block, null);
> }
> 
> But that signature is not quite correct (not as general as it could be).  The 
> "correct" signature is
> 
> public  CompletableFuture acceptEither
> (CompletableFuture other,
>  Consumer block) {
> return doAcceptEither(other, block, null);
> }
> 
> but that fails to compile, because type parameters can only be constrained by 
> extends, not super.  Is implementing this on the radar?

My favorite example:
interface Optional {
   S get(S alternate);
}
Optional o = ...;
Number n = o.get(0.0);

We were _this_ close to adding this, or something like it, with Lambda.  In the 
end, it didn't make the cut.

The good news is that capture variables already have lower bounds, and 
inference in Java 8 has been enhanced quite a bit, such that it can mostly 
handle things like this.  So it seems like it would be a relatively modest task 
to support the feature someday.

>  Angelika claims
> "lower bounds for type parameters make no sense"
> http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#Why%20is%20there%20no%20lower%20bound%20for%20type%20parameters?
> 
> but I am finding that hard to believe.  Is she right?

Lots of people said a lot of wrong things about generics in the heady Java 5 
days.  One or two of those things even ended up in the language spec. :-(  But 
no, "I can't think of why this would be useful" does not imply "this makes no 
sense."  (To be fair, I think we all make that leap from time to time.)

> For comparison,  the equivalent static method can be made to do what we want:
> 
> public static  CompletableFuture acceptEither
> (CompletableFuture f,
>  CompletableFuture other,
>  Consumer block) {
> return ...
> }

Yep, that's the workaround for now.  Or use a weaker signature for your 
instance method.  (Or both.)

On Apr 17, 2013, at 3:53 PM, Martin Buchholz  wrote:

> With the coming of lambda, it is more likely that people will be creating 
> APIs with "not quite correct" generic types, as we are doing in 
> CompletableFuture.  Which is pretty bad for a feature that is designed 
> specifically to provide compile time safety.

True.  I've made that argument for other axed features as well -- we punt now, 
and solving the problem later will just be harder, due to further compatibility 
constraints.  Ultimately, it would be great to make everything perfect out of 
the gate; but that's not practical.  (And in fact, "out of the gate" in this 
case was 9 years ago.)  Besides, we have to have something fun to do next time. 
:-)

—Dan

Re: What is the Build Process for Codes inside jdk/src/macosx/native/jobjc

[Dan Xu]

Adding core-libs-dev

On 04/17/2013 04:47 PM, Dan Xu wrote:

Hi,

As for the sourcecodes for mac platform, it has a special place 
holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I 
wonder how those codes are builtand whether its compilation process 
has any special handling. Thanks!


-Dan

RFR : 8008632 : Additional JavaDoc tags @apiNote, @implSpec and @implNote for JDK API Docs

[Mike Duigou]

Hello All;

Some of you have noticed that the lambda streams libraries patches currently 
going in to the TL repo make use of special javadoc tags. There are three tags 
being used:

@apiNote : Non-normative notes about the API. Usually used for examples.
@implSpec : Describes required behaviour of conforming implementations. Key is 
that the description is not inherited.
@implNote : Non-normative notes about the implementation. Typically used for 
descriptions of the behaviour. Also not inherited.

The tags are used primarily by default method implementations but will be used 
elsewhere as well. 

These tags are enabled by use of the -tag feature on the javadoc tool command 
line. They are not proposed as standard javadoc tags and may be implemented 
differently in future Java releases. Since they are implemented as custom tags 
just for the JDK API documentation you can't automatically use them in your own 
code. (You can, of course, add the same command line options to your javadoc 
invocations if you like these tags).

http://cr.openjdk.java.net/~mduigou/JDK-8008632/0/webrev/

The patch enumerates the new custom tags in addition to the standard tags to 
ensure correct output order.

Re: Use of super in type parameters

[Zhong Yu]

On Wed, Apr 17, 2013 at 4:53 PM, Martin Buchholz  wrote:
> With the coming of lambda, it is more likely that people will be creating
> APIs with "not quite correct" generic types, as we are doing in

I believe that we can tweak generic signatures in APIs without
breaking calling codes. No API user really pays attention to all these
questions marks in a signature, he'll just go with instinct about
co/contravariances, deduced from the nature of the method, so his code
shouldn't break when the signature is changed for the better, because
the args he provides are all in the proper types.

For example, if a method signature is supposed to be
 foo(List, List)
but we declare it today as, regrettably,
foo(List, List)
we don't really expect users to supply List and List where
S1!=S2. If a user does that, it conflicts with the implicit/explicit
contract of the method, the type system couldn't help to catch the
mistake today, but it's a bug regardless.

Zhong Yu

> CompletableFuture.  Which is pretty bad for a feature that is designed
> specifically to provide compile time safety.  It would be nice to at least
> have an acknowledgment that there is a problem here, even if it will not be
> fixed for this release.
>
>
> On Mon, Apr 15, 2013 at 12:50 PM, Zhong Yu  wrote:
>>
>> I have encountered on stackoverflow.com several legit use cases of
>> lower bound. And the other day Ali Lahijani raised the question that
>> Stream.reduce(BinaryOperator) breaks convariance of Stream, and I
>> thought that the root problem is lack of lower bound - the method
>> would have had a better signature
>> Stream
>>  Optional reduce(BinaryOperator accumulator)
>> So I don't think there's a lack of use cases for lower bound. (But I
>> have no idea how difficult it is to support it)
>>
>> Zhong Yu
>>
>>
>> On Mon, Apr 15, 2013 at 2:37 PM, Martin Buchholz 
>> wrote:
>> > CompletableFuture currently has a method like this:
>> >
>> > public CompletableFuture acceptEither
>> > (CompletableFuture other,
>> >  Consumer block) {
>> > return doAcceptEither(other, block, null);
>> > }
>> >
>> > But that signature is not quite correct (not as general as it could be).
>> >  The "correct" signature is
>> >
>> > public  CompletableFuture acceptEither
>> > (CompletableFuture other,
>> >  Consumer block) {
>> > return doAcceptEither(other, block, null);
>> > }
>> >
>> > but that fails to compile, because type parameters can only be
>> > constrained
>> > by extends, not super.  Is implementing this on the radar?  Angelika
>> > claims
>> > "lower bounds for type parameters make no sense"
>> >
>> > http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#Why%20is%20there%20no%20lower%20bound%20for%20type%20parameters
>> > ?
>> >
>> > but I am finding that hard to believe.  Is she right? For comparison,
>> > the
>> > equivalent static method can be made to do what we want:
>> >
>> > public static  CompletableFuture acceptEither
>> > (CompletableFuture f,
>> >  CompletableFuture other,
>> >  Consumer block) {
>> > return ...
>> > }
>
>

Re: What is the Build Process for Codes inside jdk/src/macosx/native/jobjc

[David Holmes]

Hi Dan,

I don't quite understand the question but all native code building is 
handled via jdk/makefiles/CompileNativeLibraries.gmk which in turn 
utilizes the set up from /common/makefiles/NativeCompilation.gmk


HTH

David

On 18/04/2013 9:51 AM, Dan Xu wrote:

Adding core-libs-dev

On 04/17/2013 04:47 PM, Dan Xu wrote:

Hi,

As for the sourcecodes for mac platform, it has a special place
holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I
wonder how those codes are builtand whether its compilation process
has any special handling. Thanks!

-Dan

Re: Use of super in type parameters

[Martin Buchholz]

Thanks, all, for the history lesson.

Re: What is the Build Process for Codes inside jdk/src/macosx/native/jobjc

[Dan Xu]

Hi David,

Under src/macosx/native/jobjc folder, it contains not only native *.m 
source files, but also *.java files. If you check the build results in 
build/macosx-x86_64-normal-server-release/jdk folder, it contains some 
build results specific for jobjc, say gensrc_jobjc/, 
gensrc_headers_jobjc/, jobjc_classes/, jobjc_classes_headers/.


So it must have some extra build steps to generate those jobjc results. 
And I wonder what they are and why they are special and not merged into 
the regular native compilation and java compilation processes. Thanks!


-Dan


On 04/17/2013 05:30 PM, David Holmes wrote:

Hi Dan,

I don't quite understand the question but all native code building is 
handled via jdk/makefiles/CompileNativeLibraries.gmk which in turn 
utilizes the set up from /common/makefiles/NativeCompilation.gmk


HTH

David

On 18/04/2013 9:51 AM, Dan Xu wrote:

Adding core-libs-dev

On 04/17/2013 04:47 PM, Dan Xu wrote:

Hi,

As for the sourcecodes for mac platform, it has a special place
holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I
wonder how those codes are builtand whether its compilation process
has any special handling. Thanks!

-Dan

RFR: JDK8011946 - java.util.Currency javadoc has broken link to iso.org

[Dan Xu]

Hi All,

Here is ajava doc fix. I have changed the broken link and pointed it to 
the page for standard ISO 4217. Thanks!


Webrev: http://cr.openjdk.java.net/~dxu/8011946/webrev/
Bug: http://bugs.sun.com/view_bug.do?bug_id=8011946

-Dan

Re: RFR: String.join(), StringJoiner additions

[Brian Goetz]

The motivation was indeed that it would support more efficient 
Collection.toString.  (But, I don't believe anything actually uses that 
feature right now, other than tests.)


Even if *our* implementations were not to use this because we had a 
better for-experts construction, I still think this is a useful feature 
that users classes may benefit from in their own toString methods.


On 4/17/2013 6:15 PM, Jim Gish wrote:

I'm open to this, but am interested in what others have to say,
especially as it relates to other lambda features coming in.  Bear in
mind that this is at least the third major round of reviews for these
changes, the first round being a year ago on lambda-dev, when I first
submitted them, and then they were distilled some more and greatly
simplified by Henry Jen.

Thanks,
Jim

On 04/17/2013 06:07 PM, Martin Buchholz wrote:

I'm still wondering about whether a joiner utility should support a
prefix and suffix.  The obvious uses for this are collection class
toString methods, but we already know that we can and should implement
those with a single precise char[] construction, so should not use
StringJoiner, or at least not this StringJoiner implementation.  And
if we're just talking about pure convenience, it's hard to beat

"[" + String.join(...) + "]"


On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish mailto:jim.g...@oracle.com>> wrote:

Here's an update:
http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/



Jim


On 04/17/2013 03:15 PM, Mike Duigou wrote:

String::

line 1253: This should use {@code } rather than .
I think regular spaces are OK as well.   seems
inappropriate.

lines 2425/2467: elements may not be null either.

I can tell you (or maybe it's just me) are itching to change :

for (CharSequence cs: elements) {
2477 joiner.add(cs);
2478 }

to:

elements.forEach(joiner::add);

StringJoiner::

-  isn't needed around  as it's already a
 you probably mean to do

 {@code
...
}

for code samples.

- It would be nice if the empty output generation in three arg
constructor could be suppressed unless needed. Perhaps a
special (not null please!) sentinel value?

- Four arg constructor doesn't include emptyOutput in @throws NPE


On Apr 11 2013, at 15:33 , Jim Gish wrote:

Please review

http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/





These are changes that we made in lambda that we're now
bringing into JDK8.

I've made a couple of additions - making StringJoiner
final and adding a couple of constructors to set the
emptyOutput chars.

Thanks,
   Jim

-- Jim Gish | Consulting Member of Technical
Staff |
+1.781.442.0304 
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com 


-- Jim Gish | Consulting Member of Technical Staff |
+1.781.442.0304

Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com 

Re: RFR: String.join(), StringJoiner additions

[Roger Riggs]

Hi,

Can I suggest that the StringJoiner.toString() method explicitly append 
the suffix

to the existing StringBuilder.

 152 return (value != null ? value.toString() + suffix : emptyValue);

Currently it will go to the trouble of creating a String from the 
builder and then

transparently create another StringBuilder to do the concatenation.

 152 return (value != null ? value.append(suffix).toString() : 
emptyValue);

or something similar.

The overhead of StringJoiner supporting prefix and suffix is lower than 
doing it separately
in terms of object allocations and garbage and all places that would 
need write their

own code to do the concatenation.

Roger


On 4/17/13 5:49 PM, Jim Gish wrote:
Here's an update: 
http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/ 



Jim

On 04/17/2013 03:15 PM, Mike Duigou wrote:

String::

line 1253: This should use {@code } rather than . I 
think regular spaces are OK as well.   seems inappropriate.


lines 2425/2467: elements may not be null either.

I can tell you (or maybe it's just me) are itching to change :

for (CharSequence cs: elements) {
2477 joiner.add(cs);
2478 }

to:

elements.forEach(joiner::add);

StringJoiner::

-  isn't needed around  as it's already a  you 
probably mean to do


 {@code
...
}

for code samples.

- It would be nice if the empty output generation in three arg 
constructor could be suppressed unless needed. Perhaps a special (not 
null please!) sentinel value?


- Four arg constructor doesn't include emptyOutput in @throws NPE


On Apr 11 2013, at 15:33 , Jim Gish wrote:

Please review 
http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/ 



These are changes that we made in lambda that we're now bringing 
into JDK8.


I've made a couple of additions - making StringJoiner final and 
adding a couple of constructors to set the emptyOutput chars.


Thanks,
   Jim

--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com

Re: RFR: JDK8011946 - java.util.Currency javadoc has broken link to iso.org

[Mike Duigou]

Looks good to me! The table is still accessible from that page it's just no 
longer part of the page. 

Mike

On Apr 17 2013, at 17:57 , Dan Xu wrote:

> Hi All,
> 
> Here is ajava doc fix. I have changed the broken link and pointed it to the 
> page for standard ISO 4217. Thanks!
> 
> Webrev: http://cr.openjdk.java.net/~dxu/8011946/webrev/
> Bug: http://bugs.sun.com/view_bug.do?bug_id=8011946
> 
> -Dan
> 

Re: What is the Build Process for Codes inside jdk/src/macosx/native/jobjc

[David Holmes]

On 18/04/2013 10:50 AM, Dan Xu wrote:

Hi David,

Under src/macosx/native/jobjc folder, it contains not only native *.m
source files, but also *.java files. If you check the build results in
build/macosx-x86_64-normal-server-release/jdk folder, it contains some
build results specific for jobjc, say gensrc_jobjc/,
gensrc_headers_jobjc/, jobjc_classes/, jobjc_classes_headers/.

So it must have some extra build steps to generate those jobjc results.
And I wonder what they are and why they are special and not merged into
the regular native compilation and java compilation processes. Thanks!


In jdk/makefiles:

- The java files are handled in CompileJavaClasses.gmk.
- There is special handling via GensrcJObjC.gmk

David


-Dan


On 04/17/2013 05:30 PM, David Holmes wrote:

Hi Dan,

I don't quite understand the question but all native code building is
handled via jdk/makefiles/CompileNativeLibraries.gmk which in turn
utilizes the set up from /common/makefiles/NativeCompilation.gmk

HTH

David

On 18/04/2013 9:51 AM, Dan Xu wrote:

Adding core-libs-dev

On 04/17/2013 04:47 PM, Dan Xu wrote:

Hi,

As for the sourcecodes for mac platform, it has a special place
holding native and java codes for jdk, jdk/src/macosx/native/jobjc. I
wonder how those codes are builtand whether its compilation process
has any special handling. Thanks!

-Dan

Re: RFR: String.join(), StringJoiner additions

[Martin Buchholz]

To be concrete, here's a proposed toString method :
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/toString/
which is pretty good as it stands, but even better once it gets to use the
no-copy String constructor.

Re: RFR: String.join(), StringJoiner additions

[Mike Duigou]

If I don't get a chance to revisit the whole UUID optimization patch soon I 
will see what I can do about breaking it up further and maybe just do the 
no-copy String constructor by itself.

Mike

On Apr 17 2013, at 20:29 , Martin Buchholz wrote:

> To be concrete, here's a proposed toString method :
> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/toString/
> which is pretty good as it stands, but even better once it gets to use the
> no-copy String constructor.

hg: jdk8/tl/jdk: 8010096: Initial java.util.Spliterator putback

[mike . duigou]

Changeset: 674880648db4
Author:briangoetz
Date:  2013-04-16 13:51 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/674880648db4

8010096: Initial java.util.Spliterator putback
Reviewed-by: mduigou, alanb, chegar, darcy
Contributed-by: Paul Sandoz , Brian Goetz 
, Doug Lea 

! src/share/classes/com/sun/tools/jdi/EventSetImpl.java
! src/share/classes/java/lang/Iterable.java
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/Iterator.java
! src/share/classes/java/util/List.java
+ src/share/classes/java/util/PrimitiveIterator.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/SortedSet.java
+ src/share/classes/java/util/Spliterator.java
+ src/share/classes/java/util/Spliterators.java
+ src/share/classes/java/util/Tripwire.java
+ test/java/util/Spliterator/SpliteratorLateBindingFailFastTest.java
+ test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java

system reserved property names

[huizhe wang]

System.getProperties [1] returns all of the "current" system properties. Is there a way 
to get a list of the system reserved properties such as "java.version" and etc.?  Would 
anyone know?


[1]http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#getProperties%28%29

Thanks,
Joe