Re: please review draft JEP: Convenience Factory Methods for Collections

[Michael Kay]

Set.of() and List.of() look very attractive; Map.of() looks very ugly.

I would much prefer to write something like

Map.of(
  Map.pair(key, value),
  Map.pair(key, value),
  Map.pair(key, value)
);

and have no limit on the number of pairs. (Don't care how it works 
internally...)

The last thing I want is to have to rewrite all my code when someone asks me to 
add a sixth entry to the map initialization!

Michael Kay
Saxonica
m...@saxonica.com
+44 (0118) 946 5893



On 17 Jul 2014, at 01:46, Stuart Marks stuart.ma...@oracle.com wrote:

 Hi all,
 
 Please review this draft JEP for Convenience Factory Methods for Collections:
 
https://bugs.openjdk.java.net/browse/JDK-8048330
 
 Brief background: several times over the years there have been proposals to 
 add collection literals to the language. The most recent round of this was 
 in regard to JEP 186, a research JEP to explore this topic. That effort was 
 concluded by Brian Goetz, as summarized in this email:
 
http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html
 
 Essentially, the idea of adding collection literals to the language was set 
 aside in favor of adding some library APIs, not entirely unlike collection 
 literals, that make it more convenient to create collections. That's what 
 this proposal is.
 
 Share and enjoy,
 
 s'marks
 

Re: FYC: 7197183 : Provide CharSequence.subSequenceView which allows for sub-sequence views of character sequences.

[Michael Kay]

In my own product (Saxon) I have a class CharSlice which is pretty much 
identical to your CharSubSequenceView. So yes, I think it is useful.

Michael Kay
Saxonica
m...@saxonica.com
+44 (0118) 946 5893



On 17 Jul 2014, at 01:09, Mike Duigou mike.dui...@oracle.com wrote:

 Hello all;
 
 In Java 7u6 there was a significant change in the implementation of 
 java.lang.String (JDK-6924259). This was done to reduce the size of String 
 instances and it has been generally regarded as a positive change. As with 
 almost any significant change to a class as core to Java as String there have 
 also been applications negatively impacted. Most of the problems involve 
 applications which make heavy use of String.substring() as sub-string 
 instances now involve creation of their own copies of the backing characters.
 
 There have been previous discussions of mitigations to the 6924259 change in 
 String.substring() behaviour. These discussions haven't come to positive 
 conclusions mostly because they generally require too many changes to the 
 specification or behaviour of String. So here's another proposal (enclosed) 
 that doesn't change the behaviour of any existing classes. It adds two new 
 methods to CharSequence to create sub-sequence views of character sequences. 
 The size of sub-sequence instances very closely matches the size of 
 pre-6924259 String instances and indeed the implementation has the same 
 pre-6924259 limitations, namely that the entire source CharSequence remains 
 alive as long as the sub-sequence is referenced.
 
 Unlike pre-6924259 the CharSubSequenceView can not be reliably compared via 
 equals() to String instances and it is unsuitable for use as a hash map key. 
 
 With these benefits and caveats in mind, would you use this?
 
 Mike
 
 diff -r 66f582158e1c src/share/classes/java/lang/CharSequence.java
 --- a/src/share/classes/java/lang/CharSequence.java   Wed Jul 16 20:43:53 
 2014 +0100
 +++ b/src/share/classes/java/lang/CharSequence.java   Wed Jul 16 16:58:52 
 2014 -0700
 @@ -25,11 +25,14 @@
 
 package java.lang;
 
 +import java.io.Serializable;
 import java.util.NoSuchElementException;
 +import java.util.Objects;
 import java.util.PrimitiveIterator;
 import java.util.Spliterator;
 import java.util.Spliterators;
 import java.util.function.IntConsumer;
 +import java.util.function.IntSupplier;
 import java.util.stream.IntStream;
 import java.util.stream.StreamSupport;
 
 @@ -231,4 +234,114 @@
 Spliterator.ORDERED,
 false);
 }
 +
 +/**
 + * Provides a sub-sequence view on a character sequence. Changes in the
 + * source will be reflected in the sub-sequence. The sub-sequence must, 
 at
 + * all times, be a proper sub-sequence of the source character sequence.
 + *
 + * @since 1.9
 + */
 +static final class CharSubSequenceView implements CharSequence, 
 Serializable {
 +
 +private final CharSequence source;
 +private final int fromInclusive;
 +private final IntSupplier toExclusive;
 +
 +CharSubSequenceView(CharSequence source, int fromInclusive, int 
 toExclusive) {
 +this(source, fromInclusive, () - toExclusive);
 +}
 +
 +CharSubSequenceView(CharSequence source, int fromInclusive, 
 IntSupplier toExclusive) {
 +this.source = Objects.requireNonNull(source);
 +if(fromInclusive  0 || fromInclusive = source.length() ||
 +   toExclusive.getAsInt()  fromInclusive || 
 toExclusive.getAsInt()  source.length()) {
 +throw new IllegalArgumentException(Invalid index);
 +}
 +this.fromInclusive = fromInclusive;
 +this.toExclusive = toExclusive;
 +}
 +
 +@Override
 +public int length() {
 +return toExclusive.getAsInt() - fromInclusive;
 +}
 +
 +@Override
 +public char charAt(int index) {
 +if(index = length()) {
 +throw new IllegalArgumentException(Invalid Index);
 +}
 +//
 +return source.charAt(fromInclusive + index);
 +}
 +
 +@Override
 +public CharSequence subSequence(int start, int end) {
 +   if (end  length()) {
 +   throw new IllegalArgumentException(Invalid Index);
 +   }
 +   return source.subSequence(fromInclusive + start, fromInclusive + 
 end);
 +}
 +
 +@Override
 +public String toString() {
 +int len = length();
 +char[] chars = new char[len];
 +for(int each = 0; each  len; each++) {
 +chars[each] = charAt(each);
 +}
 +return new String(chars, true);
 +}
 +}
 +
 +/**
 + * Returns as a character sequence the specified sub-sequence view of the
 + * provided source character sequence. Changes in the source will be
 + * reflected in the sub-sequence. The sub-sequence 

Re: please review draft JEP: Convenience Factory Methods for Collections

[Tom Hawtin]

I note that with the basic proposal, HashSet.of and indeed 
NavigableSet.of still work. They just do the wrong thing.


Tom

Re: please review draft JEP: Convenience Factory Methods for Collections

[Michael Kay]

On 17 Jul 2014, at 08:21, Michael Kay m...@saxonica.com wrote:

 Set.of() and List.of() look very attractive; Map.of() looks very ugly.
 
 I would much prefer to write something like
 
 Map.of(
  Map.pair(key, value),
  Map.pair(key, value),
  Map.pair(key, value)
 );
 

Another style that would work for me is

Map
  .add(key,value)
  .add(key,value)
  .add(key,value)
  .add(key,value);

Michael Kay
Saxonica
  

Re: please review draft JEP: Convenience Factory Methods for Collections

[Remi Forax]

On 07/17/2014 04:05 AM, Paul Benedict wrote:
Regarding why you didn't choose a straight vararg solution, I prefer 
you do allow any number of key/values as long as you throw an 
exception if the array is not an even sized.


You can not extract/infer the type of the key and the type of the value 
if you have only one array.





Cheers,
Paul


cheers,
Rémi




On Wed, Jul 16, 2014 at 8:58 PM, Stuart Marks stuart.ma...@oracle.com 
mailto:stuart.ma...@oracle.com wrote:


On 7/16/14 6:03 PM, Remi Forax wrote:

On 07/17/2014 02:46 AM, Stuart Marks wrote:

Please review this draft JEP for Convenience Factory
Methods for Collections:

https://bugs.openjdk.java.net/browse/JDK-8048330

Brief background: several times over the years there have
been proposals to
add collection literals to the language. The most recent
round of this was
in regard to JEP 186, a research JEP to explore this
topic. That effort was
concluded by Brian Goetz, as summarized in this email:


http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html

Essentially, the idea of adding collection literals to the
language was set
aside in favor of adding some library APIs, not entirely
unlike collection
literals, that make it more convenient to create
collections. That's what this
proposal is.


I think you should say something about the serialization of
the immutable
collections
because implementation details like the real class name can
leak through this
channel.
That's why, by example, java.util.Collections.ArrayList (the
internal class of
Collections) was never renamed.


Hi Remi,

(I think you mean java.util.Arrays.ArrayList?)

But yes, the point is make the implementation classes private and
to use serialization proxies (or perhaps just one serialization
proxy for all implementation classes) to control the number of
classes exposed by the serialized format. I should probably make
this more explicit.

Also 5 key/value pairs seems a little bit limited IMO, 7 or 8
will be better but
I suppose you want to use the fact
that because the number of pairs is really small, the
algorithm can do a linear
probe.


We started with 5 because that's what Guava does, but there's
nothing essential about 5. Could be 6 or 7 or maybe even 8. We
need to do some investigation of common map sizes in real
applications. That's how the Guava guys came up with 5, I think.
We have some internal numbers that I'm told are slightly higher,
but I still need to track those down.

And yes at small sizes it makes sense to do linear probe or even a
plain linear search (i.e., no hashing).

I think you should add a version that takes two arrays of the
same size (for an
(almost) unlimited number of pairs)
with an implementation that clone the two arrays (at least
until value type are
implemented).


Yes, one could add such a thing. :-) I guess if we were to choose
the right number of key/value pairs for Map.of(...), would there
still be a need for immutable maps with arbitrary numbers of
key-value pairs? And how convenient would it be to use?

I think you should also add a default method toImmutable to
Set, List and Map,
so one  can use HashSet, ArrayList
and HashMap as builder for their immutable counterparts.
Otherwise, the stream
integration will be difficult,
i.e. the implementation of Collectors.toImmutableList/Set/Map.


I don't see this proposal as providing immutable counterparts to
the existing mutable collections. The existing collections are
designed to deal well with arbitrary numbers of elements, but the
immutable collections discussed here are not -- they're intended
to support the convenience API, which is focused on relatively
small numbers of elements.

Now it might be nice to have a set of scalable, immutable
collections, which would necessarily entail some additional APIs
to construct them from streams and from existing collections. But
that's a somewhat different goal. We should have a discussion
about whether doing that is necessary, and if so, whether it
should be part of this proposal.

s'marks

Re: Review request for 8050804: (jdeps) Recommend supported API to replace use of JDK internal API

[Daniel Fuchs]

Hi Mandy,

minor:
JdepsTask.java:977 could be refactored to use putIfAbsent

I wonder whether the summary table at the end should contain a warning
for all the usage of jdk internals that have no replacement?

Otherwise looks good! I like the output much better :-)

best regards,

-- daniel

On 7/17/14 12:38 AM, Mandy Chung wrote:

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

I plan to backport this to 8u40.

Mandy

On 7/16/14 8:09 AM, Mandy Chung wrote:

My first version prints a separate table of the replacements following
the new warning message at the end of the jdeps output. I like the
first version better than this version replacing rt.jar with Use...
message.   I might be too anxious getting developers to take action
using the supported APIs when there is one and hence this version.

I'll update the webrev to print as a separate table.

thanks
Mandy

On 7/16/2014 6:10 AM, Daniel Fuchs wrote:

Hi Mandy,

here is a typical output - with names mangled to save
space:

s.u.l.p.LPA (rt.jar)
  - s.s.a.GP   JDK internal API (Use j.s.PA @since 1.1)
  - s.u.c.CLDRLPA  JDK internal API (rt.jar)

In the first dependency line, the archive name has been replaced
by the 'Use ...' message.

I wonder whether it would be better to keep the archive name
and print the use message as additional information, in order
to be 'script friendly' so that you could use things like
| grep 'rt.jar' on the output.

best regards,

-- daniel

On 7/16/14 1:35 AM, Mandy Chung wrote:

jdeps -jdkinternals flags use of JDK internal APIs.  We have created a
wiki page to keep track of the JDK internal APIs and its replacement:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool


While this page will be updated when we identify any new ones
worthnoting, it'd still be useful for jdeps to suggest the replacement
APIs of the known ones.

webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050804/webrev.00/

Mandy

Re: RFR: JDK-8042589: String.toLowerCase do not work for some concatenated strings

[Ulf Zibis]

There is again another little optimization possible:

instead
hasSurr = true;
we could use
first = ~first;
and save variable hasSurr.

If there is register pressure (especially on older CPUs), this might be a 
performance advantage.

Also I think we should not grow the result array for any character where mapLen  srcCount, we 
could wait until the result array is actually full.


-Ulf


Am 17.07.2014 00:55, schrieb Xueming Shen:

Still need a reviewer.

On 07/09/2014 01:04 PM, Xueming Shen wrote:

Hi,

Please help review the change for JDK-8042589.

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

This is a regression caused by the following change for #JDK-8032012,

issue:https://bugs.openjdk.java.net/browse/JDK-8032012
webrev: http://cr.openjdk.java.net/~sherman/8032012/
discussion: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024862.html

It appears the last optimization for the surrogates we pushed in is
incomplete. We still need to check isSurrogate() in the optimized
non-surrogate loop, as the first (checked at the very beginning) might
be triggered by a non-surrogate-upper/lowercase char.

Thanks!
-Sherman

Re: RFR: JDK-8042589: String.toLowerCase do not work for some concatenated strings

[Ulf Zibis]

Additionally I think, instead of retrieving
String lang = locale.getLanguage()
multiple times in chain, we could pass lang to the methods instead locale.

-Ulf

Am 17.07.2014 11:54, schrieb Ulf Zibis:

There is again another little optimization possible:

instead
hasSurr = true;
we could use
first = ~first;
and save variable hasSurr.

If there is register pressure (especially on older CPUs), this might be a 
performance advantage.

Also I think we should not grow the result array for any character where mapLen  srcCount, we 
could wait until the result array is actually full.


-Ulf


Am 17.07.2014 00:55, schrieb Xueming Shen:

Still need a reviewer.

On 07/09/2014 01:04 PM, Xueming Shen wrote:

Hi,

Please help review the change for JDK-8042589.

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

This is a regression caused by the following change for #JDK-8032012,

issue:https://bugs.openjdk.java.net/browse/JDK-8032012
webrev: http://cr.openjdk.java.net/~sherman/8032012/
discussion: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024862.html

It appears the last optimization for the surrogates we pushed in is
incomplete. We still need to check isSurrogate() in the optimized
non-surrogate loop, as the first (checked at the very beginning) might
be triggered by a non-surrogate-upper/lowercase char.

Thanks!
-Sherman

Re: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs

[Georgiy Rakov]

Hello,

let's consider following excerpt:

 149  * It is possible for intermediate sums of finite values to
 150  * overflow into opposite-signed infinities; if that occurs, the
 151  * final sum will be NaN even if the recorded values are all
 152  * finite.

It says about intermediate sums. I could suppose it implies those 
intermediate sums which are produced during parallel processing. If my 
supposition is true then:


1) I think it would be good to mention it explicitly because otherwise 
this excerpt could also be interpreted as if it talks about intermediate 
sums produced somehow during sequential processing, I'm not sure if this 
is desirable interpretation.
2) For DoubleSummaryStatistics those intermediate sums are added by 
calling combine I suppose, so I think it would be good to specify in 
DoubleSummaryStatistics doc, that turning two opposite-signedinfinities 
into NaN is actually resulted from calling combine().
3) The result produced from sequential and parallel processing could 
differ, say considerably. That is for sequential processing it could be 
+/-INFINITE while for parallel processing - NaN. Would it be good to 
mention it?


Thank you,
Georgiy.

On 16.07.2014 16:37, Paul Sandoz wrote:



Begin forwarded message:


*From: *Joe Darcy joe.da...@oracle.com mailto:joe.da...@oracle.com
*Subject: **JDK 9 RFR of JDK-8030942: Explicitly state floating-point 
summation requirements on non-finite inputs*

*Date: *July 16, 2014 2:29:46 AM GMT+02:00
*To: *Core-Libs-Dev core-libs-dev@openjdk.java.net 
mailto:core-libs-dev@openjdk.java.net


Hello,

Please review my changes to address:

   JDK-8030942: Explicitly state floating-point summation 
requirements on non-finite inputs
http://cr.openjdk.java.net/~darcy/8030942.0/ 
http://cr.openjdk.java.net/%7Edarcy/8030942.0/


Patch below.

Thanks,

-Joe

--- old/src/share/classes/java/util/DoubleSummaryStatistics.java 
2014-07-15 17:26:41.0 -0700
+++ new/src/share/classes/java/util/DoubleSummaryStatistics.java 
2014-07-15 17:26:41.0 -0700

@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All 
rights reserved.
+ * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All 
rights reserved.

 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
@@ -129,9 +129,6 @@
 * Returns the sum of values recorded, or zero if no values have been
 * recorded.
 *
- * If any recorded value is a NaN or the sum is at any point a NaN
- * then the sum will be NaN.
- *
 * p The value of a floating-point sum is a function both of the
 * input values as well as the order of addition operations. The
 * order of addition operations of this method is intentionally
@@ -143,6 +140,23 @@
 * numerical sum compared to a simple summation of {@code double}
 * values.
 *
+ * pIf any recorded value is a NaN or the intermediate sum is at
+ * any point a NaN, then the final sum will be NaN.
+ *
+ * If the recorded values contain infinities of opposite sign, the
+ * final sum will be NaN.
+ *
+ * It is possible for intermediate sums of finite values to
+ * overflow into opposite-signed infinities; if that occurs, the
+ * final sum will be NaN even if the recorded values are all
+ * finite.
+ *
+ * If the exact sum is infinite, a properly-signed infinity is
+ * returned.
+ *
+ * If all the recorded values are zero, the sign of zero is
+ * emnot/em guaranteed to be preserved in the final sum.
+ *
 * @apiNote Values sorted by increasing absolute magnitude tend 
to yield

 * more accurate results.
 *
@@ -193,9 +207,6 @@
 * Returns the arithmetic mean of values recorded, or zero if no
 * values have been recorded.
 *
- * If any recorded value is a NaN or the sum is at any point a NaN
- * then the average will be code NaN.
- *
 * pThe average returned can vary depending upon the order in
 * which values are recorded.
 *
@@ -203,6 +214,10 @@
 * other technique to reduce the error bound in the {@link #getSum
 * numerical sum} used to compute the average.
 *
+ * pThis method can return a NaN or infinite result in the same
+ * kind of numerical situations as {@linkplain #getSum() the sum}
+ * can be NaN or infinite, respectively.
+ *
 * @apiNote Values sorted by increasing absolute magnitude tend 
to yield

 * more accurate results.
 *
--- old/src/share/classes/java/util/stream/DoubleStream.java 
2014-07-15 17:26:42.0 -0700
+++ new/src/share/classes/java/util/stream/DoubleStream.java 
2014-07-15 17:26:42.0 -0700

@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All 
rights reserved.
+ * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All 
rights reserved.

 * DO NOT ALTER OR REMOVE COPYRIGHT 

Re: Review request for 8050804: (jdeps) Recommend supported API to replace use of JDK internal API

[Mandy Chung]

On 7/17/2014 2:41 AM, Daniel Fuchs wrote:

Hi Mandy,

minor:
JdepsTask.java:977 could be refactored to use putIfAbsent



ok.


I wonder whether the summary table at the end should contain a warning
for all the usage of jdk internals that have no replacement?



It's intentional.  The list shown by jdeps is not an excessive list and only
includes the classes that I found are used in several products. When we find
more jDK internal APIs that are used and have a replacement (or RFE), I'll
update the wiki.


Otherwise looks good! I like the output much better :-)



Thanks
Mandy


best regards,

-- daniel

On 7/17/14 12:38 AM, Mandy Chung wrote:

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

I plan to backport this to 8u40.

Mandy

On 7/16/14 8:09 AM, Mandy Chung wrote:

My first version prints a separate table of the replacements following
the new warning message at the end of the jdeps output. I like the
first version better than this version replacing rt.jar with Use...
message.   I might be too anxious getting developers to take action
using the supported APIs when there is one and hence this version.

I'll update the webrev to print as a separate table.

thanks
Mandy

On 7/16/2014 6:10 AM, Daniel Fuchs wrote:

Hi Mandy,

here is a typical output - with names mangled to save
space:

s.u.l.p.LPA (rt.jar)
  - s.s.a.GP   JDK internal API (Use j.s.PA @since 1.1)
  - s.u.c.CLDRLPA  JDK internal API (rt.jar)

In the first dependency line, the archive name has been replaced
by the 'Use ...' message.

I wonder whether it would be better to keep the archive name
and print the use message as additional information, in order
to be 'script friendly' so that you could use things like
| grep 'rt.jar' on the output.

best regards,

-- daniel

On 7/16/14 1:35 AM, Mandy Chung wrote:
jdeps -jdkinternals flags use of JDK internal APIs.  We have 
created a

wiki page to keep track of the JDK internal APIs and its replacement:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool 




While this page will be updated when we identify any new ones
worthnoting, it'd still be useful for jdeps to suggest the 
replacement

APIs of the known ones.

webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050804/webrev.00/

Mandy

Re: FYC: 7197183 : Provide CharSequence.subSequenceView which allows for sub-sequence views of character sequences.

[Claes Redestad]

Hi Mike,

 while nicely abstracting the problem, promoting developers to 
re-introduce some of the leakiness that the 7u6 String changes helped 
remove is something I think we should be wary of. If anything I think 
such an object should not be Serializable; maybe even have hashCode() 
throw NotSupportedOperationException() to make sure it's only ever used 
as a temporary object and prevent abuse? CharSequenceSlice?


 The alternative - or existing - approach, which admittedly isn't 
pretty, would be to provide methods with offsets such as 
Appendable.append(CharSequence, int, int). This avoids need for 
substring/subSequence or creating any temporary object altogether. The 
idea with an IntSupplier is pretty neat, though, but could be adopted 
for the existing offset methods as well.


/Claes

On 07/17/2014 02:09 AM, Mike Duigou wrote:

Hello all;

In Java 7u6 there was a significant change in the implementation of 
java.lang.String (JDK-6924259). This was done to reduce the size of String 
instances and it has been generally regarded as a positive change. As with 
almost any significant change to a class as core to Java as String there have 
also been applications negatively impacted. Most of the problems involve 
applications which make heavy use of String.substring() as sub-string instances 
now involve creation of their own copies of the backing characters.

There have been previous discussions of mitigations to the 6924259 change in 
String.substring() behaviour. These discussions haven't come to positive 
conclusions mostly because they generally require too many changes to the 
specification or behaviour of String. So here's another proposal (enclosed) 
that doesn't change the behaviour of any existing classes. It adds two new 
methods to CharSequence to create sub-sequence views of character sequences. 
The size of sub-sequence instances very closely matches the size of pre-6924259 
String instances and indeed the implementation has the same pre-6924259 
limitations, namely that the entire source CharSequence remains alive as long 
as the sub-sequence is referenced.

Unlike pre-6924259 the CharSubSequenceView can not be reliably compared via 
equals() to String instances and it is unsuitable for use as a hash map key.

With these benefits and caveats in mind, would you use this?

Mike

diff -r 66f582158e1c src/share/classes/java/lang/CharSequence.java
--- a/src/share/classes/java/lang/CharSequence.java Wed Jul 16 20:43:53 
2014 +0100
+++ b/src/share/classes/java/lang/CharSequence.java Wed Jul 16 16:58:52 
2014 -0700
@@ -25,11 +25,14 @@
  
  package java.lang;
  
+import java.io.Serializable;

  import java.util.NoSuchElementException;
+import java.util.Objects;
  import java.util.PrimitiveIterator;
  import java.util.Spliterator;
  import java.util.Spliterators;
  import java.util.function.IntConsumer;
+import java.util.function.IntSupplier;
  import java.util.stream.IntStream;
  import java.util.stream.StreamSupport;
  
@@ -231,4 +234,114 @@

  Spliterator.ORDERED,
  false);
  }
+
+/**
+ * Provides a sub-sequence view on a character sequence. Changes in the
+ * source will be reflected in the sub-sequence. The sub-sequence must, at
+ * all times, be a proper sub-sequence of the source character sequence.
+ *
+ * @since 1.9
+ */
+static final class CharSubSequenceView implements CharSequence, 
Serializable {
+
+private final CharSequence source;
+private final int fromInclusive;
+private final IntSupplier toExclusive;
+
+CharSubSequenceView(CharSequence source, int fromInclusive, int 
toExclusive) {
+this(source, fromInclusive, () - toExclusive);
+}
+
+CharSubSequenceView(CharSequence source, int fromInclusive, 
IntSupplier toExclusive) {
+this.source = Objects.requireNonNull(source);
+if(fromInclusive  0 || fromInclusive = source.length() ||
+   toExclusive.getAsInt()  fromInclusive || toExclusive.getAsInt() 
 source.length()) {
+throw new IllegalArgumentException(Invalid index);
+}
+this.fromInclusive = fromInclusive;
+this.toExclusive = toExclusive;
+}
+
+@Override
+public int length() {
+return toExclusive.getAsInt() - fromInclusive;
+}
+
+@Override
+public char charAt(int index) {
+if(index = length()) {
+throw new IllegalArgumentException(Invalid Index);
+}
+//
+return source.charAt(fromInclusive + index);
+}
+
+@Override
+public CharSequence subSequence(int start, int end) {
+   if (end  length()) {
+   throw new IllegalArgumentException(Invalid Index);
+   }
+   return source.subSequence(fromInclusive + start, fromInclusive + 
end);
+}
+
+@Override
+public String 

[9] RFR 8038970: Deprivilege JAX-WS/JAF code

[Miroslav Kos]

Hi everybody,
here is a request for review for

8038970: Deprivilege JAX-WS/JAF code
JBS: https://bugs.openjdk.java.net/browse/JDK-8038970
webrev: http://cr.openjdk.java.net/~mkos/8038970/jaxws.04/

This is first part of changes - after this also jdk build will have to 
be changed.
Changeset has been already discussed during testing phase with Sean 
Mullan and Mandy Chung.


Thanks
Miran

Re: [9] RFR (M): 8050877: Improve code for pairwise argument conversions and value boxing/unboxing

[Paul Sandoz]

On Jul 16, 2014, at 6:28 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com 
wrote:

 http://cr.openjdk.java.net/~vlivanov/8050877/webrev.00/
 https://bugs.openjdk.java.net/browse/JDK-8050877
 
 Improved MethodHandleImpl.makePairwiseConvert  ValueConversions.unbox and 
 small cleanups in related code.
 
 Also, improved method handle caching in ValueConversions.
 
 MethodHandleImpl.makePairwiseConvert:
 - * @param level which strength of conversion is allowed
 + * @param strict if true, only asType conversions are allowed; if false, 
 explicitCastArguments conversions allowed
 + * @param monobox if true, unboxing conversions are assumed to be 
 exactly typed (Integer to int only, not long or double)
 
 ValueConversions.unbox:
 -private static MethodHandle unbox(Wrapper wrap, boolean cast) {
 +private static MethodHandle unbox(Wrapper wrap, int kind) {
 +// kind 0 - strongly typed with NPE
 +// kind 1 - strongly typed but zero for null,
 +// kind 2 - asType rules: accept multiple box types but only 
 widening conversions with NPE
 +// kind 3 - explicitCastArguments rules: allow narrowing 
 conversions, zero for null
 +WrapperCache cache = UNBOX_CONVERSIONS[kind];
 
 Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ -ea 
 -esa and COMPILE_THRESHOLD={0,30}.
 
 Reviewed-by: vlivanov, ?
 Contributed-by: john.r.r...@oracle.com
 

MethodHandleImpl

Merge the the 'if' into an 'else if':
 365 } else {
 366 if (dst.isPrimitive()) {

ValueConversions

I can see why an EnumMap is used for convenience mapping the Wrapper to MH. 
IIUC it means the MH ref values are not @Stable? I guess it would be easy to 
unpack into an explicit array and index from the wrapper ordinal, plus then no 
additional runtime type checks on the key will be performed for get/put. Dunno 
how important that is.

Can UNBOX_CONVERSIONS be marked as @Stable? does that make any difference? Same 
for BOX_CONVERSIONS etc.

Paul.

Re: [9] RFR 8038970: Deprivilege JAX-WS/JAF code

[Mandy Chung]

On 7/17/2014 8:12 AM, Miroslav Kos wrote:

Hi everybody,
here is a request for review for

8038970: Deprivilege JAX-WS/JAF code
JBS: https://bugs.openjdk.java.net/browse/JDK-8038970
webrev: http://cr.openjdk.java.net/~mkos/8038970/jaxws.04/
 


FYI. The href at the above links were wrong.

com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java
   line 309: it's fine wrapping with NoSuchMethodError and
   you can take out throws NoSuchMethodException from line 292

Did you miss JAF classes?

As a background, this patch is to prepare for granting minimal set
of permissions.

Mandy

This is first part of changes - after this also jdk build will have to 
be changed.
Changeset has been already discussed during testing phase with Sean 
Mullan and Mandy Chung.


Thanks
Miran 

Re: [9] RFR (M): 8050884: Intrinsify ValueConversions.identity() functions

[Paul Sandoz]

On Jul 16, 2014, at 6:44 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com 
wrote:
 http://cr.openjdk.java.net/~vlivanov/8050884/webrev.00/
 https://bugs.openjdk.java.net/browse/JDK-8050884
 
 Replace ValueConversions.identity() functions with intrinsics.
 
 Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ -ea 
 -esa and COMPILE_THRESHOLD={0,30}.
 
 Reviewed-by: vlivanov, ?
 Contributed-by: john.r.r...@oracle.com
 

Looks good.

Same question as in previous email on @Stable for MethodHandles.IDENTITY_MHS.

FWIW for MethodHandles.IDENTITY_MHS the Wrapper.ordinal() is used as an index 
rather than using an EnumMap.

Paul.

Re: [9] RFR (S): 8050887: Intrinsify constants for default values

[Paul Sandoz]

On Jul 16, 2014, at 6:57 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com 
wrote:
 http://cr.openjdk.java.net/~vlivanov/8050887/webrev.00
 https://bugs.openjdk.java.net/browse/JDK-8050887
 
 Intrinsify MethodHandles.constant() for default values.
 
 Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ -ea 
 -esa and COMPILE_THRESHOLD={0,30}.
 
 Reviewed-by: vlivanov, ?
 Contributed-by: john.r.r...@oracle.com
 

Looks good. Same question as before on the cached array.

Paul.

Re: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs

[Joe Darcy]

Hello,

On 07/17/2014 04:33 AM, Georgiy Rakov wrote:

Hello,

let's consider following excerpt:

  149  * It is possible for intermediate sums of finite values to
  150  * overflow into opposite-signed infinities; if that occurs, the
  151  * final sum will be NaN even if the recorded values are all
  152  * finite.
It says about intermediate sums. I could suppose it implies those 
intermediate sums which are produced during parallel processing. If my 
supposition is true then:


Parallel processing is one possible way two intermediate sums can be 
combined, but since the order of summation is intentionally undefined, 
even a serial-only computation can have two intermediate sums being 
combined (as opposed to only combining a new element to an intermediate 
sum).


For example, an allowable implementation of sum() would do pairwise 
combination of successive elements, then add up pairs of pairs, etc., 
until the final sum is reached.




1) I think it would be good to mention it explicitly because otherwise 
this excerpt could also be interpreted as if it talks about 
intermediate sums produced somehow during sequential processing, I'm 
not sure if this is desirable interpretation.
2) For DoubleSummaryStatistics those intermediate sums are added by 
calling combine I suppose, so I think it would be good to specify in 
DoubleSummaryStatistics doc, that turning two 
opposite-signedinfinities into NaN is actually resulted from calling 
combine().


I don't think such detail is necessary or helpful.

You can get opposite signed infinities as values in the input. Or you 
can get opposite signed infinities from being given one infinity as a 
starting value and then getting the other infinity from overflow. Or you 
can get both infinities from overflow.


I don't think drawing too much distinction between these cases is needed.


3) The result produced from sequential and parallel processing could 
differ, say considerably. That is for sequential processing it could 
be +/-INFINITE while for parallel processing - NaN. Would it be good 
to mention it?


The methods already state something like:

 132  * p The value of a floating-point sum is a function both of the
 133  * input values as well as the order of addition operations. The
 134  * order of addition operations of this method is intentionally
 135  * not defined to allow for implementation flexibility to improve
 136  * the speed and accuracy of the computed result.

Parallel vs serial is only one possible source of the differences that 
the specification allows; I don't think it is worthwhile calling it out 
specially.


-Joe



Thank you,
Georgiy.

On 16.07.2014 16:37, Paul Sandoz wrote:



Begin forwarded message:


*From: *Joe Darcy joe.da...@oracle.com mailto:joe.da...@oracle.com
*Subject: **JDK 9 RFR of JDK-8030942: Explicitly state 
floating-point summation requirements on non-finite inputs*

*Date: *July 16, 2014 2:29:46 AM GMT+02:00
*To: *Core-Libs-Dev core-libs-dev@openjdk.java.net 
mailto:core-libs-dev@openjdk.java.net


Hello,

Please review my changes to address:

   JDK-8030942: Explicitly state floating-point summation 
requirements on non-finite inputs
http://cr.openjdk.java.net/~darcy/8030942.0/ 
http://cr.openjdk.java.net/%7Edarcy/8030942.0/


Patch below.

Thanks,

-Joe

--- old/src/share/classes/java/util/DoubleSummaryStatistics.java 
2014-07-15 17:26:41.0 -0700
+++ new/src/share/classes/java/util/DoubleSummaryStatistics.java 
2014-07-15 17:26:41.0 -0700

@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All 
rights reserved.
+ * Copyright (c) 2012, 2014, Oracle and/or its affiliates. All 
rights reserved.

 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
@@ -129,9 +129,6 @@
 * Returns the sum of values recorded, or zero if no values have 
been

 * recorded.
 *
- * If any recorded value is a NaN or the sum is at any point a NaN
- * then the sum will be NaN.
- *
 * p The value of a floating-point sum is a function both of the
 * input values as well as the order of addition operations. The
 * order of addition operations of this method is intentionally
@@ -143,6 +140,23 @@
 * numerical sum compared to a simple summation of {@code double}
 * values.
 *
+ * pIf any recorded value is a NaN or the intermediate sum is at
+ * any point a NaN, then the final sum will be NaN.
+ *
+ * If the recorded values contain infinities of opposite sign, the
+ * final sum will be NaN.
+ *
+ * It is possible for intermediate sums of finite values to
+ * overflow into opposite-signed infinities; if that occurs, the
+ * final sum will be NaN even if the recorded values are all
+ * finite.
+ *
+ * If the exact sum is infinite, a properly-signed infinity is
+ * returned.
+ *
+ * If 

Re: RFR: JDK-8042589: String.toLowerCase do not work for some concatenated strings

[Xueming Shen]

Let's fix the regression first, before make any more optimization :-)

-Sherman

On 07/17/2014 02:54 AM, Ulf Zibis wrote:

There is again another little optimization possible:

instead
hasSurr = true;
we could use
first = ~first;
and save variable hasSurr.

If there is register pressure (especially on older CPUs), this might be a 
performance advantage.

Also I think we should not grow the result array for any character where mapLen  
srcCount, we could wait until the result array is actually full.

-Ulf


Am 17.07.2014 00:55, schrieb Xueming Shen:

Still need a reviewer.

On 07/09/2014 01:04 PM, Xueming Shen wrote:

Hi,

Please help review the change for JDK-8042589.

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

This is a regression caused by the following change for #JDK-8032012,

issue:https://bugs.openjdk.java.net/browse/JDK-8032012
webrev: http://cr.openjdk.java.net/~sherman/8032012/
discussion: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-February/024862.html

It appears the last optimization for the surrogates we pushed in is
incomplete. We still need to check isSurrogate() in the optimized
non-surrogate loop, as the first (checked at the very beginning) might
be triggered by a non-surrogate-upper/lowercase char.

Thanks!
-Sherman

Re: please review draft JEP: Convenience Factory Methods for Collections

[Steven Schlansker]

On Jul 16, 2014, at 5:46 PM, Stuart Marks stuart.ma...@oracle.com wrote:

 Hi all,
 
 Please review this draft JEP for Convenience Factory Methods for Collections:
 
https://bugs.openjdk.java.net/browse/JDK-8048330
 
 Brief background: several times over the years there have been proposals to 
 add collection literals to the language. The most recent round of this was 
 in regard to JEP 186, a research JEP to explore this topic. That effort was 
 concluded by Brian Goetz, as summarized in this email:
 
http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html
 
 Essentially, the idea of adding collection literals to the language was set 
 aside in favor of adding some library APIs, not entirely unlike collection 
 literals, that make it more convenient to create collections. That's what 
 this proposal is.

This is fantastic, I think a large number of developers will cheer as more and 
more of Guava
makes it into core libs :)

One thing I notice is that you take a lot of care to not specify how the Map or 
Set will be implemented.
This could be troublesome because different implementations have different 
requirements for keys —
e.g. HashMap requires hashCode()/equals() but SortedMap requires compareTo().

It seems unlikely that the implementation could reasonably require anything 
other than equals() and maybe
hashCode(), but given the headache created by over/underspecifying maybe 
clarifying this is worth considering.

As another note, you briefly mentioned immutable implementations of Map, Set, 
and List.  These types are well
worth adding to the JDK in my opinion - if you try to design an immutable data 
structure containing such
types, you are forced to make many defensive copies to ensure they cannot later 
be modified.  With immutable
implementations, defensive copies are trivially cheap or free, which is a great 
boon to library maintainers.

Looking forward to being able to use this!
Steven

Re: please review draft JEP: Convenience Factory Methods for Collections

[Dan Smith]

The motivation section ought to more directly survey what we have now:
- Collections.emptyList/emptySet/emptyMap
- Collections.singletonList/singleton/singletonMap
- Arrays.asList
- EnumSet.of (varargs, plus some overloads)
- Stream.empty and Stream.of (singleton plus varargs)
- Constructors that, by convention, always have a variant that constructs an 
empty collection and another to copy the contents of an existing collection

This helps to clarify that there are multiple goals:
- Provide some default methods in List/Set/Map for easier access to existing 
behavior (following the pattern of EnumSet)
- Add new functionality to create immutable Sets/Maps for 2 = n = small 
number.
- (Maybe?) varargs methods to create immutable Sets/Maps or arbitrary size.
- Provide an array-less implementation of immutable Lists for 2 = n = small 
number.

--

If a mutable collection is desired, the contents of an immutable collection 
can easily be copied into a collection type of the caller's choice. ... If 
there are sufficient use cases to support convenient creation of mutable 
collections, factory methods for particular mutable collection classes could be 
added.

Following the existing convention, it might make more sense to make these 
constructors:
ArrayList()
ArrayList(Collection? extends E)
ArrayList(E...) // this is new

--

Converting a mutable collection into an immutable one is more difficult.

In principle, if you've got a varargs List creation method, there's nothing to 
stop you from overloading it with an Collection/Iterable/Stream version.  Same 
functionality, although this might encourage users to think that larger 
collections will behave properly.  (You could pass in a large array to the 
varargs method, but presumably most users will be passing in small varargs 
lists.)

--

I was curious about other collections that might benefit.
- It turns out Queue and Deque are pretty useless as immutable data structures.
- SortedSet and SortedMap could be useful.
- Stream could probably be made consistent with the overloading scheme you 
settle on; EnumSet, too, if it's different.
- There might be some use cases for Iterator; likely doesn't carry its weight, 
though.

—Dan

On Jul 16, 2014, at 6:46 PM, Stuart Marks stuart.ma...@oracle.com wrote:

 Hi all,
 
 Please review this draft JEP for Convenience Factory Methods for Collections:
 
https://bugs.openjdk.java.net/browse/JDK-8048330
 
 Brief background: several times over the years there have been proposals to 
 add collection literals to the language. The most recent round of this was 
 in regard to JEP 186, a research JEP to explore this topic. That effort was 
 concluded by Brian Goetz, as summarized in this email:
 
http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html
 
 Essentially, the idea of adding collection literals to the language was set 
 aside in favor of adding some library APIs, not entirely unlike collection 
 literals, that make it more convenient to create collections. That's what 
 this proposal is.
 
 Share and enjoy,
 
 s'marks
 

Re: Covariant overrides on the Buffer Hierarchy redux

[mark . reinhold]

2014/7/15 22:58 -0700, paul.san...@oracle.com:
 There was discussion here:
 
   http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026458.html
 
   https://bugs.openjdk.java.net/browse/JDK-4774077
 
   http://cr.openjdk.java.net/~rwarburton/buffer-overrides-1/
 
 The patch looks good.

Agreed!  Glad to see this (finally) get done.

- Mark

Re: please review draft JEP: Convenience Factory Methods for Collections

[Stuart Marks]

On 7/17/14 12:21 AM, Michael Kay wrote:

Set.of() and List.of() look very attractive; Map.of() looks very ugly.


The proposed Map.of() API offends our sensibilities as programmers, because of 
its repetition and its lack of generality. I think that's what you mean by 
ugly. There is a indeed certain amount of unpleasantness in the specification 
and implementation of the fix-arg Map.of() methods.


But this doesn't show up in actual usage.


I would much prefer to write something like

Map.of(
   Map.pair(key, value),
   Map.pair(key, value),
   Map.pair(key, value)
);

and have no limit on the number of pairs. (Don't care how it works 
internally...)



OK, let's posit the existance of a static Map.entry(k,v) method which will 
return an AbstractMap.SimpleImmutableEntry of (k,v). (AM.SIE would make a nice 
pair class but its name is so damned long!) Users will presumably statically 
import this method. One could then write:


MapString,Integer map = Map.of(
entry(BMW, 5),
entry(Mercedes, 3),
entry(Audi, 4),
entry(Ford, 10));

Compare this to the old-fashioned create-then-add technique:

MapString,Integer map = new HashMap();
map.put(BMW, 5);
map.put(Mercedes, 3);
map.put(Audi, 4);
map.put(Ford, 10);
map = Collections.unmodifiableMap(map);

Compared to this, the varargs list of entries reduces the visual clutter some, 
but not a tremendous amount. There is a smaller difference if you don't care to 
create the unmodifiable wrapper in the second case.


Now compare this to the proposed fixed-args version:

MapString,Integer map = Map.of(
BMW, 5,
Mercedes, 3,
Audi, 4,
Ford, 10);

That looks quite a bit simpler. In particular, there is no longer a pair of 
parentheses around each key-value pair like there is in the other example. That 
makes things visually much nicer in my estimation.


The varargs of map entries is clearly more general. Do we need that generality, 
and are we willing to put up with more clutter to get that generality?



The last thing I want is to have to rewrite all my code when someone asks me to 
add a sixth entry to the map initialization!


Well, Remi had proposed raising the limit. Suppose we offered 7 key-value pairs 
instead of 5. Would you then complain about having to rewrite your code if you 
had to add an 8th entry to the map? (Repeat for any N, N+1.) A fixed-arg 
approach, while not fully general, can be tailored to solve 80%, or 95%, or 
99.9%, or whatever percentage of the cases we choose to solve. Beyond a certain 
point the benefit provided by a varargs approach vs a fixed N approach becomes 
vanishingly small. I don't have the numbers at my fingertips, that point is 
reached very quickly, say around N = 5. But maybe it's a bit higher.


The tradeoff here is that we are willing to put up with a certain amount of API 
ugliness in order to make people's programs nicer. If we can cover a vast 
majority of people's cases, that's just fine, even if it's not fully general.


s'marks


(Example data from examples.javacodegeeks.com)



Michael Kay
Saxonica
m...@saxonica.com
+44 (0118) 946 5893



On 17 Jul 2014, at 01:46, Stuart Marks stuart.ma...@oracle.com wrote:


Hi all,

Please review this draft JEP for Convenience Factory Methods for Collections:

https://bugs.openjdk.java.net/browse/JDK-8048330

Brief background: several times over the years there have been proposals to add 
collection literals to the language. The most recent round of this was in 
regard to JEP 186, a research JEP to explore this topic. That effort was concluded by 
Brian Goetz, as summarized in this email:

http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html

Essentially, the idea of adding collection literals to the language was set 
aside in favor of adding some library APIs, not entirely unlike collection 
literals, that make it more convenient to create collections. That's what this 
proposal is.

Share and enjoy,

s'marks

Re: please review draft JEP: Convenience Factory Methods for Collections

[Stuart Marks]

On 7/17/14 12:46 AM, Tom Hawtin wrote:

I note that with the basic proposal, HashSet.of and indeed NavigableSet.of still
work. They just do the wrong thing.


I should have made more clear in the JEP that the proposed APIs are static 
methods on the List/Map/Set interfaces, not default methods. Thus they won't be 
inherited by any subinterfaces or implementors.


s'marks

RFR: 8051057: (s) Optimize StringCharBuffer.toString(int, int)

[Mike Duigou]

Hello all; 

While investigating another issue I ran across some code in 
java.nio.StringCharBuffer.toString(int, int) which might be possible to 
improve. Currently the implementation calls toString() on the source 
CharSequence and then uses String.substring to create the desired range. For 
the current String, StringBuilder and StringBuffer implementations it would be 
more efficient to first generate the subSequence via 
CharSequence.subSequence(int, int) and then call toString() on the 
sub-sequence. For these classes the toString() is actually a NOP as their 
CharSequence.subSequence(int, int) implementations return a String instance.

I looked for other CharSequence implementations and couldn't find any which 
would preform better with current StringCharBuffer.toString(int, int) 
implementation. 

jbsbug: https://bugs.openjdk.java.net/browse/JDK-8051057
webrev: http://cr.openjdk.java.net/~mduigou/JDK-8051057/0/webrev/

Does this seem like a worthwhile improvement for all of the important 
CharSequence implementations?

Mike

Re: please review draft JEP: Convenience Factory Methods for Collections

[Stuart Marks]

On 7/17/14 10:17 AM, Steven Schlansker wrote:

This is fantastic, I think a large number of developers will cheer as more and 
more of Guava
makes it into core libs :)


Great!


One thing I notice is that you take a lot of care to not specify how the Map or 
Set will be implemented.
This could be troublesome because different implementations have different 
requirements for keys —
e.g. HashMap requires hashCode()/equals() but SortedMap requires compareTo().

It seems unlikely that the implementation could reasonably require anything 
other than equals() and maybe
hashCode(), but given the headache created by over/underspecifying maybe 
clarifying this is worth considering.


First, I should clarify that these are static factory methods on the interfaces, 
not default methods. Thus they aren't inherited, and there won't be any 
complications arising from additional subinterface requirements, such as how 
SortedMap requires elements to be Comparable. (Unless a comparator is provided, 
etc.)


The implementations of instances returned by these factory methods fulfil just 
the basic interfaces. In particular, the notion of duplicate elements or keys 
for Set and Map are defined by equals(), so that's all they have to support.



As another note, you briefly mentioned immutable implementations of Map, Set, 
and List.  These types are well
worth adding to the JDK in my opinion - if you try to design an immutable data 
structure containing such
types, you are forced to make many defensive copies to ensure they cannot later 
be modified.  With immutable
implementations, defensive copies are trivially cheap or free, which is a great 
boon to library maintainers.


Yes, I certainly see the value in having implementations of immutable 
collections. There would be some relationship to this convenience factories 
project, but they aren't necessarily the same thing. If a couple really useful 
immutable implementations could be slipped in, sure, it might work out. But if 
it turns into a big design discussion with lots of different implementations -- 
consider ImmutableHashMap, ImmutableTreeMap, etc. -- then it begins to sound 
like a different effort.


s'marks

Re: please review draft JEP: Convenience Factory Methods for Collections

[Stuart Marks]

Hi Dan, thanks for the feedback.

On 7/17/14 10:40 AM, Dan Smith wrote:

The motivation section ought to more directly survey what we have now:
- Collections.emptyList/emptySet/emptyMap
- Collections.singletonList/singleton/singletonMap
- Arrays.asList
- EnumSet.of (varargs, plus some overloads)
- Stream.empty and Stream.of (singleton plus varargs)
- Constructors that, by convention, always have a variant that constructs an 
empty collection and another to copy the contents of an existing collection

This helps to clarify that there are multiple goals:
- Provide some default methods in List/Set/Map for easier access to existing 
behavior (following the pattern of EnumSet)
- Add new functionality to create immutable Sets/Maps for 2 = n = small 
number.
- (Maybe?) varargs methods to create immutable Sets/Maps or arbitrary size.
- Provide an array-less implementation of immutable Lists for 2 = n = small 
number.


WAT, you mean not everybody is a collections expert? :-)

Sure, I could add some background here. The relationship with the 
Collections.empty* and Collections.singleton* methods is especially interesting. 
They're not very discoverable; they're somewhat verbose, and the naming is odd. 
(Where is singletonSet? oh.) The implementation returned by Arrays.asList is 
also incredibly useful but is something of a strange beast compared to other 
collections.



If a mutable collection is desired, the contents of an immutable collection can easily be 
copied into a collection type of the caller's choice. ... If there are sufficient use 
cases to support convenient creation of mutable collections, factory methods for particular mutable 
collection classes could be added.

Following the existing convention, it might make more sense to make these 
constructors:
ArrayList()
ArrayList(Collection? extends E)
ArrayList(E...) // this is new


Note there is also ArrayList(int initialCapacity).

This brings in the old constructor-vs-factory-method discussion. A constructor 
is reasonable since we have no intention of returning an instance of a subclass, 
which would be a point in favor of a static factory. But I'm concerned about 
adding the varargs constructor next to existing constructors. Many of the 
collections have additional constructors besides the ones provided by 
convention. There may not be any actual ambiguity, but surprising behaviors 
would result. For example, in


ListInteger list1 = new ArrayList(1, 2);
ListInteger list2 = new ArrayList(3);

list1 would be [1, 2] as expected but list2 would be an empty list with an 
initial capacity of 3.


HashSet has a similar issues with the constructor

HashSet(int initialCapacity, float loadFactor)


Converting a mutable collection into an immutable one is more difficult.

In principle, if you've got a varargs List creation method, there's nothing to 
stop you from overloading it with an Collection/Iterable/Stream version.  Same 
functionality, although this might encourage users to think that larger 
collections will behave properly.  (You could pass in a large array to the 
varargs method, but presumably most users will be passing in small varargs 
lists.)


What I meant by ...is more difficult is that, prior to any of these proposals, 
creating an immutable collection when given a mutable one is more difficult. (Or 
at least, it's a pain.) You could copy the collection into a new collection, and 
then wrap it in an unmodifiable wrapper. Or you could import a third party 
library with actual immutable collections. Or you could write your own.


I guess I should clarify this too.

If we were to add a family of immutable collections to the JDK, as has popped up 
a couple times on this thread, its constructors or factories should clearly be 
able to consume other collections, streams, etc.




I was curious about other collections that might benefit.
- It turns out Queue and Deque are pretty useless as immutable data structures.
- SortedSet and SortedMap could be useful.
- Stream could probably be made consistent with the overloading scheme you 
settle on; EnumSet, too, if it's different.
- There might be some use cases for Iterator; likely doesn't carry its weight, 
though.


Yes, interesting. Most collection implementations have special features that 
apply to mutability. The Sorted (or maybe Navigable) variations of Set or Map 
could be useful though.


s'marks




—Dan

On Jul 16, 2014, at 6:46 PM, Stuart Marks stuart.ma...@oracle.com wrote:


Hi all,

Please review this draft JEP for Convenience Factory Methods for Collections:

https://bugs.openjdk.java.net/browse/JDK-8048330

Brief background: several times over the years there have been proposals to add 
collection literals to the language. The most recent round of this was in 
regard to JEP 186, a research JEP to explore this topic. That effort was concluded by 
Brian Goetz, as summarized in this email:

http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html

Re: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code

[John Rose]

On Jul 16, 2014, at 11:20 AM, Peter Levart peter.lev...@gmail.com wrote:

 An alternative could be:
 
 public Throwable throwIfUnchecked() {
if (this instanceof RuntimeException) throw (RuntimeException) this;
if (this instanceof Error) throw (Error) this;
 return this;
 }
 
 Then use it like:
 
try {
...
} catch (Throwable t) {
throw new WrapperException(t.throwIfUnchecked());
}

I like this one.  (I wish we could declare This types, so that 
TYPEOF[t.throwIfUnchecked()] == TYPEOF[t].)

It puts the throw of the less dangerous exception type inside the subroutine, 
making the wrapping and the more dangerous (more ad hoc) exception be 
explicit and in-line.

To complete the picture, add:

public X extends Throwable Throwable throwIf(ClassX exClass) throws X {
   if (exClass.isInstance(this)) throw exClass.cast(this);
   return this;
}

...to be used as:

   try {
   ...
   } catch (Throwable t) {
   t.throwIfUnchecked().throwIf(X.class).throwIf(Y.class).throwIf(Z.class);
   throw new WrapperException(t);
   }

Or some other combination of sequential and/or fluent calls.

— John

Different notations for static and instance methods

[Wang Weijun]

We should define different notations for static and instance methods.

For example, List.of and List::of, although I admit it is quite confusing.

--Max

On Jul 18, 2014, at 5:56, Stuart Marks stuart.ma...@oracle.com wrote:

 On 7/17/14 12:46 AM, Tom Hawtin wrote:
 I note that with the basic proposal, HashSet.of and indeed NavigableSet.of 
 still
 work. They just do the wrong thing.
 
 I should have made more clear in the JEP that the proposed APIs are static 
 methods on the List/Map/Set interfaces, not default methods. Thus they won't 
 be inherited by any subinterfaces or implementors.
 
 s'marks

Re: [9] RFR (M): 8050052: Small cleanups in java.lang.invoke code

[John Rose]

FTR, I captured this issue:

  https://bugs.openjdk.java.net/browse/JDK-8051294

(Wish they were all so easy to catch.)

— John

On Jul 17, 2014, at 5:12 PM, John Rose john.r.r...@oracle.com wrote:

 On Jul 16, 2014, at 11:20 AM, Peter Levart peter.lev...@gmail.com wrote:
 
 An alternative could be:
 
 public Throwable throwIfUnchecked() {
   if (this instanceof RuntimeException) throw (RuntimeException) this;
   if (this instanceof Error) throw (Error) this;
 return this;
 }
 
 Then use it like:
 
   try {
   ...
   } catch (Throwable t) {
   throw new WrapperException(t.throwIfUnchecked());
   }
 
 I like this one.  (I wish we could declare This types, so that 
 TYPEOF[t.throwIfUnchecked()] == TYPEOF[t].)
 
 It puts the throw of the less dangerous exception type inside the 
 subroutine, making the wrapping and the more dangerous (more ad hoc) 
 exception be explicit and in-line.
 
 To complete the picture, add:
 
 public X extends Throwable Throwable throwIf(ClassX exClass) throws X {
   if (exClass.isInstance(this)) throw exClass.cast(this);
   return this;
 }
 
 ...to be used as:
 
   try {
   ...
   } catch (Throwable t) {
   t.throwIfUnchecked().throwIf(X.class).throwIf(Y.class).throwIf(Z.class);
   throw new WrapperException(t);
   }
 
 Or some other combination of sequential and/or fluent calls.
 
 — John

Re: please review draft JEP: Convenience Factory Methods for Collections

[Tom Hawtin]

On 17/07/2014 22:56, Stuart Marks wrote:

On 7/17/14 12:46 AM, Tom Hawtin wrote:

I note that with the basic proposal, HashSet.of and indeed
NavigableSet.of still
work. They just do the wrong thing.


I should have made more clear in the JEP that the proposed APIs are
static methods on the List/Map/Set interfaces, not default methods. Thus
they won't be inherited by any subinterfaces or implementors.


Ah, static methods of interfaces behave differently to class methods. 
The language corner case I'm missing is in 8.4.8 (of Java SE 8 JLS) for 
classes


  A class does not inherit static methods from its superinterfaces.

and 9.2 for interfaces (if I've parsed this correctly)

  The interface inherits, from the interfaces it extends, all members 
of those interfaces, except for fields, classes, and interfaces that it 
hides; abstract or default methods that it overrides (9.4.1); and static 
methods.


Tom

Review request for 8050968: Extension class loader initialization fails on Win7 x64 zh_TW

[Mandy Chung]

This is a regression caused by JDK-8038177 that changed
sun.nio.cs.ext.ExtendedCharsets to use lambda.  It turns out that
ExtendedCharsets is loaded during the initialization of the extension
class loader when opening jre/lib/ext/meta-index on windows with system
locale loading extended charsets and caused the initialization error.

The fix is not to avoid lambda in ExtendedCharsets getting the system
property value.  At some point in the future, I'd like to take a closer
look at the system initialization path and what we can do better.

Webrev at:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050968/webrev.00/

thanks
Mandy

Re: Review request for 8050968: Extension class loader initialization fails on Win7 x64 zh_TW

[David Holmes]

Hi Mandy,

On 18/07/2014 2:57 PM, Mandy Chung wrote:


On 7/17/2014 9:56 PM, Mandy Chung wrote:

This is a regression caused by JDK-8038177 that changed
sun.nio.cs.ext.ExtendedCharsets to use lambda.  It turns out that
ExtendedCharsets is loaded during the initialization of the extension
class loader when opening jre/lib/ext/meta-index on windows with system
locale loading extended charsets and caused the initialization error.

The fix is not to avoid lambda in ExtendedCharsets getting the system


s/avoid/use


This looks okay to me.

It is unfortunately very hard to know how introducing a lambda 
expression can affect the initialization order, particularly when it may 
depend on locales etc.


David
-


Mandy


property value.  At some point in the future, I'd like to take a closer
look at the system initialization path and what we can do better.

Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8050968/webrev.00/

thanks
Mandy