hg: jdk8/tl/jdk: 8024253: ThreadLocal random can use SecureRandom for the initial seed

[paul . sandoz]

Changeset: 7913855ff66c
Author:psandoz
Date:  2013-09-20 11:07 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7913855ff66c

8024253: ThreadLocal random can use SecureRandom for the initial seed
Reviewed-by: psandoz, chegar, alanb
Contributed-by: Doug Lea , Peter Levart 
, Guy Steele 

! src/share/classes/java/util/SplittableRandom.java
! src/share/classes/java/util/concurrent/ThreadLocalRandom.java
! test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java

hg: jdk8/tl/jdk: 8024341: j.u.regex.Pattern.splitAsStream() doesn't correspond to split() method if using an example from the spec

[paul . sandoz]

Changeset: c30dc8e7744e
Author:psandoz
Date:  2013-09-20 17:11 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c30dc8e7744e

8024341: j.u.regex.Pattern.splitAsStream() doesn't correspond to split() method 
if using an example from the spec
Reviewed-by: alanb

! src/share/classes/java/util/regex/Pattern.java
+ test/java/util/regex/PatternStreamTest.java
- test/java/util/regex/PatternTest.java

hg: jdk8/tl/jdk: 8024408: Specifications for Collection/List/Set/SortedSet.spliterator() need to document if all the (subclass) instances are required to return SIZED spliterators

[paul . sandoz]

Changeset: f8b3ab514564
Author:psandoz
Date:  2013-10-01 12:19 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8b3ab514564

8024408: Specifications for Collection/List/Set/SortedSet.spliterator() need to 
document if all the (subclass) instances are required to return SIZED 
spliterators
Reviewed-by: alanb

! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/SortedSet.java
! test/java/util/Spliterator/SpliteratorCharacteristics.java

hg: jdk8/tl/jdk: 8025535: Unsafe typecast in java.util.stream.SortedOps

[paul . sandoz]

Changeset: e1b04fd49204
Author:psandoz
Date:  2013-10-01 18:20 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1b04fd49204

8025535: Unsafe typecast in java.util.stream.SortedOps
Reviewed-by: mduigou, chegar

! src/share/classes/java/util/stream/SortedOps.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java

hg: jdk8/tl/jdk: 2 new changesets

[paul . sandoz]

Changeset: 811c35a6a58f
Author:psandoz
Date:  2013-10-02 16:34 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/811c35a6a58f

8025534: Unsafe typecast in java.util.stream.Streams.Nodes
8025538: Unsafe typecast in java.util.stream.SpinedBuffer
8025533: Unsafe typecast in 
java.util.stream.Streams.RangeIntSpliterator.splitPoint()
8025525: Unsafe typecast in java.util.stream.Node.OfPrimitive.asArray()
Reviewed-by: chegar

! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/SortedOps.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! src/share/classes/java/util/stream/Streams.java

Changeset: c55a7941050c
Author:psandoz
Date:  2013-10-03 10:59 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c55a7941050c

8025567: Mark relevant public stream tests as serialization hostile
Reviewed-by: alanb

! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java

hg: jdk8/tl/jdk: 8025136: SplittableRandom enchancements

[paul . sandoz]

Changeset: b90dcd1a71bf
Author:psandoz
Date:  2013-10-08 11:17 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b90dcd1a71bf

8025136: SplittableRandom enchancements
Reviewed-by: psandoz, martin
Contributed-by: Doug Lea , Guy Steele 


! src/share/classes/java/util/Random.java
! src/share/classes/java/util/SplittableRandom.java
! src/share/classes/java/util/concurrent/ThreadLocalRandom.java

hg: jdk8/tl/jdk: 8020061: Clarify reporting characteristics between splits

[paul . sandoz]

Changeset: 1cd20806fd5c
Author:psandoz
Date:  2013-10-09 15:19 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1cd20806fd5c

8020061: Clarify reporting characteristics between splits
Reviewed-by: alanb, chegar

! src/share/classes/java/util/Spliterator.java

hg: jdk8/tl/jdk: 8027316: Distinct operation on an unordered stream should not be a barrier

[paul . sandoz]

Changeset: 18c111c17231
Author:psandoz
Date:  2013-10-31 11:59 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18c111c17231

8027316: Distinct operation on an unordered stream should not be a barrier
Reviewed-by: henryjen, mduigou, briangoetz

! src/share/classes/java/util/stream/DistinctOps.java
! src/share/classes/java/util/stream/StreamSpliterators.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java

hg: jdk8/tl/jdk: 8027712: DistinctOpTest fails for unordered test

[paul . sandoz]

Changeset: d5b3f83ffc40
Author:psandoz
Date:  2013-11-05 12:08 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5b3f83ffc40

8027712: DistinctOpTest fails for unordered test
Reviewed-by: henryjen, alanb

! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java

hg: jdk8/tl/jdk: 8028516: Java doc error in Int/Long/Double/Stream.peek

[paul . sandoz]

Changeset: 1f45b24ffe4b
Author:psandoz
Date:  2013-11-25 09:55 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f45b24ffe4b

8028516: Java doc error in Int/Long/Double/Stream.peek
Reviewed-by: chegar

! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Stream.java

hg: jdk8/tl/jdk: 8029164: Race condition in CompletableFuture.thenCompose with asynchronous task

[paul . sandoz]

Changeset: 2aa455506c49
Author:psandoz
Date:  2013-12-04 10:27 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2aa455506c49

8029164: Race condition in CompletableFuture.thenCompose with asynchronous task
Reviewed-by: dl, chegar, mduigou

! src/share/classes/java/util/concurrent/CompletableFuture.java
+ test/java/util/concurrent/CompletableFuture/ThenComposeAsyncTest.java

hg: jdk8/tl/jdk: 8028564: Concurrent calls to CHM.put can fail to add the key/value to the map

[paul . sandoz]

Changeset: dc2f0c40399a
Author:psandoz
Date:  2013-12-05 09:44 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dc2f0c40399a

8028564: Concurrent calls to CHM.put can fail to add the key/value to the map
Reviewed-by: psandoz, chegar, alanb
Contributed-by: Doug Lea 

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
+ test/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java
+ test/java/util/concurrent/ConcurrentHashMap/ConcurrentContainsKeyTest.java

hg: jdk8/tl/jdk: 8031187: DoubleStream.count is incorrect for a stream containing > Integer.MAX_VALUE elements

[paul . sandoz]

Changeset: 630a92015993
Author:psandoz
Date:  2014-01-09 10:52 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/630a92015993

8031187: DoubleStream.count is incorrect for a stream containing > 
Integer.MAX_VALUE elements
Reviewed-by: darcy

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountLargeTest.java
+ test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java

hg: jdk8/tl/jdk: 8032190: Specifications of stream flatMap methods should require mapped streams to be closed

[paul . sandoz]

Changeset: 68eb0c55a8c0
Author:psandoz
Date:  2014-01-21 10:49 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68eb0c55a8c0

8032190: Specifications of stream flatMap methods should require mapped streams 
to be closed
Reviewed-by: chegar, alanb

! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Stream.java

hg: jdk8/tl/jdk: 4 new changesets

[paul . sandoz]

Changeset: 9f098aed44c0
Author:anazarov
Date:  2014-01-31 12:01 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f098aed44c0

8032025: Update repeating annotations demo
Reviewed-by: jfranck

+ 
src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Device.java
+ 
src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Kettle.xml
+ 
src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Module.java
+ 
src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/PluginChecker.java
+ 
src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Require.java
+ 
src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/RequireContainer.java
+ 
src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/BoilerPlugin.java
+ 
src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/ExtendedBoilerPlugin.java
+ 
src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/TimerPlugin.java
+ src/share/sample/annotations/Validator/src/PositiveIntegerSupplier.java
+ src/share/sample/annotations/Validator/src/SupplierValidator.java
+ src/share/sample/annotations/Validator/src/Validate.java
+ src/share/sample/annotations/Validator/src/Validator.java
+ src/share/sample/annotations/index.html

Changeset: f72a8df6a2ed
Author:anazarov
Date:  2014-01-31 12:01 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f72a8df6a2ed

8031650: Update bulk operation demo
Reviewed-by: psandoz, mduigou

+ src/share/sample/lambda/BulkDataOperations/index.html
+ src/share/sample/lambda/BulkDataOperations/src/CSVProcessor.java
+ src/share/sample/lambda/BulkDataOperations/src/Grep.java
+ src/share/sample/lambda/BulkDataOperations/src/PasswordGenerator.java
+ src/share/sample/lambda/BulkDataOperations/src/WC.java

Changeset: 4574011c1689
Author:anazarov
Date:  2014-01-31 12:01 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4574011c1689

8032020: Update try-with-resources demo
Reviewed-by: darcy, alanb, smarks

+ src/share/sample/try-with-resources/index.html
+ src/share/sample/try-with-resources/src/CustomAutoCloseableSample.java
+ src/share/sample/try-with-resources/src/Unzip.java
+ src/share/sample/try-with-resources/src/ZipCat.java

Changeset: a4f68fc5f353
Author:psandoz
Date:  2014-01-31 12:01 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4f68fc5f353

8032056: Create demo to illustrate new practices of the default methods usage
Reviewed-by: briangoetz, rfield, psandoz
Contributed-by: taras.led...@oracle.com

+ src/share/sample/lambda/DefaultMethods/ArrayIterator.java
+ src/share/sample/lambda/DefaultMethods/DiamondInheritance.java
+ src/share/sample/lambda/DefaultMethods/Inheritance.java
+ src/share/sample/lambda/DefaultMethods/MixIn.java
+ src/share/sample/lambda/DefaultMethods/Reflection.java
+ src/share/sample/lambda/DefaultMethods/SimplestUsage.java

JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

[Paul Sandoz]

Hi,

This is a request for review of Otavio's patch replacing StringBuffer with 
StringBuilder within OpenJDK. (I also need to review it.)

It covers many areas and i have grouped the patches into such areas to aid 
reviewing. When commenting please including core-libs.

Jtreg tests showed no regressions, but when reviewing we need to be mindful of 
the context e.g. if the buffer escapes and can cross thread boundaries. 

This is also an experiment to see if we can review the whole thing under one 
bug :-) if things prove problematic and slow we can split it out. Many files 
are touched but there are not many changes to each file and changes are very 
formulaic.

I have also included ASM related changes, but i suspect we may have to leave 
those alone since such changes will make it more difficult to pull in ASM from 
upstream.
 
-

Otavio, for the record can you reply to this thread posting your single 
("uber") patch as textual attachment? (IIUC such attachments should now be 
supported by the email server).

Paul.

- core
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/

- io
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/

- management
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/

- rmi
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/

- security
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/


- tools
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/


- graphics/media
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/


- asm
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

[Paul Sandoz]

On May 12, 2014, at 12:42 PM, Alan Bateman  wrote:

> On 12/05/2014 11:03, Paul Sandoz wrote:
>> 
>> It covers many areas and i have grouped the patches into such areas to aid 
>> reviewing. When commenting please including core-libs.
> The groupings are a bit odd

Yeah, definitely idiosyncratic, i tried to lump 'em in terms of areas where 
people could focus their expertise without creating too few or too many webrevs.


> but I looked through the -core, -io, -management and -rmi patches and don't 
> see any issues.

Thanks!


> Nothing jumped out to suggest that the StringBuffer could be leaked to other 
> threads. There are a few cases where additional work could be done but I 
> assume you want to focus on s/StringBuffer/StringBuilder/g.
> 

It might be worth fixing those if they are not too disruptive.


> You might want to hear from Remi or Kumar before including asm. I mention it 
> because there might be preference to get changes to ASM done upstream to 
> avoid the copy in OpenJDK from diverging.
> 

Yes.


> As a general point then I don't see any reason why this can't be one 
> change-set. Periodically it makes sense to do a coarse grain split, say core 
> + client but shouldn't be necessary here, unless of course there is some 
> major refactoring or other big changes in, or coming soon to, jdk9/client. A 
> coarse grain split just reduced the need for merging when sync'ing up 
> integration forests.
> 

Ok.


> One minor comment is that refactoring where you change the name of the local 
> can sometimes impact the alignment of statement that span several lines. 
> VMID.toString is the only one that I noticed here and it's no big deal.
> 

I fixed that.

Paul.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

[Paul Sandoz]

On May 12, 2014, at 1:00 PM, Ivan Gerasimov  wrote:

> src/share/classes/sun/misc/UUDecoder.java
> 126 StringBuilder x = new StringBuilder();
> Is only filled, but doesn't seem to be used anyhow.
> Maybe just delete it?
> 

Thanks, i will take a look at this and your other change once 
s/StringBuffer/StringBuilder/g is out of the way.

Paul.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

[Paul Sandoz]

On May 12, 2014, at 4:07 PM, Daniel Fuchs  wrote:

> Hi Paul,
> 
> I looked at -management and the changes there look good.
> 
> There is just some two spaces vs four space formatting in
> 
> line 99.
> 

Thanks, updated.

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR 8049220: URL.factory data race

[Paul Sandoz]

On Jul 3, 2014, at 6:33 PM, Alan Bateman  wrote:
> On 03/07/2014 09:43, Peter Levart wrote:
>> Hi,
>> 
>> I noticed a data race in java.net.URL:
>> 
>>https://bugs.openjdk.java.net/browse/JDK-8049220
>> 
>> I propose the following simple patch:
>> 
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.01/
>> 
> A good catch and the change looks good to me.  

Yes, well spotted. May i suggest that the following comment is updated:

1109 factory = fac; // volatile write

to say something about ensuring safe publication of a constructed handle? since 
it is often quite tricky to reason about why a volatile write is needed (to 
stamp in, at least, a StoreStore barrier).

For JMM v9 we may not need to mark such a ref as volatile.


> I assume it just wasn't noticed because it can only be set once and probably 
> rared used too.
> 

Yeah, i wonder whether it would ever get optimized/inlined to the point at 
which re-ordering could practically happen.

Paul.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR 8049220: URL.factory data race

[Paul Sandoz]

On Jul 7, 2014, at 1:07 PM, Peter Levart  wrote:

> Hi Pavel, Alan and Paul,
> 
> Thanks for reviewing. I accepted the suggestions from Pavel and Paul and 
> created webrev.02:
> 
> http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.02/
> 
> Is this good to go into jdk9-dev?
> 

Looks ok.

Paul.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: The future of Serialization

[Paul Sandoz]

On Aug 9, 2014, at 7:20 PM, Brian Goetz  wrote:

>> I've noticed there's not much interest in improving Serialization on
>> these lists.  This makes me wonder if java Serialization has lost
>> relevance in recent years with the rise of protocol buffers apache
>> thrift and other means of data transfer over byte streams.
> 
> I sense your frustration, but I think you may be reaching the wrong 
> conclusion.  The lack of response is probably not evidence that there's no 
> interest in fixing serialization; its that fixing serialization, with all the 
> constraints that "fix" entails, is just really really hard, and its much 
> easier to complain about it (and even say "let's just get rid of it") than to 
> fix it.
> 
>> Should Serializable eventually be deprecated? Should Serialization be
>> disabled by default? Should a new mechanism be developed? If a new
>> mechanism is developed, what about circular object relationships?
> 
> As I delved into my own explorations of serialization, I started to realize 
> why such a horrible approach was the one that was ultimately chosen; while 
> serialization is horrible and awful and leaky and insecure and complex and 
> brittle, it does address problems like cyclic data structures and independent 
> evolution of subclass and superclass better than the "clean" models.
> 
> My conclusion is, at best, a new mechanism would have to live side-by-side 
> with the old one, since it could only handle 95% of the cases.  It might 
> handle those 95% much better -- more cleanly, securely, and allowing easier 
> schema evolution -- but the hard cases are still there.  Still, reducing the 
> use of the horrible old mechanism may still be a worthy goal, even if it 
> can't be killed outright.
> 


Also many serialization-based libraries use sun.misc.Unsafe or 
sun.reflect.ReflectionFactory for various reasons (with backup plans if such 
classes are not available or accessible).

As part to the future of serialization i think we need to evaluate libraries 
such as XStream and Objenesis  to see what unsafe/internal mechanisms can be 
replaced by functionally equivalent safe public mechanisms.

I have more questions than answers at the moment with regards to that :-(

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR 8064924: Update java.net.URL to work with modules

[Paul Sandoz]

On Jan 30, 2015, at 10:10 PM, Alan Bateman  wrote:

> On 30/01/2015 15:35, Chris Hegarty wrote:
>> :
>> 
>> Update webrev and spec diffs:
>>http://cr.openjdk.java.net/~chegar/8064924/01/
>> 
> I think the javadoc looks much better now, thanks.
> 

Minor comments in URL:

Java doc on URL constructor:

 269  * If the previous step fails to find a protocol handler, then the
 270  * {@linkplain java.util.ServiceLoader ServiceLoader} mechanism is 
used
 271  * to locate a {@code URLStreamHandlerFactory} provider using the 
system

"to locate {@code URLStreamHandlerFactory} providers using..."

Using the plural reads better given what follows:


 272  * class loader. The ordering that providers are located is
 273  * implementation specific, and an implementation is free to cache 
the
 274  * located providers. A {@linkplain 
java.util.ServiceConfigurationError
 275  * ServiceConfigurationError}, {@code Error} or {@code 
RuntimeException}
 276  * thrown from the {@code createURLStreamHandler}, if encountered, 
will
 277  * be propagated to the calling thread. The {@code
 278  * createURLStreamHandler} method of each provider, if 
instantiated, is
 279  * invoked, with the protocol string, until a provider returns 
non-null,
 280  * or all providers have been exhausted.



In getURLStreamHandler method:

1313 if (handler == null) {
1314 // Try the built-in protocol handler
1315 handler = defaultFactory.createURLStreamHandler(protocol);
1316 }
1317 
1318 synchronized (streamHandlerLock) {
1319 
1320 URLStreamHandler handler2 = null;
1321 
1322 // Check again with hashtable just in case another
1323 // thread created a handler since we last checked
1324 handler2 = handlers.get(protocol);
1325 
1326 if (handler2 != null) {
1327 return handler2;
1328 }
1329 
1330 // Check with factory if another thread set a
1331 // factory since our last check
1332 if (!checkedWithFactory) {
1333 handler2 = handlerFromSettableFactory(protocol);
1334 }
1335 
1336 if (!(handler2 == null || handler2 == NULL_HANDLER)) {
1337 // The handler from the factory must be given more
1338 // importance. Discard the default handler that
1339 // this thread created.
1340 handler = handler2;
1341 }
1342 
1343 // Insert this handler into the hashtable
1344 if (handler != null) {
1345 handlers.put(protocol, handler);
1346 }
1347 
1348 }


The code might read better if you place the stuff above the synchronized block 
within it (assuming that causes no issues):

  if (!checkedFactory) {
handle = handlerFromSettableFactory(protocol);
if (handle == NULL_HANDLER) handle = null;
  }
  if (handle == null) {
handler = defaultFactory.createURLStreamHandler(protocol);
  }
  if (handle != null) {
handlers.put(protocol, handler); 
  }

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR 8064924: Update java.net.URL to work with modules

[Paul Sandoz]

On Feb 2, 2015, at 12:34 PM, Chris Hegarty  wrote:

> On 02/02/15 11:00, Paul Sandoz wrote:
>> 
>> On Jan 30, 2015, at 10:10 PM, Alan Bateman  wrote:
>> 
>>> On 30/01/2015 15:35, Chris Hegarty wrote:
>>>> :
>>>> 
>>>> Update webrev and spec diffs:
>>>>http://cr.openjdk.java.net/~chegar/8064924/01/
>>>> 
>>> I think the javadoc looks much better now, thanks.
>>> 
>> 
>> Minor comments in URL:
>> 
>> Java doc on URL constructor:
>> 
>>  269  * If the previous step fails to find a protocol handler, then 
>> the
>>  270  * {@linkplain java.util.ServiceLoader ServiceLoader} mechanism 
>> is used
>>  271  * to locate a {@code URLStreamHandlerFactory} provider using 
>> the system
>> 
>> "to locate {@code URLStreamHandlerFactory} providers using..."
> 
> Thanks Paul, Updated in the latest version ( see other mail ).
> 

Ok.


>> 
>> The code might read better if you place the stuff above the synchronized 
>> block within it (assuming that causes no issues):
>> 
>>   if (!checkedFactory) {
>> handle = handlerFromSettableFactory(protocol);
>> if (handle == NULL_HANDLER) handle = null;
>>   }
>>   if (handle == null) {
>> handler = defaultFactory.createURLStreamHandler(protocol);
>>   }
>>   if (handle != null) {
>> handlers.put(protocol, handler);
>>   }
> 
> That is a possibility, but great effort has been put into this area recently, 
> by Peter, to attempt to keep the lookup of handlers lock free ( typically a 
> volatile read, only requiring the lock when updating the cache ).
> 
> We would also not want to hold the lock while performing the service lookup, 
> in which case we may end up with two synchronization blocks, so as to keep 
> the service lookup as lazy as possible. Or have I missed our point?
> 

It was specifically to do with the optimistic call to 
defaultFactory.createURLStreamHandle the result of which might be thrown away, 
but probably not. The method handlerFromSettableFactory is anyway called from 
within the synchronized so it did not seem a big deal to pull in default 
factory call and simplify the logic.

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as a fallback for migration

[Paul Sandoz]

On Apr 14, 2015, at 9:33 PM, Alan Bateman  wrote:

> On 14/04/2015 17:24, Chris Hegarty wrote:
>> The work done as part of JDK-8064924 [1] to introduce a new service type, 
>> java.net.spi.URLStreamHandlerProvider, provides a clean provider mechanism 
>> that will work well with modules. That part of the change should remain, but 
>> the removal of support to find handlers through the 
>> java.protocol.handler.pkgs system property is problematic, and could be an 
>> impediment to moving to JDK 9. Applications making use of custom protocol 
>> handlers and not packaged as modules should continue to be able to use this 
>> property.
>> 
>> The proposal is to reinstate the JDK 8 specification about 
>> java.protocol.handler.pkgs in java.net.URL., that documents the search 
>> order for handlers. Additionally reinstate the JDK 8 implementation code to 
>> search the system property after the service loader lookup.
>> 
>> http://cr.openjdk.java.net/~chegar/8075139/webrev.00/
>> 
>> The spec and code changes in the above webrev are almost identical to the 
>> original code pre 8064924.
>> 
>> -Chris.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8064924
> This looks okay to me although maybe we can use the opportunity to replace 
> the use of StringTokenizer with a regex.
> 

Yes, one could use a Pattern.splitAsStream, sorry could not resist :-) assuming 
this area is not sensitive to bootstrap issues e.g.

  hander = 
p.splitAsStream().map(String::trim).flatMap(this::getHandler).findFirst().orElse(null);

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as a fallback for migration

[Paul Sandoz]

On Apr 15, 2015, at 1:36 PM, Chris Hegarty  wrote:
> 
> Paul,
> 
> >
> > Yes, one could use a Pattern.splitAsStream, sorry could not resist :-) 
> > assuming this area is not sensitive to bootstrap issues e.g.
> >
> >hander = 
> > p.splitAsStream().map(String::trim).flatMap(this::getHandler).findFirst().orElse(null);
> 
> With the restriction we now have on overriding "core" protocol handlers we 
> can actually use lambda's in this specific code path. I built a webrev based 
> on your suggestion. Not too bad. I marginally favor this over webrev.01 above.
> 
> http://cr.openjdk.java.net/~chegar/8075139/webrev.02/src/java.base/share/classes/java/net/URL.java.sdiff.html
> 

Looks ok. 

I marginally prefer using flatMap rather than map/filter e.g. change getHandler 
to return Stream< URLStreamHandler> and change the last line to be "return 
Stream.ofNullable(handle). Up to you. 

If you stick with what you have perhaps consider changing "h -> h != null" to 
"Objects::nonNull".

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as a fallback for migration

[Paul Sandoz]

On Apr 15, 2015, at 4:35 PM, Chris Hegarty  wrote:
>> 
>> I marginally prefer using flatMap rather than map/filter e.g. change 
>> getHandler to return Stream< URLStreamHandler> and change the last line to 
>> be "return Stream.ofNullable(handle). Up to you.
> 
> That's better. For completeness, the updated webrev:
>  http://cr.openjdk.java.net/~chegar/8075139/webrev.03/

Looks good,
Paul.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as a fallback for migration

[Paul Sandoz]

On Apr 21, 2015, at 12:32 PM, Alan Bateman  wrote:

> 
> 
> On 21/04/2015 11:20, Chris Hegarty wrote:
>> On 15 Apr 2015, at 16:43, Paul Sandoz  wrote:
>> 
>>> On Apr 15, 2015, at 4:35 PM, Chris Hegarty  wrote:
>>>>> I marginally prefer using flatMap rather than map/filter e.g. change 
>>>>> getHandler to return Stream< URLStreamHandler> and change the last line 
>>>>> to be "return Stream.ofNullable(handle). Up to you.
>>>> That's better. For completeness, the updated webrev:
>>>> http://cr.openjdk.java.net/~chegar/8075139/webrev.03/
>> Argh! The launcher is now falling over with "Error occurred during 
>> initialization of VM”, in cases where a custom policy file contains a URL 
>> [*].
>> 

Oh well :-(

>> I’ll revert back to the version pre streams and lambda.
>> 
>> http://cr.openjdk.java.net/~chegar/8075139/webrev.01/
>> 
> This seems fine for now.
> 

Yes. 

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR 8081678: Add Stream returning methods to classes where there currently exist only Enumeration returning methods

[Paul Sandoz]

On Jun 3, 2015, at 12:46 PM, Alan Bateman  wrote:
> 
> On 02/06/2015 14:37, Paul Sandoz wrote:
> 
>> :
>> 
>> There is one small area of uncertainty with NetworkInterface. Can the 
>> following method ever return null?
>> 
>>  342 public static Enumeration getNetworkInterfaces()
>>  343 throws SocketException {
>>  344 NetworkInterface[] netifs = getAll();
>>  345
>>  346 // specified to return null if no network interfaces
>>  347 return netifs != null
>>  348? enumerationFromArray(netifs)
>>  349: null;
>>  350 }
>> 
>> Contrary to the comment i cannot find any specification. For the stream 
>> returning method, networkInterfaces, i have specified this to return an 
>> empty stream, thus it might be good to update the enumeration returning 
>> method as well to say whether it returns null or an empty enumeration.
>> 
> cc'ing net-dev. AFAIK, getNetworkInterface was originally specified to return 
> null but this was changed in Java SE 8 to always return with at least one 
> element, the loopback interface.
> 
> The underlying native getAll might still return null for exception cases 
> (which will cause the SocketException to be thrown on return). So I think you 
> can remove the null check.
> 

Ok, i removed it but added an assert for the array being non-null and 
containing at least one element. I also refined the documentation of the stream 
returning method in light of this:

  
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8081678-enumeration-and-stream/webrev/

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR 8081678: Add Stream returning methods to classes where there currently exist only Enumeration returning methods

[Paul Sandoz]

On Jun 3, 2015, at 9:27 PM, Alan Bateman  wrote:

> On 03/06/2015 17:47, Paul Sandoz wrote:
>> :
>> Ok, i removed it but added an assert for the array being non-null and 
>> containing at least one element. I also refined the documentation of the 
>> stream returning method in light of this:
>> 
>>   
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8081678-enumeration-and-stream/webrev/
>> 
> The update looks good.
> 
> A minor point on getInetAddresses where the javadoc has been changed to "Get 
> an Enumeration ...". I think that would be better as "Returns an 
> Enumeration". Same thing in inetAddresses() where "Return" would read a bit 
> better (IMO anyway).
> 

It's frustratingly inconsistent throughout, i tried to make it locally 
consistent (for example, see the instance methods for sub interfaces). The 
whole doc needs to be consistently updated.


> A niggle in inetAddresses is that it's got two /**.
> 

Ooops fixed.


> I was surprised to see PermissionCollection on the list, I don't know how 
> often that is used.
> 

grepcode.com shows quite a few usages of PermissionsCollection.elements(). Twas 
cheap to add.


> For the tests then @library ../../util/streambootlib doesn't seem right. Is 
> it time to move some infrastructure to make it easier to get at in other 
> parts of the suite?
> 

Quite probably, but not with this fix.

Thanks,
Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR 8081678: Add Stream returning methods to classes where there currently exist only Enumeration returning methods

[Paul Sandoz]

On Jun 3, 2015, at 11:00 PM, Chris Hegarty  wrote:

> Looks good Paul, just a few minor comments. ( looked at all, but *security* 
> and *sql* )
> 
> NetworkInterface
>  s/Enumertion/Stream
>L127 * will be returned in the Enumeration. However, if the caller has the
> 
>  s/an/a
>L131 * @return an Stream object with all or a subset of the InetAddresses
>L 209 * @return an Stream object with all of the subinterfaces
> 

Thanks, updated.

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8081678-enumeration-and-stream/webrev/src/java.base/share/classes/java/net/NetworkInterface.java.sdiff.html

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: WebSocket client API

[Paul Sandoz]

Hi,

Overall i think this API seems to be compressing down nicely to a small number 
of classes/interfaces, but i still think there is some room for further 
simplifications.


WebSocket

I don’t see the need for a context parameter. Context can be obtained via 
capturing. That reduces the requirement for a specific but generic BiHandler, 
since a BiConsumer could be used instead. A null completion handler could be 
allowed for those not interested in completion events.

My preferred alternative to the callback handler approach is to return a 
Completable that completes with the WebSocket instance or 
exceptionally. That to me better fits with the notion of completion of a 
specific event (just like that when async building a connected WebSocket), that 
allows one to chain off events or even block if necessary. It also reduces the 
need for a specific but generic functional interface. I suspect the common case 
would be to ignore the CF that is returned.


WebSocket.Builder

The protocol of receiving events is spread out over multiple behavioural 
parameters. Instead we could have a functional interface, 
WebSocketMessageListener say, with defaults for all but the most common event, 
which i guess is the receiving of text messages.

It’s easy to reintroduce the current behaviour as a separate layer if so 
desired e.g. a simple message event builder, but it’s really awkward to do it 
the other way around, which is a design smell to me.

The builder can then be reformulated as:

  Builder(String uri) // A URI is the only required argument
using(HttpClient ) // Overrides any previous call
using(HttpRequest.Builder ) // Overrides any previous call
subprotocols(String , String ...)
listener(WebSocketMessageListener ) // Overrides any previous call
WebSocket build( )
CF buildAsync()


The end result is WebSocket.BiHandler/Handler go away to be replaced with one 
specific web socket message listener interface whose documentation describes 
the receiving protocol and the threading/concurrency callback behaviour, and 
overall there is a simplification in the set of methods and their signatures.

Paul.

> On 6 Oct 2015, at 12:27, Pavel Rappo  wrote:
> 
> Hi,
> 
> Here's an update on the WebSocket API. This iteration tries to address all
> issues have been discussed so far:
> 
>   webrev: http://cr.openjdk.java.net/~prappo/8087113/webrev.01/
>   javadoc: http://cr.openjdk.java.net/~prappo/8087113/javadoc.01/
> 
> Main differences from the previous version:
> 
>   * Extension support has been postponed and remains an open issue [1]
>   * WebSocket.Builder now also accepts HttpRequest.Builder (for providing
> custom opening handshake headers)
>   * Outgoing is gone, instead a user can send incomplete Binary and Text
> messages with ByteBuffers and CharSequences directly
>   * Incoming is gone, instead WebSocket.Builder provides a handler
> assigning method per event (message or error)
>   * Async methods take a custom context object and a potentially reusable
> completion handler (NIO2 style)
>   * The API is now j.u.c.Flow-friendly
> 
> ---
> [1] https://bugs.openjdk.java.net/browse/JDK-8138949;
>That doesn't mean the default implementation won't support
>'permessage-deflate'.
> 
> -Pavel
> 
>> On 31 Aug 2015, at 15:30, Pavel Rappo  wrote:
>> 
>> Hi,
>> 
>> I would appreciate if you help to review a WebSocket client API proposed for
>> JDK 9. This work is a part of JEP-110 [1] and has started its public path 
>> with
>> HTTP client review in March this year [2].
>> 
>> Proposed WebSocket API is relatively small and focuses on convenient 
>> exchange of
>> data in a fully asynchronous fashion. API consists of 6 types located in the
>> java.net package [3]:
>> 
>> 1. WebSocket
>> 2. WebSocket.Builder
>> 3. WebSocket.Incoming
>> 4. WebSocket.Incoming.Chunks
>> 5. WebSocket.Outgoing
>> 6. WebSocketException
>> 
>> Starting point is a class description for java.net.WebSocket. Along with
>> in-javadoc examples, several API test samples are provided in the webrev [4] 
>> and
>> named test/java/net/WebSocket/Example%.java. They are only for informational
>> purposes and won't be included in the final version of the API.
>> 
>> I would appreciate any feedback on this API. Thanks.
>> 
>> ---
>> [1] http://openjdk.java.net/jeps/110
>> [2] http://mail.openjdk.java.net/pipermail/net-dev/2015-March/008932.html
>> [3] http://cr.openjdk.java.net/~prappo/8087113/javadoc.00/
>> [4] http://cr.openjdk.java.net/~prappo/8087113/webrev.00/
>> 
>> -Pavel
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: WebSocket client API

[Paul Sandoz]

Hi Pavel, Simone,

One way to make progress is to get the basic shape of the API agreed on without 
flow/resource management features. That probably represented the simplest form. 
I think we are very close to that.

Then lets iterate from that form and consider the additional features 
(back-pressure and resource management), see how they fit or push/pull the 
basic shape in various directions, and importantly see what additional demands 
are imposed on the developer.

Also, I expect those features would need to be co-ordinated somewhat with the 
HTTP API to ensure a common pattern and possibly reuse of certain types.

--

Regarding back pressure, i like what Michael/Pavel did with LongConsumer.

Regarding resource management. This one is tricky. For HTTP Michael had a 
clever trick of piggy backing off the back pressure support, but i think that 
might be too clever as it is conflating two independent actions. I have a hunch 
that to do this effectively we may need some sort of resource supplier that is 
registered with the builder. That supplier defines the resource management 
strategy and requirements on a listener consuming resources (that is somewhat 
annoying because it couples the resource supplier with the listener).

Paul.


> On 9 Oct 2015, at 15:18, Pavel Rappo  wrote:
> 
> 
>> On 8 Oct 2015, at 20:51, Simone Bordet  wrote:
>> 
>> What it is still missing is the fact that there is no specification
>> about the onXXX methods regarding the lifecycle of the parameters
>> passed in.
> 
> There is, actually. I have put it as a top-level javadoc, not as a javadoc to
> each single method. But that's an editorial problem, not a spec one.
> 
> 1. Go to: 
> http://cr.openjdk.java.net/~prappo/8087113/webrev.01/raw_files/new/src/java.httpclient/share/classes/java/net/httpclient/WebSocket.java
> 2. Look for occurrences of "reuse". There are exactly 2 of them :-)
> 
>> For example, this is going to surprise users (simple echo):
>> 
>> onBinary((ws, bytes, last) -> {
>>   ws.sendBinary(bytes, last, null, (_, failure) -> {});
>> }
> 
> That would only surprise people who don't read javadoc. Or you
> want to say it's an inherently bad decision to allow people to
> reuse implementation's ByteBuffer?
> 
>> It's not going to work because the send is async, and there is no
>> specification about who owns the ByteBuffer "bytes".
>> In my experience, it is bad to force applications to perform a copy
>> (not to mention that the copy could be really expensive, as WebSocket
>> frames could be large).
> 
> I wonder what percentage of use cases this scenario corresponds to? Namely, a
> huge payload being received, transformed(?) and sent on the WebSocket. I ask
> this because I have to understand whether the added complexity worth the value
> provided by the functionality.
> 
>> This would also lead to applications being forced to block waiting for
>> the send to complete
> 
> How come? Send is not blocking. Unless one performs a rather odd thing: will
> block on handler completion before returning an onXXX call.
> 
>> StatusCode makes little sense to me: it's a wrapper for int, and
>> nothing more. I would prefer to see primitive int in the signatures.
> 
> Type safety, having documentation in a single place, maybe richer string
> representation (toString)?
> 
>> Method isClosed() does not convey enough information.
>> WebSocket has built-in in the protocol half-closes, so it should be
>> able to report this information, like Socket returns
>> isInputShutDown(), isOutputShutDown() and isOpen().
>> A simple enum would do.
> 
> What's the use case other than debugging?
> 
>> I think it's enough for the builder to provide an async build() method only.
> 
> Makes sense.
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR 8131155/9, java/net/NetworkInterface/NetworkInterfaceStreamTest.java failed because of Teredo Tunneling Pseudo-Interface

[Paul Sandoz]

Hi Felix,

Is it correct to filter out all network interfaces on windows platforms?

IIUC that renders the tests testSubNetworkInterfaces and testInetAddresses 
redundant on windows.

If so it would be useful to document that on those tests.


Some minor suggestions:

  s/isWindows/IS_WINDOWS

Colocate the “isIncluded" with IS_WINDOWS.

Paul.

> On 14 Dec 2015, at 07:53, Felix Yang  wrote:
> 
> Hi all,
>please review the fix for 
> java/net/NetworkInterface/NetworkInterfaceStreamTest.java. It is necessary to 
> exclude "Teredo Tunneling Pseudo-Interface" whose configuration changes 
> frequently.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8131155
> Webrev: http://cr.openjdk.java.net/~xiaofeya/8131155/webrev.00
> 
> Thanks,
> Felix



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR 8131155/9, java/net/NetworkInterface/NetworkInterfaceStreamTest.java failed because of Teredo Tunneling Pseudo-Interface

[Paul Sandoz]

> On 14 Dec 2015, at 11:53, Chris Hegarty  wrote:
> 
> 
> 
> On 14/12/15 10:07, Paul Sandoz wrote:
>> Hi Felix,
>> 
>> Is it correct to filter out all network interfaces on windows platforms?
> 
> I may be missing something, but this should ONLY filter out
> interfaces with the name 'Teredo', on Windows. NOT ALL.

Doh yes, i missed the “!’.

Paul.

> It is quite common for networking tests to exclude Teredo
> interfaces, as they are unstable ( for testing purposes ).
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR 8131155/9, java/net/NetworkInterface/NetworkInterfaceStreamTest.java failed because of Teredo Tunneling Pseudo-Interface

[Paul Sandoz]

> On 18 Dec 2015, at 10:42, Amy Lu  wrote:
> 
> Change looks fine. Thank you for the update Felix.
> 
> (But please wait for the final GO from one official reviewer.)
> 

+1

Amy, can you sponsor?

Thanks,
Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR: 8087112 HTTP API and HTTP/1.1 implementation

[Paul Sandoz]

> On 4 Feb 2016, at 17:14, Michael McMahon  wrote:
> 
> Hi,
> 
> The following webrevs are for the initial implementation of JEP 110.
> Most of it is in the jdk repository with some build configuration in the top
> level repo for putting this code in its own module (java.httpclient).
> 
> http://cr.openjdk.java.net/~michaelm/8087112/01/top/webrev/
> 
> http://cr.openjdk.java.net/~michaelm/8087112/01/jdk/webrev/
> 

I am mostly focusing on the API, because that is where i have had most input in 
the past. Over all the API is quite compact, appears easy to use for common 
cases, yet has a powerful plugin mechanism for request/response bodies, and the 
design allows for but the implementation does not have to provide a fully 
non-blocking implementation.


HttpHeaders
—

  61 public Optional firstValueAsLong(String name);
Why not return OptionalLong?

The implementation class HttpHeadersImpl does not appear to support 
unmodifiable values i.e. the list obtained from the header map can be modified. 
Also might need to be careful about clone, since that can be called by the 
user, and this is a shallow clone.


HttpRequest
—

In the examples recommend using URI.create rather than new URI.

The examples section can be placed under an @apiNote

When building a request how does one set multiple values for a header? 
setHeaders overwrites, does one used headers(…) instead?


Processors
—

I think the flowController of HttpRequest.BodyProcessor.onRequestStart requires 
more specification (a follow up issue if you wish):
- what are the units? It represents unfulfilled demand, but of what?
- what if a -ve value is passed
- what if Long.MAX_VALUE is passed? effectively unbounded?
- does it have to be called within onRequestStart and onRequestBodyChunk?
- what happens if it is invoked outside the life-cycle of a BodyProcessor?

OK, i see there is more specification in HttpResponse.BodyProcessor. I wonder 
how implementations correlate the unit to bytes? Is there any correlation 
related to an internal buffer size? Why would the requested unfulfilled demand 
be greater than 1? i.e. as an implementor of a body processor how am i meant to 
correlate the bytes i read/write to the units required to express the 
unfulfilled demand?

For responses, what happens if the Consumer is called outside the 
life-cycle of the processors?

Paul.


> The HTTP/2 implementation will come later.
> 
> Thanks,
> Michael.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR: 8087112 HTTP API and HTTP/1.1 implementation

[Paul Sandoz]

> On 18 Feb 2016, at 16:37, Michael McMahon  
> wrote:
> 
>> When building a request how does one set multiple values for a header? 
>> setHeaders overwrites, does one used headers(…) instead?
>> 
> 
> headers(String, String)
> and headers(String ...) both accumulate headers
> 

What headers would be included in the request for the following expressions:

-  setHeader(“foo”, “value1”).setHeaders(“foo”, “value2”)

-  headers(“foo”, “value2”).headers(“foo”, “value2”)

Or put another way if i want my request to contain the header lines:

  Foo: value1
  Foo: value2

how can i express that in the API?


>> 
>> Processors
>> —
>> 
>> I think the flowController of HttpRequest.BodyProcessor.onRequestStart 
>> requires more specification (a follow up issue if you wish):
>> - what are the units? It represents unfulfilled demand, but of what?
>> - what if a -ve value is passed
>> - what if Long.MAX_VALUE is passed? effectively unbounded?
>> - does it have to be called within onRequestStart and onRequestBodyChunk?
>> - what happens if it is invoked outside the life-cycle of a BodyProcessor?
>> 
> 
> yes, spec that is in HttpResponse.BodyProcessor applies here too,
> but it should be repeated.
> 

Ok.


>> OK, i see there is more specification in HttpResponse.BodyProcessor. I 
>> wonder how implementations correlate the unit to bytes? Is there any 
>> correlation related to an internal buffer size? Why would the requested 
>> unfulfilled demand be greater than 1? i.e. as an implementor of a body 
>> processor how am i meant to correlate the bytes i read/write to the units 
>> required to express the unfulfilled demand?
>> 
> There is no direct correlation between units and bytes. If the window size is 
> 1, then the processor
> is willing to accept one more call, of whatever sized ByteBuffer.
> 
> The implementor of the processor must then decide based on how long it takes 
> to consume the
> data whether to update the window immediately or to delay and update it later.
> 

Sorry, still don’t get why a value greater than 1 needs to be provided. If i 
pass in 1 and may get one or more calls, then why pass in 1? Why not use a 
Runnable instead?


>> For responses, what happens if the Consumer is called outside the 
>> life-cycle of the processors?
>> 
> 
> Actually, that is not part of the current API. For the moment, the life-cycle 
> of the ByteBuffer is
> that it only belongs to the processor for the duration of the call, meaning 
> it would have to be
> copied if the data isn't consumed fully during the call.
> 

But happens if the Consumer is invoked outside of the life-cycle of the 
response, should an ISE be thrown?

Same for the LongConsumer, what happens if it is invoked outside the life-cycle 
of the request or response.

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR: 8087112 HTTP API and HTTP/1.1 implementation

[Paul Sandoz]

> On 18 Feb 2016, at 17:34, Michael McMahon  
> wrote:
> 
> On 18/02/16 16:06, Paul Sandoz wrote:
>>> On 18 Feb 2016, at 16:37, Michael McMahon  
>>> wrote:
>>> 
>>>> When building a request how does one set multiple values for a header? 
>>>> setHeaders overwrites, does one used headers(…) instead?
>>>> 
>>> headers(String, String)
>>> and headers(String ...) both accumulate headers
>>> 
>> What headers would be included in the request for the following expressions:
>> 
>> -  setHeader(“foo”, “value1”).setHeaders(“foo”, “value2”)
> 
> Foo: value2
>> -  headers(“foo”, “value2”).headers(“foo”, “value2”)
> 
> Foo: value2
> Foo: value2
> 

Ok, that is what i thought, unless i missed it in the docs we should document 
that more clearly.


>>>> OK, i see there is more specification in HttpResponse.BodyProcessor. I 
>>>> wonder how implementations correlate the unit to bytes? Is there any 
>>>> correlation related to an internal buffer size? Why would the requested 
>>>> unfulfilled demand be greater than 1? i.e. as an implementor of a body 
>>>> processor how am i meant to correlate the bytes i read/write to the units 
>>>> required to express the unfulfilled demand?
>>>> 
>>> There is no direct correlation between units and bytes. If the window size 
>>> is 1, then the processor
>>> is willing to accept one more call, of whatever sized ByteBuffer.
>>> 
>>> The implementor of the processor must then decide based on how long it 
>>> takes to consume the
>>> data whether to update the window immediately or to delay and update it 
>>> later.
>>> 
>> Sorry, still don’t get why a value greater than 1 needs to be provided. If i 
>> pass in 1 and may get one or more calls, then why pass in 1? Why not use a 
>> Runnable instead?
>> 
> 
> In practice, 1 seems to be the most likely use-case, but a value of N means
> that N further calls to provide 1 ByteBuffer is permitted.
> 
> It's exactly the same with the Flow API.
> 

It does not seem quite so because there is a correlation between the publisher 
and subscriber in terms of elements, where N in request(N) represents the
additional unfulfilled demand to process elements that are published.

In your case the process implementation has no way to correlate the demand in a 
meaningful way.

If there was a correlation to bytes then it may be more meaningful. For example 
flowConsumer.accept(4096) means the processor is requesting an additional 
unfulfilled demand of 4096 bytes, that way the processor can control the rate 
in terms of something it understands and it’s up to the HTTP client to respect 
that (i dunno if we can get down to the traffic control level of the TCP 
protocol in Java).

I really don’t wanna block this, but this seems to require some more bake time. 
If you can I recommend removing it from the API until you revise with HTTP 2. 
If you think this would be more work than necessary, then lets just promise to 
revise when HTTP 2 goes in.


>>>> For responses, what happens if the Consumer is called outside the 
>>>> life-cycle of the processors?
>>>> 
>>> Actually, that is not part of the current API. For the moment, the 
>>> life-cycle of the ByteBuffer is
>>> that it only belongs to the processor for the duration of the call, meaning 
>>> it would have to be
>>> copied if the data isn't consumed fully during the call.
>>> 
>> But happens if the Consumer is invoked outside of the life-cycle of the 
>> response, should an ISE be thrown?
>> 
>> Same for the LongConsumer, what happens if it is invoked outside the 
>> life-cycle of the request or response.
> 
> There is no Consumer<>

Here is the API signature:

+T onResponseBodyStart(long contentLength,
+  HttpHeaders responseHeaders,
+  LongConsumer flowController,
+  Consumer bufferpool)
+throws IOException;

There is Consumer as well as LongConsumer.


> but for the LongConsumer, it's not specified. I would expect it just to have
> no effect.
> 

We need to document the behaviour for both consumers.

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR 8146758, NetworkInterfaceStreamTest.java fails intermittently at comparing network interfaces

[Paul Sandoz]

> On 15 Apr 2016, at 11:29, Felix Yang  wrote:
> 
> Hi all,
>   please review the following fix. It is an intermittent failure because of 
> Teredo Tunneling Pseudo-Interface.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146758
> Webrev: http://cr.openjdk.java.net/~xiaofeya/8146758/webrev.00/
> 

+1

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR JDK-8156742: Miscellaneous WebSocket API improvements

[Paul Sandoz]

> On 1 Jun 2016, at 15:17, Pavel Rappo  wrote:
> 
> On the stream thing, well... If you say it's a rare use case, I say let's hear
> more people. I don't have much experience working with WebSocket as a user, 
> so I
> would like to listen to people who have it (like yourself). YAGNI is one of my
> favorite arguments though! It makes the implementation effort feel lighter.
> 

This seems like the kind of thing that can be dropped and considered for a 
later release if there is demand.

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [10] RFR: 8186930: Constant fold URI constants

[Paul Sandoz]

One way to proceed in the future is to use those static methods as constant 
producing functions (via condy), then at jlink time run the functions and 
possibly strip out the then redundant code.

Paul.

> On 30 Aug 2017, at 09:16, Daniel Fuchs  wrote:
> 
> Hi Claes,
> 
> Maybe it could be interesting to leave the
> methods in a static inner class which is
> not referenced (except by whitebox tests) and
> have this inner class expose a static test()
> method that would test that the static fields
> in URI have the expected value?
> 
> This is just a suggestion,  and it
> could be done in a followup RFE...
> 
> best regards,
> 
> -- daniel
> 
> On 31/08/2017 16:26, Claes Redestad wrote:
>> On 2017-08-30 17:17, Alan Bateman wrote:
>>> I think it could be useful as someone reading the code isn't going to 
>>> immediately know to jump to URI.
>> Done: http://cr.openjdk.java.net/~redestad/8186930/jdk.01/
>> /Claes
> 

Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v3]

[Paul Sandoz]

> On Dec 16, 2020, at 1:47 AM, Chris Hegarty  wrote:
> 
> On Wed, 16 Dec 2020 09:20:09 GMT, Andrey Turbanov 
>  wrote:
> 
>>> 8258422: Cleanup unnecessary null comparison before instanceof check in 
>>> java.base
>> 
>> Andrey Turbanov has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>  8258422: Cleanup unnecessary null comparison before instanceof check in 
>> java.base
>>  use instanceof pattern matching in UnixPath too
> 
> Let's take advantage of "flow scoping" to eliminate some of these casts. A 
> few examples follow.
> 
> src/java.base/share/classes/java/net/InetSocketAddress.java line 414:
> 
>> 412: if (!(obj instanceof InetSocketAddress))
>> 413: return false;
>> 414: return holder.equals(((InetSocketAddress) obj).holder);
> 
> If we restructure this a little we can get:
> 
>public final boolean equals(Object obj) {
>if (obj instanceof InetSocketAddress that)
>return holder.equals(that.holder);
>return false;
>}
> 

It’s also possible to use a ternary expression as in:

   return (obj instanceof InetSocketAddress that) ? holder.equals(that.holder) 
: false;

Not suggesting you have to do that here. More for information purposes for 
those that might not know.

Paul.

Re: UrlEncodedQueryString CCC request

[Paul Sandoz]

Paul Sandoz wrote:

Hi Richard, Michael,

Some clarifications on UriBuilder, URI templates and URI processing in 
JSR-311.


UriBuilder is primarily concerned about making easy to safely and 
efficiently build URIs. It was designed to be general in nature rather 
than scoped to a certain way in JSR-311.


What i said above is slightly misleading of me, i should have said it 
was *mostly* designed to be general in nature as there are 4 methods 
associated with accessing URI templates of a class or method, but it is 
simple to generalize by removing such methods.


Paul.

If it is at all specific it is 
focused on the use-cases for building and using URIs for RESTful Web 
applications. For example, given an instance of a java.net.URI how can 
one easily and safely append one or more path segments to the path 
component of that instance, or add query parameters and values to the 
query component of that instance, to create a new URI?


A UriBuilder can be created from an existing java.net.URI instance and 
then the URI components can be replaced and/or augmented (but not 
retrieved). URI templates are just one aspect of building URIs and a 
UriBuilder can be used effectively without leveraging templates (many of 
the examples provided in the Jersey, the RI, distribution do just that).


URI templates are specified in an internet draft [1], i don't know 
when/if it will become an RFC. I would not go as far to say they are "ad 
hoc", which my understanding implies a particular case, as URI templates 
are fairly general and useful so i would not discount them too early in 
the discussion process.


JSR-311 also provides access to the query parameters, path segments, and 
matrix parameters of path segments present in a URI [2].


I understood the CCC request to consider alignment as something larger 
in scope to improve both URI building and URI parsing/building of URI 
components.


JSR-311 will have to provide it's own URI-based classes but it would be 
good if we could align and improve the design in JSR-311 and JDK7.


Paul.

[1] http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-01.txt
[2] https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/UriInfo.html

Richard Kennard wrote:

Michael (Paul? Marc?),

Looking at the JSR311 URIBuilder, and with respect to Mark 
(Reinhold)'s concerns, I actually don't think there is much of an 
overlap between them. Specifically:


1) javax.ws.rs.core.UriBuilder seems primarily concerned with building 
URIs by leveraging UriTemplates
2) java.net.UrlEncodedQueryString seems primarily concerned with 
modelling a query string


While 1) is useful for building URIs in a JSR311-specific way, 2) is 
useful for parsing and retrieving and modifying query parameters (eg. 
not solely a builder)


So while an implementation of JSR311 may want to use 
java.net.UrlEncodedQueryString internally, I don't see how the two 
classes could effectively merge, because UriBuilder isn't concerned 
with parsing and retrieving and modifying, and UrlEncodedQueryString 
isn't concerned with UriTemplates.


Regards,

Richard.

Michael McMahon wrote:
We have been asked by the CCC to go back and reconsider the design of 
the proposed
UrlEncodedQueryString class/API and to consider aligning it with the 
URIBuilder class
that has been proposed in JSR311. Also, the particular concern 
expressed by the CCC

is that we possibly restricted the scope of the class too much.

What I think we would like to achieve (for Java SE) is a general 
purpose URI builder that is not

specifically tied to any particular type of web application.

When Richard initially proposed the UrlEncodedQueryString, it was 
more like a URIBuilder
but our concern (which I think is still valid) is that a Java SE 
class for constructing URIs
must be solely based on defined standards (the URI rfcs), rather than 
on ad-hoc (albeit commonly used)
conventions in the world of web applications. Specifically, I don't 
think we can impose
any additional structure on URIs that is not explicitly specified in 
the relevant URIs.
But if other people have a different view on this, I'm interested to 
discuss it.


A reference for the JSR311 class is at
https://jsr311.dev.java.net/nonav/javadoc/index.html

and Paul Sandoz's blog entry talking about it is at
http://blogs.sun.com/sandoz/entry/building_uris

The javadoc for the proposed UrlEncodedQueryString is attached in a 
zip file


Thanks,
Michael.







--
| ? + ? = To question
\
   Paul Sandoz
x38109
+33-4-76188109

Re: UrlEncodedQueryString CCC request

[Paul Sandoz]

Hi Richard, Michael,

Some clarifications on UriBuilder, URI templates and URI processing in 
JSR-311.


UriBuilder is primarily concerned about making easy to safely and 
efficiently build URIs. It was designed to be general in nature rather 
than scoped to a certain way in JSR-311. If it is at all specific it is 
focused on the use-cases for building and using URIs for RESTful Web 
applications. For example, given an instance of a java.net.URI how can 
one easily and safely append one or more path segments to the path 
component of that instance, or add query parameters and values to the 
query component of that instance, to create a new URI?


A UriBuilder can be created from an existing java.net.URI instance and 
then the URI components can be replaced and/or augmented (but not 
retrieved). URI templates are just one aspect of building URIs and a 
UriBuilder can be used effectively without leveraging templates (many of 
the examples provided in the Jersey, the RI, distribution do just that).


URI templates are specified in an internet draft [1], i don't know 
when/if it will become an RFC. I would not go as far to say they are "ad 
hoc", which my understanding implies a particular case, as URI templates 
are fairly general and useful so i would not discount them too early in 
the discussion process.


JSR-311 also provides access to the query parameters, path segments, and 
matrix parameters of path segments present in a URI [2].


I understood the CCC request to consider alignment as something larger 
in scope to improve both URI building and URI parsing/building of URI 
components.


JSR-311 will have to provide it's own URI-based classes but it would be 
good if we could align and improve the design in JSR-311 and JDK7.


Paul.

[1] http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-01.txt
[2] https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/UriInfo.html

Richard Kennard wrote:

Michael (Paul? Marc?),

Looking at the JSR311 URIBuilder, and with respect to Mark (Reinhold)'s 
concerns, I actually don't think there is much of an overlap between 
them. Specifically:


1) javax.ws.rs.core.UriBuilder seems primarily concerned with building 
URIs by leveraging UriTemplates
2) java.net.UrlEncodedQueryString seems primarily concerned with 
modelling a query string


While 1) is useful for building URIs in a JSR311-specific way, 2) is 
useful for parsing and retrieving and modifying query parameters (eg. 
not solely a builder)


So while an implementation of JSR311 may want to use 
java.net.UrlEncodedQueryString internally, I don't see how the two 
classes could effectively merge, because UriBuilder isn't concerned with 
parsing and retrieving and modifying, and UrlEncodedQueryString isn't 
concerned with UriTemplates.


Regards,

Richard.

Michael McMahon wrote:
We have been asked by the CCC to go back and reconsider the design of 
the proposed
UrlEncodedQueryString class/API and to consider aligning it with the 
URIBuilder class
that has been proposed in JSR311. Also, the particular concern 
expressed by the CCC

is that we possibly restricted the scope of the class too much.

What I think we would like to achieve (for Java SE) is a general 
purpose URI builder that is not

specifically tied to any particular type of web application.

When Richard initially proposed the UrlEncodedQueryString, it was more 
like a URIBuilder
but our concern (which I think is still valid) is that a Java SE class 
for constructing URIs
must be solely based on defined standards (the URI rfcs), rather than 
on ad-hoc (albeit commonly used)
conventions in the world of web applications. Specifically, I don't 
think we can impose
any additional structure on URIs that is not explicitly specified in 
the relevant URIs.
But if other people have a different view on this, I'm interested to 
discuss it.


A reference for the JSR311 class is at
https://jsr311.dev.java.net/nonav/javadoc/index.html

and Paul Sandoz's blog entry talking about it is at
http://blogs.sun.com/sandoz/entry/building_uris

The javadoc for the proposed UrlEncodedQueryString is attached in a 
zip file


Thanks,
Michael.





--
| ? + ? = To question
\
   Paul Sandoz
x38109
+33-4-76188109

Re: Review of new Http client API

[Paul Sandoz]

Hi,

A potential simplification of the HttpResponseHeadersHandler interface is to 
turn it into a functional interface:

  HttpResponseHandler onHeaders(Future dresp) throws 
InterruptedException, ExecutionException;

[Chris, i am not sure if an interface with two methods, one default, is 
classified as a functional interface.]

- mirrors the pull-based asynchronous approach

- dresp.isDone() always returns true

- the Future encapsulates the underling exception, if any

- harder to swallow errors, since the exception from drep.get() will propagate 
if not caught.

- a return of a null HttpResponseHandler means "not interested in the body".

FWIW the use of Future is the approach i chose for the Jersey client.

HttpResponseHandler would also be a functional interface:

void onBodyPart(Future bb) throws InterruptedException, 
ExecutionException

- there is no inheritance relationship between HttpResponseHeadersHandler and 
HttpResponseHandler.

- a "bb" with a capacity of 0 indicates the last part.

- the HttpResponse is not required as a parameter because the implementation 
can obtain it from the onHeaders method.

If the use of Future is a bit extreme for some :-) then things can still be 
simplified by following the above approach with an additional, and optional, 
functional interface to handle errors when HttpClient.sendRequest is called.

--

Rather than setting the bytes on the HttpRequest with numerous methods i wonder 
if it is better to have a functional interfaces for both OutputStream and the 
NIO equivalent:

  interface EntityWriter { // Oh for disjunct types!
/**
 * @return true if there is more to write
 */
boolean write(T t) throws IOException;
  }

I believe the above can support all the existing functionality currently 
expressed as methods, including the Iterable/Iterator. There can be instances 
of EntityWriter for common functionality:

  EntityWriters.fromBytes(byte[] b, ...);

The same might be applicable to HttpResponse with an EntityReader:

  interface EntityReader {
U read(T t) throws IOException;
  }

Of course i might be missing something obvious here in terms of optimisation 
currently performed by the implementation!

--

It somewhat bugs me that blocking and asynchronous pull/push functionality is 
all defined using the same artifacts. But, my imagination is currently is 
failing me on how to improve on such matters. Perhaps something better may come 
out of fluent-based API?

Paul.

On Aug 14, 2012, at 2:01 PM, Michael McMahon  
wrote:

> Hi,
> 
> (apologies for sending this again)
> We have just published a draft of a proposed new Http client API [1] for JDK 
> 8.
> 
> This message has been cc'd to jdk8-dev so that as many people as possible
> know about it, but the discussion will be on the net-dev list 
> (net-dev@openjdk.java.net).
> So, folks will have to join that list [2], in order to take part.
> 
> Thanks,
> Michael.
> 
> [1] http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/
> 
> [2] http://mail.openjdk.java.net/mailman/listinfo/net-dev

Re: Review of new Http client API

[Paul Sandoz]

On Aug 23, 2012, at 5:05 PM, Chris Hegarty  wrote:

> Paul,
> 
> All good feedback, and I will leave it to Michael to reply to the specifics. 
> On thought I had on separation of modes is something list this:
> 
>  interface HeaderHandler {
>  onHeaders(HttpResponse);
>  }
>  interface ErrorHandler {
>  onError(HttpResponse, Throwable);
>  }
>  interface BodyHandler {
>  onBodyPart(HttpResponse, ByteBuffer, boolean);
>  }
> 
>  class HttpRequest {
>  
>  AsyncHttpRequest async(HttpRequest);
>  
>  }
> 
>  class AsyncHttpRequest extends HttpRequest {
>  // no public constructors
>  
>  AsyncHttpRequest onHeaders(HeaderHandler);
>  AsyncHttpRequest onError(ErrorHandler);
>  AsyncHttpRequest onBodyPart(BodyHandler);
>  }
> 
>  class HttpClient {
>  
>  OutputStream sendHeaders(HttpRequest request, long contentLength)
>  Future sendRequest(HttpRequest req)
>  void sendRequest(AsyncHttpRequest req)
>  }
> 

OK, i would be inclined to separate out the instance used for building from the 
instance passed around, so one cannot muck around with the state of the latter.


> Then user code may do:
> 
>  AsyncHttpRequest request.async()
>   .onHeaders(r -> dumpHeaders(r))
>   .onError((r,t) -> handleError(r,t));
>   .onBodyPart((r,bb,c) -> transformBody(r,bb,t));
>  client.sendRequest(request);
> 

If these calls are on* calls are optional and one is not interested in when the 
headers have been received one could omit the onHeaders call, infact all those 
methods could be optional. That certainly simplifies things.


>  
> 
>  void dumpHeaders(HttpResponse r) {
>  System.out.println(r);
>  }
>  void handleError(HttpResponse r, t) {
>  throw t;
>  }
>  void transformBody(HttpResponse r, bb, boolean complete) {
>  System.out.println("Hello there!");
>  }
> 

FWIW you could use method references:

   AsyncHttpRequest request.async()
  .onHeaders(whateverthatclassiscalled::dumpHeaders)
  ...

Paul.


> Some experimentation is necessary to find a good balance here.
> 
> -Chris.

Re: Review of new Http client API

[Paul Sandoz]

On Aug 23, 2012, at 5:16 PM, Michael McMahon  
wrote:

> Paul,
> 
> Thanks for looking at it. Yes, this is an area that needs some more work.
> The current thinking is along the lines that Chris just posted and I hope to
> have another version of the API to look at tomorrow.
> 
> What you suggest seems like an unusual usage of Future<>  as we have tried to 
> provide
> a mode of operation where applications can get a Future
> which would work in the conventional way of returning the result "in the 
> future".

Agreed, it fit well with the underlying asynchronous support in Jersey, which 
was already using the Future, and it bugged me using callback interfaces with 
two methods, where most of the time the error would be swallowed. If there was 
a listener concept for Future in the JDK I would have used that instead.

I think the approach Chris shows easily allows for a default handler when one 
is not supplied.


> But, it raises a question in that while we currently have callback interfaces 
> for both
> headers and data, we only have a Future based interface for headers (but not 
> data).
> 

Indeed!

Paul.


> - Michael
> 
> On 23/08/12 15:20, Paul Sandoz wrote:
>> Hi,
>> 
>> A potential simplification of the HttpResponseHeadersHandler interface is to 
>> turn it into a functional interface:
>> 
>>   HttpResponseHandler onHeaders(Future  dresp) throws 
>> InterruptedException, ExecutionException;
>> 
>> [Chris, i am not sure if an interface with two methods, one default, is 
>> classified as a functional interface.]
>> 
>> - mirrors the pull-based asynchronous approach
>> 
>> - dresp.isDone() always returns true
>> 
>> - the Future encapsulates the underling exception, if any
>> 
>> - harder to swallow errors, since the exception from drep.get() will 
>> propagate if not caught.
>> 
>> - a return of a null HttpResponseHandler means "not interested in the body".
>> 
>> FWIW the use of Future is the approach i chose for the Jersey client.
>> 
>> HttpResponseHandler would also be a functional interface:
>> 
>> void onBodyPart(Future  bb) throws InterruptedException, 
>> ExecutionException
>> 
>> - there is no inheritance relationship between HttpResponseHeadersHandler 
>> and HttpResponseHandler.
>> 
>> - a "bb" with a capacity of 0 indicates the last part.
>> 
>> - the HttpResponse is not required as a parameter because the implementation 
>> can obtain it from the onHeaders method.
>> 
>> If the use of Future is a bit extreme for some :-) then things can still be 
>> simplified by following the above approach with an additional, and optional, 
>> functional interface to handle errors when HttpClient.sendRequest is called.
>> 
>> --
>> 
>> Rather than setting the bytes on the HttpRequest with numerous methods i 
>> wonder if it is better to have a functional interfaces for both OutputStream 
>> and the NIO equivalent:
>> 
>>   interface EntityWriter  { // Oh for disjunct types!
>> /**
>>  * @return true if there is more to write
>>  */
>> boolean write(T t) throws IOException;
>>   }
>> 
>> I believe the above can support all the existing functionality currently 
>> expressed as methods, including the Iterable/Iterator. There can be 
>> instances of EntityWriter for common functionality:
>> 
>>   EntityWriters.fromBytes(byte[] b, ...);
>> 
>> The same might be applicable to HttpResponse with an EntityReader:
>> 
>>   interface EntityReader  {
>> U read(T t) throws IOException;
>>   }
>> 
>> Of course i might be missing something obvious here in terms of optimisation 
>> currently performed by the implementation!
>> 
>> --
>> 
>> It somewhat bugs me that blocking and asynchronous pull/push functionality 
>> is all defined using the same artifacts. But, my imagination is currently is 
>> failing me on how to improve on such matters. Perhaps something better may 
>> come out of fluent-based API?
>> 
>> Paul.
>> 
>> On Aug 14, 2012, at 2:01 PM, Michael McMahon  
>> wrote:
>> 
>>> Hi,
>>> 
>>> (apologies for sending this again)
>>> We have just published a draft of a proposed new Http client API [1] for 
>>> JDK 8.
>>> 
>>> This message has been cc'd to jdk8-dev so that as many people as possible
>>> know about it, but the discussion will be on the net-dev list 
>>> (net-dev@openjdk.java.net).
>>> So, folks will have to join that list [2], in order to take part.
>>> 
>>> Thanks,
>>> Michael.
>>> 
>>> [1] http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/
>>> 
>>> [2] http://mail.openjdk.java.net/mailman/listinfo/net-dev
> 

Re: Indenting code?

[Paul Sandoz]

On Sep 14, 2012, at 1:20 PM, Alan Bateman  wrote:

> On 14/09/2012 01:21, Brad Wetmore wrote:
>> Netbean's automatic formatting does a pretty good job with new code. 
>> However, I think the general advice is to not change existing code just 
>> because.  When you're dealing with multiple release families, it makes the 
>> merges much more difficult.
>> 
>> Brad
> One think that Paul Sandoz suggested recently is that we should have a NB 
> template that folks can use to avoid some discussions/debates on styles.

+1 i.e. make producing and reviewing code easier.


> It would be great for someone to run with that, the hard part is of course 
> that it will be impossible to get agreement. Personally I find NB's defaults 
> okay but there are several cases where its indenting is horrible.
> 
> Anyway, the main advice I think is to keep things locally consistent where 
> possible. Also major refactoring or formatting in a bug fix is a royal pain 
> for reviewers.
> 

The solution to that is to re-format all JDK source code using a tool and 
commit independent of any fixes, i bet the NBs formatter could be extracted for 
command line operation.

IMHO it requires a benevolent dictator to decide on the exact formatting rules, 
since agreement is unlikely to be reached and much more heat than light will 
ever come from such discussions about where to place a '{'.

FWIW i really don't care about what the style would be as long as it is not 
equivalent to a Huggy Bear sofa so garish as to require one to wear peril 
sensitive sunglasses.

Paul.

hg: jdk8/tl/jdk: 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder

[paul . sandoz]

Changeset: 156ee44cd456
Author:psandoz
Date:  2013-05-30 16:08 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/156ee44cd456

8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder
Summary: Also fixes documentation on StreamBuilder.OfDouble
Reviewed-by: alanb, chegar, mduigou

! src/share/classes/java/util/stream/StreamBuilder.java

hg: jdk8/tl/jdk: 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst()

[paul . sandoz]

Changeset: b4742d038100
Author:psandoz
Date:  2013-05-28 15:22 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4742d038100

8014393: Minor typo in the spec for j.u.stream.Stream.findFirst()
Reviewed-by: alanb, chegar

! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Stream.java

hg: jdk8/tl/jdk: 8014732: Minor spec issue: java.util.Spliterator.getExactSizeIfKnown

[paul . sandoz]

Changeset: b47044426bcd
Author:psandoz
Date:  2013-05-31 09:58 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b47044426bcd

8014732: Minor spec issue: java.util.Spliterator.getExactSizeIfKnown
Summary: A minor documentation issue (not a spec issue).
Reviewed-by: chegar, dl

! src/share/classes/java/util/Spliterator.java

hg: jdk8/tl/jdk: 8015008: Primitive iterator over empty sequence, null consumer: forEachRemaining methods do not throw NPE

[paul . sandoz]

Changeset: f3c7c5f753dc
Author:psandoz
Date:  2013-06-03 10:28 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3c7c5f753dc

8015008: Primitive iterator over empty sequence, null consumer: 
forEachRemaining methods do not throw NPE
Reviewed-by: chegar

! src/share/classes/java/util/PrimitiveIterator.java
+ test/java/util/Iterator/PrimitiveIteratorDefaults.java

hg: jdk8/tl/jdk: 8014731: j.u.stream.StreamSupport class has default constructor generated

[paul . sandoz]

Changeset: 44ef47f3efed
Author:psandoz
Date:  2013-06-03 10:45 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44ef47f3efed

8014731: j.u.stream.StreamSupport class has default constructor generated
Summary: This change set also fixes broken links
Reviewed-by: alanb, chegar
Contributed-by: Paul Sandoz , Henry Jen 


! src/share/classes/java/util/stream/StreamSupport.java

hg: jdk8/tl/jdk: 8014383: StringJoiner example in class description not in sync with streams API

[paul . sandoz]

Changeset: a79e2683eae3
Author:psandoz
Date:  2013-06-03 17:37 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a79e2683eae3

8014383: StringJoiner example in class description not in sync with streams API
Reviewed-by: alanb

! src/share/classes/java/util/StringJoiner.java

hg: jdk8/tl/jdk: 8015790: Remove duplicate spliterator tests

[paul . sandoz]

Changeset: fad4ef2123ca
Author:psandoz
Date:  2013-06-04 11:53 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fad4ef2123ca

8015790: Remove duplicate spliterator tests
Reviewed-by: alanb, mduigou

- 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java
- 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java

hg: jdk8/tl/jdk: 8013649: HashMap spliterator tryAdvance() encounters remaining elements after forEachRemaining()

[paul . sandoz]

Changeset: de11b20f8c01
Author:psandoz
Date:  2013-05-31 10:53 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de11b20f8c01

8013649: HashMap spliterator tryAdvance() encounters remaining elements after 
forEachRemaining()
Reviewed-by: chegar

! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/WeakHashMap.java
! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java

hg: jdk8/tl/jdk: 8015792: Rename Spliterators.spliteratorFromIterator to Spliterators.iterator

[paul . sandoz]

Changeset: 9c462579b624
Author:psandoz
Date:  2013-06-10 12:26 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c462579b624

8015792: Rename Spliterators.spliteratorFromIterator to Spliterators.iterator
Reviewed-by: chegar

! src/share/classes/java/util/Spliterators.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
! test/java/util/stream/bootlib/java/util/stream/TestData.java
! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java
! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java

hg: jdk8/tl/jdk: 8015798: Rename IntStream.longs/doubles and LongStream.doubles to asXxxStream

[paul . sandoz]

Changeset: 7322e8ad7c01
Author:psandoz
Date:  2013-06-10 12:20 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7322e8ad7c01

8015798: Rename IntStream.longs/doubles and LongStream.doubles to asXxxStream
Reviewed-by: alanb

! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/LongStream.java
! test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/DoublePrimitiveOpsTests.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MapOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MinMaxTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/PrimitiveSumTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java

hg: jdk8/tl/jdk: 8015492: Remove DoubleStream.range methods

[paul . sandoz]

Changeset: 3990fcab2cd9
Author:psandoz
Date:  2013-06-10 11:52 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3990fcab2cd9

8015492: Remove DoubleStream.range methods
Reviewed-by: alanb

! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/Streams.java
! 
test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestDataProvider.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java

hg: jdk8/tl/jdk: 8015895: Int/LongStream.range/rangeClosed; ...

[paul . sandoz]

Changeset: 8d627f324c38
Author:psandoz
Date:  2013-06-11 12:13 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d627f324c38

8015895: Int/LongStream.range/rangeClosed
8012986: Right-bias range spliterators for large ranges
Reviewed-by: mduigou

! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Streams.java
! test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java
! test/java/util/stream/bootlib/java/util/stream/LongStreamTestDataProvider.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java

hg: jdk8/tl/jdk: 8016251: Balanced spliterator for SpinedBuffer

[paul . sandoz]

Changeset: a50394c44464
Author:psandoz
Date:  2013-06-13 11:13 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a50394c44464

8016251: Balanced spliterator for SpinedBuffer
Reviewed-by: mduigou
Contributed-by: Brian Goetz , Peter Levart 
, Paul Sandoz 

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/SortedOps.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java
! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java
! test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java

hg: jdk8/tl/jdk: 8016308: Updates to j.u.stream.Node/Nodes

[paul . sandoz]

Changeset: 656ea2349aa5
Author:psandoz
Date:  2013-06-20 10:45 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/656ea2349aa5

8016308: Updates to j.u.stream.Node/Nodes
Reviewed-by: mduigou
Contributed-by: Brian Goetz , Paul Sandoz 


! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/SliceOps.java
! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java
! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java

hg: jdk8/tl/jdk: 8016324: filter/flatMap pipeline sinks should pass size information to downstream sink

[paul . sandoz]

Changeset: 85524d9839dc
Author:psandoz
Date:  2013-06-20 11:02 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85524d9839dc

8016324: filter/flatMap pipeline sinks should pass size information to 
downstream sink
Reviewed-by: chegar, mduigou
Contributed-by: Brian Goetz 

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java

hg: jdk8/tl/jdk: 8016455: Sync stream tests from lambda to tl

[paul . sandoz]

Changeset: f758d7c24396
Author:psandoz
Date:  2013-06-20 11:15 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f758d7c24396

8016455: Sync stream tests from lambda to tl
Reviewed-by: mduigou
Contributed-by: Brian Goetz , Paul Sandoz 


! test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java
! test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java
+ test/java/util/stream/bootlib/java/util/stream/LoggingTestCase.java
! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java
! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java
! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java
! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java
! test/java/util/stream/boottest/java/util/stream/NodeTest.java
! test/java/util/stream/boottest/java/util/stream/UnorderedTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/GroupByOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntUniqOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ReduceByOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamLinkTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java

hg: jdk8/tl/jdk: 8016139: PrimitiveIterator.forEachRemaining

[paul . sandoz]

Changeset: 562f5cf13a9c
Author:psandoz
Date:  2013-06-20 11:21 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/562f5cf13a9c

8016139: PrimitiveIterator.forEachRemaining
Reviewed-by: alanb

! src/share/classes/java/util/PrimitiveIterator.java

hg: jdk8/tl/jdk: 8009736: Comparator API cleanup

[paul . sandoz]

Changeset: c1df54fd19b2
Author:henryjen
Date:  2013-06-11 13:41 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1df54fd19b2

8009736: Comparator API cleanup
Reviewed-by: psandoz, briangoetz, mduigou, plevart

! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/Comparator.java
! src/share/classes/java/util/Comparators.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/SortedOps.java
! test/java/nio/file/Files/StreamTest.java
! test/java/util/Collection/ListDefaults.java
+ test/java/util/Comparator/BasicTest.java
+ test/java/util/Comparator/TypeTest.java
- test/java/util/Comparators/BasicTest.java
+ test/java/util/Map/EntryComparators.java
+ test/java/util/function/BinaryOperator/BasicTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java
! test/sun/misc/JavaLangAccess/NewUnsafeString.java

hg: jdk8/tl/jdk: 8012987: Optimizations for Stream.limit/substream

[paul . sandoz]

Changeset: 28b71c97a72d
Author:psandoz
Date:  2013-06-28 10:29 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/28b71c97a72d

8012987: Optimizations for Stream.limit/substream
Reviewed-by: mduigou
Contributed-by: Brian Goetz , Paul Sandoz 


! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/AbstractTask.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/ForEachOps.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/PipelineHelper.java
! src/share/classes/java/util/stream/SliceOps.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/StreamSpliterators.java
! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java
! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java
+ test/java/util/stream/boottest/java/util/stream/SliceSpliteratorTest.java
! test/java/util/stream/boottest/java/util/stream/StreamFlagsTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java

hg: jdk8/tl/jdk: 2 new changesets

[paul . sandoz]

Changeset: dfd7fb0ce54b
Author:psandoz
Date:  2013-07-03 11:58 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dfd7fb0ce54b

8011427: java.util.concurrent collection Spliterator implementations
Reviewed-by: martin
Contributed-by: Doug Lea 

! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/BlockingDeque.java
! src/share/classes/java/util/concurrent/BlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/DelayQueue.java
! src/share/classes/java/util/concurrent/Delayed.java
! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/share/classes/java/util/concurrent/SynchronousQueue.java

Changeset: bb4ae17c98cf
Author:psandoz
Date:  2013-07-03 11:58 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb4ae17c98cf

8019481: Sync misc j.u.c classes from 166 to tl
Reviewed-by: martin
Contributed-by: Doug Lea 

! src/share/classes/java/util/concurrent/BrokenBarrierException.java
! src/share/classes/java/util/concurrent/CountDownLatch.java
! src/share/classes/java/util/concurrent/CyclicBarrier.java
! src/share/classes/java/util/concurrent/Exchanger.java
! src/share/classes/java/util/concurrent/Phaser.java
! src/share/classes/java/util/concurrent/TimeUnit.java
! src/share/classes/java/util/concurrent/TimeoutException.java
! src/share/classes/java/util/concurrent/package-info.java

hg: jdk8/tl/jdk: 8017329: 8b92-lambda regression: TreeSet("a", "b").stream().substream(1).parallel().iterator() is empty

[paul . sandoz]

Changeset: 7532bb2d6476
Author:psandoz
Date:  2013-07-03 21:19 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7532bb2d6476

8017329: 8b92-lambda regression: TreeSet("a", 
"b").stream().substream(1).parallel().iterator() is empty
Reviewed-by: alanb

! src/share/classes/java/util/stream/SliceOps.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java

hg: jdk8/tl/jdk: 8017141: java.util/stream Spliterators from sequential sources should not catch OOME

[paul . sandoz]

Changeset: 628432ee4d68
Author:henryjen
Date:  2013-07-09 09:15 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/628432ee4d68

8017141: java.util/stream Spliterators from sequential sources should not catch 
OOME
Reviewed-by: mchung
Contributed-by: paul.san...@oracle.com

! src/share/classes/java/util/LinkedList.java
! src/share/classes/java/util/Spliterators.java

hg: jdk8/tl/jdk: 8019551: Make BaseStream public

[paul . sandoz]

Changeset: 44a634c1edc4
Author:psandoz
Date:  2013-07-09 10:44 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44a634c1edc4

8019551: Make BaseStream public
Reviewed-by: chegar, psandoz
Contributed-by: brian goetz 

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/BaseStream.java

hg: jdk8/tl/jdk: 8019370: Sync j.u.c Fork/Join from 166 to tl

[paul . sandoz]

Changeset: 43134e79c0bb
Author:psandoz
Date:  2013-07-09 16:04 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43134e79c0bb

8019370: Sync j.u.c Fork/Join from 166 to tl
Reviewed-by: chegar, martin
Contributed-by: Doug Lea 

! src/share/classes/java/util/concurrent/AbstractExecutorService.java
! src/share/classes/java/util/concurrent/Callable.java
! src/share/classes/java/util/concurrent/CancellationException.java
! src/share/classes/java/util/concurrent/CompletableFuture.java
! src/share/classes/java/util/concurrent/CompletionService.java
! src/share/classes/java/util/concurrent/CountedCompleter.java
! src/share/classes/java/util/concurrent/ExecutionException.java
! src/share/classes/java/util/concurrent/Executor.java
! src/share/classes/java/util/concurrent/ExecutorService.java
! src/share/classes/java/util/concurrent/Executors.java
! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinTask.java
! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
! src/share/classes/java/util/concurrent/Future.java
! src/share/classes/java/util/concurrent/FutureTask.java
! src/share/classes/java/util/concurrent/RecursiveAction.java
! src/share/classes/java/util/concurrent/RecursiveTask.java
! src/share/classes/java/util/concurrent/RejectedExecutionException.java
! src/share/classes/java/util/concurrent/RunnableFuture.java
! src/share/classes/java/util/concurrent/RunnableScheduledFuture.java
! src/share/classes/java/util/concurrent/ScheduledExecutorService.java
! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java

hg: jdk8/tl/jdk: 8017447: Unmodifiable map entry becomes modifiable if taken from a stream of map entries

[paul . sandoz]

Changeset: ff5df05222d1
Author:psandoz
Date:  2013-07-10 09:52 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff5df05222d1

8017447: Unmodifiable map entry becomes modifiable if taken from a stream of 
map entries
Reviewed-by: briangoetz

! src/share/classes/java/util/Collections.java
+ test/java/util/Collections/UnmodifiableMapEntrySet.java

hg: jdk8/tl/jdk: 8020040: Improve and generalize the F/J tasks to handle right or left-balanced trees

[paul . sandoz]

Changeset: 882baa1e0a38
Author:psandoz
Date:  2013-07-10 10:24 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/882baa1e0a38

8020040: Improve and generalize the F/J tasks to handle right or left-balanced 
trees
Reviewed-by: briangoetz
Contributed-by: doug lea , paul sandoz 


! src/share/classes/java/util/stream/AbstractShortCircuitTask.java
! src/share/classes/java/util/stream/AbstractTask.java
! src/share/classes/java/util/stream/ForEachOps.java
! src/share/classes/java/util/stream/Nodes.java

hg: jdk8/tl/jdk: 8019484: Sync j.u.c.ConcurrentHashMap from 166 to tl

[paul . sandoz]

Changeset: 05b164788aab
Author:psandoz
Date:  2013-07-11 13:07 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/05b164788aab

8019484: Sync j.u.c.ConcurrentHashMap from 166 to tl
Reviewed-by: martin
Contributed-by: Doug Lea 

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/ConcurrentMap.java
! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java

hg: jdk8/tl/jdk: 8019395: Consolidate StreamSupport.{stream, parallelStream} into a single method

[paul . sandoz]

Changeset: be096613bfb5
Author:psandoz
Date:  2013-07-03 21:43 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be096613bfb5

8019395: Consolidate StreamSupport.{stream,parallelStream} into a single method
Reviewed-by: henryjen, briangoetz

! src/share/classes/java/io/BufferedReader.java
! src/share/classes/java/lang/CharSequence.java
! src/share/classes/java/nio/X-Buffer.java.template
! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/BitSet.java
! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/java/util/regex/Pattern.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/StreamSupport.java
! src/share/classes/java/util/stream/Streams.java
! src/share/classes/java/util/zip/ZipFile.java
! test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java
! test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java
! test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java
! test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java
! test/java/util/stream/bootlib/java/util/stream/TestData.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java

hg: jdk8/tl/jdk: 8020156: TreeMap.values().spliterator() does not report ORDERED; ...

[paul . sandoz]

Changeset: e83fc6d9cf03
Author:psandoz
Date:  2013-07-29 19:41 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e83fc6d9cf03

8020156: TreeMap.values().spliterator() does not report ORDERED
8020009: TreeMap.entrySet().spliterator() reports SORTED + null comparator but 
the elements are not Comparable
Reviewed-by: mduigou

! src/share/classes/java/util/TreeMap.java
+ test/java/util/Spliterator/SpliteratorCharacteristics.java

hg: jdk8/tl/jdk: 8021863: Stream.concat incorrectly calculates unsized state

[paul . sandoz]

Changeset: 76d88a752a03
Author:psandoz
Date:  2013-07-30 11:32 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76d88a752a03

8021863: Stream.concat incorrectly calculates unsized state
Reviewed-by: chegar

! src/share/classes/java/util/stream/Streams.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatOpTest.java

hg: jdk8/tl/jdk: 8021883: j.u.Random/RandomStream.java test needs more robust timeout duration

[paul . sandoz]

Changeset: d30f357c6050
Author:psandoz
Date:  2013-07-30 14:03 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d30f357c6050

8021883: j.u.Random/RandomStream.java test needs more robust timeout duration
Reviewed-by: chegar

! test/java/util/Random/RandomStreamTest.java

hg: jdk8/tl/jdk: 8020016: Numerous splitereator impls do not throw NPE for null Consumers

[paul . sandoz]

Changeset: 0be7839d4599
Author:psandoz
Date:  2013-08-01 15:28 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0be7839d4599

8020016: Numerous splitereator impls do not throw NPE for null Consumers
Reviewed-by: mduigou, alanb, henryjen

! src/share/classes/java/util/stream/SpinedBuffer.java
! src/share/classes/java/util/stream/StreamSpliterators.java
! src/share/classes/java/util/stream/Streams.java
! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java

hg: jdk8/tl/jdk: 8022326: Spliterator for values of j.u.c.ConcurrentSkipListMap does not report ORDERED

[paul . sandoz]

Changeset: c29ca19cb816
Author:psandoz
Date:  2013-08-09 11:44 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c29ca19cb816

8022326: Spliterator for values of j.u.c.ConcurrentSkipListMap does not report 
ORDERED
Reviewed-by: martin, chegar

! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! test/java/util/Spliterator/SpliteratorCharacteristics.java

hg: jdk8/tl/jdk: 8023150: java/util/stream tests no longer compiling following JDK-8019401

[paul . sandoz]

Changeset: 5fe19566b6f0
Author:psandoz
Date:  2013-08-16 12:29 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5fe19566b6f0

8023150: java/util/stream tests no longer compiling following JDK-8019401
Reviewed-by: alanb

! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java

hg: jdk8/tl/jdk: 2 new changesets

[paul . sandoz]

Changeset: 2eebaff52a94
Author:psandoz
Date:  2013-08-16 12:46 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2eebaff52a94

8012940: More than 50 tests failed in Serialization/DeSerialization testing 
(test-mangled)
Reviewed-by: ksrini

+ test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java
! test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java

Changeset: 02ce5a0e4b98
Author:psandoz
Date:  2013-08-16 12:46 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/02ce5a0e4b98

8022898: java/util/Spliterator/SpliteratorCollisions.java fails in 
HashableIntSpliteratorWithNull data provider
Reviewed-by: henryjen, alanb, rriggs

! test/java/util/Spliterator/SpliteratorCollisions.java

hg: jdk8/tl/jdk: 8022797: Clarify spliterator characteristics for collections containing no elements

[paul . sandoz]

Changeset: 737b6c298d81
Author:psandoz
Date:  2013-08-13 11:16 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/737b6c298d81

8022797: Clarify spliterator characteristics for collections containing no 
elements
Reviewed-by: alanb, mduigou

! src/share/classes/java/util/Collection.java

hg: jdk8/tl/jdk: 8022318: Document Spliterator characteristics and binding policy of java util concurrent collection impls

[paul . sandoz]

Changeset: 9e9f5713b26d
Author:psandoz
Date:  2013-08-06 14:26 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e9f5713b26d

8022318: Document Spliterator characteristics and binding policy of java util 
concurrent collection impls
Reviewed-by: chegar
Contributed-by: Martin Buchholz , Paul Sandoz 


! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/DelayQueue.java
! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/share/classes/java/util/concurrent/SynchronousQueue.java
! src/share/classes/java/util/concurrent/package-info.java

hg: jdk8/tl/jdk: 8014824: Document Spliterator characteristics and binding policy of java util collection impls

[paul . sandoz]

Changeset: 3647aab7b1d5
Author:psandoz
Date:  2013-08-06 14:26 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3647aab7b1d5

8014824: Document Spliterator characteristics and binding policy of java util 
collection impls
Reviewed-by: chegar

! src/share/classes/java/util/ArrayDeque.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashSet.java
! src/share/classes/java/util/LinkedHashMap.java
! src/share/classes/java/util/LinkedHashSet.java
! src/share/classes/java/util/LinkedList.java
! src/share/classes/java/util/List.java
! src/share/classes/java/util/PriorityQueue.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/TreeMap.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/Vector.java

hg: jdk8/tl/jdk: 8023367: Collections.emptyList().sort((Comparator)null) throws NPE

[paul . sandoz]

Changeset: c17d6543b30f
Author:psandoz
Date:  2013-08-20 17:36 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c17d6543b30f

8023367: Collections.emptyList().sort((Comparator)null) throws NPE
Reviewed-by: alanb, mduigou

! src/share/classes/java/util/Collections.java
! test/java/util/Collection/ListDefaults.java

hg: jdk8/tl/jdk: 8023234: StampedLock serializes readers on writer unlock

[paul . sandoz]

Changeset: 8a36fc7f494c
Author:shade
Date:  2013-08-26 17:50 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a36fc7f494c

8023234: StampedLock serializes readers on writer unlock
Summary: Sync-up the fix from jsr166 CVS, signal more readers on writer unlock
Reviewed-by: martin, shade
Contributed-by: Doug Lea 

! src/share/classes/java/util/concurrent/locks/StampedLock.java
+ test/java/util/concurrent/locks/StampedLock/ReadersUnlockAfterWriteUnlock.java

hg: jdk8/tl/jdk: 8020292: j.u.SplittableRandom

[paul . sandoz]

Changeset: 5ce9025c9e1a
Author:psandoz
Date:  2013-08-26 22:55 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ce9025c9e1a

8020292: j.u.SplittableRandom
Reviewed-by: mduigou
Contributed-by: Guy Steele , Doug Lea 
, Brian Goetz , Paul Sandoz 


+ src/share/classes/java/util/SplittableRandom.java
+ test/java/util/SplittableRandom/SplittableRandomTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/SplittableRandomTest.java

hg: jdk8/tl/jdk: 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom

[paul . sandoz]

Changeset: b1f41565b806
Author:psandoz
Date:  2013-08-28 22:11 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1f41565b806

8023155: Ensure functional consistency across Random, ThreadLocalRandom, 
SplittableRandom
Reviewed-by: mduigou
Contributed-by: Doug Lea , Paul Sandoz 


! src/share/classes/java/util/Random.java
! src/share/classes/java/util/concurrent/ThreadLocalRandom.java
! test/java/util/Random/RandomStreamTest.java
+ test/java/util/Random/RandomTest.java
! test/java/util/SplittableRandom/SplittableRandomTest.java
+ test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java

hg: jdk8/tl/jdk: 8024182: test/java/util/Arrays/SetAllTest.java fails to compile due to recent compiler changes

[paul . sandoz]

Changeset: 462c5589bc1a
Author:psandoz
Date:  2013-08-12 12:22 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/462c5589bc1a

8024182: test/java/util/Arrays/SetAllTest.java fails to compile due to recent 
compiler changes
Summary: Use explicit lambda due to javac simplfying rules for overload 
resolution with implicit lambdas
Reviewed-by: alanb, mduigou

! test/java/util/Arrays/SetAllTest.java

hg: jdk8/tl/jdk: 8023463: Improvements to HashMap/LinkedHashMap use of bins/buckets and trees (red/black); ...

[paul . sandoz]

Changeset: d62c911aebbb
Author:psandoz
Date:  2013-09-04 09:34 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d62c911aebbb

8023463: Improvements to HashMap/LinkedHashMap use of bins/buckets and trees 
(red/black)
8012913: LinkedHashMap key/value/entry spliterators should report ORDERED
Reviewed-by: mduigou, forax, bchristi, alanb
Contributed-by: Doug Lea , Paul Sandoz 


! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/LinkedHashMap.java
! test/java/lang/reflect/Generics/Probe.java
! test/java/util/Map/CheckRandomHashSeed.java
! test/java/util/Map/InPlaceOpsCollisions.java
+ test/java/util/Map/MapBinToFromTreeTest.java
- test/java/util/Map/TreeBinSplitBackToEntries.java
! test/java/util/Spliterator/SpliteratorCharacteristics.java

hg: jdk8/tl/jdk: 8010293: java/util/concurrent/ConcurrentHashMap/toArray.java fails intermittently

[paul . sandoz]

Changeset: ff6c76f7733e
Author:psandoz
Date:  2013-09-02 11:59 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff6c76f7733e

8010293: java/util/concurrent/ConcurrentHashMap/toArray.java fails 
intermittently
Reviewed-by: forax, chegar, alanb
Contributed-by: Doug Lea , Peter Levart 
, Paul Sandoz 

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! test/java/util/concurrent/ConcurrentHashMap/toArray.java

hg: jdk8/tl/jdk: 8024837: Rename java/util/concurrent/ConcurrentHashMap/toArray.java to ToArray.java

[paul . sandoz]

Changeset: 5025ed287a4a
Author:psandoz
Date:  2013-09-15 16:13 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5025ed287a4a

8024837: Rename java/util/concurrent/ConcurrentHashMap/toArray.java to 
ToArray.java
Reviewed-by: alanb

! test/java/util/concurrent/ConcurrentHashMap/ToArray.java < 
test/java/util/concurrent/ConcurrentHashMap/toArray.java

hg: jdk8/tl/jdk: 8025002: "".codePoints().sorted().iterator().hasNext() causes NegativeArraySizeException

[paul . sandoz]

Changeset: f36714707c38
Author:psandoz
Date:  2013-09-18 10:49 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f36714707c38

8025002: "".codePoints().sorted().iterator().hasNext() causes 
NegativeArraySizeException
Reviewed-by: henryjen, alanb

! src/share/classes/java/lang/CharSequence.java
! test/java/lang/CharSequence/DefaultTest.java

hg: jdk8/tl/jdk: 8024405: Spliterators.spliterator should support CONCURRENT characteristic

[paul . sandoz]

Changeset: 0ef7ddef9de0
Author:psandoz
Date:  2013-09-19 20:41 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ef7ddef9de0

8024405: Spliterators.spliterator should support CONCURRENT characteristic
Reviewed-by: martin

! src/share/classes/java/util/Spliterator.java
! src/share/classes/java/util/Spliterators.java
! test/java/util/Spliterator/SpliteratorCharacteristics.java
! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java