From ecki at zusammenkunft.net  Wed Nov  1 00:52:14 2017
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 1 Nov 2017 00:52:14 +0000
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>,
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
Message-ID: <AM4PR08MB12199717DB39BAA682DE5B3BFF5F0@AM4PR08MB1219.eurprd08.prod.outlook.com>

Having a List.of(List) copy constructor would save an additional array copy in the collector Which uses  (List<T>)List.of(list.toArray())

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Stuart Marks <stuart.marks at oracle.com>
Sent: Wednesday, November 1, 2017 12:49:56 AM
To: core-libs-dev
Subject: Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

Updated webrev, based on comments from Brian and Roger:

     http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.2/

s'marks


On 10/30/17 3:50 PM, Stuart Marks wrote:
> (also includes 8184690: add Collectors for collecting into unmodifiable List,
> Set, and Map)
>
> Hi all,
>
> Here's an updated webrev for this changeset; the previous review thread is here:
>
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049261.html
>
> This webrev includes the following:
>
> * specification revisions to provide clearer definitions of "view" collections,
> "unmodifiable" collections, and "unmodifiable views"
>
> * new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" methods
>
> * new Collectors.toUnmodifiableList, Set, and Map methods
>
> * tests for the new API methods
>
> I've added some assertions that require some independence between the source
> collection (or map) and the result of the copyOf() method.
>
> I've made a small but significant change to Set.copyOf compared to the previous
> round. Previously, it specified that the first of any equal elements was
> preserved. Now, it is explicitly unspecified which of any equals elements is
> preserved. This is consistent with Set.addAll, Collectors.toSet, and the newly
> added Collectors.toUnmodifiableSet, none of which specify which of duplicate
> elements is preserved.
>
> (The outlier here is Stream.distinct, which specifies that the first element of
> any duplicates is preserved, if the stream is ordered.)
>
> I've also made some minor wording/editorial changes in response to suggestions
> from David Holmes and Roger Riggs. I've kept the wording changes that give
> emphasis to "unmodifiable" over "immutable." The term "immutable" is
> inextricably intertwined with "persistent" when it comes to data structures, and
> I believe we'll be explaining this forever if Java's "immutable" means something
> different from everybody else's.
>
> Webrev:
>
>      http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.1/
>
> Bugs:
>
>      https://bugs.openjdk.java.net/browse/JDK-8177290
>          add copy factory methods for unmodifiable List, Set, Map
>
>      https://bugs.openjdk.java.net/browse/JDK-8184690
>          add Collectors for collecting into unmodifiable List, Set, and Map
>
> Thanks,
>
> s'marks

From david.holmes at oracle.com  Wed Nov  1 01:49:54 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 1 Nov 2017 11:49:54 +1000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
Message-ID: <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>

Hi Roger,

On 31/10/2017 11:58 PM, Roger Riggs wrote:
> Hi Peter,
> 
> Only native resources that do not map to the heap allocation/gc cycle 
> need any kind
> of cleanup.? I would work toward a model that encapsulates the reference 
> to a native resource
> with a corresponding allocation/release mechanism as you've described 
> here and in the
> thread on zip.
> 
> For cleanup purposes, the independence of each resource may improve 
> robustness
> by avoiding dependencies and opportunities for entanglements and bugs 
> due to exceptions
> and other failures.
> 
> In the case of TPE, the native resources are Threads, which keep running 
> even if they are
> unreferenced and are kept referenced via ThreadGroups.
> I don't know the Executor code well enough to do more than speculate, 
> but would suggest
> that a cleaner (or similar) should be registered for each thread .

Threads are not native resources to be managed by Cleaners! A live 
Thread can never be cleaned. A dead thread has nothing to clean!

David
-----

> For TPE, since Threads do not become unreferenced, the part of the spec 
> related to finalize
> being called by the finalizer thread is moot.
> 
> $.02, Roger
> 
> On 10/31/2017 5:24 AM, Peter Levart wrote:
>> Hi,
>>
>> Here are some of my thoughts...
>>
>> On 10/31/17 05:37, David Holmes wrote:
>>> Hi Roger,
>>>
>>> On 31/10/2017 12:43 AM, Roger Riggs wrote:
>>>> Hi David,
>>>>
>>>> On 10/30/2017 3:31 AM, David Holmes wrote:
>>>>> Hi Andrej,
>>>>>
>>>>> On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
>>>>>> Hi David,
>>>>>>
>>>>>>> On 30. Oct 2017, at 01:40, David Holmes <david.holmes at oracle.com> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Roger,
>>>>>>>
>>>>>>> On 30/10/2017 10:24 AM, Roger Riggs wrote:
>>>>>>>> Hi,
>>>>>>>> With the deprecation of Object.finalize its time to look at its 
>>>>>>>> uses too see if they can be removed or mitigated.
>>>>>>>
>>>>>>> So the nice thing about finalize was that it followed a 
>>>>>>> nice/clean/simple OO model where a subclass could override, add 
>>>>>>> their own cleanup and then call super.finalize(). With finalize() 
>>>>>>> deprecated, and the new mechanism being Cleaners, how do Cleaners 
>>>>>>> support such usages?
>>>>>>
>>>>>> Instead of ThreadPoolExecutor.finalize you can override 
>>>>>> ThreadPoolExecutor.terminated.
>>>>>
>>>>> True. Though overriding shutdown() would be the semantic equivalent 
>>>>> of overriding finalize(). :)
>>>>>
>>>>> In the general case though finalize() might be invoking a final 
>>>>> method.
>>
>> Overriding shutdown() would only work when this method is explicitly 
>> invoked by user code. Using Cleaner API instead of finalization can 
>> not employ methods on object that is being tracked as that object is 
>> already gone when Cleaner invokes the cleanup function.
>>
>> Migrating TPE to Cleaner API might be particularly painful since the 
>> state needed to perform the shutdown is currently in the TPE instance 
>> fields and would have to be moved into the cleanup function. The 
>> easiest way to do that is to:
>>
>> - rename class ThreadPoolExecutor to package-private 
>> ThreadPoolExecutorImpl
>> - create new class ThreadPoolExecutor with same public API delegating 
>> the functionality to the embedded implementation
>> - registering Cleaner.Cleanable to perform shutdown of embedded 
>> executor when the public-facing executor becomes phantom reachable
>>
>> This would have an added benefit of automatically shut(ing)down() the 
>> pool when it is not reachable any more but still has idle threads.
>>
>>>>>
>>>>> Anyway I'm not sure we can actually do something to try to move 
>>>>> away from use of finalize() in TPE. finalize() is only deprecated - 
>>>>> it is still expected to work as it has always done. Existing 
>>>>> subclasses that override finalize() must continue to work until 
>>>>> some point where we say finalize() is not only deprecated but 
>>>>> obsoleted (it no longer does anything). So until then is there 
>>>>> actually any point in doing anything? Does having a Cleaner and a 
>>>>> finalize() method make sense? Does it aid in the transition?
>>>> As you observe, the alternatives directly using PhantomRefs or the 
>>>> Cleanup do not provide
>>>> as nice a model.? Unfortunately, that model has been recognized to 
>>>> have a number of
>>>> issues [1].? Finalization is a poor substitute for explicit 
>>>> shutdown, it is unpredictable and unreliable,
>>>> and not guaranteed to be executed.
>>>
>>> I'm not trying to support/defend finalize(). But it does support the 
>>> very common OO pattern of "override to specialize then call super".
>>
>> I have been thinking about that and I see two approaches to enable 
>> subclasses to contribute cleanup code:
>>
>> - one simple approach is for each subclass to use it's own independent 
>> Cleaner/Cleanable. The benefit is that each subclass is independent of 
>> its super/sub classes, the drawback is that cleanup functions are 
>> called in arbitrary order, even in different threads. But for 
>> cleaning-up independent resources this should work.
>>
>> - the other approach is more involving as it requires the base class 
>> to establish an infrastructure for contributing cleanup code. For this 
>> purpose, the internal low-level Cleaner API is most appropriate 
>> thought it can be done with public API too. For example (with public API):
>>
>>
>> public class BaseClass implements AutoCloseable {
>>
>> ??? protected static class BaseResource implements Runnable {
>> ??????? @Override
>> ??????? public void run() {
>> ??????????? // cleanup
>> ??????? }
>> ??? }
>>
>> ??? protected final BaseResource resource = createResource();
>> ??? private final Cleaner.Cleanable cleanable = 
>> CleanerFactory.cleaner().register(this, resource);
>>
>> ??? protected BaseResource createResource() {
>> ??????? return new BaseResource();
>> ??? }
>>
>> ??? public BaseClass() {
>> ??????? // init BaseResource resource...
>> ??? }
>>
>> ??? @Override
>> ??? public final void close() {
>> ??????? cleanable.clean();
>> ??? }
>> }
>>
>>
>> public class DerivedClass extends BaseClass {
>>
>> ??? protected static class DerivedResource extends BaseResource {
>> ??????? @Override
>> ??????? public void run() {
>> ??????????? // before-super cleanup
>> ??????????? super.run();
>> ??????????? // after-super cleanup
>> ??????? }
>> ??? }
>>
>> ??? @Override
>> ??? protected DerivedResource createResource() {
>> ??????? return new DerivedResource();
>> ??? }
>>
>> ??? public DerivedClass() {
>> ??????? super();
>> ??????? DerivedResource resource = (DerivedResource) this.resource;
>> ??????? // init DerivedResource resource
>> ??? }
>> }
>>
>>
>> And alternative with private low-level API:
>>
>>
>> public class BaseClass implements AutoCloseable {
>>
>> ??? protected static class BaseResource extends 
>> PhantomCleanable<BaseClass> {
>>
>> ??????? protected BaseResource(BaseClass referent) {
>> ??????????? super(referent, CleanerFactory.cleaner());
>> ??????? }
>>
>> ??????? @Override
>> ??????? protected void performCleanup() {
>> ??????????? // cleanup
>> ??????? }
>> ??? }
>>
>> ??? protected final BaseResource resource = createResource();
>>
>> ??? protected BaseResource createResource() {
>> ??????? return new BaseResource(this);
>> ??? }
>>
>> ??? public BaseClass() {
>> ??????? // init BaseResource resource...
>> ??? }
>>
>> ??? @Override
>> ??? public final void close() {
>> ??????? resource.clean();
>> ??? }
>> }
>>
>>
>> public class DerivedClass extends BaseClass {
>>
>> ??? protected static class DerivedResource extends BaseResource {
>>
>> ??????? protected DerivedResource(DerivedClass referent) {
>> ??????????? super(referent);
>> ??????? }
>>
>> ??????? @Override
>> ??????? protected void performCleanup() {
>> ??????????? // before-super cleanup
>> ??????????? super.performCleanup();
>> ??????????? // after-super cleanup
>> ??????? }
>> ??? }
>>
>> ??? @Override
>> ??? protected DerivedResource createResource() {
>> ??????? return new DerivedResource(this);
>> ??? }
>>
>> ??? public DerivedClass() {
>> ??????? super();
>> ??????? DerivedResource resource = (DerivedResource) this.resource;
>> ??????? // init DerivedResource resource
>> ??? }
>> }
>>
>>
>> Regards, Peter
>>
>>>
>>>> ThreadPoolExecutor has a responsibility to cleanup any native 
>>>> resources it has allocated (threads)
>>>> and it should be free to use whatever mechanism is appropriate. 
>>>> Currently, the spec for finalize
>>>> does not give it that freedom.
>>>
>>> I suppose in hindsight we (JSR-166 EG) could have described automatic 
>>> shutdown without mentioning the word "finalize", but that ship has 
>>> sailed. We did specify it and people can expect it to be usable and 
>>> they can expect it to work. While encouraging people to move away 
>>> from finalization is a good thing you have to give them a workable 
>>> replacement.
>>>
>>>> The initiative is to identify and remediate existing uses of 
>>>> finalization in the JDK.
>>>> The primary concern is about subclasses that reply on the current spec.
>>>> If I'm using grepcode correctly[2], it does not show any subclasses 
>>>> of ThreadPoolExecutor that
>>>> override finalize; so it may be a non-issue.
>>>
>>> Pardon my skepticism if I don't consider "grepcode" as a reasonable 
>>> indicator of whether there are subclasses of TPE that override 
>>> finalize. Only a small fraction of source code is in the open.
>>>
>>> And I have to agree with Martin that the current documentation for 
>>> finalize() in TPE is somewhat inappropriate. If you deprecate 
>>> something you're supposed to point the user to the preferred way of 
>>> doing something other than the deprecated method - but there is none. 
>>> finalize() in TPE should not have been deprecated until we provided 
>>> that alternative.
>>>
>>> I think the way forward here would be to:
>>>
>>> 1. Change TPE.finalize() to final to force any subclasses to migrate 
>>> to the new mechanism going forward.
>>>
>>> 2. Implement the new mechanism - presumably Cleaner - and document 
>>> how to achieve the effect of "override to specialize then call super" 
>>> (presumably by overriding shutdown() instead).
>>>
>>> then in a few releases we remove TPE.finalize() (at the same time as 
>>> we remove it from Object).
>>>
>>> Cheers,
>>> David
>>>
>>>> Regards, Roger
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8165641
>>>>
>>>> [2] 
>>>> http://grepcode.com/search/usages?type=method&id=repository.grepcode.com%24java%24root at jdk%24openjdk at 8u40-b25@java%24util%24concurrent at ThreadPoolExecutor@finalize%28%29&k=d
>>>>
>>
> 

From david.holmes at oracle.com  Wed Nov  1 01:58:21 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 1 Nov 2017 11:58:21 +1000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <305aa1b0-ee40-b2fd-d1bd-4aeedad55a56@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
 <bfd6c977-df4d-53ba-a59c-8e2a6c04f2eb@Oracle.com>
 <CA+kOe08vE5hXJRot0t8p==VnsY6DEaD0ipqcrMYPkhMOW=rzDg@mail.gmail.com>
 <305aa1b0-ee40-b2fd-d1bd-4aeedad55a56@oracle.com>
Message-ID: <16f9c87e-3f23-a813-fb62-ed8f616c7e5d@oracle.com>

Hi Stuart,

Jumping to the end ...

On 1/11/2017 6:37 AM, Stuart Marks wrote:
> On 10/30/17 10:21 AM, Martin Buchholz wrote:
>>> The initiative is to identify and remediate existing uses of 
>>> finalization
>>> in the JDK.
>>
>> I've been skeptical about this initiative as stated.? I would not have
>> deprecated finalize(). We will never remove finalize() from the JDK, 
>> and I
>> don't see how switching TPE from finalize to some other mechanism such as
>> Cleaner has real benefits for users.? There aren't enough instances of 
>> TPE
>> created for finalization to be a real user performance problem.
> 
> Interesting that you say "we will never remove finalize()" ... it is 
> exactly the goal of this initiative to remove finalize() eventually. Or 
> at least to remove the finalization mechanism. It's been a thorn in the 
> side of GC implementors since forever. As Roger stated, the early part 
> of this effort is to remove uses from within the JDK, and to warn 
> external users to start migrating to other facilities. Hence, we've 
> deprecated it and are having this discussion.
> 
> I don't know what the later parts of the transition will look like. 
> Perhaps at some point we deprecate Object.finalize() for removal; 
> perhaps at some point the VM stops calling Object.finalize() even though 
> the method is declared; perhaps at some point we actually remove the 
> Object.finalize() method. All of this will require further discussion, 
> and it will be based on our experience working through these early 
> remediation steps.
> 
>> TPE's spec currently has a finalize deprecation warning, but this is not
>> helpful for users.
>> (a documentation readability regression!)
>> https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/ThreadPoolExecutor.html#finalize-- 
>>
> 
> I'm not sure why you say this isn't helpful. It's clearly not helpful to 
> *clients* of TPE; but since finalize() is protected, the warning is 
> clearly directed at subclasses, and it provides information about 
> migrating away from finalization. Should say something different?

It isn't helpful to people subclassing TPE (or any class that defines 
finalize()) because the general strategies described in 
Object.finalize() can't be applied by the subclass independent of the 
class (TPE here) it is subclassing. Unless TPE provides an alternate 
mechanism, the subclass is stuck with finalize().

David

> s'marks

From mandy.chung at oracle.com  Wed Nov  1 03:17:40 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 31 Oct 2017 20:17:40 -0700
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <55ff486d-2b09-6463-734e-c769603cdae7@gmail.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
 <59F7735A.3000501@oracle.com>
 <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>
 <0ec13ca6-d542-ba81-c804-bfd524564f6a@gmail.com>
 <64f46e40-b641-b280-eed3-99606e9ad1d5@oracle.com>
 <55ff486d-2b09-6463-734e-c769603cdae7@gmail.com>
Message-ID: <9904feb8-7cab-44eb-fcad-e6d5988982e5@oracle.com>



On 10/31/17 4:07 PM, Peter Levart wrote:
> Hi Mandy, Sherman, Roger,
>
> On 10/31/17 00:25, mandy chung wrote:
>>
> I played a little with an idea of how such additional Cleaner API 
> might look like. Here's what I came up with, together with how this 
> would apply to ZipFile/Inflater/Deflater:
>
> http://cr.openjdk.java.net/~plevart/jdk10-dev/8185582_ZIP.cleaner/webrev.02/
>
> So, what do you think of this new Cleaner API extension?

This serves as a good starting point.? I converted the 
ClassLoader.NativeLibrary to use it:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev-cleanable/

Looks reasonably well and probably some other improvement I could do.? I 
use createResource rather than createLongResource which is specialized 
for an address. We should check out panama how this plays out.

I think it would be useful to iterate on several more use cases and it 
would be better to separate this RFE from JDK-8185582 so that we can 
explore with its own pace.

Mandy

From peter.levart at gmail.com  Wed Nov  1 08:16:46 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 1 Nov 2017 09:16:46 +0100
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
Message-ID: <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>



On 11/01/17 02:49, David Holmes wrote:
> Hi Roger,
>
> On 31/10/2017 11:58 PM, Roger Riggs wrote:
>> Hi Peter,
>>
>> Only native resources that do not map to the heap allocation/gc cycle 
>> need any kind
>> of cleanup.? I would work toward a model that encapsulates the 
>> reference to a native resource
>> with a corresponding allocation/release mechanism as you've described 
>> here and in the
>> thread on zip.
>>
>> For cleanup purposes, the independence of each resource may improve 
>> robustness
>> by avoiding dependencies and opportunities for entanglements and bugs 
>> due to exceptions
>> and other failures.
>>
>> In the case of TPE, the native resources are Threads, which keep 
>> running even if they are
>> unreferenced and are kept referenced via ThreadGroups.
>> I don't know the Executor code well enough to do more than speculate, 
>> but would suggest
>> that a cleaner (or similar) should be registered for each thread .
>
> Threads are not native resources to be managed by Cleaners! A live 
> Thread can never be cleaned. A dead thread has nothing to clean!

Right, but an idle thread, waiting for a task that will never come since 
the only entry point for submitting tasks is not reachable (the pool), 
may be cleaned...

Regards, Peter

>
> David
> -----
>
>> For TPE, since Threads do not become unreferenced, the part of the 
>> spec related to finalize
>> being called by the finalizer thread is moot.
>>
>> $.02, Roger
>>
>> On 10/31/2017 5:24 AM, Peter Levart wrote:
>>> Hi,
>>>
>>> Here are some of my thoughts...
>>>
>>> On 10/31/17 05:37, David Holmes wrote:
>>>> Hi Roger,
>>>>
>>>> On 31/10/2017 12:43 AM, Roger Riggs wrote:
>>>>> Hi David,
>>>>>
>>>>> On 10/30/2017 3:31 AM, David Holmes wrote:
>>>>>> Hi Andrej,
>>>>>>
>>>>>> On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>>> On 30. Oct 2017, at 01:40, David Holmes 
>>>>>>>> <david.holmes at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hi Roger,
>>>>>>>>
>>>>>>>> On 30/10/2017 10:24 AM, Roger Riggs wrote:
>>>>>>>>> Hi,
>>>>>>>>> With the deprecation of Object.finalize its time to look at 
>>>>>>>>> its uses too see if they can be removed or mitigated.
>>>>>>>>
>>>>>>>> So the nice thing about finalize was that it followed a 
>>>>>>>> nice/clean/simple OO model where a subclass could override, add 
>>>>>>>> their own cleanup and then call super.finalize(). With 
>>>>>>>> finalize() deprecated, and the new mechanism being Cleaners, 
>>>>>>>> how do Cleaners support such usages?
>>>>>>>
>>>>>>> Instead of ThreadPoolExecutor.finalize you can override 
>>>>>>> ThreadPoolExecutor.terminated.
>>>>>>
>>>>>> True. Though overriding shutdown() would be the semantic 
>>>>>> equivalent of overriding finalize(). :)
>>>>>>
>>>>>> In the general case though finalize() might be invoking a final 
>>>>>> method.
>>>
>>> Overriding shutdown() would only work when this method is explicitly 
>>> invoked by user code. Using Cleaner API instead of finalization can 
>>> not employ methods on object that is being tracked as that object is 
>>> already gone when Cleaner invokes the cleanup function.
>>>
>>> Migrating TPE to Cleaner API might be particularly painful since the 
>>> state needed to perform the shutdown is currently in the TPE 
>>> instance fields and would have to be moved into the cleanup 
>>> function. The easiest way to do that is to:
>>>
>>> - rename class ThreadPoolExecutor to package-private 
>>> ThreadPoolExecutorImpl
>>> - create new class ThreadPoolExecutor with same public API 
>>> delegating the functionality to the embedded implementation
>>> - registering Cleaner.Cleanable to perform shutdown of embedded 
>>> executor when the public-facing executor becomes phantom reachable
>>>
>>> This would have an added benefit of automatically shut(ing)down() 
>>> the pool when it is not reachable any more but still has idle threads.
>>>
>>>>>>
>>>>>> Anyway I'm not sure we can actually do something to try to move 
>>>>>> away from use of finalize() in TPE. finalize() is only deprecated 
>>>>>> - it is still expected to work as it has always done. Existing 
>>>>>> subclasses that override finalize() must continue to work until 
>>>>>> some point where we say finalize() is not only deprecated but 
>>>>>> obsoleted (it no longer does anything). So until then is there 
>>>>>> actually any point in doing anything? Does having a Cleaner and a 
>>>>>> finalize() method make sense? Does it aid in the transition?
>>>>> As you observe, the alternatives directly using PhantomRefs or the 
>>>>> Cleanup do not provide
>>>>> as nice a model.? Unfortunately, that model has been recognized to 
>>>>> have a number of
>>>>> issues [1].? Finalization is a poor substitute for explicit 
>>>>> shutdown, it is unpredictable and unreliable,
>>>>> and not guaranteed to be executed.
>>>>
>>>> I'm not trying to support/defend finalize(). But it does support 
>>>> the very common OO pattern of "override to specialize then call 
>>>> super".
>>>
>>> I have been thinking about that and I see two approaches to enable 
>>> subclasses to contribute cleanup code:
>>>
>>> - one simple approach is for each subclass to use it's own 
>>> independent Cleaner/Cleanable. The benefit is that each subclass is 
>>> independent of its super/sub classes, the drawback is that cleanup 
>>> functions are called in arbitrary order, even in different threads. 
>>> But for cleaning-up independent resources this should work.
>>>
>>> - the other approach is more involving as it requires the base class 
>>> to establish an infrastructure for contributing cleanup code. For 
>>> this purpose, the internal low-level Cleaner API is most appropriate 
>>> thought it can be done with public API too. For example (with public 
>>> API):
>>>
>>>
>>> public class BaseClass implements AutoCloseable {
>>>
>>> ??? protected static class BaseResource implements Runnable {
>>> ??????? @Override
>>> ??????? public void run() {
>>> ??????????? // cleanup
>>> ??????? }
>>> ??? }
>>>
>>> ??? protected final BaseResource resource = createResource();
>>> ??? private final Cleaner.Cleanable cleanable = 
>>> CleanerFactory.cleaner().register(this, resource);
>>>
>>> ??? protected BaseResource createResource() {
>>> ??????? return new BaseResource();
>>> ??? }
>>>
>>> ??? public BaseClass() {
>>> ??????? // init BaseResource resource...
>>> ??? }
>>>
>>> ??? @Override
>>> ??? public final void close() {
>>> ??????? cleanable.clean();
>>> ??? }
>>> }
>>>
>>>
>>> public class DerivedClass extends BaseClass {
>>>
>>> ??? protected static class DerivedResource extends BaseResource {
>>> ??????? @Override
>>> ??????? public void run() {
>>> ??????????? // before-super cleanup
>>> ??????????? super.run();
>>> ??????????? // after-super cleanup
>>> ??????? }
>>> ??? }
>>>
>>> ??? @Override
>>> ??? protected DerivedResource createResource() {
>>> ??????? return new DerivedResource();
>>> ??? }
>>>
>>> ??? public DerivedClass() {
>>> ??????? super();
>>> ??????? DerivedResource resource = (DerivedResource) this.resource;
>>> ??????? // init DerivedResource resource
>>> ??? }
>>> }
>>>
>>>
>>> And alternative with private low-level API:
>>>
>>>
>>> public class BaseClass implements AutoCloseable {
>>>
>>> ??? protected static class BaseResource extends 
>>> PhantomCleanable<BaseClass> {
>>>
>>> ??????? protected BaseResource(BaseClass referent) {
>>> ??????????? super(referent, CleanerFactory.cleaner());
>>> ??????? }
>>>
>>> ??????? @Override
>>> ??????? protected void performCleanup() {
>>> ??????????? // cleanup
>>> ??????? }
>>> ??? }
>>>
>>> ??? protected final BaseResource resource = createResource();
>>>
>>> ??? protected BaseResource createResource() {
>>> ??????? return new BaseResource(this);
>>> ??? }
>>>
>>> ??? public BaseClass() {
>>> ??????? // init BaseResource resource...
>>> ??? }
>>>
>>> ??? @Override
>>> ??? public final void close() {
>>> ??????? resource.clean();
>>> ??? }
>>> }
>>>
>>>
>>> public class DerivedClass extends BaseClass {
>>>
>>> ??? protected static class DerivedResource extends BaseResource {
>>>
>>> ??????? protected DerivedResource(DerivedClass referent) {
>>> ??????????? super(referent);
>>> ??????? }
>>>
>>> ??????? @Override
>>> ??????? protected void performCleanup() {
>>> ??????????? // before-super cleanup
>>> ??????????? super.performCleanup();
>>> ??????????? // after-super cleanup
>>> ??????? }
>>> ??? }
>>>
>>> ??? @Override
>>> ??? protected DerivedResource createResource() {
>>> ??????? return new DerivedResource(this);
>>> ??? }
>>>
>>> ??? public DerivedClass() {
>>> ??????? super();
>>> ??????? DerivedResource resource = (DerivedResource) this.resource;
>>> ??????? // init DerivedResource resource
>>> ??? }
>>> }
>>>
>>>
>>> Regards, Peter
>>>
>>>>
>>>>> ThreadPoolExecutor has a responsibility to cleanup any native 
>>>>> resources it has allocated (threads)
>>>>> and it should be free to use whatever mechanism is appropriate. 
>>>>> Currently, the spec for finalize
>>>>> does not give it that freedom.
>>>>
>>>> I suppose in hindsight we (JSR-166 EG) could have described 
>>>> automatic shutdown without mentioning the word "finalize", but that 
>>>> ship has sailed. We did specify it and people can expect it to be 
>>>> usable and they can expect it to work. While encouraging people to 
>>>> move away from finalization is a good thing you have to give them a 
>>>> workable replacement.
>>>>
>>>>> The initiative is to identify and remediate existing uses of 
>>>>> finalization in the JDK.
>>>>> The primary concern is about subclasses that reply on the current 
>>>>> spec.
>>>>> If I'm using grepcode correctly[2], it does not show any 
>>>>> subclasses of ThreadPoolExecutor that
>>>>> override finalize; so it may be a non-issue.
>>>>
>>>> Pardon my skepticism if I don't consider "grepcode" as a reasonable 
>>>> indicator of whether there are subclasses of TPE that override 
>>>> finalize. Only a small fraction of source code is in the open.
>>>>
>>>> And I have to agree with Martin that the current documentation for 
>>>> finalize() in TPE is somewhat inappropriate. If you deprecate 
>>>> something you're supposed to point the user to the preferred way of 
>>>> doing something other than the deprecated method - but there is 
>>>> none. finalize() in TPE should not have been deprecated until we 
>>>> provided that alternative.
>>>>
>>>> I think the way forward here would be to:
>>>>
>>>> 1. Change TPE.finalize() to final to force any subclasses to 
>>>> migrate to the new mechanism going forward.
>>>>
>>>> 2. Implement the new mechanism - presumably Cleaner - and document 
>>>> how to achieve the effect of "override to specialize then call 
>>>> super" (presumably by overriding shutdown() instead).
>>>>
>>>> then in a few releases we remove TPE.finalize() (at the same time 
>>>> as we remove it from Object).
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>> Regards, Roger
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8165641
>>>>>
>>>>> [2] 
>>>>> http://grepcode.com/search/usages?type=method&id=repository.grepcode.com%24java%24root at jdk%24openjdk at 8u40-b25@java%24util%24concurrent at ThreadPoolExecutor@finalize%28%29&k=d
>>>>>
>>>
>>


From david.holmes at oracle.com  Wed Nov  1 09:04:13 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 1 Nov 2017 19:04:13 +1000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
Message-ID: <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>

On 1/11/2017 6:16 PM, Peter Levart wrote:
> On 11/01/17 02:49, David Holmes wrote:
>> Hi Roger,
>>
>> On 31/10/2017 11:58 PM, Roger Riggs wrote:
>>> Hi Peter,
>>>
>>> Only native resources that do not map to the heap allocation/gc cycle 
>>> need any kind
>>> of cleanup.? I would work toward a model that encapsulates the 
>>> reference to a native resource
>>> with a corresponding allocation/release mechanism as you've described 
>>> here and in the
>>> thread on zip.
>>>
>>> For cleanup purposes, the independence of each resource may improve 
>>> robustness
>>> by avoiding dependencies and opportunities for entanglements and bugs 
>>> due to exceptions
>>> and other failures.
>>>
>>> In the case of TPE, the native resources are Threads, which keep 
>>> running even if they are
>>> unreferenced and are kept referenced via ThreadGroups.
>>> I don't know the Executor code well enough to do more than speculate, 
>>> but would suggest
>>> that a cleaner (or similar) should be registered for each thread .
>>
>> Threads are not native resources to be managed by Cleaners! A live 
>> Thread can never be cleaned. A dead thread has nothing to clean!
> 
> Right, but an idle thread, waiting for a task that will never come since 
> the only entry point for submitting tasks is not reachable (the pool), 
> may be cleaned...

cleaned? It can be interrupted if you know about it and find locate it. 
But it will not be eligible for cleaning ala Cleaner as it will always 
be strongly reachable.

David

> Regards, Peter
> 
>>
>> David
>> -----
>>
>>> For TPE, since Threads do not become unreferenced, the part of the 
>>> spec related to finalize
>>> being called by the finalizer thread is moot.
>>>
>>> $.02, Roger
>>>
>>> On 10/31/2017 5:24 AM, Peter Levart wrote:
>>>> Hi,
>>>>
>>>> Here are some of my thoughts...
>>>>
>>>> On 10/31/17 05:37, David Holmes wrote:
>>>>> Hi Roger,
>>>>>
>>>>> On 31/10/2017 12:43 AM, Roger Riggs wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> On 10/30/2017 3:31 AM, David Holmes wrote:
>>>>>>> Hi Andrej,
>>>>>>>
>>>>>>> On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>>> On 30. Oct 2017, at 01:40, David Holmes 
>>>>>>>>> <david.holmes at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Roger,
>>>>>>>>>
>>>>>>>>> On 30/10/2017 10:24 AM, Roger Riggs wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> With the deprecation of Object.finalize its time to look at 
>>>>>>>>>> its uses too see if they can be removed or mitigated.
>>>>>>>>>
>>>>>>>>> So the nice thing about finalize was that it followed a 
>>>>>>>>> nice/clean/simple OO model where a subclass could override, add 
>>>>>>>>> their own cleanup and then call super.finalize(). With 
>>>>>>>>> finalize() deprecated, and the new mechanism being Cleaners, 
>>>>>>>>> how do Cleaners support such usages?
>>>>>>>>
>>>>>>>> Instead of ThreadPoolExecutor.finalize you can override 
>>>>>>>> ThreadPoolExecutor.terminated.
>>>>>>>
>>>>>>> True. Though overriding shutdown() would be the semantic 
>>>>>>> equivalent of overriding finalize(). :)
>>>>>>>
>>>>>>> In the general case though finalize() might be invoking a final 
>>>>>>> method.
>>>>
>>>> Overriding shutdown() would only work when this method is explicitly 
>>>> invoked by user code. Using Cleaner API instead of finalization can 
>>>> not employ methods on object that is being tracked as that object is 
>>>> already gone when Cleaner invokes the cleanup function.
>>>>
>>>> Migrating TPE to Cleaner API might be particularly painful since the 
>>>> state needed to perform the shutdown is currently in the TPE 
>>>> instance fields and would have to be moved into the cleanup 
>>>> function. The easiest way to do that is to:
>>>>
>>>> - rename class ThreadPoolExecutor to package-private 
>>>> ThreadPoolExecutorImpl
>>>> - create new class ThreadPoolExecutor with same public API 
>>>> delegating the functionality to the embedded implementation
>>>> - registering Cleaner.Cleanable to perform shutdown of embedded 
>>>> executor when the public-facing executor becomes phantom reachable
>>>>
>>>> This would have an added benefit of automatically shut(ing)down() 
>>>> the pool when it is not reachable any more but still has idle threads.
>>>>
>>>>>>>
>>>>>>> Anyway I'm not sure we can actually do something to try to move 
>>>>>>> away from use of finalize() in TPE. finalize() is only deprecated 
>>>>>>> - it is still expected to work as it has always done. Existing 
>>>>>>> subclasses that override finalize() must continue to work until 
>>>>>>> some point where we say finalize() is not only deprecated but 
>>>>>>> obsoleted (it no longer does anything). So until then is there 
>>>>>>> actually any point in doing anything? Does having a Cleaner and a 
>>>>>>> finalize() method make sense? Does it aid in the transition?
>>>>>> As you observe, the alternatives directly using PhantomRefs or the 
>>>>>> Cleanup do not provide
>>>>>> as nice a model.? Unfortunately, that model has been recognized to 
>>>>>> have a number of
>>>>>> issues [1].? Finalization is a poor substitute for explicit 
>>>>>> shutdown, it is unpredictable and unreliable,
>>>>>> and not guaranteed to be executed.
>>>>>
>>>>> I'm not trying to support/defend finalize(). But it does support 
>>>>> the very common OO pattern of "override to specialize then call 
>>>>> super".
>>>>
>>>> I have been thinking about that and I see two approaches to enable 
>>>> subclasses to contribute cleanup code:
>>>>
>>>> - one simple approach is for each subclass to use it's own 
>>>> independent Cleaner/Cleanable. The benefit is that each subclass is 
>>>> independent of its super/sub classes, the drawback is that cleanup 
>>>> functions are called in arbitrary order, even in different threads. 
>>>> But for cleaning-up independent resources this should work.
>>>>
>>>> - the other approach is more involving as it requires the base class 
>>>> to establish an infrastructure for contributing cleanup code. For 
>>>> this purpose, the internal low-level Cleaner API is most appropriate 
>>>> thought it can be done with public API too. For example (with public 
>>>> API):
>>>>
>>>>
>>>> public class BaseClass implements AutoCloseable {
>>>>
>>>> ??? protected static class BaseResource implements Runnable {
>>>> ??????? @Override
>>>> ??????? public void run() {
>>>> ??????????? // cleanup
>>>> ??????? }
>>>> ??? }
>>>>
>>>> ??? protected final BaseResource resource = createResource();
>>>> ??? private final Cleaner.Cleanable cleanable = 
>>>> CleanerFactory.cleaner().register(this, resource);
>>>>
>>>> ??? protected BaseResource createResource() {
>>>> ??????? return new BaseResource();
>>>> ??? }
>>>>
>>>> ??? public BaseClass() {
>>>> ??????? // init BaseResource resource...
>>>> ??? }
>>>>
>>>> ??? @Override
>>>> ??? public final void close() {
>>>> ??????? cleanable.clean();
>>>> ??? }
>>>> }
>>>>
>>>>
>>>> public class DerivedClass extends BaseClass {
>>>>
>>>> ??? protected static class DerivedResource extends BaseResource {
>>>> ??????? @Override
>>>> ??????? public void run() {
>>>> ??????????? // before-super cleanup
>>>> ??????????? super.run();
>>>> ??????????? // after-super cleanup
>>>> ??????? }
>>>> ??? }
>>>>
>>>> ??? @Override
>>>> ??? protected DerivedResource createResource() {
>>>> ??????? return new DerivedResource();
>>>> ??? }
>>>>
>>>> ??? public DerivedClass() {
>>>> ??????? super();
>>>> ??????? DerivedResource resource = (DerivedResource) this.resource;
>>>> ??????? // init DerivedResource resource
>>>> ??? }
>>>> }
>>>>
>>>>
>>>> And alternative with private low-level API:
>>>>
>>>>
>>>> public class BaseClass implements AutoCloseable {
>>>>
>>>> ??? protected static class BaseResource extends 
>>>> PhantomCleanable<BaseClass> {
>>>>
>>>> ??????? protected BaseResource(BaseClass referent) {
>>>> ??????????? super(referent, CleanerFactory.cleaner());
>>>> ??????? }
>>>>
>>>> ??????? @Override
>>>> ??????? protected void performCleanup() {
>>>> ??????????? // cleanup
>>>> ??????? }
>>>> ??? }
>>>>
>>>> ??? protected final BaseResource resource = createResource();
>>>>
>>>> ??? protected BaseResource createResource() {
>>>> ??????? return new BaseResource(this);
>>>> ??? }
>>>>
>>>> ??? public BaseClass() {
>>>> ??????? // init BaseResource resource...
>>>> ??? }
>>>>
>>>> ??? @Override
>>>> ??? public final void close() {
>>>> ??????? resource.clean();
>>>> ??? }
>>>> }
>>>>
>>>>
>>>> public class DerivedClass extends BaseClass {
>>>>
>>>> ??? protected static class DerivedResource extends BaseResource {
>>>>
>>>> ??????? protected DerivedResource(DerivedClass referent) {
>>>> ??????????? super(referent);
>>>> ??????? }
>>>>
>>>> ??????? @Override
>>>> ??????? protected void performCleanup() {
>>>> ??????????? // before-super cleanup
>>>> ??????????? super.performCleanup();
>>>> ??????????? // after-super cleanup
>>>> ??????? }
>>>> ??? }
>>>>
>>>> ??? @Override
>>>> ??? protected DerivedResource createResource() {
>>>> ??????? return new DerivedResource(this);
>>>> ??? }
>>>>
>>>> ??? public DerivedClass() {
>>>> ??????? super();
>>>> ??????? DerivedResource resource = (DerivedResource) this.resource;
>>>> ??????? // init DerivedResource resource
>>>> ??? }
>>>> }
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>>
>>>>>> ThreadPoolExecutor has a responsibility to cleanup any native 
>>>>>> resources it has allocated (threads)
>>>>>> and it should be free to use whatever mechanism is appropriate. 
>>>>>> Currently, the spec for finalize
>>>>>> does not give it that freedom.
>>>>>
>>>>> I suppose in hindsight we (JSR-166 EG) could have described 
>>>>> automatic shutdown without mentioning the word "finalize", but that 
>>>>> ship has sailed. We did specify it and people can expect it to be 
>>>>> usable and they can expect it to work. While encouraging people to 
>>>>> move away from finalization is a good thing you have to give them a 
>>>>> workable replacement.
>>>>>
>>>>>> The initiative is to identify and remediate existing uses of 
>>>>>> finalization in the JDK.
>>>>>> The primary concern is about subclasses that reply on the current 
>>>>>> spec.
>>>>>> If I'm using grepcode correctly[2], it does not show any 
>>>>>> subclasses of ThreadPoolExecutor that
>>>>>> override finalize; so it may be a non-issue.
>>>>>
>>>>> Pardon my skepticism if I don't consider "grepcode" as a reasonable 
>>>>> indicator of whether there are subclasses of TPE that override 
>>>>> finalize. Only a small fraction of source code is in the open.
>>>>>
>>>>> And I have to agree with Martin that the current documentation for 
>>>>> finalize() in TPE is somewhat inappropriate. If you deprecate 
>>>>> something you're supposed to point the user to the preferred way of 
>>>>> doing something other than the deprecated method - but there is 
>>>>> none. finalize() in TPE should not have been deprecated until we 
>>>>> provided that alternative.
>>>>>
>>>>> I think the way forward here would be to:
>>>>>
>>>>> 1. Change TPE.finalize() to final to force any subclasses to 
>>>>> migrate to the new mechanism going forward.
>>>>>
>>>>> 2. Implement the new mechanism - presumably Cleaner - and document 
>>>>> how to achieve the effect of "override to specialize then call 
>>>>> super" (presumably by overriding shutdown() instead).
>>>>>
>>>>> then in a few releases we remove TPE.finalize() (at the same time 
>>>>> as we remove it from Object).
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>> Regards, Roger
>>>>>>
>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8165641
>>>>>>
>>>>>> [2] 
>>>>>> http://grepcode.com/search/usages?type=method&id=repository.grepcode.com%24java%24root at jdk%24openjdk at 8u40-b25@java%24util%24concurrent at ThreadPoolExecutor@finalize%28%29&k=d
>>>>>>
>>>>
>>>
> 

From peter.levart at gmail.com  Wed Nov  1 12:04:31 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 1 Nov 2017 13:04:31 +0100
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <59F90664.9050403@oracle.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
 <59F7735A.3000501@oracle.com>
 <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>
 <59F7B6A1.5040303@oracle.com>
 <16e98d55-35c0-a039-edf5-95240bed2510@gmail.com>
 <59F90664.9050403@oracle.com>
Message-ID: <5b2ec510-7420-142f-eb96-6d851bb049eb@gmail.com>

Hi Sherman,

On 11/01/17 00:25, Xueming Shen wrote:
> Hi Peter,
>
> After tried couple implementations it seems the most reasonable 
> approach is to
> use the coding pattern you suggested to move all pieces into ZSStream 
> Ref. Given
> we are already using the internal API CleanerFactory it is attractive 
> to go a little
> further to subclass PhantomCleanable directly (in which I would assume 
> we can
> save one extra object), but I think I'd better to follow the 
> "suggested" clean usage
> (to register a runnable into the cleaner) for now.
>
> ? 39 class ZStreamRef implements Runnable {
> ? 40
> ? 41???? private LongConsumer end;
> ? 42???? private volatile long address;
> ? 43???? private final Cleanable cleanable;
> ? 44
> ? 45???? ZStreamRef (Object owner, LongSupplier addr, LongConsumer end) {
> ? 46???????? this.cleanable = CleanerFactory.cleaner().register(owner, 
> this);
> ? 47???????? this.end = end;
> ? 48???????? this.address = addr.getAsLong();
> ? 49???? }
> ? 50
>
> Similar change has been made for the ZipFile cleaner to follow the 
> same coding
> pattern. The "cleaner" is now renamed from Releaser to CleanableResource.
>
> http://cr.openjdk.java.net/~sherman/8185582/webrev/
>
> Thanks,
> Sherman

This looks mostly fine. One minor nit is that ZStreamRef.address field 
does not have to be volatile. I checked all usages of 
ZStreamRef.address() and all of them invoke it while holding a lock on 
the ZStreamRef instance. The ZStreamRef.run() which modifies the address 
is also synchronized. The other minor nit is that the following ZipFile 
imports are not needed:

import java.nio.file.Path;
import java.util.Map;
import jdk.internal.misc.JavaIORandomAccessFileAccess;
import static java.util.zip.ZipConstants.*;

(at least my IDEA colors them unused)

Cleaner is modified in this webrev (just one empty line deleted) - 
better not touch this file in this changeset

Additional nits in ZipFile:

- in lines 355, 356 you pull out two res fields into locals, but then 
not use them consistently (lines 372, 389)
- line 403 has a TAB character (is this OK?) and shows incorrectly 
indented in my editor (should I set tab stops differently?)
- line 457 - while should actually be if ?
- in ensureOpen() the check for res.zsrc == null can never succeed 
(CleanableResource.zsrc is a final field. If CleanableResource 
constructor fails, there's no res object and there's no ZipFile object 
either as ZipFile constructor does not do anything for this to escape 
prematurely)
- why don't you let IOExceptions thrown from CleanableResource.run() 
propagate out of ZipFile.close() ?

I would also rename static method Source.close(Source) to 
Source.release(Source) so it would not clash with instance method 
Source.close() which makes it ambiguous when one wants to use 
Source::close method reference (both methods apply). I would also make 
static methods Source.get() and Source.release(Source) package-private 
(currently one is public and the other is private, which needs compiler 
bridges to be invoked) and both are in a private nested class.

Inflater/Deflater/ZipFile now follow the coding pattern as suggested. 
But ZipFileInflaterInputStream still does not. It's not critical since 
failing to register cleanup which releases the inflater back into cache 
would simply mean that Inflater employs its own cleanup and ends itself.

And now another thing I would like to discuss. Why an initiative for 
using Cleaner instead of finalization()? Among drawbacks finalization 
has one of the more troubling is that the tracked referent survives the 
GC cycle that initiates its finalization reference processing pipeline, 
so the GC may reclaim the object (and referenced objects) only after the 
finalize() has finished in yet another GC round. Cleaner API separates 
the tracked object from the cleanup function and state needed to perform 
it into distinct instances. The tracked object can be reclaimed and the 
cleanup reference processing pipeline initiated in the same GC cycle. 
More heap may be reclaimed earlier.

Unless we are careful and create a cleaning function for one tracked 
object which captures (directly or indirectly) another object which 
registers its own cleaning function but we don't deal with explicit 
cleaning of the 2nd object in the 1st cleaning function.

Take for example the ZipFileInflaterInputStream's cleaning function. It 
captures the ZipFile in order to invoke ZipFile.releaseInflater instance 
method. What this means is that ZipFile will be kept reachable until all 
ZipFileInflaterInputStream's cleaning functions have fired. So we are 
back to the finalization drawback which needs at least 2 GC cycles to 
collect and clean-up what might be done in one go.

I suggest moving the getInflater() and releaseInflater() from ZipFile 
into the CleanableResource so that ZipFileInflaterInputStream's cleaning 
function captures just the CleanableResource and not the ZipFile. 
ZipFile therefore may become eligible for cleanup as soon as all opened 
input streams become eligible (but their cleaning functions need not 
have fired yet). CleanableResource.run() (the ZipFile cleaning function) 
and CleanableResource.releaseInflater() (the 
ZipFileInflaterInputStream's cleaning function) may therefore be invoked 
in arbitrary order (maybe even concurrently if one of them is explicit 
cleanup and the other is automatic), so code must be prepared for that.

I have tried to capture all above in a modified webrev (taking your last 
webrev as a base):

http://cr.openjdk.java.net/~plevart/jdk10-dev/8185582_ZIP.cleaner/webrev.03/


Regards, Peter


From peter.levart at gmail.com  Wed Nov  1 12:20:51 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 1 Nov 2017 13:20:51 +0100
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
 <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
Message-ID: <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>



On 11/01/17 10:04, David Holmes wrote:
> On 1/11/2017 6:16 PM, Peter Levart wrote:
>> On 11/01/17 02:49, David Holmes wrote:
>>> Hi Roger,
>>>
>>> On 31/10/2017 11:58 PM, Roger Riggs wrote:
>>>> Hi Peter,
>>>>
>>>> Only native resources that do not map to the heap allocation/gc 
>>>> cycle need any kind
>>>> of cleanup.? I would work toward a model that encapsulates the 
>>>> reference to a native resource
>>>> with a corresponding allocation/release mechanism as you've 
>>>> described here and in the
>>>> thread on zip.
>>>>
>>>> For cleanup purposes, the independence of each resource may improve 
>>>> robustness
>>>> by avoiding dependencies and opportunities for entanglements and 
>>>> bugs due to exceptions
>>>> and other failures.
>>>>
>>>> In the case of TPE, the native resources are Threads, which keep 
>>>> running even if they are
>>>> unreferenced and are kept referenced via ThreadGroups.
>>>> I don't know the Executor code well enough to do more than 
>>>> speculate, but would suggest
>>>> that a cleaner (or similar) should be registered for each thread .
>>>
>>> Threads are not native resources to be managed by Cleaners! A live 
>>> Thread can never be cleaned. A dead thread has nothing to clean!
>>
>> Right, but an idle thread, waiting for a task that will never come 
>> since the only entry point for submitting tasks is not reachable (the 
>> pool), may be cleaned...
>
> cleaned? It can be interrupted if you know about it and find locate 
> it. But it will not be eligible for cleaning ala Cleaner as it will 
> always be strongly reachable.

Ah I see what you meant before. Yes, tracking Thread object with a 
Cleaner does not have any sense. But tracking thread pool object with a 
Cleaner and cleaning (stopping) threads as a result makes sense...

Regards, Peter

>
> David
>
>> Regards, Peter
>>
>>>
>>> David
>>> -----
>>>
>>>> For TPE, since Threads do not become unreferenced, the part of the 
>>>> spec related to finalize
>>>> being called by the finalizer thread is moot.
>>>>
>>>> $.02, Roger
>>>>
>>>> On 10/31/2017 5:24 AM, Peter Levart wrote:
>>>>> Hi,
>>>>>
>>>>> Here are some of my thoughts...
>>>>>
>>>>> On 10/31/17 05:37, David Holmes wrote:
>>>>>> Hi Roger,
>>>>>>
>>>>>> On 31/10/2017 12:43 AM, Roger Riggs wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> On 10/30/2017 3:31 AM, David Holmes wrote:
>>>>>>>> Hi Andrej,
>>>>>>>>
>>>>>>>> On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>>> On 30. Oct 2017, at 01:40, David Holmes 
>>>>>>>>>> <david.holmes at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Roger,
>>>>>>>>>>
>>>>>>>>>> On 30/10/2017 10:24 AM, Roger Riggs wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>> With the deprecation of Object.finalize its time to look at 
>>>>>>>>>>> its uses too see if they can be removed or mitigated.
>>>>>>>>>>
>>>>>>>>>> So the nice thing about finalize was that it followed a 
>>>>>>>>>> nice/clean/simple OO model where a subclass could override, 
>>>>>>>>>> add their own cleanup and then call super.finalize(). With 
>>>>>>>>>> finalize() deprecated, and the new mechanism being Cleaners, 
>>>>>>>>>> how do Cleaners support such usages?
>>>>>>>>>
>>>>>>>>> Instead of ThreadPoolExecutor.finalize you can override 
>>>>>>>>> ThreadPoolExecutor.terminated.
>>>>>>>>
>>>>>>>> True. Though overriding shutdown() would be the semantic 
>>>>>>>> equivalent of overriding finalize(). :)
>>>>>>>>
>>>>>>>> In the general case though finalize() might be invoking a final 
>>>>>>>> method.
>>>>>
>>>>> Overriding shutdown() would only work when this method is 
>>>>> explicitly invoked by user code. Using Cleaner API instead of 
>>>>> finalization can not employ methods on object that is being 
>>>>> tracked as that object is already gone when Cleaner invokes the 
>>>>> cleanup function.
>>>>>
>>>>> Migrating TPE to Cleaner API might be particularly painful since 
>>>>> the state needed to perform the shutdown is currently in the TPE 
>>>>> instance fields and would have to be moved into the cleanup 
>>>>> function. The easiest way to do that is to:
>>>>>
>>>>> - rename class ThreadPoolExecutor to package-private 
>>>>> ThreadPoolExecutorImpl
>>>>> - create new class ThreadPoolExecutor with same public API 
>>>>> delegating the functionality to the embedded implementation
>>>>> - registering Cleaner.Cleanable to perform shutdown of embedded 
>>>>> executor when the public-facing executor becomes phantom reachable
>>>>>
>>>>> This would have an added benefit of automatically shut(ing)down() 
>>>>> the pool when it is not reachable any more but still has idle 
>>>>> threads.
>>>>>
>>>>>>>>
>>>>>>>> Anyway I'm not sure we can actually do something to try to move 
>>>>>>>> away from use of finalize() in TPE. finalize() is only 
>>>>>>>> deprecated - it is still expected to work as it has always 
>>>>>>>> done. Existing subclasses that override finalize() must 
>>>>>>>> continue to work until some point where we say finalize() is 
>>>>>>>> not only deprecated but obsoleted (it no longer does anything). 
>>>>>>>> So until then is there actually any point in doing anything? 
>>>>>>>> Does having a Cleaner and a finalize() method make sense? Does 
>>>>>>>> it aid in the transition?
>>>>>>> As you observe, the alternatives directly using PhantomRefs or 
>>>>>>> the Cleanup do not provide
>>>>>>> as nice a model.? Unfortunately, that model has been recognized 
>>>>>>> to have a number of
>>>>>>> issues [1].? Finalization is a poor substitute for explicit 
>>>>>>> shutdown, it is unpredictable and unreliable,
>>>>>>> and not guaranteed to be executed.
>>>>>>
>>>>>> I'm not trying to support/defend finalize(). But it does support 
>>>>>> the very common OO pattern of "override to specialize then call 
>>>>>> super".
>>>>>
>>>>> I have been thinking about that and I see two approaches to enable 
>>>>> subclasses to contribute cleanup code:
>>>>>
>>>>> - one simple approach is for each subclass to use it's own 
>>>>> independent Cleaner/Cleanable. The benefit is that each subclass 
>>>>> is independent of its super/sub classes, the drawback is that 
>>>>> cleanup functions are called in arbitrary order, even in different 
>>>>> threads. But for cleaning-up independent resources this should work.
>>>>>
>>>>> - the other approach is more involving as it requires the base 
>>>>> class to establish an infrastructure for contributing cleanup 
>>>>> code. For this purpose, the internal low-level Cleaner API is most 
>>>>> appropriate thought it can be done with public API too. For 
>>>>> example (with public API):
>>>>>
>>>>>
>>>>> public class BaseClass implements AutoCloseable {
>>>>>
>>>>> ??? protected static class BaseResource implements Runnable {
>>>>> ??????? @Override
>>>>> ??????? public void run() {
>>>>> ??????????? // cleanup
>>>>> ??????? }
>>>>> ??? }
>>>>>
>>>>> ??? protected final BaseResource resource = createResource();
>>>>> ??? private final Cleaner.Cleanable cleanable = 
>>>>> CleanerFactory.cleaner().register(this, resource);
>>>>>
>>>>> ??? protected BaseResource createResource() {
>>>>> ??????? return new BaseResource();
>>>>> ??? }
>>>>>
>>>>> ??? public BaseClass() {
>>>>> ??????? // init BaseResource resource...
>>>>> ??? }
>>>>>
>>>>> ??? @Override
>>>>> ??? public final void close() {
>>>>> ??????? cleanable.clean();
>>>>> ??? }
>>>>> }
>>>>>
>>>>>
>>>>> public class DerivedClass extends BaseClass {
>>>>>
>>>>> ??? protected static class DerivedResource extends BaseResource {
>>>>> ??????? @Override
>>>>> ??????? public void run() {
>>>>> ??????????? // before-super cleanup
>>>>> ??????????? super.run();
>>>>> ??????????? // after-super cleanup
>>>>> ??????? }
>>>>> ??? }
>>>>>
>>>>> ??? @Override
>>>>> ??? protected DerivedResource createResource() {
>>>>> ??????? return new DerivedResource();
>>>>> ??? }
>>>>>
>>>>> ??? public DerivedClass() {
>>>>> ??????? super();
>>>>> ??????? DerivedResource resource = (DerivedResource) this.resource;
>>>>> ??????? // init DerivedResource resource
>>>>> ??? }
>>>>> }
>>>>>
>>>>>
>>>>> And alternative with private low-level API:
>>>>>
>>>>>
>>>>> public class BaseClass implements AutoCloseable {
>>>>>
>>>>> ??? protected static class BaseResource extends 
>>>>> PhantomCleanable<BaseClass> {
>>>>>
>>>>> ??????? protected BaseResource(BaseClass referent) {
>>>>> ??????????? super(referent, CleanerFactory.cleaner());
>>>>> ??????? }
>>>>>
>>>>> ??????? @Override
>>>>> ??????? protected void performCleanup() {
>>>>> ??????????? // cleanup
>>>>> ??????? }
>>>>> ??? }
>>>>>
>>>>> ??? protected final BaseResource resource = createResource();
>>>>>
>>>>> ??? protected BaseResource createResource() {
>>>>> ??????? return new BaseResource(this);
>>>>> ??? }
>>>>>
>>>>> ??? public BaseClass() {
>>>>> ??????? // init BaseResource resource...
>>>>> ??? }
>>>>>
>>>>> ??? @Override
>>>>> ??? public final void close() {
>>>>> ??????? resource.clean();
>>>>> ??? }
>>>>> }
>>>>>
>>>>>
>>>>> public class DerivedClass extends BaseClass {
>>>>>
>>>>> ??? protected static class DerivedResource extends BaseResource {
>>>>>
>>>>> ??????? protected DerivedResource(DerivedClass referent) {
>>>>> ??????????? super(referent);
>>>>> ??????? }
>>>>>
>>>>> ??????? @Override
>>>>> ??????? protected void performCleanup() {
>>>>> ??????????? // before-super cleanup
>>>>> ??????????? super.performCleanup();
>>>>> ??????????? // after-super cleanup
>>>>> ??????? }
>>>>> ??? }
>>>>>
>>>>> ??? @Override
>>>>> ??? protected DerivedResource createResource() {
>>>>> ??????? return new DerivedResource(this);
>>>>> ??? }
>>>>>
>>>>> ??? public DerivedClass() {
>>>>> ??????? super();
>>>>> ??????? DerivedResource resource = (DerivedResource) this.resource;
>>>>> ??????? // init DerivedResource resource
>>>>> ??? }
>>>>> }
>>>>>
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>>>
>>>>>>> ThreadPoolExecutor has a responsibility to cleanup any native 
>>>>>>> resources it has allocated (threads)
>>>>>>> and it should be free to use whatever mechanism is appropriate. 
>>>>>>> Currently, the spec for finalize
>>>>>>> does not give it that freedom.
>>>>>>
>>>>>> I suppose in hindsight we (JSR-166 EG) could have described 
>>>>>> automatic shutdown without mentioning the word "finalize", but 
>>>>>> that ship has sailed. We did specify it and people can expect it 
>>>>>> to be usable and they can expect it to work. While encouraging 
>>>>>> people to move away from finalization is a good thing you have to 
>>>>>> give them a workable replacement.
>>>>>>
>>>>>>> The initiative is to identify and remediate existing uses of 
>>>>>>> finalization in the JDK.
>>>>>>> The primary concern is about subclasses that reply on the 
>>>>>>> current spec.
>>>>>>> If I'm using grepcode correctly[2], it does not show any 
>>>>>>> subclasses of ThreadPoolExecutor that
>>>>>>> override finalize; so it may be a non-issue.
>>>>>>
>>>>>> Pardon my skepticism if I don't consider "grepcode" as a 
>>>>>> reasonable indicator of whether there are subclasses of TPE that 
>>>>>> override finalize. Only a small fraction of source code is in the 
>>>>>> open.
>>>>>>
>>>>>> And I have to agree with Martin that the current documentation 
>>>>>> for finalize() in TPE is somewhat inappropriate. If you deprecate 
>>>>>> something you're supposed to point the user to the preferred way 
>>>>>> of doing something other than the deprecated method - but there 
>>>>>> is none. finalize() in TPE should not have been deprecated until 
>>>>>> we provided that alternative.
>>>>>>
>>>>>> I think the way forward here would be to:
>>>>>>
>>>>>> 1. Change TPE.finalize() to final to force any subclasses to 
>>>>>> migrate to the new mechanism going forward.
>>>>>>
>>>>>> 2. Implement the new mechanism - presumably Cleaner - and 
>>>>>> document how to achieve the effect of "override to specialize 
>>>>>> then call super" (presumably by overriding shutdown() instead).
>>>>>>
>>>>>> then in a few releases we remove TPE.finalize() (at the same time 
>>>>>> as we remove it from Object).
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>>> Regards, Roger
>>>>>>>
>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8165641
>>>>>>>
>>>>>>> [2] 
>>>>>>> http://grepcode.com/search/usages?type=method&id=repository.grepcode.com%24java%24root at jdk%24openjdk at 8u40-b25@java%24util%24concurrent at ThreadPoolExecutor@finalize%28%29&k=d
>>>>>>>
>>>>>
>>>>
>>


From david.holmes at oracle.com  Wed Nov  1 12:34:36 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 1 Nov 2017 22:34:36 +1000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
 <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
 <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>
Message-ID: <e83dd002-89a5-1e03-9593-dc09a1db3d66@oracle.com>

On 1/11/2017 10:20 PM, Peter Levart wrote:
> On 11/01/17 10:04, David Holmes wrote:
>> On 1/11/2017 6:16 PM, Peter Levart wrote:
>>> On 11/01/17 02:49, David Holmes wrote:
>>>> Hi Roger,
>>>>
>>>> On 31/10/2017 11:58 PM, Roger Riggs wrote:
>>>>> Hi Peter,
>>>>>
>>>>> Only native resources that do not map to the heap allocation/gc 
>>>>> cycle need any kind
>>>>> of cleanup.? I would work toward a model that encapsulates the 
>>>>> reference to a native resource
>>>>> with a corresponding allocation/release mechanism as you've 
>>>>> described here and in the
>>>>> thread on zip.
>>>>>
>>>>> For cleanup purposes, the independence of each resource may improve 
>>>>> robustness
>>>>> by avoiding dependencies and opportunities for entanglements and 
>>>>> bugs due to exceptions
>>>>> and other failures.
>>>>>
>>>>> In the case of TPE, the native resources are Threads, which keep 
>>>>> running even if they are
>>>>> unreferenced and are kept referenced via ThreadGroups.
>>>>> I don't know the Executor code well enough to do more than 
>>>>> speculate, but would suggest
>>>>> that a cleaner (or similar) should be registered for each thread .
>>>>
>>>> Threads are not native resources to be managed by Cleaners! A live 
>>>> Thread can never be cleaned. A dead thread has nothing to clean!
>>>
>>> Right, but an idle thread, waiting for a task that will never come 
>>> since the only entry point for submitting tasks is not reachable (the 
>>> pool), may be cleaned...
>>
>> cleaned? It can be interrupted if you know about it and find locate 
>> it. But it will not be eligible for cleaning ala Cleaner as it will 
>> always be strongly reachable.
> 
> Ah I see what you meant before. Yes, tracking Thread object with a 
> Cleaner does not have any sense. But tracking thread pool object with a 
> Cleaner and cleaning (stopping) threads as a result makes sense...

No, because live Threads will keep the thread pool strongly reachable.

If you manage to structure things such that the Threads don't keep the 
pool strongly reachable then you risk having the pool cleaned while 
still actively in use.

David

David

> Regards, Peter
> 
>>
>> David
>>
>>> Regards, Peter
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>>> For TPE, since Threads do not become unreferenced, the part of the 
>>>>> spec related to finalize
>>>>> being called by the finalizer thread is moot.
>>>>>
>>>>> $.02, Roger
>>>>>
>>>>> On 10/31/2017 5:24 AM, Peter Levart wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Here are some of my thoughts...
>>>>>>
>>>>>> On 10/31/17 05:37, David Holmes wrote:
>>>>>>> Hi Roger,
>>>>>>>
>>>>>>> On 31/10/2017 12:43 AM, Roger Riggs wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> On 10/30/2017 3:31 AM, David Holmes wrote:
>>>>>>>>> Hi Andrej,
>>>>>>>>>
>>>>>>>>> On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>>> On 30. Oct 2017, at 01:40, David Holmes 
>>>>>>>>>>> <david.holmes at oracle.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Roger,
>>>>>>>>>>>
>>>>>>>>>>> On 30/10/2017 10:24 AM, Roger Riggs wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> With the deprecation of Object.finalize its time to look at 
>>>>>>>>>>>> its uses too see if they can be removed or mitigated.
>>>>>>>>>>>
>>>>>>>>>>> So the nice thing about finalize was that it followed a 
>>>>>>>>>>> nice/clean/simple OO model where a subclass could override, 
>>>>>>>>>>> add their own cleanup and then call super.finalize(). With 
>>>>>>>>>>> finalize() deprecated, and the new mechanism being Cleaners, 
>>>>>>>>>>> how do Cleaners support such usages?
>>>>>>>>>>
>>>>>>>>>> Instead of ThreadPoolExecutor.finalize you can override 
>>>>>>>>>> ThreadPoolExecutor.terminated.
>>>>>>>>>
>>>>>>>>> True. Though overriding shutdown() would be the semantic 
>>>>>>>>> equivalent of overriding finalize(). :)
>>>>>>>>>
>>>>>>>>> In the general case though finalize() might be invoking a final 
>>>>>>>>> method.
>>>>>>
>>>>>> Overriding shutdown() would only work when this method is 
>>>>>> explicitly invoked by user code. Using Cleaner API instead of 
>>>>>> finalization can not employ methods on object that is being 
>>>>>> tracked as that object is already gone when Cleaner invokes the 
>>>>>> cleanup function.
>>>>>>
>>>>>> Migrating TPE to Cleaner API might be particularly painful since 
>>>>>> the state needed to perform the shutdown is currently in the TPE 
>>>>>> instance fields and would have to be moved into the cleanup 
>>>>>> function. The easiest way to do that is to:
>>>>>>
>>>>>> - rename class ThreadPoolExecutor to package-private 
>>>>>> ThreadPoolExecutorImpl
>>>>>> - create new class ThreadPoolExecutor with same public API 
>>>>>> delegating the functionality to the embedded implementation
>>>>>> - registering Cleaner.Cleanable to perform shutdown of embedded 
>>>>>> executor when the public-facing executor becomes phantom reachable
>>>>>>
>>>>>> This would have an added benefit of automatically shut(ing)down() 
>>>>>> the pool when it is not reachable any more but still has idle 
>>>>>> threads.
>>>>>>
>>>>>>>>>
>>>>>>>>> Anyway I'm not sure we can actually do something to try to move 
>>>>>>>>> away from use of finalize() in TPE. finalize() is only 
>>>>>>>>> deprecated - it is still expected to work as it has always 
>>>>>>>>> done. Existing subclasses that override finalize() must 
>>>>>>>>> continue to work until some point where we say finalize() is 
>>>>>>>>> not only deprecated but obsoleted (it no longer does anything). 
>>>>>>>>> So until then is there actually any point in doing anything? 
>>>>>>>>> Does having a Cleaner and a finalize() method make sense? Does 
>>>>>>>>> it aid in the transition?
>>>>>>>> As you observe, the alternatives directly using PhantomRefs or 
>>>>>>>> the Cleanup do not provide
>>>>>>>> as nice a model.? Unfortunately, that model has been recognized 
>>>>>>>> to have a number of
>>>>>>>> issues [1].? Finalization is a poor substitute for explicit 
>>>>>>>> shutdown, it is unpredictable and unreliable,
>>>>>>>> and not guaranteed to be executed.
>>>>>>>
>>>>>>> I'm not trying to support/defend finalize(). But it does support 
>>>>>>> the very common OO pattern of "override to specialize then call 
>>>>>>> super".
>>>>>>
>>>>>> I have been thinking about that and I see two approaches to enable 
>>>>>> subclasses to contribute cleanup code:
>>>>>>
>>>>>> - one simple approach is for each subclass to use it's own 
>>>>>> independent Cleaner/Cleanable. The benefit is that each subclass 
>>>>>> is independent of its super/sub classes, the drawback is that 
>>>>>> cleanup functions are called in arbitrary order, even in different 
>>>>>> threads. But for cleaning-up independent resources this should work.
>>>>>>
>>>>>> - the other approach is more involving as it requires the base 
>>>>>> class to establish an infrastructure for contributing cleanup 
>>>>>> code. For this purpose, the internal low-level Cleaner API is most 
>>>>>> appropriate thought it can be done with public API too. For 
>>>>>> example (with public API):
>>>>>>
>>>>>>
>>>>>> public class BaseClass implements AutoCloseable {
>>>>>>
>>>>>> ??? protected static class BaseResource implements Runnable {
>>>>>> ??????? @Override
>>>>>> ??????? public void run() {
>>>>>> ??????????? // cleanup
>>>>>> ??????? }
>>>>>> ??? }
>>>>>>
>>>>>> ??? protected final BaseResource resource = createResource();
>>>>>> ??? private final Cleaner.Cleanable cleanable = 
>>>>>> CleanerFactory.cleaner().register(this, resource);
>>>>>>
>>>>>> ??? protected BaseResource createResource() {
>>>>>> ??????? return new BaseResource();
>>>>>> ??? }
>>>>>>
>>>>>> ??? public BaseClass() {
>>>>>> ??????? // init BaseResource resource...
>>>>>> ??? }
>>>>>>
>>>>>> ??? @Override
>>>>>> ??? public final void close() {
>>>>>> ??????? cleanable.clean();
>>>>>> ??? }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> public class DerivedClass extends BaseClass {
>>>>>>
>>>>>> ??? protected static class DerivedResource extends BaseResource {
>>>>>> ??????? @Override
>>>>>> ??????? public void run() {
>>>>>> ??????????? // before-super cleanup
>>>>>> ??????????? super.run();
>>>>>> ??????????? // after-super cleanup
>>>>>> ??????? }
>>>>>> ??? }
>>>>>>
>>>>>> ??? @Override
>>>>>> ??? protected DerivedResource createResource() {
>>>>>> ??????? return new DerivedResource();
>>>>>> ??? }
>>>>>>
>>>>>> ??? public DerivedClass() {
>>>>>> ??????? super();
>>>>>> ??????? DerivedResource resource = (DerivedResource) this.resource;
>>>>>> ??????? // init DerivedResource resource
>>>>>> ??? }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> And alternative with private low-level API:
>>>>>>
>>>>>>
>>>>>> public class BaseClass implements AutoCloseable {
>>>>>>
>>>>>> ??? protected static class BaseResource extends 
>>>>>> PhantomCleanable<BaseClass> {
>>>>>>
>>>>>> ??????? protected BaseResource(BaseClass referent) {
>>>>>> ??????????? super(referent, CleanerFactory.cleaner());
>>>>>> ??????? }
>>>>>>
>>>>>> ??????? @Override
>>>>>> ??????? protected void performCleanup() {
>>>>>> ??????????? // cleanup
>>>>>> ??????? }
>>>>>> ??? }
>>>>>>
>>>>>> ??? protected final BaseResource resource = createResource();
>>>>>>
>>>>>> ??? protected BaseResource createResource() {
>>>>>> ??????? return new BaseResource(this);
>>>>>> ??? }
>>>>>>
>>>>>> ??? public BaseClass() {
>>>>>> ??????? // init BaseResource resource...
>>>>>> ??? }
>>>>>>
>>>>>> ??? @Override
>>>>>> ??? public final void close() {
>>>>>> ??????? resource.clean();
>>>>>> ??? }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> public class DerivedClass extends BaseClass {
>>>>>>
>>>>>> ??? protected static class DerivedResource extends BaseResource {
>>>>>>
>>>>>> ??????? protected DerivedResource(DerivedClass referent) {
>>>>>> ??????????? super(referent);
>>>>>> ??????? }
>>>>>>
>>>>>> ??????? @Override
>>>>>> ??????? protected void performCleanup() {
>>>>>> ??????????? // before-super cleanup
>>>>>> ??????????? super.performCleanup();
>>>>>> ??????????? // after-super cleanup
>>>>>> ??????? }
>>>>>> ??? }
>>>>>>
>>>>>> ??? @Override
>>>>>> ??? protected DerivedResource createResource() {
>>>>>> ??????? return new DerivedResource(this);
>>>>>> ??? }
>>>>>>
>>>>>> ??? public DerivedClass() {
>>>>>> ??????? super();
>>>>>> ??????? DerivedResource resource = (DerivedResource) this.resource;
>>>>>> ??????? // init DerivedResource resource
>>>>>> ??? }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> Regards, Peter
>>>>>>
>>>>>>>
>>>>>>>> ThreadPoolExecutor has a responsibility to cleanup any native 
>>>>>>>> resources it has allocated (threads)
>>>>>>>> and it should be free to use whatever mechanism is appropriate. 
>>>>>>>> Currently, the spec for finalize
>>>>>>>> does not give it that freedom.
>>>>>>>
>>>>>>> I suppose in hindsight we (JSR-166 EG) could have described 
>>>>>>> automatic shutdown without mentioning the word "finalize", but 
>>>>>>> that ship has sailed. We did specify it and people can expect it 
>>>>>>> to be usable and they can expect it to work. While encouraging 
>>>>>>> people to move away from finalization is a good thing you have to 
>>>>>>> give them a workable replacement.
>>>>>>>
>>>>>>>> The initiative is to identify and remediate existing uses of 
>>>>>>>> finalization in the JDK.
>>>>>>>> The primary concern is about subclasses that reply on the 
>>>>>>>> current spec.
>>>>>>>> If I'm using grepcode correctly[2], it does not show any 
>>>>>>>> subclasses of ThreadPoolExecutor that
>>>>>>>> override finalize; so it may be a non-issue.
>>>>>>>
>>>>>>> Pardon my skepticism if I don't consider "grepcode" as a 
>>>>>>> reasonable indicator of whether there are subclasses of TPE that 
>>>>>>> override finalize. Only a small fraction of source code is in the 
>>>>>>> open.
>>>>>>>
>>>>>>> And I have to agree with Martin that the current documentation 
>>>>>>> for finalize() in TPE is somewhat inappropriate. If you deprecate 
>>>>>>> something you're supposed to point the user to the preferred way 
>>>>>>> of doing something other than the deprecated method - but there 
>>>>>>> is none. finalize() in TPE should not have been deprecated until 
>>>>>>> we provided that alternative.
>>>>>>>
>>>>>>> I think the way forward here would be to:
>>>>>>>
>>>>>>> 1. Change TPE.finalize() to final to force any subclasses to 
>>>>>>> migrate to the new mechanism going forward.
>>>>>>>
>>>>>>> 2. Implement the new mechanism - presumably Cleaner - and 
>>>>>>> document how to achieve the effect of "override to specialize 
>>>>>>> then call super" (presumably by overriding shutdown() instead).
>>>>>>>
>>>>>>> then in a few releases we remove TPE.finalize() (at the same time 
>>>>>>> as we remove it from Object).
>>>>>>>
>>>>>>> Cheers,
>>>>>>> David
>>>>>>>
>>>>>>>> Regards, Roger
>>>>>>>>
>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8165641
>>>>>>>>
>>>>>>>> [2] 
>>>>>>>> http://grepcode.com/search/usages?type=method&id=repository.grepcode.com%24java%24root at jdk%24openjdk at 8u40-b25@java%24util%24concurrent at ThreadPoolExecutor@finalize%28%29&k=d
>>>>>>>>
>>>>>>
>>>>>
>>>
> 

From Alan.Bateman at oracle.com  Wed Nov  1 12:42:59 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 1 Nov 2017 12:42:59 +0000
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
Message-ID: <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>

On 16/12/2014 22:54, Pavel Rappo wrote:
> Hi Patrick, nice to hear from you again! I agree we should consider adding this
> method. Unfortunately, from the spec point of view I suppose this one will
> require a lot more chewing. For instance there's nothing that can be closed
> either in Readable or Appendable (in general case), since neither of them is
> java.io.Closeable or even java.lang.AutoCloseable. In my opinion, all mentions
> of 'close' operations should go.
I agree that transferTo(Writer) is a no-brainer. When changed to be more 
general and Appendable then it might be simplest to just deal with the 
AutoCloseable case in the javadoc.

-Alan

From Roger.Riggs at Oracle.com  Wed Nov  1 14:31:46 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 1 Nov 2017 10:31:46 -0400
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <9904feb8-7cab-44eb-fcad-e6d5988982e5@oracle.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
 <59F7735A.3000501@oracle.com>
 <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>
 <0ec13ca6-d542-ba81-c804-bfd524564f6a@gmail.com>
 <64f46e40-b641-b280-eed3-99606e9ad1d5@oracle.com>
 <55ff486d-2b09-6463-734e-c769603cdae7@gmail.com>
 <9904feb8-7cab-44eb-fcad-e6d5988982e5@oracle.com>
Message-ID: <a1ad85e4-fd40-a409-1e88-79380b0f8423@Oracle.com>

Hi Peter,

The Supplier/Consumer allocator/deallocator version is useful and 
interesting encapsulation.

We should be able to do better than exposing raw native pointers for 
other resources.
They should have better more complete encapsulation including their cleanup.
For example, the recent work on FileDescriptor.
The current state with direct memory pointers floating freely is quite 
sensitive.

I'm hopeful that Panama will support that direction.

In CleanerImp:322, is there a JMM issue with the escape of the reference 
to PhantomCleanableResource
to the cleaner thread before the constructor has finished and published 
the instance?
True, the constructor holds this until the very end of the method but 
what makes sure
the new valuewritten to the resource field will be read by the cleanable 
thread?

Thanks, Roger


On 10/31/2017 11:17 PM, mandy chung wrote:
>
>
> On 10/31/17 4:07 PM, Peter Levart wrote:
>> Hi Mandy, Sherman, Roger,
>>
>> On 10/31/17 00:25, mandy chung wrote:
>>>
>> I played a little with an idea of how such additional Cleaner API 
>> might look like. Here's what I came up with, together with how this 
>> would apply to ZipFile/Inflater/Deflater:
>>
>> http://cr.openjdk.java.net/~plevart/jdk10-dev/8185582_ZIP.cleaner/webrev.02/
>>
>> So, what do you think of this new Cleaner API extension?
>
> This serves as a good starting point.? I converted the 
> ClassLoader.NativeLibrary to use it:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev-cleanable/
>
> Looks reasonably well and probably some other improvement I could do.? 
> I use createResource rather than createLongResource which is 
> specialized for an address. We should check out panama how this plays out.
>
> I think it would be useful to iterate on several more use cases and it 
> would be better to separate this RFE from JDK-8185582 so that we can 
> explore with its own pace.
>
> Mandy


From patrick at reini.net  Wed Nov  1 14:57:30 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 1 Nov 2017 15:57:30 +0100
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
Message-ID: <484ae491-9988-b977-1ddc-aded096b3784@reini.net>

I tried to put that in my latest proposal:

/**
?* Reads all characters from this readable and writes the characters to
?* the given appendable in the order that they are read. On return, this
?* readable will be at end its data.
?* <p>
?* This method may block indefinitely reading from the readable, or
?* writing to the appendable. The behavior for the case where the readable
?* and/or appendable is <i>asynchronously closed</i>, or the thread
?* interrupted during the transfer, is highly readable and appendable
?* specific, and therefore not specified.
?* <p>
?* If an I/O error occurs reading from the readable or writing to the
?* appendable, then it may do so after some characters have been read or
?* written. Consequently the readable may not be at end of its data and
?* one, or both participants may be in an inconsistent state. That in mind
?* all additional measures required by one or both participants in order to
?* eventually free their internal resources have to be taken by the caller
?* of this method.
?*
?* @param? out the appendable, non-null
?* @return the number of characters transferred
?* @throws IOException if an I/O error occurs when reading or writing
?* @throws NullPointerException if {@code out} is {@code null}
?*
?* @since 18.3
?*/
default long transferTo(Appendable out) throws IOException {
....
}

-Patrick

Am 01.11.2017 um 13:42 schrieb Alan Bateman:
> On 16/12/2014 22:54, Pavel Rappo wrote:
>> Hi Patrick, nice to hear from you again! I agree we should consider
>> adding this
>> method. Unfortunately, from the spec point of view I suppose this one
>> will
>> require a lot more chewing. For instance there's nothing that can be
>> closed
>> either in Readable or Appendable (in general case), since neither of
>> them is
>> java.io.Closeable or even java.lang.AutoCloseable. In my opinion, all
>> mentions
>> of 'close' operations should go.
> I agree that transferTo(Writer) is a no-brainer. When changed to be
> more general and Appendable then it might be simplest to just deal
> with the AutoCloseable case in the javadoc.
>
> -Alan




From dmitry.samersoff at bell-sw.com  Wed Nov  1 07:44:36 2017
From: dmitry.samersoff at bell-sw.com (Dmitry Samersoff)
Date: Wed, 1 Nov 2017 10:44:36 +0300
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <58726425-BA16-482B-A02E-3B0613CD5010@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <b8c8d33a-2782-cfba-64df-fc32151ac117@bell-sw.com>
 <93431280-9CBF-4722-961D-F2D2D0F83B4E@oracle.com>
 <EBC28788-F65A-42F8-A6AD-7B670FDB74C5@oracle.com>
 <d3d6c258-4a26-331b-a85c-9e7f23fa8229@bell-sw.com>
 <58726425-BA16-482B-A02E-3B0613CD5010@oracle.com>
Message-ID: <ff937e56-43ba-1f44-7f37-96d715661082@bell-sw.com>

Paul,

Thank you!

-Dmitry


On 31.10.2017 20:32, Paul Sandoz wrote:
> 
>> On 31 Oct 2017, at 05:58, Dmitry Samersoff <dmitry.samersoff at bell-sw.com> wrote:
>>
>> Paul and Frederic,
>>
>> Thank you.
>>
>> One more question. Do we need to call verify_oop below?
>>
>> 509   { // Check for the null sentinel.
>> ...
>> 517      xorptr(result, result);  // NULL object reference
>> ...
>>
>> 521   if (VerifyOops) {
>> 522      verify_oop(result);
>> 523   }
>>
> 
> I believe it?s harmless.
> 
> When the flag is on it eventually results in a call to the stub generated by generate_verify_oop:
> 
> http://hg.openjdk.java.net/jdk10/hs/file/tip/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#l1023
> 
>     // make sure object is 'reasonable'
>     __ testptr(rax, rax);
>     __ jcc(Assembler::zero, exit); // if obj is NULL it is OK
> 
> If the oop is null the verification will exit safely.
> 
> Paul.
> 
>> -Dmitry
>>
>>
>> On 31.10.2017 00:56, Frederic Parain wrote:
>>> I?m seeing no issue with rcx being aliased in this code.
>>>
>>> Fred
>>>
>>>> On Oct 30, 2017, at 15:44, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Thanks for reviewing.
>>>>
>>>>> On 30 Oct 2017, at 11:05, Dmitry Samersoff <dmitry.samersoff at bell-sw.com> wrote:
>>>>>
>>>>> Paul,
>>>>>
>>>>> templateTable_x86.cpp:
>>>>>
>>>>> 564   const Register flags = rcx;
>>>>> 565   const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1);
>>>>>
>>>>> Should we use another register for rarg under NOT_LP64 ?
>>>>>
>>>>
>>>> I think it should be ok, it i ain?t an expert here on the interpreter and the calling conventions, so please correct me.
>>>>
>>>> Some more context:
>>>>
>>>> +  const Register flags = rcx;
>>>> +  const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1);
>>>> +  __ movl(rarg, (int)bytecode());
>>>>
>>>> The current bytecode code is loaded into ?rarg?
>>>>
>>>> +  call_VM(obj, CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_ldc), rarg);
>>>>
>>>> Then ?rarg" is the argument to the call to InterpreterRuntime::resolve_ldc, after which it is no longer referred to.
>>>>
>>>> +#ifndef _LP64
>>>> +  // borrow rdi from locals
>>>> +  __ get_thread(rdi);
>>>> +  __ get_vm_result_2(flags, rdi);
>>>> +  __ restore_locals();
>>>> +#else
>>>> +  __ get_vm_result_2(flags, r15_thread);
>>>> +#endif
>>>>
>>>> The result from the call is then loaded into flags.
>>>>
>>>> So i don?t think it matters in this case if rcx is aliased.
>>>>
>>>> Paul.
>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>> On 10/26/2017 08:03 PM, Paul Sandoz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the following patch for minimal dynamic constant support:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186046 <https://bugs.openjdk.java.net/browse/JDK-8186046>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186209 <https://bugs.openjdk.java.net/browse/JDK-8186209>
>>>>>>
>>>>>> This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good.
>>>>>>
>>>>>> By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex.
>>>>>>
>>>>>> A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository).
>>>>>>
>>>>>> Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments.
>>>>>>
>>>>>> The CSR for the VM specification is here:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8189199 <https://bugs.openjdk.java.net/browse/JDK-8189199>
>>>>>>
>>>>>> the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles).
>>>>>>
>>>>>> Any AoT-related work will be deferred to a future release.
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte).
>>>>>>
>>>>>> We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches.
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants.
>>>>>>
>>>>>> One test uses class file bytes produced from a modified version of asmtools.  The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test.
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> Paul.
>>>>>>
>>>>>
>>>>
>>>
>>
>>
> 



From paul.sandoz at oracle.com  Wed Nov  1 17:21:25 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 1 Nov 2017 10:21:25 -0700
Subject: RFR Re: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <f09eee75-39f2-b8cc-a95e-29e5be9c3b7e@oracle.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <DF5459F9-D1F9-4E54-8543-43FFB2BF4341@gmail.com>
 <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>
 <59F7C175.7010705@oracle.com>
 <11BAC038-0D59-467C-AE0B-212049E5E46B@oracle.com>
 <f09eee75-39f2-b8cc-a95e-29e5be9c3b7e@oracle.com>
Message-ID: <BA7001C8-479A-4669-9EA3-74250DF7196B@oracle.com>


> On 31 Oct 2017, at 16:46, joe darcy <joe.darcy at oracle.com> wrote:
>>> 
>> In that case we need to double (sorry) down on the NaNs and include sum as well:
>> 
>> *   <li>{@code (min <= max && !isNaN(sum)) || (isNaN(min) && isNaN(max) && isNaN(sum))}
> 
> A more complete test for the numerical consistency conditions would be something like
> 
>    min <= sum/count  <= max
> 
> However, that would require a bit of thought due to potential round-off so this might not be worth the complexity trade-off. (If any of min, sum, and max were NaN, the comparisons would be false.)
> 

Yes, my recollection from the discussions we concluded not to do such checks.

Paul.

From amaembo at gmail.com  Wed Nov  1 17:45:04 2017
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 1 Nov 2017 18:45:04 +0100
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
Message-ID: <CAE+3fjYzgEMmFFOge6hdN9wi3qS=5OCTKJKupeLbf-gaaPf9eQ@mail.gmail.com>

Hello!

Set.of:

+        if (coll instanceof ImmutableCollections.AbstractImmutableSet) {
+            return (Set<E>)coll;
+        } else {
+            return (Set<E>)Set.of(coll.stream().distinct().toArray());

I think that good old Set.of(new HashSet<>(coll).toArray()) would
produce less garbage. distinct() also maintains HashSet internally,
but it removes the SIZED characteristic, so instead of preallocated
array you will have a SpinedBuffer which is less efficient than
AbstractCollection.toArray() implementation which just allocates the
array of exact size. What do you think?

Collectors:

+    static final Set<Collector.Characteristics> CH_UNORDERED_NOID
+            = Collections.unmodifiableSet(EnumSet.of(Collector.Characteristics.UNORDERED));

Is it really more efficient currently than
Set.of(Collector.Characteristics.UNORDERED)? At least less objects
will be allocated with Set.of

+    Collector<T, ?, List<T>> toUnmodifiableList() {
+        return new CollectorImpl<>((Supplier<List<T>>)
ArrayList::new, List::add,
+                                   (left, right) -> {
left.addAll(right); return left; },
+                                   list -> (List<T>)List.of(list.toArray()),
+                                   CH_NOID);
+    }

Isn't it reasonable to use `e -> List.add(Objects.requireNonNull(e))`
instead of simply `List::add`? In this case if null is added, then
failure will occur much earlier, and the failure stacktrace would be
more relevant. The same for Set/Map.

+                map ->
(Map<K,U>)Map.ofEntries(map.entrySet().toArray(new Map.Entry[0])));

It's the same lambda in two versions of toUnmodifiableMap. Isn't it
better to extract it to the constant to prevent duplication in the
bytecode (or at least to method and refer to it via method reference)?

With best regards,
Tagir Valeev.




With best regards,
Tagir Valeev.

On Wed, Nov 1, 2017 at 12:49 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
> Updated webrev, based on comments from Brian and Roger:
>
>     http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.2/
>
> s'marks
>
>
>
> On 10/30/17 3:50 PM, Stuart Marks wrote:
>>
>> (also includes 8184690: add Collectors for collecting into unmodifiable
>> List, Set, and Map)
>>
>> Hi all,
>>
>> Here's an updated webrev for this changeset; the previous review thread is
>> here:
>>
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049261.html
>>
>> This webrev includes the following:
>>
>> * specification revisions to provide clearer definitions of "view"
>> collections, "unmodifiable" collections, and "unmodifiable views"
>>
>> * new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" methods
>>
>> * new Collectors.toUnmodifiableList, Set, and Map methods
>>
>> * tests for the new API methods
>>
>> I've added some assertions that require some independence between the
>> source collection (or map) and the result of the copyOf() method.
>>
>> I've made a small but significant change to Set.copyOf compared to the
>> previous round. Previously, it specified that the first of any equal
>> elements was preserved. Now, it is explicitly unspecified which of any
>> equals elements is preserved. This is consistent with Set.addAll,
>> Collectors.toSet, and the newly added Collectors.toUnmodifiableSet, none of
>> which specify which of duplicate elements is preserved.
>>
>> (The outlier here is Stream.distinct, which specifies that the first
>> element of any duplicates is preserved, if the stream is ordered.)
>>
>> I've also made some minor wording/editorial changes in response to
>> suggestions from David Holmes and Roger Riggs. I've kept the wording changes
>> that give emphasis to "unmodifiable" over "immutable." The term "immutable"
>> is inextricably intertwined with "persistent" when it comes to data
>> structures, and I believe we'll be explaining this forever if Java's
>> "immutable" means something different from everybody else's.
>>
>> Webrev:
>>
>>      http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.1/
>>
>> Bugs:
>>
>>      https://bugs.openjdk.java.net/browse/JDK-8177290
>>          add copy factory methods for unmodifiable List, Set, Map
>>
>>      https://bugs.openjdk.java.net/browse/JDK-8184690
>>          add Collectors for collecting into unmodifiable List, Set, and
>> Map
>>
>> Thanks,
>>
>> s'marks

From peter.levart at gmail.com  Wed Nov  1 17:46:13 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 1 Nov 2017 18:46:13 +0100
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <e83dd002-89a5-1e03-9593-dc09a1db3d66@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
 <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
 <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>
 <e83dd002-89a5-1e03-9593-dc09a1db3d66@oracle.com>
Message-ID: <6db5bef5-e373-709e-edf6-de2a312020da@gmail.com>



On 11/01/17 13:34, David Holmes wrote:
> On 1/11/2017 10:20 PM, Peter Levart wrote:
>> On 11/01/17 10:04, David Holmes wrote:
>>> On 1/11/2017 6:16 PM, Peter Levart wrote:
>>>> On 11/01/17 02:49, David Holmes wrote:
>>>>> Hi Roger,
>>>>>
>>>>> On 31/10/2017 11:58 PM, Roger Riggs wrote:
>>>>>> Hi Peter,
>>>>>>
>>>>>> Only native resources that do not map to the heap allocation/gc 
>>>>>> cycle need any kind
>>>>>> of cleanup.? I would work toward a model that encapsulates the 
>>>>>> reference to a native resource
>>>>>> with a corresponding allocation/release mechanism as you've 
>>>>>> described here and in the
>>>>>> thread on zip.
>>>>>>
>>>>>> For cleanup purposes, the independence of each resource may 
>>>>>> improve robustness
>>>>>> by avoiding dependencies and opportunities for entanglements and 
>>>>>> bugs due to exceptions
>>>>>> and other failures.
>>>>>>
>>>>>> In the case of TPE, the native resources are Threads, which keep 
>>>>>> running even if they are
>>>>>> unreferenced and are kept referenced via ThreadGroups.
>>>>>> I don't know the Executor code well enough to do more than 
>>>>>> speculate, but would suggest
>>>>>> that a cleaner (or similar) should be registered for each thread .
>>>>>
>>>>> Threads are not native resources to be managed by Cleaners! A live 
>>>>> Thread can never be cleaned. A dead thread has nothing to clean!
>>>>
>>>> Right, but an idle thread, waiting for a task that will never come 
>>>> since the only entry point for submitting tasks is not reachable 
>>>> (the pool), may be cleaned...
>>>
>>> cleaned? It can be interrupted if you know about it and find locate 
>>> it. But it will not be eligible for cleaning ala Cleaner as it will 
>>> always be strongly reachable.
>>
>> Ah I see what you meant before. Yes, tracking Thread object with a 
>> Cleaner does not have any sense. But tracking thread pool object with 
>> a Cleaner and cleaning (stopping) threads as a result makes sense...
>
> No, because live Threads will keep the thread pool strongly reachable.
>
> If you manage to structure things such that the Threads don't keep the 
> pool strongly reachable then you risk having the pool cleaned while 
> still actively in use.

Pool is actively in use when it is still reachable. Only in that case 
can new tasks be submitted. When it is not reachable any more, no new 
tasks can be submitted and it can be shutdown():

 ??? /**
 ???? * Initiates an orderly shutdown in which previously submitted
 ???? * tasks are executed, but no new tasks will be accepted...

Regards, Peter


From stuart.marks at oracle.com  Wed Nov  1 19:07:17 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 1 Nov 2017 12:07:17 -0700
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <16f9c87e-3f23-a813-fb62-ed8f616c7e5d@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
 <bfd6c977-df4d-53ba-a59c-8e2a6c04f2eb@Oracle.com>
 <CA+kOe08vE5hXJRot0t8p==VnsY6DEaD0ipqcrMYPkhMOW=rzDg@mail.gmail.com>
 <305aa1b0-ee40-b2fd-d1bd-4aeedad55a56@oracle.com>
 <16f9c87e-3f23-a813-fb62-ed8f616c7e5d@oracle.com>
Message-ID: <a94bf6ce-95d5-3c7b-1e91-711450fb5adb@oracle.com>

On 10/31/17 6:58 PM, David Holmes wrote:
>> I'm not sure why you say this isn't helpful. It's clearly not helpful to 
>> *clients* of TPE; but since finalize() is protected, the warning is clearly 
>> directed at subclasses, and it provides information about migrating away from 
>> finalization. Should say something different?
> 
> It isn't helpful to people subclassing TPE (or any class that defines 
> finalize()) because the general strategies described in Object.finalize() can't 
> be applied by the subclass independent of the class (TPE here) it is 
> subclassing. Unless TPE provides an alternate mechanism, the subclass is stuck 
> with finalize().

I don't understand why the subclass has to rely on the mechanism provided by its 
superclass (TPE here). I'm thinking of a case like the following.

Suppose a subclass has some independent native resource that it needs to clean 
up. Prior to the introduction of java.lang.ref, the only thing available was 
finalization. The subclass would have to override finalize(), do its own 
cleanup, and then make sure to call super.finalize().

With Cleaner in JDK 9, the subclass can refactor its native resources into a 
Cleanable, register it with a Cleaner, and then clean up its native resources 
when the Cleanable's clean() method is called.

Can't this be done independently of TPE and finalization?

s'marks

From xueming.shen at oracle.com  Wed Nov  1 19:17:39 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 01 Nov 2017 12:17:39 -0700
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <5b2ec510-7420-142f-eb96-6d851bb049eb@gmail.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
 <59F7735A.3000501@oracle.com>
 <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>
 <59F7B6A1.5040303@oracle.com>
 <16e98d55-35c0-a039-edf5-95240bed2510@gmail.com>
 <59F90664.9050403@oracle.com>
 <5b2ec510-7420-142f-eb96-6d851bb049eb@gmail.com>
Message-ID: <59FA1DD3.2090604@oracle.com>

Hi Peter,

I like the idea of moving get/releaseInflter() into CleanableResource, 
though I doubt
how much it can really help the GC it should be a good thing to do to 
remove the strong
reference of ZipFile from stream's cleaner, and the code appears a 
little cleaner as well.

I was debating with myself whether or not the ZipFile.close() should 
throw an
UncheckedIOException (like those java.nio.file.Files methods do). But 
you're right it's
not good to simply ignoring them silently. Now I catch/unwarp the potential
UncheckedIOException from res.clean() and re-throw the embedded ioe.

I need to dig a little to recall the real reason of zsrc==null check in 
ensureOpen()
the comment does not sound updated. res.zsrc is not final and it is set 
to null
when clean up/close. So I keep it for now.

Most (if not all?) "minor nit" has been updated accordingly.

It seems like we might have have put the "finalize()" method back as an 
empty-body
method for compatibility reason. So not done yet :-)

http://cr.openjdk.java.net/~sherman/8185582/webrev/

thanks,
sherman

On 11/1/17, 5:04 AM, Peter Levart wrote:
> Hi Sherman,
>
> On 11/01/17 00:25, Xueming Shen wrote:
>> Hi Peter,
>>
>> After tried couple implementations it seems the most reasonable 
>> approach is to
>> use the coding pattern you suggested to move all pieces into ZSStream 
>> Ref. Given
>> we are already using the internal API CleanerFactory it is attractive 
>> to go a little
>> further to subclass PhantomCleanable directly (in which I would 
>> assume we can
>> save one extra object), but I think I'd better to follow the 
>> "suggested" clean usage
>> (to register a runnable into the cleaner) for now.
>>
>>   39 class ZStreamRef implements Runnable {
>>   40
>>   41     private LongConsumer end;
>>   42     private volatile long address;
>>   43     private final Cleanable cleanable;
>>   44
>>   45     ZStreamRef (Object owner, LongSupplier addr, LongConsumer 
>> end) {
>>   46         this.cleanable = 
>> CleanerFactory.cleaner().register(owner, this);
>>   47         this.end = end;
>>   48         this.address = addr.getAsLong();
>>   49     }
>>   50
>>
>> Similar change has been made for the ZipFile cleaner to follow the 
>> same coding
>> pattern. The "cleaner" is now renamed from Releaser to 
>> CleanableResource.
>>
>> http://cr.openjdk.java.net/~sherman/8185582/webrev/
>>
>> Thanks,
>> Sherman
>
> This looks mostly fine. One minor nit is that ZStreamRef.address field 
> does not have to be volatile. I checked all usages of 
> ZStreamRef.address() and all of them invoke it while holding a lock on 
> the ZStreamRef instance. The ZStreamRef.run() which modifies the 
> address is also synchronized. The other minor nit is that the 
> following ZipFile imports are not needed:
>
> import java.nio.file.Path;
> import java.util.Map;
> import jdk.internal.misc.JavaIORandomAccessFileAccess;
> import static java.util.zip.ZipConstants.*;
>
> (at least my IDEA colors them unused)
>
> Cleaner is modified in this webrev (just one empty line deleted) - 
> better not touch this file in this changeset
>
> Additional nits in ZipFile:
>
> - in lines 355, 356 you pull out two res fields into locals, but then 
> not use them consistently (lines 372, 389)
> - line 403 has a TAB character (is this OK?) and shows incorrectly 
> indented in my editor (should I set tab stops differently?)
> - line 457 - while should actually be if ?
> - in ensureOpen() the check for res.zsrc == null can never succeed 
> (CleanableResource.zsrc is a final field. If CleanableResource 
> constructor fails, there's no res object and there's no ZipFile object 
> either as ZipFile constructor does not do anything for this to escape 
> prematurely)
> - why don't you let IOExceptions thrown from CleanableResource.run() 
> propagate out of ZipFile.close() ?
>
> I would also rename static method Source.close(Source) to 
> Source.release(Source) so it would not clash with instance method 
> Source.close() which makes it ambiguous when one wants to use 
> Source::close method reference (both methods apply). I would also make 
> static methods Source.get() and Source.release(Source) package-private 
> (currently one is public and the other is private, which needs 
> compiler bridges to be invoked) and both are in a private nested class.
>
> Inflater/Deflater/ZipFile now follow the coding pattern as suggested. 
> But ZipFileInflaterInputStream still does not. It's not critical since 
> failing to register cleanup which releases the inflater back into 
> cache would simply mean that Inflater employs its own cleanup and ends 
> itself.
>
> And now another thing I would like to discuss. Why an initiative for 
> using Cleaner instead of finalization()? Among drawbacks finalization 
> has one of the more troubling is that the tracked referent survives 
> the GC cycle that initiates its finalization reference processing 
> pipeline, so the GC may reclaim the object (and referenced objects) 
> only after the finalize() has finished in yet another GC round. 
> Cleaner API separates the tracked object from the cleanup function and 
> state needed to perform it into distinct instances. The tracked object 
> can be reclaimed and the cleanup reference processing pipeline 
> initiated in the same GC cycle. More heap may be reclaimed earlier.
>
> Unless we are careful and create a cleaning function for one tracked 
> object which captures (directly or indirectly) another object which 
> registers its own cleaning function but we don't deal with explicit 
> cleaning of the 2nd object in the 1st cleaning function.
>
> Take for example the ZipFileInflaterInputStream's cleaning function. 
> It captures the ZipFile in order to invoke ZipFile.releaseInflater 
> instance method. What this means is that ZipFile will be kept 
> reachable until all ZipFileInflaterInputStream's cleaning functions 
> have fired. So we are back to the finalization drawback which needs at 
> least 2 GC cycles to collect and clean-up what might be done in one go.
>
> I suggest moving the getInflater() and releaseInflater() from ZipFile 
> into the CleanableResource so that ZipFileInflaterInputStream's 
> cleaning function captures just the CleanableResource and not the 
> ZipFile. ZipFile therefore may become eligible for cleanup as soon as 
> all opened input streams become eligible (but their cleaning functions 
> need not have fired yet). CleanableResource.run() (the ZipFile 
> cleaning function) and CleanableResource.releaseInflater() (the 
> ZipFileInflaterInputStream's cleaning function) may therefore be 
> invoked in arbitrary order (maybe even concurrently if one of them is 
> explicit cleanup and the other is automatic), so code must be prepared 
> for that.
>
> I have tried to capture all above in a modified webrev (taking your 
> last webrev as a base):
>
> http://cr.openjdk.java.net/~plevart/jdk10-dev/8185582_ZIP.cleaner/webrev.03/
>
>
> Regards, Peter
>


From stuart.marks at oracle.com  Wed Nov  1 19:25:21 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 1 Nov 2017 12:25:21 -0700
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <AM4PR08MB12199717DB39BAA682DE5B3BFF5F0@AM4PR08MB1219.eurprd08.prod.outlook.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <AM4PR08MB12199717DB39BAA682DE5B3BFF5F0@AM4PR08MB1219.eurprd08.prod.outlook.com>
Message-ID: <3ea78605-b083-1fcc-3cb8-1adc6d76d045@oracle.com>

On 10/31/17 5:52 PM, Bernd Eckenfels wrote:
> Having a List.of(List) copy constructor would save an additional array copy in the collector Which uses  (List<T>)List.of(list.toArray())

The quickest way to get all the elements from the source collection is to call 
toArray() on it. Some copy constructors (like ArrayList's) simply use the 
returned array for internal storage. This saves a copy, but it relies on the 
source collection's toArray() implementation to be correct. In particular, the 
returned array must be freshly created, and that array must be of type Object[]. 
If either of these is violated, it will break the ArrayList.

The "immutable" collections behind List.of/copyOf/etc. are fastidious about 
allocating their internal arrays in order to ensure that they are referenced 
only from within the newly created collection. This requires making an "extra" 
copy of the array returned by toArray().

An alternative is for the new collection to preallocate its internal array using 
the source's size(), and then to copy the elements out. But the source's size 
might change during the copy (e.g., if it's a concurrent collection) so this 
complicates things.

I think the only safe way to avoid the extra copy is to create a private 
interface that can be used by JDK implementations.

s'marks

From patrick at reini.net  Wed Nov  1 19:44:55 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 1 Nov 2017 20:44:55 +0100
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <3ea78605-b083-1fcc-3cb8-1adc6d76d045@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <AM4PR08MB12199717DB39BAA682DE5B3BFF5F0@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <3ea78605-b083-1fcc-3cb8-1adc6d76d045@oracle.com>
Message-ID: <1B0724CA-ADB2-432A-9004-B0A9C6B74F6E@reini.net>


> Am 01.11.2017 um 20:25 schrieb Stuart Marks <stuart.marks at oracle.com>:
> 
> On 10/31/17 5:52 PM, Bernd Eckenfels wrote:
>> Having a List.of(List) copy constructor would save an additional array copy in the collector Which uses  (List<T>)List.of(list.toArray())
> 
> The quickest way to get all the elements from the source collection is to call toArray() on it. Some copy constructors (like ArrayList's) simply use the returned array for internal storage. This saves a copy, but it relies on the source collection's toArray() implementation to be correct. In particular, the returned array must be freshly created, and that array must be of type Object[]. If either of these is violated, it will break the ArrayList.
> 
> The "immutable" collections behind List.of/copyOf/etc. are fastidious about allocating their internal arrays in order to ensure that they are referenced only from within the newly created collection. This requires making an ?extra" copy of the array returned by toArray().
> 
> An alternative is for the new collection to preallocate its internal array using the source's size(), and then to copy the elements out. But the source?s
> size might change during the copy (e.g., if it?s a concurrent collection) so this complicates things.

I think the array ?overhead? would be only for the cases of zero, one and two value implementations. That seems to me not worth of optimizing?

> I think the only safe way to avoid the extra copy is to create a private interface that can be used by JDK implementations.
> 
> s'marks

-Patrick

From stuart.marks at oracle.com  Wed Nov  1 19:55:42 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 1 Nov 2017 12:55:42 -0700
Subject: Confusion (or bugs) regarding the 'UNORDERED' Collector
 Characteristic
In-Reply-To: <A00CF5D4-7F22-45C0-A032-B339E9CC8DBF@gmail.com>
References: <A00CF5D4-7F22-45C0-A032-B339E9CC8DBF@gmail.com>
Message-ID: <c9d0365e-d3b1-f890-00ff-14674094be40@oracle.com>

On 10/27/17 1:56 PM, Chris Dennis wrote:
> I?m very confused about what was intended with the ?UNORDERED? Collector characteristic.  My logical inference was that unordered as a Collector characteristic meant that the result of this collector applied to any stream was independent of the order of element delivery.  This means that the stream backend could safely elide any ordered characteristic of the stream driving the collector and open up more possible execution pathways (parallelism for example).  The javadoc for unordered is two sentences:
> 
> /**
>   * Indicates that the collection operation does not commit to preserving
>   * the encounter order of input elements.  (This might be true if the
>   * result container has no intrinsic order, such as a {@link Set}.)
>   */
> 
> The first sentence makes sense, although it is phrased in a way that also explains the behavior seen if you flag an order sensitive collector as unordered.  The second sentence is weird, it implies a relation between collectors, encounter order, and an inherent ordering or iteration order of a collection object that might be the target of a collection. To me the important property of a Collection object with regards to ordering of a Collector that fills it is whether reordering the insertions to the collection can change the resultant state, for a Set this is clearly true since only the first presented element that is equal will be stored.

I think you need to be very careful making any assumptions about which of equal 
elements will end up in a set. Consider the spec of Set.addAll:

     Adds all of the elements in the specified collection to this set
     if they're not already present.

Suppose the source collection has several non-identical elements that are equal 
to each other. This says nothing about which of them is preserved, and indeed 
there is no mention whatsoever about the identity of equal objects. The entire 
Set spec is defined in terms of equals, not identity. So I think it's mistaken 
to assume that the first of equal but non-identical objects will be stored.

(This is also the reason I changed the specification of Set.copyOf in my recent 
draft, to remove the requirement that the first such element be preserved. 
Set.addAll and Collectors.toSet make no such stipulation.)

> There is also a paragraph in the Collector javadoc:
> 
> * <p>For collectors that do not have the {@code UNORDERED} characteristic,
> * two accumulated results {@code a1} and {@code a2} are equivalent if
> * {@code finisher.apply(a1).equals(finisher.apply(a2))}.  For unordered
> * collectors, equivalence is relaxed to allow for non-equality related to
> * differences in order.  (For example, an unordered collector that accumulated
> * elements to a {@code List} would consider two lists equivalent if they
> * contained the same elements, ignoring order.)
> 
> This seems weird, why would we try to define correctness of a parallel reduction against a collector that was sensitive to ordering.

This is indeed a bit odd, but it makes sense. You might have a collector that 
collects into a List, because you want to collect duplicates. But you might not 
actually care about the order; you just want all the elements. The fact that 
List stores elements in some order is irrelevant. In this case such a collector 
would quite reasonably have the UNORDERED characteristic.

> Finally, when investigating the properties of the collectors returned from the Collectors static factory I was surprised to discover that none of the collectors that are truly unordered were marked as such (counting, min, max, averaging, summing, summarizing), and the only collector that was marked as unordered was Collectors.toSet(), which although it is explicitly marked as unordered seems like it really shouldn?t be.
> 
> Whats going on here?  Which parts of all this are intended and which (if any) are bugs?

Well I think it does make sense for the toSet() collector to be UNORDERED. It 
may be the case, though, that other collectors are lacking the UNORDERED 
characteristic that they should have. That sounds like it might be a bug.

s'marks


> 
> Thanks in advance for any enlightenment,
> 
> Chris Dennis
> 
> P.S. Coincidentally the unordered toSet() collector works perfectly at the moment due to the happy interaction of the Spliterator.trySplit() contract and the folding/combining behavior of the stream implementations parallel reduction algorithm.
> 

From lowasser at google.com  Wed Nov  1 20:05:11 2017
From: lowasser at google.com (Louis Wasserman)
Date: Wed, 01 Nov 2017 20:05:11 +0000
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <1B0724CA-ADB2-432A-9004-B0A9C6B74F6E@reini.net>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <AM4PR08MB12199717DB39BAA682DE5B3BFF5F0@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <3ea78605-b083-1fcc-3cb8-1adc6d76d045@oracle.com>
 <1B0724CA-ADB2-432A-9004-B0A9C6B74F6E@reini.net>
Message-ID: <CAGB9EW-Zpd4D5Hc1ri4vPjnVQQ1zG7hifHoe=6cYr7zEB2r0Gg@mail.gmail.com>

I disagree, actually.  Collections with size zero and one are significantly
more common than bigger collections.

In Guava's immutable collection factories (ImmutableList.of(...) etc.), we
observed a roughly exponential decline in the number of users of factory
methods of each size: if N people created empty lists, ~N/2 created
singleton lists, ~N/4 created two-element lists, etc.  We got noticeable
pushback from RAM-sensitive customers when we eliminated some specialized
singleton collection implementations.

Our experience has been that specializing for N=0 and N=1 does pay off.
Probably not N=2, though?

On Wed, Nov 1, 2017 at 12:45 PM Patrick Reinhart <patrick at reini.net> wrote:

>
> > Am 01.11.2017 um 20:25 schrieb Stuart Marks <stuart.marks at oracle.com>:
> >
> > On 10/31/17 5:52 PM, Bernd Eckenfels wrote:
> >> Having a List.of(List) copy constructor would save an additional array
> copy in the collector Which uses  (List<T>)List.of(list.toArray())
> >
> > The quickest way to get all the elements from the source collection is
> to call toArray() on it. Some copy constructors (like ArrayList's) simply
> use the returned array for internal storage. This saves a copy, but it
> relies on the source collection's toArray() implementation to be correct.
> In particular, the returned array must be freshly created, and that array
> must be of type Object[]. If either of these is violated, it will break the
> ArrayList.
> >
> > The "immutable" collections behind List.of/copyOf/etc. are fastidious
> about allocating their internal arrays in order to ensure that they are
> referenced only from within the newly created collection. This requires
> making an ?extra" copy of the array returned by toArray().
> >
> > An alternative is for the new collection to preallocate its internal
> array using the source's size(), and then to copy the elements out. But the
> source?s
> > size might change during the copy (e.g., if it?s a concurrent
> collection) so this complicates things.
>
> I think the array ?overhead? would be only for the cases of zero, one and
> two value implementations. That seems to me not worth of optimizing?
>
> > I think the only safe way to avoid the extra copy is to create a private
> interface that can be used by JDK implementations.
> >
> > s'marks
>
> -Patrick
>

From patrick at reini.net  Wed Nov  1 20:29:46 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 1 Nov 2017 21:29:46 +0100
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <CAGB9EW-Zpd4D5Hc1ri4vPjnVQQ1zG7hifHoe=6cYr7zEB2r0Gg@mail.gmail.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <AM4PR08MB12199717DB39BAA682DE5B3BFF5F0@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <3ea78605-b083-1fcc-3cb8-1adc6d76d045@oracle.com>
 <1B0724CA-ADB2-432A-9004-B0A9C6B74F6E@reini.net>
 <CAGB9EW-Zpd4D5Hc1ri4vPjnVQQ1zG7hifHoe=6cYr7zEB2r0Gg@mail.gmail.com>
Message-ID: <85BE47B6-2214-43AD-B7D0-01F846E42EED@reini.net>

In this case I would prefer a non static copyOf() method on the list to create a unmodifiable list/set/map, where the optimal factory method can be called. This would also solve the problem of a concurrent implementation.

-Patrick


> Am 01.11.2017 um 21:05 schrieb Louis Wasserman <lowasser at google.com>:
> 
> I disagree, actually.  Collections with size zero and one are significantly more common than bigger collections.
> 
> In Guava's immutable collection factories (ImmutableList.of(...) etc.), we observed a roughly exponential decline in the number of users of factory methods of each size: if N people created empty lists, ~N/2 created singleton lists, ~N/4 created two-element lists, etc.  We got noticeable pushback from RAM-sensitive customers when we eliminated some specialized singleton collection implementations.
> 
> Our experience has been that specializing for N=0 and N=1 does pay off.  Probably not N=2, though?
> 
> On Wed, Nov 1, 2017 at 12:45 PM Patrick Reinhart <patrick at reini.net <mailto:patrick at reini.net>> wrote:
> 
> > Am 01.11.2017 um 20:25 schrieb Stuart Marks <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com>>:
> >
> > On 10/31/17 5:52 PM, Bernd Eckenfels wrote:
> >> Having a List.of(List) copy constructor would save an additional array copy in the collector Which uses  (List<T>)List.of(list.toArray())
> >
> > The quickest way to get all the elements from the source collection is to call toArray() on it. Some copy constructors (like ArrayList's) simply use the returned array for internal storage. This saves a copy, but it relies on the source collection's toArray() implementation to be correct. In particular, the returned array must be freshly created, and that array must be of type Object[]. If either of these is violated, it will break the ArrayList.
> >
> > The "immutable" collections behind List.of/copyOf/etc. are fastidious about allocating their internal arrays in order to ensure that they are referenced only from within the newly created collection. This requires making an ?extra" copy of the array returned by toArray().
> >
> > An alternative is for the new collection to preallocate its internal array using the source's size(), and then to copy the elements out. But the source?s
> > size might change during the copy (e.g., if it?s a concurrent collection) so this complicates things.
> 
> I think the array ?overhead? would be only for the cases of zero, one and two value implementations. That seems to me not worth of optimizing?
> 
> > I think the only safe way to avoid the extra copy is to create a private interface that can be used by JDK implementations.
> >
> > s'marks
> 
> -Patrick


From Roger.Riggs at Oracle.com  Wed Nov  1 20:50:28 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 1 Nov 2017 16:50:28 -0400
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
Message-ID: <b453a03d-f791-cd28-bb68-0f4f75311825@Oracle.com>

Hi Stuart,

A few editorial comments:

Collection.java: Lines 110, 133, 166
The bold labels probably want to be on their own lines and not 
terminated by "." to look like headings
(or be headings if the CSS supports them)

List.java: Consistency of markup references to unmodifiable List|Set|Map.
The List.of constructors put the reference on a separate line, but the 
copyOf constructor
does not.? You could probably omit the blank line.
(BTW, the copyOf constructor does not always create a copy; I'm not sure 
if the method
name will result in an incorrect assumption but it may be misleading or 
a spec issue.)

The same observations are true for Map and Set constructors.

Thanks, Roger




On 10/31/2017 7:49 PM, Stuart Marks wrote:
> Updated webrev, based on comments from Brian and Roger:
>
> ??? http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.2/
>
> s'marks
>
>
> On 10/30/17 3:50 PM, Stuart Marks wrote:
>> (also includes 8184690: add Collectors for collecting into 
>> unmodifiable List, Set, and Map)
>>
>> Hi all,
>>
>> Here's an updated webrev for this changeset; the previous review 
>> thread is here:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049261.html
>>
>> This webrev includes the following:
>>
>> * specification revisions to provide clearer definitions of "view" 
>> collections, "unmodifiable" collections, and "unmodifiable views"
>>
>> * new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" 
>> methods
>>
>> * new Collectors.toUnmodifiableList, Set, and Map methods
>>
>> * tests for the new API methods
>>
>> I've added some assertions that require some independence between the 
>> source collection (or map) and the result of the copyOf() method.
>>
>> I've made a small but significant change to Set.copyOf compared to 
>> the previous round. Previously, it specified that the first of any 
>> equal elements was preserved. Now, it is explicitly unspecified which 
>> of any equals elements is preserved. This is consistent with 
>> Set.addAll, Collectors.toSet, and the newly added 
>> Collectors.toUnmodifiableSet, none of which specify which of 
>> duplicate elements is preserved.
>>
>> (The outlier here is Stream.distinct, which specifies that the first 
>> element of any duplicates is preserved, if the stream is ordered.)
>>
>> I've also made some minor wording/editorial changes in response to 
>> suggestions from David Holmes and Roger Riggs. I've kept the wording 
>> changes that give emphasis to "unmodifiable" over "immutable." The 
>> term "immutable" is inextricably intertwined with "persistent" when 
>> it comes to data structures, and I believe we'll be explaining this 
>> forever if Java's "immutable" means something different from 
>> everybody else's.
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.1/
>>
>> Bugs:
>>
>> ???? https://bugs.openjdk.java.net/browse/JDK-8177290
>> ???????? add copy factory methods for unmodifiable List, Set, Map
>>
>> ???? https://bugs.openjdk.java.net/browse/JDK-8184690
>> ???????? add Collectors for collecting into unmodifiable List, Set, 
>> and Map
>>
>> Thanks,
>>
>> s'marks


From spliterator at gmail.com  Wed Nov  1 23:01:19 2017
From: spliterator at gmail.com (Stefan Zobel)
Date: Thu, 2 Nov 2017 00:01:19 +0100
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
Message-ID: <CAPkkuSctDbApfZDxi-CcJLYAU0KuvNCg28BYA-rj_9yUeTSd9A@mail.gmail.com>

Hi Stuart,

only a minor nit. In Map.java, the class-level
Javadoc anchor id="immutable" doesn't match the
href="#unmodifiable" used in the methods.

+ * <h2><a id="immutable">Unmodifiable Maps</a></h2>

vs.

+ * See <a href="#unmodifiable">Unmodifiable Maps</a> for details.


Regards,
Stefan


2017-11-01 0:49 GMT+01:00 Stuart Marks <stuart.marks at oracle.com>:
> Updated webrev, based on comments from Brian and Roger:
>
>     http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.2/
>
> s'marks
>
>
>
> On 10/30/17 3:50 PM, Stuart Marks wrote:
>>
>> (also includes 8184690: add Collectors for collecting into unmodifiable
>> List, Set, and Map)
>>
>> Hi all,
>>
>> Here's an updated webrev for this changeset; the previous review thread is
>> here:
>>
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049261.html
>>
>> This webrev includes the following:
>>
>> * specification revisions to provide clearer definitions of "view"
>> collections, "unmodifiable" collections, and "unmodifiable views"
>>
>> * new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" methods
>>
>> * new Collectors.toUnmodifiableList, Set, and Map methods
>>
>> * tests for the new API methods
>>
>> I've added some assertions that require some independence between the
>> source collection (or map) and the result of the copyOf() method.
>>
>> I've made a small but significant change to Set.copyOf compared to the
>> previous round. Previously, it specified that the first of any equal
>> elements was preserved. Now, it is explicitly unspecified which of any
>> equals elements is preserved. This is consistent with Set.addAll,
>> Collectors.toSet, and the newly added Collectors.toUnmodifiableSet, none of
>> which specify which of duplicate elements is preserved.
>>
>> (The outlier here is Stream.distinct, which specifies that the first
>> element of any duplicates is preserved, if the stream is ordered.)
>>
>> I've also made some minor wording/editorial changes in response to
>> suggestions from David Holmes and Roger Riggs. I've kept the wording changes
>> that give emphasis to "unmodifiable" over "immutable." The term "immutable"
>> is inextricably intertwined with "persistent" when it comes to data
>> structures, and I believe we'll be explaining this forever if Java's
>> "immutable" means something different from everybody else's.
>>
>> Webrev:
>>
>>      http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.1/
>>
>> Bugs:
>>
>>      https://bugs.openjdk.java.net/browse/JDK-8177290
>>          add copy factory methods for unmodifiable List, Set, Map
>>
>>      https://bugs.openjdk.java.net/browse/JDK-8184690
>>          add Collectors for collecting into unmodifiable List, Set, and
>> Map
>>
>> Thanks,
>>
>> s'marks

From stuart.marks at oracle.com  Wed Nov  1 23:51:02 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 1 Nov 2017 16:51:02 -0700
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <CAE+3fjYzgEMmFFOge6hdN9wi3qS=5OCTKJKupeLbf-gaaPf9eQ@mail.gmail.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <CAE+3fjYzgEMmFFOge6hdN9wi3qS=5OCTKJKupeLbf-gaaPf9eQ@mail.gmail.com>
Message-ID: <d02cf931-6bd4-3b99-3375-dbce6e8047c8@oracle.com>



On 11/1/17 10:45 AM, Tagir Valeev wrote:
> Set.of:
> 
> +        if (coll instanceof ImmutableCollections.AbstractImmutableSet) {
> +            return (Set<E>)coll;
> +        } else {
> +            return (Set<E>)Set.of(coll.stream().distinct().toArray());
> 
> I think that good old Set.of(new HashSet<>(coll).toArray()) would
> produce less garbage. distinct() also maintains HashSet internally,
> but it removes the SIZED characteristic, so instead of preallocated
> array you will have a SpinedBuffer which is less efficient than
> AbstractCollection.toArray() implementation which just allocates the
> array of exact size. What do you think?

Oh yes, good point. I had initially used stream().distinct() because I wanted to 
use distinct()'s semantics of preserving the first equal element among 
duplicates. But since I removed that requirement from the spec, using a HashSet 
as you suggest is much simpler.

> Collectors:
> 
> +    static final Set<Collector.Characteristics> CH_UNORDERED_NOID
> +            = Collections.unmodifiableSet(EnumSet.of(Collector.Characteristics.UNORDERED));
> 
> Is it really more efficient currently than
> Set.of(Collector.Characteristics.UNORDERED)? At least less objects
> will be allocated with Set.of

Maybe. I'm just following the same pattern as the nearby characteristics. 
They're singletons, so this hardly makes any difference. What's really needed is 
an unmodifiable EnumSet, which I hope to get to at some point.

> +    Collector<T, ?, List<T>> toUnmodifiableList() {
> +        return new CollectorImpl<>((Supplier<List<T>>)
> ArrayList::new, List::add,
> +                                   (left, right) -> {
> left.addAll(right); return left; },
> +                                   list -> (List<T>)List.of(list.toArray()),
> +                                   CH_NOID);
> +    }
> 
> Isn't it reasonable to use `e -> List.add(Objects.requireNonNull(e))`
> instead of simply `List::add`? In this case if null is added, then
> failure will occur much earlier, and the failure stacktrace would be
> more relevant. The same for Set/Map.

Interesting. Initally I thought this would be a good idea, but then I tried it 
out. With the implementation in my latest webrev, the stack trace is this:


jshell> Arrays.asList(1, 2, null, 
4).stream().collect(Collectors.toUnmodifiableList())
|  java.lang.NullPointerException thrown
|        at Objects.requireNonNull (Objects.java:221)
|        at ImmutableCollections$ListN.<init> (ImmutableCollections.java:234)
|        at List.of (List.java:1039)
|        at Collectors.lambda$toUnmodifiableList$6 (Collectors.java:299)
|        at ReferencePipeline.collect (ReferencePipeline.java:515)
|        at (#2:1)


With the lambda and requireNonNull(), the stack trace is this:


jshell> Arrays.asList(1, 2, null, 
4).stream().collect(Collectors.toUnmodifiableList())
|  java.lang.NullPointerException thrown
|        at Objects.requireNonNull (Objects.java:221)
|        at Collectors.lambda$toUnmodifiableList$5 (Collectors.java:298)
|        at ReduceOps$3ReducingSink.accept (ReduceOps.java:169)
|        at Spliterators$ArraySpliterator.forEachRemaining (Spliterators.java:948)
|        at AbstractPipeline.copyInto (AbstractPipeline.java:484)
|        at AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:474)
|        at ReduceOps$ReduceOp.evaluateSequential (ReduceOps.java:913)
|        at AbstractPipeline.evaluate (AbstractPipeline.java:234)
|        at ReferencePipeline.collect (ReferencePipeline.java:511)
|        at (#2:1)


It's true that with lambda+requireNonNull, the NPE will be thrown earlier in 
processing. But the stack trace isn't any clearer (the only user code is at the 
very bottom at location "#2:1") and it's still within the context of the same 
call to the stream's terminal collect() call. So, doesn't seem like it makes 
much difference.


> +                map ->
> (Map<K,U>)Map.ofEntries(map.entrySet().toArray(new Map.Entry[0])));
> 
> It's the same lambda in two versions of toUnmodifiableMap. Isn't it
> better to extract it to the constant to prevent duplication in the
> bytecode (or at least to method and refer to it via method reference)?

It might be better to do that, but given that this is the code I want to replace 
with a private interface, I don't think it's worth fiddling around with at this 
point.

Thanks,

s'marks


> With best regards,
> Tagir Valeev.
> 
> 
> 
> 
> With best regards,
> Tagir Valeev.
> 
> On Wed, Nov 1, 2017 at 12:49 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
>> Updated webrev, based on comments from Brian and Roger:
>>
>>      http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.2/
>>
>> s'marks
>>
>>
>>
>> On 10/30/17 3:50 PM, Stuart Marks wrote:
>>>
>>> (also includes 8184690: add Collectors for collecting into unmodifiable
>>> List, Set, and Map)
>>>
>>> Hi all,
>>>
>>> Here's an updated webrev for this changeset; the previous review thread is
>>> here:
>>>
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049261.html
>>>
>>> This webrev includes the following:
>>>
>>> * specification revisions to provide clearer definitions of "view"
>>> collections, "unmodifiable" collections, and "unmodifiable views"
>>>
>>> * new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" methods
>>>
>>> * new Collectors.toUnmodifiableList, Set, and Map methods
>>>
>>> * tests for the new API methods
>>>
>>> I've added some assertions that require some independence between the
>>> source collection (or map) and the result of the copyOf() method.
>>>
>>> I've made a small but significant change to Set.copyOf compared to the
>>> previous round. Previously, it specified that the first of any equal
>>> elements was preserved. Now, it is explicitly unspecified which of any
>>> equals elements is preserved. This is consistent with Set.addAll,
>>> Collectors.toSet, and the newly added Collectors.toUnmodifiableSet, none of
>>> which specify which of duplicate elements is preserved.
>>>
>>> (The outlier here is Stream.distinct, which specifies that the first
>>> element of any duplicates is preserved, if the stream is ordered.)
>>>
>>> I've also made some minor wording/editorial changes in response to
>>> suggestions from David Holmes and Roger Riggs. I've kept the wording changes
>>> that give emphasis to "unmodifiable" over "immutable." The term "immutable"
>>> is inextricably intertwined with "persistent" when it comes to data
>>> structures, and I believe we'll be explaining this forever if Java's
>>> "immutable" means something different from everybody else's.
>>>
>>> Webrev:
>>>
>>>       http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.1/
>>>
>>> Bugs:
>>>
>>>       https://bugs.openjdk.java.net/browse/JDK-8177290
>>>           add copy factory methods for unmodifiable List, Set, Map
>>>
>>>       https://bugs.openjdk.java.net/browse/JDK-8184690
>>>           add Collectors for collecting into unmodifiable List, Set, and
>>> Map
>>>
>>> Thanks,
>>>
>>> s'marks

From stuart.marks at oracle.com  Thu Nov  2 00:53:33 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 1 Nov 2017 17:53:33 -0700
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <b453a03d-f791-cd28-bb68-0f4f75311825@Oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <b453a03d-f791-cd28-bb68-0f4f75311825@Oracle.com>
Message-ID: <5534d8f6-a321-16a2-7bc7-e4c718c93cc3@oracle.com>



On 11/1/17 1:50 PM, Roger Riggs wrote:
> Collection.java: Lines 110, 133, 166
> The bold labels probably want to be on their own lines and not terminated by 
> "." to look like headings
> (or be headings if the CSS supports them)
I'll change these to be actual headings.
> List.java: Consistency of markup references to unmodifiable List|Set|Map.
> The List.of constructors put the reference on a separate line, but the copyOf 
> constructor
> does not.? You could probably omit the blank line.
Yeah, I should update all of these at some point. Given that there are 30-odd 
more methods to change, plus I have a pile of other collections doc changes to 
work on, I think I'll do these in a separate doc pass.
> (BTW, the copyOf constructor does not always create a copy; I'm not sure if 
> the method
> name will result in an incorrect assumption but it may be misleading or a spec 
> issue.)
Right. I haven't been able to come up with any names that had the right 
semantics and that didn't also have connotations that were misleading in some 
other way. I observe that Guava's Immutable collections have copyOf() methods 
with pretty much the same semantics. The Guava docs do note that their methods 
try to avoid making a copy if they can, but they explicitly say that the 
circumstances under which this occurs are unspecified. I've considered adding an 
@apiNote to this effect, but I haven't been able to convince myself that it 
would be helpful to do so. It would seem to raise new issues that we're 
unwilling to answer, such as exactly when is a copy is made vs. when the 
argument is returned. Better, I think, to have people make a copy whenever they 
think they need a copy, and have the implementation short-circuit this when it can.

s'marks

>
> The same observations are true for Map and Set constructors.
>
> Thanks, Roger
>
>
>
>
> On 10/31/2017 7:49 PM, Stuart Marks wrote:
>> Updated webrev, based on comments from Brian and Roger:
>>
>> http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.2/
>>
>> s'marks
>>
>>
>> On 10/30/17 3:50 PM, Stuart Marks wrote:
>>> (also includes 8184690: add Collectors for collecting into unmodifiable 
>>> List, Set, and Map)
>>>
>>> Hi all,
>>>
>>> Here's an updated webrev for this changeset; the previous review thread is 
>>> here:
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049261.html
>>>
>>> This webrev includes the following:
>>>
>>> * specification revisions to provide clearer definitions of "view" 
>>> collections, "unmodifiable" collections, and "unmodifiable views"
>>>
>>> * new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" methods
>>>
>>> * new Collectors.toUnmodifiableList, Set, and Map methods
>>>
>>> * tests for the new API methods
>>>
>>> I've added some assertions that require some independence between the source 
>>> collection (or map) and the result of the copyOf() method.
>>>
>>> I've made a small but significant change to Set.copyOf compared to the 
>>> previous round. Previously, it specified that the first of any equal 
>>> elements was preserved. Now, it is explicitly unspecified which of any 
>>> equals elements is preserved. This is consistent with Set.addAll, 
>>> Collectors.toSet, and the newly added Collectors.toUnmodifiableSet, none of 
>>> which specify which of duplicate elements is preserved.
>>>
>>> (The outlier here is Stream.distinct, which specifies that the first element 
>>> of any duplicates is preserved, if the stream is ordered.)
>>>
>>> I've also made some minor wording/editorial changes in response to 
>>> suggestions from David Holmes and Roger Riggs. I've kept the wording changes 
>>> that give emphasis to "unmodifiable" over "immutable." The term "immutable" 
>>> is inextricably intertwined with "persistent" when it comes to data 
>>> structures, and I believe we'll be explaining this forever if Java's 
>>> "immutable" means something different from everybody else's.
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.1/
>>>
>>> Bugs:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8177290
>>> ???????? add copy factory methods for unmodifiable List, Set, Map
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8184690
>>> ???????? add Collectors for collecting into unmodifiable List, Set, and Map
>>>
>>> Thanks,
>>>
>>> s'marks
>


From stuart.marks at oracle.com  Thu Nov  2 00:53:59 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 1 Nov 2017 17:53:59 -0700
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <CAPkkuSctDbApfZDxi-CcJLYAU0KuvNCg28BYA-rj_9yUeTSd9A@mail.gmail.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <CAPkkuSctDbApfZDxi-CcJLYAU0KuvNCg28BYA-rj_9yUeTSd9A@mail.gmail.com>
Message-ID: <3eeefa3a-fffa-138d-fecb-29e22a00d4c0@oracle.com>

Good catch! Thanks, I'll fix it.

s'marks

On 11/1/17 4:01 PM, Stefan Zobel wrote:
> Hi Stuart,
> 
> only a minor nit. In Map.java, the class-level
> Javadoc anchor id="immutable" doesn't match the
> href="#unmodifiable" used in the methods.
> 
> + * <h2><a id="immutable">Unmodifiable Maps</a></h2>
> 
> vs.
> 
> + * See <a href="#unmodifiable">Unmodifiable Maps</a> for details.
> 
> 
> Regards,
> Stefan
> 
> 
> 2017-11-01 0:49 GMT+01:00 Stuart Marks <stuart.marks at oracle.com>:
>> Updated webrev, based on comments from Brian and Roger:
>>
>>      http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.2/
>>
>> s'marks
>>
>>
>>
>> On 10/30/17 3:50 PM, Stuart Marks wrote:
>>>
>>> (also includes 8184690: add Collectors for collecting into unmodifiable
>>> List, Set, and Map)
>>>
>>> Hi all,
>>>
>>> Here's an updated webrev for this changeset; the previous review thread is
>>> here:
>>>
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049261.html
>>>
>>> This webrev includes the following:
>>>
>>> * specification revisions to provide clearer definitions of "view"
>>> collections, "unmodifiable" collections, and "unmodifiable views"
>>>
>>> * new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" methods
>>>
>>> * new Collectors.toUnmodifiableList, Set, and Map methods
>>>
>>> * tests for the new API methods
>>>
>>> I've added some assertions that require some independence between the
>>> source collection (or map) and the result of the copyOf() method.
>>>
>>> I've made a small but significant change to Set.copyOf compared to the
>>> previous round. Previously, it specified that the first of any equal
>>> elements was preserved. Now, it is explicitly unspecified which of any
>>> equals elements is preserved. This is consistent with Set.addAll,
>>> Collectors.toSet, and the newly added Collectors.toUnmodifiableSet, none of
>>> which specify which of duplicate elements is preserved.
>>>
>>> (The outlier here is Stream.distinct, which specifies that the first
>>> element of any duplicates is preserved, if the stream is ordered.)
>>>
>>> I've also made some minor wording/editorial changes in response to
>>> suggestions from David Holmes and Roger Riggs. I've kept the wording changes
>>> that give emphasis to "unmodifiable" over "immutable." The term "immutable"
>>> is inextricably intertwined with "persistent" when it comes to data
>>> structures, and I believe we'll be explaining this forever if Java's
>>> "immutable" means something different from everybody else's.
>>>
>>> Webrev:
>>>
>>>       http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.1/
>>>
>>> Bugs:
>>>
>>>       https://bugs.openjdk.java.net/browse/JDK-8177290
>>>           add copy factory methods for unmodifiable List, Set, Map
>>>
>>>       https://bugs.openjdk.java.net/browse/JDK-8184690
>>>           add Collectors for collecting into unmodifiable List, Set, and
>>> Map
>>>
>>> Thanks,
>>>
>>> s'marks

From david.holmes at oracle.com  Thu Nov  2 02:30:10 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 2 Nov 2017 12:30:10 +1000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <a94bf6ce-95d5-3c7b-1e91-711450fb5adb@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
 <bfd6c977-df4d-53ba-a59c-8e2a6c04f2eb@Oracle.com>
 <CA+kOe08vE5hXJRot0t8p==VnsY6DEaD0ipqcrMYPkhMOW=rzDg@mail.gmail.com>
 <305aa1b0-ee40-b2fd-d1bd-4aeedad55a56@oracle.com>
 <16f9c87e-3f23-a813-fb62-ed8f616c7e5d@oracle.com>
 <a94bf6ce-95d5-3c7b-1e91-711450fb5adb@oracle.com>
Message-ID: <684d9e38-46e0-875f-3cc3-c6d87735d3dd@oracle.com>

On 2/11/2017 5:07 AM, Stuart Marks wrote:
> On 10/31/17 6:58 PM, David Holmes wrote:
>>> I'm not sure why you say this isn't helpful. It's clearly not helpful 
>>> to *clients* of TPE; but since finalize() is protected, the warning 
>>> is clearly directed at subclasses, and it provides information about 
>>> migrating away from finalization. Should say something different?
>>
>> It isn't helpful to people subclassing TPE (or any class that defines 
>> finalize()) because the general strategies described in 
>> Object.finalize() can't be applied by the subclass independent of the 
>> class (TPE here) it is subclassing. Unless TPE provides an alternate 
>> mechanism, the subclass is stuck with finalize().
> 
> I don't understand why the subclass has to rely on the mechanism 
> provided by its superclass (TPE here). I'm thinking of a case like the 
> following.
> 
> Suppose a subclass has some independent native resource that it needs to 
> clean up. Prior to the introduction of java.lang.ref, the only thing 
> available was finalization. The subclass would have to override 
> finalize(), do its own cleanup, and then make sure to call 
> super.finalize().
> 
> With Cleaner in JDK 9, the subclass can refactor its native resources 
> into a Cleanable, register it with a Cleaner, and then clean up its 
> native resources when the Cleanable's clean() method is called.
> 
> Can't this be done independently of TPE and finalization?

Of course it can. The independent part of the subclass can use whatever 
mechanism it likes - it's independent. The point is that if the subclass 
needs to coordinate it's additional cleanup with the shutdown done by 
finalize() then it needs a means to do so.

David

> s'marks

From david.holmes at oracle.com  Thu Nov  2 02:34:26 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 2 Nov 2017 12:34:26 +1000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <6db5bef5-e373-709e-edf6-de2a312020da@gmail.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
 <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
 <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>
 <e83dd002-89a5-1e03-9593-dc09a1db3d66@oracle.com>
 <6db5bef5-e373-709e-edf6-de2a312020da@gmail.com>
Message-ID: <c4ddb1aa-c115-560b-419e-6742257a4416@oracle.com>



On 2/11/2017 3:46 AM, Peter Levart wrote:
> 
> 
> On 11/01/17 13:34, David Holmes wrote:
>> On 1/11/2017 10:20 PM, Peter Levart wrote:
>>> On 11/01/17 10:04, David Holmes wrote:
>>>> On 1/11/2017 6:16 PM, Peter Levart wrote:
>>>>> On 11/01/17 02:49, David Holmes wrote:
>>>>>> Hi Roger,
>>>>>>
>>>>>> On 31/10/2017 11:58 PM, Roger Riggs wrote:
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> Only native resources that do not map to the heap allocation/gc 
>>>>>>> cycle need any kind
>>>>>>> of cleanup.? I would work toward a model that encapsulates the 
>>>>>>> reference to a native resource
>>>>>>> with a corresponding allocation/release mechanism as you've 
>>>>>>> described here and in the
>>>>>>> thread on zip.
>>>>>>>
>>>>>>> For cleanup purposes, the independence of each resource may 
>>>>>>> improve robustness
>>>>>>> by avoiding dependencies and opportunities for entanglements and 
>>>>>>> bugs due to exceptions
>>>>>>> and other failures.
>>>>>>>
>>>>>>> In the case of TPE, the native resources are Threads, which keep 
>>>>>>> running even if they are
>>>>>>> unreferenced and are kept referenced via ThreadGroups.
>>>>>>> I don't know the Executor code well enough to do more than 
>>>>>>> speculate, but would suggest
>>>>>>> that a cleaner (or similar) should be registered for each thread .
>>>>>>
>>>>>> Threads are not native resources to be managed by Cleaners! A live 
>>>>>> Thread can never be cleaned. A dead thread has nothing to clean!
>>>>>
>>>>> Right, but an idle thread, waiting for a task that will never come 
>>>>> since the only entry point for submitting tasks is not reachable 
>>>>> (the pool), may be cleaned...
>>>>
>>>> cleaned? It can be interrupted if you know about it and find locate 
>>>> it. But it will not be eligible for cleaning ala Cleaner as it will 
>>>> always be strongly reachable.
>>>
>>> Ah I see what you meant before. Yes, tracking Thread object with a 
>>> Cleaner does not have any sense. But tracking thread pool object with 
>>> a Cleaner and cleaning (stopping) threads as a result makes sense...
>>
>> No, because live Threads will keep the thread pool strongly reachable.
>>
>> If you manage to structure things such that the Threads don't keep the 
>> pool strongly reachable then you risk having the pool cleaned while 
>> still actively in use.
> 
> Pool is actively in use when it is still reachable. Only in that case 
> can new tasks be submitted. When it is not reachable any more, no new 
> tasks can be submitted and it can be shutdown():
> 
>  ??? /**
>  ???? * Initiates an orderly shutdown in which previously submitted
>  ???? * tasks are executed, but no new tasks will be accepted...

Didn't we already determine that a Cleaner can't call shutdown() because 
that requires a strong reference it doesn't have?

I think Doug already summed this up. The existing finalize() is 
pointless because when it could be called there is nothing left to be 
"cleaned up". There's no need for any use of Cleaner (even if it could 
do anything useful).

David

> Regards, Peter
> 

From ivan.gerasimov at oracle.com  Thu Nov  2 03:26:05 2017
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 1 Nov 2017 20:26:05 -0700
Subject: [Bug][JDK10] Fix duplicated "a" occurrences in docs
In-Reply-To: <21f98480-6654-3a03-71cc-a1853f56a1c2@oracle.com>
References: <007701d35197$f6440200$e2cc0600$@freenet.de>
 <CA+kOe09K04HdXYJ1Vca3g7DfTLj=XLo44gj9R9QN7iRv=cHGAw@mail.gmail.com>
 <40cd4c5a-57eb-18de-0e18-d20cdfa416bd@oracle.com>
 <ee252e05-cea9-9d05-ba03-46a3ae6335c9@oracle.com>
 <21f98480-6654-3a03-71cc-a1853f56a1c2@oracle.com>
Message-ID: <61a9ca27-5c2d-e5a3-b0a4-9bd74a2e9e90@oracle.com>

If it's not too late, I'd lake to take part in this feast :)

Here's a handful of some more word duplicates:

http://cr.openjdk.java.net/~igerasim/double-trouble-2/00/webrev/

With kind regards,

Ivan


On 10/30/17 6:16 PM, Stuart Marks wrote:
> No, Roger checked in the "the the" patch before Christophe posted a "a 
> a" followup patch. :-)
>
> s'marks
>
> On 10/30/17 6:00 PM, David Holmes wrote:
>> Does this duplicate the the patch Christoph sent regarding the the? 
>> ;-) Roger was handling that one.
>>
>> David
>>
>> On 31/10/2017 10:29 AM, Stuart Marks wrote:
>>> Hi all,
>>>
>>> Please review the patch below. I'm sending this for review because 
>>> it's expanded considerably beyond the original patch that Christoph 
>>> had submitted. I ran a full-text search over the java.base source 
>>> files looking for "the the" and "a a" and it found a bunch of 
>>> additional occurrences that were split across line breaks. I also 
>>> fixed up a few other places that I happened to notice.
>>>
>>> Christoph wrote:
>>>> I wasn't sure about the capitalization change on EventObject. 
>>>> What's the
>>>> rule of thumb in cases where the class does not follow the 
>>>> guidelines for
>>>> docs[1]? Sticking to the overall class scheme or aligning everything?
>>>
>>> Good question. The first rule of styling is to stick with the 
>>> prevailing style in the file. In this case, changing just the text 
>>> of that one @return tag would have conflicted with the style in use 
>>> in the rest of the file, even though that style is arguably 
>>> incorrect; the rest of the file uses an initial capital and ends the 
>>> description with a period (full stop), whereas the recommended style 
>>> is to use a noun phrase (a sentence fragment), without an initial 
>>> capital, and without a trailing period (since there is no sentence 
>>> following).
>>>
>>> However, the file is small, and there were only three or four other 
>>> places that needed to be changed in order to bring the file into 
>>> compliance with the preferred style, so I just fixed them all.
>>>
>>>
>>> Thanks,
>>>
>>> s'marks
>>>
>>>
>>>
>>> # HG changeset patch
>>> # User smarks
>>> # Date 1509409127 25200
>>> #      Mon Oct 30 17:18:47 2017 -0700
>>> # Node ID d2823a0c8dfab9e95e5c482794a96864b2592aad
>>> # Parent  d87f89c74f54873f273c4fbd8e6d49d7cbf3930b
>>> 8190382: fix small typographic errors in comments
>>> Reviewed-by: XXX
>>> Contributed-by: christoph.dreis at freenet.de
>>>
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/io/FilePermission.java
>>> --- a/src/java.base/share/classes/java/io/FilePermission.java Mon 
>>> Oct 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/io/FilePermission.java Mon 
>>> Oct 30 17:18:47 2017 -0700
>>> @@ -698,7 +698,7 @@
>>>               if (p2.equals(EMPTY_PATH)) {
>>>                   return 0;
>>>               } else if (p2.getName(0).equals(DOTDOT_PATH)) {
>>> -                // "." contains p2 iif p2 has no "..". Since a
>>> +                // "." contains p2 iff p2 has no "..". Since
>>>                   // a normalized path can only have 0 or more
>>>                   // ".." at the beginning. We only need to look
>>>                   // at the head.
>>> @@ -711,7 +711,7 @@
>>>           } else if (p2.equals(EMPTY_PATH)) {
>>>               int c1 = p1.getNameCount();
>>>               if (!p1.getName(c1 - 1).equals(DOTDOT_PATH)) {
>>> -                // "." is inside p1 iif p1 is 1 or more "..".
>>> +                // "." is inside p1 iff p1 is 1 or more "..".
>>>                   // For the same reason above, we only need to
>>>                   // look at the tail.
>>>                   return -1;
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/lang/invoke/MethodHandle.java
>>> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandle.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandle.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -765,7 +765,7 @@
>>>        * In every other case, all conversions are applied 
>>> <em>pairwise</em>,
>>>        * which means that each argument or return value is converted to
>>>        * exactly one argument or return value (or no return value).
>>> -     * The applied conversions are defined by consulting the
>>> +     * The applied conversions are defined by consulting
>>>        * the corresponding component types of the old and new
>>>        * method handle types.
>>>        * <p>
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>>> --- 
>>> a/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ 
>>> b/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -194,7 +194,7 @@
>>>       static {
>>>           // In case we need to double-back onto the 
>>> StringConcatFactory during this
>>>           // static initialization, make sure we have the reasonable 
>>> defaults to complete
>>> -        // the static initialization properly. After that, actual 
>>> users would use the
>>> +        // the static initialization properly. After that, actual 
>>> users would use
>>>           // the proper values we have read from the properties.
>>>           STRATEGY = DEFAULT_STRATEGY;
>>>           // CACHE_ENABLE = false; // implied
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/lang/invoke/VarHandle.java
>>> --- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/lang/invoke/VarHandle.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -205,7 +205,7 @@
>>>    * and {@code double} on 32-bit platforms.
>>>    *
>>>    * <p>Access modes will override any memory ordering effects 
>>> specified at
>>> - * the declaration site of a variable.  For example, a VarHandle 
>>> accessing a
>>> + * the declaration site of a variable.  For example, a VarHandle 
>>> accessing
>>>    * a field using the {@code get} access mode will access the field as
>>>    * specified <em>by its access mode</em> even if that field is 
>>> declared
>>>    * {@code volatile}.  When mixed access is performed extreme care 
>>> should be
>>> @@ -423,7 +423,7 @@
>>>    * {@link java.lang.invoke.MethodHandles#varHandleInvoker}.
>>>    *
>>>    * <h1>Interoperation between VarHandles and Java generics</h1>
>>> - * A VarHandle can be obtained for a variable, such as a a field, 
>>> which is
>>> + * A VarHandle can be obtained for a variable, such as a field, 
>>> which is
>>>    * declared with Java generic types.  As with the Core Reflection 
>>> API, the
>>>    * VarHandle's variable type will be constructed from the erasure 
>>> of the
>>>    * source-level type.  When a VarHandle access mode method is 
>>> invoked, the
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/net/DatagramSocket.java
>>> --- a/src/java.base/share/classes/java/net/DatagramSocket.java Mon 
>>> Oct 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/net/DatagramSocket.java Mon 
>>> Oct 30 17:18:47 2017 -0700
>>> @@ -988,7 +988,7 @@
>>>
>>>       /**
>>>        * Sets the SO_RCVBUF option to the specified value for this
>>> -     * {@code DatagramSocket}. The SO_RCVBUF option is used by the
>>> +     * {@code DatagramSocket}. The SO_RCVBUF option is used by
>>>        * the network implementation as a hint to size the underlying
>>>        * network I/O buffers. The SO_RCVBUF setting may also be used
>>>        * by the network implementation to determine the maximum size
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/net/Inet4Address.java
>>> --- a/src/java.base/share/classes/java/net/Inet4Address.java Mon Oct 
>>> 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/net/Inet4Address.java Mon Oct 
>>> 30 17:18:47 2017 -0700
>>> @@ -143,7 +143,7 @@
>>>           /**
>>>            * Prior to 1.4 an InetAddress was created with a family
>>>            * based on the platform AF_INET value (usually 2).
>>> -         * For compatibility reasons we must therefore write the
>>> +         * For compatibility reasons we must therefore write
>>>            * the InetAddress with this family.
>>>            */
>>>           inet.holder().family = 2;
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/net/SocketImpl.java
>>> --- a/src/java.base/share/classes/java/net/SocketImpl.java Mon Oct 
>>> 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/net/SocketImpl.java Mon Oct 
>>> 30 17:18:47 2017 -0700
>>> @@ -333,7 +333,7 @@
>>>        * latency, and low latency above short connection time, then 
>>> it could
>>>        * invoke this method with the values {@code (0, 1, 2)}.
>>>        *
>>> -     * By default, this method does nothing, unless it is 
>>> overridden in a
>>> +     * By default, this method does nothing, unless it is 
>>> overridden in
>>>        * a sub-class.
>>>        *
>>>        * @param  connectionTime
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/net/SocksSocketImpl.java
>>> --- a/src/java.base/share/classes/java/net/SocksSocketImpl.java Mon 
>>> Oct 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/net/SocksSocketImpl.java Mon 
>>> Oct 30 17:18:47 2017 -0700
>>> @@ -657,7 +657,7 @@
>>>
>>>       /**
>>>        * Sends the Bind request to the SOCKS proxy. In the SOCKS 
>>> protocol, bind
>>> -     * means "accept incoming connection from", so the 
>>> SocketAddress is the
>>> +     * means "accept incoming connection from", so the 
>>> SocketAddress is
>>>        * the one of the host we do accept connection from.
>>>        *
>>>        * @param      saddr   the Socket address of the remote host.
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/net/URLConnection.java
>>> --- a/src/java.base/share/classes/java/net/URLConnection.java Mon 
>>> Oct 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/net/URLConnection.java Mon 
>>> Oct 30 17:18:47 2017 -0700
>>> @@ -785,7 +785,7 @@
>>>        * required to make the connection. By default, this method
>>>        * returns {@code java.security.AllPermission}. Subclasses
>>>        * should override this method and return the permission
>>> -     * that best represents the permission required to make a
>>> +     * that best represents the permission required to make
>>>        * a connection to the URL. For example, a {@code URLConnection}
>>>        * representing a {@code file:} URL would return a
>>>        * {@code java.io.FilePermission} object.
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java
>>> --- 
>>> a/src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ 
>>> b/src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -165,7 +165,7 @@
>>>        * <tr>
>>>        *   <th scope="row" > {@link 
>>> StandardOpenOption#DELETE_ON_CLOSE DELETE_ON_CLOSE} </th>
>>>        *   <td> When this option is present then the implementation 
>>> makes a
>>> -     *   <em>best effort</em> attempt to delete the file when 
>>> closed by the
>>> +     *   <em>best effort</em> attempt to delete the file when 
>>> closed by
>>>        *   the {@link #close close} method. If the {@code close} 
>>> method is not
>>>        *   invoked then a <em>best effort</em> attempt is made to 
>>> delete the file
>>>        *   when the Java virtual machine terminates. </td>
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/nio/channels/FileChannel.java
>>> --- a/src/java.base/share/classes/java/nio/channels/FileChannel.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/nio/channels/FileChannel.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -216,7 +216,7 @@
>>>        * <tr>
>>>        *   <th scope="row" > {@link 
>>> StandardOpenOption#DELETE_ON_CLOSE DELETE_ON_CLOSE} </th>
>>>        *   <td> When this option is present then the implementation 
>>> makes a
>>> -     *   <em>best effort</em> attempt to delete the file when 
>>> closed by the
>>> +     *   <em>best effort</em> attempt to delete the file when 
>>> closed by
>>>        *   the {@link #close close} method. If the {@code close} 
>>> method is not
>>>        *   invoked then a <em>best effort</em> attempt is made to 
>>> delete the file
>>>        *   when the Java virtual machine terminates. </td>
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/nio/file/Files.java
>>> --- a/src/java.base/share/classes/java/nio/file/Files.java Mon Oct 
>>> 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/nio/file/Files.java Mon Oct 
>>> 30 17:18:47 2017 -0700
>>> @@ -3301,7 +3301,7 @@
>>>       }
>>>
>>>       /**
>>> -     * Writes bytes to a file. The {@code options} parameter 
>>> specifies how the
>>> +     * Writes bytes to a file. The {@code options} parameter 
>>> specifies how
>>>        * the file is created or opened. If no options are present 
>>> then this method
>>>        * works as if the {@link StandardOpenOption#CREATE CREATE}, 
>>> {@link
>>>        * StandardOpenOption#TRUNCATE_EXISTING TRUNCATE_EXISTING}, 
>>> and {@link
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/security/KeyPairGenerator.java
>>> --- 
>>> a/src/java.base/share/classes/java/security/KeyPairGenerator.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ 
>>> b/src/java.base/share/classes/java/security/KeyPairGenerator.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -84,7 +84,7 @@
>>>    * exists (e.g., so-called <i>community parameters</i> in DSA), 
>>> there are two
>>>    * {@link #initialize(java.security.spec.AlgorithmParameterSpec)
>>>    * initialize} methods that have an {@code AlgorithmParameterSpec}
>>> - * argument. One also has a {@code SecureRandom} argument, while the
>>> + * argument. One also has a {@code SecureRandom} argument, while
>>>    * the other uses the {@code SecureRandom}
>>>    * implementation of the highest-priority installed provider as 
>>> the source
>>>    * of randomness. (If none of the installed providers supply an 
>>> implementation
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>>> --- 
>>> a/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ 
>>> b/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -4775,7 +4775,7 @@
>>> //----------------------------------------------------------------------- 
>>>
>>>       /**
>>>        * Prints or parses a localized pattern from a localized field.
>>> -     * The specific formatter and parameters is not selected until the
>>> +     * The specific formatter and parameters is not selected until
>>>        * the field is to be printed or parsed.
>>>        * The locale is needed to select the proper WeekFields from 
>>> which
>>>        * the field for day-of-week, week-of-month, or week-of-year 
>>> is selected.
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/time/temporal/WeekFields.java
>>> --- a/src/java.base/share/classes/java/time/temporal/WeekFields.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/time/temporal/WeekFields.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -311,7 +311,7 @@
>>>        * the new month or year.
>>>        * <p>
>>>        * WeekFields instances are singletons; for each unique 
>>> combination
>>> -     * of {@code firstDayOfWeek} and {@code minimalDaysInFirstWeek} 
>>> the
>>> +     * of {@code firstDayOfWeek} and {@code minimalDaysInFirstWeek}
>>>        * the same instance will be returned.
>>>        *
>>>        * @param firstDayOfWeek  the first day of the week, not null
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/util/Base64.java
>>> --- a/src/java.base/share/classes/java/util/Base64.java    Mon Oct 
>>> 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/util/Base64.java    Mon Oct 
>>> 30 17:18:47 2017 -0700
>>> @@ -56,7 +56,7 @@
>>>    *     base64 alphabet.</p></li>
>>>    *
>>>    * <li><a id="mime"><b>MIME</b></a>
>>> - * <p> Uses the "The Base64 Alphabet" as specified in Table 1 of
>>> + * <p> Uses "The Base64 Alphabet" as specified in Table 1 of
>>>    *     RFC 2045 for encoding and decoding operation. The encoded 
>>> output
>>>    *     must be represented in lines of no more than 76 characters 
>>> each
>>>    *     and uses a carriage return {@code '\r'} followed 
>>> immediately by
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/util/EventObject.java
>>> --- a/src/java.base/share/classes/java/util/EventObject.java Mon Oct 
>>> 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/util/EventObject.java Mon Oct 
>>> 30 17:18:47 2017 -0700
>>> @@ -43,13 +43,13 @@
>>>       /**
>>>        * The object on which the Event initially occurred.
>>>        */
>>> -    protected transient Object  source;
>>> +    protected transient Object source;
>>>
>>>       /**
>>>        * Constructs a prototypical Event.
>>>        *
>>> -     * @param    source    The object on which the Event initially 
>>> occurred.
>>> -     * @exception  IllegalArgumentException  if source is null.
>>> +     * @param source the object on which the Event initially occurred
>>> +     * @throws IllegalArgumentException if source is null
>>>        */
>>>       public EventObject(Object source) {
>>>           if (source == null)
>>> @@ -61,7 +61,7 @@
>>>       /**
>>>        * The object on which the Event initially occurred.
>>>        *
>>> -     * @return   The object on which the Event initially occurred.
>>> +     * @return the object on which the Event initially occurred
>>>        */
>>>       public Object getSource() {
>>>           return source;
>>> @@ -70,7 +70,7 @@
>>>       /**
>>>        * Returns a String representation of this EventObject.
>>>        *
>>> -     * @return  A a String representation of this EventObject.
>>> +     * @return a String representation of this EventObject
>>>        */
>>>       public String toString() {
>>>           return getClass().getName() + "[source=" + source + "]";
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/util/FormattableFlags.java
>>> --- a/src/java.base/share/classes/java/util/FormattableFlags.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/util/FormattableFlags.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -26,7 +26,7 @@
>>>   package java.util;
>>>
>>>   /**
>>> - * FomattableFlags are passed to the {@link Formattable#formatTo
>>> + * FormattableFlags are passed to the {@link Formattable#formatTo
>>>    * Formattable.formatTo()} method and modify the output format for 
>>> {@linkplain
>>>    * Formattable Formattables}.  Implementations of {@link 
>>> Formattable} are
>>>    * responsible for interpreting and validating any flags.
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/java/util/ResourceBundle.java
>>> --- a/src/java.base/share/classes/java/util/ResourceBundle.java Mon 
>>> Oct 30 07:06:49 2017 -0700
>>> +++ b/src/java.base/share/classes/java/util/ResourceBundle.java Mon 
>>> Oct 30 17:18:47 2017 -0700
>>> @@ -2743,7 +2743,7 @@
>>>            * of multiple subtags separated by underscore, generate 
>>> candidate
>>>            * <code>Locale</code>s by omitting the variant subtags 
>>> one by one, then
>>>            * insert them after every occurrence of <code> 
>>> Locale</code>s with the
>>> -         * full variant value in the original list.  For example, 
>>> if the
>>> +         * full variant value in the original list.  For example, if
>>>            * the variant consists of two subtags <em>V1</em> and 
>>> <em>V2</em>:
>>>            *
>>>            * <ul>
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java
>>> --- 
>>> a/src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ 
>>> b/src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -238,7 +238,7 @@
>>>       // This way we could simply do things like:
>>>       //    push((logger) -> logger.log(level, msg));
>>>       // Unfortunately, if we come to here it means we are in the 
>>> bootsraping
>>> -    // phase where using lambdas is not safe yet - so we have to use a
>>> +    // phase where using lambdas is not safe yet - so we have to use
>>>       // a data object instead...
>>>       //
>>>       static final class LogEvent {
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
>>> --- 
>>> a/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ 
>>> b/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -2888,7 +2888,7 @@
>>>               /*
>>>                * If we have an input stream this means we received a 
>>> response
>>>                * from the server. That stream may have been read to 
>>> EOF and
>>> -             * dependening on the stream type may already be closed 
>>> or the
>>> +             * depending on the stream type may already be closed or
>>>                * the http client may be returned to the keep-alive 
>>> cache.
>>>                * If the http client has been returned to the 
>>> keep-alive cache
>>>                * it may be closed (idle timeout) or may be allocated to
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java 
>>>
>>> --- 
>>> a/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ 
>>> b/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -66,7 +66,7 @@
>>>       /**
>>>        * Static factory. Given a (generic) class, actual type arguments
>>>        * and an owner type, creates a parameterized type.
>>> -     * This class can be instantiated with a a raw type that does not
>>> +     * This class can be instantiated with a raw type that does not
>>>        * represent a generic type, provided the list of actual type
>>>        * arguments is empty.
>>>        * If the ownerType argument is null, the declaring class of the
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java
>>> --- 
>>> a/src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ 
>>> b/src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -411,7 +411,7 @@
>>>                           certs = null;
>>>                       }
>>>
>>> -                    // only add if we had no signer or we had a
>>> +                    // only add if we had no signer or we had
>>>                       // a signer and found the keys for it.
>>>                       if (certs != null || pe.signedBy == null) {
>>>                               Permission perm = new 
>>> UnresolvedPermission(
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/sun/security/provider/PolicyFile.java
>>> --- 
>>> a/src/java.base/share/classes/sun/security/provider/PolicyFile.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ 
>>> b/src/java.base/share/classes/sun/security/provider/PolicyFile.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -789,7 +789,7 @@
>>>                           certs = null;
>>>                       }
>>>
>>> -                    // only add if we had no signer or we had a
>>> +                    // only add if we had no signer or we had
>>>                       // a signer and found the keys for it.
>>>                       if (certs != null || pe.signedBy == null) {
>>>                           Permission perm = new UnresolvedPermission(
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java 
>>>
>>> --- 
>>> a/src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ 
>>> b/src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -154,7 +154,7 @@
>>>        *
>>>        * @param codesource the <code>CodeSource</code> to compare 
>>> against.
>>>        *
>>> -     * @return true if this <code>SubjectCodeSource</code> implies the
>>> +     * @return true if this <code>SubjectCodeSource</code> implies
>>>        *          the specified <code>CodeSource</code>.
>>>        */
>>>       public boolean implies(CodeSource codesource) {
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java
>>> --- 
>>> a/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ 
>>> b/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -539,7 +539,7 @@
>>>
>>>                   // Should be repacked for suitable fragment length.
>>>                   //
>>> -                // Note that the acquiring processes will 
>>> reassemble the
>>> +                // Note that the acquiring processes will reassemble
>>>                   // the fragments later.
>>>                   return compareToSequence(o.recordEpoch, o.recordSeq);
>>>               }
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/sun/security/x509/X509CertImpl.java
>>> --- 
>>> a/src/java.base/share/classes/sun/security/x509/X509CertImpl.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ 
>>> b/src/java.base/share/classes/sun/security/x509/X509CertImpl.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -1485,7 +1485,7 @@
>>>       }
>>>
>>>       /**
>>> -     * Get the certificate constraints path length from the
>>> +     * Get the certificate constraints path length from
>>>        * the critical BasicConstraints extension, (oid = 2.5.29.19).
>>>        * @return the length of the constraint.
>>>        */
>>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>>> src/java.base/share/classes/sun/util/logging/PlatformLogger.java
>>> --- 
>>> a/src/java.base/share/classes/sun/util/logging/PlatformLogger.java 
>>> Mon Oct 30 07:06:49 2017 -0700
>>> +++ 
>>> b/src/java.base/share/classes/sun/util/logging/PlatformLogger.java 
>>> Mon Oct 30 17:18:47 2017 -0700
>>> @@ -45,7 +45,7 @@
>>>    *
>>>    * If the logging facility is not enabled, the platform loggers
>>>    * will output log messages per the default logging configuration
>>> - * (see below). In this implementation, it does not log the
>>> + * (see below). In this implementation, it does not log
>>>    * the stack frame information issuing the log message.
>>>    *
>>>    * When the logging facility is enabled (at startup or runtime),
>>>

-- 
With kind regards,
Ivan Gerasimov


From felix.yang at oracle.com  Thu Nov  2 03:36:23 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Thu, 2 Nov 2017 11:36:23 +0800
Subject: RFR 8190505, typo in test/jdk/ProblemList.txt
Message-ID: <aec800fb-80ba-16e5-d52b-ac98e7e33035@oracle.com>

Please review a minor patch to correct typo in test/jdk/ProblemList.txt. 
Change "Hashmap" to "HashMap".

diff -r 4a35a00eb001 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt??? Wed Nov 01 16:45:28 2017 +0100
+++ b/test/jdk/ProblemList.txt??? Wed Nov 01 23:34:44 2017 -0400
@@ -320,7 +320,7 @@

 ?org/omg/CORBA/OrbPropertiesTest.java??? ??? ??? ??????? 8175177 
generic-all

-javax/rmi/PortableRemoteObject/ConcurrentHashmapTest.java 8080643 
generic-all
+javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java 8080643 
generic-all

 ?javax/rmi/ssl/SSLSocketParametersTest.sh 8162906 generic-all


Issue: https://bugs.openjdk.java.net/browse/JDK-8190505

Thanks,

Felix


From Alan.Bateman at oracle.com  Thu Nov  2 08:16:33 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 Nov 2017 08:16:33 +0000
Subject: RFR 8190505, typo in test/jdk/ProblemList.txt
In-Reply-To: <aec800fb-80ba-16e5-d52b-ac98e7e33035@oracle.com>
References: <aec800fb-80ba-16e5-d52b-ac98e7e33035@oracle.com>
Message-ID: <aee4bbdb-b33b-5676-7271-1810a15c1ead@oracle.com>

+1

On 02/11/2017 03:36, Felix Yang wrote:
> Please review a minor patch to correct typo in 
> test/jdk/ProblemList.txt. Change "Hashmap" to "HashMap".
>
> diff -r 4a35a00eb001 test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt??? Wed Nov 01 16:45:28 2017 +0100
> +++ b/test/jdk/ProblemList.txt??? Wed Nov 01 23:34:44 2017 -0400
> @@ -320,7 +320,7 @@
>
> ?org/omg/CORBA/OrbPropertiesTest.java??? ??? ??? ??????? 8175177 
> generic-all
>
> -javax/rmi/PortableRemoteObject/ConcurrentHashmapTest.java 8080643 
> generic-all
> +javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java 8080643 
> generic-all
>
> ?javax/rmi/ssl/SSLSocketParametersTest.sh 8162906 generic-all
>
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8190505
>
> Thanks,
>
> Felix
>


From Alan.Bateman at oracle.com  Thu Nov  2 08:19:04 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 Nov 2017 08:19:04 +0000
Subject: [Bug][JDK10] Fix duplicated "a" occurrences in docs
In-Reply-To: <61a9ca27-5c2d-e5a3-b0a4-9bd74a2e9e90@oracle.com>
References: <007701d35197$f6440200$e2cc0600$@freenet.de>
 <CA+kOe09K04HdXYJ1Vca3g7DfTLj=XLo44gj9R9QN7iRv=cHGAw@mail.gmail.com>
 <40cd4c5a-57eb-18de-0e18-d20cdfa416bd@oracle.com>
 <ee252e05-cea9-9d05-ba03-46a3ae6335c9@oracle.com>
 <21f98480-6654-3a03-71cc-a1853f56a1c2@oracle.com>
 <61a9ca27-5c2d-e5a3-b0a4-9bd74a2e9e90@oracle.com>
Message-ID: <acdd5004-9fd6-8ac5-f339-e95627c56989@oracle.com>



On 02/11/2017 03:26, Ivan Gerasimov wrote:
> If it's not too late, I'd lake to take part in this feast :)
>
> Here's a handful of some more word duplicates:
>
> http://cr.openjdk.java.net/~igerasim/double-trouble-2/00/webrev/ 
> ????????? /**
Looks good, how many times have you done this :-)

From zheng.jun.li at oracle.com  Thu Nov  2 08:34:58 2017
From: zheng.jun.li at oracle.com (Jack Li)
Date: Thu, 2 Nov 2017 16:34:58 +0800
Subject: RFR: 8187954 Update JAX-WS RI integration to latest version
In-Reply-To: <A6E211A7-10B2-4242-939E-F6CEB6BFC726@oracle.com>
References: <12668CC3-A8DB-4BDC-9F21-5068CA559DA8@oracle.com>
 <DE008EE6-ABC3-455F-85D0-C83239CD4622@oracle.com>
 <A9736FE3-E30D-4EDD-839F-6FFAB6A4BF38@oracle.com>
 <B53D7902-137F-4082-930F-713D427E3CDF@oracle.com>
 <95066DA9-03A6-4BF1-8895-6A442548EC60@oracle.com>
 <50F96A1B-78C3-4FC4-82E5-691E06749F29@oracle.com>
 <A6E211A7-10B2-4242-939E-F6CEB6BFC726@oracle.com>
Message-ID: <68A33758-0DA4-4B8A-8692-2A382AC63652@oracle.com>

Hi Lance

Is there anything wrong in the new webrev?


> On Oct 25, 2017, at 10:00, Jack Li <zheng.jun.li at oracle.com> wrote:
> 
> Hi Lance,
> 
> The webrev is updated, can you please review it again?
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> 
> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01 <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01>
> 
> Summary of changes:
> 
> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
> 
> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
> And also contains the fixes for importing nodes for SOAPDocumentFragment
> 
> 
> Patch also contains several small bugfixes, not tracked in JBS.
> 
>> On Oct 11, 2017, at 18:47, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>> 
>> Hi Jack,
>> 
>> I would prefer to see an updated webrev so that we do not inadvertently
>> push these changes.
>> 
>> Best
>> Lance
>>> On Oct 11, 2017, at 3:26 AM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>> 
>>> Hi Lance
>>> 
>>> I will update them in Metro repository, do I need to regenerate webrev?
>>> or can you skip the files this time and I fix it in next integration?
>>> 
>>>> On Oct 9, 2017, at 19:35, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>>>> 
>>>> Hi Jack,
>>>> 
>>>> UnMarshaller also has the same issue.  I would update the webrev given the number of places to help sanity check for omissions
>>>> 
>>>> Best
>>>> Lance
>>>>> On Oct 8, 2017, at 9:22 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>>> 
>>>>> Hi Lance,
>>>>> 
>>>>> the change is incorrect, it should be ?javax/xml/bind?.
>>>>> thanks a lot for your finding, do you think I need to fix it and resubmit the webrev this time?
>>>>> or can you skip this file this time and I fix it in next integration?
>>>>> 
>>>>>> On Oct 4, 2017, at 02:09, Lance Andersen <Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>> wrote:
>>>>>> 
>>>>>> Hi Jack,
>>>>>> 
>>>>>> Is this change correct:
>>>>>> 
>>>>>> -------------
>>>>>> --- old/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.968185273 +0100
>>>>>> +++ new/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.676185267 +0100
>>>>>> @@ -373,7 +373,7 @@
>>>>>>       *      If the {@link ValidationEventHandler ValidationEventHandler}
>>>>>>       *      returns false from its {@code handleEvent} method or the
>>>>>>       *      {@code Marshaller} is unable to marshal {@code jaxbElement} (or any
>>>>>> -     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/javax/xml/bind/Marshaller.html#elementMarshalling">
>>>>>> +     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/java/xml/bind/Marshaller.html#elementMarshalling">
>>>>>>       *      Marshalling a JAXB element</a>.
>>>>>> 
>>>>>> ------------
>>>>>> 
>>>>>> The URL that is being changed currently works
>>>>>> 
>>>>>> Best
>>>>>> Lance
>>>>>> On Sep 29, 2017, at 10:55 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>>>>> 
>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>>
>>>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>>
>>>>>>> 
>>>>>>> Summary of changes:
>>>>>>> 
>>>>>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>>>>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>>>>>> 
>>>>>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>>>>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>>>>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>>>>>> 
>>>>>>> 
>>>>>>> Patch also contains several small bugfixes, not tracked in JBS.
>>>>>>> 
>>>>>>> ----------------
>>>>>>> Best regards
>>>>>>> Jack Li
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> <oracle_sig_logo.gif>
>>>>>> 
>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>> Oracle?Java Engineering?
>>>>>> 1 Network Drive?
>>>>>> Burlington, MA 01803
>>>>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>>> 
>>>>> ----------------
>>>>> Best regards
>>>>> Jack Li
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle Java Engineering 
>>>> 1 Network Drive 
>>>> Burlington, MA 01803
>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> ----------------
>>> Best regards
>>> Jack Li
>> 
>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>> 
>> 
>> 
> 
> 
> ----------------
> Best regards
> Jack Li
> 
> 
> 
> 
> 
> 


----------------
Best regards
Jack Li







From peter.levart at gmail.com  Thu Nov  2 09:26:58 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 2 Nov 2017 10:26:58 +0100
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <c4ddb1aa-c115-560b-419e-6742257a4416@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
 <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
 <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>
 <e83dd002-89a5-1e03-9593-dc09a1db3d66@oracle.com>
 <6db5bef5-e373-709e-edf6-de2a312020da@gmail.com>
 <c4ddb1aa-c115-560b-419e-6742257a4416@oracle.com>
Message-ID: <792aa967-d3b0-a461-7647-84a4ece34a72@gmail.com>



On 11/02/2017 03:34 AM, David Holmes wrote:
>
>
> On 2/11/2017 3:46 AM, Peter Levart wrote:
>>
>>
>> On 11/01/17 13:34, David Holmes wrote:
>>> On 1/11/2017 10:20 PM, Peter Levart wrote:
>>>> On 11/01/17 10:04, David Holmes wrote:
>>>>> On 1/11/2017 6:16 PM, Peter Levart wrote:
>>>>>> On 11/01/17 02:49, David Holmes wrote:
>>>>>>> Hi Roger,
>>>>>>>
>>>>>>> On 31/10/2017 11:58 PM, Roger Riggs wrote:
>>>>>>>> Hi Peter,
>>>>>>>>
>>>>>>>> Only native resources that do not map to the heap allocation/gc 
>>>>>>>> cycle need any kind
>>>>>>>> of cleanup.? I would work toward a model that encapsulates the 
>>>>>>>> reference to a native resource
>>>>>>>> with a corresponding allocation/release mechanism as you've 
>>>>>>>> described here and in the
>>>>>>>> thread on zip.
>>>>>>>>
>>>>>>>> For cleanup purposes, the independence of each resource may 
>>>>>>>> improve robustness
>>>>>>>> by avoiding dependencies and opportunities for entanglements 
>>>>>>>> and bugs due to exceptions
>>>>>>>> and other failures.
>>>>>>>>
>>>>>>>> In the case of TPE, the native resources are Threads, which 
>>>>>>>> keep running even if they are
>>>>>>>> unreferenced and are kept referenced via ThreadGroups.
>>>>>>>> I don't know the Executor code well enough to do more than 
>>>>>>>> speculate, but would suggest
>>>>>>>> that a cleaner (or similar) should be registered for each thread .
>>>>>>>
>>>>>>> Threads are not native resources to be managed by Cleaners! A 
>>>>>>> live Thread can never be cleaned. A dead thread has nothing to 
>>>>>>> clean!
>>>>>>
>>>>>> Right, but an idle thread, waiting for a task that will never 
>>>>>> come since the only entry point for submitting tasks is not 
>>>>>> reachable (the pool), may be cleaned...
>>>>>
>>>>> cleaned? It can be interrupted if you know about it and find 
>>>>> locate it. But it will not be eligible for cleaning ala Cleaner as 
>>>>> it will always be strongly reachable.
>>>>
>>>> Ah I see what you meant before. Yes, tracking Thread object with a 
>>>> Cleaner does not have any sense. But tracking thread pool object 
>>>> with a Cleaner and cleaning (stopping) threads as a result makes 
>>>> sense...
>>>
>>> No, because live Threads will keep the thread pool strongly reachable.
>>>
>>> If you manage to structure things such that the Threads don't keep 
>>> the pool strongly reachable then you risk having the pool cleaned 
>>> while still actively in use.
>>
>> Pool is actively in use when it is still reachable. Only in that case 
>> can new tasks be submitted. When it is not reachable any more, no new 
>> tasks can be submitted and it can be shutdown():
>>
>> ???? /**
>> ????? * Initiates an orderly shutdown in which previously submitted
>> ????? * tasks are executed, but no new tasks will be accepted...
>
> Didn't we already determine that a Cleaner can't call shutdown() 
> because that requires a strong reference it doesn't have?

It can't call shutdown() on a tracked pool object, but it could do 
something that acted equivalently as shutdown().

>
> I think Doug already summed this up. The existing finalize() is 
> pointless because when it could be called there is nothing left to be 
> "cleaned up". There's no need for any use of Cleaner (even if it could 
> do anything useful).

There's no need for finalize() or Cleaner in existing TPE as is, I 
agree. But there could be a thread pool that would self-shutdown when it 
is of no use any more (either using finalize() or Cleaner). For example, 
here is such pool:

public class CleanableExecutorService implements ExecutorService {
 ??? private final ThreadPoolExecutor tpe;

 ??? public CleanableExecutorService(ThreadPoolExecutor tpe) {
 ??????? CleanerFactory.cleaner().register(this, tpe::shutdown);
 ??????? this.tpe = tpe;
 ??? }

 ??? // implement and delegate all ExecutorService methods to tpe...
}

Regards, Peter

>
> David


From lance.andersen at oracle.com  Thu Nov  2 11:34:56 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 2 Nov 2017 07:34:56 -0400
Subject: RFR: 8187954 Update JAX-WS RI integration to latest version
In-Reply-To: <68A33758-0DA4-4B8A-8692-2A382AC63652@oracle.com>
References: <12668CC3-A8DB-4BDC-9F21-5068CA559DA8@oracle.com>
 <DE008EE6-ABC3-455F-85D0-C83239CD4622@oracle.com>
 <A9736FE3-E30D-4EDD-839F-6FFAB6A4BF38@oracle.com>
 <B53D7902-137F-4082-930F-713D427E3CDF@oracle.com>
 <95066DA9-03A6-4BF1-8895-6A442548EC60@oracle.com>
 <50F96A1B-78C3-4FC4-82E5-691E06749F29@oracle.com>
 <A6E211A7-10B2-4242-939E-F6CEB6BFC726@oracle.com>
 <68A33758-0DA4-4B8A-8692-2A382AC63652@oracle.com>
Message-ID: <BB9DBC59-0733-42FB-9D0A-27B1C06F555C@oracle.com>

Hi Jack

Its on my list to finish by the end of the week. 

Best
Lance
> On Nov 2, 2017, at 4:34 AM, Jack Li <zheng.jun.li at oracle.com> wrote:
> 
> Hi Lance
> 
> Is there anything wrong in the new webrev?
> 
> 
>> On Oct 25, 2017, at 10:00, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>> 
>> Hi Lance,
>> 
>> The webrev is updated, can you please review it again?
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> 
>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01 <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01>
>> 
>> Summary of changes:
>> 
>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>> 
>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>> 
>> 
>> Patch also contains several small bugfixes, not tracked in JBS.
>> 
>>> On Oct 11, 2017, at 18:47, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>>> 
>>> Hi Jack,
>>> 
>>> I would prefer to see an updated webrev so that we do not inadvertently
>>> push these changes.
>>> 
>>> Best
>>> Lance
>>>> On Oct 11, 2017, at 3:26 AM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>> 
>>>> Hi Lance
>>>> 
>>>> I will update them in Metro repository, do I need to regenerate webrev?
>>>> or can you skip the files this time and I fix it in next integration?
>>>> 
>>>>> On Oct 9, 2017, at 19:35, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>>>>> 
>>>>> Hi Jack,
>>>>> 
>>>>> UnMarshaller also has the same issue.  I would update the webrev given the number of places to help sanity check for omissions
>>>>> 
>>>>> Best
>>>>> Lance
>>>>>> On Oct 8, 2017, at 9:22 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>>>> 
>>>>>> Hi Lance,
>>>>>> 
>>>>>> the change is incorrect, it should be ?javax/xml/bind?.
>>>>>> thanks a lot for your finding, do you think I need to fix it and resubmit the webrev this time?
>>>>>> or can you skip this file this time and I fix it in next integration?
>>>>>> 
>>>>>>> On Oct 4, 2017, at 02:09, Lance Andersen <Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>> wrote:
>>>>>>> 
>>>>>>> Hi Jack,
>>>>>>> 
>>>>>>> Is this change correct:
>>>>>>> 
>>>>>>> -------------
>>>>>>> --- old/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.968185273 +0100
>>>>>>> +++ new/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.676185267 +0100
>>>>>>> @@ -373,7 +373,7 @@
>>>>>>>       *      If the {@link ValidationEventHandler ValidationEventHandler}
>>>>>>>       *      returns false from its {@code handleEvent} method or the
>>>>>>>       *      {@code Marshaller} is unable to marshal {@code jaxbElement} (or any
>>>>>>> -     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/javax/xml/bind/Marshaller.html#elementMarshalling">
>>>>>>> +     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/java/xml/bind/Marshaller.html#elementMarshalling">
>>>>>>>       *      Marshalling a JAXB element</a>.
>>>>>>> 
>>>>>>> ------------
>>>>>>> 
>>>>>>> The URL that is being changed currently works
>>>>>>> 
>>>>>>> Best
>>>>>>> Lance
>>>>>>> On Sep 29, 2017, at 10:55 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>>>>>> 
>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>>
>>>>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>>
>>>>>>>> 
>>>>>>>> Summary of changes:
>>>>>>>> 
>>>>>>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>>>>>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>>>>>>> 
>>>>>>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>>>>>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>>>>>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Patch also contains several small bugfixes, not tracked in JBS.
>>>>>>>> 
>>>>>>>> ----------------
>>>>>>>> Best regards
>>>>>>>> Jack Li
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> <oracle_sig_logo.gif>
>>>>>>> 
>>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>> Oracle?Java Engineering?
>>>>>>> 1 Network Drive?
>>>>>>> Burlington, MA 01803
>>>>>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>>>> 
>>>>>> ----------------
>>>>>> Best regards
>>>>>> Jack Li
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>> Oracle Java Engineering 
>>>>> 1 Network Drive 
>>>>> Burlington, MA 01803
>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> ----------------
>>>> Best regards
>>>> Jack Li
>>> 
>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering 
>>> 1 Network Drive 
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>> 
>>> 
>>> 
>> 
>> 
>> ----------------
>> Best regards
>> Jack Li
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> ----------------
> Best regards
> Jack Li
> 
> 
> 
> 
> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From peter.levart at gmail.com  Thu Nov  2 12:31:05 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 2 Nov 2017 13:31:05 +0100
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <d02cf931-6bd4-3b99-3375-dbce6e8047c8@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <CAE+3fjYzgEMmFFOge6hdN9wi3qS=5OCTKJKupeLbf-gaaPf9eQ@mail.gmail.com>
 <d02cf931-6bd4-3b99-3375-dbce6e8047c8@oracle.com>
Message-ID: <2a20565b-83f5-a39d-8b31-ac70c64ff8b9@gmail.com>

Hi,

On 11/02/2017 12:51 AM, Stuart Marks wrote:
> On 11/1/17 10:45 AM, Tagir Valeev wrote:
>> Set.of:
>>
>> +??????? if (coll instanceof 
>> ImmutableCollections.AbstractImmutableSet) {
>> +??????????? return (Set<E>)coll;
>> +??????? } else {
>> +??????????? return (Set<E>)Set.of(coll.stream().distinct().toArray());
>>
>> I think that good old Set.of(new HashSet<>(coll).toArray()) would
>> produce less garbage. distinct() also maintains HashSet internally,
>> but it removes the SIZED characteristic, so instead of preallocated
>> array you will have a SpinedBuffer which is less efficient than
>> AbstractCollection.toArray() implementation which just allocates the
>> array of exact size. What do you think?
>
> Oh yes, good point. I had initially used stream().distinct() because I 
> wanted to use distinct()'s semantics of preserving the first equal 
> element among duplicates. But since I removed that requirement from 
> the spec, using a HashSet as you suggest is much simpler. 

Why not using:

 ??? coll.stream().collect(Collectors.toImmutableSet())

As Collectors.toImmutableSet() is currently implemented, with serial 
Stream it will create a single HashSet, add all the elements to it and 
call Set.of(HashSet.toArray()) with it. Pretty much the same as what 
Tagir proposes, but the Collector could be made more efficient in the 
future and with it, the optimization would automatically extend to 
Set.copyOf()...

Regards, Peter


From david.holmes at oracle.com  Thu Nov  2 12:47:25 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 2 Nov 2017 22:47:25 +1000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <792aa967-d3b0-a461-7647-84a4ece34a72@gmail.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
 <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
 <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>
 <e83dd002-89a5-1e03-9593-dc09a1db3d66@oracle.com>
 <6db5bef5-e373-709e-edf6-de2a312020da@gmail.com>
 <c4ddb1aa-c115-560b-419e-6742257a4416@oracle.com>
 <792aa967-d3b0-a461-7647-84a4ece34a72@gmail.com>
Message-ID: <ce05cb58-0504-4af1-44e5-e7a54295f8e3@oracle.com>

On 2/11/2017 7:26 PM, Peter Levart wrote:
> On 11/02/2017 03:34 AM, David Holmes wrote:
>> On 2/11/2017 3:46 AM, Peter Levart wrote:
>>> On 11/01/17 13:34, David Holmes wrote:
>>>> On 1/11/2017 10:20 PM, Peter Levart wrote:
>>>>> On 11/01/17 10:04, David Holmes wrote:
>>>>>> On 1/11/2017 6:16 PM, Peter Levart wrote:
>>>>>>> On 11/01/17 02:49, David Holmes wrote:
>>>>>>>> Hi Roger,
>>>>>>>>
>>>>>>>> On 31/10/2017 11:58 PM, Roger Riggs wrote:
>>>>>>>>> Hi Peter,
>>>>>>>>>
>>>>>>>>> Only native resources that do not map to the heap allocation/gc 
>>>>>>>>> cycle need any kind
>>>>>>>>> of cleanup.? I would work toward a model that encapsulates the 
>>>>>>>>> reference to a native resource
>>>>>>>>> with a corresponding allocation/release mechanism as you've 
>>>>>>>>> described here and in the
>>>>>>>>> thread on zip.
>>>>>>>>>
>>>>>>>>> For cleanup purposes, the independence of each resource may 
>>>>>>>>> improve robustness
>>>>>>>>> by avoiding dependencies and opportunities for entanglements 
>>>>>>>>> and bugs due to exceptions
>>>>>>>>> and other failures.
>>>>>>>>>
>>>>>>>>> In the case of TPE, the native resources are Threads, which 
>>>>>>>>> keep running even if they are
>>>>>>>>> unreferenced and are kept referenced via ThreadGroups.
>>>>>>>>> I don't know the Executor code well enough to do more than 
>>>>>>>>> speculate, but would suggest
>>>>>>>>> that a cleaner (or similar) should be registered for each thread .
>>>>>>>>
>>>>>>>> Threads are not native resources to be managed by Cleaners! A 
>>>>>>>> live Thread can never be cleaned. A dead thread has nothing to 
>>>>>>>> clean!
>>>>>>>
>>>>>>> Right, but an idle thread, waiting for a task that will never 
>>>>>>> come since the only entry point for submitting tasks is not 
>>>>>>> reachable (the pool), may be cleaned...
>>>>>>
>>>>>> cleaned? It can be interrupted if you know about it and find 
>>>>>> locate it. But it will not be eligible for cleaning ala Cleaner as 
>>>>>> it will always be strongly reachable.
>>>>>
>>>>> Ah I see what you meant before. Yes, tracking Thread object with a 
>>>>> Cleaner does not have any sense. But tracking thread pool object 
>>>>> with a Cleaner and cleaning (stopping) threads as a result makes 
>>>>> sense...
>>>>
>>>> No, because live Threads will keep the thread pool strongly reachable.
>>>>
>>>> If you manage to structure things such that the Threads don't keep 
>>>> the pool strongly reachable then you risk having the pool cleaned 
>>>> while still actively in use.
>>>
>>> Pool is actively in use when it is still reachable. Only in that case 
>>> can new tasks be submitted. When it is not reachable any more, no new 
>>> tasks can be submitted and it can be shutdown():
>>>
>>> ???? /**
>>> ????? * Initiates an orderly shutdown in which previously submitted
>>> ????? * tasks are executed, but no new tasks will be accepted...
>>
>> Didn't we already determine that a Cleaner can't call shutdown() 
>> because that requires a strong reference it doesn't have?
> 
> It can't call shutdown() on a tracked pool object, but it could do 
> something that acted equivalently as shutdown().
> 
>>
>> I think Doug already summed this up. The existing finalize() is 
>> pointless because when it could be called there is nothing left to be 
>> "cleaned up". There's no need for any use of Cleaner (even if it could 
>> do anything useful).
> 
> There's no need for finalize() or Cleaner in existing TPE as is, I 
> agree. But there could be a thread pool that would self-shutdown when it 
> is of no use any more (either using finalize() or Cleaner). For example, 
> here is such pool:
> 
> public class CleanableExecutorService implements ExecutorService {
>  ??? private final ThreadPoolExecutor tpe;
> 
>  ??? public CleanableExecutorService(ThreadPoolExecutor tpe) {
>  ??????? CleanerFactory.cleaner().register(this, tpe::shutdown);
>  ??????? this.tpe = tpe;
>  ??? }
> 
>  ??? // implement and delegate all ExecutorService methods to tpe...
> }

Ah I see - the old "extra level of indirection" solution. :) The Cleaner 
keeps the tpe strongly reachable, but as soon as the holder class 
becomes "unreachable" the Cleaner will shutdown the tpe.

Though if you plan on abandoning a TPE such that you can't shutdown 
directly, then you may as well just configure it so all the threads 
terminate and it will "self-clean".

Cheers,
David

> Regards, Peter
> 
>>
>> David
> 

From Alan.Bateman at oracle.com  Thu Nov  2 13:52:02 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 Nov 2017 13:52:02 +0000
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
Message-ID: <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>

On 01/11/2017 14:57, Patrick Reinhart wrote:
> I tried to put that in my latest proposal:
>
> /**
>  ?* Reads all characters from this readable and writes the characters to
>  ?* the given appendable in the order that they are read. On return, this
>  ?* readable will be at end its data.
You might want to try using? "this source" in the wording, as in "On 
return, the source of characters will be at its end". I think this will 
make it a bit more consistent with the existing wording in the read method.

>  ?* <p>
>  ?* This method may block indefinitely reading from the readable, or
>  ?* writing to the appendable. The behavior for the case where the readable
>  ?* and/or appendable is <i>asynchronously closed</i>, or the thread
>  ?* interrupted during the transfer, is highly readable and appendable
>  ?* specific, and therefore not specified.
I think this needs more setup to allow for close, maybe "Where this 
source or the appendable is {@link AutoCloseable closeable} then the 
behavior when either are asynchronously closed ...".


>  ?*
>  ?* @since 18.3
>
We're using "@since 10" for now, pending an outcome of the version 
string discussion.

-Alan

From chris.w.dennis at gmail.com  Thu Nov  2 14:21:32 2017
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Thu, 2 Nov 2017 10:21:32 -0400
Subject: Confusion (or bugs) regarding the 'UNORDERED' Collector
 Characteristic
In-Reply-To: <c9d0365e-d3b1-f890-00ff-14674094be40@oracle.com>
References: <A00CF5D4-7F22-45C0-A032-B339E9CC8DBF@gmail.com>
 <c9d0365e-d3b1-f890-00ff-14674094be40@oracle.com>
Message-ID: <F1DC47B3-00B2-4EA3-95F6-167AF5724239@gmail.com>

I can buy the argument with toSet, I mainly pointed it out because to me the arguments for the numerical collectors being unordered (ignoring the floating point complication of double streams) are much stronger, so it struck me as strange that toSet was the only thing flagged as unordered.  Can we consider the other collectors missing the unordered attirbute attribute to be a bug then, and get it fixed for 10?

> On Nov 1, 2017, at 3:55 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> On 10/27/17 1:56 PM, Chris Dennis wrote:
>> I?m very confused about what was intended with the ?UNORDERED? Collector characteristic.  My logical inference was that unordered as a Collector characteristic meant that the result of this collector applied to any stream was independent of the order of element delivery.  This means that the stream backend could safely elide any ordered characteristic of the stream driving the collector and open up more possible execution pathways (parallelism for example).  The javadoc for unordered is two sentences:
>> /**
>>  * Indicates that the collection operation does not commit to preserving
>>  * the encounter order of input elements.  (This might be true if the
>>  * result container has no intrinsic order, such as a {@link Set}.)
>>  */
>> The first sentence makes sense, although it is phrased in a way that also explains the behavior seen if you flag an order sensitive collector as unordered.  The second sentence is weird, it implies a relation between collectors, encounter order, and an inherent ordering or iteration order of a collection object that might be the target of a collection. To me the important property of a Collection object with regards to ordering of a Collector that fills it is whether reordering the insertions to the collection can change the resultant state, for a Set this is clearly true since only the first presented element that is equal will be stored.
> 
> I think you need to be very careful making any assumptions about which of equal elements will end up in a set. Consider the spec of Set.addAll:
> 
>    Adds all of the elements in the specified collection to this set
>    if they're not already present.
> 
> Suppose the source collection has several non-identical elements that are equal to each other. This says nothing about which of them is preserved, and indeed there is no mention whatsoever about the identity of equal objects. The entire Set spec is defined in terms of equals, not identity. So I think it's mistaken to assume that the first of equal but non-identical objects will be stored.
> 
> (This is also the reason I changed the specification of Set.copyOf in my recent draft, to remove the requirement that the first such element be preserved. Set.addAll and Collectors.toSet make no such stipulation.)
> 
>> There is also a paragraph in the Collector javadoc:
>> * <p>For collectors that do not have the {@code UNORDERED} characteristic,
>> * two accumulated results {@code a1} and {@code a2} are equivalent if
>> * {@code finisher.apply(a1).equals(finisher.apply(a2))}.  For unordered
>> * collectors, equivalence is relaxed to allow for non-equality related to
>> * differences in order.  (For example, an unordered collector that accumulated
>> * elements to a {@code List} would consider two lists equivalent if they
>> * contained the same elements, ignoring order.)
>> This seems weird, why would we try to define correctness of a parallel reduction against a collector that was sensitive to ordering.
> 
> This is indeed a bit odd, but it makes sense. You might have a collector that collects into a List, because you want to collect duplicates. But you might not actually care about the order; you just want all the elements. The fact that List stores elements in some order is irrelevant. In this case such a collector would quite reasonably have the UNORDERED characteristic.
> 
>> Finally, when investigating the properties of the collectors returned from the Collectors static factory I was surprised to discover that none of the collectors that are truly unordered were marked as such (counting, min, max, averaging, summing, summarizing), and the only collector that was marked as unordered was Collectors.toSet(), which although it is explicitly marked as unordered seems like it really shouldn?t be.
>> Whats going on here?  Which parts of all this are intended and which (if any) are bugs?
> 
> Well I think it does make sense for the toSet() collector to be UNORDERED. It may be the case, though, that other collectors are lacking the UNORDERED characteristic that they should have. That sounds like it might be a bug.
> 
> s'marks
> 
> 
>> Thanks in advance for any enlightenment,
>> Chris Dennis
>> P.S. Coincidentally the unordered toSet() collector works perfectly at the moment due to the happy interaction of the Spliterator.trySplit() contract and the folding/combining behavior of the stream implementations parallel reduction algorithm.


From chris.w.dennis at gmail.com  Thu Nov  2 14:24:15 2017
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Thu, 2 Nov 2017 10:24:15 -0400
Subject: RFR Re: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <BA7001C8-479A-4669-9EA3-74250DF7196B@oracle.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <DF5459F9-D1F9-4E54-8543-43FFB2BF4341@gmail.com>
 <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>
 <59F7C175.7010705@oracle.com>
 <11BAC038-0D59-467C-AE0B-212049E5E46B@oracle.com>
 <f09eee75-39f2-b8cc-a95e-29e5be9c3b7e@oracle.com>
 <BA7001C8-479A-4669-9EA3-74250DF7196B@oracle.com>
Message-ID: <CC1C3541-4281-4984-B82B-6853D2664DC3@gmail.com>

Just to confirm this looks fine to me. From my point of view too much input validation would seem a little odd given that the implementation does nothing to protect itself from overflow in the first place.


> On Nov 1, 2017, at 1:21 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 
>> On 31 Oct 2017, at 16:46, joe darcy <joe.darcy at oracle.com> wrote:
>>>> 
>>> In that case we need to double (sorry) down on the NaNs and include sum as well:
>>> 
>>> *   <li>{@code (min <= max && !isNaN(sum)) || (isNaN(min) && isNaN(max) && isNaN(sum))}
>> 
>> A more complete test for the numerical consistency conditions would be something like
>> 
>>   min <= sum/count  <= max
>> 
>> However, that would require a bit of thought due to potential round-off so this might not be worth the complexity trade-off. (If any of min, sum, and max were NaN, the comparisons would be false.)
>> 
> 
> Yes, my recollection from the discussions we concluded not to do such checks.
> 
> Paul.


From peter.levart at gmail.com  Thu Nov  2 15:16:37 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 2 Nov 2017 16:16:37 +0100
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <ce05cb58-0504-4af1-44e5-e7a54295f8e3@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
 <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
 <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>
 <e83dd002-89a5-1e03-9593-dc09a1db3d66@oracle.com>
 <6db5bef5-e373-709e-edf6-de2a312020da@gmail.com>
 <c4ddb1aa-c115-560b-419e-6742257a4416@oracle.com>
 <792aa967-d3b0-a461-7647-84a4ece34a72@gmail.com>
 <ce05cb58-0504-4af1-44e5-e7a54295f8e3@oracle.com>
Message-ID: <3c4e081e-1042-8d8b-85d7-3ea27e05e381@gmail.com>



On 11/02/2017 01:47 PM, David Holmes wrote:
> On 2/11/2017 7:26 PM, Peter Levart wrote:
>> On 11/02/2017 03:34 AM, David Holmes wrote:
>>> On 2/11/2017 3:46 AM, Peter Levart wrote:
>>>> On 11/01/17 13:34, David Holmes wrote:
>>>>> On 1/11/2017 10:20 PM, Peter Levart wrote:
>>>>>> On 11/01/17 10:04, David Holmes wrote:
>>>>>>> On 1/11/2017 6:16 PM, Peter Levart wrote:
>>>>>>>> On 11/01/17 02:49, David Holmes wrote:
>>>>>>>>> Hi Roger,
>>>>>>>>>
>>>>>>>>> On 31/10/2017 11:58 PM, Roger Riggs wrote:
>>>>>>>>>> Hi Peter,
>>>>>>>>>>
>>>>>>>>>> Only native resources that do not map to the heap 
>>>>>>>>>> allocation/gc cycle need any kind
>>>>>>>>>> of cleanup.? I would work toward a model that encapsulates 
>>>>>>>>>> the reference to a native resource
>>>>>>>>>> with a corresponding allocation/release mechanism as you've 
>>>>>>>>>> described here and in the
>>>>>>>>>> thread on zip.
>>>>>>>>>>
>>>>>>>>>> For cleanup purposes, the independence of each resource may 
>>>>>>>>>> improve robustness
>>>>>>>>>> by avoiding dependencies and opportunities for entanglements 
>>>>>>>>>> and bugs due to exceptions
>>>>>>>>>> and other failures.
>>>>>>>>>>
>>>>>>>>>> In the case of TPE, the native resources are Threads, which 
>>>>>>>>>> keep running even if they are
>>>>>>>>>> unreferenced and are kept referenced via ThreadGroups.
>>>>>>>>>> I don't know the Executor code well enough to do more than 
>>>>>>>>>> speculate, but would suggest
>>>>>>>>>> that a cleaner (or similar) should be registered for each 
>>>>>>>>>> thread .
>>>>>>>>>
>>>>>>>>> Threads are not native resources to be managed by Cleaners! A 
>>>>>>>>> live Thread can never be cleaned. A dead thread has nothing to 
>>>>>>>>> clean!
>>>>>>>>
>>>>>>>> Right, but an idle thread, waiting for a task that will never 
>>>>>>>> come since the only entry point for submitting tasks is not 
>>>>>>>> reachable (the pool), may be cleaned...
>>>>>>>
>>>>>>> cleaned? It can be interrupted if you know about it and find 
>>>>>>> locate it. But it will not be eligible for cleaning ala Cleaner 
>>>>>>> as it will always be strongly reachable.
>>>>>>
>>>>>> Ah I see what you meant before. Yes, tracking Thread object with 
>>>>>> a Cleaner does not have any sense. But tracking thread pool 
>>>>>> object with a Cleaner and cleaning (stopping) threads as a result 
>>>>>> makes sense...
>>>>>
>>>>> No, because live Threads will keep the thread pool strongly 
>>>>> reachable.
>>>>>
>>>>> If you manage to structure things such that the Threads don't keep 
>>>>> the pool strongly reachable then you risk having the pool cleaned 
>>>>> while still actively in use.
>>>>
>>>> Pool is actively in use when it is still reachable. Only in that 
>>>> case can new tasks be submitted. When it is not reachable any more, 
>>>> no new tasks can be submitted and it can be shutdown():
>>>>
>>>> ???? /**
>>>> ????? * Initiates an orderly shutdown in which previously submitted
>>>> ????? * tasks are executed, but no new tasks will be accepted...
>>>
>>> Didn't we already determine that a Cleaner can't call shutdown() 
>>> because that requires a strong reference it doesn't have?
>>
>> It can't call shutdown() on a tracked pool object, but it could do 
>> something that acted equivalently as shutdown().
>>
>>>
>>> I think Doug already summed this up. The existing finalize() is 
>>> pointless because when it could be called there is nothing left to 
>>> be "cleaned up". There's no need for any use of Cleaner (even if it 
>>> could do anything useful).
>>
>> There's no need for finalize() or Cleaner in existing TPE as is, I 
>> agree. But there could be a thread pool that would self-shutdown when 
>> it is of no use any more (either using finalize() or Cleaner). For 
>> example, here is such pool:
>>
>> public class CleanableExecutorService implements ExecutorService {
>> ???? private final ThreadPoolExecutor tpe;
>>
>> ???? public CleanableExecutorService(ThreadPoolExecutor tpe) {
>> ???????? CleanerFactory.cleaner().register(this, tpe::shutdown);
>> ???????? this.tpe = tpe;
>> ???? }
>>
>> ???? // implement and delegate all ExecutorService methods to tpe...
>> }
>
> Ah I see - the old "extra level of indirection" solution. :) The 
> Cleaner keeps the tpe strongly reachable, but as soon as the holder 
> class becomes "unreachable" the Cleaner will shutdown the tpe.
>
> Though if you plan on abandoning a TPE such that you can't shutdown 
> directly, then you may as well just configure it so all the threads 
> terminate and it will "self-clean".

True, but if I for some reason want to use a long keepAliveTime, the TPE 
will hang there unused for such amount of time after all executing tasks 
are already finished before idle threads finally terminate. Suppose I 
want to use TPE in a library where I don't have control over the 
life-cycle of the program and such library is used in an app deployed in 
app server. Each redeployment of such app will keep threads alive for 
more time than necessary. Frequent redeployment (such as when developing 
the app) might pile up more threads than available...

Regards, Peter

> Cheers,
> David
>
>> Regards, Peter
>>
>>>
>>> David
>>


From peter.levart at gmail.com  Thu Nov  2 15:23:52 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 2 Nov 2017 16:23:52 +0100
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <ce05cb58-0504-4af1-44e5-e7a54295f8e3@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
 <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
 <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>
 <e83dd002-89a5-1e03-9593-dc09a1db3d66@oracle.com>
 <6db5bef5-e373-709e-edf6-de2a312020da@gmail.com>
 <c4ddb1aa-c115-560b-419e-6742257a4416@oracle.com>
 <792aa967-d3b0-a461-7647-84a4ece34a72@gmail.com>
 <ce05cb58-0504-4af1-44e5-e7a54295f8e3@oracle.com>
Message-ID: <8f4033f5-4e3d-6185-4f2c-5a8b46542a04@gmail.com>

Hi,

On 11/02/2017 01:47 PM, David Holmes wrote:
>> public class CleanableExecutorService implements ExecutorService {
>> ???? private final ThreadPoolExecutor tpe;
>>
>> ???? public CleanableExecutorService(ThreadPoolExecutor tpe) {
>> ???????? CleanerFactory.cleaner().register(this, tpe::shutdown);
>> ???????? this.tpe = tpe;
>> ???? }
>>
>> ???? // implement and delegate all ExecutorService methods to tpe...
>> }
>
> Ah I see - the old "extra level of indirection" solution. :) The 
> Cleaner keeps the tpe strongly reachable, but as soon as the holder 
> class becomes "unreachable" the Cleaner will shutdown the tpe. 

 ?I see there already is the following method in Executors:

 ??? public static ExecutorService newSingleThreadExecutor() {
 ??????? return new FinalizableDelegatedExecutorService
 ??????????? (new ThreadPoolExecutor(1, 1,
 ??????????????????????????????????? 0L, TimeUnit.MILLISECONDS,
 ??????????????????????????????????? new LinkedBlockingQueue<Runnable>()));
 ??? }

 ??? private static class FinalizableDelegatedExecutorService
 ??????????? extends DelegatedExecutorService {
 ??????? FinalizableDelegatedExecutorService(ExecutorService executor) {
 ??????????? super(executor);
 ??????? }
 ??????? @SuppressWarnings("deprecation")
 ??????? protected void finalize() {
 ??????????? super.shutdown();
 ??????? }
 ??? }


If the same FinalizableDelegatedExecutorService was used also for the 
following method:

 ??? /**
 ???? * Returns an object that delegates all defined {@link
 ???? * ExecutorService} methods to the given executor, but not any
 ???? * other methods that might otherwise be accessible using
 ???? * casts. This provides a way to safely "freeze" configuration and
 ???? * disallow tuning of a given concrete implementation.
 ???? * @param executor the underlying implementation
 ???? * @return an {@code ExecutorService} instance
 ???? * @throws NullPointerException if executor null
 ???? */
 ??? public static ExecutorService 
unconfigurableExecutorService(ExecutorService executor) {
 ??????? if (executor == null)
 ??????????? throw new NullPointerException();
 ??????? return new DelegatedExecutorService(executor);
 ??? }


...we would get such ExecutorService out of the box.


Regards, Peter


From jason_mehrens at hotmail.com  Thu Nov  2 16:13:33 2017
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 2 Nov 2017 16:13:33 +0000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <8f4033f5-4e3d-6185-4f2c-5a8b46542a04@gmail.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
 <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
 <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>
 <e83dd002-89a5-1e03-9593-dc09a1db3d66@oracle.com>
 <6db5bef5-e373-709e-edf6-de2a312020da@gmail.com>
 <c4ddb1aa-c115-560b-419e-6742257a4416@oracle.com>
 <792aa967-d3b0-a461-7647-84a4ece34a72@gmail.com>
 <ce05cb58-0504-4af1-44e5-e7a54295f8e3@oracle.com>,
 <8f4033f5-4e3d-6185-4f2c-5a8b46542a04@gmail.com>
Message-ID: <DM5PR1801MB194509CD70639B9F57562056835C0@DM5PR1801MB1945.namprd18.prod.outlook.com>

Peter,

Executors.unconfigurableExecutorService was not modified on purpose because of the following case:  http://cs.oswego.edu/pipermail/concurrency-interest/2006-March/002353.html

Jason

________________________________________
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Peter Levart <peter.levart at gmail.com>
Sent: Thursday, November 2, 2017 10:23 AM
To: David Holmes; Roger Riggs
Cc: core-libs-dev
Subject: Re: ThreadPoolExecutor and finalization

Hi,

On 11/02/2017 01:47 PM, David Holmes wrote:
>> public class CleanableExecutorService implements ExecutorService {
>>      private final ThreadPoolExecutor tpe;
>>
>>      public CleanableExecutorService(ThreadPoolExecutor tpe) {
>>          CleanerFactory.cleaner().register(this, tpe::shutdown);
>>          this.tpe = tpe;
>>      }
>>
>>      // implement and delegate all ExecutorService methods to tpe...
>> }
>
> Ah I see - the old "extra level of indirection" solution. :) The
> Cleaner keeps the tpe strongly reachable, but as soon as the holder
> class becomes "unreachable" the Cleaner will shutdown the tpe.

  I see there already is the following method in Executors:

     public static ExecutorService newSingleThreadExecutor() {
         return new FinalizableDelegatedExecutorService
             (new ThreadPoolExecutor(1, 1,
                                     0L, TimeUnit.MILLISECONDS,
                                     new LinkedBlockingQueue<Runnable>()));
     }

     private static class FinalizableDelegatedExecutorService
             extends DelegatedExecutorService {
         FinalizableDelegatedExecutorService(ExecutorService executor) {
             super(executor);
         }
         @SuppressWarnings("deprecation")
         protected void finalize() {
             super.shutdown();
         }
     }


If the same FinalizableDelegatedExecutorService was used also for the
following method:

     /**
      * Returns an object that delegates all defined {@link
      * ExecutorService} methods to the given executor, but not any
      * other methods that might otherwise be accessible using
      * casts. This provides a way to safely "freeze" configuration and
      * disallow tuning of a given concrete implementation.
      * @param executor the underlying implementation
      * @return an {@code ExecutorService} instance
      * @throws NullPointerException if executor null
      */
     public static ExecutorService
unconfigurableExecutorService(ExecutorService executor) {
         if (executor == null)
             throw new NullPointerException();
         return new DelegatedExecutorService(executor);
     }


...we would get such ExecutorService out of the box.


Regards, Peter


From daniel.fuchs at oracle.com  Thu Nov  2 16:47:10 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 2 Nov 2017 16:47:10 +0000
Subject: RFR: 8189953: FileHandler constructor throws NoSuchFileException with
 absolute path
Message-ID: <0513b8d0-ab37-7700-6d06-2b5e0f574f45@oracle.com>

Hi,

Please find below a patch for:
8189953: FileHandler constructor throws NoSuchFileException
          with absolute path
https://bugs.openjdk.java.net/browse/JDK-8189953

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8189953/webrev.00/

This is a windows only bug.

The issue is caused by a change that happen somewhen between
8 and 9, where new File(new File("C:"),"Workspace") was fixed
to return "C:Workspace" and not "C:\\Workspace".
This uncovered a bug in the FileHandler::generate algorithm.

The FileHandler::generate algorithm could arguably be improved
by being entirely rewritten but I choose to keep the changes
as minimal as I could.

best regards,

-- daniel

From paul.sandoz at oracle.com  Thu Nov  2 16:58:39 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 2 Nov 2017 09:58:39 -0700
Subject: RFR Re: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <ac37386a-5399-c425-5bd0-aed943451186@oracle.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <DF5459F9-D1F9-4E54-8543-43FFB2BF4341@gmail.com>
 <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>
 <ac37386a-5399-c425-5bd0-aed943451186@oracle.com>
Message-ID: <1983EE5B-6DC6-476E-B9C1-23ABCBC5FF2A@oracle.com>


> On 31 Oct 2017, at 11:24, Brian Goetz <brian.goetz at Oracle.COM> wrote:
> 
> While I agree that the overflow-detecting constraint on min/max in the early version was too aggressive, you could reasonably choose to enforce the constraint that if count == 0, then so should sum, min, and max.
> 

I?m on the fence on this one. Joe is going to follow up with another issue for DoubleSummaryStatistics adjusting to a varargs constructor and and may consider doing this at the same time.

Paul.

> On 10/30/2017 6:49 PM, Paul Sandoz wrote:
>> Hi Chris,
>> 
>> After some hiatus here is an updated webrev, i made some tweaks to the JavaDoc:
>> 
>>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8178117-summary-constructors/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8178117-summary-constructors/webrev/>
>> 
>> And the CSR:
>> 
>>   https://bugs.openjdk.java.net/browse/JDK-8190381 <https://bugs.openjdk.java.net/browse/JDK-8190381>
>> 
>> The support for a double sum of consisting of an array of double is going beyond my complexity budget for this feature. If that is deemed important later on we can add another constructor.
>> 
>> Paul.
>> 


From peter.levart at gmail.com  Thu Nov  2 17:24:35 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 2 Nov 2017 18:24:35 +0100
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <DM5PR1801MB194509CD70639B9F57562056835C0@DM5PR1801MB1945.namprd18.prod.outlook.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
 <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
 <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>
 <e83dd002-89a5-1e03-9593-dc09a1db3d66@oracle.com>
 <6db5bef5-e373-709e-edf6-de2a312020da@gmail.com>
 <c4ddb1aa-c115-560b-419e-6742257a4416@oracle.com>
 <792aa967-d3b0-a461-7647-84a4ece34a72@gmail.com>
 <ce05cb58-0504-4af1-44e5-e7a54295f8e3@oracle.com>
 <8f4033f5-4e3d-6185-4f2c-5a8b46542a04@gmail.com>
 <DM5PR1801MB194509CD70639B9F57562056835C0@DM5PR1801MB1945.namprd18.prod.outlook.com>
Message-ID: <f2afcaf5-fc77-9671-89b5-b171a289c151@gmail.com>

Hi Jason,

On 11/02/2017 05:13 PM, Jason Mehrens wrote:
> Peter,
>
> Executors.unconfigurableExecutorService was not modified on purpose because of the following case:  http://cs.oswego.edu/pipermail/concurrency-interest/2006-March/002353.html
>
> Jason

Oh, I see. The method is meant to provide a limited view over any 
ExecutorService and there may be multiple views over same instance.

Regards, Peter

>
> ________________________________________
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Peter Levart <peter.levart at gmail.com>
> Sent: Thursday, November 2, 2017 10:23 AM
> To: David Holmes; Roger Riggs
> Cc: core-libs-dev
> Subject: Re: ThreadPoolExecutor and finalization
>
> Hi,
>
> On 11/02/2017 01:47 PM, David Holmes wrote:
>>> public class CleanableExecutorService implements ExecutorService {
>>>       private final ThreadPoolExecutor tpe;
>>>
>>>       public CleanableExecutorService(ThreadPoolExecutor tpe) {
>>>           CleanerFactory.cleaner().register(this, tpe::shutdown);
>>>           this.tpe = tpe;
>>>       }
>>>
>>>       // implement and delegate all ExecutorService methods to tpe...
>>> }
>> Ah I see - the old "extra level of indirection" solution. :) The
>> Cleaner keeps the tpe strongly reachable, but as soon as the holder
>> class becomes "unreachable" the Cleaner will shutdown the tpe.
>    I see there already is the following method in Executors:
>
>       public static ExecutorService newSingleThreadExecutor() {
>           return new FinalizableDelegatedExecutorService
>               (new ThreadPoolExecutor(1, 1,
>                                       0L, TimeUnit.MILLISECONDS,
>                                       new LinkedBlockingQueue<Runnable>()));
>       }
>
>       private static class FinalizableDelegatedExecutorService
>               extends DelegatedExecutorService {
>           FinalizableDelegatedExecutorService(ExecutorService executor) {
>               super(executor);
>           }
>           @SuppressWarnings("deprecation")
>           protected void finalize() {
>               super.shutdown();
>           }
>       }
>
>
> If the same FinalizableDelegatedExecutorService was used also for the
> following method:
>
>       /**
>        * Returns an object that delegates all defined {@link
>        * ExecutorService} methods to the given executor, but not any
>        * other methods that might otherwise be accessible using
>        * casts. This provides a way to safely "freeze" configuration and
>        * disallow tuning of a given concrete implementation.
>        * @param executor the underlying implementation
>        * @return an {@code ExecutorService} instance
>        * @throws NullPointerException if executor null
>        */
>       public static ExecutorService
> unconfigurableExecutorService(ExecutorService executor) {
>           if (executor == null)
>               throw new NullPointerException();
>           return new DelegatedExecutorService(executor);
>       }
>
>
> ...we would get such ExecutorService out of the box.
>
>
> Regards, Peter
>


From joe.darcy at oracle.com  Thu Nov  2 17:40:12 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 2 Nov 2017 10:40:12 -0700
Subject: RFR Re: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <1983EE5B-6DC6-476E-B9C1-23ABCBC5FF2A@oracle.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <DF5459F9-D1F9-4E54-8543-43FFB2BF4341@gmail.com>
 <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>
 <ac37386a-5399-c425-5bd0-aed943451186@oracle.com>
 <1983EE5B-6DC6-476E-B9C1-23ABCBC5FF2A@oracle.com>
Message-ID: <840c552e-e1e3-4807-791c-5b74a4614c40@oracle.com>

On 11/2/2017 9:58 AM, Paul Sandoz wrote:
>> On 31 Oct 2017, at 11:24, Brian Goetz <brian.goetz at Oracle.COM> wrote:
>>
>> While I agree that the overflow-detecting constraint on min/max in the early version was too aggressive, you could reasonably choose to enforce the constraint that if count == 0, then so should sum, min, and max.
>>
> I?m on the fence on this one. Joe is going to follow up with another issue for DoubleSummaryStatistics adjusting to a varargs constructor and and may consider doing this at the same time.
>

Added a comment to record that possibility to JDK-8190517: "Allow 
DoubleSummaryStatistics constructor to accept additional state."

-Joe

From jason_mehrens at hotmail.com  Thu Nov  2 17:55:48 2017
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 2 Nov 2017 17:55:48 +0000
Subject: 8189953: FileHandler constructor throws NoSuchFileException with
 absolute path
In-Reply-To: <0513b8d0-ab37-7700-6d06-2b5e0f574f45@oracle.com>
References: <0513b8d0-ab37-7700-6d06-2b5e0f574f45@oracle.com>
Message-ID: <DM5PR1801MB194594953454B771BFB9D7FD835C0@DM5PR1801MB1945.namprd18.prod.outlook.com>

Hi Daniel,

For more background on this issue I think you should link to this issue to the following:

https://bugs.openjdk.java.net/browse/JDK-8153250
https://bugs.openjdk.java.net/browse/JDK-8130462
https://bugs.openjdk.java.net/browse/JDK-8189862

Thanks,

Jason
________________________________________
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Daniel Fuchs <daniel.fuchs at oracle.com>
Sent: Thursday, November 2, 2017 11:47 AM
To: core-libs-dev
Subject: RFR: 8189953: FileHandler constructor throws NoSuchFileException with absolute path

Hi,

Please find below a patch for:
8189953: FileHandler constructor throws NoSuchFileException
          with absolute path
https://bugs.openjdk.java.net/browse/JDK-8189953

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8189953/webrev.00/

This is a windows only bug.

The issue is caused by a change that happen somewhen between
8 and 9, where new File(new File("C:"),"Workspace") was fixed
to return "C:Workspace" and not "C:\\Workspace".
This uncovered a bug in the FileHandler::generate algorithm.

The FileHandler::generate algorithm could arguably be improved
by being entirely rewritten but I choose to keep the changes
as minimal as I could.

best regards,

-- daniel

From patrick at reini.net  Thu Nov  2 18:36:13 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 2 Nov 2017 19:36:13 +0100
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
Message-ID: <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>

Hi Alan,

The latest version is here:

http://cr.openjdk.java.net/~reinhapa/reviews/8067661/signature


> Am 02.11.2017 um 14:52 schrieb Alan Bateman <Alan.Bateman at oracle.com>:
> 
> On 01/11/2017 14:57, Patrick Reinhart wrote:
>> I tried to put that in my latest proposal:
>> 
>> /**
>>  * Reads all characters from this readable and writes the characters to
>>  * the given appendable in the order that they are read. On return, this
>>  * readable will be at end its data.
> You might want to try using  "this source" in the wording, as in "On return, the source of characters will be at its end". I think this will make it a bit more consistent with the existing wording in the read method.

That would read then something like this:

 * Reads all characters from this readable and writes the characters to
 * the given appendable in the order that they are read. On return, the
 * source of characters will be at its end.


> 
>>  * <p>
>>  * This method may block indefinitely reading from the readable, or
>>  * writing to the appendable. The behavior for the case where the readable
>>  * and/or appendable is <i>asynchronously closed</i>, or the thread
>>  * interrupted during the transfer, is highly readable and appendable
>>  * specific, and therefore not specified.
> I think this needs more setup to allow for close, maybe ?Where this source or the appendable is {@link AutoCloseable closeable} then the behavior when either are asynchronously closed ??.

The second part:

 * This method may block indefinitely reading from the readable, or
 * writing to the appendable. Where this source or the appendable is
 * {@link java.io.AutoCloseable closeable}, then the behavior when either are
 * <i>asynchronously closed</i>, or the thread interrupted during the transfer,
 * is highly readable and appendable specific, and therefore not specified.

The only thing that worries me is that the @link is pointing form java.lang to java.io stuff, which I tried to prevent.

> 
>>  *
>>  * @since 18.3
>> 
> We're using "@since 10" for now, pending an outcome of the version string discussion.
> 
> -Alan


From daniel.fuchs at oracle.com  Thu Nov  2 18:41:58 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 2 Nov 2017 18:41:58 +0000
Subject: 8189953: FileHandler constructor throws NoSuchFileException with
 absolute path
In-Reply-To: <DM5PR1801MB194594953454B771BFB9D7FD835C0@DM5PR1801MB1945.namprd18.prod.outlook.com>
References: <0513b8d0-ab37-7700-6d06-2b5e0f574f45@oracle.com>
 <DM5PR1801MB194594953454B771BFB9D7FD835C0@DM5PR1801MB1945.namprd18.prod.outlook.com>
Message-ID: <3a9ad1e2-d508-4e83-9429-026c34d81104@oracle.com>

On 02/11/2017 17:55, Jason Mehrens wrote:
> Hi Daniel,
> 
> For more background on this issue I think you should link to this issue to the following:
> 
> https://bugs.openjdk.java.net/browse/JDK-8153250
> https://bugs.openjdk.java.net/browse/JDK-8130462
> https://bugs.openjdk.java.net/browse/JDK-8189862

Oh, thanks Jason!
That is great :-)

I have linked the issues.

best regards,

-- daniel


From Roger.Riggs at Oracle.com  Thu Nov  2 19:08:37 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 2 Nov 2017 15:08:37 -0400
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <85BE47B6-2214-43AD-B7D0-01F846E42EED@reini.net>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <AM4PR08MB12199717DB39BAA682DE5B3BFF5F0@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <3ea78605-b083-1fcc-3cb8-1adc6d76d045@oracle.com>
 <1B0724CA-ADB2-432A-9004-B0A9C6B74F6E@reini.net>
 <CAGB9EW-Zpd4D5Hc1ri4vPjnVQQ1zG7hifHoe=6cYr7zEB2r0Gg@mail.gmail.com>
 <85BE47B6-2214-43AD-B7D0-01F846E42EED@reini.net>
Message-ID: <a76d535f-7e92-5700-8cb9-2b254eee2153@Oracle.com>

Hi,

It would also support a more fluent use of the APIs.? Though if we start 
down that road
it may become littered with convenience methods.? Something to ponder 
for a bit.

Roger


On 11/1/2017 4:29 PM, Patrick Reinhart wrote:
> In this case I would prefer a non static copyOf() method on the list to create a unmodifiable list/set/map, where the optimal factory method can be called. This would also solve the problem of a concurrent implementation.
>
> -Patrick
>
>
>> Am 01.11.2017 um 21:05 schrieb Louis Wasserman <lowasser at google.com>:
>>
>> I disagree, actually.  Collections with size zero and one are significantly more common than bigger collections.
>>
>> In Guava's immutable collection factories (ImmutableList.of(...) etc.), we observed a roughly exponential decline in the number of users of factory methods of each size: if N people created empty lists, ~N/2 created singleton lists, ~N/4 created two-element lists, etc.  We got noticeable pushback from RAM-sensitive customers when we eliminated some specialized singleton collection implementations.
>>
>> Our experience has been that specializing for N=0 and N=1 does pay off.  Probably not N=2, though?
>>
>> On Wed, Nov 1, 2017 at 12:45 PM Patrick Reinhart <patrick at reini.net <mailto:patrick at reini.net>> wrote:
>>
>>> Am 01.11.2017 um 20:25 schrieb Stuart Marks <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com>>:
>>>
>>> On 10/31/17 5:52 PM, Bernd Eckenfels wrote:
>>>> Having a List.of(List) copy constructor would save an additional array copy in the collector Which uses  (List<T>)List.of(list.toArray())
>>> The quickest way to get all the elements from the source collection is to call toArray() on it. Some copy constructors (like ArrayList's) simply use the returned array for internal storage. This saves a copy, but it relies on the source collection's toArray() implementation to be correct. In particular, the returned array must be freshly created, and that array must be of type Object[]. If either of these is violated, it will break the ArrayList.
>>>
>>> The "immutable" collections behind List.of/copyOf/etc. are fastidious about allocating their internal arrays in order to ensure that they are referenced only from within the newly created collection. This requires making an ?extra" copy of the array returned by toArray().
>>>
>>> An alternative is for the new collection to preallocate its internal array using the source's size(), and then to copy the elements out. But the source?s
>>> size might change during the copy (e.g., if it?s a concurrent collection) so this complicates things.
>> I think the array ?overhead? would be only for the cases of zero, one and two value implementations. That seems to me not worth of optimizing?
>>
>>> I think the only safe way to avoid the extra copy is to create a private interface that can be used by JDK implementations.
>>>
>>> s'marks
>> -Patrick


From Alan.Bateman at oracle.com  Thu Nov  2 19:34:23 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 Nov 2017 19:34:23 +0000
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
Message-ID: <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>

On 02/11/2017 18:36, Patrick Reinhart wrote:
> :
> That would read then something like this:
>
>   * Reads all characters from this readable and writes the characters to
>   * the given appendable in the order that they are read. On return, the
>   * source of characters will be at its end.
Yes, or even "Reads all characters from this source ...".


> :
> The second part:
>
>   * This method may block indefinitely reading from the readable, or
>   * writing to the appendable. Where this source or the appendable is
>   * {@link java.io.AutoCloseable closeable}, then the behavior when either are
>   * <i>asynchronously closed</i>, or the thread interrupted during the transfer,
>   * is highly readable and appendable specific, and therefore not specified.
>
> The only thing that worries me is that the @link is pointing form java.lang to java.io stuff, which I tried to prevent.
>
The read method reads from a CharBuffer and throws IOException so I 
think this is okay.

So are you planning to adding an implementation + tests for this?

-Alan



From Roger.Riggs at Oracle.com  Thu Nov  2 19:49:28 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 2 Nov 2017 15:49:28 -0400
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <f2afcaf5-fc77-9671-89b5-b171a289c151@gmail.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
 <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
 <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>
 <e83dd002-89a5-1e03-9593-dc09a1db3d66@oracle.com>
 <6db5bef5-e373-709e-edf6-de2a312020da@gmail.com>
 <c4ddb1aa-c115-560b-419e-6742257a4416@oracle.com>
 <792aa967-d3b0-a461-7647-84a4ece34a72@gmail.com>
 <ce05cb58-0504-4af1-44e5-e7a54295f8e3@oracle.com>
 <8f4033f5-4e3d-6185-4f2c-5a8b46542a04@gmail.com>
 <DM5PR1801MB194509CD70639B9F57562056835C0@DM5PR1801MB1945.namprd18.prod.outlook.com>
 <f2afcaf5-fc77-9671-89b5-b171a289c151@gmail.com>
Message-ID: <708689cc-6752-e457-16c7-56c34540e232@Oracle.com>

Hi,

I would think that the some part of the application or library would be 
responsible for the (lifecycle of the)
executor that is being wrapped and it is not the responsibility of the 
'view' to keep it alive.

$.02, Roger


On 11/2/2017 1:24 PM, Peter Levart wrote:
> Hi Jason,
>
> On 11/02/2017 05:13 PM, Jason Mehrens wrote:
>> Peter,
>>
>> Executors.unconfigurableExecutorService was not modified on purpose 
>> because of the following case: 
>> http://cs.oswego.edu/pipermail/concurrency-interest/2006-March/002353.html
>>
>> Jason
>
> Oh, I see. The method is meant to provide a limited view over any 
> ExecutorService and there may be multiple views over same instance.
>
> Regards, Peter
>
>>
>> ________________________________________
>> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on 
>> behalf of Peter Levart <peter.levart at gmail.com>
>> Sent: Thursday, November 2, 2017 10:23 AM
>> To: David Holmes; Roger Riggs
>> Cc: core-libs-dev
>> Subject: Re: ThreadPoolExecutor and finalization
>>
>> Hi,
>>
>> On 11/02/2017 01:47 PM, David Holmes wrote:
>>>> public class CleanableExecutorService implements ExecutorService {
>>>> ????? private final ThreadPoolExecutor tpe;
>>>>
>>>> ????? public CleanableExecutorService(ThreadPoolExecutor tpe) {
>>>> ????????? CleanerFactory.cleaner().register(this, tpe::shutdown);
>>>> ????????? this.tpe = tpe;
>>>> ????? }
>>>>
>>>> ????? // implement and delegate all ExecutorService methods to tpe...
>>>> }
>>> Ah I see - the old "extra level of indirection" solution. :) The
>>> Cleaner keeps the tpe strongly reachable, but as soon as the holder
>>> class becomes "unreachable" the Cleaner will shutdown the tpe.
>> ?? I see there already is the following method in Executors:
>>
>> ????? public static ExecutorService newSingleThreadExecutor() {
>> ????????? return new FinalizableDelegatedExecutorService
>> ????????????? (new ThreadPoolExecutor(1, 1,
>> ????????????????????????????????????? 0L, TimeUnit.MILLISECONDS,
>> ????????????????????????????????????? new 
>> LinkedBlockingQueue<Runnable>()));
>> ????? }
>>
>> ????? private static class FinalizableDelegatedExecutorService
>> ????????????? extends DelegatedExecutorService {
>> ????????? FinalizableDelegatedExecutorService(ExecutorService 
>> executor) {
>> ????????????? super(executor);
>> ????????? }
>> ????????? @SuppressWarnings("deprecation")
>> ????????? protected void finalize() {
>> ????????????? super.shutdown();
>> ????????? }
>> ????? }
>>
>>
>> If the same FinalizableDelegatedExecutorService was used also for the
>> following method:
>>
>> ????? /**
>> ?????? * Returns an object that delegates all defined {@link
>> ?????? * ExecutorService} methods to the given executor, but not any
>> ?????? * other methods that might otherwise be accessible using
>> ?????? * casts. This provides a way to safely "freeze" configuration and
>> ?????? * disallow tuning of a given concrete implementation.
>> ?????? * @param executor the underlying implementation
>> ?????? * @return an {@code ExecutorService} instance
>> ?????? * @throws NullPointerException if executor null
>> ?????? */
>> ????? public static ExecutorService
>> unconfigurableExecutorService(ExecutorService executor) {
>> ????????? if (executor == null)
>> ????????????? throw new NullPointerException();
>> ????????? return new DelegatedExecutorService(executor);
>> ????? }
>>
>>
>> ...we would get such ExecutorService out of the box.
>>
>>
>> Regards, Peter
>>
>


From patrick at reini.net  Thu Nov  2 19:55:14 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 2 Nov 2017 20:55:14 +0100
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
Message-ID: <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>

Hi Alan,

> Am 02.11.2017 um 20:34 schrieb Alan Bateman <Alan.Bateman at oracle.com>:
> 
> On 02/11/2017 18:36, Patrick Reinhart wrote:
>> :
>> That would read then something like this:
>> 
>>  * Reads all characters from this readable and writes the characters to
>>  * the given appendable in the order that they are read. On return, the
>>  * source of characters will be at its end.
> Yes, or even ?Reads all characters from this source ??

Updated accordingly:

http://cr.openjdk.java.net/~reinhapa/reviews/8067661/signature

> 
>> :
>> The second part:
>> 
>>  * This method may block indefinitely reading from the readable, or
>>  * writing to the appendable. Where this source or the appendable is
>>  * {@link java.io.AutoCloseable closeable}, then the behavior when either are
>>  * <i>asynchronously closed</i>, or the thread interrupted during the transfer,
>>  * is highly readable and appendable specific, and therefore not specified.
>> 
>> The only thing that worries me is that the @link is pointing form java.lang to java.io stuff, which I tried to prevent.
>> 
> The read method reads from a CharBuffer and throws IOException so I think this is okay.
> 
> So are you planning to adding an implementation + tests for this?
> 

If we are all happy with the API so far, I could start adding an initial implementation and test?

-Patrick

From john.r.rose at oracle.com  Thu Nov  2 19:56:04 2017
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 2 Nov 2017 12:56:04 -0700
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
Message-ID: <F9C4D58D-41C7-494E-ADD7-F7DFD49A0BF8@oracle.com>

On Oct 20, 2017, at 4:45 AM, Christoph Dreis <christoph.dreis at freenet.de> wrote:
> 
> What do you think about that? Is someone willing to sponsor this given it's
> considered worthwhile.

Let's set that up on top of the new unmodifiable lists from List.of.
It will be simpler and more powerful in the end.  Coding with
the new unmodifiable collections is really nice, and we should
encourage it.

So for every old-school access method of the form T[] getFoos(),
let's consider adding List<T> getFooList(), which returns a list
that works like List.of.  If we use a shared-secrets mechanism,
we can even reuse the same List.of code, using a private
API List.ofSharedArray(T[]) which doesn't copy the argument..

? John

P.S.  A couple thoughts on naming:

Ultimately it would be good if we could do overload selection
based on return type, in which case we wouldn't have to change
the name of the T[] access functions, just their return types.

If we *are* going to change names, we might consider a more
modern-looking form for immutable getters, which elides that
grody "get" prefix.  The "get" prefix makes the most sense when
there is a possibility of a corresponding "set" operator, but these
data structures have no setters, since they are unmodifiable.
The "get" prefix is notably absent from the java.lang.invoke
APIs, except where there really are setters present also.
I wish we could decide to adopt that convention more widely.


From joe.darcy at oracle.com  Thu Nov  2 20:20:38 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 2 Nov 2017 13:20:38 -0700
Subject: JDK 10 RFR of JDK-8190573: Problem list
 InheritedChannelNotServerSocket.java
Message-ID: <b0bde1e7-5f04-92c7-64e7-816974d39237@oracle.com>

Hello,

The test

java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java

fails intermittently fairly often (JDK-8170562). Until the instability 
is addressed, I'd like to put the test on the problem list. Patch below.

Thanks,

-Joe

diff -r 30186b6741b8 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt    Thu Oct 26 18:04:29 2017 -0700
+++ b/test/jdk/ProblemList.txt    Thu Nov 02 13:12:00 2017 -0700
@@ -200,6 +200,8 @@

  java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java 8169569 windows-all

+java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java 
8170562 generic-all
+
  java/rmi/registry/readTest/CodebaseTest.java 8173324 windows-all

  ############################################################################


From Roger.Riggs at Oracle.com  Thu Nov  2 20:21:52 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 2 Nov 2017 16:21:52 -0400
Subject: JDK 10 RFR of JDK-8190573: Problem list
 InheritedChannelNotServerSocket.java
In-Reply-To: <b0bde1e7-5f04-92c7-64e7-816974d39237@oracle.com>
References: <b0bde1e7-5f04-92c7-64e7-816974d39237@oracle.com>
Message-ID: <83e62ab6-849d-b308-935c-f9f04a94b9f6@Oracle.com>

Look good

Regards, Roger

On 11/2/2017 4:20 PM, joe darcy wrote:
> Hello,
>
> The test
>
> java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java 
>
>
> fails intermittently fairly often (JDK-8170562). Until the instability 
> is addressed, I'd like to put the test on the problem list. Patch below.
>
> Thanks,
>
> -Joe
>
> diff -r 30186b6741b8 test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt??? Thu Oct 26 18:04:29 2017 -0700
> +++ b/test/jdk/ProblemList.txt??? Thu Nov 02 13:12:00 2017 -0700
> @@ -200,6 +200,8 @@
>
> ?java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java 
> 8169569 windows-all
>
> +java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java 
> 8170562 generic-all
> +
> ?java/rmi/registry/readTest/CodebaseTest.java 8173324 windows-all
>
> ?############################################################################ 
>
>


From christoph.dreis at freenet.de  Thu Nov  2 20:33:23 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Thu, 2 Nov 2017 21:33:23 +0100
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <F9C4D58D-41C7-494E-ADD7-F7DFD49A0BF8@oracle.com>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
 <F9C4D58D-41C7-494E-ADD7-F7DFD49A0BF8@oracle.com>
Message-ID: <012d01d35419$d48bbe80$7da33b80$@freenet.de>

Hey John,

I'm not quite able to make the connection between my proposal to add Executable.getParameterType(index) and your answer.

>> What do you think about that? Is someone willing to sponsor this given it's
>> considered worthwhile.

> Let's set that up on top of the new unmodifiable lists from List.of.
> It will be simpler and more powerful in the end.  Coding with
> the new unmodifiable collections is really nice, and we should
> encourage it.

> So for every old-school access method of the form T[] getFoos(),
> let's consider adding List<T> getFooList(), which returns a list
> that works like List.of.  If we use a shared-secrets mechanism,
> we can even reuse the same List.of code, using a private
> API List.ofSharedArray(T[]) which doesn't copy the argument..

Could you elaborate, please?

Thanks,
Christoph




From Roger.Riggs at Oracle.com  Thu Nov  2 20:39:33 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 2 Nov 2017 16:39:33 -0400
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <684d9e38-46e0-875f-3cc3-c6d87735d3dd@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
 <bfd6c977-df4d-53ba-a59c-8e2a6c04f2eb@Oracle.com>
 <CA+kOe08vE5hXJRot0t8p==VnsY6DEaD0ipqcrMYPkhMOW=rzDg@mail.gmail.com>
 <305aa1b0-ee40-b2fd-d1bd-4aeedad55a56@oracle.com>
 <16f9c87e-3f23-a813-fb62-ed8f616c7e5d@oracle.com>
 <a94bf6ce-95d5-3c7b-1e91-711450fb5adb@oracle.com>
 <684d9e38-46e0-875f-3cc3-c6d87735d3dd@oracle.com>
Message-ID: <356151e6-7291-2f56-3cd5-13314f5c65ea@Oracle.com>

Hi David,

On 11/1/2017 10:30 PM, David Holmes wrote:
> On 2/11/2017 5:07 AM, Stuart Marks wrote:
>> On 10/31/17 6:58 PM, David Holmes wrote:
>>>> I'm not sure why you say this isn't helpful. It's clearly not 
>>>> helpful to *clients* of TPE; but since finalize() is protected, the 
>>>> warning is clearly directed at subclasses, and it provides 
>>>> information about migrating away from finalization. Should say 
>>>> something different?
>>>
>>> It isn't helpful to people subclassing TPE (or any class that 
>>> defines finalize()) because the general strategies described in 
>>> Object.finalize() can't be applied by the subclass independent of 
>>> the class (TPE here) it is subclassing. Unless TPE provides an 
>>> alternate mechanism, the subclass is stuck with finalize().
>>
>> I don't understand why the subclass has to rely on the mechanism 
>> provided by its superclass (TPE here). I'm thinking of a case like 
>> the following.
>>
>> Suppose a subclass has some independent native resource that it needs 
>> to clean up. Prior to the introduction of java.lang.ref, the only 
>> thing available was finalization. The subclass would have to override 
>> finalize(), do its own cleanup, and then make sure to call 
>> super.finalize().
>>
>> With Cleaner in JDK 9, the subclass can refactor its native resources 
>> into a Cleanable, register it with a Cleaner, and then clean up its 
>> native resources when the Cleanable's clean() method is called.
>>
>> Can't this be done independently of TPE and finalization?
>
> Of course it can. The independent part of the subclass can use 
> whatever mechanism it likes - it's independent. The point is that if 
> the subclass needs to coordinate it's additional cleanup with the 
> shutdown done by finalize() then it needs a means to do so.
Given the use cases and the context in which an unreferenced resource 
needs to be
released, I don't think a fully general purpose mechanism is appropriate.
If there are dependencies in the cleanup those can be references between 
the dependent
objects.? Those dependencies will ensure that cleanup of each occurs 
when it is unreferenced.
It is more robust if each resource handles its own cleanup.? Peter 
already suggested
that if coordination was required, the mechanism should be explicitly 
provided by the
owning/coordinating object.

Roger


>
> David
>
>> s'marks


From john.r.rose at oracle.com  Thu Nov  2 21:34:15 2017
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 2 Nov 2017 14:34:15 -0700
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <012d01d35419$d48bbe80$7da33b80$@freenet.de>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
 <F9C4D58D-41C7-494E-ADD7-F7DFD49A0BF8@oracle.com>
 <012d01d35419$d48bbe80$7da33b80$@freenet.de>
Message-ID: <90EA3CF8-5E39-4E75-91AB-4C7432E8044B@oracle.com>

On Nov 2, 2017, at 1:33 PM, Christoph Dreis <christoph.dreis at freenet.de> wrote:
> 
> Could you elaborate, please?

Sure.  It's really quite simple:  Replace the old mutable array
with a modern immutable list.

Executable:
   /**
     * Returns a list of {@code Class} objects that represent the formal
     * parameter types, in declaration order, of the executable
     * represented by this object.  Returns a list of length
     * 0 if the underlying executable takes no parameters.
     * 
     * The list is immutable.
     * See <a href="../../util/List.html#immutable">Immutable List Static Factory Methods</a> for details.
     *
     * @return the parameter types for the executable this object
     * represents
     */
   public abstract List<Class<?>> parameterTypes();
   // "getParameterTypeList" if you must but you shouldn't

(etc.)

Your and Claes' proposal to add the index accessor adds
a more complex API point and requires more complex usage
patterns (for-loops).  In short it's very 90's.  Using a List instead
gives interoperability with new APIs like java.util.stream.

Because of the way immutable lists are organized, the sharing
and code quality at least as good as an indexed access method,
if that was a concern.

? John

From naoto.sato at oracle.com  Thu Nov  2 21:42:10 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 2 Nov 2017 14:42:10 -0700
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
Message-ID: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>

Hello,

Please review the proposed changes for the following issues:

8176841: Additional Unicode Language-Tag Extensions
8189134: New system properties for the default Locale extensions

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8176841/webrev.03/

This serves as the implementation of JEP 314.

Naoto




From christoph.dreis at freenet.de  Thu Nov  2 22:00:18 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Thu, 2 Nov 2017 23:00:18 +0100
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <90EA3CF8-5E39-4E75-91AB-4C7432E8044B@oracle.com>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
 <F9C4D58D-41C7-494E-ADD7-F7DFD49A0BF8@oracle.com>
 <012d01d35419$d48bbe80$7da33b80$@freenet.de>
 <90EA3CF8-5E39-4E75-91AB-4C7432E8044B@oracle.com>
Message-ID: <013001d35425$f8b9ddd0$ea2d9970$@freenet.de>

Hey John,

>> Could you elaborate, please?

> Sure.  It's really quite simple:  Replace the old mutable array
> with a modern immutable list.
> ....
> Your and Claes' proposal to add the index accessor adds
> a more complex API point and requires more complex usage
> patterns (for-loops).  In short it's very 90's.  Using a List instead
> gives interoperability with new APIs like java.util.stream.
> Because of the way immutable lists are organized, the sharing
> and code quality at least as good as an indexed access method,
> if that was a concern.

Thanks for the clarification. Actually the more important concern was to get rid of unnecessary allocations that the cloning inside Executable.getParameterTypes() is producing. As Claes mentioned experience and experiments show that JIT's escaping mechanisms fail from time to time on this one. And if you ask me it is not good practice to rely on the compiler optimizations anyhow, but that's maybe just me.

I do like your proposal nonetheless as an additional improvement, but I think it won't achieve the allocation-free part I was aiming for. Correct me if I'm wrong, please.

Cheers,
Christoph


From stuart.marks at oracle.com  Thu Nov  2 22:04:46 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 2 Nov 2017 15:04:46 -0700
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <2a20565b-83f5-a39d-8b31-ac70c64ff8b9@gmail.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <CAE+3fjYzgEMmFFOge6hdN9wi3qS=5OCTKJKupeLbf-gaaPf9eQ@mail.gmail.com>
 <d02cf931-6bd4-3b99-3375-dbce6e8047c8@oracle.com>
 <2a20565b-83f5-a39d-8b31-ac70c64ff8b9@gmail.com>
Message-ID: <c2137520-677d-2a7c-898a-2b8884df96f3@oracle.com>


> Why not using:
>
> ??? coll.stream().collect(Collectors.toImmutableSet())
>
> As Collectors.toImmutableSet() is currently implemented, with serial Stream it 
> will create a single HashSet, add all the elements to it and call 
> Set.of(HashSet.toArray()) with it. Pretty much the same as what Tagir 
> proposes, but the Collector could be made more efficient in the future and 
> with it, the optimization would automatically extend to Set.copyOf()...
This is mainly about whether Set.copyOf() is implemented in terms of 
Collectors.toUnmodifiableSet(), or vice-versa, which then calls Set.of(T[]) to 
do the actual creation. Some future optimization will probably replace both of 
these implementations with calls to JDK internal methods that can bypass the 
extra copying, so it doesn't really matter which one of these calls the other 
right now.

s'marks


From john.r.rose at oracle.com  Thu Nov  2 22:13:51 2017
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 2 Nov 2017 15:13:51 -0700
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <013001d35425$f8b9ddd0$ea2d9970$@freenet.de>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
 <F9C4D58D-41C7-494E-ADD7-F7DFD49A0BF8@oracle.com>
 <012d01d35419$d48bbe80$7da33b80$@freenet.de>
 <90EA3CF8-5E39-4E75-91AB-4C7432E8044B@oracle.com>
 <013001d35425$f8b9ddd0$ea2d9970$@freenet.de>
Message-ID: <603EF3CC-F789-4D06-9295-DBD948493692@oracle.com>

On Nov 2, 2017, at 3:00 PM, Christoph Dreis <christoph.dreis at freenet.de> wrote:
> 
> Thanks for the clarification. Actually the more important concern was to get rid of unnecessary allocations that the cloning inside Executable.getParameterTypes() is producing. As Claes mentioned experience and experiments show that JIT's escaping mechanisms fail from time to time on this one. And if you ask me it is not good practice to rely on the compiler optimizations anyhow, but that's maybe just me.
> 
> I do like your proposal nonetheless as an additional improvement, but I think it won't achieve the allocation-free part I was aiming for. Correct me if I'm wrong, please.

There are two ways it can directly achieve what you are after.

First, if the guts of the jlr.Method can cache the List and return
the same value every time.  Then the legacy API point can use
List::toArray to create the legacy array values.

Second, if the guts of the jlr.Method choose to cache the Class[],
it can still return a List wrapped around the same array, each time,
as long as the List refuses modification.

Either option avoids the O(N) copying and avoids problems
with escape analysis.  The second option has O(1) allocation,
the first does zero allocation.

The first option also allows constant propagation through the
List.of values, something that arrays can never do (until we
introduce frozen arrays).  This bit of magic is one of several
reasons people who program with arrays should try to move
over to lists.  It is enabled by the private annotation @Stable.

? John

From philipp.kunz at paratix.ch  Thu Nov  2 23:04:44 2017
From: philipp.kunz at paratix.ch (Philipp Kunz)
Date: Fri, 3 Nov 2017 00:04:44 +0100
Subject: JDK-6372077: JarFile.getManifest() should handle manifest attribute
 name 70 bytes
In-Reply-To: <02abcb68-2294-c733-5048-b1f81ee99435@oracle.com>
References: <9a4edee0-4edd-caaa-9970-61df083d39df@paratix.ch>
 <02abcb68-2294-c733-5048-b1f81ee99435@oracle.com>
Message-ID: <88b89995-cfe0-d439-d63d-699c628e2315@paratix.ch>

Hi Sean and Max and all others,

Thank you Sean for the hint about the right mailing list. And thanks 
also for his hint to Max to make smaller portions of changes.

I would like to contribute a fix for JDK-6372077 which is about 
JarFile.getManifest() should handle manifest attribute name[s longer 
than] 70 bytes.

It looks like the bug is caused by Manifest.make72Safe breaking lines at 
70 bytes instead of 72 despite its comment and name 
(http://hg.openjdk.java.net/jdk10/master/file/tip/src/java.base/share/classes/java/util/jar/Manifest.java#l176).The 
resulting StringBuffer has then lines of 72 bytes maximum each including 
the following line break. Without the line break that leaves 70 bytes of 
characters per line. On the other hand, header names can be up to 70 
bytes (only single-byte utf-8 characters) and cannot be broken across a 
line break and need to be followed by a colon and a space which must be 
on the same line too according to the specification. When breaking at 70 
bytes excluding the line break, however, long header names don't fit in 
one line together with the colon space delimiter because there is not 
sufficient space.
Manifests with names up to 70 bytes long can still be written without 
immediate exception but the resulting manifests are illegal in my 
opinion. When later reading such manifests 
(http://hg.openjdk.java.net/jdk10/master/file/tip/src/java.base/share/classes/java/util/jar/Attributes.java#l406), 
an error occurs as a consequence of the bad manifest. This is more or 
less the current situation and also what JDK-6372077 already knew.

  --> After all, in order to fix it, i'd like to propose to make 
manifest file lines wider by two bytes.

The only proper alternative that came into my mind would be to change 
the manifest specification and reduce the maximum header name length 
there by two and also in the code. If that would break any existing code 
i guess that would affect code only that produced invalid manifests and 
would be acceptable.

Supporting all existing and possibly invalid manifests would mean to add 
support for reading headers the delimiters of which are broken onto the 
next line which I consider too complex with respect to the value added 
and even more so considering that those invalid manifest can be assumed 
to have been detected as such by reading them and also because it would 
be a feature that would be used less and less over time if the code to 
write manifest is changed at the same time to produce only valid 
manifests in the discussed respect here. I don't think this should be 
actually done.

Before I actually do the leg work, i'd like to ask, if there are 
concerns or objections or tips for such a change or if anyone can or 
cannot follow the reasoning and the conclusion to make manifests 2 bytes 
wider or if i missed an important point altogether.

In case there will be a consent about how to solve this, would someone 
volunteer to sponsor? That may be less urgent at the moment than the 
question above about how to proceed.

Philipp


On 12.10.2017 22:32, Sean Mullan wrote:
> Hi Phillip,
>
> All of these bugs are in the core-libs area, so I am copying the 
> core-libs-dev list since that is where they should be discussed and 
> reviewed. I have -bcc-ed security-dev (where this was originally posted).
>
> --Sean
>
> On 10/2/17 1:24 PM, Philipp Kunz wrote:
>> Hi,
>>
>> While fixing JDK-6695402 I came across other related bugs to 
>> manifests such as JDK-6372077, JDK-6202130, JDK-8176843, JDK-4842483, 
>> and JDK-6443578 which all relate to manifest reading and writing. 
>> Somewhere bug 7071055 is mentioned but I cannot find anywhere. 
>> Another group of bugs, JDK-6910466, JDK-4935610, and JDK-4271239 
>> concern the mandatory manifest main attributes Manifest-Version or 
>> Signature-Version and at first glance are duplicates. If you know of 
>> more known bugs, not necessarily present in jira, I'd be glad to get 
>> notified.
>>
>> There are also some comments about utf handling and line breaking in 
>> the code of Manifest:
>> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l299 
>>
>> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l327 
>>
>> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l370 
>>
>>
>> Furthermore, Attributes.map should declare appropriate type parameters:
>> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l61 
>>
>> The specification would also require that `header names must not 
>> start with _, - or "From"` 
>> (http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Section-Specification) 
>> but I would opt not to add this as a hard restriction because I guess 
>> it can be assumed that such names are in use now after having been 
>> working for years. A warning to a logger might be conceivable such as in
>> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l424 
>>
>> Attribute values are never checked at all and invalid characters such 
>> as line breaks are never detected except that when reading the 
>> manifest again the values are cut off.
>> The tab character (U+0008) does not work in manifest values.
>> I suspect that there are also issues regarding the iteration order 
>> but I haven't got a prove yet unlike for the other points above:
>> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Manifest.java#l54 
>>
>> There is duplicated or very similar code in Attributes and Manifest: 
>> Attributes.write-Manifest.write-Attributes.writeMain and 
>> Attributes.read-Manifest.read.
>> Resolving JDK-6202130 would have the additional benefit to be able to 
>> view manifests with any utf-8 capable editor even if multi-byte 
>> characters break across lines.
>>
>> Fixing these issues individually looks like more complicated work 
>> than fixing them all at once, I guess, also because of a very low 
>> current test coverage. So I'd suggest to add some thorough tests 
>> along with fixing these issues. But before I start I would like to 
>> get some guidance, assistance or at least confirmation on how to 
>> proceed. I'm new to open jdk and have submitted only one patch so far.
>>
>> Is it ok to add tests for things that have worked before?
>> Is it ok to refactor duplicated code just for the added value to 
>> reduce effort for testing?
>> I assume compatibility to and from existing manifests is the highest 
>> priority, correct? This would also be the hard part in adding as 
>> complete test coverage as possible. What would be acceptable criteria 
>> to meet?
>> Why does Attributes not extend LinkedHashMap and why does Manifest 
>> not extend HashMap? Any objection?
>> While I would not want to write code that looks slow or change more 
>> than necessary one can never know before having performance actually 
>> measured. Is there some way this is dealt with or should I wait for 
>> such feedback until after patch submission?
>>
>> Would someone sponsor?
>>
>> Regards,
>> Philipp
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> Paratix GmbH
>> St Peterhofstatt 11
>> 8001 Z?rich
>>
>> +41 (0)76 397 79 35
>> philipp.kunz at paratix.ch <mailto:philipp.kunz at paratix.ch>

-- 


Gruss Philipp



------------------------------------------------------------------------



Paratix GmbH
St Peterhofstatt 11
8001 Z?rich

+41 (0)76 397 79 35
philipp.kunz at paratix.ch <mailto:philipp.kunz at paratix.ch>

From claes.redestad at oracle.com  Thu Nov  2 23:25:11 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 3 Nov 2017 00:25:11 +0100
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <603EF3CC-F789-4D06-9295-DBD948493692@oracle.com>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
 <F9C4D58D-41C7-494E-ADD7-F7DFD49A0BF8@oracle.com>
 <012d01d35419$d48bbe80$7da33b80$@freenet.de>
 <90EA3CF8-5E39-4E75-91AB-4C7432E8044B@oracle.com>
 <013001d35425$f8b9ddd0$ea2d9970$@freenet.de>
 <603EF3CC-F789-4D06-9295-DBD948493692@oracle.com>
Message-ID: <fb9bf496-ebd0-f852-f14e-28c4319aa449@oracle.com>



On 2017-11-02 23:13, John Rose wrote:
> On Nov 2, 2017, at 3:00 PM, Christoph Dreis 
> <christoph.dreis at freenet.de <mailto:christoph.dreis at freenet.de>> wrote:
>>
>> Thanks for the clarification. Actually the more important concern was 
>> to get rid of unnecessary allocations that the cloning inside 
>> Executable.getParameterTypes() is producing. As Claes mentioned 
>> experience and experiments show that JIT's escaping mechanisms fail 
>> from time to time on this one. And if you ask me it is not good 
>> practice to rely on the compiler optimizations anyhow, but that's 
>> maybe just me.
>>
>> I do like your proposal nonetheless as an additional improvement, but 
>> I think it won't achieve the allocation-free part I was aiming for. 
>> Correct me if I'm wrong, please.
>
> There are two ways it can directly achieve what you are after.
>
> First, if the guts of the jlr.Method can cache the List and return
> the same value every time. ?Then the legacy API point can use
> List::toArray to create the legacy array values.
>
> Second, if the guts of the jlr.Method choose to cache the Class[],
> it can still return a List wrapped around the same array, each time,
> as long as the List refuses modification.
>
> Either option avoids the O(N) copying and avoids problems
> with escape analysis. ?The second option has O(1) allocation,
> the first does zero allocation.
>
> The first option also allows constant propagation through the
> List.of values, something that arrays can never do (until we
> introduce frozen arrays). ?This bit of magic is one of several
> reasons people who program with arrays should try to move
> over to lists. ?It is enabled by the private annotation @Stable.
>
> ? John

I like the first option, and it'd be a nice extra to allow consumers to
move forward from a 90s to an early 2000s programming model. :-)

One drawback is that this would be a somewhat larger effort to a
piece of sensitive, legacy code, but my gut feeling is that by moving
over from arrays to immutable Lists we are likely to reduce risk of
certain bugs creeping in.

/Claes

From christoph.dreis at freenet.de  Thu Nov  2 23:33:41 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Fri, 3 Nov 2017 00:33:41 +0100
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <603EF3CC-F789-4D06-9295-DBD948493692@oracle.com>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
 <F9C4D58D-41C7-494E-ADD7-F7DFD49A0BF8@oracle.com>
 <012d01d35419$d48bbe80$7da33b80$@freenet.de>
 <90EA3CF8-5E39-4E75-91AB-4C7432E8044B@oracle.com>
 <013001d35425$f8b9ddd0$ea2d9970$@freenet.de>
 <603EF3CC-F789-4D06-9295-DBD948493692@oracle.com>
Message-ID: <000001d35433$04f2c280$0ed84780$@freenet.de>

Hi John,

>> I do like your proposal nonetheless as an additional improvement, but I think it won't achieve the allocation-free part I was aiming for. Correct me if I'm wrong, please.

> There are two ways it can directly achieve what you are after.
> First, if the guts of the jlr.Method can cache the List and return
> the same value every time.  Then the legacy API point can use
> List::toArray to create the legacy array values.
> Second, if the guts of the jlr.Method choose to cache the Class[],
> it can still return a List wrapped around the same array, each time,
> as long as the List refuses modification.

Again - thank you for sharing your thoughts. I really like your first proposal of caching the parameter list. I am bit concerned though that this has a bigger impact on the overall footprint of Method/Executable objects. What are your thoughts on this?

Cheers,
Christoph



From christoph.dreis at freenet.de  Fri Nov  3 00:55:59 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Fri, 3 Nov 2017 01:55:59 +0100
Subject: [Patch][JDK10] Use Class.getPackageName() where possible
Message-ID: <000101d3543e$840b6080$8c222180$@freenet.de>

Hey,

I noticed two places in the codebase that could call JDK 9's new method
Class.getPackageName().

Would be happy if this is sponsored in case the patch is correct.

Cheers,
Christoph

====== PATCH =======
diff -r 438e0c9f2f17
src/java.base/share/classes/java/io/ObjectStreamClass.java
--- a/src/java.base/share/classes/java/io/ObjectStreamClass.java	Mon
Oct 30 17:49:33 2017 -0700
+++ b/src/java.base/share/classes/java/io/ObjectStreamClass.java	Fri
Nov 03 01:47:04 2017 +0100
@@ -1587,11 +1587,7 @@
      * Returns package name of given class.
      */
     private static String getPackageName(Class<?> cl) {
-        String s = cl.getName();
-        int i = s.lastIndexOf('[');
-        i = (i < 0) ? 0 : i + 2;
-        int j = s.lastIndexOf('.');
-        return (i < j) ? s.substring(i, j) : "";
+        return cl.getPackageName();
     }
 
     /**
diff -r 438e0c9f2f17
src/java.base/share/classes/java/lang/reflect/Proxy.java
--- a/src/java.base/share/classes/java/lang/reflect/Proxy.java	Mon Oct 30
17:49:33 2017 -0700
+++ b/src/java.base/share/classes/java/lang/reflect/Proxy.java	Fri Nov 03
01:47:04 2017 +0100
@@ -1034,11 +1034,8 @@
 
                 // do permission check if the caller is in a different
runtime package
                 // of the proxy class
-                int n = proxyClass.getName().lastIndexOf('.');
-                String pkg = (n == -1) ? "" :
proxyClass.getName().substring(0, n);
-
-                n = caller.getName().lastIndexOf('.');
-                String callerPkg = (n == -1) ? "" :
caller.getName().substring(0, n);
+                String pkg = proxyClass.getPackageName();
+                String callerPkg = caller.getPackageName();
 
                 if (pcl != ccl || !pkg.equals(callerPkg)) {
                     sm.checkPermission(new
ReflectPermission("newProxyInPackage." + pkg));


From john.r.rose at oracle.com  Fri Nov  3 00:59:46 2017
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 2 Nov 2017 17:59:46 -0700
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <000001d35433$04f2c280$0ed84780$@freenet.de>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
 <F9C4D58D-41C7-494E-ADD7-F7DFD49A0BF8@oracle.com>
 <012d01d35419$d48bbe80$7da33b80$@freenet.de>
 <90EA3CF8-5E39-4E75-91AB-4C7432E8044B@oracle.com>
 <013001d35425$f8b9ddd0$ea2d9970$@freenet.de>
 <603EF3CC-F789-4D06-9295-DBD948493692@oracle.com>
 <000001d35433$04f2c280$0ed84780$@freenet.de>
Message-ID: <D6817D33-993C-48C3-8B84-A39C8177FE2C@oracle.com>

On Nov 2, 2017, at 4:33 PM, Christoph Dreis <christoph.dreis at freenet.de> wrote:
> 
> this has a bigger impact on the overall footprint of Method/Executable objects. What are your thoughts on this?

The footprint is probably about the same.  Small List.of values
do not contain arrays, and may be smaller than arrays with the
same number of elements, since they do not have a length field.
And, indeed, methods typically have a small number of parameters.

See the type java.lang.util.ImmutableCollections.List2 for an
example of an array-free data structure.

? John

From mandy.chung at oracle.com  Fri Nov  3 03:23:08 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 2 Nov 2017 20:23:08 -0700
Subject: [Patch][JDK10] Use Class.getPackageName() where possible
In-Reply-To: <000101d3543e$840b6080$8c222180$@freenet.de>
References: <000101d3543e$840b6080$8c222180$@freenet.de>
Message-ID: <72043f40-6a9c-f79a-66be-5e68e6ce1f0c@oracle.com>



On 11/2/17 5:55 PM, Christoph Dreis wrote:
> Hey,
>
> I noticed two places in the codebase that could call JDK 9's new method
> Class.getPackageName().

It's good to see JDK code be updated to use Class::getPackageName. One 
thing to pay attention is that Class.getPackageName() returns 
"java.lang" for primitive type and void.? Your patch fixing 
ObjectStreamClass::getPackageName and Proxy::checkNewProxyPermission 
look fine.

There are other places that can be converted.? Do you mind updating 
java.io.ObjectInputFilter::matchesPackage and 
ClassLoader::checkPackageAccess??? I may miss there are other places in 
java.base.

I can sponsor this once you have an updated patch.

Mandy

> Would be happy if this is sponsored in case the patch is correct.
>
> Cheers,
> Christoph
>
> ====== PATCH =======
> diff -r 438e0c9f2f17
> src/java.base/share/classes/java/io/ObjectStreamClass.java
> --- a/src/java.base/share/classes/java/io/ObjectStreamClass.java	Mon
> Oct 30 17:49:33 2017 -0700
> +++ b/src/java.base/share/classes/java/io/ObjectStreamClass.java	Fri
> Nov 03 01:47:04 2017 +0100
> @@ -1587,11 +1587,7 @@
>        * Returns package name of given class.
>        */
>       private static String getPackageName(Class<?> cl) {
> -        String s = cl.getName();
> -        int i = s.lastIndexOf('[');
> -        i = (i < 0) ? 0 : i + 2;
> -        int j = s.lastIndexOf('.');
> -        return (i < j) ? s.substring(i, j) : "";
> +        return cl.getPackageName();
>       }
>   
>       /**
> diff -r 438e0c9f2f17
> src/java.base/share/classes/java/lang/reflect/Proxy.java
> --- a/src/java.base/share/classes/java/lang/reflect/Proxy.java	Mon Oct 30
> 17:49:33 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/reflect/Proxy.java	Fri Nov 03
> 01:47:04 2017 +0100
> @@ -1034,11 +1034,8 @@
>   
>                   // do permission check if the caller is in a different
> runtime package
>                   // of the proxy class
> -                int n = proxyClass.getName().lastIndexOf('.');
> -                String pkg = (n == -1) ? "" :
> proxyClass.getName().substring(0, n);
> -
> -                n = caller.getName().lastIndexOf('.');
> -                String callerPkg = (n == -1) ? "" :
> caller.getName().substring(0, n);
> +                String pkg = proxyClass.getPackageName();
> +                String callerPkg = caller.getPackageName();
>   
>                   if (pcl != ccl || !pkg.equals(callerPkg)) {
>                       sm.checkPermission(new
> ReflectPermission("newProxyInPackage." + pkg));
>


From patrick at reini.net  Fri Nov  3 05:26:12 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Fri, 3 Nov 2017 06:26:12 +0100
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <a76d535f-7e92-5700-8cb9-2b254eee2153@Oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <AM4PR08MB12199717DB39BAA682DE5B3BFF5F0@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <3ea78605-b083-1fcc-3cb8-1adc6d76d045@oracle.com>
 <1B0724CA-ADB2-432A-9004-B0A9C6B74F6E@reini.net>
 <CAGB9EW-Zpd4D5Hc1ri4vPjnVQQ1zG7hifHoe=6cYr7zEB2r0Gg@mail.gmail.com>
 <85BE47B6-2214-43AD-B7D0-01F846E42EED@reini.net>
 <a76d535f-7e92-5700-8cb9-2b254eee2153@Oracle.com>
Message-ID: <ad9c1a86-9ff0-4247-ddcb-00e4d6e80f65@reini.net>

Am 02.11.2017 um 20:08 schrieb Roger Riggs:
> Hi,
>
> It would also support a more fluent use of the APIs.? Though if we
> start down that road
> it may become littered with convenience methods.? Something to ponder
> for a bit.
>
One one hand I see your obligation, on the other hand we would open the
chance to write
more optimal implementations for a library implementers though. That
seems to me also
an considerable point here. For instance an unmodifiable List could
basically return a fast
copy of itself here using an internal constructor passing the values
from itself or a Set
implementation has not to check for duplicate entries or similar.

-Patrick

>
>
> On 11/1/2017 4:29 PM, Patrick Reinhart wrote:
>> In this case I would prefer a non static copyOf() method on the list
>> to create a unmodifiable list/set/map, where the optimal factory
>> method can be called. This would also solve the problem of a
>> concurrent implementation.
>>
>> -Patrick
>>
>>
>>> Am 01.11.2017 um 21:05 schrieb Louis Wasserman <lowasser at google.com>:
>>>
>>> I disagree, actually.? Collections with size zero and one are
>>> significantly more common than bigger collections.
>>>
>>> In Guava's immutable collection factories (ImmutableList.of(...)
>>> etc.), we observed a roughly exponential decline in the number of
>>> users of factory methods of each size: if N people created empty
>>> lists, ~N/2 created singleton lists, ~N/4 created two-element lists,
>>> etc.? We got noticeable pushback from RAM-sensitive customers when
>>> we eliminated some specialized singleton collection implementations.
>>>
>>> Our experience has been that specializing for N=0 and N=1 does pay
>>> off.? Probably not N=2, though?
>>>
>>> On Wed, Nov 1, 2017 at 12:45 PM Patrick Reinhart <patrick at reini.net
>>> <mailto:patrick at reini.net>> wrote:
>>>
>>>> Am 01.11.2017 um 20:25 schrieb Stuart Marks
>>>> <stuart.marks at oracle.com <mailto:stuart.marks at oracle.com>>:
>>>>
>>>> On 10/31/17 5:52 PM, Bernd Eckenfels wrote:
>>>>> Having a List.of(List) copy constructor would save an additional
>>>>> array copy in the collector Which uses?
>>>>> (List<T>)List.of(list.toArray())
>>>> The quickest way to get all the elements from the source collection
>>>> is to call toArray() on it. Some copy constructors (like
>>>> ArrayList's) simply use the returned array for internal storage.
>>>> This saves a copy, but it relies on the source collection's
>>>> toArray() implementation to be correct. In particular, the returned
>>>> array must be freshly created, and that array must be of type
>>>> Object[]. If either of these is violated, it will break the ArrayList.
>>>>
>>>> The "immutable" collections behind List.of/copyOf/etc. are
>>>> fastidious about allocating their internal arrays in order to
>>>> ensure that they are referenced only from within the newly created
>>>> collection. This requires making an ?extra" copy of the array
>>>> returned by toArray().
>>>>
>>>> An alternative is for the new collection to preallocate its
>>>> internal array using the source's size(), and then to copy the
>>>> elements out. But the source?s
>>>> size might change during the copy (e.g., if it?s a concurrent
>>>> collection) so this complicates things.
>>> I think the array ?overhead? would be only for the cases of zero,
>>> one and two value implementations. That seems to me not worth of
>>> optimizing?
>>>
>>>> I think the only safe way to avoid the extra copy is to create a
>>>> private interface that can be used by JDK implementations.
>>>>
>>>> s'marks
>>> -Patrick
>



From christoph.dreis at freenet.de  Fri Nov  3 08:06:38 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Fri, 3 Nov 2017 09:06:38 +0100
Subject: [Patch][JDK10] Use Class.getPackageName() where possible
In-Reply-To: <72043f40-6a9c-f79a-66be-5e68e6ce1f0c@oracle.com>
References: <000101d3543e$840b6080$8c222180$@freenet.de>
 <72043f40-6a9c-f79a-66be-5e68e6ce1f0c@oracle.com>
Message-ID: <000c01d3547a$ad4d6470$07e82d50$@freenet.de>

Hi Mandy,

> It's good to see JDK code be updated to use Class::getPackageName.  One thing to pay attention is that Class.getPackageName() returns "java.lang" for primitive type and void.  Your patch fixing ObjectStreamClass::getPackageName and Proxy::checkNewProxyPermission look fine.
> There are other places that can be converted.  Do you mind updating java.io.ObjectInputFilter::matchesPackage and ClassLoader::checkPackageAccess?   I may miss there are other places in java.base.

Thanks - I updated both as you suggested to use Class::getPackageName. Please find the updated patch below.

There is also a public static VerifyAccess::getPackageName which seems to be not working with arrays at all and as far as I can see is at least not used inside the JDK itself.
Should this be deprecated maybe in favor of Class.getPackageName() or also adjusted to use it (which would mean different return values than before as you already noted)?

Cheers,
Christoph

====== PATCH =======
diff -r 438e0c9f2f17 src/java.base/share/classes/java/io/ObjectInputFilter.java
--- a/src/java.base/share/classes/java/io/ObjectInputFilter.java	Mon Oct 30 17:49:33 2017 -0700
+++ b/src/java.base/share/classes/java/io/ObjectInputFilter.java	Fri Nov 03 08:38:15 2017 +0100
@@ -656,8 +656,8 @@
              * otherwise {@code false}
              */
             private static boolean matchesPackage(Class<?> c, String pkg) {
-                String n = c.getName();
-                return n.startsWith(pkg) && n.lastIndexOf('.') == pkg.length() - 1;
+                String n = c.getPackageName();
+                return n.length() == pkg.length() - 1 && n.startsWith(pkg);
             }
 
             /**

diff -r 438e0c9f2f17 src/java.base/share/classes/java/io/ObjectStreamClass.java
--- a/src/java.base/share/classes/java/io/ObjectStreamClass.java	Mon Oct 30 17:49:33 2017 -0700
+++ b/src/java.base/share/classes/java/io/ObjectStreamClass.java	Fri Nov 03 08:38:15 2017 +0100
@@ -1587,11 +1587,7 @@
      * Returns package name of given class.
      */
     private static String getPackageName(Class<?> cl) {
-        String s = cl.getName();
-        int i = s.lastIndexOf('[');
-        i = (i < 0) ? 0 : i + 2;
-        int j = s.lastIndexOf('.');
-        return (i < j) ? s.substring(i, j) : "";
+        return cl.getPackageName();
     }
 
     /**

diff -r 438e0c9f2f17 src/java.base/share/classes/java/lang/ClassLoader.java
--- a/src/java.base/share/classes/java/lang/ClassLoader.java	Mon Oct 30 17:49:33 2017 -0700
+++ b/src/java.base/share/classes/java/lang/ClassLoader.java	Fri Nov 03 08:38:15 2017 +0100
@@ -672,12 +672,11 @@
                 return;
             }
 
-            final String name = cls.getName();
-            final int i = name.lastIndexOf('.');
-            if (i != -1) {
+            final String packageName = cls.getPackageName();
+            if (!packageName.isEmpty()) {
                 AccessController.doPrivileged(new PrivilegedAction<>() {
                     public Void run() {
-                        sm.checkPackageAccess(name.substring(0, i));
+                        sm.checkPackageAccess(packageName);
                         return null;
                     }
                 }, new AccessControlContext(new ProtectionDomain[] {pd}));

diff -r 438e0c9f2f17 src/java.base/share/classes/java/lang/reflect/Proxy.java
--- a/src/java.base/share/classes/java/lang/reflect/Proxy.java	Mon Oct 30 17:49:33 2017 -0700
+++ b/src/java.base/share/classes/java/lang/reflect/Proxy.java	Fri Nov 03 08:38:15 2017 +0100
@@ -1034,11 +1034,8 @@
 
                 // do permission check if the caller is in a different runtime package
                 // of the proxy class
-                int n = proxyClass.getName().lastIndexOf('.');
-                String pkg = (n == -1) ? "" : proxyClass.getName().substring(0, n);
-
-                n = caller.getName().lastIndexOf('.');
-                String callerPkg = (n == -1) ? "" : caller.getName().substring(0, n);
+                String pkg = proxyClass.getPackageName();
+                String callerPkg = caller.getPackageName();
 
                 if (pcl != ccl || !pkg.equals(callerPkg)) {
                     sm.checkPermission(new ReflectPermission("newProxyInPackage." + pkg));



From christoph.dreis at freenet.de  Fri Nov  3 08:11:48 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Fri, 3 Nov 2017 09:11:48 +0100
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <D6817D33-993C-48C3-8B84-A39C8177FE2C@oracle.com>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
 <F9C4D58D-41C7-494E-ADD7-F7DFD49A0BF8@oracle.com>
 <012d01d35419$d48bbe80$7da33b80$@freenet.de>
 <90EA3CF8-5E39-4E75-91AB-4C7432E8044B@oracle.com>
 <013001d35425$f8b9ddd0$ea2d9970$@freenet.de>
 <603EF3CC-F789-4D06-9295-DBD948493692@oracle.com>
 <000001d35433$04f2c280$0ed84780$@freenet.de>
 <D6817D33-993C-48C3-8B84-A39C8177FE2C@oracle.com>
Message-ID: <000d01d3547b$664bf180$32e3d480$@freenet.de>

Hi John,

>> this has a bigger impact on the overall footprint of Method/Executable objects. What are your thoughts on this?

> The footprint is probably about the same.  Small List.of values
> do not contain arrays, and may be smaller than arrays with the
> same number of elements, since they do not have a length field.
> And, indeed, methods typically have a small number of parameters.

Ah, so you would remove the current array field completely and replace it with the immutable List, right?
In that case I said nothing. I was thinking of a field on top.

Cheers,
Christoph


From peter.levart at gmail.com  Fri Nov  3 08:48:25 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 3 Nov 2017 09:48:25 +0100
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <59FA1DD3.2090604@oracle.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
 <59F7735A.3000501@oracle.com>
 <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>
 <59F7B6A1.5040303@oracle.com>
 <16e98d55-35c0-a039-edf5-95240bed2510@gmail.com>
 <59F90664.9050403@oracle.com>
 <5b2ec510-7420-142f-eb96-6d851bb049eb@gmail.com>
 <59FA1DD3.2090604@oracle.com>
Message-ID: <78b4d19c-28cb-4552-67de-cb0bf0cadf62@gmail.com>

Hi Sherman,

I think this looks good now. Thanks.

Regards, Peter

On 11/01/2017 08:17 PM, Xueming Shen wrote:
> Hi Peter,
>
> I like the idea of moving get/releaseInflter() into CleanableResource, 
> though I doubt
> how much it can really help the GC it should be a good thing to do to 
> remove the strong
> reference of ZipFile from stream's cleaner, and the code appears a 
> little cleaner as well.
>
> I was debating with myself whether or not the ZipFile.close() should 
> throw an
> UncheckedIOException (like those java.nio.file.Files methods do). But 
> you're right it's
> not good to simply ignoring them silently. Now I catch/unwarp the 
> potential
> UncheckedIOException from res.clean() and re-throw the embedded ioe.
>
> I need to dig a little to recall the real reason of zsrc==null check 
> in ensureOpen()
> the comment does not sound updated. res.zsrc is not final and it is 
> set to null
> when clean up/close. So I keep it for now.
>
> Most (if not all?) "minor nit" has been updated accordingly.
>
> It seems like we might have have put the "finalize()" method back as 
> an empty-body
> method for compatibility reason. So not done yet :-)
>
> http://cr.openjdk.java.net/~sherman/8185582/webrev/
>
> thanks,
> sherman
>
> On 11/1/17, 5:04 AM, Peter Levart wrote:
>> Hi Sherman,
>>
>> On 11/01/17 00:25, Xueming Shen wrote:
>>> Hi Peter,
>>>
>>> After tried couple implementations it seems the most reasonable 
>>> approach is to
>>> use the coding pattern you suggested to move all pieces into 
>>> ZSStream Ref. Given
>>> we are already using the internal API CleanerFactory it is 
>>> attractive to go a little
>>> further to subclass PhantomCleanable directly (in which I would 
>>> assume we can
>>> save one extra object), but I think I'd better to follow the 
>>> "suggested" clean usage
>>> (to register a runnable into the cleaner) for now.
>>>
>>> ? 39 class ZStreamRef implements Runnable {
>>> ? 40
>>> ? 41???? private LongConsumer end;
>>> ? 42???? private volatile long address;
>>> ? 43???? private final Cleanable cleanable;
>>> ? 44
>>> ? 45???? ZStreamRef (Object owner, LongSupplier addr, LongConsumer 
>>> end) {
>>> ? 46???????? this.cleanable = 
>>> CleanerFactory.cleaner().register(owner, this);
>>> ? 47???????? this.end = end;
>>> ? 48???????? this.address = addr.getAsLong();
>>> ? 49???? }
>>> ? 50
>>>
>>> Similar change has been made for the ZipFile cleaner to follow the 
>>> same coding
>>> pattern. The "cleaner" is now renamed from Releaser to 
>>> CleanableResource.
>>>
>>> http://cr.openjdk.java.net/~sherman/8185582/webrev/
>>>
>>> Thanks,
>>> Sherman
>>
>> This looks mostly fine. One minor nit is that ZStreamRef.address 
>> field does not have to be volatile. I checked all usages of 
>> ZStreamRef.address() and all of them invoke it while holding a lock 
>> on the ZStreamRef instance. The ZStreamRef.run() which modifies the 
>> address is also synchronized. The other minor nit is that the 
>> following ZipFile imports are not needed:
>>
>> import java.nio.file.Path;
>> import java.util.Map;
>> import jdk.internal.misc.JavaIORandomAccessFileAccess;
>> import static java.util.zip.ZipConstants.*;
>>
>> (at least my IDEA colors them unused)
>>
>> Cleaner is modified in this webrev (just one empty line deleted) - 
>> better not touch this file in this changeset
>>
>> Additional nits in ZipFile:
>>
>> - in lines 355, 356 you pull out two res fields into locals, but then 
>> not use them consistently (lines 372, 389)
>> - line 403 has a TAB character (is this OK?) and shows incorrectly 
>> indented in my editor (should I set tab stops differently?)
>> - line 457 - while should actually be if ?
>> - in ensureOpen() the check for res.zsrc == null can never succeed 
>> (CleanableResource.zsrc is a final field. If CleanableResource 
>> constructor fails, there's no res object and there's no ZipFile 
>> object either as ZipFile constructor does not do anything for this to 
>> escape prematurely)
>> - why don't you let IOExceptions thrown from CleanableResource.run() 
>> propagate out of ZipFile.close() ?
>>
>> I would also rename static method Source.close(Source) to 
>> Source.release(Source) so it would not clash with instance method 
>> Source.close() which makes it ambiguous when one wants to use 
>> Source::close method reference (both methods apply). I would also 
>> make static methods Source.get() and Source.release(Source) 
>> package-private (currently one is public and the other is private, 
>> which needs compiler bridges to be invoked) and both are in a private 
>> nested class.
>>
>> Inflater/Deflater/ZipFile now follow the coding pattern as suggested. 
>> But ZipFileInflaterInputStream still does not. It's not critical 
>> since failing to register cleanup which releases the inflater back 
>> into cache would simply mean that Inflater employs its own cleanup 
>> and ends itself.
>>
>> And now another thing I would like to discuss. Why an initiative for 
>> using Cleaner instead of finalization()? Among drawbacks finalization 
>> has one of the more troubling is that the tracked referent survives 
>> the GC cycle that initiates its finalization reference processing 
>> pipeline, so the GC may reclaim the object (and referenced objects) 
>> only after the finalize() has finished in yet another GC round. 
>> Cleaner API separates the tracked object from the cleanup function 
>> and state needed to perform it into distinct instances. The tracked 
>> object can be reclaimed and the cleanup reference processing pipeline 
>> initiated in the same GC cycle. More heap may be reclaimed earlier.
>>
>> Unless we are careful and create a cleaning function for one tracked 
>> object which captures (directly or indirectly) another object which 
>> registers its own cleaning function but we don't deal with explicit 
>> cleaning of the 2nd object in the 1st cleaning function.
>>
>> Take for example the ZipFileInflaterInputStream's cleaning function. 
>> It captures the ZipFile in order to invoke ZipFile.releaseInflater 
>> instance method. What this means is that ZipFile will be kept 
>> reachable until all ZipFileInflaterInputStream's cleaning functions 
>> have fired. So we are back to the finalization drawback which needs 
>> at least 2 GC cycles to collect and clean-up what might be done in 
>> one go.
>>
>> I suggest moving the getInflater() and releaseInflater() from ZipFile 
>> into the CleanableResource so that ZipFileInflaterInputStream's 
>> cleaning function captures just the CleanableResource and not the 
>> ZipFile. ZipFile therefore may become eligible for cleanup as soon as 
>> all opened input streams become eligible (but their cleaning 
>> functions need not have fired yet). CleanableResource.run() (the 
>> ZipFile cleaning function) and CleanableResource.releaseInflater() 
>> (the ZipFileInflaterInputStream's cleaning function) may therefore be 
>> invoked in arbitrary order (maybe even concurrently if one of them is 
>> explicit cleanup and the other is automatic), so code must be 
>> prepared for that.
>>
>> I have tried to capture all above in a modified webrev (taking your 
>> last webrev as a base):
>>
>> http://cr.openjdk.java.net/~plevart/jdk10-dev/8185582_ZIP.cleaner/webrev.03/
>>
>>
>> Regards, Peter
>>
>


From Alan.Bateman at oracle.com  Fri Nov  3 12:49:33 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 3 Nov 2017 12:49:33 +0000
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
Message-ID: <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>

On 02/11/2017 19:55, Patrick Reinhart wrote:
> :
> If we are all happy with the API so far, I could start adding an initial implementation and test?
>
I think the API looks fine so go ahead.

-Alan

From Alan.Bateman at oracle.com  Fri Nov  3 13:17:52 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 3 Nov 2017 13:17:52 +0000
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <000d01d3547b$664bf180$32e3d480$@freenet.de>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
 <F9C4D58D-41C7-494E-ADD7-F7DFD49A0BF8@oracle.com>
 <012d01d35419$d48bbe80$7da33b80$@freenet.de>
 <90EA3CF8-5E39-4E75-91AB-4C7432E8044B@oracle.com>
 <013001d35425$f8b9ddd0$ea2d9970$@freenet.de>
 <603EF3CC-F789-4D06-9295-DBD948493692@oracle.com>
 <000001d35433$04f2c280$0ed84780$@freenet.de>
 <D6817D33-993C-48C3-8B84-A39C8177FE2C@oracle.com>
 <000d01d3547b$664bf180$32e3d480$@freenet.de>
Message-ID: <065ff3b8-7967-594d-7d60-0006f8d48eb3@oracle.com>

On 03/11/2017 08:11, Christoph Dreis wrote:
> Hi John,
>
>>> this has a bigger impact on the overall footprint of Method/Executable objects. What are your thoughts on this?
>> The footprint is probably about the same.  Small List.of values
>> do not contain arrays, and may be smaller than arrays with the
>> same number of elements, since they do not have a length field.
>> And, indeed, methods typically have a small number of parameters.
> Ah, so you would remove the current array field completely and replace it with the immutable List, right?
> In that case I said nothing. I was thinking of a field on top.
>
The VM creates Method objects and sets the fields, including 
parameterTypes, directly so I think removing it would require more work 
than it initially looks. If you add a field then it does increase the 
footprint a bit. Alternatively, have the method could use a 
ImmutableCollection.ListN like implementation that is backed by the 
array and doesn't scan it for nulls at create time, this wouldn't be 
completely allocation free of course.

In any case, the proposed API does look reasonable although it 
deviations from the usual conventions in java.lang.reflect.

-Alan

From claes.redestad at oracle.com  Fri Nov  3 14:41:27 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 3 Nov 2017 15:41:27 +0100
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <065ff3b8-7967-594d-7d60-0006f8d48eb3@oracle.com>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
 <F9C4D58D-41C7-494E-ADD7-F7DFD49A0BF8@oracle.com>
 <012d01d35419$d48bbe80$7da33b80$@freenet.de>
 <90EA3CF8-5E39-4E75-91AB-4C7432E8044B@oracle.com>
 <013001d35425$f8b9ddd0$ea2d9970$@freenet.de>
 <603EF3CC-F789-4D06-9295-DBD948493692@oracle.com>
 <000001d35433$04f2c280$0ed84780$@freenet.de>
 <D6817D33-993C-48C3-8B84-A39C8177FE2C@oracle.com>
 <000d01d3547b$664bf180$32e3d480$@freenet.de>
 <065ff3b8-7967-594d-7d60-0006f8d48eb3@oracle.com>
Message-ID: <ae1b8914-66f3-1060-e9c8-f1c9429bc35b@oracle.com>



On 2017-11-03 14:17, Alan Bateman wrote:
> On 03/11/2017 08:11, Christoph Dreis wrote:
>> Hi John,
>>
>>>> this has a bigger impact on the overall footprint of 
>>>> Method/Executable objects. What are your thoughts on this?
>>> The footprint is probably about the same.? Small List.of values
>>> do not contain arrays, and may be smaller than arrays with the
>>> same number of elements, since they do not have a length field.
>>> And, indeed, methods typically have a small number of parameters.
>> Ah, so you would remove the current array field completely and 
>> replace it with the immutable List, right?
>> In that case I said nothing. I was thinking of a field on top.
>>
> The VM creates Method objects and sets the fields, including 
> parameterTypes, directly so I think removing it would require more 
> work than it initially looks. If you add a field then it does increase 
> the footprint a bit. Alternatively, have the method could use a 
> ImmutableCollection.ListN like implementation that is backed by the 
> array and doesn't scan it for nulls at create time, this wouldn't be 
> completely allocation free of course.

While it would be pretty sweet if we could train the VM to use List.of 
as appropriate (might be applicable in a number of places where we want 
to communicate immutable array-like data from the VM), it should be 
pretty straightforward to change the interaction so that the VM calls a 
private method that takes the parameter array and turns it into a List.

My guess is that the superfluous null checking will be hardly measurable 
even in micros.

> In any case, the proposed API does look reasonable although it 
> deviations from the usual conventions in java.lang.reflect.

I agree the getParameterType(index) method should still up for 
consideration if we can't act on the more elegant proposal to turn 
things into Lists in a reasonable time-frame.

/Claes

From peter.levart at gmail.com  Fri Nov  3 16:40:04 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 3 Nov 2017 17:40:04 +0100
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <065ff3b8-7967-594d-7d60-0006f8d48eb3@oracle.com>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
 <F9C4D58D-41C7-494E-ADD7-F7DFD49A0BF8@oracle.com>
 <012d01d35419$d48bbe80$7da33b80$@freenet.de>
 <90EA3CF8-5E39-4E75-91AB-4C7432E8044B@oracle.com>
 <013001d35425$f8b9ddd0$ea2d9970$@freenet.de>
 <603EF3CC-F789-4D06-9295-DBD948493692@oracle.com>
 <000001d35433$04f2c280$0ed84780$@freenet.de>
 <D6817D33-993C-48C3-8B84-A39C8177FE2C@oracle.com>
 <000d01d3547b$664bf180$32e3d480$@freenet.de>
 <065ff3b8-7967-594d-7d60-0006f8d48eb3@oracle.com>
Message-ID: <9c2a3550-4e51-21fa-c99b-d226aeb6b5ac@gmail.com>

Hi,

On 11/03/2017 02:17 PM, Alan Bateman wrote:
> On 03/11/2017 08:11, Christoph Dreis wrote:
>> Hi John,
>>
>>>> this has a bigger impact on the overall footprint of 
>>>> Method/Executable objects. What are your thoughts on this?
>>> The footprint is probably about the same.? Small List.of values
>>> do not contain arrays, and may be smaller than arrays with the
>>> same number of elements, since they do not have a length field.
>>> And, indeed, methods typically have a small number of parameters.
>> Ah, so you would remove the current array field completely and 
>> replace it with the immutable List, right?
>> In that case I said nothing. I was thinking of a field on top.
>>
> The VM creates Method objects and sets the fields, including 
> parameterTypes, directly so I think removing it would require more 
> work than it initially looks. If you add a field then it does increase 
> the footprint a bit. Alternatively, have the method could use a 
> ImmutableCollection.ListN like implementation that is backed by the 
> array and doesn't scan it for nulls at create time, this wouldn't be 
> completely allocation free of course.

What if the work was done in 2 phases.

Phase 1: Array typed fields are changed to be of type Object, then for 
example Method could use the following implementation, VM code has no 
changes:

 ??? private Object parameterTypes;

 ??? public List<Class<?>> parameterTypes() {
 ??????? return (List<Class<?>>) parameterTypes;
 ??? }

 ??? public Class<?>[] getParameterTypes() {
 ??????? return parameterTypes().toArray(new Class<?>[0]);
 ??? }

...etc.

The "root" Method objects are never used directly. Their methods are 
never called. When "root" Method objects are copied, the arrays would be 
swapped for lists:

 ??? /**
 ???? * Package-private routine (exposed to java.lang.Class via
 ???? * ReflectAccess) which returns a copy of this Method. The copy's
 ???? * "root" field points to this Method.
 ???? */
 ??? Method copy() {
 ??????? // This routine enables sharing of MethodAccessor objects
 ??????? // among Method objects which refer to the same underlying
 ??????? // method in the VM. (All of this contortion is only necessary
 ??????? // because of the "accessibility" bit in AccessibleObject,
 ??????? // which implicitly requires that new java.lang.reflect
 ??????? // objects be fabricated for each reflective call on Class
 ??????? // objects.)
 ??????? if (this.root != null)
 ??????????? throw new IllegalArgumentException("Can not copy a non-root 
Method");

 ??????? Object _ptypes = parameterTypes;
 ??????? if (_ptypes instanceof Class<?>[]) {
 ??????????? parameterTypes = _ptypes = List.ofShared((Class<?>[]) _ptypes);
 ??????? }

 ??????? Object _etypes = exceptionTypes;
 ??????? if (_etypes instanceof Class<?>[]) {
 ??????????? exceptionTypes = _etypes = List.ofShared((Class<?>[]) _etypes);
 ??????? }

 ??????? Method res = new Method(clazz, name, _ptypes, returnType,
 ??????????????????????????????? _etypes, modifiers, slot, signature,
 ??????????????????????????????? annotations, parameterAnnotations, 
annotationDefault);
 ??????? res.root = this;
 ??????? // Might as well eagerly propagate this if already present
 ??????? res.methodAccessor = methodAccessor;
 ??????? return res;
 ??? }



Phase 2: VM is changed to inject List(s) instead of arrays and fields ca 
be changed to be of type List with swap-conversions removed.


Regards, Peter


From karen.kinnear at oracle.com  Fri Nov  3 18:14:53 2017
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Fri, 3 Nov 2017 14:14:53 -0400
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
Message-ID: <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com>

Thank you so much for doing this jointly.

Couple of questions/comments:
1. thank you for making UseBootstrapCallInfo diagnostic

2. org/objectweb/asmClassReader.java
why hardcoded 17 instead of ClassWriter.CONDY?

3. java/lang/invoke/package-info.java 128-134
Error handling could be clearer.
My understanding is that if a LinkageError or subclass is thrown, this will be rethrown
for all subsequent attempts. Other errors, e.g. VMError may retry resolution

Also: after line 165: rules do not enable the JVM to share call sites.
Is it worth noting anywhere that the Constant_Dynamic resolution is shared?

4. SD::find_java_mirror_for_type
lines 2679+
  ConDy should not be supporting CONSTANT_Class(?;? + FD)
  IIRC that is temporary for MVT but not part of ConDy?s spec, nor part of what
  should be checked in for 18.3
also line 2731 - remove comment about ?Foo;?

5. constantTag.hpp
ofBasicType: case T_OBJECT return constantTag(JVM_CONSTANT_String) ?
why not JVM_CONSTANT_CLASS?

6. SD::find_java_mirror_for_type
You have resolve_or_null/fail doing CHECK_(empty) which should
check for a NULL constant_type_klass. This is followed by an explicit if
(constant_type_klass == NULL) ? is that needed?

7. reflection.cpp
get_mirror_from_signature
Looks like potential for side effects. Odd to set mirror_oop inside if (log_is_enabled)
Is the intent to assert that k->java_mirror() == mirror_oop?
Or is the issue that we have a make drop here and the potential for a safe point?
If so, make a handle and extract it on return?

? Or better yet - don?t make any changes to reflection.cpp - not necessary

8. BootstrapMethodInvoker
Could you possibly add a comment that the default today is vmIsPushing and IsPullModeBSM is false?
Or find a slightly different naming to make that clearer?

9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java
How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that
was not ACC_STATIC?
Or was not ACC_PUBLIC?
Or was 
Or did I read the invoke dynamic method incorrectly?

thanks,
Karen

> On Oct 26, 2017, at 1:03 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi,
> 
> Please review the following patch for minimal dynamic constant support:
> 
>  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>
> 
>  https://bugs.openjdk.java.net/browse/JDK-8186046 <https://bugs.openjdk.java.net/browse/JDK-8186046>
>  https://bugs.openjdk.java.net/browse/JDK-8186209 <https://bugs.openjdk.java.net/browse/JDK-8186209>
> 
> This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good.
> 
> By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex.
> 
> A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository).
> 
> Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments.
> 
> The CSR for the VM specification is here:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8189199 <https://bugs.openjdk.java.net/browse/JDK-8189199>
> 
> the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles).
> 
> Any AoT-related work will be deferred to a future release.
> 
> ?
> 
> This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte).
> 
> We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches.
> 
> ?
> 
> Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants.
> 
> One test uses class file bytes produced from a modified version of asmtools.  The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test.
> 
> ?
> 
> Paul.


From patrick at reini.net  Fri Nov  3 19:54:19 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Fri, 3 Nov 2017 20:54:19 +0100
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
Message-ID: <3B17DF35-506F-4F0C-AF7F-30069B0582CB@reini.net>

Hi Alan,

I will have a version ready at Devoxx next week ;-)

-Patrick


> Am 03.11.2017 um 13:49 schrieb Alan Bateman <Alan.Bateman at oracle.com>:
> 
> On 02/11/2017 19:55, Patrick Reinhart wrote:
>> :
>> If we are all happy with the API so far, I could start adding an initial implementation and test?
>> 
> I think the API looks fine so go ahead.
> 
> -Alan


From paul.sandoz at oracle.com  Fri Nov  3 21:28:54 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 3 Nov 2017 14:28:54 -0700
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com>
Message-ID: <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com>


> On 3 Nov 2017, at 11:14, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> Thank you so much for doing this jointly.
> 
> Couple of questions/comments:
> 1. thank you for making UseBootstrapCallInfo diagnostic
> 
> 2. org/objectweb/asmClassReader.java
> why hardcoded 17 instead of ClassWriter.CONDY?
> 

I chose to make the absolute minimal amount of changes to our internal ASM to reduce possible conflicts as i anticipate that a new version of ASM with condy support will eventually be rolled in.


> 3. java/lang/invoke/package-info.java 128-134
> Error handling could be clearer.
> My understanding is that if a LinkageError or subclass is thrown, this will be rethrown
> for all subsequent attempts. Other errors, e.g. VMError may retry resolution
> 
> Also: after line 165: rules do not enable the JVM to share call sites.
> Is it worth noting anywhere that the Constant_Dynamic resolution is shared?
> 
> 4. SD::find_java_mirror_for_type
> lines 2679+
>   ConDy should not be supporting CONSTANT_Class(?;? + FD)
>   IIRC that is temporary for MVT but not part of ConDy?s spec, nor part of what
>   should be checked in for 18.3


Yes, i deleted lines 2678 to 2687

TempNewSymbol type_buf;
if (type->utf8_length() > 1 && type->byte_at(0) == ';') {
  // Strip the quote, which may have come from CONSTANT_Class[";"+FD].
  // (This logic corresponds to the use of "FieldType::is_obj"
  // in resolve_or_null.  A field type can be unwrapped to a class
  // type and vice versa.)
  type = SymbolTable::new_symbol(type->as_C_string() + 1,
                                 type->utf8_length() - 1, CHECK_(empty));
  type_buf = type;  // will free later
}


> also line 2731 - remove comment about ?Foo;?
> 

Removed.


> 5. constantTag.hpp
> ofBasicType: case T_OBJECT return constantTag(JVM_CONSTANT_String) ?
> why not JVM_CONSTANT_CLASS?
> 

We would have to ask John on that, i am guessing it does not matter much since round tripping is ok and it is the more benign of the mapping. I do find this sits awkwardly though, perhaps there is a more general cleanup that can follow in this regard?


> 6. SD::find_java_mirror_for_type
> You have resolve_or_null/fail doing CHECK_(empty) which should
> check for a NULL constant_type_klass. This is followed by an explicit if
> (constant_type_klass == NULL) ? is that needed?
> 

Can SD:resolve_or_null return a null value when HAS_PENDING_EXCEPTION=false?

I see other usages that suggest this to be the case. Where as for resolve_or_fail:

Klass* SystemDictionary::resolve_or_fail(Symbol* class_name, Handle class_loader, Handle protection_domain, bool throw_error, TRAPS) {
  Klass* klass = resolve_or_null(class_name, class_loader, protection_domain, THREAD);
  if (HAS_PENDING_EXCEPTION || klass == NULL) {
    // can return a null klass
    klass = handle_resolution_exception(class_name, throw_error, klass, THREAD);
  }
  return klass;
}


It suggests we can change the code from:

if (failure_mode == SignatureStream::ReturnNull) {
  constant_type_klass = resolve_or_null(type, class_loader, protection_domain,
                                        CHECK_(empty));
} else {
  bool throw_error = (failure_mode == SignatureStream::NCDFError);
  constant_type_klass = resolve_or_fail(type, class_loader, protection_domain,
                                        throw_error, CHECK_(empty));
}
if (constant_type_klass == NULL) {
  return Handle();  // report failure this way
}

to

if (failure_mode == SignatureStream::ReturnNull) {
  constant_type_klass = resolve_or_null(type, class_loader, protection_domain,
                                        CHECK_(empty));
  if (constant_type_klass == NULL) {
    return Handle();  // report failure this way
  }
} else {
  bool throw_error = (failure_mode == SignatureStream::NCDFError);
  constant_type_klass = resolve_or_fail(type, class_loader, protection_domain,
                                        throw_error, CHECK_(empty));
}

?


> 7. reflection.cpp
> get_mirror_from_signature
> Looks like potential for side effects. Odd to set mirror_oop inside if (log_is_enabled)
> Is the intent to assert that k->java_mirror() == mirror_oop?
> Or is the issue that we have a make drop here and the potential for a safe point?
> If so, make a handle and extract it on return?
> 
> ? Or better yet - don?t make any changes to reflection.cpp - not necessary
> 

Lois, John?

My recollection was John was attempting to tunnel things through a single method find_java_mirror_for_type, but i agree the setting of mirror_oop is odd.



> 8. BootstrapMethodInvoker
> Could you possibly add a comment that the default today is vmIsPushing and IsPullModeBSM is false?
> Or find a slightly different naming to make that clearer?

boolean pullMode = isPullModeBSM(bootstrapMethod);  // default value is false
boolean vmIsPushing = !staticArgumentsPulled(info); // default value is true

?


> 
> 9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java
> How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that
> was not ACC_STATIC?

https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.23

See the note under bootstrap_method_ref. The kind of method handle is constrained because of the arguments that are pushed on the stack before invocation. I believe it?s possible to have a constructor, but the declaring class would need to be a subtype of CallSite in the case of indy, and a subtype of the constant value type in the case of condy.


> Or was not ACC_PUBLIC?

That?s dependent on the accessibility between the lookup class the the BSM declaring class.


> Or was 
> Or did I read the invoke dynamic method incorrectly?
> 

By default, and for convenience, the InstructionHelper assumes the BSM is declared by the lookup class. I recently modified that to support the BSM being declared on another class, to test the minimal set of BSMs for condy (separate issue [1]). Note it?s always possible to use the bytecode API more directly.

So we can easily add more -ve tests for non-accessible or non-static BSMs.

Paul.

[1] http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/


From mandy.chung at oracle.com  Fri Nov  3 21:41:52 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 3 Nov 2017 14:41:52 -0700
Subject: [Patch][JDK10] Use Class.getPackageName() where possible
In-Reply-To: <000c01d3547a$ad4d6470$07e82d50$@freenet.de>
References: <000101d3543e$840b6080$8c222180$@freenet.de>
 <72043f40-6a9c-f79a-66be-5e68e6ce1f0c@oracle.com>
 <000c01d3547a$ad4d6470$07e82d50$@freenet.de>
Message-ID: <4a0476c1-1333-9e28-5b07-066b8fa74213@oracle.com>



On 11/3/17 1:06 AM, Christoph Dreis wrote:
>
> Thanks - I updated both as you suggested to use Class::getPackageName. Please find the updated patch below.

I have created https://bugs.openjdk.java.net/browse/JDK-8190733 for this 
patch.

> There is also a public static VerifyAccess::getPackageName which seems to be not working with arrays at all and as far as I can see is at least not used inside the JDK itself.
> Should this be deprecated maybe in favor of Class.getPackageName() or also adjusted to use it (which would mean different return values than before as you already noted)?

VerifyAccess::getPackageName is unused in jdk8u-dev neither.  So I think it can be removed.  No deprecation is needed since this is JDK internal API and I hardly think anyone is depending on it.

Mandy

> Cheers,
> Christoph
>
> ====== PATCH =======
> diff -r 438e0c9f2f17 src/java.base/share/classes/java/io/ObjectInputFilter.java
> --- a/src/java.base/share/classes/java/io/ObjectInputFilter.java	Mon Oct 30 17:49:33 2017 -0700
> +++ b/src/java.base/share/classes/java/io/ObjectInputFilter.java	Fri Nov 03 08:38:15 2017 +0100
> @@ -656,8 +656,8 @@
>                * otherwise {@code false}
>                */
>               private static boolean matchesPackage(Class<?> c, String pkg) {
> -                String n = c.getName();
> -                return n.startsWith(pkg) && n.lastIndexOf('.') == pkg.length() - 1;
> +                String n = c.getPackageName();
> +                return n.length() == pkg.length() - 1 && n.startsWith(pkg);
>               }
>   
>               /**
>
> diff -r 438e0c9f2f17 src/java.base/share/classes/java/io/ObjectStreamClass.java
> --- a/src/java.base/share/classes/java/io/ObjectStreamClass.java	Mon Oct 30 17:49:33 2017 -0700
> +++ b/src/java.base/share/classes/java/io/ObjectStreamClass.java	Fri Nov 03 08:38:15 2017 +0100
> @@ -1587,11 +1587,7 @@
>        * Returns package name of given class.
>        */
>       private static String getPackageName(Class<?> cl) {
> -        String s = cl.getName();
> -        int i = s.lastIndexOf('[');
> -        i = (i < 0) ? 0 : i + 2;
> -        int j = s.lastIndexOf('.');
> -        return (i < j) ? s.substring(i, j) : "";
> +        return cl.getPackageName();
>       }
>   
>       /**
>
> diff -r 438e0c9f2f17 src/java.base/share/classes/java/lang/ClassLoader.java
> --- a/src/java.base/share/classes/java/lang/ClassLoader.java	Mon Oct 30 17:49:33 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/ClassLoader.java	Fri Nov 03 08:38:15 2017 +0100
> @@ -672,12 +672,11 @@
>                   return;
>               }
>   
> -            final String name = cls.getName();
> -            final int i = name.lastIndexOf('.');
> -            if (i != -1) {
> +            final String packageName = cls.getPackageName();
> +            if (!packageName.isEmpty()) {
>                   AccessController.doPrivileged(new PrivilegedAction<>() {
>                       public Void run() {
> -                        sm.checkPackageAccess(name.substring(0, i));
> +                        sm.checkPackageAccess(packageName);
>                           return null;
>                       }
>                   }, new AccessControlContext(new ProtectionDomain[] {pd}));
>
> diff -r 438e0c9f2f17 src/java.base/share/classes/java/lang/reflect/Proxy.java
> --- a/src/java.base/share/classes/java/lang/reflect/Proxy.java	Mon Oct 30 17:49:33 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/reflect/Proxy.java	Fri Nov 03 08:38:15 2017 +0100
> @@ -1034,11 +1034,8 @@
>   
>                   // do permission check if the caller is in a different runtime package
>                   // of the proxy class
> -                int n = proxyClass.getName().lastIndexOf('.');
> -                String pkg = (n == -1) ? "" : proxyClass.getName().substring(0, n);
> -
> -                n = caller.getName().lastIndexOf('.');
> -                String callerPkg = (n == -1) ? "" : caller.getName().substring(0, n);
> +                String pkg = proxyClass.getPackageName();
> +                String callerPkg = caller.getPackageName();
>   
>                   if (pcl != ccl || !pkg.equals(callerPkg)) {
>                       sm.checkPermission(new ReflectPermission("newProxyInPackage." + pkg));
>
>


From ecki at zusammenkunft.net  Sat Nov  4 01:52:28 2017
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sat, 4 Nov 2017 01:52:28 +0000
Subject: [Patch][JDK10] Use Class.getPackageName() where possible
In-Reply-To: <4a0476c1-1333-9e28-5b07-066b8fa74213@oracle.com>
References: <000101d3543e$840b6080$8c222180$@freenet.de>
 <72043f40-6a9c-f79a-66be-5e68e6ce1f0c@oracle.com>
 <000c01d3547a$ad4d6470$07e82d50$@freenet.de>,
 <4a0476c1-1333-9e28-5b07-066b8fa74213@oracle.com>
Message-ID: <AM4PR08MB1219C410B9E57E3E39B2F9A2FF520@AM4PR08MB1219.eurprd08.prod.outlook.com>

The private static helper in ObjectStreamClass became a oneliner and can be removed and the callsites can transform from getPackageName(c) to c.getPackageName().

Gruss
Bernd
--
http://bernd.eckenfels.net
_____________________________
From: mandy chung <mandy.chung at oracle.com<mailto:mandy.chung at oracle.com>>
Sent: Samstag, November 4, 2017 1:12 AM
Subject: Re: [Patch][JDK10] Use Class.getPackageName() where possible
To: Christoph Dreis <christoph.dreis at freenet.de<mailto:christoph.dreis at freenet.de>>, 'Core-Libs-Dev' <core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>>




On 11/3/17 1:06 AM, Christoph Dreis wrote:
>
> Thanks - I updated both as you suggested to use Class::getPackageName. Please find the updated patch below.

I have created https://bugs.openjdk.java.net/browse/JDK-8190733 for this
patch.

> There is also a public static VerifyAccess::getPackageName which seems to be not working with arrays at all and as far as I can see is at least not used inside the JDK itself.
> Should this be deprecated maybe in favor of Class.getPackageName() or also adjusted to use it (which would mean different return values than before as you already noted)?

VerifyAccess::getPackageName is unused in jdk8u-dev neither. So I think it can be removed. No deprecation is needed since this is JDK internal API and I hardly think anyone is depending on it.

Mandy

> Cheers,
> Christoph
>
> ====== PATCH =======
> diff -r 438e0c9f2f17 src/java.base/share/classes/java/io/ObjectInputFilter.java
> --- a/src/java.base/share/classes/java/io/ObjectInputFilter.java Mon Oct 30 17:49:33 2017 -0700
> +++ b/src/java.base/share/classes/java/io/ObjectInputFilter.java Fri Nov 03 08:38:15 2017 +0100
> @@ -656,8 +656,8 @@
> * otherwise {@code false}
> */
> private static boolean matchesPackage(Class<?> c, String pkg) {
> - String n = c.getName();
> - return n.startsWith(pkg) && n.lastIndexOf('.') == pkg.length() - 1;
> + String n = c.getPackageName();
> + return n.length() == pkg.length() - 1 && n.startsWith(pkg);
> }
>
> /**
>
> diff -r 438e0c9f2f17 src/java.base/share/classes/java/io/ObjectStreamClass.java
> --- a/src/java.base/share/classes/java/io/ObjectStreamClass.java Mon Oct 30 17:49:33 2017 -0700
> +++ b/src/java.base/share/classes/java/io/ObjectStreamClass.java Fri Nov 03 08:38:15 2017 +0100
> @@ -1587,11 +1587,7 @@
> * Returns package name of given class.
> */
> private static String getPackageName(Class<?> cl) {
> - String s = cl.getName();
> - int i = s.lastIndexOf('[');
> - i = (i < 0) ? 0 : i + 2;
> - int j = s.lastIndexOf('.');
> - return (i < j) ? s.substring(i, j) : "";
> + return cl.getPackageName();
> }
>
> /**
>
> diff -r 438e0c9f2f17 src/java.base/share/classes/java/lang/ClassLoader.java
> --- a/src/java.base/share/classes/java/lang/ClassLoader.java Mon Oct 30 17:49:33 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/ClassLoader.java Fri Nov 03 08:38:15 2017 +0100
> @@ -672,12 +672,11 @@
> return;
> }
>
> - final String name = cls.getName();
> - final int i = name.lastIndexOf('.');
> - if (i != -1) {
> + final String packageName = cls.getPackageName();
> + if (!packageName.isEmpty()) {
> AccessController.doPrivileged(new PrivilegedAction<>() {
> public Void run() {
> - sm.checkPackageAccess(name.substring(0, i));
> + sm.checkPackageAccess(packageName);
> return null;
> }
> }, new AccessControlContext(new ProtectionDomain[] {pd}));
>
> diff -r 438e0c9f2f17 src/java.base/share/classes/java/lang/reflect/Proxy.java
> --- a/src/java.base/share/classes/java/lang/reflect/Proxy.java Mon Oct 30 17:49:33 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/reflect/Proxy.java Fri Nov 03 08:38:15 2017 +0100
> @@ -1034,11 +1034,8 @@
>
> // do permission check if the caller is in a different runtime package
> // of the proxy class
> - int n = proxyClass.getName().lastIndexOf('.');
> - String pkg = (n == -1) ? "" : proxyClass.getName().substring(0, n);
> -
> - n = caller.getName().lastIndexOf('.');
> - String callerPkg = (n == -1) ? "" : caller.getName().substring(0, n);
> + String pkg = proxyClass.getPackageName();
> + String callerPkg = caller.getPackageName();
>
> if (pcl != ccl || !pkg.equals(callerPkg)) {
> sm.checkPermission(new ReflectPermission("newProxyInPackage." + pkg));
>
>




From patrick at reini.net  Sun Nov  5 08:34:27 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Sun, 5 Nov 2017 09:34:27 +0100
Subject: RFR: 8067661 transferTo() for Appendable
Message-ID: <9D63A7E3-7123-4A58-8C05-71804399E627@reini.net>

After discussing [0] for about the API for the new transferTo() method on Appendable, I have created an initial
Version of the actual implementation for review:

http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.00/index.html

Any comments/suggestions are welcome, also I will need a sponsor for it at the end?

-Patrick

[0|] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/049797.html


From Alan.Bateman at oracle.com  Sun Nov  5 10:02:14 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 5 Nov 2017 10:02:14 +0000
Subject: RFR: 8067661 transferTo() for Appendable
In-Reply-To: <9D63A7E3-7123-4A58-8C05-71804399E627@reini.net>
References: <9D63A7E3-7123-4A58-8C05-71804399E627@reini.net>
Message-ID: <0ed3db13-6a5c-529b-8f0a-8332bc1fb6c9@oracle.com>

On 05/11/2017 08:34, Patrick Reinhart wrote:
> After discussing [0] for about the API for the new transferTo() method on Appendable, I have created an initial
> Version of the actual implementation for review:
>
> http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.00/index.html
>
> Any comments/suggestions are welcome, also I will need a sponsor for it at the end?
>
CharBuffer may need special attention. It implements both Readable and 
Appendable and additional creates the potential for 
BufferOverflowException or ReadOnlyBufferException when the target is a 
CharBuffer. This is only so much that the javadoc in Readable can 
specify of course.

One possibly is to override the method in CharBuffer so that you can 
clarify some of this behavior. This would allow you to specify that it 
works like target.put(src) when both are char buffers for example - that 
probably is a nice property to specify anyway.

Are you planning to add an @implSpec to specify the default implementation?

-Alan.

From chris.hegarty at oracle.com  Sun Nov  5 10:02:30 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sun, 5 Nov 2017 10:02:30 +0000
Subject: RFR - 8190482: InnocuousThread creation should not require the caller
 to possess enableContextClassLoaderOverride
Message-ID: <09E42B38-0C64-42F6-881A-6B61A7ECFE7A@oracle.com>

Currently JDK code that wants to create innocuous threads is required to do so within a privileged context that has the "enableContextClassLoaderOverride" RuntimePermission ( since the InnocuousThread class overrides setContextClassLoader ). This permissions should not be required, especially if code in de-privileged modules wants to create innocuous threads. 

The factory methods for creating innocuous threads should assert privileges before constructing the thread.

diff --git a/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java b/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java
--- a/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java
+++ b/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java
@@ -62,10 +62,16 @@
      * set to the system class loader.
      */
     public static Thread newThread(String name, Runnable target) {
-        return new InnocuousThread(INNOCUOUSTHREADGROUP,
-                                   target,
-                                   name,
-                                   ClassLoader.getSystemClassLoader());
+        return AccessController.doPrivileged(
+                new PrivilegedAction<Thread>() {
+                    @Override
+                    public Thread run() {
+                        return new InnocuousThread(INNOCUOUSTHREADGROUP,
+                                                   target,
+                                                   name,
+                                                   ClassLoader.getSystemClassLoader());
+                    }
+                });
     }
 
     /**
@@ -80,8 +86,14 @@
      * Returns a new InnocuousThread with null context class loader.
      */
     public static Thread newSystemThread(String name, Runnable target) {
-        return new InnocuousThread(INNOCUOUSTHREADGROUP,
-                                   target, name, null);
+        return AccessController.doPrivileged(
+                new PrivilegedAction<Thread>() {
+                    @Override
+                    public Thread run() {
+                        return new InnocuousThread(INNOCUOUSTHREADGROUP,
+                                                   target, name, null);
+                    }
+                });
     }
 
-Chris.

From patrick at reini.net  Sun Nov  5 10:55:35 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Sun, 5 Nov 2017 11:55:35 +0100
Subject: RFR: 8067661 transferTo() for Appendable
In-Reply-To: <0ed3db13-6a5c-529b-8f0a-8332bc1fb6c9@oracle.com>
References: <9D63A7E3-7123-4A58-8C05-71804399E627@reini.net>
 <0ed3db13-6a5c-529b-8f0a-8332bc1fb6c9@oracle.com>
Message-ID: <F2DB10CE-D2C2-4B4E-B5BB-C186A3D5B66C@reini.net>


> Am 05.11.2017 um 11:02 schrieb Alan Bateman <Alan.Bateman at oracle.com>:
> 
> On 05/11/2017 08:34, Patrick Reinhart wrote:
>> After discussing [0] for about the API for the new transferTo() method on Appendable, I have created an initial
>> Version of the actual implementation for review:
>> 
>> http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.00/index.html
>> 
>> Any comments/suggestions are welcome, also I will need a sponsor for it at the end?
>> 
> CharBuffer may need special attention. It implements both Readable and Appendable and additional creates the potential for BufferOverflowException or ReadOnlyBufferException when the target is a CharBuffer. This is only so much that the javadoc in Readable can specify of course.
> 
> One possibly is to override the method in CharBuffer so that you can clarify some of this behavior. This would allow you to specify that it works like target.put(src) when both are char buffers for example - that probably is a nice property to specify anyway.
> 

This sounds reasonable and worth while doing. I will take a deeper look into that one, as soon I have finished the default implementation.


> Are you planning to add an @implSpec to specify the default implementation?

I can do that, but I may need some assistance for the language specific parts of it. Would you add the CharBuffer potential exceptions there or more or less describe the default implementation?

> 
> -Alan.

-Patrick

From peter.levart at gmail.com  Sun Nov  5 20:05:41 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 5 Nov 2017 21:05:41 +0100
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <78b4d19c-28cb-4552-67de-cb0bf0cadf62@gmail.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
 <59F7735A.3000501@oracle.com>
 <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>
 <59F7B6A1.5040303@oracle.com>
 <16e98d55-35c0-a039-edf5-95240bed2510@gmail.com>
 <59F90664.9050403@oracle.com>
 <5b2ec510-7420-142f-eb96-6d851bb049eb@gmail.com>
 <59FA1DD3.2090604@oracle.com>
 <78b4d19c-28cb-4552-67de-cb0bf0cadf62@gmail.com>
Message-ID: <e290a58b-6542-6673-99bb-33be4e3a4d41@gmail.com>



On 11/03/17 09:48, Peter Levart wrote:
> Hi Sherman,
>
> I think this looks good now. Thanks.
>
> Regards, Peter

Just one more thing. Re-reading the code once more after a few days made 
me re-think about why in my last version I did what I did with 
CleanableResource.inflaters field. In CleanableResource.run() I reset it 
to null after 1st ending all cached inflaters. This makes 
ZipFileInflaterInputStream(s) that are cleaned after the ZipFile has 
been cleaned, release the inflaters immediately and not in next GC round:

 ?623???????? void releaseInflater(Inflater inf) {
 ?624???????????? Deque<Inflater> inflaters = this.inflaters;
 ?625???????????? if (inflaters != null) {
 ?626???????????????? synchronized (inflaters) {
 ?627???????????????????? // double checked!
 ?628???????????????????? if (this.inflaters == inflaters) {
 ?629???????????????????????? inf.reset();
 ?630???????????????????????? inflaters.add(inf);
 ?631???????????????????????? return;
 ?632???????????????????? }
 ?633???????????????? }
 ?634???????????? }
 ?635???????????? // inflaters cache already closed - just end late comers
 ?636???????????? inf.end();
 ?637???????? }

 ?639???????? public void run() {
 ?640???????????? // Release cached inflaters and close inflaters cache 1st
 ?641???????????? Deque<Inflater> inflaters = this.inflaters;
 ?642???????????? if (inflaters != null) {
 ?643???????????????? synchronized (inflaters) {
 ?644???????????????????? // no need to double-check as only one thread 
gets a chance
 ?645???????????????????? // to execute run() (Cleaner guarantee)...
 ?646???????????????????? Inflater inf;
 ?647???????????????????? while ((inf = inflaters.poll()) != null) {
 ?648???????????????????????? inf.end();
 ?649???????????????????? }
 ?650???????????????????? // close inflaters cache
 ?651???????????????????? this.inflaters = null;
 ?652???????????????? }
 ?653???????????? }


For example, in the following code:

{
 ??? ZipFile zf = ...
 ??? ZipEntry ze = zf.getEntry(...);
 ??? InputStream is = zf.getInputStream(ze);

 ??? ...
}
// 1st GC round

...we want all native resources to be released in 1st GC round after 
'zf' and 'is' become unreachable.


Regards, Peter

>
> On 11/01/2017 08:17 PM, Xueming Shen wrote:
>> Hi Peter,
>>
>> I like the idea of moving get/releaseInflter() into 
>> CleanableResource, though I doubt
>> how much it can really help the GC it should be a good thing to do to 
>> remove the strong
>> reference of ZipFile from stream's cleaner, and the code appears a 
>> little cleaner as well.
>>
>> I was debating with myself whether or not the ZipFile.close() should 
>> throw an
>> UncheckedIOException (like those java.nio.file.Files methods do). But 
>> you're right it's
>> not good to simply ignoring them silently. Now I catch/unwarp the 
>> potential
>> UncheckedIOException from res.clean() and re-throw the embedded ioe.
>>
>> I need to dig a little to recall the real reason of zsrc==null check 
>> in ensureOpen()
>> the comment does not sound updated. res.zsrc is not final and it is 
>> set to null
>> when clean up/close. So I keep it for now.
>>
>> Most (if not all?) "minor nit" has been updated accordingly.
>>
>> It seems like we might have have put the "finalize()" method back as 
>> an empty-body
>> method for compatibility reason. So not done yet :-)
>>
>> http://cr.openjdk.java.net/~sherman/8185582/webrev/
>>
>> thanks,
>> sherman
>>
>> On 11/1/17, 5:04 AM, Peter Levart wrote:
>>> Hi Sherman,
>>>
>>> On 11/01/17 00:25, Xueming Shen wrote:
>>>> Hi Peter,
>>>>
>>>> After tried couple implementations it seems the most reasonable 
>>>> approach is to
>>>> use the coding pattern you suggested to move all pieces into 
>>>> ZSStream Ref. Given
>>>> we are already using the internal API CleanerFactory it is 
>>>> attractive to go a little
>>>> further to subclass PhantomCleanable directly (in which I would 
>>>> assume we can
>>>> save one extra object), but I think I'd better to follow the 
>>>> "suggested" clean usage
>>>> (to register a runnable into the cleaner) for now.
>>>>
>>>> ? 39 class ZStreamRef implements Runnable {
>>>> ? 40
>>>> ? 41???? private LongConsumer end;
>>>> ? 42???? private volatile long address;
>>>> ? 43???? private final Cleanable cleanable;
>>>> ? 44
>>>> ? 45???? ZStreamRef (Object owner, LongSupplier addr, LongConsumer 
>>>> end) {
>>>> ? 46???????? this.cleanable = 
>>>> CleanerFactory.cleaner().register(owner, this);
>>>> ? 47???????? this.end = end;
>>>> ? 48???????? this.address = addr.getAsLong();
>>>> ? 49???? }
>>>> ? 50
>>>>
>>>> Similar change has been made for the ZipFile cleaner to follow the 
>>>> same coding
>>>> pattern. The "cleaner" is now renamed from Releaser to 
>>>> CleanableResource.
>>>>
>>>> http://cr.openjdk.java.net/~sherman/8185582/webrev/
>>>>
>>>> Thanks,
>>>> Sherman
>>>
>>> This looks mostly fine. One minor nit is that ZStreamRef.address 
>>> field does not have to be volatile. I checked all usages of 
>>> ZStreamRef.address() and all of them invoke it while holding a lock 
>>> on the ZStreamRef instance. The ZStreamRef.run() which modifies the 
>>> address is also synchronized. The other minor nit is that the 
>>> following ZipFile imports are not needed:
>>>
>>> import java.nio.file.Path;
>>> import java.util.Map;
>>> import jdk.internal.misc.JavaIORandomAccessFileAccess;
>>> import static java.util.zip.ZipConstants.*;
>>>
>>> (at least my IDEA colors them unused)
>>>
>>> Cleaner is modified in this webrev (just one empty line deleted) - 
>>> better not touch this file in this changeset
>>>
>>> Additional nits in ZipFile:
>>>
>>> - in lines 355, 356 you pull out two res fields into locals, but 
>>> then not use them consistently (lines 372, 389)
>>> - line 403 has a TAB character (is this OK?) and shows incorrectly 
>>> indented in my editor (should I set tab stops differently?)
>>> - line 457 - while should actually be if ?
>>> - in ensureOpen() the check for res.zsrc == null can never succeed 
>>> (CleanableResource.zsrc is a final field. If CleanableResource 
>>> constructor fails, there's no res object and there's no ZipFile 
>>> object either as ZipFile constructor does not do anything for this 
>>> to escape prematurely)
>>> - why don't you let IOExceptions thrown from CleanableResource.run() 
>>> propagate out of ZipFile.close() ?
>>>
>>> I would also rename static method Source.close(Source) to 
>>> Source.release(Source) so it would not clash with instance method 
>>> Source.close() which makes it ambiguous when one wants to use 
>>> Source::close method reference (both methods apply). I would also 
>>> make static methods Source.get() and Source.release(Source) 
>>> package-private (currently one is public and the other is private, 
>>> which needs compiler bridges to be invoked) and both are in a 
>>> private nested class.
>>>
>>> Inflater/Deflater/ZipFile now follow the coding pattern as 
>>> suggested. But ZipFileInflaterInputStream still does not. It's not 
>>> critical since failing to register cleanup which releases the 
>>> inflater back into cache would simply mean that Inflater employs its 
>>> own cleanup and ends itself.
>>>
>>> And now another thing I would like to discuss. Why an initiative for 
>>> using Cleaner instead of finalization()? Among drawbacks 
>>> finalization has one of the more troubling is that the tracked 
>>> referent survives the GC cycle that initiates its finalization 
>>> reference processing pipeline, so the GC may reclaim the object (and 
>>> referenced objects) only after the finalize() has finished in yet 
>>> another GC round. Cleaner API separates the tracked object from the 
>>> cleanup function and state needed to perform it into distinct 
>>> instances. The tracked object can be reclaimed and the cleanup 
>>> reference processing pipeline initiated in the same GC cycle. More 
>>> heap may be reclaimed earlier.
>>>
>>> Unless we are careful and create a cleaning function for one tracked 
>>> object which captures (directly or indirectly) another object which 
>>> registers its own cleaning function but we don't deal with explicit 
>>> cleaning of the 2nd object in the 1st cleaning function.
>>>
>>> Take for example the ZipFileInflaterInputStream's cleaning function. 
>>> It captures the ZipFile in order to invoke ZipFile.releaseInflater 
>>> instance method. What this means is that ZipFile will be kept 
>>> reachable until all ZipFileInflaterInputStream's cleaning functions 
>>> have fired. So we are back to the finalization drawback which needs 
>>> at least 2 GC cycles to collect and clean-up what might be done in 
>>> one go.
>>>
>>> I suggest moving the getInflater() and releaseInflater() from 
>>> ZipFile into the CleanableResource so that 
>>> ZipFileInflaterInputStream's cleaning function captures just the 
>>> CleanableResource and not the ZipFile. ZipFile therefore may become 
>>> eligible for cleanup as soon as all opened input streams become 
>>> eligible (but their cleaning functions need not have fired yet). 
>>> CleanableResource.run() (the ZipFile cleaning function) and 
>>> CleanableResource.releaseInflater() (the 
>>> ZipFileInflaterInputStream's cleaning function) may therefore be 
>>> invoked in arbitrary order (maybe even concurrently if one of them 
>>> is explicit cleanup and the other is automatic), so code must be 
>>> prepared for that.
>>>
>>> I have tried to capture all above in a modified webrev (taking your 
>>> last webrev as a base):
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk10-dev/8185582_ZIP.cleaner/webrev.03/
>>>
>>>
>>> Regards, Peter
>>>
>>
>


From lance.andersen at oracle.com  Sun Nov  5 21:05:45 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sun, 5 Nov 2017 16:05:45 -0500
Subject: RFR: 8187954 Update JAX-WS RI integration to latest version
In-Reply-To: <BB9DBC59-0733-42FB-9D0A-27B1C06F555C@oracle.com>
References: <12668CC3-A8DB-4BDC-9F21-5068CA559DA8@oracle.com>
 <DE008EE6-ABC3-455F-85D0-C83239CD4622@oracle.com>
 <A9736FE3-E30D-4EDD-839F-6FFAB6A4BF38@oracle.com>
 <B53D7902-137F-4082-930F-713D427E3CDF@oracle.com>
 <95066DA9-03A6-4BF1-8895-6A442548EC60@oracle.com>
 <50F96A1B-78C3-4FC4-82E5-691E06749F29@oracle.com>
 <A6E211A7-10B2-4242-939E-F6CEB6BFC726@oracle.com>
 <68A33758-0DA4-4B8A-8692-2A382AC63652@oracle.com>
 <BB9DBC59-0733-42FB-9D0A-27B1C06F555C@oracle.com>
Message-ID: <8CE70301-1DFA-4C5B-B1E8-A557BE68EE08@oracle.com>

Hi Jack,

Overall looks OK.  I am assuming all of the test suites are passing?

Best
Lance
> On Nov 2, 2017, at 7:34 AM, Lance Andersen <lance.andersen at oracle.com> wrote:
> 
> Hi Jack
> 
> Its on my list to finish by the end of the week. 
> 
> Best
> Lance
>> On Nov 2, 2017, at 4:34 AM, Jack Li <zheng.jun.li at oracle.com> wrote:
>> 
>> Hi Lance
>> 
>> Is there anything wrong in the new webrev?
>> 
>> 
>>> On Oct 25, 2017, at 10:00, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>> 
>>> Hi Lance,
>>> 
>>> The webrev is updated, can you please review it again?
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> 
>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01 <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01>
>>> 
>>> Summary of changes:
>>> 
>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>> 
>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>> 
>>> 
>>> Patch also contains several small bugfixes, not tracked in JBS.
>>> 
>>>> On Oct 11, 2017, at 18:47, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>>>> 
>>>> Hi Jack,
>>>> 
>>>> I would prefer to see an updated webrev so that we do not inadvertently
>>>> push these changes.
>>>> 
>>>> Best
>>>> Lance
>>>>> On Oct 11, 2017, at 3:26 AM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>>> 
>>>>> Hi Lance
>>>>> 
>>>>> I will update them in Metro repository, do I need to regenerate webrev?
>>>>> or can you skip the files this time and I fix it in next integration?
>>>>> 
>>>>>> On Oct 9, 2017, at 19:35, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>>>>>> 
>>>>>> Hi Jack,
>>>>>> 
>>>>>> UnMarshaller also has the same issue.  I would update the webrev given the number of places to help sanity check for omissions
>>>>>> 
>>>>>> Best
>>>>>> Lance
>>>>>>> On Oct 8, 2017, at 9:22 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>>>>> 
>>>>>>> Hi Lance,
>>>>>>> 
>>>>>>> the change is incorrect, it should be ?javax/xml/bind?.
>>>>>>> thanks a lot for your finding, do you think I need to fix it and resubmit the webrev this time?
>>>>>>> or can you skip this file this time and I fix it in next integration?
>>>>>>> 
>>>>>>>> On Oct 4, 2017, at 02:09, Lance Andersen <Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>> wrote:
>>>>>>>> 
>>>>>>>> Hi Jack,
>>>>>>>> 
>>>>>>>> Is this change correct:
>>>>>>>> 
>>>>>>>> -------------
>>>>>>>> --- old/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.968185273 +0100
>>>>>>>> +++ new/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.676185267 +0100
>>>>>>>> @@ -373,7 +373,7 @@
>>>>>>>>      *      If the {@link ValidationEventHandler ValidationEventHandler}
>>>>>>>>      *      returns false from its {@code handleEvent} method or the
>>>>>>>>      *      {@code Marshaller} is unable to marshal {@code jaxbElement} (or any
>>>>>>>> -     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/javax/xml/bind/Marshaller.html#elementMarshalling">
>>>>>>>> +     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/java/xml/bind/Marshaller.html#elementMarshalling">
>>>>>>>>      *      Marshalling a JAXB element</a>.
>>>>>>>> 
>>>>>>>> ------------
>>>>>>>> 
>>>>>>>> The URL that is being changed currently works
>>>>>>>> 
>>>>>>>> Best
>>>>>>>> Lance
>>>>>>>> On Sep 29, 2017, at 10:55 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>>>>>>> 
>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>>
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>>
>>>>>>>>> 
>>>>>>>>> Summary of changes:
>>>>>>>>> 
>>>>>>>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>>>>>>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>>>>>>>> 
>>>>>>>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>>>>>>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>>>>>>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Patch also contains several small bugfixes, not tracked in JBS.
>>>>>>>>> 
>>>>>>>>> ----------------
>>>>>>>>> Best regards
>>>>>>>>> Jack Li
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> <oracle_sig_logo.gif>
>>>>>>>> 
>>>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>>> Oracle Java Engineering 
>>>>>>>> 1 Network Drive 
>>>>>>>> Burlington, MA 01803
>>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>>>>> 
>>>>>>> ----------------
>>>>>>> Best regards
>>>>>>> Jack Li
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>> Oracle Java Engineering 
>>>>>> 1 Network Drive 
>>>>>> Burlington, MA 01803
>>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> ----------------
>>>>> Best regards
>>>>> Jack Li
>>>> 
>>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle Java Engineering 
>>>> 1 Network Drive 
>>>> Burlington, MA 01803
>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> ----------------
>>> Best regards
>>> Jack Li
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> ----------------
>> Best regards
>> Jack Li
>> 
>> 
>> 
>> 
>> 
>> 
> 
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> 
> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From zheng.jun.li at oracle.com  Sun Nov  5 23:59:20 2017
From: zheng.jun.li at oracle.com (ZhengJun Li)
Date: Mon, 6 Nov 2017 07:59:20 +0800
Subject: RFR: 8187954 Update JAX-WS RI integration to latest version
In-Reply-To: <8CE70301-1DFA-4C5B-B1E8-A557BE68EE08@oracle.com>
References: <12668CC3-A8DB-4BDC-9F21-5068CA559DA8@oracle.com>
 <DE008EE6-ABC3-455F-85D0-C83239CD4622@oracle.com>
 <A9736FE3-E30D-4EDD-839F-6FFAB6A4BF38@oracle.com>
 <B53D7902-137F-4082-930F-713D427E3CDF@oracle.com>
 <95066DA9-03A6-4BF1-8895-6A442548EC60@oracle.com>
 <50F96A1B-78C3-4FC4-82E5-691E06749F29@oracle.com>
 <A6E211A7-10B2-4242-939E-F6CEB6BFC726@oracle.com>
 <68A33758-0DA4-4B8A-8692-2A382AC63652@oracle.com>
 <BB9DBC59-0733-42FB-9D0A-27B1C06F555C@oracle.com>
 <8CE70301-1DFA-4C5B-B1E8-A557BE68EE08@oracle.com>
Message-ID: <06DBFD86-3710-4211-8C00-087DE4F90C04@oracle.com>


Yes, all the tests are passed.


> ? 2017?11?6??05:05?Lance Andersen <lance.andersen at oracle.com> ???
> 
> Hi Jack,
> 
> Overall looks OK.  I am assuming all of the test suites are passing?
> 
> Best
> Lance
>> On Nov 2, 2017, at 7:34 AM, Lance Andersen <lance.andersen at oracle.com> wrote:
>> 
>> Hi Jack
>> 
>> Its on my list to finish by the end of the week. 
>> 
>> Best
>> Lance
>>> On Nov 2, 2017, at 4:34 AM, Jack Li <zheng.jun.li at oracle.com> wrote:
>>> 
>>> Hi Lance
>>> 
>>> Is there anything wrong in the new webrev?
>>> 
>>> 
>>>> On Oct 25, 2017, at 10:00, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>> 
>>>> Hi Lance,
>>>> 
>>>> The webrev is updated, can you please review it again?
>>>> 
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> 
>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01 <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01>
>>>> 
>>>> Summary of changes:
>>>> 
>>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>>> 
>>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>>> 
>>>> 
>>>> Patch also contains several small bugfixes, not tracked in JBS.
>>>> 
>>>>> On Oct 11, 2017, at 18:47, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>>>>> 
>>>>> Hi Jack,
>>>>> 
>>>>> I would prefer to see an updated webrev so that we do not inadvertently
>>>>> push these changes.
>>>>> 
>>>>> Best
>>>>> Lance
>>>>>> On Oct 11, 2017, at 3:26 AM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>>>> 
>>>>>> Hi Lance
>>>>>> 
>>>>>> I will update them in Metro repository, do I need to regenerate webrev?
>>>>>> or can you skip the files this time and I fix it in next integration?
>>>>>> 
>>>>>>> On Oct 9, 2017, at 19:35, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>>>>>>> 
>>>>>>> Hi Jack,
>>>>>>> 
>>>>>>> UnMarshaller also has the same issue.  I would update the webrev given the number of places to help sanity check for omissions
>>>>>>> 
>>>>>>> Best
>>>>>>> Lance
>>>>>>>> On Oct 8, 2017, at 9:22 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>>>>>> 
>>>>>>>> Hi Lance,
>>>>>>>> 
>>>>>>>> the change is incorrect, it should be ?javax/xml/bind?.
>>>>>>>> thanks a lot for your finding, do you think I need to fix it and resubmit the webrev this time?
>>>>>>>> or can you skip this file this time and I fix it in next integration?
>>>>>>>> 
>>>>>>>>> On Oct 4, 2017, at 02:09, Lance Andersen <Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Jack,
>>>>>>>>> 
>>>>>>>>> Is this change correct:
>>>>>>>>> 
>>>>>>>>> -------------
>>>>>>>>> --- old/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.968185273 +0100
>>>>>>>>> +++ new/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.676185267 +0100
>>>>>>>>> @@ -373,7 +373,7 @@
>>>>>>>>>      *      If the {@link ValidationEventHandler ValidationEventHandler}
>>>>>>>>>      *      returns false from its {@code handleEvent} method or the
>>>>>>>>>      *      {@code Marshaller} is unable to marshal {@code jaxbElement} (or any
>>>>>>>>> -     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/javax/xml/bind/Marshaller.html#elementMarshalling">
>>>>>>>>> +     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/java/xml/bind/Marshaller.html#elementMarshalling">
>>>>>>>>>      *      Marshalling a JAXB element</a>.
>>>>>>>>> 
>>>>>>>>> ------------
>>>>>>>>> 
>>>>>>>>> The URL that is being changed currently works
>>>>>>>>> 
>>>>>>>>> Best
>>>>>>>>> Lance
>>>>>>>>>> On Sep 29, 2017, at 10:55 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>>>>>>>> 
>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>>
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>>
>>>>>>>>>> 
>>>>>>>>>> Summary of changes:
>>>>>>>>>> 
>>>>>>>>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>>>>>>>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>>>>>>>>> 
>>>>>>>>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>>>>>>>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>>>>>>>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Patch also contains several small bugfixes, not tracked in JBS.
>>>>>>>>>> 
>>>>>>>>>> ----------------
>>>>>>>>>> Best regards
>>>>>>>>>> Jack Li
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> <oracle_sig_logo.gif>
>>>>>>>>> 
>>>>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>>>> Oracle Java Engineering 
>>>>>>>>> 1 Network Drive 
>>>>>>>>> Burlington, MA 01803
>>>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>>>>>> 
>>>>>>>> ----------------
>>>>>>>> Best regards
>>>>>>>> Jack Li
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>> Oracle Java Engineering 
>>>>>>> 1 Network Drive 
>>>>>>> Burlington, MA 01803
>>>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ----------------
>>>>>> Best regards
>>>>>> Jack Li
>>>>> 
>>>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>> Oracle Java Engineering 
>>>>> 1 Network Drive 
>>>>> Burlington, MA 01803
>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> ----------------
>>>> Best regards
>>>> Jack Li
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> ----------------
>>> Best regards
>>> Jack Li
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>> 
>> 
>> 
> 
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> 
> 
> 

From david.holmes at oracle.com  Mon Nov  6 00:55:04 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 6 Nov 2017 10:55:04 +1000
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com>
 <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com>
Message-ID: <8cbd0397-a840-0c84-9a17-3dbe2a6bed1b@oracle.com>

On 4/11/2017 7:28 AM, Paul Sandoz wrote:
>> On 3 Nov 2017, at 11:14, Karen Kinnear <karen.kinnear at oracle.com> wrote:
>> 6. SD::find_java_mirror_for_type
>> You have resolve_or_null/fail doing CHECK_(empty) which should
>> check for a NULL constant_type_klass. This is followed by an explicit if
>> (constant_type_klass == NULL) ? is that needed?
>>
> 
> Can SD:resolve_or_null return a null value when HAS_PENDING_EXCEPTION=false?

I don't believe it actually can - the only reason you would get NULL is 
if something went wrong, for which an exception must be pending. 
However, even the internal implementation underlying this seems unclear 
on that point e.g in SystemDictionary::resolve_instance_class_or_null we 
have:

   if (HAS_PENDING_EXCEPTION || k == NULL) {
     return NULL;
   }

David
-----

> I see other usages that suggest this to be the case. Where as for resolve_or_fail:
> 
> Klass* SystemDictionary::resolve_or_fail(Symbol* class_name, Handle class_loader, Handle protection_domain, bool throw_error, TRAPS) {
>    Klass* klass = resolve_or_null(class_name, class_loader, protection_domain, THREAD);
>    if (HAS_PENDING_EXCEPTION || klass == NULL) {
>      // can return a null klass
>      klass = handle_resolution_exception(class_name, throw_error, klass, THREAD);
>    }
>    return klass;
> }
> 
> 
> It suggests we can change the code from:
> 
> if (failure_mode == SignatureStream::ReturnNull) {
>    constant_type_klass = resolve_or_null(type, class_loader, protection_domain,
>                                          CHECK_(empty));
> } else {
>    bool throw_error = (failure_mode == SignatureStream::NCDFError);
>    constant_type_klass = resolve_or_fail(type, class_loader, protection_domain,
>                                          throw_error, CHECK_(empty));
> }
> if (constant_type_klass == NULL) {
>    return Handle();  // report failure this way
> }
> 
> to
> 
> if (failure_mode == SignatureStream::ReturnNull) {
>    constant_type_klass = resolve_or_null(type, class_loader, protection_domain,
>                                          CHECK_(empty));
>    if (constant_type_klass == NULL) {
>      return Handle();  // report failure this way
>    }
> } else {
>    bool throw_error = (failure_mode == SignatureStream::NCDFError);
>    constant_type_klass = resolve_or_fail(type, class_loader, protection_domain,
>                                          throw_error, CHECK_(empty));
> }
> 
> ?
> 
> 
>> 7. reflection.cpp
>> get_mirror_from_signature
>> Looks like potential for side effects. Odd to set mirror_oop inside if (log_is_enabled)
>> Is the intent to assert that k->java_mirror() == mirror_oop?
>> Or is the issue that we have a make drop here and the potential for a safe point?
>> If so, make a handle and extract it on return?
>>
>> ? Or better yet - don?t make any changes to reflection.cpp - not necessary
>>
> 
> Lois, John?
> 
> My recollection was John was attempting to tunnel things through a single method find_java_mirror_for_type, but i agree the setting of mirror_oop is odd.
> 
> 
> 
>> 8. BootstrapMethodInvoker
>> Could you possibly add a comment that the default today is vmIsPushing and IsPullModeBSM is false?
>> Or find a slightly different naming to make that clearer?
> 
> boolean pullMode = isPullModeBSM(bootstrapMethod);  // default value is false
> boolean vmIsPushing = !staticArgumentsPulled(info); // default value is true
> 
> ?
> 
> 
>>
>> 9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java
>> How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that
>> was not ACC_STATIC?
> 
> https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.23
> 
> See the note under bootstrap_method_ref. The kind of method handle is constrained because of the arguments that are pushed on the stack before invocation. I believe it?s possible to have a constructor, but the declaring class would need to be a subtype of CallSite in the case of indy, and a subtype of the constant value type in the case of condy.
> 
> 
>> Or was not ACC_PUBLIC?
> 
> That?s dependent on the accessibility between the lookup class the the BSM declaring class.
> 
> 
>> Or was
>> Or did I read the invoke dynamic method incorrectly?
>>
> 
> By default, and for convenience, the InstructionHelper assumes the BSM is declared by the lookup class. I recently modified that to support the BSM being declared on another class, to test the minimal set of BSMs for condy (separate issue [1]). Note it?s always possible to use the bytecode API more directly.
> 
> So we can easily add more -ve tests for non-accessible or non-static BSMs.
> 
> Paul.
> 
> [1] http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/
> 

From ramanand.patil at oracle.com  Mon Nov  6 14:06:30 2017
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 6 Nov 2017 06:06:30 -0800 (PST)
Subject: JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c and 8190259: test
 tck.java.time.zone.TCKZoneRules is broken by tzdata2017c
Message-ID: <e0b6ec8c-9d01-4c57-8a49-884bb2317e6d@default>

Hi all,
Please review the latest TZDATA integration (tzdata2017c) to JDK10.
Bugs:
https://bugs.openjdk.java.net/browse/JDK-8190258
https://bugs.openjdk.java.net/browse/JDK-8190259

Webrev: http://cr.openjdk.java.net/~rpatil/8190258+8190259/webrev.00/

All the TimeZone related tests are passed after integration.

Regards,
Ramanand.

From Roger.Riggs at Oracle.com  Mon Nov  6 16:22:00 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 6 Nov 2017 11:22:00 -0500
Subject: RFR - 8190482: InnocuousThread creation should not require the
 caller to possess enableContextClassLoaderOverride
In-Reply-To: <09E42B38-0C64-42F6-881A-6B61A7ECFE7A@oracle.com>
References: <09E42B38-0C64-42F6-881A-6B61A7ECFE7A@oracle.com>
Message-ID: <4881c419-bab5-a302-c371-a23aa2d46eb3@Oracle.com>

Hi Chris,

Looks fine

Roger


On 11/5/2017 5:02 AM, Chris Hegarty wrote:
> Currently JDK code that wants to create innocuous threads is required to do so within a privileged context that has the "enableContextClassLoaderOverride" RuntimePermission ( since the InnocuousThread class overrides setContextClassLoader ). This permissions should not be required, especially if code in de-privileged modules wants to create innocuous threads.
>
> The factory methods for creating innocuous threads should assert privileges before constructing the thread.
>
> diff --git a/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java b/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java
> --- a/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java
> +++ b/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java
> @@ -62,10 +62,16 @@
>        * set to the system class loader.
>        */
>       public static Thread newThread(String name, Runnable target) {
> -        return new InnocuousThread(INNOCUOUSTHREADGROUP,
> -                                   target,
> -                                   name,
> -                                   ClassLoader.getSystemClassLoader());
> +        return AccessController.doPrivileged(
> +                new PrivilegedAction<Thread>() {
> +                    @Override
> +                    public Thread run() {
> +                        return new InnocuousThread(INNOCUOUSTHREADGROUP,
> +                                                   target,
> +                                                   name,
> +                                                   ClassLoader.getSystemClassLoader());
> +                    }
> +                });
>       }
>   
>       /**
> @@ -80,8 +86,14 @@
>        * Returns a new InnocuousThread with null context class loader.
>        */
>       public static Thread newSystemThread(String name, Runnable target) {
> -        return new InnocuousThread(INNOCUOUSTHREADGROUP,
> -                                   target, name, null);
> +        return AccessController.doPrivileged(
> +                new PrivilegedAction<Thread>() {
> +                    @Override
> +                    public Thread run() {
> +                        return new InnocuousThread(INNOCUOUSTHREADGROUP,
> +                                                   target, name, null);
> +                    }
> +                });
>       }
>   
> -Chris.


From mandy.chung at oracle.com  Mon Nov  6 19:29:43 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 6 Nov 2017 11:29:43 -0800
Subject: [Patch][JDK10] Use Class.getPackageName() where possible
In-Reply-To: <AM4PR08MB1219C410B9E57E3E39B2F9A2FF520@AM4PR08MB1219.eurprd08.prod.outlook.com>
References: <000101d3543e$840b6080$8c222180$@freenet.de>
 <72043f40-6a9c-f79a-66be-5e68e6ce1f0c@oracle.com>
 <000c01d3547a$ad4d6470$07e82d50$@freenet.de>
 <4a0476c1-1333-9e28-5b07-066b8fa74213@oracle.com>
 <AM4PR08MB1219C410B9E57E3E39B2F9A2FF520@AM4PR08MB1219.eurprd08.prod.outlook.com>
Message-ID: <ecea8e88-3890-50f8-fcf7-e8e9e3461127@oracle.com>


On 11/3/17 6:52 PM, Bernd Eckenfels wrote:
> The private static helper in ObjectStreamClass became a oneliner and can be removed and the callsites can transform from getPackageName(c) to c.getPackageName().

Good catch.?? we should clean that up.

Christoph - can you send a updated patch to remove 
ObjectStreamClass::getPackageName and replace the calls with 
Class::getPackageName and also remove VerifyAccess::getPackageName?

thanks
Mandy

> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> _____________________________
> From: mandy chung <mandy.chung at oracle.com<mailto:mandy.chung at oracle.com>>
> Sent: Samstag, November 4, 2017 1:12 AM
> Subject: Re: [Patch][JDK10] Use Class.getPackageName() where possible
> To: Christoph Dreis <christoph.dreis at freenet.de<mailto:christoph.dreis at freenet.de>>, 'Core-Libs-Dev' <core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>>
>
>
>
>
> On 11/3/17 1:06 AM, Christoph Dreis wrote:
>> Thanks - I updated both as you suggested to use Class::getPackageName. Please find the updated patch below.
> I have created https://bugs.openjdk.java.net/browse/JDK-8190733 for this
> patch.
>
>> There is also a public static VerifyAccess::getPackageName which seems to be not working with arrays at all and as far as I can see is at least not used inside the JDK itself.
>> Should this be deprecated maybe in favor of Class.getPackageName() or also adjusted to use it (which would mean different return values than before as you already noted)?
> VerifyAccess::getPackageName is unused in jdk8u-dev neither. So I think it can be removed. No deprecation is needed since this is JDK internal API and I hardly think anyone is depending on it.
>
> Mandy
>
>> Cheers,
>> Christoph
>>
>> ====== PATCH =======
>> diff -r 438e0c9f2f17 src/java.base/share/classes/java/io/ObjectInputFilter.java
>> --- a/src/java.base/share/classes/java/io/ObjectInputFilter.java Mon Oct 30 17:49:33 2017 -0700
>> +++ b/src/java.base/share/classes/java/io/ObjectInputFilter.java Fri Nov 03 08:38:15 2017 +0100
>> @@ -656,8 +656,8 @@
>> * otherwise {@code false}
>> */
>> private static boolean matchesPackage(Class<?> c, String pkg) {
>> - String n = c.getName();
>> - return n.startsWith(pkg) && n.lastIndexOf('.') == pkg.length() - 1;
>> + String n = c.getPackageName();
>> + return n.length() == pkg.length() - 1 && n.startsWith(pkg);
>> }
>>
>> /**
>>
>> diff -r 438e0c9f2f17 src/java.base/share/classes/java/io/ObjectStreamClass.java
>> --- a/src/java.base/share/classes/java/io/ObjectStreamClass.java Mon Oct 30 17:49:33 2017 -0700
>> +++ b/src/java.base/share/classes/java/io/ObjectStreamClass.java Fri Nov 03 08:38:15 2017 +0100
>> @@ -1587,11 +1587,7 @@
>> * Returns package name of given class.
>> */
>> private static String getPackageName(Class<?> cl) {
>> - String s = cl.getName();
>> - int i = s.lastIndexOf('[');
>> - i = (i < 0) ? 0 : i + 2;
>> - int j = s.lastIndexOf('.');
>> - return (i < j) ? s.substring(i, j) : "";
>> + return cl.getPackageName();
>> }
>>
>> /**
>>
>> diff -r 438e0c9f2f17 src/java.base/share/classes/java/lang/ClassLoader.java
>> --- a/src/java.base/share/classes/java/lang/ClassLoader.java Mon Oct 30 17:49:33 2017 -0700
>> +++ b/src/java.base/share/classes/java/lang/ClassLoader.java Fri Nov 03 08:38:15 2017 +0100
>> @@ -672,12 +672,11 @@
>> return;
>> }
>>
>> - final String name = cls.getName();
>> - final int i = name.lastIndexOf('.');
>> - if (i != -1) {
>> + final String packageName = cls.getPackageName();
>> + if (!packageName.isEmpty()) {
>> AccessController.doPrivileged(new PrivilegedAction<>() {
>> public Void run() {
>> - sm.checkPackageAccess(name.substring(0, i));
>> + sm.checkPackageAccess(packageName);
>> return null;
>> }
>> }, new AccessControlContext(new ProtectionDomain[] {pd}));
>>
>> diff -r 438e0c9f2f17 src/java.base/share/classes/java/lang/reflect/Proxy.java
>> --- a/src/java.base/share/classes/java/lang/reflect/Proxy.java Mon Oct 30 17:49:33 2017 -0700
>> +++ b/src/java.base/share/classes/java/lang/reflect/Proxy.java Fri Nov 03 08:38:15 2017 +0100
>> @@ -1034,11 +1034,8 @@
>>
>> // do permission check if the caller is in a different runtime package
>> // of the proxy class
>> - int n = proxyClass.getName().lastIndexOf('.');
>> - String pkg = (n == -1) ? "" : proxyClass.getName().substring(0, n);
>> -
>> - n = caller.getName().lastIndexOf('.');
>> - String callerPkg = (n == -1) ? "" : caller.getName().substring(0, n);
>> + String pkg = proxyClass.getPackageName();
>> + String callerPkg = caller.getPackageName();
>>
>> if (pcl != ccl || !pkg.equals(callerPkg)) {
>> sm.checkPermission(new ReflectPermission("newProxyInPackage." + pkg));
>>
>>
>
>


From mandy.chung at oracle.com  Mon Nov  6 19:37:16 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 6 Nov 2017 11:37:16 -0800
Subject: RFR - 8190482: InnocuousThread creation should not require the
 caller to possess enableContextClassLoaderOverride
In-Reply-To: <09E42B38-0C64-42F6-881A-6B61A7ECFE7A@oracle.com>
References: <09E42B38-0C64-42F6-881A-6B61A7ECFE7A@oracle.com>
Message-ID: <b2dc7708-adf5-b3ef-3f08-fd72242256e3@oracle.com>

Looks fine to me.

Mandy

On 11/5/17 2:02 AM, Chris Hegarty wrote:
> Currently JDK code that wants to create innocuous threads is required to do so within a privileged context that has the "enableContextClassLoaderOverride" RuntimePermission ( since the InnocuousThread class overrides setContextClassLoader ). This permissions should not be required, especially if code in de-privileged modules wants to create innocuous threads.
>
> The factory methods for creating innocuous threads should assert privileges before constructing the thread.
>
> diff --git a/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java b/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java
> --- a/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java
> +++ b/src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java
> @@ -62,10 +62,16 @@
>        * set to the system class loader.
>        */
>       public static Thread newThread(String name, Runnable target) {
> -        return new InnocuousThread(INNOCUOUSTHREADGROUP,
> -                                   target,
> -                                   name,
> -                                   ClassLoader.getSystemClassLoader());
> +        return AccessController.doPrivileged(
> +                new PrivilegedAction<Thread>() {
> +                    @Override
> +                    public Thread run() {
> +                        return new InnocuousThread(INNOCUOUSTHREADGROUP,
> +                                                   target,
> +                                                   name,
> +                                                   ClassLoader.getSystemClassLoader());
> +                    }
> +                });
>       }
>   
>       /**
> @@ -80,8 +86,14 @@
>        * Returns a new InnocuousThread with null context class loader.
>        */
>       public static Thread newSystemThread(String name, Runnable target) {
> -        return new InnocuousThread(INNOCUOUSTHREADGROUP,
> -                                   target, name, null);
> +        return AccessController.doPrivileged(
> +                new PrivilegedAction<Thread>() {
> +                    @Override
> +                    public Thread run() {
> +                        return new InnocuousThread(INNOCUOUSTHREADGROUP,
> +                                                   target, name, null);
> +                    }
> +                });
>       }
>   
> -Chris.


From martinrb at google.com  Mon Nov  6 20:00:35 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 6 Nov 2017 12:00:35 -0800
Subject: RFR: jsr166 jdk10 integration wave 5
Message-ID: <CA+kOe0-8aiXK2f5qR5FPp4uyA18QTVG8rgH7C96Qs0QG-GFF5g@mail.gmail.com>

The notable thing this time around is the embarrassing number of rare races
being fixed, all of which are second tries.  This time for sure!

There's a large number of boring changes to appease errorprone, notably
http://errorprone.info/bugpattern/RandomModInteger
http://errorprone.info/bugpattern/MixedArrayDimensions

http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/overview.html

8190747: ExecutorService/Invoke.java fails intermittently
8179314: CountedCompleterTest.testForkHelpQuiesce fails with expected:<21>
but was:<13>
8189387: ConcurrentLinkedDeque linearizability continued ...
8189764: Miscellaneous changes imported from jsr166 CVS 2017-11

From david.holmes at oracle.com  Mon Nov  6 21:36:04 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 7 Nov 2017 07:36:04 +1000
Subject: RFR: jsr166 jdk10 integration wave 5
In-Reply-To: <CA+kOe0-8aiXK2f5qR5FPp4uyA18QTVG8rgH7C96Qs0QG-GFF5g@mail.gmail.com>
References: <CA+kOe0-8aiXK2f5qR5FPp4uyA18QTVG8rgH7C96Qs0QG-GFF5g@mail.gmail.com>
Message-ID: <82163eec-1cbb-d9dc-fce4-5c7fc5b72927@oracle.com>

Hi Martin,

On 7/11/2017 6:00 AM, Martin Buchholz wrote:
> The notable thing this time around is the embarrassing number of rare 
> races being fixed, all of which are second tries.? This time for sure!
> 
> There's a large number of boring changes to appease errorprone, notably
> http://errorprone.info/bugpattern/RandomModInteger
> http://errorprone.info/bugpattern/MixedArrayDimensions
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/overview.html
> 
> 8190747: ExecutorService/Invoke.java fails intermittently

Looks fine.

> 8179314: CountedCompleterTest.testForkHelpQuiesce fails with 
> expected:<21> but was:<13>

Looks fine.

> 8189387: ConcurrentLinkedDeque linearizability continued ...

Can't really comment on linearizability changes but I found  this change 
to be very confusing:

src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java

       final Node<E> pred(Node<E> p) {
!         Node<E> q = p.prev;
!         return (p == q) ? last() : q;
       }

       /**
        * Returns the first node, the unique node p for which:
        *     p.prev == null && p.next != p
--- 693,705 ----
        * Returns the predecessor of p, or the last node if p.prev has been
        * linked to self, which will only be true if traversing with a
        * stale pointer that is now off the list.
        */
       final Node<E> pred(Node<E> p) {
!         if (p == (p = p.prev))
!             p = last();
!         return p;
       }

The original version is quite clear, the new version is trying to be far 
too clever with order of evaluation and to me is far less clear.


> 8189764: Miscellaneous changes imported from jsr166 CVS 2017-11

All seem okay. Though I'm curious about the changes from 
"catch(Throwable" to "catch(Exception" ?

Thanks,
David

From martinrb at google.com  Mon Nov  6 22:12:29 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 6 Nov 2017 14:12:29 -0800
Subject: RFR: jsr166 jdk10 integration wave 5
In-Reply-To: <82163eec-1cbb-d9dc-fce4-5c7fc5b72927@oracle.com>
References: <CA+kOe0-8aiXK2f5qR5FPp4uyA18QTVG8rgH7C96Qs0QG-GFF5g@mail.gmail.com>
 <82163eec-1cbb-d9dc-fce4-5c7fc5b72927@oracle.com>
Message-ID: <CA+kOe0_30EJ9c5NyOaxYkOFbSi21R=7p4p2sXhaADN4=OtzxvA@mail.gmail.com>

On Mon, Nov 6, 2017 at 1:36 PM, David Holmes <david.holmes at oracle.com>
wrote:

>
> src/java.base/share/classes/java/util/concurrent/ConcurrentL
> inkedDeque.java
>
>       final Node<E> pred(Node<E> p) {
> !         Node<E> q = p.prev;
> !         return (p == q) ? last() : q;
>       }
>
>       /**
>        * Returns the first node, the unique node p for which:
>        *     p.prev == null && p.next != p
> --- 693,705 ----
>        * Returns the predecessor of p, or the last node if p.prev has been
>        * linked to self, which will only be true if traversing with a
>        * stale pointer that is now off the list.
>        */
>       final Node<E> pred(Node<E> p) {
> !         if (p == (p = p.prev))
> !             p = last();
> !         return p;
>       }
>
> The original version is quite clear, the new version is trying to be far
> too clever with order of evaluation and to me is far less clear.


Well, this idiom is already in widespread use in these files, notably in
succ, which was non-symmetrical with pred for no reason.  The trickier code
saves 2 bytes of bytecode; admittedly unlikely to make a difference; we are
not near the 35-bytecode limit.  The more common form of the idiom is

                if (p == (p = p.next))
                    continue restart;

After 10 years working on lock-free queues it starts to look natural (but
don't try it in C++!)

From martinrb at google.com  Mon Nov  6 22:17:33 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 6 Nov 2017 14:17:33 -0800
Subject: RFR: jsr166 jdk10 integration wave 5
In-Reply-To: <82163eec-1cbb-d9dc-fce4-5c7fc5b72927@oracle.com>
References: <CA+kOe0-8aiXK2f5qR5FPp4uyA18QTVG8rgH7C96Qs0QG-GFF5g@mail.gmail.com>
 <82163eec-1cbb-d9dc-fce4-5c7fc5b72927@oracle.com>
Message-ID: <CA+kOe0_u1KQCNtPw8FdAaymrV6QpFA6XT1e=etvx_9LOTBW1KA@mail.gmail.com>

Thanks for the review!

On Mon, Nov 6, 2017 at 1:36 PM, David Holmes <david.holmes at oracle.com>
wrote:

>
> 8189764: Miscellaneous changes imported from jsr166 CVS 2017-11
>>
>
> All seem okay. Though I'm curious about the changes from "catch(Throwable"
> to "catch(Exception" ?
>

There's a half-hearted attempt to appease
http://errorprone.info/bugpattern/TryFailThrowable
No actual bugs were fixed.

From Roger.Riggs at Oracle.com  Mon Nov  6 22:18:52 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 6 Nov 2017 17:18:52 -0500
Subject: RFR 8187281 : Remove @intermittent from OnExitTest
Message-ID: <825523d0-0db1-b8b1-686c-aae162ce36ef@Oracle.com>

Please review the removal of the @intermittent keyword from OnExitTest.
The failure has not occurred since it was fixed on 9/21.

--- old/test/jdk/java/lang/ProcessHandle/OnExitTest.java	2017-11-06 16:45:40.762305867 -0500
+++ new/test/jdk/java/lang/ProcessHandle/OnExitTest.java	2017-11-06 16:45:40.206333294 -0500
@@ -40,7 +40,6 @@
  
  /*
   * @test
- * @key intermittent
   * @library /test/lib
   * @build jdk.test.lib.Utils
   * @run testng OnExitTest

Issue: https://bugs.openjdk.java.net/browse/JDK-8187281

Thanks, Roger

From lance.andersen at oracle.com  Mon Nov  6 22:23:57 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 6 Nov 2017 17:23:57 -0500
Subject: RFR 8187281 : Remove @intermittent from OnExitTest
In-Reply-To: <825523d0-0db1-b8b1-686c-aae162ce36ef@Oracle.com>
References: <825523d0-0db1-b8b1-686c-aae162ce36ef@Oracle.com>
Message-ID: <EE444774-E62E-4A87-AB71-138974EF7CDF@oracle.com>

looking good Roger
> On Nov 6, 2017, at 5:18 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Please review the removal of the @intermittent keyword from OnExitTest.
> The failure has not occurred since it was fixed on 9/21.
> 
> --- old/test/jdk/java/lang/ProcessHandle/OnExitTest.java	2017-11-06 16:45:40.762305867 -0500
> +++ new/test/jdk/java/lang/ProcessHandle/OnExitTest.java	2017-11-06 16:45:40.206333294 -0500
> @@ -40,7 +40,6 @@
>  /*
>  * @test
> - * @key intermittent
>  * @library /test/lib
>  * @build jdk.test.lib.Utils
>  * @run testng OnExitTest
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8187281
> 
> Thanks, Roger

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From naoto.sato at oracle.com  Mon Nov  6 23:48:15 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 6 Nov 2017 15:48:15 -0800
Subject: <i18n dev> JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c and
 8190259: test tck.java.time.zone.TCKZoneRules is broken by tzdata2017c
In-Reply-To: <e0b6ec8c-9d01-4c57-8a49-884bb2317e6d@default>
References: <e0b6ec8c-9d01-4c57-8a49-884bb2317e6d@default>
Message-ID: <1ec07748-3b87-5ec1-ff59-5da026807520@oracle.com>

Hi Ramanand,

In java/time/format/ZoneName.java, should the zid for Africa_Central map 
to "Africa/Maputo"?

Naoto

On 11/6/17 6:06 AM, Ramanand Patil wrote:
> Hi all,
> Please review the latest TZDATA integration (tzdata2017c) to JDK10.
> Bugs:
> https://bugs.openjdk.java.net/browse/JDK-8190258
> https://bugs.openjdk.java.net/browse/JDK-8190259
> 
> Webrev: http://cr.openjdk.java.net/~rpatil/8190258+8190259/webrev.00/
> 
> All the TimeZone related tests are passed after integration.
> 
> Regards,
> Ramanand.
> 

From brent.christian at oracle.com  Tue Nov  7 00:23:16 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 6 Nov 2017 16:23:16 -0800
Subject: RFR: 8185925 & 8153682 (footprint reduction of
 java.lang.StackFrameInfo)
Message-ID: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com>

Hi,

There are a couple opportunities to reduce the memory footprint of 
java.lang.StackFrameInfo (the internal implementation of 
java.lang.StackWalker.StackFrame):

8153682[1] : StackFrameInfo.declaringClass could be removed
8185925[2] : StackFrameInfo::walker field can be replaced with bitmap to 
save footprint

I had a look using jol[3].  Removing only 'walker' helps only under 32- 
and 64-bit, but not with compressed oops.  Removing both 'walker' and 
'declaringClass' brings a benefit to compressed oops as well (though not 
for 16-byte aligned).

The size change, in bytes, for each execution mode is as follows:

                              32-bit: 32->24
                              64-bit: 56->40
                  64/compressed oops: 32->24
64/compressed oops, 16-byte aligned: 32->32

(For reference, the jol reports for the baseline and specimen are at [4] 
and [5], respectively.)

Please review my code change for this.  The webrev is here:
http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/

An automated test run is in progress.

Thanks!
-Brent

--
1. https://bugs.openjdk.java.net/browse/JDK-8153682
2. https://bugs.openjdk.java.net/browse/JDK-8185925
3. http://openjdk.java.net/projects/code-tools/jol/
4. 
http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt
5. 
http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt

From david.holmes at oracle.com  Tue Nov  7 01:33:02 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 7 Nov 2017 11:33:02 +1000
Subject: RFR: jsr166 jdk10 integration wave 5
In-Reply-To: <CA+kOe0_u1KQCNtPw8FdAaymrV6QpFA6XT1e=etvx_9LOTBW1KA@mail.gmail.com>
References: <CA+kOe0-8aiXK2f5qR5FPp4uyA18QTVG8rgH7C96Qs0QG-GFF5g@mail.gmail.com>
 <82163eec-1cbb-d9dc-fce4-5c7fc5b72927@oracle.com>
 <CA+kOe0_u1KQCNtPw8FdAaymrV6QpFA6XT1e=etvx_9LOTBW1KA@mail.gmail.com>
Message-ID: <ef91d796-f804-6d60-57b2-83bedc602916@oracle.com>

On 7/11/2017 8:17 AM, Martin Buchholz wrote:
> Thanks for the review!
> 
> On Mon, Nov 6, 2017 at 1:36 PM, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
> 
>         8189764: Miscellaneous changes imported from jsr166 CVS 2017-11
> 
> 
>     All seem okay. Though I'm curious about the changes from
>     "catch(Throwable" to "catch(Exception" ?
> 
> 
> There's a half-hearted attempt to appease
> http://errorprone.info/bugpattern/TryFailThrowable
> No actual bugs were fixed.

Hmmm. Not sure I see a problem if threadUnexpectedException just wraps 
and rethrows the original exception. On the other hand Errors are no 
longer being handled this way. Probably doesn't make a difference either 
way.

Thanks,
David

From forax at univ-mlv.fr  Tue Nov  7 07:45:32 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 7 Nov 2017 08:45:32 +0100 (CET)
Subject: RFR: 8185925 & 8153682 (footprint reduction of
 java.lang.StackFrameInfo)
In-Reply-To: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com>
References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com>
Message-ID: <1246227356.615417.1510040732859.JavaMail.zimbra@u-pem.fr>

Hi Brent,
if you declare retainClassRef as a byte, you can even compress the data structure a little bit more, no ?
a boolean (as a field) uses 4 bytes while a byte uses welll 1 byte.
Given that bci is a short, the VM will put both bci and retainClassRef on the same 32 bits slot.

cheers,
R?mi

----- Mail original -----
> De: "Brent Christian" <brent.christian at oracle.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev" <hotspot-dev at openjdk.java.net>
> Envoy?: Mardi 7 Novembre 2017 01:23:16
> Objet: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo)

> Hi,
> 
> There are a couple opportunities to reduce the memory footprint of
> java.lang.StackFrameInfo (the internal implementation of
> java.lang.StackWalker.StackFrame):
> 
> 8153682[1] : StackFrameInfo.declaringClass could be removed
> 8185925[2] : StackFrameInfo::walker field can be replaced with bitmap to
> save footprint
> 
> I had a look using jol[3].  Removing only 'walker' helps only under 32-
> and 64-bit, but not with compressed oops.  Removing both 'walker' and
> 'declaringClass' brings a benefit to compressed oops as well (though not
> for 16-byte aligned).
> 
> The size change, in bytes, for each execution mode is as follows:
> 
>                              32-bit: 32->24
>                              64-bit: 56->40
>                  64/compressed oops: 32->24
> 64/compressed oops, 16-byte aligned: 32->32
> 
> (For reference, the jol reports for the baseline and specimen are at [4]
> and [5], respectively.)
> 
> Please review my code change for this.  The webrev is here:
> http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/
> 
> An automated test run is in progress.
> 
> Thanks!
> -Brent
> 
> --
> 1. https://bugs.openjdk.java.net/browse/JDK-8153682
> 2. https://bugs.openjdk.java.net/browse/JDK-8185925
> 3. http://openjdk.java.net/projects/code-tools/jol/
> 4.
> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt
> 5.
> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt

From ramanand.patil at oracle.com  Tue Nov  7 11:41:42 2017
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Tue, 7 Nov 2017 03:41:42 -0800 (PST)
Subject: <i18n dev> JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c and
 8190259: test tck.java.time.zone.TCKZoneRules is broken by tzdata2017c
In-Reply-To: <1ec07748-3b87-5ec1-ff59-5da026807520@oracle.com>
References: <e0b6ec8c-9d01-4c57-8a49-884bb2317e6d@default>
 <1ec07748-3b87-5ec1-ff59-5da026807520@oracle.com>
Message-ID: <17f3b700-4c79-4cb7-b869-7943a9b87854@default>

Hi Naoto,
Thank you for pointing that. I have modified both the affected files(ZoneName.java from src and test).
Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8190258+8190259/webrev.01/

Regards,
Ramanand.

> -----Original Message-----
> From: Naoto Sato
> Sent: Tuesday, November 07, 2017 5:18 AM
> To: Ramanand Patil <ramanand.patil at oracle.com>; core-libs-dev <core-libs-
> dev at openjdk.java.net>; i18n-dev at openjdk.java.net
> Subject: Re: <i18n dev> JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c
> and 8190259: test tck.java.time.zone.TCKZoneRules is broken by tzdata2017c
> 
> Hi Ramanand,
> 
> In java/time/format/ZoneName.java, should the zid for Africa_Central map
> to "Africa/Maputo"?
> 
> Naoto
> 
> On 11/6/17 6:06 AM, Ramanand Patil wrote:
> > Hi all,
> > Please review the latest TZDATA integration (tzdata2017c) to JDK10.
> > Bugs:
> > https://bugs.openjdk.java.net/browse/JDK-8190258
> > https://bugs.openjdk.java.net/browse/JDK-8190259
> >
> > Webrev: http://cr.openjdk.java.net/~rpatil/8190258+8190259/webrev.00/
> >
> > All the TimeZone related tests are passed after integration.
> >
> > Regards,
> > Ramanand.
> >

From christoph.dreis at freenet.de  Tue Nov  7 14:48:16 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Tue, 7 Nov 2017 15:48:16 +0100
Subject: [Patch][JDK10] Use Class.getPackageName() where possible
In-Reply-To: <ecea8e88-3890-50f8-fcf7-e8e9e3461127@oracle.com>
References: <000101d3543e$840b6080$8c222180$@freenet.de>
 <72043f40-6a9c-f79a-66be-5e68e6ce1f0c@oracle.com>
 <000c01d3547a$ad4d6470$07e82d50$@freenet.de>
 <4a0476c1-1333-9e28-5b07-066b8fa74213@oracle.com>
 <AM4PR08MB1219C410B9E57E3E39B2F9A2FF520@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ecea8e88-3890-50f8-fcf7-e8e9e3461127@oracle.com>
Message-ID: <000001d357d7$7269fc50$573df4f0$@freenet.de>

Hi,

> On 11/3/17 6:52 PM, Bernd Eckenfels wrote:
>> The private static helper in ObjectStreamClass became a oneliner and can be removed and the callsites can transform from getPackageName(c) to c.getPackageName().
> Good catch.   we should clean that up.
> Christoph - can you send a updated patch to remove ObjectStreamClass::getPackageName and replace the calls with Class::getPackageName and also remove VerifyAccess::getPackageName?

Please find the updated patch below.

Cheers,
Christoph


======= PATCH =======
diff -r 67aa34b019e1 src/java.base/share/classes/java/io/ObjectInputFilter.java
--- a/src/java.base/share/classes/java/io/ObjectInputFilter.java	Mon Nov 06 17:48:00 2017 -0800
+++ b/src/java.base/share/classes/java/io/ObjectInputFilter.java	Tue Nov 07 15:44:36 2017 +0100
@@ -656,8 +656,8 @@
              * otherwise {@code false}
              */
             private static boolean matchesPackage(Class<?> c, String pkg) {
-                String n = c.getName();
-                return n.startsWith(pkg) && n.lastIndexOf('.') == pkg.length() - 1;
+                String n = c.getPackageName();
+                return n.length() == pkg.length() - 1 && n.startsWith(pkg);
             }
 
             /**
diff -r 67aa34b019e1 src/java.base/share/classes/java/io/ObjectStreamClass.java
--- a/src/java.base/share/classes/java/io/ObjectStreamClass.java	Mon Nov 06 17:48:00 2017 -0800
+++ b/src/java.base/share/classes/java/io/ObjectStreamClass.java	Tue Nov 07 15:44:36 2017 +0100
@@ -1580,18 +1580,7 @@
      */
     private static boolean packageEquals(Class<?> cl1, Class<?> cl2) {
         return (cl1.getClassLoader() == cl2.getClassLoader() &&
-                getPackageName(cl1).equals(getPackageName(cl2)));
-    }
-
-    /**
-     * Returns package name of given class.
-     */
-    private static String getPackageName(Class<?> cl) {
-        String s = cl.getName();
-        int i = s.lastIndexOf('[');
-        i = (i < 0) ? 0 : i + 2;
-        int j = s.lastIndexOf('.');
-        return (i < j) ? s.substring(i, j) : "";
+                cl1.getPackageName().equals(cl2.getPackageName()));
     }
 
     /**
diff -r 67aa34b019e1 src/java.base/share/classes/java/lang/ClassLoader.java
--- a/src/java.base/share/classes/java/lang/ClassLoader.java	Mon Nov 06 17:48:00 2017 -0800
+++ b/src/java.base/share/classes/java/lang/ClassLoader.java	Tue Nov 07 15:44:36 2017 +0100
@@ -675,12 +675,11 @@
                 return;
             }
 
-            final String name = cls.getName();
-            final int i = name.lastIndexOf('.');
-            if (i != -1) {
+            final String packageName = cls.getPackageName();
+            if (!packageName.isEmpty()) {
                 AccessController.doPrivileged(new PrivilegedAction<>() {
                     public Void run() {
-                        sm.checkPackageAccess(name.substring(0, i));
+                        sm.checkPackageAccess(packageName);
                         return null;
                     }
                 }, new AccessControlContext(new ProtectionDomain[] {pd}));
diff -r 67aa34b019e1 src/java.base/share/classes/java/lang/reflect/Proxy.java
--- a/src/java.base/share/classes/java/lang/reflect/Proxy.java	Mon Nov 06 17:48:00 2017 -0800
+++ b/src/java.base/share/classes/java/lang/reflect/Proxy.java	Tue Nov 07 15:44:36 2017 +0100
@@ -1034,11 +1034,8 @@
 
                 // do permission check if the caller is in a different runtime package
                 // of the proxy class
-                int n = proxyClass.getName().lastIndexOf('.');
-                String pkg = (n == -1) ? "" : proxyClass.getName().substring(0, n);
-
-                n = caller.getName().lastIndexOf('.');
-                String callerPkg = (n == -1) ? "" : caller.getName().substring(0, n);
+                String pkg = proxyClass.getPackageName();
+                String callerPkg = caller.getPackageName();
 
                 if (pcl != ccl || !pkg.equals(callerPkg)) {
                     sm.checkPermission(new ReflectPermission("newProxyInPackage." + pkg));
diff -r 67aa34b019e1 src/java.base/share/classes/sun/invoke/util/VerifyAccess.java
--- a/src/java.base/share/classes/sun/invoke/util/VerifyAccess.java	Mon Nov 06 17:48:00 2017 -0800
+++ b/src/java.base/share/classes/sun/invoke/util/VerifyAccess.java	Tue Nov 07 15:44:36 2017 +0100
@@ -332,16 +332,6 @@
         return Objects.equals(class1.getPackageName(), class2.getPackageName());
     }
 
-    /** Return the package name for this class.
-     */
-    public static String getPackageName(Class<?> cls) {
-        assert (!cls.isArray());
-        String name = cls.getName();
-        int dot = name.lastIndexOf('.');
-        if (dot < 0) return "";
-        return name.substring(0, dot);
-    }
-
     /**
      * Test if two classes are defined as part of the same package member (top-level class).
      * If this is true, they can share private access with each other.



From paul.sandoz at oracle.com  Tue Nov  7 16:31:02 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 7 Nov 2017 08:31:02 -0800
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <8cbd0397-a840-0c84-9a17-3dbe2a6bed1b@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com>
 <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com>
 <8cbd0397-a840-0c84-9a17-3dbe2a6bed1b@oracle.com>
Message-ID: <B7028E51-6948-499E-B5AD-389354B5EBAC@oracle.com>


> On 5 Nov 2017, at 16:55, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 4/11/2017 7:28 AM, Paul Sandoz wrote:
>>> On 3 Nov 2017, at 11:14, Karen Kinnear <karen.kinnear at oracle.com> wrote:
>>> 6. SD::find_java_mirror_for_type
>>> You have resolve_or_null/fail doing CHECK_(empty) which should
>>> check for a NULL constant_type_klass. This is followed by an explicit if
>>> (constant_type_klass == NULL) ? is that needed?
>>> 
>> Can SD:resolve_or_null return a null value when HAS_PENDING_EXCEPTION=false?
> 
> I don't believe it actually can - the only reason you would get NULL is if something went wrong, for which an exception must be pending. However, even the internal implementation underlying this seems unclear on that point

Right, i am gonna leave things as they are for now unless we come up with a more definitive answer.

Paul.

> e.g in SystemDictionary::resolve_instance_class_or_null we have:
> 
>  if (HAS_PENDING_EXCEPTION || k == NULL) {
>    return NULL;
>  }
> 
> David
> ??

From brent.christian at oracle.com  Tue Nov  7 16:42:33 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 7 Nov 2017 08:42:33 -0800
Subject: RFR: 8185925 & 8153682 (footprint reduction of
 java.lang.StackFrameInfo)
In-Reply-To: <1246227356.615417.1510040732859.JavaMail.zimbra@u-pem.fr>
References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com>
 <1246227356.615417.1510040732859.JavaMail.zimbra@u-pem.fr>
Message-ID: <a9fc9664-ea13-ce3b-24bd-38e2e21c5e2c@oracle.com>

Hi, Remi

Thanks for the idea.  From my reading of the jol ouput:

http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt 


I believe retainClassRef is already being stored in a single byte (i.e. 
SIZE of 1):

  OFFSET  SIZE     TYPE DESCRIPTION
...
      10     1  boolean StackFrameInfo.retainClassRef

Thanks,
-Brent

On 11/6/17 11:45 PM, Remi Forax wrote:
> Hi Brent,
> if you declare retainClassRef as a byte, you can even compress the data structure a little bit more, no ?
> a boolean (as a field) uses 4 bytes while a byte uses welll 1 byte.
> Given that bci is a short, the VM will put both bci and retainClassRef on the same 32 bits slot.
> 
> cheers,
> R?mi
> 
> ----- Mail original -----
>> De: "Brent Christian" <brent.christian at oracle.com>
>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev" <hotspot-dev at openjdk.java.net>
>> Envoy?: Mardi 7 Novembre 2017 01:23:16
>> Objet: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo)
> 
>> Hi,
>>
>> There are a couple opportunities to reduce the memory footprint of
>> java.lang.StackFrameInfo (the internal implementation of
>> java.lang.StackWalker.StackFrame):
>>
>> 8153682[1] : StackFrameInfo.declaringClass could be removed
>> 8185925[2] : StackFrameInfo::walker field can be replaced with bitmap to
>> save footprint
>>
>> I had a look using jol[3].  Removing only 'walker' helps only under 32-
>> and 64-bit, but not with compressed oops.  Removing both 'walker' and
>> 'declaringClass' brings a benefit to compressed oops as well (though not
>> for 16-byte aligned).
>>
>> The size change, in bytes, for each execution mode is as follows:
>>
>>                               32-bit: 32->24
>>                               64-bit: 56->40
>>                   64/compressed oops: 32->24
>> 64/compressed oops, 16-byte aligned: 32->32
>>
>> (For reference, the jol reports for the baseline and specimen are at [4]
>> and [5], respectively.)
>>
>> Please review my code change for this.  The webrev is here:
>> http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/
>>
>> An automated test run is in progress.
>>
>> Thanks!
>> -Brent
>>
>> --
>> 1. https://bugs.openjdk.java.net/browse/JDK-8153682
>> 2. https://bugs.openjdk.java.net/browse/JDK-8185925
>> 3. http://openjdk.java.net/projects/code-tools/jol/
>> 4.
>> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt
>> 5.
>> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt

From mandy.chung at oracle.com  Tue Nov  7 17:45:59 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 7 Nov 2017 09:45:59 -0800
Subject: RFR: 8185925 & 8153682 (footprint reduction of
 java.lang.StackFrameInfo)
In-Reply-To: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com>
References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com>
Message-ID: <40ffc6a6-68c1-5654-e5c4-d451e7a2b9b7@oracle.com>



On 11/6/17 4:23 PM, Brent Christian wrote:
> Please review my code change for this.? The webrev is here:
> http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/
>

It's a good footprint improvement.? Thanks for doing this.

StackFrameInfo.java

   38     // Footprint improvement: MemberName::clazz can replace
   39     // StackFrameInfo::declaringClass.


The above comment can be removed.

41 private final boolean retainClassRef;

JVMS [1] has a note about Hotspot implementation of boolean array that 
is encoded as a byte array. That explains JOL output that this boolean 
field is 8-bit in our implementation.? This field could be changed to a 
byte to hold additional flags, if any in the future.? It may be good to 
change this to a byte making the field size explicit.

Otherwise looks good.

Mandy
[1] 
https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-2.html#jvms-2.3.4
> An automated test run is in progress.
>
> Thanks!
> -Brent
>
> -- 
> 1. https://bugs.openjdk.java.net/browse/JDK-8153682
> 2. https://bugs.openjdk.java.net/browse/JDK-8185925
> 3. http://openjdk.java.net/projects/code-tools/jol/
> 4. 
> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt
> 5. 
> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt


From forax at univ-mlv.fr  Tue Nov  7 18:25:00 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 07 Nov 2017 18:25:00 +0000
Subject: RFR: 8185925 & 8153682 (footprint reduction of
 java.lang.StackFrameInfo)
In-Reply-To: <a9fc9664-ea13-ce3b-24bd-38e2e21c5e2c@oracle.com>
References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com>
 <1246227356.615417.1510040732859.JavaMail.zimbra@u-pem.fr>
 <a9fc9664-ea13-ce3b-24bd-38e2e21c5e2c@oracle.com>
Message-ID: <B23B45AF-D2C8-46AA-BBCF-3E7CBC82BE5C@univ-mlv.fr>

My bad,
I've calculated that the header was 8 bytes instead of 12, so I've supposed that the boolean was not stored in a byte.

For my culture, why the header is 12 bytes, the pointer to the vtable is on 64bits and can not be compressed like the other oops ?

R?mi


On November 7, 2017 5:42:33 PM GMT+01:00, Brent Christian <brent.christian at oracle.com> wrote:
>Hi, Remi
>
>Thanks for the idea.  From my reading of the jol ouput:
>
>http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt
>
>
>
>I believe retainClassRef is already being stored in a single byte (i.e.
>
>SIZE of 1):
>
>  OFFSET  SIZE     TYPE DESCRIPTION
>...
>      10     1  boolean StackFrameInfo.retainClassRef
>
>Thanks,
>-Brent
>
>On 11/6/17 11:45 PM, Remi Forax wrote:
>> Hi Brent,
>> if you declare retainClassRef as a byte, you can even compress the
>data structure a little bit more, no ?
>> a boolean (as a field) uses 4 bytes while a byte uses welll 1 byte.
>> Given that bci is a short, the VM will put both bci and
>retainClassRef on the same 32 bits slot.
>> 
>> cheers,
>> R?mi
>> 
>> ----- Mail original -----
>>> De: "Brent Christian" <brent.christian at oracle.com>
>>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev"
><hotspot-dev at openjdk.java.net>
>>> Envoy?: Mardi 7 Novembre 2017 01:23:16
>>> Objet: RFR: 8185925 & 8153682 (footprint reduction of
>java.lang.StackFrameInfo)
>> 
>>> Hi,
>>>
>>> There are a couple opportunities to reduce the memory footprint of
>>> java.lang.StackFrameInfo (the internal implementation of
>>> java.lang.StackWalker.StackFrame):
>>>
>>> 8153682[1] : StackFrameInfo.declaringClass could be removed
>>> 8185925[2] : StackFrameInfo::walker field can be replaced with
>bitmap to
>>> save footprint
>>>
>>> I had a look using jol[3].  Removing only 'walker' helps only under
>32-
>>> and 64-bit, but not with compressed oops.  Removing both 'walker'
>and
>>> 'declaringClass' brings a benefit to compressed oops as well (though
>not
>>> for 16-byte aligned).
>>>
>>> The size change, in bytes, for each execution mode is as follows:
>>>
>>>                               32-bit: 32->24
>>>                               64-bit: 56->40
>>>                   64/compressed oops: 32->24
>>> 64/compressed oops, 16-byte aligned: 32->32
>>>
>>> (For reference, the jol reports for the baseline and specimen are at
>[4]
>>> and [5], respectively.)
>>>
>>> Please review my code change for this.  The webrev is here:
>>> http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/
>>>
>>> An automated test run is in progress.
>>>
>>> Thanks!
>>> -Brent
>>>
>>> --
>>> 1. https://bugs.openjdk.java.net/browse/JDK-8153682
>>> 2. https://bugs.openjdk.java.net/browse/JDK-8185925
>>> 3. http://openjdk.java.net/projects/code-tools/jol/
>>> 4.
>>>
>http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt
>>> 5.
>>>
>http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From paul.sandoz at oracle.com  Tue Nov  7 18:38:57 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 7 Nov 2017 10:38:57 -0800
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
Message-ID: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>

Hi,

Please review the patch that adds a minimal set of bootstrap methods can be be used for producing dynamic constants:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/>

The aim is to provide a small but common set of BSMs that are likely useful with ldc or as BSM arguments, filling in the gaps for constants that cannot be currently represented, such as null, primitive classes and VarHandles. It?s possible to get more sophisticated regarding say factories but that is something to consider later on.

This patch is based off the minimal dynamic constant support (still in review):

  http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html>

Paul.


From naoto.sato at oracle.com  Tue Nov  7 18:38:10 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 7 Nov 2017 10:38:10 -0800
Subject: <i18n dev> JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c and
 8190259: test tck.java.time.zone.TCKZoneRules is broken by tzdata2017c
In-Reply-To: <17f3b700-4c79-4cb7-b869-7943a9b87854@default>
References: <e0b6ec8c-9d01-4c57-8a49-884bb2317e6d@default>
 <1ec07748-3b87-5ec1-ff59-5da026807520@oracle.com>
 <17f3b700-4c79-4cb7-b869-7943a9b87854@default>
Message-ID: <8bc77da3-515f-6bca-22b3-82bd6685bff2@oracle.com>

Looks good.

Naoto

On 11/7/17 3:41 AM, Ramanand Patil wrote:
> Hi Naoto,
> Thank you for pointing that. I have modified both the affected files(ZoneName.java from src and test).
> Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8190258+8190259/webrev.01/
> 
> Regards,
> Ramanand.
> 
>> -----Original Message-----
>> From: Naoto Sato
>> Sent: Tuesday, November 07, 2017 5:18 AM
>> To: Ramanand Patil <ramanand.patil at oracle.com>; core-libs-dev <core-libs-
>> dev at openjdk.java.net>; i18n-dev at openjdk.java.net
>> Subject: Re: <i18n dev> JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c
>> and 8190259: test tck.java.time.zone.TCKZoneRules is broken by tzdata2017c
>>
>> Hi Ramanand,
>>
>> In java/time/format/ZoneName.java, should the zid for Africa_Central map
>> to "Africa/Maputo"?
>>
>> Naoto
>>
>> On 11/6/17 6:06 AM, Ramanand Patil wrote:
>>> Hi all,
>>> Please review the latest TZDATA integration (tzdata2017c) to JDK10.
>>> Bugs:
>>> https://bugs.openjdk.java.net/browse/JDK-8190258
>>> https://bugs.openjdk.java.net/browse/JDK-8190259
>>>
>>> Webrev: http://cr.openjdk.java.net/~rpatil/8190258+8190259/webrev.00/
>>>
>>> All the TimeZone related tests are passed after integration.
>>>
>>> Regards,
>>> Ramanand.
>>>

From martinrb at google.com  Tue Nov  7 18:48:11 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 7 Nov 2017 10:48:11 -0800
Subject: <i18n dev> JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c and
 8190259: test tck.java.time.zone.TCKZoneRules is broken by tzdata2017c
In-Reply-To: <17f3b700-4c79-4cb7-b869-7943a9b87854@default>
References: <e0b6ec8c-9d01-4c57-8a49-884bb2317e6d@default>
 <1ec07748-3b87-5ec1-ff59-5da026807520@oracle.com>
 <17f3b700-4c79-4cb7-b869-7943a9b87854@default>
Message-ID: <CA+kOe0-3ckvbbHqSCQFQ67iwbvmWoOit+7vKH1h6wNMD0xyy2Q@mail.gmail.com>

Looks good to me too.

I've always wondered about how the corresponding java source files are
maintained.  Is it all manual or do y'all have some magic script to help
keep IANA data and java data aligned?  Do we need more testing that
mistakes don't creep in?

On Tue, Nov 7, 2017 at 3:41 AM, Ramanand Patil <ramanand.patil at oracle.com>
wrote:

> Hi Naoto,
> Thank you for pointing that. I have modified both the affected
> files(ZoneName.java from src and test).
> Here is the updated Webrev: http://cr.openjdk.java.net/~
> rpatil/8190258+8190259/webrev.01/
>
> Regards,
> Ramanand.
>
> > -----Original Message-----
> > From: Naoto Sato
> > Sent: Tuesday, November 07, 2017 5:18 AM
> > To: Ramanand Patil <ramanand.patil at oracle.com>; core-libs-dev
> <core-libs-
> > dev at openjdk.java.net>; i18n-dev at openjdk.java.net
> > Subject: Re: <i18n dev> JDK10 RFR of JDK-8190258: (tz) Support
> tzdata2017c
> > and 8190259: test tck.java.time.zone.TCKZoneRules is broken by
> tzdata2017c
> >
> > Hi Ramanand,
> >
> > In java/time/format/ZoneName.java, should the zid for Africa_Central map
> > to "Africa/Maputo"?
> >
> > Naoto
> >
> > On 11/6/17 6:06 AM, Ramanand Patil wrote:
> > > Hi all,
> > > Please review the latest TZDATA integration (tzdata2017c) to JDK10.
> > > Bugs:
> > > https://bugs.openjdk.java.net/browse/JDK-8190258
> > > https://bugs.openjdk.java.net/browse/JDK-8190259
> > >
> > > Webrev: http://cr.openjdk.java.net/~rpatil/8190258+8190259/webrev.00/
> > >
> > > All the TimeZone related tests are passed after integration.
> > >
> > > Regards,
> > > Ramanand.
> > >
>

From huizhe.wang at oracle.com  Tue Nov  7 19:12:36 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 07 Nov 2017 11:12:36 -0800
Subject: RFR (JDK10/JAXP) 8181151: Fix lint warnings in JAXP repo: cast
Message-ID: <5A0205A4.5050006@oracle.com>

Hi,

This change fixes about 300 [cast] warnings in the JAXP sources. Changes 
are basically removing the redundant cast, a bit more than that only in 
one case: in XSDUniqueOrKeyTraverser at line 92, uniqueOrKey was 
assigned to itself when it meant to be "idc". The change didn't affect 
the operation since idc is a result of the get operation with 
uniqueOrKey's name.

JAXP tests passed.

JBS: https://bugs.openjdk.java.net/browse/JDK-8181151
webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181151/webrev/

Thanks,
Joe

From forax at univ-mlv.fr  Tue Nov  7 19:33:11 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 7 Nov 2017 20:33:11 +0100 (CET)
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
Message-ID: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>

Hi Paul,

You have an import static requireNonNull but it is only used once in nullConstant, all other methods use Objects.requireNonNull.

The test that checks that lookup, name and type are null or not is different in each method,
so by example in primitiveClass, if type equals null, you get an IAE. 

I fail to see the point of using validateClassAccess(), if the BSM is used through an indy, the type is created only if the caller class can create it, so the test seems redundant. If it's not used by an indy, why do we need to test that ? Also, why it's not called in invoke ?

There is also no reason to validate that the parameter type is the right one because the VM will validate the return type of the BSM is asTypable to the type sent as argument.

Some methods use generics, so other don't. Given it's not useful to use generics if the methods is used as a BSM, i think the generics signature should be removed, otherwise, getstatic and invoke should use generics.

In nullConstant, you do not need a requireNonNull here, getting you call isPrimitive() just after.

In primitiveClass, the second test is equivalent to name.length() != 1, to remove the @SuppressWarnings, type should be declared as a Class<Class<?>>. Why not using getstatic to retrieve the field Type of the wrapper instead ?

If you have invoke(), you do not need enumConstant because you can cook a constant method handle Enum.valueOf and send it to invoke. The methods that returns VarHandles are trickier because you need a Lookup object. 

getstatic should be renamed to getConstant because this is what it does.
wrapping the Throwable in a LinkageError seems wrong to me given that a calls to a BSM already does that, so getstatic can just declare "throws Throawble" like invoke and you have the same semantics.

in arrayVarHandle, the doc said that lookup is not used but lookup is used.

in validateClassAccess, the return can be moved at the end of the method.

and as a minor issue, all the ifs should be followed by curly braces per the coding convention.

cheers,
R?mi

----- Mail original -----
> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev" <hotspot-dev at openjdk.java.net>
> Envoy?: Mardi 7 Novembre 2017 19:38:57
> Objet: RFR 8187742 Minimal set of bootstrap methods for dynamic constants

> Hi,
> 
> Please review the patch that adds a minimal set of bootstrap methods can be be
> used for producing dynamic constants:
> 
>  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/
>  <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/>
> 
> The aim is to provide a small but common set of BSMs that are likely useful with
> ldc or as BSM arguments, filling in the gaps for constants that cannot be
> currently represented, such as null, primitive classes and VarHandles. It?s
> possible to get more sophisticated regarding say factories but that is
> something to consider later on.
> 
> This patch is based off the minimal dynamic constant support (still in review):
> 
>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html
>  <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html>
> 
> Paul.

From lance.andersen at oracle.com  Tue Nov  7 19:47:25 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 7 Nov 2017 14:47:25 -0500
Subject: RFR (JDK10/JAXP) 8181151: Fix lint warnings in JAXP repo: cast
In-Reply-To: <5A0205A4.5050006@oracle.com>
References: <5A0205A4.5050006@oracle.com>
Message-ID: <70BBA69B-4226-498E-ACA2-17F9EDFE4710@oracle.com>

Looks OK Joe
> On Nov 7, 2017, at 2:12 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> Hi,
> 
> This change fixes about 300 [cast] warnings in the JAXP sources. Changes are basically removing the redundant cast, a bit more than that only in one case: in XSDUniqueOrKeyTraverser at line 92, uniqueOrKey was assigned to itself when it meant to be "idc". The change didn't affect the operation since idc is a result of the get operation with uniqueOrKey's name.
> 
> JAXP tests passed.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8181151
> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181151/webrev/
> 
> Thanks,
> Joe

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From vitalyd at gmail.com  Tue Nov  7 19:48:43 2017
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 07 Nov 2017 19:48:43 +0000
Subject: RFR: 8185925 & 8153682 (footprint reduction of
 java.lang.StackFrameInfo)
In-Reply-To: <B23B45AF-D2C8-46AA-BBCF-3E7CBC82BE5C@univ-mlv.fr>
References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com>
 <1246227356.615417.1510040732859.JavaMail.zimbra@u-pem.fr>
 <a9fc9664-ea13-ce3b-24bd-38e2e21c5e2c@oracle.com>
 <B23B45AF-D2C8-46AA-BBCF-3E7CBC82BE5C@univ-mlv.fr>
Message-ID: <CAHjP37GQRV0J3ER3qZnudiEcoBA04LL+YYu7o_xLg4iup2PjMw@mail.gmail.com>

On Tue, Nov 7, 2017 at 1:25 PM Remi Forax <forax at univ-mlv.fr> wrote:

> My bad,
> I've calculated that the header was 8 bytes instead of 12, so I've
> supposed that the boolean was not stored in a byte.
>
> For my culture, why the header is 12 bytes, the pointer to the vtable is
> on 64bits and can not be compressed like the other oops ?

It?s 12 bytes (on x64) with compressed klass ptr; 8 bytes for the mark word
and a 4 byte compressed klass ptr.  It?s 16 bytes without compressed klass
ptr.  Or are you asking something else Remi?

I think many folks would be upset if a boolean wasn?t stored as a byte :).

>
>
> R?mi
>
>
> On November 7, 2017 5:42:33 PM GMT+01:00, Brent Christian <
> brent.christian at oracle.com> wrote:
> >Hi, Remi
> >
> >Thanks for the idea.  From my reading of the jol ouput:
> >
> >
> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt
> >
> >
> >
> >I believe retainClassRef is already being stored in a single byte (i.e.
> >
> >SIZE of 1):
> >
> >  OFFSET  SIZE     TYPE DESCRIPTION
> >...
> >      10     1  boolean StackFrameInfo.retainClassRef
> >
> >Thanks,
> >-Brent
> >
> >On 11/6/17 11:45 PM, Remi Forax wrote:
> >> Hi Brent,
> >> if you declare retainClassRef as a byte, you can even compress the
> >data structure a little bit more, no ?
> >> a boolean (as a field) uses 4 bytes while a byte uses welll 1 byte.
> >> Given that bci is a short, the VM will put both bci and
> >retainClassRef on the same 32 bits slot.
> >>
> >> cheers,
> >> R?mi
> >>
> >> ----- Mail original -----
> >>> De: "Brent Christian" <brent.christian at oracle.com>
> >>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev"
> ><hotspot-dev at openjdk.java.net>
> >>> Envoy?: Mardi 7 Novembre 2017 01:23:16
> >>> Objet: RFR: 8185925 & 8153682 (footprint reduction of
> >java.lang.StackFrameInfo)
> >>
> >>> Hi,
> >>>
> >>> There are a couple opportunities to reduce the memory footprint of
> >>> java.lang.StackFrameInfo (the internal implementation of
> >>> java.lang.StackWalker.StackFrame):
> >>>
> >>> 8153682[1] : StackFrameInfo.declaringClass could be removed
> >>> 8185925[2] : StackFrameInfo::walker field can be replaced with
> >bitmap to
> >>> save footprint
> >>>
> >>> I had a look using jol[3].  Removing only 'walker' helps only under
> >32-
> >>> and 64-bit, but not with compressed oops.  Removing both 'walker'
> >and
> >>> 'declaringClass' brings a benefit to compressed oops as well (though
> >not
> >>> for 16-byte aligned).
> >>>
> >>> The size change, in bytes, for each execution mode is as follows:
> >>>
> >>>                               32-bit: 32->24
> >>>                               64-bit: 56->40
> >>>                   64/compressed oops: 32->24
> >>> 64/compressed oops, 16-byte aligned: 32->32
> >>>
> >>> (For reference, the jol reports for the baseline and specimen are at
> >[4]
> >>> and [5], respectively.)
> >>>
> >>> Please review my code change for this.  The webrev is here:
> >>> http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/
> >>>
> >>> An automated test run is in progress.
> >>>
> >>> Thanks!
> >>> -Brent
> >>>
> >>> --
> >>> 1. https://bugs.openjdk.java.net/browse/JDK-8153682
> >>> 2. https://bugs.openjdk.java.net/browse/JDK-8185925
> >>> 3. http://openjdk.java.net/projects/code-tools/jol/
> >>> 4.
> >>>
> >
> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt
> >>> 5.
> >>>
> >
> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
-- 
Sent from my phone

From Roger.Riggs at Oracle.com  Tue Nov  7 20:04:33 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 7 Nov 2017 15:04:33 -0500
Subject: RFR (JDK10/JAXP) 8181151: Fix lint warnings in JAXP repo: cast
In-Reply-To: <70BBA69B-4226-498E-ACA2-17F9EDFE4710@oracle.com>
References: <5A0205A4.5050006@oracle.com>
 <70BBA69B-4226-498E-ACA2-17F9EDFE4710@oracle.com>
Message-ID: <6dbdf0a6-cfee-9420-c1a4-af30dd5069f9@Oracle.com>

+1

On 11/7/2017 2:47 PM, Lance Andersen wrote:
> Looks OK Joe
>> On Nov 7, 2017, at 2:12 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
>>
>> Hi,
>>
>> This change fixes about 300 [cast] warnings in the JAXP sources. Changes are basically removing the redundant cast, a bit more than that only in one case: in XSDUniqueOrKeyTraverser at line 92, uniqueOrKey was assigned to itself when it meant to be "idc". The change didn't affect the operation since idc is a result of the get operation with uniqueOrKey's name.
>>
>> JAXP tests passed.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181151
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181151/webrev/
>>
>> Thanks,
>> Joe
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>


From karen.kinnear at oracle.com  Tue Nov  7 20:04:57 2017
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Tue, 7 Nov 2017 15:04:57 -0500
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com>
 <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com>
Message-ID: <22E25545-9DEA-4B3F-9735-8B34D9E69B2E@oracle.com>

Paul,

Thank you for the explanations. Asking for your help in some test case construction at the end here:

>> 3. java/lang/invoke/package-info.java 128-134
>> Error handling could be clearer.
>> My understanding is that if a LinkageError or subclass is thrown, this will be rethrown
>> for all subsequent attempts. Other errors, e.g. VMError may retry resolution
I was WRONG here - this does match the JVMS. Apologies for the confusion.
>> 
>> 9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java
>> How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that
>> was not ACC_STATIC?
> 
> https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.23 <https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.23>
> 
> See the note under bootstrap_method_ref. The kind of method handle is constrained because of the arguments that are pushed on the stack before invocation. I believe it?s possible to have a constructor, but the declaring class would need to be a subtype of CallSite in the case of indy, and a subtype of the constant value type in the case of condy.
> 
> 
>> Or was not ACC_PUBLIC?
> 
> That?s dependent on the accessibility between the lookup class the the BSM declaring class.
> 
> 
>> Or was 
>> Or did I read the invoke dynamic method incorrectly?
>> 
> 
> By default, and for convenience, the InstructionHelper assumes the BSM is declared by the lookup class. I recently modified that to support the BSM being declared on another class, to test the minimal set of BSMs for condy (separate issue [1]). Note it?s always possible to use the bytecode API more directly.
> 
> So we can easily add more -ve tests for non-accessible or non-static BSMs.
Thank you - that is what we were trying to do - test BSM declared in another class, test in-accessible
BSM and test non static method.

Could you help us figure out how to
1) invoke a constructor? 
2) invoke a virtual method? How do you pass the receiver? 

thanks,
Karen

> 
> Paul.
> 
> [1] http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/>

From mandy.chung at oracle.com  Tue Nov  7 20:06:12 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 7 Nov 2017 12:06:12 -0800
Subject: Review request: JDK-8157246 MHs.arrayLength,
 arrayElementGetter/Setter, arrayConstructor need to specify invocation-time
 behavior
Message-ID: <aeb0d6af-e148-55ec-cbb6-05f3a46eb0b6@oracle.com>

http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.00/index.html

This fixes the spec of MethodHandles::arrayLength, arrayConstructor, 
arrayElementGetter/Setter to specify the behavior if the returned method 
handle is invoked with null array or invalid index; same runtime 
exception thrown by the bytecode behavior.? MethodHandle::asSpreader 
spec is also clarified to throw NPE and IAE except when it spreads with 
no argument and the returned method handle accepts a zero-length array 
or null array.

Thanks
Mandy

From huizhe.wang at oracle.com  Tue Nov  7 20:10:19 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 7 Nov 2017 12:10:19 -0800
Subject: RFR (JDK10/JAXP) 8181151: Fix lint warnings in JAXP repo: cast
In-Reply-To: <6dbdf0a6-cfee-9420-c1a4-af30dd5069f9@Oracle.com>
References: <5A0205A4.5050006@oracle.com>
 <70BBA69B-4226-498E-ACA2-17F9EDFE4710@oracle.com>
 <6dbdf0a6-cfee-9420-c1a4-af30dd5069f9@Oracle.com>
Message-ID: <1e46facc-f4cd-bfdc-6bec-f1ffbdb0aef3@oracle.com>

Thanks Lance, Roger!? After this, will do a final check, a few JDK 9 
deprecations, we'll be completely free from warnings!

-Joe

On 11/7/2017 12:04 PM, Roger Riggs wrote:
> +1
>
> On 11/7/2017 2:47 PM, Lance Andersen wrote:
>> Looks OK Joe
>>> On Nov 7, 2017, at 2:12 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> This change fixes about 300 [cast] warnings in the JAXP sources. 
>>> Changes are basically removing the redundant cast, a bit more than 
>>> that only in one case: in XSDUniqueOrKeyTraverser at line 92, 
>>> uniqueOrKey was assigned to itself when it meant to be "idc". The 
>>> change didn't affect the operation since idc is a result of the get 
>>> operation with uniqueOrKey's name.
>>>
>>> JAXP tests passed.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181151
>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181151/webrev/
>>>
>>> Thanks,
>>> Joe
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> 
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>
>>
>>
>


From brent.christian at oracle.com  Tue Nov  7 20:15:29 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 7 Nov 2017 12:15:29 -0800
Subject: RFR: 8185925 & 8153682 (footprint reduction of
 java.lang.StackFrameInfo)
In-Reply-To: <40ffc6a6-68c1-5654-e5c4-d451e7a2b9b7@oracle.com>
References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com>
 <40ffc6a6-68c1-5654-e5c4-d451e7a2b9b7@oracle.com>
Message-ID: <9dbc4181-3921-eae9-8ab1-72f781dc97fb@oracle.com>

On 11/07/2017 09:45 AM, mandy chung wrote:
>
> StackFrameInfo.java
>
>   38     // Footprint improvement: MemberName::clazz can replace
>   39     // StackFrameInfo::declaringClass.
>
> The above comment can be removed.

Whoops - thanks.

> 41 private final boolean retainClassRef;
>
> JVMS [1] has a note about Hotspot implementation of boolean array that
> is encoded as a byte array.  That explains JOL output that this boolean
> field is 8-bit in our implementation.  This field could be changed to a
> byte to hold additional flags, if any in the future.  It may be good to
> change this to a byte making the field size explicit.

Thanks for the link and explanation.  I agree with making the change now.

Updated webrev here:
http://cr.openjdk.java.net/~bchristi/8185925/webrev.04/

-Brent


From mandy.chung at oracle.com  Tue Nov  7 20:22:31 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 7 Nov 2017 12:22:31 -0800
Subject: RFR: 8185925 & 8153682 (footprint reduction of
 java.lang.StackFrameInfo)
In-Reply-To: <9dbc4181-3921-eae9-8ab1-72f781dc97fb@oracle.com>
References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com>
 <40ffc6a6-68c1-5654-e5c4-d451e7a2b9b7@oracle.com>
 <9dbc4181-3921-eae9-8ab1-72f781dc97fb@oracle.com>
Message-ID: <bc19b4bd-d4f6-9222-29d9-a0bade859b2e@oracle.com>



On 11/7/17 12:15 PM, Brent Christian wrote:
> Updated webrev here:
> http://cr.openjdk.java.net/~bchristi/8185925/webrev.04/

Nit: FLAGS should be lower-case (not a constant)

Otherwise looks good.?? No need for a new webrev.

Mandy

From forax at univ-mlv.fr  Tue Nov  7 20:45:04 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 07 Nov 2017 20:45:04 +0000
Subject: RFR: 8185925 & 8153682 (footprint reduction of
 java.lang.StackFrameInfo)
In-Reply-To: <CAHjP37GQRV0J3ER3qZnudiEcoBA04LL+YYu7o_xLg4iup2PjMw@mail.gmail.com>
References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com>
 <1246227356.615417.1510040732859.JavaMail.zimbra@u-pem.fr>
 <a9fc9664-ea13-ce3b-24bd-38e2e21c5e2c@oracle.com>
 <B23B45AF-D2C8-46AA-BBCF-3E7CBC82BE5C@univ-mlv.fr>
 <CAHjP37GQRV0J3ER3qZnudiEcoBA04LL+YYu7o_xLg4iup2PjMw@mail.gmail.com>
Message-ID: <9A992D58-6A73-4069-9297-DF242B27D734@univ-mlv.fr>



On November 7, 2017 8:48:43 PM GMT+01:00, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>On Tue, Nov 7, 2017 at 1:25 PM Remi Forax <forax at univ-mlv.fr> wrote:
>
>> My bad,
>> I've calculated that the header was 8 bytes instead of 12, so I've
>> supposed that the boolean was not stored in a byte.
>>
>> For my culture, why the header is 12 bytes, the pointer to the vtable
>is
>> on 64bits and can not be compressed like the other oops ?
>
>It?s 12 bytes (on x64) with compressed klass ptr; 8 bytes for the mark
>word
>and a 4 byte compressed klass ptr.  It?s 16 bytes without compressed
>klass
>ptr.  Or are you asking something else Remi?

My question is more given you have compressed oops  (and compressed klass) why the header is 12 bytes and not 8 bytes (a two words header).

so why the  mark word is 8 bytes and not 4 ? At worst it's a pointer and again you can use the compressed oops trick ?

>
>I think many folks would be upset if a boolean wasn?t stored as a byte
>:).

yes, right.

Remi

>
>>
>>
>> R?mi
>>
>>
>> On November 7, 2017 5:42:33 PM GMT+01:00, Brent Christian <
>> brent.christian at oracle.com> wrote:
>> >Hi, Remi
>> >
>> >Thanks for the idea.  From my reading of the jol ouput:
>> >
>> >
>>
>http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt
>> >
>> >
>> >
>> >I believe retainClassRef is already being stored in a single byte
>(i.e.
>> >
>> >SIZE of 1):
>> >
>> >  OFFSET  SIZE     TYPE DESCRIPTION
>> >...
>> >      10     1  boolean StackFrameInfo.retainClassRef
>> >
>> >Thanks,
>> >-Brent
>> >
>> >On 11/6/17 11:45 PM, Remi Forax wrote:
>> >> Hi Brent,
>> >> if you declare retainClassRef as a byte, you can even compress the
>> >data structure a little bit more, no ?
>> >> a boolean (as a field) uses 4 bytes while a byte uses welll 1
>byte.
>> >> Given that bci is a short, the VM will put both bci and
>> >retainClassRef on the same 32 bits slot.
>> >>
>> >> cheers,
>> >> R?mi
>> >>
>> >> ----- Mail original -----
>> >>> De: "Brent Christian" <brent.christian at oracle.com>
>> >>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>,
>"hotspot-dev"
>> ><hotspot-dev at openjdk.java.net>
>> >>> Envoy?: Mardi 7 Novembre 2017 01:23:16
>> >>> Objet: RFR: 8185925 & 8153682 (footprint reduction of
>> >java.lang.StackFrameInfo)
>> >>
>> >>> Hi,
>> >>>
>> >>> There are a couple opportunities to reduce the memory footprint
>of
>> >>> java.lang.StackFrameInfo (the internal implementation of
>> >>> java.lang.StackWalker.StackFrame):
>> >>>
>> >>> 8153682[1] : StackFrameInfo.declaringClass could be removed
>> >>> 8185925[2] : StackFrameInfo::walker field can be replaced with
>> >bitmap to
>> >>> save footprint
>> >>>
>> >>> I had a look using jol[3].  Removing only 'walker' helps only
>under
>> >32-
>> >>> and 64-bit, but not with compressed oops.  Removing both 'walker'
>> >and
>> >>> 'declaringClass' brings a benefit to compressed oops as well
>(though
>> >not
>> >>> for 16-byte aligned).
>> >>>
>> >>> The size change, in bytes, for each execution mode is as follows:
>> >>>
>> >>>                               32-bit: 32->24
>> >>>                               64-bit: 56->40
>> >>>                   64/compressed oops: 32->24
>> >>> 64/compressed oops, 16-byte aligned: 32->32
>> >>>
>> >>> (For reference, the jol reports for the baseline and specimen are
>at
>> >[4]
>> >>> and [5], respectively.)
>> >>>
>> >>> Please review my code change for this.  The webrev is here:
>> >>> http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/
>> >>>
>> >>> An automated test run is in progress.
>> >>>
>> >>> Thanks!
>> >>> -Brent
>> >>>
>> >>> --
>> >>> 1. https://bugs.openjdk.java.net/browse/JDK-8153682
>> >>> 2. https://bugs.openjdk.java.net/browse/JDK-8185925
>> >>> 3. http://openjdk.java.net/projects/code-tools/jol/
>> >>> 4.
>> >>>
>> >
>>
>http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt
>> >>> 5.
>> >>>
>> >
>>
>http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From paul.sandoz at oracle.com  Tue Nov  7 20:54:06 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 7 Nov 2017 12:54:06 -0800
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>
Message-ID: <CCF772BE-6AB0-435E-8974-6AE9D8E5EE1F@oracle.com>

Hi Remi,

You are asking a lot of the same questions we went through a number of times before landing where we are :-)


> On 7 Nov 2017, at 11:33, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi Paul,
> 
> You have an import static requireNonNull but it is only used once in nullConstant, all other methods use Objects.requireNonNull.
> 

Fixed.


> The test that checks that lookup, name and type are null or not is different in each method,
> so by example in primitiveClass, if type equals null, you get an IAE. 
> 

Fixed.


> I fail to see the point of using validateClassAccess(), if the BSM is used through an indy, the type is created only if the caller class can create it, so the test seems redundant. If it's not used by an indy, why do we need to test that ?

We are being deliberately conservative ensuring the lookup is consistent with the type in case nefarious byte code spinners punch a hole (not proven a hole can be punched, just being conservative).


> Also, why it's not called in invoke ?
> 

What ?it? are you referring to?


> There is also no reason to validate that the parameter type is the right one because the VM will validate the return type of the BSM is asTypable to the type sent as argument.
> 

Yes, but we prefer that the BSM reject thereby better signalling the source of the error.


> Some methods use generics, so other don't. Given it's not useful to use generics if the methods is used as a BSM, i think the generics signature should be removed, otherwise, getstatic and invoke should use generics.
> 

I updated the nullConstant method and removed the type variable.

In general we try to be consistent with the explicit erasure unless it causes some contortion in the implementation as is the case for Enum.


> In nullConstant, you do not need a requireNonNull here, getting you call isPrimitive() just after.
> 

We decided to be explicit rather than implicit for all null checks.


> In primitiveClass, the second test is equivalent to name.length() != 1, to remove the @SuppressWarnings, type should be declared as a Class<Class<?>>. Why not using getstatic to retrieve the field Type of the wrapper instead ?
> 

Try passing Class.class to it. To be honest this is somewhat motivated by testing when called explicitly.


> If you have invoke(), you do not need enumConstant because you can cook a constant method handle Enum.valueOf and send it to invoke.

It?s also possible to support via getStatic as well, as is the case for primitive class. 

We went back and forth on the generic and specific axis. For cases where we considered constants are ?honorary" members of the constant pool we provide explicit BSMs.


> The methods that returns VarHandles are trickier because you need a Lookup object. 
> 
> getstatic should be renamed to getConstant because this is what it does.

No, we want to stick closely with the notion of what the BSM does, there is a close connection also with MethodHandle getStatic, it?s performing a static field access. ?getConstant? is too vague, notionally all the BSMs return constants.


> wrapping the Throwable in a LinkageError seems wrong to me given that a calls to a BSM already does that, so getstatic can just declare "throws Throawble" like invoke and you have the same semantics.
> 

We don?t want to declare Throwable for the API in this case. This try/catch is just ceremony since a getstatic MH in the implementation can only throw a VM error e.g. related to out of memory or stack overflow. I can add some comments in the code.

Note that reflective exceptions are mapped to their equivalent errors. Although the BSM has been linked it is being asked to perform what can be considered further linkage.


> in arrayVarHandle, the doc said that lookup is not used but lookup is used.
> 

Fixed.


> in validateClassAccess, the return can be moved at the end of the method.
> 
> and as a minor issue, all the ifs should be followed by curly braces per the coding convention.
> 

I expanded to curly braces.

Paul.

From john.r.rose at oracle.com  Tue Nov  7 20:59:41 2017
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 7 Nov 2017 12:59:41 -0800
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>
Message-ID: <E44F19C5-D530-41C2-AB21-F0CCABE9DD1B@oracle.com>

Good comments!  I can handle a couple of them?

On Nov 7, 2017, at 11:33 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> I fail to see the point of using validateClassAccess(), if the BSM is used through an indy, the type is created only if the caller class can create it, so the test seems redundant.

That's true, but? 

> If it's not used by an indy, why do we need to test that ? Also, why it's not called in invoke ?

?Enum.valueOf doesn't do a security check; that is its choice.
This means that if you pass it an enum type that is not public
or not in a package exported to you, you can still peek at its
enum values.  Meanwhile, when javac emits a reference to
an enum, it does so with getstatic.  The getstatic bytecode
*does* perform access checks.  The call to validateClassAccess
performs those checks, for alignment with the semantics
of getstatic.  The internal use of Enum.valueOf is just a detail
of the emulation of getstatic in the case of an enum.

(Note to self:  Never use enums to implement a shared
secrets pattern.)

For bootstrap methods I prefer to use the most restrictive
set of applicable access rules, handshaking with the lookup.

In the case of enums it doesn't matter much, as you say,
because Enum.valueOf leaves the door open.

I could go either way on this one.

> There is also no reason to validate that the parameter type is the right one because the VM will validate the return type of the BSM is asTypable to the type sent as argument.

For condy, having the BSM validate types is a code smell
for the reason you mention.  Also, when primitives (and value
types) are in the mix, people usually code the validation
incorrectly, since Class.isInstance is the wrong tool, and
the right tool is non-obvious (MHs.identity.asType).

Are you commenting on the return type adjustment in invoke?
That's just a minor optimization to avoid (un)boxing, which
should have no semantic effect.

> Some methods use generics, so other don't. Given it's not useful to use generics if the methods is used as a BSM, i think the generics signature should be removed, otherwise, getstatic and invoke should use generics.

The generics are present to make normal calls from source
code type check.  Use cases:  Combinators, test code.

> to remove the @SuppressWarnings, type should be declared as a Class<Class<?>>.

Paul explained this one to me when I made the same objection.  Turns
out that the class literal "Class.class" (which is required to call that
BSM from source code) can only have a raw type.  Yuck.  So we
declare the formal with a matching amount of raw-ness.

> Why not using getstatic to retrieve the field Type of the wrapper instead ?

Because the descriptor is a more compact notation for a primitive type.
Primitive type references will be common and we want them to be small.

> If you have invoke(), you do not need enumConstant because you can cook a constant method handle Enum.valueOf and send it to invoke. The methods that returns VarHandles are trickier because you need a Lookup object. 

The set is minimal, but not that minimal.  We *could* express *everything*
using invoke but that would be grotesquely verbose and opaque.
The "extra" API points are thought to be helpful in reducing class file size,
and also clarifying the intentions of the affected constants.

> getstatic should be renamed to getConstant because this is what it does.

(I could go either way; since the JVM has ConstantValue attrs, "Constant"
is a Thing.  If it's getstatic I prefer getStatic, for alignment with pre-existing
names in jli.)

> wrapping the Throwable in a LinkageError seems wrong to me given that a calls to a BSM already does that, so getstatic can just declare "throws Throawble" like invoke and you have the same semantics.

The point is that we are emulating the semantics of a getstatic instruction,
which only throws LEs.  We don't want other stuff to leak out of the
implementation.  Remember that "bytecode behavior" is a normative
specification, to use when applicable.  It's applicable here.

Again, I could go either way on this one.

Thanks,
? John

From vitalyd at gmail.com  Tue Nov  7 21:17:36 2017
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 07 Nov 2017 21:17:36 +0000
Subject: RFR: 8185925 & 8153682 (footprint reduction of
 java.lang.StackFrameInfo)
In-Reply-To: <9A992D58-6A73-4069-9297-DF242B27D734@univ-mlv.fr>
References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com>
 <1246227356.615417.1510040732859.JavaMail.zimbra@u-pem.fr>
 <a9fc9664-ea13-ce3b-24bd-38e2e21c5e2c@oracle.com>
 <B23B45AF-D2C8-46AA-BBCF-3E7CBC82BE5C@univ-mlv.fr>
 <CAHjP37GQRV0J3ER3qZnudiEcoBA04LL+YYu7o_xLg4iup2PjMw@mail.gmail.com>
 <9A992D58-6A73-4069-9297-DF242B27D734@univ-mlv.fr>
Message-ID: <CAHjP37G6t2Xt0w-xZKxvAEWyDtpQH=Qca0sv4yYV63dHrN3p4w@mail.gmail.com>

On Tue, Nov 7, 2017 at 3:45 PM Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> On November 7, 2017 8:48:43 PM GMT+01:00, Vitaly Davidovich <
> vitalyd at gmail.com> wrote:
> >On Tue, Nov 7, 2017 at 1:25 PM Remi Forax <forax at univ-mlv.fr> wrote:
> >
> >> My bad,
> >> I've calculated that the header was 8 bytes instead of 12, so I've
> >> supposed that the boolean was not stored in a byte.
> >>
> >> For my culture, why the header is 12 bytes, the pointer to the vtable
> >is
> >> on 64bits and can not be compressed like the other oops ?
> >
> >It?s 12 bytes (on x64) with compressed klass ptr; 8 bytes for the mark
> >word
> >and a 4 byte compressed klass ptr.  It?s 16 bytes without compressed
> >klass
> >ptr.  Or are you asking something else Remi?
>
> My question is more given you have compressed oops  (and compressed klass)
> why the header is 12 bytes and not 8 bytes (a two words header).
>
> so why the  mark word is 8 bytes and not 4 ? At worst it's a pointer and
> again you can use the compressed oops trick ?

http://hg.openjdk.java.net/jdk9/hs/hotspot/file/c68024d52834/src/share/vm/oops/markOop.hpp
has
a description of the layout - it?s not a pointer per se (although some
states do encode one) but a bunch of metadata.

>
>
> >
> >I think many folks would be upset if a boolean wasn?t stored as a byte
> >:).
>
> yes, right.
>
> Remi
>
> >
> >>
> >>
> >> R?mi
> >>
> >>
> >> On November 7, 2017 5:42:33 PM GMT+01:00, Brent Christian <
> >> brent.christian at oracle.com> wrote:
> >> >Hi, Remi
> >> >
> >> >Thanks for the idea.  From my reading of the jol ouput:
> >> >
> >> >
> >>
> >
> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt
> >> >
> >> >
> >> >
> >> >I believe retainClassRef is already being stored in a single byte
> >(i.e.
> >> >
> >> >SIZE of 1):
> >> >
> >> >  OFFSET  SIZE     TYPE DESCRIPTION
> >> >...
> >> >      10     1  boolean StackFrameInfo.retainClassRef
> >> >
> >> >Thanks,
> >> >-Brent
> >> >
> >> >On 11/6/17 11:45 PM, Remi Forax wrote:
> >> >> Hi Brent,
> >> >> if you declare retainClassRef as a byte, you can even compress the
> >> >data structure a little bit more, no ?
> >> >> a boolean (as a field) uses 4 bytes while a byte uses welll 1
> >byte.
> >> >> Given that bci is a short, the VM will put both bci and
> >> >retainClassRef on the same 32 bits slot.
> >> >>
> >> >> cheers,
> >> >> R?mi
> >> >>
> >> >> ----- Mail original -----
> >> >>> De: "Brent Christian" <brent.christian at oracle.com>
> >> >>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>,
> >"hotspot-dev"
> >> ><hotspot-dev at openjdk.java.net>
> >> >>> Envoy?: Mardi 7 Novembre 2017 01:23:16
> >> >>> Objet: RFR: 8185925 & 8153682 (footprint reduction of
> >> >java.lang.StackFrameInfo)
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>> There are a couple opportunities to reduce the memory footprint
> >of
> >> >>> java.lang.StackFrameInfo (the internal implementation of
> >> >>> java.lang.StackWalker.StackFrame):
> >> >>>
> >> >>> 8153682[1] : StackFrameInfo.declaringClass could be removed
> >> >>> 8185925[2] : StackFrameInfo::walker field can be replaced with
> >> >bitmap to
> >> >>> save footprint
> >> >>>
> >> >>> I had a look using jol[3].  Removing only 'walker' helps only
> >under
> >> >32-
> >> >>> and 64-bit, but not with compressed oops.  Removing both 'walker'
> >> >and
> >> >>> 'declaringClass' brings a benefit to compressed oops as well
> >(though
> >> >not
> >> >>> for 16-byte aligned).
> >> >>>
> >> >>> The size change, in bytes, for each execution mode is as follows:
> >> >>>
> >> >>>                               32-bit: 32->24
> >> >>>                               64-bit: 56->40
> >> >>>                   64/compressed oops: 32->24
> >> >>> 64/compressed oops, 16-byte aligned: 32->32
> >> >>>
> >> >>> (For reference, the jol reports for the baseline and specimen are
> >at
> >> >[4]
> >> >>> and [5], respectively.)
> >> >>>
> >> >>> Please review my code change for this.  The webrev is here:
> >> >>> http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/
> >> >>>
> >> >>> An automated test run is in progress.
> >> >>>
> >> >>> Thanks!
> >> >>> -Brent
> >> >>>
> >> >>> --
> >> >>> 1. https://bugs.openjdk.java.net/browse/JDK-8153682
> >> >>> 2. https://bugs.openjdk.java.net/browse/JDK-8185925
> >> >>> 3. http://openjdk.java.net/projects/code-tools/jol/
> >> >>> 4.
> >> >>>
> >> >
> >>
> >
> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt
> >> >>> 5.
> >> >>>
> >> >
> >>
> >
> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt
> >>
> >> --
> >> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> >>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
-- 
Sent from my phone

From forax at univ-mlv.fr  Tue Nov  7 21:35:06 2017
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 7 Nov 2017 22:35:06 +0100 (CET)
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <E44F19C5-D530-41C2-AB21-F0CCABE9DD1B@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>
 <E44F19C5-D530-41C2-AB21-F0CCABE9DD1B@oracle.com>
Message-ID: <876381003.1124033.1510090506277.JavaMail.zimbra@u-pem.fr>



----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> ?: "R?mi Forax" <forax at univ-mlv.fr>
> Cc: "Paul Sandoz" <paul.sandoz at oracle.com>, "hotspot-dev" <hotspot-dev at openjdk.java.net>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 7 Novembre 2017 21:59:41
> Objet: Re: RFR 8187742 Minimal set of bootstrap methods for dynamic constants

> Good comments!  I can handle a couple of them?
> 
> On Nov 7, 2017, at 11:33 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> I fail to see the point of using validateClassAccess(), if the BSM is used
>> through an indy, the type is created only if the caller class can create it, so
>> the test seems redundant.
> 
> That's true, but?
> 
>> If it's not used by an indy, why do we need to test that ? Also, why it's not
>> called in invoke ?
> 
> ?Enum.valueOf doesn't do a security check; that is its choice.
> This means that if you pass it an enum type that is not public
> or not in a package exported to you, you can still peek at its
> enum values.  Meanwhile, when javac emits a reference to
> an enum, it does so with getstatic.  The getstatic bytecode
> *does* perform access checks.  The call to validateClassAccess
> performs those checks, for alignment with the semantics
> of getstatic.  The internal use of Enum.valueOf is just a detail
> of the emulation of getstatic in the case of an enum.
> 
> (Note to self:  Never use enums to implement a shared
> secrets pattern.)
> 
> For bootstrap methods I prefer to use the most restrictive
> set of applicable access rules, handshaking with the lookup.
> 
> In the case of enums it doesn't matter much, as you say,
> because Enum.valueOf leaves the door open.
> 
> I could go either way on this one.

As you said, javac use getstatic (the bytecode), why not reuse getstatic (the BSM) in that case, being a field of an enum doesn't seem important and at least you are sure that you have the semantics of getstatic (you miss the cache in java.lang.Class but i'm not sure it worth it).

> 
>> There is also no reason to validate that the parameter type is the right one
>> because the VM will validate the return type of the BSM is asTypable to the
>> type sent as argument.
> 
> For condy, having the BSM validate types is a code smell
> for the reason you mention.  Also, when primitives (and value
> types) are in the mix, people usually code the validation
> incorrectly, since Class.isInstance is the wrong tool, and
> the right tool is non-obvious (MHs.identity.asType).
> 
> Are you commenting on the return type adjustment in invoke?
> That's just a minor optimization to avoid (un)boxing, which
> should have no semantic effect.

no, the return type adjustment is ok for me, it avoid unboxing + boxing if the original handle returns a primitive.

> 
>> Some methods use generics, so other don't. Given it's not useful to use generics
>> if the methods is used as a BSM, i think the generics signature should be
>> removed, otherwise, getstatic and invoke should use generics.
> 
> The generics are present to make normal calls from source
> code type check.  Use cases:  Combinators, test code.

so getstatic and invoke should have generics in their signature too.

> 
>> to remove the @SuppressWarnings, type should be declared as a Class<Class<?>>.
> 
> Paul explained this one to me when I made the same objection.  Turns
> out that the class literal "Class.class" (which is required to call that
> BSM from source code) can only have a raw type.  Yuck.  So we
> declare the formal with a matching amount of raw-ness.

yes, right X.class and x.getClass() are the two rules in the JLS that can introduce raw types.
I think i prefer 'type' to be typed as a Class<?> in that case, it's not a raw type and you can assign Class<Class>> to it. 

> 
>> Why not using getstatic to retrieve the field Type of the wrapper instead ?
> 
> Because the descriptor is a more compact notation for a primitive type.
> Primitive type references will be common and we want them to be small.

Ok, you have to send the wrapper type if you use getstatic, so you are saving a reference to the wrapper type.

> 
>> If you have invoke(), you do not need enumConstant because you can cook a
>> constant method handle Enum.valueOf and send it to invoke. The methods that
>> returns VarHandles are trickier because you need a Lookup object.
> 
> The set is minimal, but not that minimal.  We *could* express *everything*
> using invoke but that would be grotesquely verbose and opaque.
> The "extra" API points are thought to be helpful in reducing class file size,
> and also clarifying the intentions of the affected constants.
> 
>> getstatic should be renamed to getConstant because this is what it does.
> 
> (I could go either way; since the JVM has ConstantValue attrs, "Constant"
> is a Thing.  If it's getstatic I prefer getStatic, for alignment with
> pre-existing
> names in jli.)

perhaps getFinalStatic, because it's restricted to final field.

> 
>> wrapping the Throwable in a LinkageError seems wrong to me given that a calls to
>> a BSM already does that, so getstatic can just declare "throws Throawble" like
>> invoke and you have the same semantics.
> 
> The point is that we are emulating the semantics of a getstatic instruction,
> which only throws LEs.  We don't want other stuff to leak out of the
> implementation.  Remember that "bytecode behavior" is a normative
> specification, to use when applicable.  It's applicable here.

it's not the catch line 155 that bother me, it's the other line 165 (and 162).

> 
> Again, I could go either way on this one.
> 
> Thanks,
> ? John

R?mi

From paul.sandoz at oracle.com  Tue Nov  7 21:54:51 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 7 Nov 2017 13:54:51 -0800
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <E44F19C5-D530-41C2-AB21-F0CCABE9DD1B@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>
 <E44F19C5-D530-41C2-AB21-F0CCABE9DD1B@oracle.com>
Message-ID: <64439AE0-931E-4FC6-ABCF-C17D6AC94DC9@oracle.com>


> On 7 Nov 2017, at 12:59, John Rose <john.r.rose at oracle.com> wrote:
> 
> Good comments!  I can handle a couple of them?
> 
> On Nov 7, 2017, at 11:33 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> I fail to see the point of using validateClassAccess(), if the BSM is used through an indy, the type is created only if the caller class can create it, so the test seems redundant.
> 
> That's true, but? 
> 
>> If it's not used by an indy, why do we need to test that ? Also, why it's not called in invoke ?
> 
> ?Enum.valueOf doesn't do a security check; that is its choice.
> This means that if you pass it an enum type that is not public
> or not in a package exported to you, you can still peek at its
> enum values.  Meanwhile, when javac emits a reference to
> an enum, it does so with getstatic.  The getstatic bytecode
> *does* perform access checks.  The call to validateClassAccess
> performs those checks, for alignment with the semantics
> of getstatic.  The internal use of Enum.valueOf is just a detail
> of the emulation of getstatic in the case of an enum.
> 
> (Note to self:  Never use enums to implement a shared
> secrets pattern.)
> 
> For bootstrap methods I prefer to use the most restrictive
> set of applicable access rules, handshaking with the lookup.
> 
> In the case of enums it doesn't matter much, as you say,
> because Enum.valueOf leaves the door open.
> 

Yes, Brian and I noticed that so we punted on the access control.


> I could go either way on this one.
> 

For consistency with our conservative position on other BSMs we should probably perform the checks. I?ll update.


>> There is also no reason to validate that the parameter type is the right one because the VM will validate the return type of the BSM is asTypable to the type sent as argument.
> 
> For condy, having the BSM validate types is a code smell
> for the reason you mention.

If the BSM should only accept specific types it seems within its remit to reject thereby better associating the error with the dynamic constant entry. We are dealing here with known fixed types (Class and VarHandle).

 
>  Also, when primitives (and value
> types) are in the mix, people usually code the validation
> incorrectly, since Class.isInstance is the wrong tool, and
> the right tool is non-obvious (MHs.identity.asType).
> 
> Are you commenting on the return type adjustment in invoke?
> That's just a minor optimization to avoid (un)boxing, which
> should have no semantic effect.
> 
>> Some methods use generics, so other don't. Given it's not useful to use generics if the methods is used as a BSM, i think the generics signature should be removed, otherwise, getstatic and invoke should use generics.
> 
> The generics are present to make normal calls from source
> code type check.  Use cases:  Combinators, test code.
> 
>> to remove the @SuppressWarnings, type should be declared as a Class<Class<?>>.
> 
> Paul explained this one to me when I made the same objection.  Turns
> out that the class literal "Class.class" (which is required to call that
> BSM from source code) can only have a raw type.  Yuck.  So we
> declare the formal with a matching amount of raw-ness.
> 
>> Why not using getstatic to retrieve the field Type of the wrapper instead ?
> 
> Because the descriptor is a more compact notation for a primitive type.
> Primitive type references will be common and we want them to be small.
> 

Yes, i forgot to mention the size aspect.


>> If you have invoke(), you do not need enumConstant because you can cook a constant method handle Enum.valueOf and send it to invoke. The methods that returns VarHandles are trickier because you need a Lookup object. 
> 
> The set is minimal, but not that minimal.  We *could* express *everything*
> using invoke but that would be grotesquely verbose and opaque.
> The "extra" API points are thought to be helpful in reducing class file size,
> and also clarifying the intentions of the affected constants.
> 

Yes.


>> getstatic should be renamed to getConstant because this is what it does.
> 
> (I could go either way; since the JVM has ConstantValue attrs, "Constant"
> is a Thing.  If it's getstatic I prefer getStatic, for alignment with pre-existing
> names in jli.)
> 

+1 on getStatic alignment with jli.

getConstant is too general for this case IMO.

The naming convention we chose was to append Constant if the prefix was a keyword such as null or enum.

Paul.


>> wrapping the Throwable in a LinkageError seems wrong to me given that a calls to a BSM already does that, so getstatic can just declare "throws Throawble" like invoke and you have the same semantics.
> 
> The point is that we are emulating the semantics of a getstatic instruction,
> which only throws LEs.  We don't want other stuff to leak out of the
> implementation.  Remember that "bytecode behavior" is a normative
> specification, to use when applicable.  It's applicable here.
> 
> Again, I could go either way on this one.
> 
> Thanks,
> ? John


From paul.sandoz at oracle.com  Tue Nov  7 22:00:23 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 7 Nov 2017 14:00:23 -0800
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <64439AE0-931E-4FC6-ABCF-C17D6AC94DC9@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>
 <E44F19C5-D530-41C2-AB21-F0CCABE9DD1B@oracle.com>
 <64439AE0-931E-4FC6-ABCF-C17D6AC94DC9@oracle.com>
Message-ID: <A85FBB38-3C5E-43D1-B8CA-D43A85CD2096@oracle.com>


> On 7 Nov 2017, at 13:54, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>>> If it's not used by an indy, why do we need to test that ? Also, why it's not called in invoke ?
>> 
>> ?Enum.valueOf doesn't do a security check; that is its choice.
>> This means that if you pass it an enum type that is not public
>> or not in a package exported to you, you can still peek at its
>> enum values.  Meanwhile, when javac emits a reference to
>> an enum, it does so with getstatic.  The getstatic bytecode
>> *does* perform access checks.  The call to validateClassAccess
>> performs those checks, for alignment with the semantics
>> of getstatic.  The internal use of Enum.valueOf is just a detail
>> of the emulation of getstatic in the case of an enum.
>> 
>> (Note to self:  Never use enums to implement a shared
>> secrets pattern.)
>> 
>> For bootstrap methods I prefer to use the most restrictive
>> set of applicable access rules, handshaking with the lookup.
>> 
>> In the case of enums it doesn't matter much, as you say,
>> because Enum.valueOf leaves the door open.
>> 
> 
> Yes, Brian and I noticed that so we punted on the access control.
> 

Hold on? no we didn?t, we included the explicit access control check.

Paul.

From forax at univ-mlv.fr  Tue Nov  7 22:18:15 2017
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 7 Nov 2017 23:18:15 +0100 (CET)
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <CCF772BE-6AB0-435E-8974-6AE9D8E5EE1F@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>
 <CCF772BE-6AB0-435E-8974-6AE9D8E5EE1F@oracle.com>
Message-ID: <1693333239.1128109.1510093095542.JavaMail.zimbra@u-pem.fr>



----- Mail original -----
> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev" <hotspot-dev at openjdk.java.net>
> Envoy?: Mardi 7 Novembre 2017 21:54:06
> Objet: Re: RFR 8187742 Minimal set of bootstrap methods for dynamic constants

> Hi Remi,
> 
> You are asking a lot of the same questions we went through a number of times
> before landing where we are :-)
> 
> 
>> On 7 Nov 2017, at 11:33, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Hi Paul,
>> 
>> You have an import static requireNonNull but it is only used once in
>> nullConstant, all other methods use Objects.requireNonNull.
>> 
> 
> Fixed.
> 
> 
>> The test that checks that lookup, name and type are null or not is different in
>> each method,
>> so by example in primitiveClass, if type equals null, you get an IAE.
>> 
> 
> Fixed.
> 
> 
>> I fail to see the point of using validateClassAccess(), if the BSM is used
>> through an indy, the type is created only if the caller class can create it, so
>> the test seems redundant. If it's not used by an indy, why do we need to test
>> that ?
> 
> We are being deliberately conservative ensuring the lookup is consistent with
> the type in case nefarious byte code spinners punch a hole (not proven a hole
> can be punched, just being conservative).
> 
> 
>> Also, why it's not called in invoke ?
>> 
> 
> What ?it? are you referring to?

validateClassAccess.

> 
> 
>> There is also no reason to validate that the parameter type is the right one
>> because the VM will validate the return type of the BSM is asTypable to the
>> type sent as argument.
>> 
> 
> Yes, but we prefer that the BSM reject thereby better signalling the source of
> the error.

the method returns a Class in its signature, so it can not be something else if not call by a condy and if the type is wrong in the bytecode, the VM will throw a CCE with the same info than your IAE.
i still think it's unnecessary. 

> 
> 
>> Some methods use generics, so other don't. Given it's not useful to use generics
>> if the methods is used as a BSM, i think the generics signature should be
>> removed, otherwise, getstatic and invoke should use generics.
>> 
> 
> I updated the nullConstant method and removed the type variable.
> 
> In general we try to be consistent with the explicit erasure unless it causes
> some contortion in the implementation as is the case for Enum.
> 
> 
>> In nullConstant, you do not need a requireNonNull here, getting you call
>> isPrimitive() just after.
>> 
> 
> We decided to be explicit rather than implicit for all null checks.
> 
> 
>> In primitiveClass, the second test is equivalent to name.length() != 1, to
>> remove the @SuppressWarnings, type should be declared as a Class<Class<?>>. Why
>> not using getstatic to retrieve the field Type of the wrapper instead ?
>> 
> 
> Try passing Class.class to it. To be honest this is somewhat motivated by
> testing when called explicitly.

see my answer to John.

> 
> 
>> If you have invoke(), you do not need enumConstant because you can cook a
>> constant method handle Enum.valueOf and send it to invoke.
> 
> It?s also possible to support via getStatic as well, as is the case for
> primitive class.
> 
> We went back and forth on the generic and specific axis. For cases where we
> considered constants are ?honorary" members of the constant pool we provide
> explicit BSMs.
> 
> 
>> The methods that returns VarHandles are trickier because you need a Lookup
>> object.
>> 
>> getstatic should be renamed to getConstant because this is what it does.
> 
> No, we want to stick closely with the notion of what the BSM does, there is a
> close connection also with MethodHandle getStatic, it?s performing a static
> field access. ?getConstant? is too vague, notionally all the BSMs return
> constants.
> 
> 
>> wrapping the Throwable in a LinkageError seems wrong to me given that a calls to
>> a BSM already does that, so getstatic can just declare "throws Throawble" like
>> invoke and you have the same semantics.
>> 
> 
> We don?t want to declare Throwable for the API in this case. This try/catch is
> just ceremony since a getstatic MH in the implementation can only throw a VM
> error e.g. related to out of memory or stack overflow. I can add some comments
> in the code.

but you do that in invoke().

> 
> Note that reflective exceptions are mapped to their equivalent errors. Although
> the BSM has been linked it is being asked to perform what can be considered
> further linkage.
> 
> 
>> in arrayVarHandle, the doc said that lookup is not used but lookup is used.
>> 
> 
> Fixed.
> 
> 
>> in validateClassAccess, the return can be moved at the end of the method.
>> 
>> and as a minor issue, all the ifs should be followed by curly braces per the
>> coding convention.
>> 
> 
> I expanded to curly braces.
> 
> Paul.

R?mi

From john.r.rose at oracle.com  Tue Nov  7 22:20:01 2017
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 7 Nov 2017 14:20:01 -0800
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <1693333239.1128109.1510093095542.JavaMail.zimbra@u-pem.fr>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>
 <CCF772BE-6AB0-435E-8974-6AE9D8E5EE1F@oracle.com>
 <1693333239.1128109.1510093095542.JavaMail.zimbra@u-pem.fr>
Message-ID: <4AE7F5C4-E98C-464D-903A-0A43C83B38C0@oracle.com>

On Nov 7, 2017, at 2:18 PM, forax at univ-mlv.fr wrote:
> 
>>> 
>>> Also, why it's not called in invoke ?
>>> 
>> 
>> What ?it? are you referring to?
> 
> validateClassAccess.

Because having a MH means you have already been granted
access to invoke it.  Having a Class does *not* mean you have
been granted access to its members; that is a further step.

? John

From forax at univ-mlv.fr  Tue Nov  7 22:25:40 2017
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 7 Nov 2017 23:25:40 +0100 (CET)
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <4AE7F5C4-E98C-464D-903A-0A43C83B38C0@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>
 <CCF772BE-6AB0-435E-8974-6AE9D8E5EE1F@oracle.com>
 <1693333239.1128109.1510093095542.JavaMail.zimbra@u-pem.fr>
 <4AE7F5C4-E98C-464D-903A-0A43C83B38C0@oracle.com>
Message-ID: <2125890785.1128598.1510093540787.JavaMail.zimbra@u-pem.fr>

> De: "John Rose" <john.r.rose at oracle.com>
> ?: "R?mi Forax" <forax at univ-mlv.fr>
> Cc: "Paul Sandoz" <paul.sandoz at oracle.com>, "hotspot-dev"
> <hotspot-dev at openjdk.java.net>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 7 Novembre 2017 23:20:01
> Objet: Re: RFR 8187742 Minimal set of bootstrap methods for dynamic constants

> On Nov 7, 2017, at 2:18 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
> wrote:

>>>> Also, why it's not called in invoke ?

>>> What ?it? are you referring to?

>> validateClassAccess.

> Because having a MH means you have already been granted
> access to invoke it. Having a Class does *not* mean you have
> been granted access to its members; that is a further step.

but here you are using the class to change the mh, so you can have access to the mh and still have no access to the Class if you do not call the BSM with a condy, which is the purpose of validateClassAccess, no ? 

> ? John

R?mi 

From christoph.dreis at freenet.de  Tue Nov  7 22:25:08 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Tue, 7 Nov 2017 23:25:08 +0100
Subject: [NEW BUG][JDK10] TimeUnit.timedWait(Object obj,
 long timeout) doc should emphasize possibility of
 IllegalMonitorStateException
Message-ID: <000501d35817$45294120$cf7bc360$@freenet.de>

Hi,

I don't know if this is considered a real bug or just a lack of
documentation, but I found that although the example in the documentation of
TimeUnit.timedWait(Object obj, long timeout) shows the correct usage of the
method, I think at least the documentation should emphasize the possibility
of an IllegalMonitorStateException in case it isn't executed inside a
synchronized block.

The method seems to be not used inside the JDK itself after all, but people
might use it.

Please find a minimal reproduction and a possible documentation patch below.
In case it is considered worthwhile I'd be happy if this is sponsored.

Cheers,
Christoph

===== MINIMAL REPRO ======
public class Main {

    public static void main(String[] args) {
        Lock lock = new ReentrantLock();
        try {
            TimeUnit.MILLISECONDS.timedWait(lock, 1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

}

====== PATCH ==========
diff -r 67aa34b019e1
src/java.base/share/classes/java/util/concurrent/TimeUnit.java
--- a/src/java.base/share/classes/java/util/concurrent/TimeUnit.java    Mon
Nov 06 17:48:00 2017 -0800
+++ b/src/java.base/share/classes/java/util/concurrent/TimeUnit.java    Tue
Nov 07 23:09:24 2017 +0100
@@ -356,6 +356,8 @@
      * @param timeout the maximum time to wait. If less than
      * or equal to zero, do not wait at all.
      * @throws InterruptedException if interrupted while waiting
+     * @throws IllegalMonitorStateException if not executed inside a
+     *         synchronized block
      */
     public void timedWait(Object obj, long timeout)
             throws InterruptedException {


From paul.sandoz at oracle.com  Tue Nov  7 22:37:03 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 7 Nov 2017 14:37:03 -0800
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <1693333239.1128109.1510093095542.JavaMail.zimbra@u-pem.fr>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>
 <CCF772BE-6AB0-435E-8974-6AE9D8E5EE1F@oracle.com>
 <1693333239.1128109.1510093095542.JavaMail.zimbra@u-pem.fr>
Message-ID: <C6C76FD9-67BF-486E-878F-840CE4BB2D1B@oracle.com>


> On 7 Nov 2017, at 14:18, forax at univ-mlv.fr wrote:
>> 
>> Try passing Class.class to it. To be honest this is somewhat motivated by
>> testing when called explicitly.
> 
> see my answer to John.
> 

Fair point, i?ll go with Class<?>. It?s the less smelly option.

Updated along with other changes:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/> 


>> 
>> 
>>> If you have invoke(), you do not need enumConstant because you can cook a
>>> constant method handle Enum.valueOf and send it to invoke.
>> 
>> It?s also possible to support via getStatic as well, as is the case for
>> primitive class.
>> 
>> We went back and forth on the generic and specific axis. For cases where we
>> considered constants are ?honorary" members of the constant pool we provide
>> explicit BSMs.
>> 
>> 
>>> The methods that returns VarHandles are trickier because you need a Lookup
>>> object.
>>> 
>>> getstatic should be renamed to getConstant because this is what it does.
>> 
>> No, we want to stick closely with the notion of what the BSM does, there is a
>> close connection also with MethodHandle getStatic, it?s performing a static
>> field access. ?getConstant? is too vague, notionally all the BSMs return
>> constants.
>> 
>> 
>>> wrapping the Throwable in a LinkageError seems wrong to me given that a calls to
>>> a BSM already does that, so getstatic can just declare "throws Throawble" like
>>> invoke and you have the same semantics.
>>> 
>> 
>> We don?t want to declare Throwable for the API in this case. This try/catch is
>> just ceremony since a getstatic MH in the implementation can only throw a VM
>> error e.g. related to out of memory or stack overflow. I can add some comments
>> in the code.
> 
> but you do that in invoke().
> 

There is no choice when Invoking a method handle that is passed to us.

In the case of getStatic the use of a MH can be considered an implementation detail (we could use reflection) and we know what the j.l.invoke implementation does. In this case i believe only VM errors can be produced.

Paul.

From brian.burkhalter at oracle.com  Tue Nov  7 22:38:04 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 7 Nov 2017 14:38:04 -0800
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
Message-ID: <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>

I am a little late to this thread, but some alternative verbiage to consider is included below. This wording however diverges from that of [1] so if we want them to remain similar then it?s probably not worth it to change from what has been agreed upon already.

Thanks,

Brian

[1] https://docs.oracle.com/javase/9/docs/api/java/io/InputStream.html#transferTo-java.io.OutputStream-

  57      * Reads all characters from this source and writes the characters to
  58      * the given appendable in the order that they are read. On return, the
  59      * source of characters will be at its end.

Reads all characters from this source and appends them to a destination in
the order in which they are read. On return, ...

  60      * <p>
  61      * This method may block indefinitely reading from the readable, or
  62      * writing to the appendable. Where this source or the appendable is
  63      * {@link AutoCloseable closeable}, then the behavior when either are
  64      * <i>asynchronously closed</i>, or the thread interrupted during the transfer,
  65      * is highly readable and appendable specific, and therefore not specified.

This method may block indefinitely while reading from the source or writing to the destination.
If the source or destination is {@link AutoCloseable closeable}, then the behavior when either
is <i>asynchronously closed</i>, or the thread is interrupted during the transfer, is highly
implementation-dependent and hence unspecified.

  66      * <p>
  67      * If an I/O error occurs reading from the readable or writing to the
  68      * appendable, then it may do so after some characters have been read or
  69      * written. Consequently the readable may not be at end of its data and
  70      * one, or both participants may be in an inconsistent state. That in mind
  71      * all additional measures required by one or both participants in order to
  72      * eventually free their internal resources have to be taken by the caller
  73      * of this method.

If an I/O error occurs during the operation, then not all characters might have been transferred
and the source or destination could be left in an inconsistent state. The caller of this method
should therefore ensure in such a case that measures are taken to release any resources held
by the source and destination.

On Nov 3, 2017, at 5:49 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 02/11/2017 19:55, Patrick Reinhart wrote:
>> :
>> If we are all happy with the API so far, I could start adding an initial implementation and test?
>> 
> I think the API looks fine so go ahead.


From paul.sandoz at oracle.com  Tue Nov  7 22:47:16 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 7 Nov 2017 14:47:16 -0800
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <22E25545-9DEA-4B3F-9735-8B34D9E69B2E@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com>
 <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com>
 <22E25545-9DEA-4B3F-9735-8B34D9E69B2E@oracle.com>
Message-ID: <8F7AE06B-34A0-43A7-8861-24BE952A5532@oracle.com>


> On 7 Nov 2017, at 12:04, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> Paul,
> 
> Thank you for the explanations. Asking for your help in some test case construction at the end here:
> 
>>> 3. java/lang/invoke/package-info.java 128-134
>>> Error handling could be clearer.
>>> My understanding is that if a LinkageError or subclass is thrown, this will be rethrown
>>> for all subsequent attempts. Other errors, e.g. VMError may retry resolution
> I was WRONG here - this does match the JVMS. Apologies for the confusion.
>>> 
>>> 9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java
>>> How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that
>>> was not ACC_STATIC?
>> 
>> https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.23
>> 
>> See the note under bootstrap_method_ref. The kind of method handle is constrained because of the arguments that are pushed on the stack before invocation. I believe it?s possible to have a constructor, but the declaring class would need to be a subtype of CallSite in the case of indy, and a subtype of the constant value type in the case of condy.
>> 
>> 
>>> Or was not ACC_PUBLIC?
>> 
>> That?s dependent on the accessibility between the lookup class the the BSM declaring class.
>> 
>> 
>>> Or was 
>>> Or did I read the invoke dynamic method incorrectly?
>>> 
>> 
>> By default, and for convenience, the InstructionHelper assumes the BSM is declared by the lookup class. I recently modified that to support the BSM being declared on another class, to test the minimal set of BSMs for condy (separate issue [1]). Note it?s always possible to use the bytecode API more directly.
>> 
>> So we can easily add more -ve tests for non-accessible or non-static BSMs.

I am wrong, i forgot i updated the API to remove the declaration of the BSM kind, and it only supports static BSMs.


> Thank you - that is what we were trying to do - test BSM declared in another class, test in-accessible
> BSM and test non static method.
> 

The latter (access to a BSM in another class) is easy now using the high-level construct of InstructionHelper.ldcDynamicConstant (see patch for the condy BSMs, which is also in the amber repo in the condy branch).


> Could you help us figure out how to
> 1) invoke a constructor? 
> 2) invoke a virtual method? How do you pass the receiver? 
> 

I think for these you will need to use ASM tools to massage the MH for the BSM e.g. develop for a class with a static BSM then adjust the constant pool entry for the associated MH.

Paul.

From Roger.Riggs at Oracle.com  Tue Nov  7 22:55:05 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 7 Nov 2017 17:55:05 -0500
Subject: RFR 8190884: java/lang/Runtime/exec/LotsOfOutput fails intermittently
Message-ID: <59dccba6-6ffa-afd6-0a22-654b94051cba@Oracle.com>

Please review a test update to run LotsOfOutput with 'othervm';
running under the default batch testing mode of agentvm may cause 
instability.

--- old/test/jdk/java/lang/Runtime/exec/LotsOfOutput.java 2017-11-07 
17:48:38.398907014 -0500
+++ new/test/jdk/java/lang/Runtime/exec/LotsOfOutput.java 2017-11-07 
17:48:37.846921042 -0500
@@ -23,7 +23,8 @@

 ?/**
 ? * @test
- * @bug 4369826 8078582
+ * @bug 4369826 8078582 8190884
+ * @run main/othervm LotsOfOutput
 ? * @summary Process with lots of output should not crash VM
 ? * @author kladko
 ? */

Thanks, Roger




From lance.andersen at oracle.com  Tue Nov  7 22:57:12 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 7 Nov 2017 17:57:12 -0500
Subject: RFR 8190884: java/lang/Runtime/exec/LotsOfOutput fails
 intermittently
In-Reply-To: <59dccba6-6ffa-afd6-0a22-654b94051cba@Oracle.com>
References: <59dccba6-6ffa-afd6-0a22-654b94051cba@Oracle.com>
Message-ID: <0B6E9BEE-A22D-42AF-A485-98FC38166C85@oracle.com>

+1

> On Nov 7, 2017, at 5:55 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Please review a test update to run LotsOfOutput with 'othervm';
> running under the default batch testing mode of agentvm may cause instability.
> 
> --- old/test/jdk/java/lang/Runtime/exec/LotsOfOutput.java 2017-11-07 17:48:38.398907014 -0500
> +++ new/test/jdk/java/lang/Runtime/exec/LotsOfOutput.java 2017-11-07 17:48:37.846921042 -0500
> @@ -23,7 +23,8 @@
> 
>  /**
>   * @test
> - * @bug 4369826 8078582
> + * @bug 4369826 8078582 8190884
> + * @run main/othervm LotsOfOutput
>   * @summary Process with lots of output should not crash VM
>   * @author kladko
>   */
> 
> Thanks, Roger
> 
> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From mandy.chung at oracle.com  Tue Nov  7 23:00:35 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 7 Nov 2017 15:00:35 -0800
Subject: [Patch][JDK10] Use Class.getPackageName() where possible
In-Reply-To: <000001d357d7$7269fc50$573df4f0$@freenet.de>
References: <000101d3543e$840b6080$8c222180$@freenet.de>
 <72043f40-6a9c-f79a-66be-5e68e6ce1f0c@oracle.com>
 <000c01d3547a$ad4d6470$07e82d50$@freenet.de>
 <4a0476c1-1333-9e28-5b07-066b8fa74213@oracle.com>
 <AM4PR08MB1219C410B9E57E3E39B2F9A2FF520@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ecea8e88-3890-50f8-fcf7-e8e9e3461127@oracle.com>
 <000001d357d7$7269fc50$573df4f0$@freenet.de>
Message-ID: <25780137-1178-af0d-a322-1ba29d020ac8@oracle.com>



On 11/7/17 6:48 AM, Christoph Dreis wrote:
> ======= PATCH =======
> diff -r 67aa34b019e1 src/java.base/share/classes/java/io/ObjectInputFilter.java
> --- a/src/java.base/share/classes/java/io/ObjectInputFilter.java	Mon Nov 06 17:48:00 2017 -0800
> +++ b/src/java.base/share/classes/java/io/ObjectInputFilter.java	Tue Nov 07 15:44:36 2017 +0100
> @@ -656,8 +656,8 @@
>                * otherwise {@code false}
>                */
>               private static boolean matchesPackage(Class<?> c, String pkg) {
> -                String n = c.getName();
> -                return n.startsWith(pkg) && n.lastIndexOf('.') == pkg.length() - 1;
> +                String n = c.getPackageName();
> +                return n.length() == pkg.length() - 1 && n.startsWith(pkg);
>               }
>   

This is correct but we could simplify this.? We can modify the callers 
to drop a trailing "." from the pkg parameter.? I took the liberty to 
revise it a little.

http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8190733/webrev.00/

Roger - can you take a look at the change in ObjectInputFilter?

Mandy

From patrick at reini.net  Tue Nov  7 23:01:55 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 8 Nov 2017 00:01:55 +0100
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
Message-ID: <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>

Hi Brian,

I integrated your changes into my current version which I will look into tomorrow with Alan at Devoxx. I think adding some implementation note on the default method implementation will be needed to review later on?

I also made an override on the CharBuffer, where we need to add a enhanced documentation for the specialties around the CharBuffer implementations (BufferOverflowException/ReadOnlyBufferException), where a review of some native english speakers would help :-)

-Patrick


> Am 07.11.2017 um 23:38 schrieb Brian Burkhalter <brian.burkhalter at oracle.com>:
> 
> I am a little late to this thread, but some alternative verbiage to consider is included below. This wording however diverges from that of [1] so if we want them to remain similar then it?s probably not worth it to change from what has been agreed upon already.
> 
> Thanks,
> 
> Brian
> 
> [1] https://docs.oracle.com/javase/9/docs/api/java/io/InputStream.html#transferTo-java.io.OutputStream- <https://docs.oracle.com/javase/9/docs/api/java/io/InputStream.html#transferTo-java.io.OutputStream->
> 
>   57      * Reads all characters from this source and writes the characters to
>   58      * the given appendable in the order that they are read. On return, the
>   59      * source of characters will be at its end.
> 
> Reads all characters from this source and appends them to a destination in
> the order in which they are read. On return, ...
> 
>   60      * <p>
>   61      * This method may block indefinitely reading from the readable, or
>   62      * writing to the appendable. Where this source or the appendable is
>   63      * {@link AutoCloseable closeable}, then the behavior when either are
>   64      * <i>asynchronously closed</i>, or the thread interrupted during the transfer,
>   65      * is highly readable and appendable specific, and therefore not specified.
> 
> This method may block indefinitely while reading from the source or writing to the destination.
> If the source or destination is {@link AutoCloseable closeable}, then the behavior when either
> is <i>asynchronously closed</i>, or the thread is interrupted during the transfer, is highly
> implementation-dependent and hence unspecified.
> 
>   66      * <p>
>   67      * If an I/O error occurs reading from the readable or writing to the
>   68      * appendable, then it may do so after some characters have been read or
>   69      * written. Consequently the readable may not be at end of its data and
>   70      * one, or both participants may be in an inconsistent state. That in mind
>   71      * all additional measures required by one or both participants in order to
>   72      * eventually free their internal resources have to be taken by the caller
>   73      * of this method.
> 
> If an I/O error occurs during the operation, then not all characters might have been transferred
> and the source or destination could be left in an inconsistent state. The caller of this method
> should therefore ensure in such a case that measures are taken to release any resources held
> by the source and destination.
> 
> On Nov 3, 2017, at 5:49 AM, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
> 
>> On 02/11/2017 19:55, Patrick Reinhart wrote:
>>> :
>>> If we are all happy with the API so far, I could start adding an initial implementation and test?
>>> 
>> I think the API looks fine so go ahead.
> 


From mandy.chung at oracle.com  Tue Nov  7 23:02:44 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 7 Nov 2017 15:02:44 -0800
Subject: RFR 8190884: java/lang/Runtime/exec/LotsOfOutput fails
 intermittently
In-Reply-To: <59dccba6-6ffa-afd6-0a22-654b94051cba@Oracle.com>
References: <59dccba6-6ffa-afd6-0a22-654b94051cba@Oracle.com>
Message-ID: <dcedcbca-8f7d-16fa-be62-744257305f0c@oracle.com>

+1

Mandy

On 11/7/17 2:55 PM, Roger Riggs wrote:
> Please review a test update to run LotsOfOutput with 'othervm';
> running under the default batch testing mode of agentvm may cause 
> instability.
>
> --- old/test/jdk/java/lang/Runtime/exec/LotsOfOutput.java 2017-11-07 
> 17:48:38.398907014 -0500
> +++ new/test/jdk/java/lang/Runtime/exec/LotsOfOutput.java 2017-11-07 
> 17:48:37.846921042 -0500
> @@ -23,7 +23,8 @@
>
> ?/**
> ? * @test
> - * @bug 4369826 8078582
> + * @bug 4369826 8078582 8190884
> + * @run main/othervm LotsOfOutput
> ? * @summary Process with lots of output should not crash VM
> ? * @author kladko
> ? */
>
> Thanks, Roger
>
>
>


From brian.burkhalter at oracle.com  Tue Nov  7 23:03:33 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 7 Nov 2017 15:03:33 -0800
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
 <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
Message-ID: <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>

Hi Patrick,

On Nov 7, 2017, at 3:01 PM, Patrick Reinhart <patrick at reini.net> wrote:

> I integrated your changes into my current version which I will look into tomorrow with Alan at Devoxx. I think adding some implementation note on the default method implementation will be needed to review later on?

I concur.

> I also made an override on the CharBuffer, where we need to add a enhanced documentation for the specialties around the CharBuffer implementations (BufferOverflowException/ReadOnlyBufferException), where a review of some native english speakers would help :-)

Sounds good!

Thanks,

Brian

From martinrb at google.com  Wed Nov  8 00:26:29 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 7 Nov 2017 16:26:29 -0800
Subject: [NEW BUG][JDK10] TimeUnit.timedWait(Object obj, long timeout) doc
 should emphasize possibility of IllegalMonitorStateException
In-Reply-To: <000501d35817$45294120$cf7bc360$@freenet.de>
References: <000501d35817$45294120$cf7bc360$@freenet.de>
Message-ID: <CA+kOe0_A7NvBKVjP9XYz_i1z4+fiiBowE9D=zAxbz2+ujvNgeA@mail.gmail.com>

Thanks - you're right - I filed
https://bugs.openjdk.java.net/browse/JDK-8190889


On Tue, Nov 7, 2017 at 2:25 PM, Christoph Dreis <christoph.dreis at freenet.de>
wrote:

> Hi,
>
> I don't know if this is considered a real bug or just a lack of
> documentation, but I found that although the example in the documentation
> of
> TimeUnit.timedWait(Object obj, long timeout) shows the correct usage of the
> method, I think at least the documentation should emphasize the possibility
> of an IllegalMonitorStateException in case it isn't executed inside a
> synchronized block.
>
> The method seems to be not used inside the JDK itself after all, but people
> might use it.
>
> Please find a minimal reproduction and a possible documentation patch
> below.
> In case it is considered worthwhile I'd be happy if this is sponsored.
>
> Cheers,
> Christoph
>
> ===== MINIMAL REPRO ======
> public class Main {
>
>     public static void main(String[] args) {
>         Lock lock = new ReentrantLock();
>         try {
>             TimeUnit.MILLISECONDS.timedWait(lock, 1);
>         } catch (InterruptedException e) {
>             e.printStackTrace();
>         }
>     }
>
> }
>
> ====== PATCH ==========
> diff -r 67aa34b019e1
> src/java.base/share/classes/java/util/concurrent/TimeUnit.java
> --- a/src/java.base/share/classes/java/util/concurrent/TimeUnit.java
> Mon
> Nov 06 17:48:00 2017 -0800
> +++ b/src/java.base/share/classes/java/util/concurrent/TimeUnit.java
> Tue
> Nov 07 23:09:24 2017 +0100
> @@ -356,6 +356,8 @@
>       * @param timeout the maximum time to wait. If less than
>       * or equal to zero, do not wait at all.
>       * @throws InterruptedException if interrupted while waiting
> +     * @throws IllegalMonitorStateException if not executed inside a
> +     *         synchronized block
>       */
>      public void timedWait(Object obj, long timeout)
>              throws InterruptedException {
>
>

From martinrb at google.com  Wed Nov  8 02:35:36 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 7 Nov 2017 18:35:36 -0800
Subject: RFR: jsr166 jdk10 integration wave 5
In-Reply-To: <ef91d796-f804-6d60-57b2-83bedc602916@oracle.com>
References: <CA+kOe0-8aiXK2f5qR5FPp4uyA18QTVG8rgH7C96Qs0QG-GFF5g@mail.gmail.com>
 <82163eec-1cbb-d9dc-fce4-5c7fc5b72927@oracle.com>
 <CA+kOe0_u1KQCNtPw8FdAaymrV6QpFA6XT1e=etvx_9LOTBW1KA@mail.gmail.com>
 <ef91d796-f804-6d60-57b2-83bedc602916@oracle.com>
Message-ID: <CA+kOe0-HDL4rWKGoVtMf+5sRWPiURGn0Sa6eh0TWvSgfbcORJQ@mail.gmail.com>

On Mon, Nov 6, 2017 at 5:33 PM, David Holmes <david.holmes at oracle.com>
wrote:

> On 7/11/2017 8:17 AM, Martin Buchholz wrote:
>
>> Thanks for the review!
>>
>> On Mon, Nov 6, 2017 at 1:36 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>
>>         8189764: Miscellaneous changes imported from jsr166 CVS 2017-11
>>
>>
>>     All seem okay. Though I'm curious about the changes from
>>     "catch(Throwable" to "catch(Exception" ?
>>
>>
>> There's a half-hearted attempt to appease
>> http://errorprone.info/bugpattern/TryFailThrowable
>> No actual bugs were fixed.
>>
>
> Hmmm. Not sure I see a problem if threadUnexpectedException just wraps and
> rethrows the original exception. On the other hand Errors are no longer
> being handled this way. Probably doesn't make a difference either way.
>

Yes, probably doesn't make a difference either way.  These  TryFailThrowable
<http://errorprone.info/bugpattern/TryFailThrowable> warnings just don't
have enough value, so they are all reverted back to catch (Throwable).

From ramanand.patil at oracle.com  Wed Nov  8 07:14:07 2017
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Tue, 7 Nov 2017 23:14:07 -0800 (PST)
Subject: <i18n dev> JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c and
 8190259: test tck.java.time.zone.TCKZoneRules is broken by tzdata2017c
In-Reply-To: <CA+kOe0-3ckvbbHqSCQFQ67iwbvmWoOit+7vKH1h6wNMD0xyy2Q@mail.gmail.com>
References: <e0b6ec8c-9d01-4c57-8a49-884bb2317e6d@default>
 <1ec07748-3b87-5ec1-ff59-5da026807520@oracle.com>
 <17f3b700-4c79-4cb7-b869-7943a9b87854@default>
 <CA+kOe0-3ckvbbHqSCQFQ67iwbvmWoOit+7vKH1h6wNMD0xyy2Q@mail.gmail.com>
Message-ID: <05a9ea38-66b5-4cbb-bedd-b3273bcba494@default>

Thank you Martin for your review.

?

For the java file updates, currently I don?t use any script but just simple ?find and replace? whenever possible and rest is manual. I run all the TZ related tests locally on Ubuntu and use JPRT for all other platforms.

?

?

Regards,

Ramanand.

?

From: Martin Buchholz [mailto:martinrb at google.com] 
Sent: Wednesday, November 08, 2017 12:18 AM
To: Ramanand Patil <ramanand.patil at oracle.com>
Cc: Naoto Sato <naoto.sato at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev at openjdk.java.net
Subject: Re: <i18n dev> JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c and 8190259: test tck.java.time.zone.TCKZoneRules is broken by tzdata2017c

?

Looks good to me too.

?

I've always wondered about how the corresponding java source files are maintained.? Is it all manual or do y'all have some magic script to help keep IANA data and java data aligned?? Do we need more testing that mistakes don't creep in?

?

On Tue, Nov 7, 2017 at 3:41 AM, Ramanand Patil <HYPERLINK "mailto:ramanand.patil at oracle.com"ramanand.patil at oracle.com> wrote:

Hi Naoto,
Thank you for pointing that. I have modified both the affected files(ZoneName.java from src and test).
Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8190258+8190259/webrev.01/

Regards,
Ramanand.


> -----Original Message-----
> From: Naoto Sato
> Sent: Tuesday, November 07, 2017 5:18 AM
> To: Ramanand Patil <HYPERLINK "mailto:ramanand.patil at oracle.com"ramanand.patil at oracle.com>; core-libs-dev <core-libs-
> HYPERLINK "mailto:dev at openjdk.java.net"dev at openjdk.java.net>; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net
> Subject: Re: <i18n dev> JDK10 RFR of JDK-8190258: (tz) Support tzdata2017c
> and 8190259: test tck.java.time.zone.TCKZoneRules is broken by tzdata2017c
>
> Hi Ramanand,
>
> In java/time/format/ZoneName.java, should the zid for Africa_Central map
> to "Africa/Maputo"?
>
> Naoto
>
> On 11/6/17 6:06 AM, Ramanand Patil wrote:
> > Hi all,
> > Please review the latest TZDATA integration (tzdata2017c) to JDK10.
> > Bugs:
> > https://bugs.openjdk.java.net/browse/JDK-8190258
> > https://bugs.openjdk.java.net/browse/JDK-8190259
> >
> > Webrev: http://cr.openjdk.java.net/~rpatil/8190258+8190259/webrev.00/
> >
> > All the TimeZone related tests are passed after integration.
> >
> > Regards,
> > Ramanand.
> >

?

From paul.sandoz at oracle.com  Wed Nov  8 16:49:41 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 8 Nov 2017 08:49:41 -0800
Subject: Review request: JDK-8157246 MHs.arrayLength,
 arrayElementGetter/Setter, arrayConstructor need to specify invocation-time
 behavior
In-Reply-To: <aeb0d6af-e148-55ec-cbb6-05f3a46eb0b6@oracle.com>
References: <aeb0d6af-e148-55ec-cbb6-05f3a46eb0b6@oracle.com>
Message-ID: <2DEB8EC2-7A14-4492-AA34-9E83B8EAD6B1@oracle.com>


> On 7 Nov 2017, at 12:06, mandy chung <mandy.chung at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.00/index.html
> 
> This fixes the spec of MethodHandles::arrayLength, arrayConstructor, arrayElementGetter/Setter to specify the behavior if the returned method handle is invoked with null array or invalid index; same runtime exception thrown by the bytecode behavior.  MethodHandle::asSpreader spec is also clarified to throw NPE and IAE except when it spreads with no argument and the returned method handle accepts a zero-length array or null array.
> 

Looks good, minor comment.

MethodHandle
--

 889      * When the adapter is called, the length of the supplied {@code array}
 890      * argument is queried as if by {@code array.length} or {@code arrayLength}

s/arrayLength/arraylength/

See also MethodHandles.

Paul.

From john.r.rose at oracle.com  Wed Nov  8 16:59:40 2017
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 8 Nov 2017 08:59:40 -0800
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <876381003.1124033.1510090506277.JavaMail.zimbra@u-pem.fr>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>
 <E44F19C5-D530-41C2-AB21-F0CCABE9DD1B@oracle.com>
 <876381003.1124033.1510090506277.JavaMail.zimbra@u-pem.fr>
Message-ID: <458D86E4-51CC-48E8-A3D3-4AEE737FD558@oracle.com>

On Nov 7, 2017, at 1:35 PM, forax at univ-mlv.fr wrote:
> 
> perhaps getFinalStatic, because it's restricted to final field.

The restriction to final field is because we are expecting the
method to be used from condy, where it seems to be a syntax
error to sample a constant from a non-constant variable.

That said, I too would prefer to make it explicit (even in the name)
that the BSM applies only to static final fields.

So +1 for getStaticFinal instead of getStatic.  We also discussed
this internally back and forth.   Your comment pushed me over
the edge.

("getFinalStatic" is wrong BTW because "Final" is an extra
constraint after "getStatic", and because "static final" is the
usual written order for the corresponding modifiers, not
"final static", at least in the relevant source bases.)

? John

From paul.sandoz at oracle.com  Wed Nov  8 17:03:11 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 8 Nov 2017 09:03:11 -0800
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <458D86E4-51CC-48E8-A3D3-4AEE737FD558@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>
 <E44F19C5-D530-41C2-AB21-F0CCABE9DD1B@oracle.com>
 <876381003.1124033.1510090506277.JavaMail.zimbra@u-pem.fr>
 <458D86E4-51CC-48E8-A3D3-4AEE737FD558@oracle.com>
Message-ID: <4043E2D6-B8F3-4AA2-A8B3-C952CEE4F945@oracle.com>


> On 8 Nov 2017, at 08:59, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Nov 7, 2017, at 1:35 PM, forax at univ-mlv.fr <mailto:forax at univ-mlv.fr> wrote:
>> 
>> perhaps getFinalStatic, because it's restricted to final field.
> 
> The restriction to final field is because we are expecting the
> method to be used from condy, where it seems to be a syntax
> error to sample a constant from a non-constant variable.
> 
> That said, I too would prefer to make it explicit (even in the name)
> that the BSM applies only to static final fields.
> 
> So +1 for getStaticFinal instead of getStatic.  We also discussed
> this internally back and forth.   Your comment pushed me over
> the edge.
> 

Updated the CSR to reflect this. I will update the webrev soon.


> ("getFinalStatic" is wrong BTW because "Final" is an extra
> constraint after "getStatic", and because "static final" is the
> usual written order for the corresponding modifiers, not
> "final static", at least in the relevant source bases.)
> 

+1

Paul.

From Roger.Riggs at Oracle.com  Wed Nov  8 18:11:32 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 8 Nov 2017 13:11:32 -0500
Subject: [Patch][JDK10] Use Class.getPackageName() where possible
In-Reply-To: <25780137-1178-af0d-a322-1ba29d020ac8@oracle.com>
References: <000101d3543e$840b6080$8c222180$@freenet.de>
 <72043f40-6a9c-f79a-66be-5e68e6ce1f0c@oracle.com>
 <000c01d3547a$ad4d6470$07e82d50$@freenet.de>
 <4a0476c1-1333-9e28-5b07-066b8fa74213@oracle.com>
 <AM4PR08MB1219C410B9E57E3E39B2F9A2FF520@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ecea8e88-3890-50f8-fcf7-e8e9e3461127@oracle.com>
 <000001d357d7$7269fc50$573df4f0$@freenet.de>
 <25780137-1178-af0d-a322-1ba29d020ac8@oracle.com>
Message-ID: <b18ca297-04b1-a4c3-4871-3d1fa24929be@Oracle.com>

Hi Mandy,

yes, the revision in the webrev is correct; the trailing '.' in the pkg 
was just to ensure it was a package prefix.

+1, Roger




On 11/7/2017 6:00 PM, mandy chung wrote:
>
>
> On 11/7/17 6:48 AM, Christoph Dreis wrote:
>> ======= PATCH =======
>> diff -r 67aa34b019e1 src/java.base/share/classes/java/io/ObjectInputFilter.java
>> --- a/src/java.base/share/classes/java/io/ObjectInputFilter.java	Mon Nov 06 17:48:00 2017 -0800
>> +++ b/src/java.base/share/classes/java/io/ObjectInputFilter.java	Tue Nov 07 15:44:36 2017 +0100
>> @@ -656,8 +656,8 @@
>>                * otherwise {@code false}
>>                */
>>               private static boolean matchesPackage(Class<?> c, String pkg) {
>> -                String n = c.getName();
>> -                return n.startsWith(pkg) && n.lastIndexOf('.') == pkg.length() - 1;
>> +                String n = c.getPackageName();
>> +                return n.length() == pkg.length() - 1 && n.startsWith(pkg);
>>               }
>>   
>
> This is correct but we could simplify this.? We can modify the callers 
> to drop a trailing "." from the pkg parameter.? I took the liberty to 
> revise it a little.
>
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8190733/webrev.00/
>
> Roger - can you take a look at the change in ObjectInputFilter?
>
> Mandy


From mandy.chung at oracle.com  Wed Nov  8 18:13:23 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 8 Nov 2017 10:13:23 -0800
Subject: Review request: JDK-8157246 MHs.arrayLength,
 arrayElementGetter/Setter, arrayConstructor need to specify invocation-time
 behavior
In-Reply-To: <2DEB8EC2-7A14-4492-AA34-9E83B8EAD6B1@oracle.com>
References: <aeb0d6af-e148-55ec-cbb6-05f3a46eb0b6@oracle.com>
 <2DEB8EC2-7A14-4492-AA34-9E83B8EAD6B1@oracle.com>
Message-ID: <328d482f-4d2e-7e2b-905d-44eef27581a8@oracle.com>



On 11/8/17 8:49 AM, Paul Sandoz wrote:
>> On 7 Nov 2017, at 12:06, mandy chung <mandy.chung at oracle.com> wrote:
>>
>> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.00/index.html
>>
>> This fixes the spec of MethodHandles::arrayLength, arrayConstructor, arrayElementGetter/Setter to specify the behavior if the returned method handle is invoked with null array or invalid index; same runtime exception thrown by the bytecode behavior.  MethodHandle::asSpreader spec is also clarified to throw NPE and IAE except when it spreads with no argument and the returned method handle accepts a zero-length array or null array.
>>
> Looks good, minor comment.
>
> MethodHandle
> --
>
>   889      * When the adapter is called, the length of the supplied {@code array}
>   890      * argument is queried as if by {@code array.length} or {@code arrayLength}
>
> s/arrayLength/arraylength/
>
> See also MethodHandles.
>

Oops typo.? Fixed.

http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.01/

Here is the CSR:
 ?? https://bugs.openjdk.java.net/browse/JDK-8190945

Can you also review it?

thanks
Mandy

From paul.sandoz at oracle.com  Wed Nov  8 18:20:10 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 8 Nov 2017 10:20:10 -0800
Subject: Review request: JDK-8157246 MHs.arrayLength,
 arrayElementGetter/Setter, arrayConstructor need to specify invocation-time
 behavior
In-Reply-To: <328d482f-4d2e-7e2b-905d-44eef27581a8@oracle.com>
References: <aeb0d6af-e148-55ec-cbb6-05f3a46eb0b6@oracle.com>
 <2DEB8EC2-7A14-4492-AA34-9E83B8EAD6B1@oracle.com>
 <328d482f-4d2e-7e2b-905d-44eef27581a8@oracle.com>
Message-ID: <0214446A-B18C-475D-88D3-73A5F8F924BB@oracle.com>


> On 8 Nov 2017, at 10:13, mandy chung <mandy.chung at oracle.com> wrote:
> 
> 
> 
> On 11/8/17 8:49 AM, Paul Sandoz wrote:
>>> On 7 Nov 2017, at 12:06, mandy chung <mandy.chung at oracle.com> <mailto:mandy.chung at oracle.com> wrote:
>>> 
>>> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.00/index.html <http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.00/index.html>
>>> 
>>> This fixes the spec of MethodHandles::arrayLength, arrayConstructor, arrayElementGetter/Setter to specify the behavior if the returned method handle is invoked with null array or invalid index; same runtime exception thrown by the bytecode behavior.  MethodHandle::asSpreader spec is also clarified to throw NPE and IAE except when it spreads with no argument and the returned method handle accepts a zero-length array or null array.
>>> 
>> Looks good, minor comment.
>> 
>> MethodHandle
>> --
>> 
>>  889      * When the adapter is called, the length of the supplied {@code array}
>>  890      * argument is queried as if by {@code array.length} or {@code arrayLength}
>> 
>> s/arrayLength/arraylength/
>> 
>> See also MethodHandles.
>> 
> 
> Oops typo.  Fixed.
> 
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.01/ <http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.01/>
> 
> Here is the CSR:
>    https://bugs.openjdk.java.net/browse/JDK-8190945 <https://bugs.openjdk.java.net/browse/JDK-8190945>
> 
> Can you also review it?
> 

Reviewed.

Paul.

From Roger.Riggs at Oracle.com  Wed Nov  8 19:37:40 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 8 Nov 2017 14:37:40 -0500
Subject: Review request: JDK-8157246 MHs.arrayLength,
 arrayElementGetter/Setter, arrayConstructor need to specify invocation-time
 behavior
In-Reply-To: <0214446A-B18C-475D-88D3-73A5F8F924BB@oracle.com>
References: <aeb0d6af-e148-55ec-cbb6-05f3a46eb0b6@oracle.com>
 <2DEB8EC2-7A14-4492-AA34-9E83B8EAD6B1@oracle.com>
 <328d482f-4d2e-7e2b-905d-44eef27581a8@oracle.com>
 <0214446A-B18C-475D-88D3-73A5F8F924BB@oracle.com>
Message-ID: <9ed49215-49f4-c188-1bd9-7e5f8d6aa044@Oracle.com>

Hi Mandy,

A few editorial suggestions:

MethodHandle.java:
891: "accepts**a** zero-length trailing array argument
895: "if **the* *{@code array} does"

MethodHandleImpl.java:
667:? hard to follow indentation; perhaps adding the "else" will help.

MethodHandles.java:
2517: "Produces a method handle *for* constructing arrays..."
2523:? "array size, *a* {@code NegativeArraySizeException} will be thrown."
2550: "array reference, *a* {@code NullPointerPointer} exception will be 
thrown."
2573 & 2598 & 2641: "*A* {@code NullPointerPointer} *exception* will be 
thrown if the array reference

Is there a test for asSpreader(null, 0) and asSpreader(null, 1)? (The 
new exception thrown at MethodHandleImpl:667)

Roger


On 11/8/2017 1:20 PM, Paul Sandoz wrote:
>> On 8 Nov 2017, at 10:13, mandy chung <mandy.chung at oracle.com> wrote:
>>
>>
>>
>> On 11/8/17 8:49 AM, Paul Sandoz wrote:
>>>> On 7 Nov 2017, at 12:06, mandy chung <mandy.chung at oracle.com> <mailto:mandy.chung at oracle.com> wrote:
>>>>
>>>> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.00/index.html <http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.00/index.html>
>>>>
>>>> This fixes the spec of MethodHandles::arrayLength, arrayConstructor, arrayElementGetter/Setter to specify the behavior if the returned method handle is invoked with null array or invalid index; same runtime exception thrown by the bytecode behavior.  MethodHandle::asSpreader spec is also clarified to throw NPE and IAE except when it spreads with no argument and the returned method handle accepts a zero-length array or null array.
>>>>
>>> Looks good, minor comment.
>>>
>>> MethodHandle
>>> --
>>>
>>>   889      * When the adapter is called, the length of the supplied {@code array}
>>>   890      * argument is queried as if by {@code array.length} or {@code arrayLength}
>>>
>>> s/arrayLength/arraylength/
>>>
>>> See also MethodHandles.
>>>
>> Oops typo.  Fixed.
>>
>> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.01/ <http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.01/>
>>
>> Here is the CSR:
>>     https://bugs.openjdk.java.net/browse/JDK-8190945 <https://bugs.openjdk.java.net/browse/JDK-8190945>
>>
>> Can you also review it?
>>
> Reviewed.
>
> Paul.


From paul.sandoz at oracle.com  Wed Nov  8 21:01:09 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 8 Nov 2017 13:01:09 -0800
Subject: RFR 8190974 Parallel stream execution within a custom ForkJoinPool
 should obey the parallelism
Message-ID: <CFFC012D-28A8-4CEB-853E-ACE60041C4FA@oracle.com>

Hi,

Please review this patch to ensure that a parallel stream obeys the parallelism of a custom fork join pool when it is executed within that pool:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/>

Streams currently do not support capabilities to control the level of parallelism and therefore resources utilised (tricky API design problem to get right). 

At the moment the trick is to run stream executions within a custom pool, however the number of fork join tasks created will be in proportion to the parallelism of the common pool thus the execution will be over-provisioned. This can be especially noticeable on large machines with many cores.

Paul.

From mandy.chung at oracle.com  Wed Nov  8 21:43:52 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 8 Nov 2017 13:43:52 -0800
Subject: [Patch][JDK10] Use Class.getPackageName() where possible
In-Reply-To: <b18ca297-04b1-a4c3-4871-3d1fa24929be@Oracle.com>
References: <000101d3543e$840b6080$8c222180$@freenet.de>
 <72043f40-6a9c-f79a-66be-5e68e6ce1f0c@oracle.com>
 <000c01d3547a$ad4d6470$07e82d50$@freenet.de>
 <4a0476c1-1333-9e28-5b07-066b8fa74213@oracle.com>
 <AM4PR08MB1219C410B9E57E3E39B2F9A2FF520@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ecea8e88-3890-50f8-fcf7-e8e9e3461127@oracle.com>
 <000001d357d7$7269fc50$573df4f0$@freenet.de>
 <25780137-1178-af0d-a322-1ba29d020ac8@oracle.com>
 <b18ca297-04b1-a4c3-4871-3d1fa24929be@Oracle.com>
Message-ID: <6cae865b-d346-3ac1-916f-ca1ab1dd2387@oracle.com>

Thanks Roger.

Christoph - your patch has been pushed to jdk/jdk repo.

Mandy


On 11/8/17 10:11 AM, Roger Riggs wrote:
> Hi Mandy,
>
> yes, the revision in the webrev is correct; the trailing '.' in the 
> pkg was just to ensure it was a package prefix.
>
> +1, Roger
>
>
>
>
> On 11/7/2017 6:00 PM, mandy chung wrote:
>>
>>
>> On 11/7/17 6:48 AM, Christoph Dreis wrote:
>>> ======= PATCH =======
>>> diff -r 67aa34b019e1 src/java.base/share/classes/java/io/ObjectInputFilter.java
>>> --- a/src/java.base/share/classes/java/io/ObjectInputFilter.java	Mon Nov 06 17:48:00 2017 -0800
>>> +++ b/src/java.base/share/classes/java/io/ObjectInputFilter.java	Tue Nov 07 15:44:36 2017 +0100
>>> @@ -656,8 +656,8 @@
>>>                * otherwise {@code false}
>>>                */
>>>               private static boolean matchesPackage(Class<?> c, String pkg) {
>>> -                String n = c.getName();
>>> -                return n.startsWith(pkg) && n.lastIndexOf('.') == pkg.length() - 1;
>>> +                String n = c.getPackageName();
>>> +                return n.length() == pkg.length() - 1 && n.startsWith(pkg);
>>>               }
>>>   
>>
>> This is correct but we could simplify this.? We can modify the 
>> callers to drop a trailing "." from the pkg parameter.? I took the 
>> liberty to revise it a little.
>>
>> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8190733/webrev.00/
>>
>> Roger - can you take a look at the change in ObjectInputFilter?
>>
>> Mandy
>


From christoph.dreis at freenet.de  Wed Nov  8 21:55:47 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Wed, 8 Nov 2017 22:55:47 +0100
Subject: [Patch][JDK10] Use Class.getPackageName() where possible
In-Reply-To: <6cae865b-d346-3ac1-916f-ca1ab1dd2387@oracle.com>
References: <000101d3543e$840b6080$8c222180$@freenet.de>
 <72043f40-6a9c-f79a-66be-5e68e6ce1f0c@oracle.com>
 <000c01d3547a$ad4d6470$07e82d50$@freenet.de>
 <4a0476c1-1333-9e28-5b07-066b8fa74213@oracle.com>
 <AM4PR08MB1219C410B9E57E3E39B2F9A2FF520@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <ecea8e88-3890-50f8-fcf7-e8e9e3461127@oracle.com>
 <000001d357d7$7269fc50$573df4f0$@freenet.de>
 <25780137-1178-af0d-a322-1ba29d020ac8@oracle.com>
 <b18ca297-04b1-a4c3-4871-3d1fa24929be@Oracle.com>
 <6cae865b-d346-3ac1-916f-ca1ab1dd2387@oracle.com>
Message-ID: <002901d358dc$55caf490$0160ddb0$@freenet.de>

Hi Mandy,

> Christoph - your patch has been pushed to jdk/jdk repo.

I appreciate the sponsoring. Thanks!

Cheers,
Christoph



From paul.sandoz at oracle.com  Wed Nov  8 22:09:44 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 8 Nov 2017 14:09:44 -0800
Subject: RFR: jsr166 jdk10 integration wave 5
In-Reply-To: <CA+kOe0-8aiXK2f5qR5FPp4uyA18QTVG8rgH7C96Qs0QG-GFF5g@mail.gmail.com>
References: <CA+kOe0-8aiXK2f5qR5FPp4uyA18QTVG8rgH7C96Qs0QG-GFF5g@mail.gmail.com>
Message-ID: <868F794F-6598-4B46-9912-8183500DD092@oracle.com>


> On 6 Nov 2017, at 12:00, Martin Buchholz <martinrb at google.com> wrote:
> 
> The notable thing this time around is the embarrassing number of rare races being fixed, all of which are second tries.  This time for sure!
> 
> There's a large number of boring changes to appease errorprone, notably
> http://errorprone.info/bugpattern/RandomModInteger
> http://errorprone.info/bugpattern/MixedArrayDimensions
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/overview.html
> 

Looks good.


> 8190747: ExecutorService/Invoke.java fails intermittently
> 8179314: CountedCompleterTest.testForkHelpQuiesce fails with expected:<21> but was:<13>
> 8189387: ConcurrentLinkedDeque linearizability continued ?


 685     final Node<E> succ(Node<E> p) {
 686         // TODO: should we skip deleted nodes here?

Is the comment still relevant?

Paul.

> 8189764: Miscellaneous changes imported from jsr166 CVS 2017-11
> 


From martinrb at google.com  Wed Nov  8 22:20:05 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 8 Nov 2017 14:20:05 -0800
Subject: RFR: jsr166 jdk10 integration wave 5
In-Reply-To: <868F794F-6598-4B46-9912-8183500DD092@oracle.com>
References: <CA+kOe0-8aiXK2f5qR5FPp4uyA18QTVG8rgH7C96Qs0QG-GFF5g@mail.gmail.com>
 <868F794F-6598-4B46-9912-8183500DD092@oracle.com>
Message-ID: <CA+kOe0_NyT_Lsb+FgaDU3fhXdh2qEATc9c=wTWc0ookA4OVUuw@mail.gmail.com>

On Wed, Nov 8, 2017 at 2:09 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
>
>  685     final Node<E> succ(Node<E> p) {
>  686         // TODO: should we skip deleted nodes here?
>
> Is the comment still relevant?
>

It's still an open question, like what's the best GC strategy, or should
ArrayList automatically shrink (as well as grow) its backing array?

From paul.sandoz at oracle.com  Wed Nov  8 22:25:03 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 8 Nov 2017 14:25:03 -0800
Subject: RFR: jsr166 jdk10 integration wave 5
In-Reply-To: <CA+kOe0_NyT_Lsb+FgaDU3fhXdh2qEATc9c=wTWc0ookA4OVUuw@mail.gmail.com>
References: <CA+kOe0-8aiXK2f5qR5FPp4uyA18QTVG8rgH7C96Qs0QG-GFF5g@mail.gmail.com>
 <868F794F-6598-4B46-9912-8183500DD092@oracle.com>
 <CA+kOe0_NyT_Lsb+FgaDU3fhXdh2qEATc9c=wTWc0ookA4OVUuw@mail.gmail.com>
Message-ID: <927FAB71-8BE0-4D3D-B152-9E42DF35329F@oracle.com>


> On 8 Nov 2017, at 14:20, Martin Buchholz <martinrb at google.com> wrote:
> 
> 
> 
> On Wed, Nov 8, 2017 at 2:09 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 
>  685     final Node<E> succ(Node<E> p) {
>  686         // TODO: should we skip deleted nodes here?
> 
> Is the comment still relevant?
> 
> It's still an open question, like what's the best GC strategy, or should ArrayList automatically shrink (as well as grow) its backing array? 

Ok, i thought it might be somewhat related to skipping over null nodes and thus related to the linearizability fixes.

Paul.


From martinrb at google.com  Wed Nov  8 23:48:53 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 8 Nov 2017 15:48:53 -0800
Subject: RFR 8190974 Parallel stream execution within a custom
 ForkJoinPool should obey the parallelism
In-Reply-To: <CFFC012D-28A8-4CEB-853E-ACE60041C4FA@oracle.com>
References: <CFFC012D-28A8-4CEB-853E-ACE60041C4FA@oracle.com>
Message-ID: <CA+kOe0-cnk8_s7SuA=uMw5E_iKWw-1BdHopnK+_KHGKD0w4mJw@mail.gmail.com>

You probably want a different summary.

+ * @summary Tests counting of streams containing Integer.MAX_VALUE + 1 elements


Will this fail if common pool parallelism is odd?

+            int splitsForPHalfC = countSplits(new
ForkJoinPool(ForkJoinPool.getCommonPoolParallelism() / 2));


I would drop the word "factor" below:

+     * Default target factor of leaf tasks for parallel decomposition.


Do you ever test with

-Djava.util.concurrent.ForkJoinPool.common.parallelism=0

 * @run junit/othervm/timeout=1000
 *      --add-opens java.base/java.util.concurrent=ALL-UNNAMED
 *      --add-opens java.base/java.lang=ALL-UNNAMED
 *      -Djsr166.testImplementationDetails=true
 *      -Djava.util.concurrent.ForkJoinPool.common.parallelism=0
 *      JSR166TestCase




On Wed, Nov 8, 2017 at 1:01 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> Please review this patch to ensure that a parallel stream obeys the
> parallelism of a custom fork join pool when it is executed within that pool:
>
>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-
> stream-custom-pool/webrev/ <http://cr.openjdk.java.net/~
> psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/>
>
> Streams currently do not support capabilities to control the level of
> parallelism and therefore resources utilised (tricky API design problem to
> get right).
>
> At the moment the trick is to run stream executions within a custom pool,
> however the number of fork join tasks created will be in proportion to the
> parallelism of the common pool thus the execution will be over-provisioned.
> This can be especially noticeable on large machines with many cores.
>
> Paul.

From mandy.chung at oracle.com  Wed Nov  8 23:52:13 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 8 Nov 2017 15:52:13 -0800
Subject: Review request: JDK-8157246 MHs.arrayLength,
 arrayElementGetter/Setter, arrayConstructor need to specify invocation-time
 behavior
In-Reply-To: <9ed49215-49f4-c188-1bd9-7e5f8d6aa044@Oracle.com>
References: <aeb0d6af-e148-55ec-cbb6-05f3a46eb0b6@oracle.com>
 <2DEB8EC2-7A14-4492-AA34-9E83B8EAD6B1@oracle.com>
 <328d482f-4d2e-7e2b-905d-44eef27581a8@oracle.com>
 <0214446A-B18C-475D-88D3-73A5F8F924BB@oracle.com>
 <9ed49215-49f4-c188-1bd9-7e5f8d6aa044@Oracle.com>
Message-ID: <87e6fd45-6a82-b3c6-4536-df7c2cfae4ba@oracle.com>

Hi Roger,

Updated version:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.02/index.html

On 11/8/17 11:37 AM, Roger Riggs wrote:
> Hi Mandy,
>
> A few editorial suggestions:
>
> MethodHandle.java:
> 891: "accepts**a** zero-length trailing array argument

Fixed
> 895: "if **the* *{@code array} does"
>

{@code array} is referred to the parameter name where I don't use 
article.? I drop the {@code...} and change it to "If the array".

> MethodHandleImpl.java:
> 667:? hard to follow indentation; perhaps adding the "else" will help.
>

I revised it to the following:

 ??????? if (av == null && n == 0) {
 ??????????? return;
 ??????? } else if (av == null) {
 ??????????? throw new NullPointerException("null array reference");

> MethodHandles.java:
> 2517: "Produces a method handle *for* constructing arrays..."

It reads fine without "for" and the other arrayXXX factory methods are 
similar.? I leave it for the original author to follow up.

> 2523: "array size, *a* {@code NegativeArraySizeException} will be 
> thrown."
> 2550: "array reference, *a* {@code NullPointerPointer} exception will 
> be thrown."
> 2573 & 2598 & 2641: "*A* {@code NullPointerPointer} *exception* will 
> be thrown if the array reference
>
> Is there a test for asSpreader(null, 0) and asSpreader(null, 1)? (The 
> new exception thrown at MethodHandleImpl:667)
>

The new exception is thrown when the MethodHandle returned by 
MethodHandle::asSpreader.? The test cases are covered by the new 
InvokeMethodHandleWithBadArgument test.

asSpreader(null, 0) and asSpreader(null, 1) are not related to this 
issue.? The check is done by MethodHandle::asSpreaderChecks. Since this 
gets my attention, I add the test cases in an existing test 
SpreadCollectTest.java.

Mandy

From john.r.rose at oracle.com  Thu Nov  9 00:01:20 2017
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 8 Nov 2017 16:01:20 -0800
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <E44F19C5-D530-41C2-AB21-F0CCABE9DD1B@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr>
 <E44F19C5-D530-41C2-AB21-F0CCABE9DD1B@oracle.com>
Message-ID: <CA889026-86D3-4700-9834-537EF9CB2160@oracle.com>

On Nov 7, 2017, at 12:59 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> For condy, having the BSM validate types is a code smell
> for the reason you mention.  Also, when primitives (and value
> types) are in the mix, people usually code the validation
> incorrectly, since Class.isInstance is the wrong tool, and
> the right tool is non-obvious (MHs.identity.asType).

For the record, here is a method that performs the correct conversions:

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

The bug suggests that it be called Class::convert.

The code itself is simple enough to cut-n-paste into your own BSMs.

? John

From paul.sandoz at oracle.com  Thu Nov  9 00:43:48 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 8 Nov 2017 16:43:48 -0800
Subject: RFR 8190974 Parallel stream execution within a custom
 ForkJoinPool should obey the parallelism
In-Reply-To: <CA+kOe0-cnk8_s7SuA=uMw5E_iKWw-1BdHopnK+_KHGKD0w4mJw@mail.gmail.com>
References: <CFFC012D-28A8-4CEB-853E-ACE60041C4FA@oracle.com>
 <CA+kOe0-cnk8_s7SuA=uMw5E_iKWw-1BdHopnK+_KHGKD0w4mJw@mail.gmail.com>
Message-ID: <8445A78E-A5EE-4266-ACC2-520499398D5F@oracle.com>


> On 8 Nov 2017, at 15:48, Martin Buchholz <martinrb at google.com> wrote:
> 
> You probably want a different summary.
> + * @summary Tests counting of streams containing Integer.MAX_VALUE + 1 elements
> 
Doh, indeed.


> Will this fail if common pool parallelism is odd?
> +            int splitsForPHalfC = countSplits(new ForkJoinPool(ForkJoinPool.getCommonPoolParallelism() / 2));
> 

Yes, the number of splits will be parallelism * 4 rounded up to the nearest power of 2.

I modified the common pool testing and removed the doubling of the parallelism since this might result in OOME when creating the threads.


> I would drop the word "factor" below:
> +     * Default target factor of leaf tasks for parallel decomposition.
> 
Ok.


> Do you ever test with
> 
> -Djava.util.concurrent.ForkJoinPool.common.parallelism=0
> 
>  * @run junit/othervm/timeout=1000
>  *      --add-opens java.base/java.util.concurrent=ALL-UNNAMED
>  *      --add-opens java.base/java.lang=ALL-UNNAMED
>  *      -Djsr166.testImplementationDetails=true
>  *      -Djava.util.concurrent.ForkJoinPool.common.parallelism=0
>  *      JSR166TestCase
> 

Added. I had to move the test outside of the stream test area, which is set up to run in a more restricted manner.

WebRev updated in place 

Thanks,
Paul.

> 
> 
> 
> On Wed, Nov 8, 2017 at 1:01 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
> Hi,
> 
> Please review this patch to ensure that a parallel stream obeys the parallelism of a custom fork join pool when it is executed within that pool:
> 
>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/> <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/>>
> 
> Streams currently do not support capabilities to control the level of parallelism and therefore resources utilised (tricky API design problem to get right).
> 
> At the moment the trick is to run stream executions within a custom pool, however the number of fork join tasks created will be in proportion to the parallelism of the common pool thus the execution will be over-provisioned. This can be especially noticeable on large machines with many cores.
> 
> Paul.
> 


From jeremymanson at google.com  Thu Nov  9 01:09:50 2017
From: jeremymanson at google.com (Jeremy Manson)
Date: Wed, 8 Nov 2017 17:09:50 -0800
Subject: Change in properties for logging: deliberate?
Message-ID: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>

Hey folks,

I can't find reference to this in a relnote, so I thought I would ask.  If
we have the following files:

logging.properties:

# Set the level of the root logger
.level = INFO

# Send the root logger's output to the console
.handlers = java.util.logging.ConsoleHandler

Test.java:
public class Test {
  public static void main(String[] args) {
    java.util.logging.Logger.getAnonymousLogger().info("Hi!");
  }
}

In Java 8, we will see console output, and in Java 9, we won't.

# Java 8
$ java -Djava.util.logging.config.file=logging.properties Test
Nov 08, 2017 5:02:05 PM Test main
INFO: Hi!

# Java 9
$ java -Djava.util.logging.config.file=logging.properties Test


I thought that, perhaps, a decision was made to have the empty string no
longer mean the root logger, so I took it off of .handlers:

logging.properties:

# Set the level of the root logger
.level = INFO

# Send the root logger's output to the console
handlers = java.util.logging.ConsoleHandler

Success in the sense that this got me output in Java 9.  However, .level
still seems to work; if I then have:

# Set the level of the root logger
.level = WARNING

# Send the root logger's output to the console
handlers = java.util.logging.ConsoleHandler

it sets the root logger's level to WARNING.

I don't see any of this in a relnote anywhere, and I don't see an obvious
bug about it anywhere.  There seem to have been a fair few changes to
java.util.logging in Java 9.  Was a documented decision made to have
.handlers stop meaning handlers on the root logger, but to allow .level to
continue meaning level on the root logger?  Or do I just have the wrong end
of the stick on this?

Thanks!

Jeremy

From martinrb at google.com  Thu Nov  9 02:44:12 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 8 Nov 2017 18:44:12 -0800
Subject: RFR 8190974 Parallel stream execution within a custom
 ForkJoinPool should obey the parallelism
In-Reply-To: <8445A78E-A5EE-4266-ACC2-520499398D5F@oracle.com>
References: <CFFC012D-28A8-4CEB-853E-ACE60041C4FA@oracle.com>
 <CA+kOe0-cnk8_s7SuA=uMw5E_iKWw-1BdHopnK+_KHGKD0w4mJw@mail.gmail.com>
 <8445A78E-A5EE-4266-ACC2-520499398D5F@oracle.com>
Message-ID: <CA+kOe08xj1DzjarnxYwn80QEd0YAp5g+HPoRcPeQLZyfnHQArg@mail.gmail.com>

Looks good, but have comments as always.

Fix type: exection

Unrelated typo: the this slice spliterator

I would test core libraries under taskset with an odd number of cpus



On Wed, Nov 8, 2017 at 4:43 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> On 8 Nov 2017, at 15:48, Martin Buchholz <martinrb at google.com> wrote:
>
> You probably want a different summary.
>
> + * @summary Tests counting of streams containing Integer.MAX_VALUE + 1 elements
>
>
> Doh, indeed.
>
>
> Will this fail if common pool parallelism is odd?
>
> +            int splitsForPHalfC = countSplits(new ForkJoinPool(ForkJoinPool.getCommonPoolParallelism() / 2));
>
>
>
> Yes, the number of splits will be parallelism * 4 rounded up to the
> nearest power of 2.
>
> I modified the common pool testing and removed the doubling of the
> parallelism since this might result in OOME when creating the threads.
>
>
> I would drop the word "factor" below:
>
> +     * Default target factor of leaf tasks for parallel decomposition.
>
>
> Ok.
>
>
> Do you ever test with
>
> -Djava.util.concurrent.ForkJoinPool.common.parallelism=0
>
>  * @run junit/othervm/timeout=1000
>  *      --add-opens java.base/java.util.concurrent=ALL-UNNAMED
>  *      --add-opens java.base/java.lang=ALL-UNNAMED
>  *      -Djsr166.testImplementationDetails=true
>  *      -Djava.util.concurrent.ForkJoinPool.common.parallelism=0
>  *      JSR166TestCase
>
>
> Added. I had to move the test outside of the stream test area, which is
> set up to run in a more restricted manner.
>
> WebRev updated in place
>
> Thanks,
> Paul.
>
>
>
>
> On Wed, Nov 8, 2017 at 1:01 PM, Paul Sandoz <paul.sandoz at oracle.com>
> wrote:
>
>> Hi,
>>
>> Please review this patch to ensure that a parallel stream obeys the
>> parallelism of a custom fork join pool when it is executed within that pool:
>>
>>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-st
>> ream-custom-pool/webrev/ <http://cr.openjdk.java.net/~p
>> sandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/>
>>
>> Streams currently do not support capabilities to control the level of
>> parallelism and therefore resources utilised (tricky API design problem to
>> get right).
>>
>> At the moment the trick is to run stream executions within a custom pool,
>> however the number of fork join tasks created will be in proportion to the
>> parallelism of the common pool thus the execution will be over-provisioned.
>> This can be especially noticeable on large machines with many cores.
>>
>> Paul.
>
>
>
>

From stanislav.lukyanov at oracle.com  Thu Nov  9 08:24:38 2017
From: stanislav.lukyanov at oracle.com (stanislav lukyanov)
Date: Thu, 9 Nov 2017 13:54:38 +0530
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
Message-ID: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com>

Hi Paul,

How about changing the name of the class to ConstantFactory to align
with its two siblings - LambdaMetafactory and StringConcatFactory?

Other comments are purely about the spec text (should I be posting them 
in the CSR issue instead?)

The class-level javadoc could use more text to describe the contents
(e.g. "Methods to facilitate creation of common kinds of dynamic 
constants...", similar to other bootstrap factories)
and motivation for having this class. I think giving the motivation here 
is important - it might be not obvious why, for example,
nullConstant is needed when there is aconst_null.
Maybe an example of an invokedynamic using static arguments that are 
dynamic constants (repeat the last six words together BTW!)
could also be there (javap- or jasm-style pseudocode for that?)
Also, @author and @since are missing.

All methods repeat the same NPE condition
 ??? @throws NullPointerException if any used argument is {@code null}
which looks especially strange in methods with one used parameter (e.g. 
nullConstant)
or with no unused parameters (e.g. getStaticFinal).
I'd suggest to instead go with the commonly used shortcut of declaring 
the NPE in the class-level Javadoc, e.g.
 ??? "Passing a null argument to a method in this class will cause of 
NullPointerException to be thrown,
 ????? unless the argument is specified to be unused, or unless 
otherwise noted".

The VarHandle methods have
 ??? @param type unused; must be {@code Class<VarHandle>}
Looks like the "unused;" part should be removed.

Thanks,
Stas

On 08.11.2017 0:08, Paul Sandoz wrote:
> Hi,
>
> Please review the patch that adds a minimal set of bootstrap methods can be be used for producing dynamic constants:
>
>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/>
>
> The aim is to provide a small but common set of BSMs that are likely useful with ldc or as BSM arguments, filling in the gaps for constants that cannot be currently represented, such as null, primitive classes and VarHandles. It?s possible to get more sophisticated regarding say factories but that is something to consider later on.
>
> This patch is based off the minimal dynamic constant support (still in review):
>
>    http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html>
>
> Paul.
>


From stanislav.lukyanov at oracle.com  Thu Nov  9 08:42:02 2017
From: stanislav.lukyanov at oracle.com (stanislav lukyanov)
Date: Thu, 9 Nov 2017 14:12:02 +0530
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com>
Message-ID: <f043c86b-4702-4325-466e-fdb2d4cf3260@oracle.com>

I also noticed that Class::isPrimitive now says the following:
 ??? "These objects may only be accessed via the following public static 
final variables, and are the only Class objects for which this method 
returns true."
(the fields its talking about are the <Box>.TYPE)
Should this text be tweaked?

Thanks,
Stas

On 09.11.2017 13:54, stanislav lukyanov wrote:
> Hi Paul,
>
> How about changing the name of the class to ConstantFactory to align
> with its two siblings - LambdaMetafactory and StringConcatFactory?
>
> Other comments are purely about the spec text (should I be posting 
> them in the CSR issue instead?)
>
> The class-level javadoc could use more text to describe the contents
> (e.g. "Methods to facilitate creation of common kinds of dynamic 
> constants...", similar to other bootstrap factories)
> and motivation for having this class. I think giving the motivation 
> here is important - it might be not obvious why, for example,
> nullConstant is needed when there is aconst_null.
> Maybe an example of an invokedynamic using static arguments that are 
> dynamic constants (repeat the last six words together BTW!)
> could also be there (javap- or jasm-style pseudocode for that?)
> Also, @author and @since are missing.
>
> All methods repeat the same NPE condition
> ??? @throws NullPointerException if any used argument is {@code null}
> which looks especially strange in methods with one used parameter 
> (e.g. nullConstant)
> or with no unused parameters (e.g. getStaticFinal).
> I'd suggest to instead go with the commonly used shortcut of declaring 
> the NPE in the class-level Javadoc, e.g.
> ??? "Passing a null argument to a method in this class will cause of 
> NullPointerException to be thrown,
> ????? unless the argument is specified to be unused, or unless 
> otherwise noted".
>
> The VarHandle methods have
> ??? @param type unused; must be {@code Class<VarHandle>}
> Looks like the "unused;" part should be removed.
>
> Thanks,
> Stas
>
> On 08.11.2017 0:08, Paul Sandoz wrote:
>> Hi,
>>
>> Please review the patch that adds a minimal set of bootstrap methods 
>> can be be used for producing dynamic constants:
>>
>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ 
>> <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/> 
>>
>>
>> The aim is to provide a small but common set of BSMs that are likely 
>> useful with ldc or as BSM arguments, filling in the gaps for 
>> constants that cannot be currently represented, such as null, 
>> primitive classes and VarHandles. It?s possible to get more 
>> sophisticated regarding say factories but that is something to 
>> consider later on.
>>
>> This patch is based off the minimal dynamic constant support (still 
>> in review):
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html 
>> <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html> 
>>
>>
>> Paul.
>>
>


From bourges.laurent at gmail.com  Thu Nov  9 09:00:37 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 9 Nov 2017 10:00:37 +0100
Subject: Faster Math ?
In-Reply-To: <CAKjRUT4iFEZ1p-OLYAOiyKVmiTGLSPN0-HJVRwLGboxqgv4xkA@mail.gmail.com>
References: <CAKjRUT7V1swPZJkEJKOtde-vZQgvAOg=_=uA-e9t+Z+QySMoVQ@mail.gmail.com>
 <CAKjRUT5RjVW_FYfSVJ4N4U-g7E7yHASRYMNdw1LV0czRi1WT3g@mail.gmail.com>
 <CAKjRUT6EWLiVka04exEQzgDLsF_Bu-ihbKBuHKr-r7sh843zeA@mail.gmail.com>
 <CAKjRUT40h-VFb63biagg0PM-pOctbPN_6fCW1GMLWY0SsyDtkg@mail.gmail.com>
 <CAKjRUT7d5ABHmmq9JS4SQVegDxGvaaqeEise0=Fz3w24HZHFRg@mail.gmail.com>
 <CAKjRUT7xXu4qCTJQjq+FRNPHFE+QRJ4AoAcTo-BobtKps3GwNw@mail.gmail.com>
 <CAKjRUT7Xo2FX9zsu-s-mVCzGBbi_qBRxGi9s7YFUK-42zSOJbw@mail.gmail.com>
 <CAKjRUT42-j3D8phr6f5ZDZPU59526gUwY-t4PoLVb6YTe+=mBA@mail.gmail.com>
 <CAKjRUT6LRph5iDZramw72RqNTByE-AXT5vzzsQ5n07rSF20WPQ@mail.gmail.com>
 <CAKjRUT5fT_Y6xijmXJW=G2oJpoKhFMYX2iiOW90K7N8f5mPmuA@mail.gmail.com>
 <CAKjRUT653G1i6vzzZDh5enMB8_7HoQiHaxRSn58oXz6iUcGJ2g@mail.gmail.com>
 <CAKjRUT7ti7ZOD2RGzgL4QpSAwbfoLUL15E2MiAqGxbhCJSm3jA@mail.gmail.com>
 <CAKjRUT7wdnuGnX=n4YA0TnQuCe98tHorCBqAvhFbAFS=W1+4ag@mail.gmail.com>
 <CAKjRUT4j-R60NpCmEcs+x5-whmobyvBcAHSqecaH6PFG_NzaZA@mail.gmail.com>
 <CAKjRUT46GRnUqNgD-s81z_qYd0-_Rj-VQUgtVsMSUMKfHqJOxw@mail.gmail.com>
 <CAKjRUT5Ltn=4URTR2NXDgFis=b9s6e2TJS-FCK5qqqeyAXswuA@mail.gmail.com>
 <CAKjRUT7XkZevTau--k8avcUX6KE_bZmgRwJaGSx-2rt=Nz-4=Q@mail.gmail.com>
 <CAKjRUT668ng+Xh08a4VzJt4vPceuQp4VyOuRF2X=nZK+R4RHzw@mail.gmail.com>
 <CAKjRUT7K0evbnjY0ixzhMB54MEXiJxCkW4es_C1vLJ-hWywCaA@mail.gmail.com>
 <CAKjRUT6sbq8GoPLfZUtirvSX7okWSW+xOQ5B=rggOkYJ889PYQ@mail.gmail.com>
 <CAKjRUT48TpyU8XgHNewSu7Vt_GKMOS3-D7sKa6VuGTiNPERaSA@mail.gmail.com>
 <CAKjRUT6i8iSF07USPhY=jTPU5dc4g7rNn9WuA+DHRQioMS=1og@mail.gmail.com>
 <CAKjRUT4ezaSE5mPMNfXQaQfgu+3Y34+O1yBTvnbJ6Rmv+mkUyw@mail.gmail.com>
 <CAKjRUT4iFEZ1p-OLYAOiyKVmiTGLSPN0-HJVRwLGboxqgv4xkA@mail.gmail.com>
Message-ID: <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>

Hi,

The Marlin renderer (JEP265) uses few Math functions: sqrt, cbrt, acos...

Could you check if the current JDK uses C2 intrinsics or libfdm (native /
JNI overhead?) and tell me if such functions are already highly optimized
in jdk9 or 10 ?

Some people have implemented their own fast Math like Apache Commons Math
or JaFaMa libraries that are 10x faster for acos / cbrt.

I wonder if I should implement my own cbrt function (cubics) in pure java
as I do not need the highest accuracy but SPEED.

Would it sound possible to have a JDK FastMath public API (lots faster but
less accurate?)

Do you know if recent CPU (intel?) have dedicated instructions for such
math operations ?
Why not use it instead?
Maybe that's part of the new Vectorization API (panama) ?

Cheers,
Laurent Bourges

From volker.simonis at gmail.com  Thu Nov  9 09:01:16 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 9 Nov 2017 10:01:16 +0100
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com>
Message-ID: <CA+3eh11pz0dYhgtwd285xaj_We1ezn2Gw7XZmQ2FsHPLxvg4JA@mail.gmail.com>

Hi Paul,

just some quick process-related questions.

Is this intended to be targeted for jdk 10?

Is the current implementation already available in a separate
repository and/or branch? I've read in the RFR for 8186046 that some
parts are currently being refined in the amber repository. Or is the
complete implementation already available there?

If I want to port this to ppc64, what's the best way to start and what
do I need? Is it just the two webrevs for 8187742 and 8186046 on top
of the jdk hs repo? Or is it a branch of the amber repo?

You may know that there's currently a discussion going on about what
is a JEP and what's the right way to implement and integrate a JEP
into the mainline. The general idea is that only 'finished' JEPs will
be targeted and integrated into the always feature complete main line.
So is this and the review for 8186046 about the integration into the
jdk repo (which shouldn't happen before the JEP is not targeted for
jdk10) or is it just the review before the JEP can actually be
targeted? This is important because there's not much time before the
jdk10 repos will enter Rampdown phase 1 and we would still have to
port this to ppc (and also ARM/SPARC) if it will be targeted for jdk
10.

I don't want to question the merits and quality of the current
implementation which I'm sure are great. For me as an external
observer its just hard to oversee the current status of the
implementation.

Thanks,
Volker


On Thu, Nov 9, 2017 at 9:24 AM, stanislav lukyanov
<stanislav.lukyanov at oracle.com> wrote:
> Hi Paul,
>
> How about changing the name of the class to ConstantFactory to align
> with its two siblings - LambdaMetafactory and StringConcatFactory?
>
> Other comments are purely about the spec text (should I be posting them in
> the CSR issue instead?)
>
> The class-level javadoc could use more text to describe the contents
> (e.g. "Methods to facilitate creation of common kinds of dynamic
> constants...", similar to other bootstrap factories)
> and motivation for having this class. I think giving the motivation here is
> important - it might be not obvious why, for example,
> nullConstant is needed when there is aconst_null.
> Maybe an example of an invokedynamic using static arguments that are dynamic
> constants (repeat the last six words together BTW!)
> could also be there (javap- or jasm-style pseudocode for that?)
> Also, @author and @since are missing.
>
> All methods repeat the same NPE condition
>     @throws NullPointerException if any used argument is {@code null}
> which looks especially strange in methods with one used parameter (e.g.
> nullConstant)
> or with no unused parameters (e.g. getStaticFinal).
> I'd suggest to instead go with the commonly used shortcut of declaring the
> NPE in the class-level Javadoc, e.g.
>     "Passing a null argument to a method in this class will cause of
> NullPointerException to be thrown,
>       unless the argument is specified to be unused, or unless otherwise
> noted".
>
> The VarHandle methods have
>     @param type unused; must be {@code Class<VarHandle>}
> Looks like the "unused;" part should be removed.
>
> Thanks,
> Stas
>
>
> On 08.11.2017 0:08, Paul Sandoz wrote:
>>
>> Hi,
>>
>> Please review the patch that adds a minimal set of bootstrap methods can
>> be be used for producing dynamic constants:
>>
>>
>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/
>> <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/>
>>
>> The aim is to provide a small but common set of BSMs that are likely
>> useful with ldc or as BSM arguments, filling in the gaps for constants that
>> cannot be currently represented, such as null, primitive classes and
>> VarHandles. It?s possible to get more sophisticated regarding say factories
>> but that is something to consider later on.
>>
>> This patch is based off the minimal dynamic constant support (still in
>> review):
>>
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html
>> <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html>
>>
>> Paul.
>>
>

From me at yawk.at  Thu Nov  9 09:51:17 2017
From: me at yawk.at (Jonas Konrad)
Date: Thu, 9 Nov 2017 10:51:17 +0100
Subject: Faster Math ?
In-Reply-To: <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>
References: <CAKjRUT7V1swPZJkEJKOtde-vZQgvAOg=_=uA-e9t+Z+QySMoVQ@mail.gmail.com>
 <CAKjRUT7wdnuGnX=n4YA0TnQuCe98tHorCBqAvhFbAFS=W1+4ag@mail.gmail.com>
 <CAKjRUT4j-R60NpCmEcs+x5-whmobyvBcAHSqecaH6PFG_NzaZA@mail.gmail.com>
 <CAKjRUT46GRnUqNgD-s81z_qYd0-_Rj-VQUgtVsMSUMKfHqJOxw@mail.gmail.com>
 <CAKjRUT5Ltn=4URTR2NXDgFis=b9s6e2TJS-FCK5qqqeyAXswuA@mail.gmail.com>
 <CAKjRUT7XkZevTau--k8avcUX6KE_bZmgRwJaGSx-2rt=Nz-4=Q@mail.gmail.com>
 <CAKjRUT668ng+Xh08a4VzJt4vPceuQp4VyOuRF2X=nZK+R4RHzw@mail.gmail.com>
 <CAKjRUT7K0evbnjY0ixzhMB54MEXiJxCkW4es_C1vLJ-hWywCaA@mail.gmail.com>
 <CAKjRUT6sbq8GoPLfZUtirvSX7okWSW+xOQ5B=rggOkYJ889PYQ@mail.gmail.com>
 <CAKjRUT48TpyU8XgHNewSu7Vt_GKMOS3-D7sKa6VuGTiNPERaSA@mail.gmail.com>
 <CAKjRUT6i8iSF07USPhY=jTPU5dc4g7rNn9WuA+DHRQioMS=1og@mail.gmail.com>
 <CAKjRUT4ezaSE5mPMNfXQaQfgu+3Y34+O1yBTvnbJ6Rmv+mkUyw@mail.gmail.com>
 <CAKjRUT4iFEZ1p-OLYAOiyKVmiTGLSPN0-HJVRwLGboxqgv4xkA@mail.gmail.com>
 <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>
Message-ID: <39a39ddd-7ef7-3e48-fb56-1ce293a8a0a9@yawk.at>

Hey,

Most functions in the Math class are intrinsic ( 
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/classfile/vmSymbols.hpp#l664 
) and will use native instructions where available. You can also test 
this yourself using jitwatch. There is no native call overhead.

The standard library does not currently include less accurate but faster 
Math functions, maybe someone else can answer if that is something to be 
considered.

- Jonas Konrad

On 11/09/2017 10:00 AM, Laurent Bourg?s wrote:
> Hi,
> 
> The Marlin renderer (JEP265) uses few Math functions: sqrt, cbrt, acos...
> 
> Could you check if the current JDK uses C2 intrinsics or libfdm (native /
> JNI overhead?) and tell me if such functions are already highly optimized
> in jdk9 or 10 ?
> 
> Some people have implemented their own fast Math like Apache Commons Math
> or JaFaMa libraries that are 10x faster for acos / cbrt.
> 
> I wonder if I should implement my own cbrt function (cubics) in pure java
> as I do not need the highest accuracy but SPEED.
> 
> Would it sound possible to have a JDK FastMath public API (lots faster but
> less accurate?)
> 
> Do you know if recent CPU (intel?) have dedicated instructions for such
> math operations ?
> Why not use it instead?
> Maybe that's part of the new Vectorization API (panama) ?
> 
> Cheers,
> Laurent Bourges
> 

From daniel.fuchs at oracle.com  Thu Nov  9 12:36:42 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 Nov 2017 12:36:42 +0000
Subject: Change in properties for logging: deliberate?
In-Reply-To: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
Message-ID: <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>

Hi Jeremy,

Which jdk version/distribution are you using?

I see .level = INFO in the jdk9/master sources:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.logging/share/conf/logging.properties

There should be no changes WRT the default level between 8 and 9.

best regards,

-- daniel

On 09/11/2017 01:09, Jeremy Manson wrote:
> Hey folks,
> 
> I can't find reference to this in a relnote, so I thought I would ask.  If
> we have the following files:
> 
> logging.properties:
> 
> # Set the level of the root logger
> .level = INFO
> 
> # Send the root logger's output to the console
> .handlers = java.util.logging.ConsoleHandler
> 
> Test.java:
> public class Test {
>    public static void main(String[] args) {
>      java.util.logging.Logger.getAnonymousLogger().info("Hi!");
>    }
> }
> 
> In Java 8, we will see console output, and in Java 9, we won't.
> 
> # Java 8
> $ java -Djava.util.logging.config.file=logging.properties Test
> Nov 08, 2017 5:02:05 PM Test main
> INFO: Hi!
> 
> # Java 9
> $ java -Djava.util.logging.config.file=logging.properties Test
> 
> 
> I thought that, perhaps, a decision was made to have the empty string no
> longer mean the root logger, so I took it off of .handlers:
> 
> logging.properties:
> 
> # Set the level of the root logger
> .level = INFO
> 
> # Send the root logger's output to the console
> handlers = java.util.logging.ConsoleHandler
> 
> Success in the sense that this got me output in Java 9.  However, .level
> still seems to work; if I then have:
> 
> # Set the level of the root logger
> .level = WARNING
> 
> # Send the root logger's output to the console
> handlers = java.util.logging.ConsoleHandler
> 
> it sets the root logger's level to WARNING.
> 
> I don't see any of this in a relnote anywhere, and I don't see an obvious
> bug about it anywhere.  There seem to have been a fair few changes to
> java.util.logging in Java 9.  Was a documented decision made to have
> .handlers stop meaning handlers on the root logger, but to allow .level to
> continue meaning level on the root logger?  Or do I just have the wrong end
> of the stick on this?
> 
> Thanks!
> 
> Jeremy
> 


From bourges.laurent at gmail.com  Thu Nov  9 13:33:15 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 9 Nov 2017 14:33:15 +0100
Subject: Faster Math ?
In-Reply-To: <39a39ddd-7ef7-3e48-fb56-1ce293a8a0a9@yawk.at>
References: <CAKjRUT7V1swPZJkEJKOtde-vZQgvAOg=_=uA-e9t+Z+QySMoVQ@mail.gmail.com>
 <CAKjRUT7wdnuGnX=n4YA0TnQuCe98tHorCBqAvhFbAFS=W1+4ag@mail.gmail.com>
 <CAKjRUT4j-R60NpCmEcs+x5-whmobyvBcAHSqecaH6PFG_NzaZA@mail.gmail.com>
 <CAKjRUT46GRnUqNgD-s81z_qYd0-_Rj-VQUgtVsMSUMKfHqJOxw@mail.gmail.com>
 <CAKjRUT5Ltn=4URTR2NXDgFis=b9s6e2TJS-FCK5qqqeyAXswuA@mail.gmail.com>
 <CAKjRUT7XkZevTau--k8avcUX6KE_bZmgRwJaGSx-2rt=Nz-4=Q@mail.gmail.com>
 <CAKjRUT668ng+Xh08a4VzJt4vPceuQp4VyOuRF2X=nZK+R4RHzw@mail.gmail.com>
 <CAKjRUT7K0evbnjY0ixzhMB54MEXiJxCkW4es_C1vLJ-hWywCaA@mail.gmail.com>
 <CAKjRUT6sbq8GoPLfZUtirvSX7okWSW+xOQ5B=rggOkYJ889PYQ@mail.gmail.com>
 <CAKjRUT48TpyU8XgHNewSu7Vt_GKMOS3-D7sKa6VuGTiNPERaSA@mail.gmail.com>
 <CAKjRUT6i8iSF07USPhY=jTPU5dc4g7rNn9WuA+DHRQioMS=1og@mail.gmail.com>
 <CAKjRUT4ezaSE5mPMNfXQaQfgu+3Y34+O1yBTvnbJ6Rmv+mkUyw@mail.gmail.com>
 <CAKjRUT4iFEZ1p-OLYAOiyKVmiTGLSPN0-HJVRwLGboxqgv4xkA@mail.gmail.com>
 <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>
 <39a39ddd-7ef7-3e48-fb56-1ce293a8a0a9@yawk.at>
Message-ID: <CAKjRUT4ZGrpDm1QUF=PWtzxib3pJ1LVfVYBDpi7Dc4RCzeJqWw@mail.gmail.com>

I checked in the latest jdk master and both cbrt / acos are NOT intrinsics.

However, cbrt(x) = pow(x, 1/3) so it may be optmized...

Could someone tell me how cbrt() is concretely implemented ?

In native libfdm, there is no e_cbrt.c !

Thanks for your help,
Laurent

Le 9 nov. 2017 10:52 AM, "Jonas Konrad" <me at yawk.at> a ?crit :

> Hey,
>
> Most functions in the Math class are intrinsic (
> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/
> share/vm/classfile/vmSymbols.hpp#l664 ) and will use native instructions
> where available. You can also test this yourself using jitwatch. There is
> no native call overhead.
>
> The standard library does not currently include less accurate but faster
> Math functions, maybe someone else can answer if that is something to be
> considered.
>
> - Jonas Konrad
>
> On 11/09/2017 10:00 AM, Laurent Bourg?s wrote:
>
>> Hi,
>>
>> The Marlin renderer (JEP265) uses few Math functions: sqrt, cbrt, acos...
>>
>> Could you check if the current JDK uses C2 intrinsics or libfdm (native /
>> JNI overhead?) and tell me if such functions are already highly optimized
>> in jdk9 or 10 ?
>>
>> Some people have implemented their own fast Math like Apache Commons Math
>> or JaFaMa libraries that are 10x faster for acos / cbrt.
>>
>> I wonder if I should implement my own cbrt function (cubics) in pure java
>> as I do not need the highest accuracy but SPEED.
>>
>> Would it sound possible to have a JDK FastMath public API (lots faster but
>> less accurate?)
>>
>> Do you know if recent CPU (intel?) have dedicated instructions for such
>> math operations ?
>> Why not use it instead?
>> Maybe that's part of the new Vectorization API (panama) ?
>>
>> Cheers,
>> Laurent Bourges
>>
>>

From bourges.laurent at gmail.com  Thu Nov  9 15:02:19 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 9 Nov 2017 16:02:19 +0100
Subject: Faster Math ?
In-Reply-To: <CAKjRUT4ZGrpDm1QUF=PWtzxib3pJ1LVfVYBDpi7Dc4RCzeJqWw@mail.gmail.com>
References: <CAKjRUT7V1swPZJkEJKOtde-vZQgvAOg=_=uA-e9t+Z+QySMoVQ@mail.gmail.com>
 <CAKjRUT7wdnuGnX=n4YA0TnQuCe98tHorCBqAvhFbAFS=W1+4ag@mail.gmail.com>
 <CAKjRUT4j-R60NpCmEcs+x5-whmobyvBcAHSqecaH6PFG_NzaZA@mail.gmail.com>
 <CAKjRUT46GRnUqNgD-s81z_qYd0-_Rj-VQUgtVsMSUMKfHqJOxw@mail.gmail.com>
 <CAKjRUT5Ltn=4URTR2NXDgFis=b9s6e2TJS-FCK5qqqeyAXswuA@mail.gmail.com>
 <CAKjRUT7XkZevTau--k8avcUX6KE_bZmgRwJaGSx-2rt=Nz-4=Q@mail.gmail.com>
 <CAKjRUT668ng+Xh08a4VzJt4vPceuQp4VyOuRF2X=nZK+R4RHzw@mail.gmail.com>
 <CAKjRUT7K0evbnjY0ixzhMB54MEXiJxCkW4es_C1vLJ-hWywCaA@mail.gmail.com>
 <CAKjRUT6sbq8GoPLfZUtirvSX7okWSW+xOQ5B=rggOkYJ889PYQ@mail.gmail.com>
 <CAKjRUT48TpyU8XgHNewSu7Vt_GKMOS3-D7sKa6VuGTiNPERaSA@mail.gmail.com>
 <CAKjRUT6i8iSF07USPhY=jTPU5dc4g7rNn9WuA+DHRQioMS=1og@mail.gmail.com>
 <CAKjRUT4ezaSE5mPMNfXQaQfgu+3Y34+O1yBTvnbJ6Rmv+mkUyw@mail.gmail.com>
 <CAKjRUT4iFEZ1p-OLYAOiyKVmiTGLSPN0-HJVRwLGboxqgv4xkA@mail.gmail.com>
 <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>
 <39a39ddd-7ef7-3e48-fb56-1ce293a8a0a9@yawk.at>
 <CAKjRUT4ZGrpDm1QUF=PWtzxib3pJ1LVfVYBDpi7Dc4RCzeJqWw@mail.gmail.com>
Message-ID: <CAKjRUT7k-ZCAt8uwc0ZLg8OE4xgDHTcC+nJbzNv+R72xQP=9yQ@mail.gmail.com>

Hi,

Here are very basic benchmark results from (JaFaMa 2 - FastMathPerf) made
on my laptop (i7-6820HQ set @ 2Ghz + JDK8):
--- testing asin(double) ---
Loop on     Math.asin(double) took 6.675 s
Loop on FastMath.asin(double) took 0.162 s

--- testing acos(double) ---
Loop on     Math.acos(double) took 6.332 s
Loop on FastMath.acos(double) took 0.16 s

--- testing atan(double) ---
Loop on     Math.atan(double) took 0.766 s
Loop on FastMath.atan(double) took 0.167

--- testing sqrt(double) ---
Loop on     Math.sqrt(double), args in [0.0,10.0], took 0.095 s
Loop on FastMath.sqrt(double), args in [0.0,10.0], took 0.097 s
Loop on     Math.sqrt(double), args in [0.0,1.0E12], took 0.109 s
Loop on FastMath.sqrt(double), args in [0.0,1.0E12], took 0.093 s
Loop on     Math.sqrt(double), args in all magnitudes (>=0), took 0.091 s
Loop on FastMath.sqrt(double), args in all magnitudes (>=0), took 0.092

--- testing cbrt(double) ---
Loop on     Math.cbrt(double), args in [-10.0,10.0], took 1.152 s
Loop on FastMath.cbrt(double), args in [-10.0,10.0], took 0.195 s
Loop on     Math.cbrt(double), args in [-1.0E12,1.0E12], took 1.153 s
Loop on FastMath.cbrt(double), args in [-1.0E12,1.0E12], took 0.193 s
Loop on     Math.cbrt(double), args in all magnitudes, took 1.154 s
Loop on FastMath.cbrt(double), args in all magnitudes, took 0.272

--- testing cbrt(double) = pow(double, 1/3) ---
Loop on     Math.pow(double, 1/3), args in [-10.0,10.0], took 0.739 s
Loop on FastMath.cbrt(double), args in [-10.0,10.0], took 0.166 s
Loop on     Math.pow(double, 1/3), args in [-0.7,0.7], took 0.746 s
Loop on FastMath.cbrt(double), args in [-0.7,0.7], took 0.166 s
Loop on     Math.pow(double, 1/3), args in [-0.1,0.1], took 0.742 s
Loop on FastMath.cbrt(double), args in [-0.1,0.1], took 0.165 s
Loop on     Math.pow(double, 1/3), args in all magnitudes, took 0.753 s
Loop on FastMath.cbrt(double), args in all magnitudes, took 0.244

Conclusion:
- acos / asin / atan functions are quite slow: it confirms these are not
optimized by hotspot intrinsics.

- cbrt() is slower than sqrt() : 1.1s vs 0.1 => 10x slower
- cbrt() is slower than pow(1/3) : 1.1s vs 0.7s => 50% slower

Any plan to enhance these specific math operations ?

Laurent


2017-11-09 14:33 GMT+01:00 Laurent Bourg?s <bourges.laurent at gmail.com>:

> I checked in the latest jdk master and both cbrt / acos are NOT intrinsics.
>
> However, cbrt(x) = pow(x, 1/3) so it may be optmized...
>
> Could someone tell me how cbrt() is concretely implemented ?
>
> In native libfdm, there is no e_cbrt.c !
>
> Thanks for your help,
> Laurent
>
> Le 9 nov. 2017 10:52 AM, "Jonas Konrad" <me at yawk.at> a ?crit :
>
>> Hey,
>>
>> Most functions in the Math class are intrinsic (
>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/
>> share/vm/classfile/vmSymbols.hpp#l664 ) and will use native instructions
>> where available. You can also test this yourself using jitwatch. There is
>> no native call overhead.
>>
>> The standard library does not currently include less accurate but faster
>> Math functions, maybe someone else can answer if that is something to be
>> considered.
>>
>> - Jonas Konrad
>>
>> On 11/09/2017 10:00 AM, Laurent Bourg?s wrote:
>>
>>> Hi,
>>>
>>> The Marlin renderer (JEP265) uses few Math functions: sqrt, cbrt, acos...
>>>
>>> Could you check if the current JDK uses C2 intrinsics or libfdm (native /
>>> JNI overhead?) and tell me if such functions are already highly optimized
>>> in jdk9 or 10 ?
>>>
>>> Some people have implemented their own fast Math like Apache Commons Math
>>> or JaFaMa libraries that are 10x faster for acos / cbrt.
>>>
>>> I wonder if I should implement my own cbrt function (cubics) in pure java
>>> as I do not need the highest accuracy but SPEED.
>>>
>>> Would it sound possible to have a JDK FastMath public API (lots faster
>>> but
>>> less accurate?)
>>>
>>> Do you know if recent CPU (intel?) have dedicated instructions for such
>>> math operations ?
>>> Why not use it instead?
>>> Maybe that's part of the new Vectorization API (panama) ?
>>>
>>> Cheers,
>>> Laurent Bourges
>>>
>>>


-- 
-- 
Laurent Bourg?s

From daniel.fuchs at oracle.com  Thu Nov  9 15:09:56 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 Nov 2017 15:09:56 +0000
Subject: Change in properties for logging: deliberate?
In-Reply-To: <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
 <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
Message-ID: <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>

Sorry Jeremy,

I think I misread your issue.

The issue is that .handlers=X behaves differently than handlers=X
I'm afraid I might have introduced this regression with
https://bugs.openjdk.java.net/browse/JDK-8033661 :-(

The obvious workaround for now would be to use
handlers=
as documented in the logging.properties file.

For compatibility reasons then I think we unfortunately
must continue to support ".handlers" as well, if that
used to work in 8.

I logged https://bugs.openjdk.java.net/browse/JDK-8191033

best regards,

-- daniel


On 09/11/2017 12:36, Daniel Fuchs wrote:
> Hi Jeremy,
> 
> Which jdk version/distribution are you using?
> 
> I see .level = INFO in the jdk9/master sources:
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.logging/share/conf/logging.properties 
> 
> 
> There should be no changes WRT the default level between 8 and 9.
> 
> best regards,
> 
> -- daniel
> 
> On 09/11/2017 01:09, Jeremy Manson wrote:
>> Hey folks,
>>
>> I can't find reference to this in a relnote, so I thought I would 
>> ask.? If
>> we have the following files:
>>
>> logging.properties:
>>
>> # Set the level of the root logger
>> .level = INFO
>>
>> # Send the root logger's output to the console
>> .handlers = java.util.logging.ConsoleHandler
>>
>> Test.java:
>> public class Test {
>> ?? public static void main(String[] args) {
>> ???? java.util.logging.Logger.getAnonymousLogger().info("Hi!");
>> ?? }
>> }
>>
>> In Java 8, we will see console output, and in Java 9, we won't.
>>
>> # Java 8
>> $ java -Djava.util.logging.config.file=logging.properties Test
>> Nov 08, 2017 5:02:05 PM Test main
>> INFO: Hi!
>>
>> # Java 9
>> $ java -Djava.util.logging.config.file=logging.properties Test
>>
>>
>> I thought that, perhaps, a decision was made to have the empty string no
>> longer mean the root logger, so I took it off of .handlers:
>>
>> logging.properties:
>>
>> # Set the level of the root logger
>> .level = INFO
>>
>> # Send the root logger's output to the console
>> handlers = java.util.logging.ConsoleHandler
>>
>> Success in the sense that this got me output in Java 9.? However, .level
>> still seems to work; if I then have:
>>
>> # Set the level of the root logger
>> .level = WARNING
>>
>> # Send the root logger's output to the console
>> handlers = java.util.logging.ConsoleHandler
>>
>> it sets the root logger's level to WARNING.
>>
>> I don't see any of this in a relnote anywhere, and I don't see an obvious
>> bug about it anywhere.? There seem to have been a fair few changes to
>> java.util.logging in Java 9.? Was a documented decision made to have
>> .handlers stop meaning handlers on the root logger, but to allow 
>> .level to
>> continue meaning level on the root logger?? Or do I just have the 
>> wrong end
>> of the stick on this?
>>
>> Thanks!
>>
>> Jeremy
>>
> 


From patrick at reini.net  Thu Nov  9 15:37:26 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 9 Nov 2017 16:37:26 +0100
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
 <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
 <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>
Message-ID: <8167AB26-7918-4920-A889-4FB2F2254BE5@reini.net>

Finally did some review with Alan and integrated all into this webrev:

http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.01 <http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.01>

-Patrick

> Am 08.11.2017 um 00:03 schrieb Brian Burkhalter <brian.burkhalter at oracle.com>:
> 
> Hi Patrick,
> 
> On Nov 7, 2017, at 3:01 PM, Patrick Reinhart <patrick at reini.net <mailto:patrick at reini.net>> wrote:
> 
>> I integrated your changes into my current version which I will look into tomorrow with Alan at Devoxx. I think adding some implementation note on the default method implementation will be needed to review later on?
> 
> I concur.
> 
>> I also made an override on the CharBuffer, where we need to add a enhanced documentation for the specialties around the CharBuffer implementations (BufferOverflowException/ReadOnlyBufferException), where a review of some native english speakers would help :-)
> 
> Sounds good!
> 
> Thanks,
> 
> Brian


From aph at redhat.com  Thu Nov  9 15:59:13 2017
From: aph at redhat.com (Andrew Haley)
Date: Thu, 9 Nov 2017 15:59:13 +0000
Subject: Faster Math ?
In-Reply-To: <CAKjRUT4ZGrpDm1QUF=PWtzxib3pJ1LVfVYBDpi7Dc4RCzeJqWw@mail.gmail.com>
References: <CAKjRUT7V1swPZJkEJKOtde-vZQgvAOg=_=uA-e9t+Z+QySMoVQ@mail.gmail.com>
 <CAKjRUT46GRnUqNgD-s81z_qYd0-_Rj-VQUgtVsMSUMKfHqJOxw@mail.gmail.com>
 <CAKjRUT5Ltn=4URTR2NXDgFis=b9s6e2TJS-FCK5qqqeyAXswuA@mail.gmail.com>
 <CAKjRUT7XkZevTau--k8avcUX6KE_bZmgRwJaGSx-2rt=Nz-4=Q@mail.gmail.com>
 <CAKjRUT668ng+Xh08a4VzJt4vPceuQp4VyOuRF2X=nZK+R4RHzw@mail.gmail.com>
 <CAKjRUT7K0evbnjY0ixzhMB54MEXiJxCkW4es_C1vLJ-hWywCaA@mail.gmail.com>
 <CAKjRUT6sbq8GoPLfZUtirvSX7okWSW+xOQ5B=rggOkYJ889PYQ@mail.gmail.com>
 <CAKjRUT48TpyU8XgHNewSu7Vt_GKMOS3-D7sKa6VuGTiNPERaSA@mail.gmail.com>
 <CAKjRUT6i8iSF07USPhY=jTPU5dc4g7rNn9WuA+DHRQioMS=1og@mail.gmail.com>
 <CAKjRUT4ezaSE5mPMNfXQaQfgu+3Y34+O1yBTvnbJ6Rmv+mkUyw@mail.gmail.com>
 <CAKjRUT4iFEZ1p-OLYAOiyKVmiTGLSPN0-HJVRwLGboxqgv4xkA@mail.gmail.com>
 <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>
 <39a39ddd-7ef7-3e48-fb56-1ce293a8a0a9@yawk.at>
 <CAKjRUT4ZGrpDm1QUF=PWtzxib3pJ1LVfVYBDpi7Dc4RCzeJqWw@mail.gmail.com>
Message-ID: <11d1b098-27eb-5f6a-5aa4-a9eb9fe41689@redhat.com>

On 09/11/17 13:33, Laurent Bourg?s wrote:
> I checked in the latest jdk master and both cbrt / acos are NOT intrinsics.
> 
> However, cbrt(x) = pow(x, 1/3) so it may be optmized...
> 
> Could someone tell me how cbrt() is concretely implemented ?

It's in FdLibm.java.  It's not great, but it's better than it used to be
now that it's not a native call.  I'm seeing that it's twice as fast as
the previous native implementation.

> In native libfdm, there is no e_cbrt.c !

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Thu Nov  9 16:08:00 2017
From: aph at redhat.com (Andrew Haley)
Date: Thu, 9 Nov 2017 16:08:00 +0000
Subject: Faster Math ?
In-Reply-To: <CAKjRUT7k-ZCAt8uwc0ZLg8OE4xgDHTcC+nJbzNv+R72xQP=9yQ@mail.gmail.com>
References: <CAKjRUT7V1swPZJkEJKOtde-vZQgvAOg=_=uA-e9t+Z+QySMoVQ@mail.gmail.com>
 <CAKjRUT5Ltn=4URTR2NXDgFis=b9s6e2TJS-FCK5qqqeyAXswuA@mail.gmail.com>
 <CAKjRUT7XkZevTau--k8avcUX6KE_bZmgRwJaGSx-2rt=Nz-4=Q@mail.gmail.com>
 <CAKjRUT668ng+Xh08a4VzJt4vPceuQp4VyOuRF2X=nZK+R4RHzw@mail.gmail.com>
 <CAKjRUT7K0evbnjY0ixzhMB54MEXiJxCkW4es_C1vLJ-hWywCaA@mail.gmail.com>
 <CAKjRUT6sbq8GoPLfZUtirvSX7okWSW+xOQ5B=rggOkYJ889PYQ@mail.gmail.com>
 <CAKjRUT48TpyU8XgHNewSu7Vt_GKMOS3-D7sKa6VuGTiNPERaSA@mail.gmail.com>
 <CAKjRUT6i8iSF07USPhY=jTPU5dc4g7rNn9WuA+DHRQioMS=1og@mail.gmail.com>
 <CAKjRUT4ezaSE5mPMNfXQaQfgu+3Y34+O1yBTvnbJ6Rmv+mkUyw@mail.gmail.com>
 <CAKjRUT4iFEZ1p-OLYAOiyKVmiTGLSPN0-HJVRwLGboxqgv4xkA@mail.gmail.com>
 <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>
 <39a39ddd-7ef7-3e48-fb56-1ce293a8a0a9@yawk.at>
 <CAKjRUT4ZGrpDm1QUF=PWtzxib3pJ1LVfVYBDpi7Dc4RCzeJqWw@mail.gmail.com>
 <CAKjRUT7k-ZCAt8uwc0ZLg8OE4xgDHTcC+nJbzNv+R72xQP=9yQ@mail.gmail.com>
Message-ID: <0d279402-9865-b879-71fe-cecdb27375ca@redhat.com>

On 09/11/17 15:02, Laurent Bourg?s wrote:
> --- testing cbrt(double) = pow(double, 1/3) ---
> Loop on     Math.pow(double, 1/3), args in [-10.0,10.0], took 0.739 s
> Loop on FastMath.cbrt(double), args in [-10.0,10.0], took 0.166 s
> Loop on     Math.pow(double, 1/3), args in [-0.7,0.7], took 0.746 s
> Loop on FastMath.cbrt(double), args in [-0.7,0.7], took 0.166 s
> Loop on     Math.pow(double, 1/3), args in [-0.1,0.1], took 0.742 s
> Loop on FastMath.cbrt(double), args in [-0.1,0.1], took 0.165 s
> Loop on     Math.pow(double, 1/3), args in all magnitudes, took 0.753 s
> Loop on FastMath.cbrt(double), args in all magnitudes, took 0.244
> 
> Conclusion:
> - acos / asin / atan functions are quite slow: it confirms these are not
> optimized by hotspot intrinsics.
> 
> - cbrt() is slower than sqrt() : 1.1s vs 0.1 => 10x slower
> - cbrt() is slower than pow(1/3) : 1.1s vs 0.7s => 50% slower

No.  cbrt() is faster than pow(1/3) : 0.24 vs 0.75

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From paul.sandoz at oracle.com  Thu Nov  9 16:30:42 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 9 Nov 2017 08:30:42 -0800
Subject: RFR 8190974 Parallel stream execution within a custom
 ForkJoinPool should obey the parallelism
In-Reply-To: <CA+kOe08xj1DzjarnxYwn80QEd0YAp5g+HPoRcPeQLZyfnHQArg@mail.gmail.com>
References: <CFFC012D-28A8-4CEB-853E-ACE60041C4FA@oracle.com>
 <CA+kOe0-cnk8_s7SuA=uMw5E_iKWw-1BdHopnK+_KHGKD0w4mJw@mail.gmail.com>
 <8445A78E-A5EE-4266-ACC2-520499398D5F@oracle.com>
 <CA+kOe08xj1DzjarnxYwn80QEd0YAp5g+HPoRcPeQLZyfnHQArg@mail.gmail.com>
Message-ID: <2AE22876-BE92-42B7-A49E-90D74B451C05@oracle.com>


> On 8 Nov 2017, at 18:44, Martin Buchholz <martinrb at google.com> wrote:
> 
> Looks good, but have comments as always.
> 
> Fix type: exection
> 
> Unrelated typo: the this slice spliterator
> 

Fixed.

Thanks,
Paul.

> I would test core libraries under taskset with an odd number of cpus
> 




From paul.sandoz at oracle.com  Thu Nov  9 17:19:32 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 9 Nov 2017 09:19:32 -0800
Subject: Faster Math ?
In-Reply-To: <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>
References: <CAKjRUT7V1swPZJkEJKOtde-vZQgvAOg=_=uA-e9t+Z+QySMoVQ@mail.gmail.com>
 <CAKjRUT5RjVW_FYfSVJ4N4U-g7E7yHASRYMNdw1LV0czRi1WT3g@mail.gmail.com>
 <CAKjRUT6EWLiVka04exEQzgDLsF_Bu-ihbKBuHKr-r7sh843zeA@mail.gmail.com>
 <CAKjRUT40h-VFb63biagg0PM-pOctbPN_6fCW1GMLWY0SsyDtkg@mail.gmail.com>
 <CAKjRUT7d5ABHmmq9JS4SQVegDxGvaaqeEise0=Fz3w24HZHFRg@mail.gmail.com>
 <CAKjRUT7xXu4qCTJQjq+FRNPHFE+QRJ4AoAcTo-BobtKps3GwNw@mail.gmail.com>
 <CAKjRUT7Xo2FX9zsu-s-mVCzGBbi_qBRxGi9s7YFUK-42zSOJbw@mail.gmail.com>
 <CAKjRUT42-j3D8phr6f5ZDZPU59526gUwY-t4PoLVb6YTe+=mBA@mail.gmail.com>
 <CAKjRUT6LRph5iDZramw72RqNTByE-AXT5vzzsQ5n07rSF20WPQ@mail.gmail.com>
 <CAKjRUT5fT_Y6xijmXJW=G2oJpoKhFMYX2iiOW90K7N8f5mPmuA@mail.gmail.com>
 <CAKjRUT653G1i6vzzZDh5enMB8_7HoQiHaxRSn58oXz6iUcGJ2g@mail.gmail.com>
 <CAKjRUT7ti7ZOD2RGzgL4QpSAwbfoLUL15E2MiAqGxbhCJSm3jA@mail.gmail.com>
 <CAKjRUT7wdnuGnX=n4YA0TnQuCe98tHorCBqAvhFbAFS=W1+4ag@mail.gmail.com>
 <CAKjRUT4j-R60NpCmEcs+x5-whmobyvBcAHSqecaH6PFG_NzaZA@mail.gmail.com>
 <CAKjRUT46GRnUqNgD-s81z_qYd0-_Rj-VQUgtVsMSUMKfHqJOxw@mail.gmail.com>
 <CAKjRUT5Ltn=4URTR2NXDgFis=b9s6e2TJS-FCK5qqqeyAXswuA@mail.gmail.com>
 <CAKjRUT7XkZevTau--k8avcUX6KE_bZmgRwJaGSx-2rt=Nz-4=Q@mail.gmail.com>
 <CAKjRUT668ng+Xh08a4VzJt4vPceuQp4VyOuRF2X=nZK+R4RHzw@mail.gmail.com>
 <CAKjRUT7K0evbnjY0ixzhMB54MEXiJxCkW4es_C1vLJ-hWywCaA@mail.gmail.com>
 <CAKjRUT6sbq8GoPLfZUtirvSX7okWSW+xOQ5B=rggOkYJ889PYQ@mail.gmail.com>
 <CAKjRUT48TpyU8XgHNewSu7Vt_GKMOS3-D7sKa6VuGTiNPERaSA@mail.gmail.com>
 <CAKjRUT6i8iSF07USPhY=jTPU5dc4g7rNn9WuA+DHRQioMS=1og@mail.gmail.com>
 <CAKjRUT4ezaSE5mPMNfXQaQfgu+3Y34+O1yBTvnbJ6Rmv+mkUyw@mail.gmail.com>
 <CAKjRUT4iFEZ1p-OLYAOiyKVmiTGLSPN0-HJVRwLGboxqgv4xkA@mail.gmail.com>
 <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>
Message-ID: <06AB6270-7489-41CE-B82F-668C582C9D41@oracle.com>

Hi Laurent,

A Java method is a candidate for intrinsification if it is annotated with @HotSpotIntrinsicCandidate. When running Java code you can also use the HotSpot flags -XX:+PrintCompilarion -XX:+PrintInlining to show methods that are intrinsic (JIT watch, as mentioned, is also excellent in this regard).

I recommend cloning OpenJDK and browsing the source.

Some of the math functions are intrinsic in the interpreter and all the runtime compilers to ensure consistent results across interpretation and compilation.

Work was done by Intel to improve many of the math functions. See:

  Update for x86 sin and cos in the math lib
  https://bugs.openjdk.java.net/browse/JDK-8143353

  Update for x86 pow in the math lib
  https://bugs.openjdk.java.net/browse/JDK-8145688
  
  (From these you can track related issues.)

Other Math functions are not intrinsic like cbrt (non-native) and acos (native). There is ongoing work to turn native implementations into Java implementations (i don?t know if there would be any follow up on intrinsification).

  https://bugs.openjdk.java.net/browse/JDK-8134780
  https://bugs.openjdk.java.net/browse/JDK-8171407

Joe knows more.

?

As part of the Vector API effort we will likely need to investigate the support for less accurate but faster math functions. It?s too early to tell if something like a FastMath class will pop out of that, but FWIW i am sympathetic to that :-)

I liked this tweet:

https://twitter.com/FioraAeterna/status/926150700836405248

  life as a gpu compiler dev is basically just fielding repeated complaints that 
  "fast math" isn't precise and "precise math" isn't fast

as an indication of what we could be getting into :-)

Paul.

> On 9 Nov 2017, at 01:00, Laurent Bourg?s <bourges.laurent at gmail.com> wrote:
> 
> Hi,
> 
> The Marlin renderer (JEP265) uses few Math functions: sqrt, cbrt, acos...
> 
> Could you check if the current JDK uses C2 intrinsics or libfdm (native /
> JNI overhead?) and tell me if such functions are already highly optimized
> in jdk9 or 10 ?
> 
> Some people have implemented their own fast Math like Apache Commons Math
> or JaFaMa libraries that are 10x faster for acos / cbrt.
> 
> I wonder if I should implement my own cbrt function (cubics) in pure java
> as I do not need the highest accuracy but SPEED.
> 
> Would it sound possible to have a JDK FastMath public API (lots faster but
> less accurate?)
> 
> Do you know if recent CPU (intel?) have dedicated instructions for such
> math operations ?
> Why not use it instead?
> Maybe that's part of the new Vectorization API (panama) ?
> 
> Cheers,
> Laurent Bourges


From bourges.laurent at gmail.com  Thu Nov  9 17:24:04 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 9 Nov 2017 18:24:04 +0100
Subject: Faster Math ?
In-Reply-To: <0d279402-9865-b879-71fe-cecdb27375ca@redhat.com>
References: <CAKjRUT7V1swPZJkEJKOtde-vZQgvAOg=_=uA-e9t+Z+QySMoVQ@mail.gmail.com>
 <CAKjRUT5Ltn=4URTR2NXDgFis=b9s6e2TJS-FCK5qqqeyAXswuA@mail.gmail.com>
 <CAKjRUT7XkZevTau--k8avcUX6KE_bZmgRwJaGSx-2rt=Nz-4=Q@mail.gmail.com>
 <CAKjRUT668ng+Xh08a4VzJt4vPceuQp4VyOuRF2X=nZK+R4RHzw@mail.gmail.com>
 <CAKjRUT7K0evbnjY0ixzhMB54MEXiJxCkW4es_C1vLJ-hWywCaA@mail.gmail.com>
 <CAKjRUT6sbq8GoPLfZUtirvSX7okWSW+xOQ5B=rggOkYJ889PYQ@mail.gmail.com>
 <CAKjRUT48TpyU8XgHNewSu7Vt_GKMOS3-D7sKa6VuGTiNPERaSA@mail.gmail.com>
 <CAKjRUT6i8iSF07USPhY=jTPU5dc4g7rNn9WuA+DHRQioMS=1og@mail.gmail.com>
 <CAKjRUT4ezaSE5mPMNfXQaQfgu+3Y34+O1yBTvnbJ6Rmv+mkUyw@mail.gmail.com>
 <CAKjRUT4iFEZ1p-OLYAOiyKVmiTGLSPN0-HJVRwLGboxqgv4xkA@mail.gmail.com>
 <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>
 <39a39ddd-7ef7-3e48-fb56-1ce293a8a0a9@yawk.at>
 <CAKjRUT4ZGrpDm1QUF=PWtzxib3pJ1LVfVYBDpi7Dc4RCzeJqWw@mail.gmail.com>
 <CAKjRUT7k-ZCAt8uwc0ZLg8OE4xgDHTcC+nJbzNv+R72xQP=9yQ@mail.gmail.com>
 <0d279402-9865-b879-71fe-cecdb27375ca@redhat.com>
Message-ID: <CAKjRUT4LP0Bf0vu1sRNiQLfh8kBzxwVEP9xOjLE40iLWMRKW1g@mail.gmail.com>

Thanks, andrew.

I searched on the web and I understand now:
Fdlibm native library has been ported in Java code for jdk9 (like the
jafama library).

Cbrt changeset:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7dc9726cfa82

I will anyway compare jdk9 with latest jafama 2.2 to have an up-to-date
comparison.

Does somebody else need a faster but less accurate math library ?
JaFaMa has such alternative methods...

Preserving double-precision may be very costly in terms of performance and
sometimes such accuracy is not required.

Last question:
Is there a sin & cos function returning both values for the same angle ?
It is very useful to compute exact fourrier transform...
It is called sinAndCos(double wrappers) in jafama.

Cheers,
Laurent

Le 9 nov. 2017 17:08, "Andrew Haley" <aph at redhat.com> a ?crit :

> On 09/11/17 15:02, Laurent Bourg?s wrote:
> > --- testing cbrt(double) = pow(double, 1/3) ---
> > Loop on     Math.pow(double, 1/3), args in [-10.0,10.0], took 0.739 s
> > Loop on FastMath.cbrt(double), args in [-10.0,10.0], took 0.166 s
> > Loop on     Math.pow(double, 1/3), args in [-0.7,0.7], took 0.746 s
> > Loop on FastMath.cbrt(double), args in [-0.7,0.7], took 0.166 s
> > Loop on     Math.pow(double, 1/3), args in [-0.1,0.1], took 0.742 s
> > Loop on FastMath.cbrt(double), args in [-0.1,0.1], took 0.165 s
> > Loop on     Math.pow(double, 1/3), args in all magnitudes, took 0.753 s
> > Loop on FastMath.cbrt(double), args in all magnitudes, took 0.244
> >
> > Conclusion:
> > - acos / asin / atan functions are quite slow: it confirms these are not
> > optimized by hotspot intrinsics.
> >
> > - cbrt() is slower than sqrt() : 1.1s vs 0.1 => 10x slower
> > - cbrt() is slower than pow(1/3) : 1.1s vs 0.7s => 50% slower
>
> No.  cbrt() is faster than pow(1/3) : 0.24 vs 0.75
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>

From mandy.chung at oracle.com  Thu Nov  9 17:41:02 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 9 Nov 2017 09:41:02 -0800
Subject: RFR: 8189953: FileHandler constructor throws NoSuchFileException
 with absolute path
In-Reply-To: <0513b8d0-ab37-7700-6d06-2b5e0f574f45@oracle.com>
References: <0513b8d0-ab37-7700-6d06-2b5e0f574f45@oracle.com>
Message-ID: <97d57d22-b4f0-aa74-079b-9aad0032d3f0@oracle.com>

Hi Daniel,

On 11/2/17 9:47 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch for:
> 8189953: FileHandler constructor throws NoSuchFileException
> ???????? with absolute path
> https://bugs.openjdk.java.net/browse/JDK-8189953
>
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8189953/webrev.00/
>
This looks okay.

A minor comment: I think line 695-709 can be made cleaner and easier to 
read and

e.g.

if (word.length() >0) {
     String n = word.toString();
     if (result ==null) {
         result = prev !=null ? prev.resolveSibling(n) : Paths.get(n);
     }else {
         Path p = prev !=null ? prev.resolveSibling(n) : Paths.get(n);
         result = result.resolve(p);
     }
}else if (result ==null) {
     result = Paths.get("");
}
if (path.getRoot() ==null)
     return result.toFile();
else return path.getRoot().resolve(result).toFile();


Mandy

From jeremymanson at google.com  Thu Nov  9 17:42:18 2017
From: jeremymanson at google.com (Jeremy Manson)
Date: Thu, 9 Nov 2017 09:42:18 -0800
Subject: Change in properties for logging: deliberate?
In-Reply-To: <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
 <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
 <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>
Message-ID: <CAPYFHW0zNys6RwDLrCdw31oWbL7dZiHou7cMqXQSF5E5xk6Oug@mail.gmail.com>

Thanks, Daniel.  That is the issue.  I probably should have described it
more clearly.

Do you have a sense of a fix timeline?  If there is a relatively prompt
fix, I can backport it to our internal build instead of introducing churn
in our many, many logging configuration files.  If it is likely to be a
long time, I'll go ahead and change the logging configs.

Jeremy

On Thu, Nov 9, 2017 at 7:09 AM, Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Sorry Jeremy,
>
> I think I misread your issue.
>
> The issue is that .handlers=X behaves differently than handlers=X
> I'm afraid I might have introduced this regression with
> https://bugs.openjdk.java.net/browse/JDK-8033661 :-(
>
> The obvious workaround for now would be to use
> handlers=
> as documented in the logging.properties file.
>
> For compatibility reasons then I think we unfortunately
> must continue to support ".handlers" as well, if that
> used to work in 8.
>
> I logged https://bugs.openjdk.java.net/browse/JDK-8191033
>
> best regards,
>
> -- daniel
>
>
>
> On 09/11/2017 12:36, Daniel Fuchs wrote:
>
>> Hi Jeremy,
>>
>> Which jdk version/distribution are you using?
>>
>> I see .level = INFO in the jdk9/master sources:
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/java.
>> logging/share/conf/logging.properties
>>
>> There should be no changes WRT the default level between 8 and 9.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 09/11/2017 01:09, Jeremy Manson wrote:
>>
>>> Hey folks,
>>>
>>> I can't find reference to this in a relnote, so I thought I would ask.
>>> If
>>> we have the following files:
>>>
>>> logging.properties:
>>>
>>> # Set the level of the root logger
>>> .level = INFO
>>>
>>> # Send the root logger's output to the console
>>> .handlers = java.util.logging.ConsoleHandler
>>>
>>> Test.java:
>>> public class Test {
>>>    public static void main(String[] args) {
>>>      java.util.logging.Logger.getAnonymousLogger().info("Hi!");
>>>    }
>>> }
>>>
>>> In Java 8, we will see console output, and in Java 9, we won't.
>>>
>>> # Java 8
>>> $ java -Djava.util.logging.config.file=logging.properties Test
>>> Nov 08, 2017 5:02:05 PM Test main
>>> INFO: Hi!
>>>
>>> # Java 9
>>> $ java -Djava.util.logging.config.file=logging.properties Test
>>>
>>>
>>> I thought that, perhaps, a decision was made to have the empty string no
>>> longer mean the root logger, so I took it off of .handlers:
>>>
>>> logging.properties:
>>>
>>> # Set the level of the root logger
>>> .level = INFO
>>>
>>> # Send the root logger's output to the console
>>> handlers = java.util.logging.ConsoleHandler
>>>
>>> Success in the sense that this got me output in Java 9.  However, .level
>>> still seems to work; if I then have:
>>>
>>> # Set the level of the root logger
>>> .level = WARNING
>>>
>>> # Send the root logger's output to the console
>>> handlers = java.util.logging.ConsoleHandler
>>>
>>> it sets the root logger's level to WARNING.
>>>
>>> I don't see any of this in a relnote anywhere, and I don't see an obvious
>>> bug about it anywhere.  There seem to have been a fair few changes to
>>> java.util.logging in Java 9.  Was a documented decision made to have
>>> .handlers stop meaning handlers on the root logger, but to allow .level
>>> to
>>> continue meaning level on the root logger?  Or do I just have the wrong
>>> end
>>> of the stick on this?
>>>
>>> Thanks!
>>>
>>> Jeremy
>>>
>>>
>>
>

From daniel.fuchs at oracle.com  Thu Nov  9 17:48:40 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 Nov 2017 17:48:40 +0000
Subject: Change in properties for logging: deliberate?
In-Reply-To: <CAPYFHW0zNys6RwDLrCdw31oWbL7dZiHou7cMqXQSF5E5xk6Oug@mail.gmail.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
 <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
 <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>
 <CAPYFHW0zNys6RwDLrCdw31oWbL7dZiHou7cMqXQSF5E5xk6Oug@mail.gmail.com>
Message-ID: <59156c8a-8622-99b9-7a2f-b0c161868b4f@oracle.com>

Hi Jeremy,

I'm afraid I don't have a timeline at this point, but I will
try having a look at the issue in the next couple of days.

best regards,

-- daniel

On 09/11/2017 17:42, Jeremy Manson wrote:
> Thanks, Daniel.? That is the issue.? I probably should have described it 
> more clearly.
> 
> Do you have a sense of a fix timeline?? If there is a relatively prompt 
> fix, I can backport it to our internal build instead of introducing 
> churn in our many, many logging configuration files.? If it is likely to 
> be a long time, I'll go ahead and change the logging configs.
> 
> Jeremy

From bourges.laurent at gmail.com  Thu Nov  9 18:30:36 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 9 Nov 2017 19:30:36 +0100
Subject: Faster Math ?
In-Reply-To: <06AB6270-7489-41CE-B82F-668C582C9D41@oracle.com>
References: <CAKjRUT7V1swPZJkEJKOtde-vZQgvAOg=_=uA-e9t+Z+QySMoVQ@mail.gmail.com>
 <CAKjRUT5RjVW_FYfSVJ4N4U-g7E7yHASRYMNdw1LV0czRi1WT3g@mail.gmail.com>
 <CAKjRUT6EWLiVka04exEQzgDLsF_Bu-ihbKBuHKr-r7sh843zeA@mail.gmail.com>
 <CAKjRUT40h-VFb63biagg0PM-pOctbPN_6fCW1GMLWY0SsyDtkg@mail.gmail.com>
 <CAKjRUT7d5ABHmmq9JS4SQVegDxGvaaqeEise0=Fz3w24HZHFRg@mail.gmail.com>
 <CAKjRUT7xXu4qCTJQjq+FRNPHFE+QRJ4AoAcTo-BobtKps3GwNw@mail.gmail.com>
 <CAKjRUT7Xo2FX9zsu-s-mVCzGBbi_qBRxGi9s7YFUK-42zSOJbw@mail.gmail.com>
 <CAKjRUT42-j3D8phr6f5ZDZPU59526gUwY-t4PoLVb6YTe+=mBA@mail.gmail.com>
 <CAKjRUT6LRph5iDZramw72RqNTByE-AXT5vzzsQ5n07rSF20WPQ@mail.gmail.com>
 <CAKjRUT5fT_Y6xijmXJW=G2oJpoKhFMYX2iiOW90K7N8f5mPmuA@mail.gmail.com>
 <CAKjRUT653G1i6vzzZDh5enMB8_7HoQiHaxRSn58oXz6iUcGJ2g@mail.gmail.com>
 <CAKjRUT7ti7ZOD2RGzgL4QpSAwbfoLUL15E2MiAqGxbhCJSm3jA@mail.gmail.com>
 <CAKjRUT7wdnuGnX=n4YA0TnQuCe98tHorCBqAvhFbAFS=W1+4ag@mail.gmail.com>
 <CAKjRUT4j-R60NpCmEcs+x5-whmobyvBcAHSqecaH6PFG_NzaZA@mail.gmail.com>
 <CAKjRUT46GRnUqNgD-s81z_qYd0-_Rj-VQUgtVsMSUMKfHqJOxw@mail.gmail.com>
 <CAKjRUT5Ltn=4URTR2NXDgFis=b9s6e2TJS-FCK5qqqeyAXswuA@mail.gmail.com>
 <CAKjRUT7XkZevTau--k8avcUX6KE_bZmgRwJaGSx-2rt=Nz-4=Q@mail.gmail.com>
 <CAKjRUT668ng+Xh08a4VzJt4vPceuQp4VyOuRF2X=nZK+R4RHzw@mail.gmail.com>
 <CAKjRUT7K0evbnjY0ixzhMB54MEXiJxCkW4es_C1vLJ-hWywCaA@mail.gmail.com>
 <CAKjRUT6sbq8GoPLfZUtirvSX7okWSW+xOQ5B=rggOkYJ889PYQ@mail.gmail.com>
 <CAKjRUT48TpyU8XgHNewSu7Vt_GKMOS3-D7sKa6VuGTiNPERaSA@mail.gmail.com>
 <CAKjRUT6i8iSF07USPhY=jTPU5dc4g7rNn9WuA+DHRQioMS=1og@mail.gmail.com>
 <CAKjRUT4ezaSE5mPMNfXQaQfgu+3Y34+O1yBTvnbJ6Rmv+mkUyw@mail.gmail.com>
 <CAKjRUT4iFEZ1p-OLYAOiyKVmiTGLSPN0-HJVRwLGboxqgv4xkA@mail.gmail.com>
 <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>
 <06AB6270-7489-41CE-B82F-668C582C9D41@oracle.com>
Message-ID: <CAKjRUT68kw_E-qG7igsqkAjDrkeW7KgB1sDTG+iWV-TsajmDrg@mail.gmail.com>

Hi Paul,

Thank you so much for this complete summary !

I will still perform some benchmarks and could port acos native code into
java code as it is used by marlin.

Anyway I will backport the Cbrt java code into Marlin @ github for JDK8
users (GPL v2).

Thanks,
Laurent

Le 9 nov. 2017 18:19, "Paul Sandoz" <paul.sandoz at oracle.com> a ?crit :

> Hi Laurent,
>
> A Java method is a candidate for intrinsification if it is annotated with
> @HotSpotIntrinsicCandidate. When running Java code you can also use the
> HotSpot flags -XX:+PrintCompilarion -XX:+PrintInlining to show methods that
> are intrinsic (JIT watch, as mentioned, is also excellent in this regard).
>
> I recommend cloning OpenJDK and browsing the source.
>
> Some of the math functions are intrinsic in the interpreter and all the
> runtime compilers to ensure consistent results across interpretation and
> compilation.
>
> Work was done by Intel to improve many of the math functions. See:
>
>   Update for x86 sin and cos in the math lib
>   https://bugs.openjdk.java.net/browse/JDK-8143353
>
>   Update for x86 pow in the math lib
>   https://bugs.openjdk.java.net/browse/JDK-8145688
>
>   (From these you can track related issues.)
>
> Other Math functions are not intrinsic like cbrt (non-native) and acos
> (native). There is ongoing work to turn native implementations into Java
> implementations (i don?t know if there would be any follow up on
> intrinsification).
>
>   https://bugs.openjdk.java.net/browse/JDK-8134780
>   https://bugs.openjdk.java.net/browse/JDK-8171407
>
> Joe knows more.
>
> ?
>
> As part of the Vector API effort we will likely need to investigate the
> support for less accurate but faster math functions. It?s too early to tell
> if something like a FastMath class will pop out of that, but FWIW i am
> sympathetic to that :-)
>
> I liked this tweet:
>
> https://twitter.com/FioraAeterna/status/926150700836405248
>
>   life as a gpu compiler dev is basically just fielding repeated
> complaints that
>   "fast math" isn't precise and "precise math" isn't fast
>
> as an indication of what we could be getting into :-)
>
> Paul.
>
> > On 9 Nov 2017, at 01:00, Laurent Bourg?s <bourges.laurent at gmail.com>
> wrote:
> >
> > Hi,
> >
> > The Marlin renderer (JEP265) uses few Math functions: sqrt, cbrt, acos...
> >
> > Could you check if the current JDK uses C2 intrinsics or libfdm (native /
> > JNI overhead?) and tell me if such functions are already highly optimized
> > in jdk9 or 10 ?
> >
> > Some people have implemented their own fast Math like Apache Commons Math
> > or JaFaMa libraries that are 10x faster for acos / cbrt.
> >
> > I wonder if I should implement my own cbrt function (cubics) in pure java
> > as I do not need the highest accuracy but SPEED.
> >
> > Would it sound possible to have a JDK FastMath public API (lots faster
> but
> > less accurate?)
> >
> > Do you know if recent CPU (intel?) have dedicated instructions for such
> > math operations ?
> > Why not use it instead?
> > Maybe that's part of the new Vectorization API (panama) ?
> >
> > Cheers,
> > Laurent Bourges
>
>

From paul.sandoz at oracle.com  Thu Nov  9 18:43:28 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 9 Nov 2017 10:43:28 -0800
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com>
Message-ID: <26336F4F-0A21-4A08-AFA3-23CA972CAD93@oracle.com>

Hi,

> On 9 Nov 2017, at 00:24, stanislav lukyanov <stanislav.lukyanov at oracle.com> wrote:
> 
> Hi Paul,
> 
> How about changing the name of the class to ConstantFactory to align
> with its two siblings - LambdaMetafactory and StringConcatFactory?
> 

I would prefer to keep it as is. It is intended to cover many forms of BSMs producing dynamic constants. LMF and SCF are very focused and there is some precedent that they may be called explicitly as factories where as for dynamic constants there is less motivation for this.


> Other comments are purely about the spec text (should I be posting them in the CSR issue instead?)
> 
> The class-level javadoc could use more text to describe the contents
> (e.g. "Methods to facilitate creation of common kinds of dynamic constants...", similar to other bootstrap factories)
> and motivation for having this class. I think giving the motivation here is important - it might be not obvious why, for example,
> nullConstant is needed when there is aconst_null.
> Maybe an example of an invokedynamic using static arguments that are dynamic constants (repeat the last six words together BTW!)
> could also be there (javap- or jasm-style pseudocode for that?)

I would prefer to follow up later on with more non-normative explanatory text. It will take some careful crafting and i don?t want that to side-track the review for the moment (including guidance on what forms of computed constants are acceptable).


> Also, @author

We don?t add @author.


> and @since are missing.
> 

Added.


> All methods repeat the same NPE condition
>     @throws NullPointerException if any used argument is {@code null}
> which looks especially strange in methods with one used parameter (e.g. nullConstant)
> or with no unused parameters (e.g. getStaticFinal).
> I'd suggest to instead go with the commonly used shortcut of declaring the NPE in the class-level Javadoc, e.g.
>     "Passing a null argument to a method in this class will cause of NullPointerException to be thrown,
>       unless the argument is specified to be unused, or unless otherwise noted?.


I like that:

* <p>The bootstrap methods in this class will throw a
* {@code NullPointerException} for any reference argument that is {@code null},
* unless the argument is specified to be unused or specified to accept a
* {@code null} value.

And adjusted the invoke method:

* @param args the arguments to pass to the method handle, as if with
* {@link MethodHandle#invokeWithArguments}.  Each argument may be
* {@code null}.
...
* @throws NullPointerException if {@code args} is {@code null}
* (each argument of {@code args} may be {@code null}).

We have been fleshing out the NPE behaviour because we know you will log bugs against us later on if we don?t :-)


> The VarHandle methods have
>     @param type unused; must be {@code Class<VarHandle>}
> Looks like the "unused;" part should be removed.
> 

Updated to:

  * @param type the required result type (must be {@code Class<VarHandle>})

and added the null check.


> On 9 Nov 2017, at 00:42, stanislav lukyanov <stanislav.lukyanov at oracle.com> wrote:
> 
> I also noticed that Class::isPrimitive now says the following:
>     "These objects may only be accessed via the following public static final variables, and are the only Class objects for which this method returns true."
> (the fields its talking about are the <Box>.TYPE)
> Should this text be tweaked?

I think it would be a distraction for most developers. The BSM is doing nothing special in regard to what isPrimitive specifies it just dynamically returns the value of the associated static field.

Paul.

From paul.sandoz at oracle.com  Thu Nov  9 19:06:00 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 9 Nov 2017 11:06:00 -0800
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <CA+3eh11pz0dYhgtwd285xaj_We1ezn2Gw7XZmQ2FsHPLxvg4JA@mail.gmail.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com>
 <CA+3eh11pz0dYhgtwd285xaj_We1ezn2Gw7XZmQ2FsHPLxvg4JA@mail.gmail.com>
Message-ID: <D9A579D7-D93D-4BFF-BBA8-7C4766D9C9E8@oracle.com>

Hi Volker,

> On 9 Nov 2017, at 01:01, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> Hi Paul,
> 
> just some quick process-related questions.
> 
> Is this intended to be targeted for jdk 10?
> 

Yes, that?s what we are aiming for. I am front loading reviews ahead of a propose to target (which should hopefully happen soon) to make better use of time given the shorter cycles, thus increasing the quality and giving heads up to other developers like yourself who are responsible for other platforms.


> Is the current implementation already available in a separate
> repository and/or branch? I've read in the RFR for 8186046 that some
> parts are currently being refined in the amber repository. Or is the
> complete implementation already available there?
> 

A super set of functionality is present in the amber repo under the condy branch. We pealed a sub-set of that off and created patches for the idk/hs repo tracked in:

  Minimal ConstantDynamic support
  https://bugs.openjdk.java.net/browse/JDK-8186046
  Tool support for ConstantDynamic
  https://bugs.openjdk.java.net/browse/JDK-8186209
  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/

  Minimal set of bootstrap methods for dynamic constants
  https://bugs.openjdk.java.net/browse/JDK-8187742
  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/

While these are under review they might diverge a little from the condy branch in the amber repo but i will sync back up in batches.


> If I want to port this to ppc64, what's the best way to start and what
> do I need? Is it just the two webrevs for 8187742 and 8186046 on top
> of the jdk hs repo? Or is it a branch of the amber repo?
> 

Yes, and focus on the following applied to the jdk/hs repo:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/

There are tests in that patch that are currently targeted to run only on x86 that would otherwise tickle failures on other platforms.
 

> You may know that there's currently a discussion going on about what
> is a JEP and what's the right way to implement and integrate a JEP
> into the mainline. The general idea is that only 'finished' JEPs will
> be targeted and integrated into the always feature complete main line.
> So is this and the review for 8186046 about the integration into the
> jdk repo (which shouldn't happen before the JEP is not targeted for
> jdk10) or is it just the review before the JEP can actually be
> targeted? This is important because there's not much time before the
> jdk10 repos will enter Rampdown phase 1 and we would still have to
> port this to ppc (and also ARM/SPARC) if it will be targeted for jdk
> 10.
> 
> I don't want to question the merits and quality of the current
> implementation which I'm sure are great. For me as an external
> observer its just hard to oversee the current status of the
> implementation.
> 

I hear you, thanks for your patience. Is it a little clearer now?

From my own perspective this is the first flight over the new release cycle territory, the ride might be a little bumpy while we learn to pilot this better :-)

Paul.

From mandy.chung at oracle.com  Thu Nov  9 19:16:06 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 9 Nov 2017 11:16:06 -0800
Subject: Change in properties for logging: deliberate?
In-Reply-To: <59156c8a-8622-99b9-7a2f-b0c161868b4f@oracle.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
 <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
 <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>
 <CAPYFHW0zNys6RwDLrCdw31oWbL7dZiHou7cMqXQSF5E5xk6Oug@mail.gmail.com>
 <59156c8a-8622-99b9-7a2f-b0c161868b4f@oracle.com>
Message-ID: <5d3ffed1-6c0d-d2f2-a541-a82d5ed8ebd5@oracle.com>

Daniel - we should add this known issue in the release note and document 
the workaround.

Mandy

On 11/9/17 9:48 AM, Daniel Fuchs wrote:
> Hi Jeremy,
>
> I'm afraid I don't have a timeline at this point, but I will
> try having a look at the issue in the next couple of days.
>
> best regards,
>
> -- daniel
>
> On 09/11/2017 17:42, Jeremy Manson wrote:
>> Thanks, Daniel.? That is the issue.? I probably should have described 
>> it more clearly.
>>
>> Do you have a sense of a fix timeline?? If there is a relatively 
>> prompt fix, I can backport it to our internal build instead of 
>> introducing churn in our many, many logging configuration files.? If 
>> it is likely to be a long time, I'll go ahead and change the logging 
>> configs.
>>
>> Jeremy


From daniel.fuchs at oracle.com  Thu Nov  9 19:20:24 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 Nov 2017 19:20:24 +0000
Subject: RFR: 8189953: FileHandler constructor throws NoSuchFileException
 with absolute path
In-Reply-To: <97d57d22-b4f0-aa74-079b-9aad0032d3f0@oracle.com>
References: <0513b8d0-ab37-7700-6d06-2b5e0f574f45@oracle.com>
 <97d57d22-b4f0-aa74-079b-9aad0032d3f0@oracle.com>
Message-ID: <68f13645-6045-5bf2-fed4-17ca280952bd@oracle.com>

Hi Mandy,

Thanks for the review - and thanks for reminding me about
@modules java.logging/java.util.logging:open

I have a new webrev that incorporates your suggestions.
I have also tried to reduce the long lines (I recently
switched to a new IDE whose default config make them more
difficult to spot).

http://cr.openjdk.java.net/~dfuchs/webrev_8189953/webrev.01

best regards,

-- daniel

On 09/11/2017 17:41, mandy chung wrote:
> Hi Daniel,
> 
> On 11/2/17 9:47 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a patch for:
>> 8189953: FileHandler constructor throws NoSuchFileException
>> ???????? with absolute path
>> https://bugs.openjdk.java.net/browse/JDK-8189953
>>
>> webrev:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8189953/webrev.00/
>>
> This looks okay.
> 
> A minor comment: I think line 695-709 can be made cleaner and easier to 
> read and
> 
> e.g.
> 
> if (word.length() >0) {
>  ??? String n = word.toString();
>  ??? if (result ==null) {
>  ??????? result = prev !=null ? prev.resolveSibling(n) : Paths.get(n);
>  ??? }else {
>  ??????? Path p = prev !=null ? prev.resolveSibling(n) : Paths.get(n);
>  ??????? result = result.resolve(p);
>  ??? }
> }else if (result ==null) {
>  ??? result = Paths.get("");
> }
> if (path.getRoot() ==null)
>  ??? return result.toFile();
> else return path.getRoot().resolve(result).toFile();
> 
> 
> Mandy


From mandy.chung at oracle.com  Thu Nov  9 19:27:50 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 9 Nov 2017 11:27:50 -0800
Subject: RFR: 8189953: FileHandler constructor throws NoSuchFileException
 with absolute path
In-Reply-To: <68f13645-6045-5bf2-fed4-17ca280952bd@oracle.com>
References: <0513b8d0-ab37-7700-6d06-2b5e0f574f45@oracle.com>
 <97d57d22-b4f0-aa74-079b-9aad0032d3f0@oracle.com>
 <68f13645-6045-5bf2-fed4-17ca280952bd@oracle.com>
Message-ID: <6bf90b59-d331-5d9f-5c59-1ad60f60648d@oracle.com>



On 11/9/17 11:20 AM, Daniel Fuchs wrote:
> Hi Mandy,
>
> Thanks for the review - and thanks for reminding me about
> @modules java.logging/java.util.logging:open
>
> I have a new webrev that incorporates your suggestions.
> I have also tried to reduce the long lines (I recently
> switched to a new IDE whose default config make them more
> difficult to spot).
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8189953/webrev.01

Looks good.

thanks
Mandy

From daniel.fuchs at oracle.com  Thu Nov  9 19:29:39 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 Nov 2017 19:29:39 +0000
Subject: Change in properties for logging: deliberate?
In-Reply-To: <5d3ffed1-6c0d-d2f2-a541-a82d5ed8ebd5@oracle.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
 <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
 <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>
 <CAPYFHW0zNys6RwDLrCdw31oWbL7dZiHou7cMqXQSF5E5xk6Oug@mail.gmail.com>
 <59156c8a-8622-99b9-7a2f-b0c161868b4f@oracle.com>
 <5d3ffed1-6c0d-d2f2-a541-a82d5ed8ebd5@oracle.com>
Message-ID: <f1d8e738-0516-cdda-da19-989ae479911e@oracle.com>

On 09/11/2017 19:16, mandy chung wrote:
> Daniel - we should add this known issue in the release note and document 
> the workaround.

Hi Mandy,

Right, it either need to be fixed, or documented in the release
notes. Let me first have a look at the issue though.

best regards,

-- daniel


From jason_mehrens at hotmail.com  Thu Nov  9 19:50:46 2017
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 9 Nov 2017 19:50:46 +0000
Subject: Change in properties for logging: deliberate?
In-Reply-To: <f1d8e738-0516-cdda-da19-989ae479911e@oracle.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
 <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
 <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>
 <CAPYFHW0zNys6RwDLrCdw31oWbL7dZiHou7cMqXQSF5E5xk6Oug@mail.gmail.com>
 <59156c8a-8622-99b9-7a2f-b0c161868b4f@oracle.com>
 <5d3ffed1-6c0d-d2f2-a541-a82d5ed8ebd5@oracle.com>,
 <f1d8e738-0516-cdda-da19-989ae479911e@oracle.com>
Message-ID: <DM5PR1801MB19458C8FEEEEABA67E21DBDE83570@DM5PR1801MB1945.namprd18.prod.outlook.com>

Daniel,

I would assume you would fix since it is advertised as a feature over here: https://docs.oracle.com/javase/1.5.0/docs/guide/logging/changes.html

If it helps, I've dug up a lot of the history on this over here a while back:
https://stackoverflow.com/questions/36726431/in-a-java-util-logging-logging-properties-file-whats-the-difference-between-h

I've updated that to include the links to this new issue.  Now that I've linked this message thread to that message thread that should crash the internet. :)

Jason

________________________________________
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Daniel Fuchs <daniel.fuchs at oracle.com>
Sent: Thursday, November 9, 2017 1:29 PM
To: mandy chung
Cc: core-libs-dev at openjdk.java.net
Subject: Re: Change in properties for logging: deliberate?

On 09/11/2017 19:16, mandy chung wrote:
> Daniel - we should add this known issue in the release note and document
> the workaround.

Hi Mandy,

Right, it either need to be fixed, or documented in the release
notes. Let me first have a look at the issue though.

best regards,

-- daniel


From Roger.Riggs at Oracle.com  Thu Nov  9 20:19:40 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 9 Nov 2017 15:19:40 -0500
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <8167AB26-7918-4920-A889-4FB2F2254BE5@reini.net>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
 <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
 <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>
 <8167AB26-7918-4920-A889-4FB2F2254BE5@reini.net>
Message-ID: <3755dc7c-84b2-61a8-06a2-e45f5007f8b7@Oracle.com>

Hi Patrick,

A few comments:

Readable.java:
 ?67: + it may be worth mentioning that the input might not fit in 
output (as seen in the CharBuffer case)
Though I see we didn't call that out in the other transferTo description 
but here it is more likely that the output is bounded.

77: "The total amount will be added up by after the write method has 
been completed." should not be part
of the @implSpec.? It is untestable and unnecessary. If an exception 
occurs the value is lost.

96: "in order not having the extra overhead creating" -> "to avoid the 
extra overhead of"

X-Buffer.java.template:

1555: "form" -> "from"

1554: I would avoid most of the details in the @implSpec since it is 
requiring a specific use of CharBuffer methods.
That's fine as an @ImplNote but restricts the implementation too much as 
spec.
(others will disagree)

1565:? in the code, perhaps it should use an explicit 
RequireNonNull(out, "out") otherwise the NPE will be on put()/append().

1566: "insufficient space in this" refers to the source, not dest and it 
should only apply if out is a CharBuffer.
 ? Omit it or leave it more general;? that behavior is covered by the 
spec of the out Appendable.

1568: I don't see code to enforce:? "if out is this buffer"


On the tests; had you considered using TestNG;
it provides some good structure and is preferred (AFAIK) for new tests.

As for Randomness, it is useful to be explicit about the seed used in 
the particular run so it can be
replayed if necessary.? There is a testlibrary function to do that if 
you don't want to code-your-own.
(test/jdk/test/lib/RandomFactory::getRandom())

Thanks, Roger

On 11/9/2017 10:37 AM, Patrick Reinhart wrote:
> Finally did some review with Alan and integrated all into this webrev:
>
> http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.01 <http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.01>
>
> -Patrick
>
>> Am 08.11.2017 um 00:03 schrieb Brian Burkhalter <brian.burkhalter at oracle.com>:
>>
>> Hi Patrick,
>>
>> On Nov 7, 2017, at 3:01 PM, Patrick Reinhart <patrick at reini.net <mailto:patrick at reini.net>> wrote:
>>
>>> I integrated your changes into my current version which I will look into tomorrow with Alan at Devoxx. I think adding some implementation note on the default method implementation will be needed to review later on?
>> I concur.
>>
>>> I also made an override on the CharBuffer, where we need to add a enhanced documentation for the specialties around the CharBuffer implementations (BufferOverflowException/ReadOnlyBufferException), where a review of some native english speakers would help :-)
>> Sounds good!
>>
>> Thanks,
>>
>> Brian


From naoto.sato at oracle.com  Thu Nov  9 23:34:35 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 9 Nov 2017 15:34:35 -0800
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
Message-ID: <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>

Kindly requesting reviews. I incorporated a fix to the following issue 
raised by the test team:

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

Here is the updated webrev:

http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/

And the webrev since the one below (to address 8190918):

http://cr.openjdk.java.net/~naoto/8190918/

Naoto



On 11/2/17 2:42 PM, Naoto Sato wrote:
> Hello,
> 
> Please review the proposed changes for the following issues:
> 
> 8176841: Additional Unicode Language-Tag Extensions
> 8189134: New system properties for the default Locale extensions
> 
> The proposed changeset is located at:
> 
> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
> 
> This serves as the implementation of JEP 314.
> 
> Naoto
> 
> 
> 

From patrick at reini.net  Fri Nov 10 08:49:47 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Fri, 10 Nov 2017 09:49:47 +0100
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <c2137520-677d-2a7c-898a-2b8884df96f3@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <CAE+3fjYzgEMmFFOge6hdN9wi3qS=5OCTKJKupeLbf-gaaPf9eQ@mail.gmail.com>
 <d02cf931-6bd4-3b99-3375-dbce6e8047c8@oracle.com>
 <2a20565b-83f5-a39d-8b31-ac70c64ff8b9@gmail.com>
 <c2137520-677d-2a7c-898a-2b8884df96f3@oracle.com>
Message-ID: <1F53EBF0-AC41-4DDF-949A-BE6DA91CCA47@reini.net>

Hi Stuart,

After having thought over your arguments about copyOf versus unmodifiableCopyOf length discussion (also with my colleague) I was thinking about why not create additional X.of(X) methods instead of X.copyOf(X). It would seem to me a logical enhancement in the sense of the existing API though.

-Patrick

> Am 02.11.2017 um 23:04 schrieb Stuart Marks <stuart.marks at oracle.com>:
> 
> 
>> Why not using:
>> 
>>     coll.stream().collect(Collectors.toImmutableSet())
>> 
>> As Collectors.toImmutableSet() is currently implemented, with serial Stream it will create a single HashSet, add all the elements to it and call Set.of(HashSet.toArray()) with it. Pretty much the same as what Tagir proposes, but the Collector could be made more efficient in the future and with it, the optimization would automatically extend to Set.copyOf()...
> This is mainly about whether Set.copyOf() is implemented in terms of Collectors.toUnmodifiableSet(), or vice-versa, which then calls Set.of(T[]) to do the actual creation. Some future optimization will probably replace both of these implementations with calls to JDK internal methods that can bypass the extra copying, so it doesn't really matter which one of these calls the other right now.
> 
> s'marks
> 


From stanislav.lukyanov at oracle.com  Fri Nov 10 09:36:51 2017
From: stanislav.lukyanov at oracle.com (stanislav lukyanov)
Date: Fri, 10 Nov 2017 15:06:51 +0530
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <26336F4F-0A21-4A08-AFA3-23CA972CAD93@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com>
 <26336F4F-0A21-4A08-AFA3-23CA972CAD93@oracle.com>
Message-ID: <e9dad599-2e49-d66d-4236-59191a52320b@oracle.com>

On 10.11.2017 0:13, Paul Sandoz wrote:
> <...>
> I would prefer to follow up later on with more non-normative explanatory text. It will take some careful crafting and i don?t want that to side-track the review for the moment (including guidance on what forms of computed constants are acceptable).
Fair. Does it make sense to add a sub-task for this to JDK-8185992 to 
keep it on the radar?
> <...>
>
> And adjusted the invoke method:
>
> * @param args the arguments to pass to the method handle, as if with
> * {@link MethodHandle#invokeWithArguments}.  Each argument may be
> * {@code null}.
> ...
> * @throws NullPointerException if {@code args} is {@code null}
> * (each argument of {@code args} may be {@code null}).
I think the `@throws NPE` is not needed, at least not from the normative 
perspective.
The class-level text about NPE doesn't assume anything about the 
contents of objects passed to the methods,
and the second part of the `@param args` already clarifies the behavior 
for this particular case.
Arguably having this `@throws` might improve clarity, but I would rather 
remove it.
>
> We have been fleshing out the NPE behaviour because we know you will log bugs against us later on if we don?t :-)
Yep, that's sounds familiar :)

<...>

Thanks for the updates!

Also, javac isn't going to use `::primitiveClass` instead of `getstatic 
Integer.TYPE` to load int.class, right?
If it is, int.class probably needs to be changed to Integer.TYPE in 
sun.invoke.util.Wrapper to avoid cycles.

Stas


From patrick at reini.net  Fri Nov 10 09:42:36 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Fri, 10 Nov 2017 10:42:36 +0100
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <3755dc7c-84b2-61a8-06a2-e45f5007f8b7@Oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
 <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
 <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>
 <8167AB26-7918-4920-A889-4FB2F2254BE5@reini.net>
 <3755dc7c-84b2-61a8-06a2-e45f5007f8b7@Oracle.com>
Message-ID: <2D157CBB-65F0-41B1-8DB5-99F45BB8A412@reini.net>

An updated webrev:

http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.01


> A few comments:
> 
> Readable.java:
>  67: + it may be worth mentioning that the input might not fit in output (as seen in the CharBuffer case)
> Though I see we didn?t call that out in the other transferTo description but here it is more likely that the output is bounded.
I tried to mention that now.

> 
> 77: "The total amount will be added up by after the write method has been completed." should not be part
> of the @implSpec.  It is untestable and unnecessary. If an exception occurs the value is lost.
I see that point - removed

> 
> 96: ?in order not having the extra overhead creating" -> "to avoid the extra overhead of"
done

> 
> X-Buffer.java.template:
> 
> 1555: ?form" -> "from"
done

> 
> 1554: I would avoid most of the details in the @implSpec since it is requiring a specific use of CharBuffer methods.
> That's fine as an @ImplNote but restricts the implementation too much as spec.
> (others will disagree)
> 
> 1565:  in the code, perhaps it should use an explicit RequireNonNull(out, ?out") otherwise the NPE will be on put()/append().
done

> 
> 1566: "insufficient space in this" refers to the source, not dest and it should only apply if out is a CharBuffer.
>   Omit it or leave it more general;  that behavior is covered by the spec of the out Appendable.
> 
> 1568: I don?t see code to enforce:  "if out is this buffer"
done

> 
> 
> On the tests; had you considered using TestNG;
> it provides some good structure and is preferred (AFAIK) for new tests.
To be honest, no. The test for the Readable I basically copied from the InputStream and the one for CharBuffer I just did
not think about? I will certainly consider that for the future :-)

> 
> As for Randomness, it is useful to be explicit about the seed used in the particular run so it can be
> replayed if necessary.  There is a testlibrary function to do that if you don't want to code-your-own.
> (test/jdk/test/lib/RandomFactory::getRandom())
I will need some digging how to have the RandomFactory be added to the test class path?

> 
> Thanks, Roger
> 


From jaroslav.tulach at oracle.com  Fri Nov 10 09:55:04 2017
From: jaroslav.tulach at oracle.com (Jaroslav Tulach)
Date: Fri, 10 Nov 2017 10:55:04 +0100
Subject: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only the
 permissions it really needs to expose the bean
Message-ID: <2138013.zvGs44vPXg@pracovni>

Hi.
I believe I have a fix for JDK-8189116 - the 
jdk.internal.vm.compiler.management needs only few permissions as shown in my 
webrev: http://cr.openjdk.java.net/~jtulach/8189116/webrev.01/

I have executed all the tests I found and it seems none of them regressed. 
Also the Graal Compiler MX bean is properly exposed when the built JDK is 
launched with

./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
+EnableJVMCI -XX:+UseJVMCICompiler -jar ...

Please take a look and review my changes. Thanks a lot.
-jt


From volker.simonis at gmail.com  Fri Nov 10 10:37:43 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 10 Nov 2017 11:37:43 +0100
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <D9A579D7-D93D-4BFF-BBA8-7C4766D9C9E8@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com>
 <CA+3eh11pz0dYhgtwd285xaj_We1ezn2Gw7XZmQ2FsHPLxvg4JA@mail.gmail.com>
 <D9A579D7-D93D-4BFF-BBA8-7C4766D9C9E8@oracle.com>
Message-ID: <CA+3eh11WXqhMhkH_mW8-sibfGuH4znBpSdfDig2sqYwdoRUtEw@mail.gmail.com>

On Thu, Nov 9, 2017 at 8:06 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> Hi Volker,
>
>> On 9 Nov 2017, at 01:01, Volker Simonis <volker.simonis at gmail.com> wrote:
>>
>> Hi Paul,
>>
>> just some quick process-related questions.
>>
>> Is this intended to be targeted for jdk 10?
>>
>
> Yes, that?s what we are aiming for. I am front loading reviews ahead of a propose to target (which should hopefully happen soon) to make better use of time given the shorter cycles, thus increasing the quality and giving heads up to other developers like yourself who are responsible for other platforms.
>
>
>> Is the current implementation already available in a separate
>> repository and/or branch? I've read in the RFR for 8186046 that some
>> parts are currently being refined in the amber repository. Or is the
>> complete implementation already available there?
>>
>
> A super set of functionality is present in the amber repo under the condy branch. We pealed a sub-set of that off and created patches for the idk/hs repo tracked in:
>
>   Minimal ConstantDynamic support
>   https://bugs.openjdk.java.net/browse/JDK-8186046
>   Tool support for ConstantDynamic
>   https://bugs.openjdk.java.net/browse/JDK-8186209
>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/
>
>   Minimal set of bootstrap methods for dynamic constants
>   https://bugs.openjdk.java.net/browse/JDK-8187742
>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/
>
> While these are under review they might diverge a little from the condy branch in the amber repo but i will sync back up in batches.
>
>
>> If I want to port this to ppc64, what's the best way to start and what
>> do I need? Is it just the two webrevs for 8187742 and 8186046 on top
>> of the jdk hs repo? Or is it a branch of the amber repo?
>>
>
> Yes, and focus on the following applied to the jdk/hs repo:
>
>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/
>
> There are tests in that patch that are currently targeted to run only on x86 that would otherwise tickle failures on other platforms.
>
>
>> You may know that there's currently a discussion going on about what
>> is a JEP and what's the right way to implement and integrate a JEP
>> into the mainline. The general idea is that only 'finished' JEPs will
>> be targeted and integrated into the always feature complete main line.
>> So is this and the review for 8186046 about the integration into the
>> jdk repo (which shouldn't happen before the JEP is not targeted for
>> jdk10) or is it just the review before the JEP can actually be
>> targeted? This is important because there's not much time before the
>> jdk10 repos will enter Rampdown phase 1 and we would still have to
>> port this to ppc (and also ARM/SPARC) if it will be targeted for jdk
>> 10.
>>
>> I don't want to question the merits and quality of the current
>> implementation which I'm sure are great. For me as an external
>> observer its just hard to oversee the current status of the
>> implementation.
>>
>
> I hear you, thanks for your patience. Is it a little clearer now?
>

Thanks Paul!

Things are much clearer now. I'll start looking at the changes
required for ppc/s390.

Regards,
Volker

> From my own perspective this is the first flight over the new release cycle territory, the ride might be a little bumpy while we learn to pilot this better :-)
>
> Paul.

From venkatec at linux.vnet.ibm.com  Fri Nov 10 12:07:46 2017
From: venkatec at linux.vnet.ibm.com (Venkateswara R Chintala)
Date: Fri, 10 Nov 2017 17:37:46 +0530
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
Message-ID: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>

Hi,

In a multi-threaded environment, when java.util.SimpleTimeZone object is 
used to create a default timezone, there can be a race condition between 
the methods java.util.Timezone.getDefault() and 
java.util.Timezone.getDefaultRef() which can result in inconsistency of 
cache that is used to validate a particular time/date in DST.

When a thread is cloning a default timezone object (SimpleTimeZone) and 
at the same time if a different thread modifies the time/year values, 
then the cache values (cacheYear, cacheStart, cacheEnd) can become 
inconsistent which leads to incorrect DST determination.

We considered two approaches to fix the issue.

1)Synchronize access to cloning default timezone object when cache is 
being modified.

2)Invalidate the cache while returning the clone.

We preferred the second option as synchronization is more expensive.

We have attached the patch and jtreg testcase. Please review.

-- 
Regards
-Venkat


From venkatec at linux.vnet.ibm.com  Fri Nov 10 12:18:49 2017
From: venkatec at linux.vnet.ibm.com (Venkateswara R Chintala)
Date: Fri, 10 Nov 2017 17:48:49 +0530
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
Message-ID: <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>

Looks like the patch attached earlier is not visible. As this is my 
first contribution, please let me know how I can send the patch for review.


On 10/11/17 5:37 PM, Venkateswara R Chintala wrote:
> Hi,
>
> In a multi-threaded environment, when java.util.SimpleTimeZone object 
> is used to create a default timezone, there can be a race condition 
> between the methods java.util.Timezone.getDefault() and 
> java.util.Timezone.getDefaultRef() which can result in inconsistency 
> of cache that is used to validate a particular time/date in DST.
>
> When a thread is cloning a default timezone object (SimpleTimeZone) 
> and at the same time if a different thread modifies the time/year 
> values, then the cache values (cacheYear, cacheStart, cacheEnd) can 
> become inconsistent which leads to incorrect DST determination.
>
> We considered two approaches to fix the issue.
>
> 1)Synchronize access to cloning default timezone object when cache is 
> being modified.
>
> 2)Invalidate the cache while returning the clone.
>
> We preferred the second option as synchronization is more expensive.
>
> We have attached the patch and jtreg testcase. Please review.
>

-- 
Regards
-Venkat


From amaembo at gmail.com  Fri Nov 10 13:01:08 2017
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 10 Nov 2017 20:01:08 +0700
Subject: RFR 8190974 Parallel stream execution within a custom
 ForkJoinPool should obey the parallelism
In-Reply-To: <CFFC012D-28A8-4CEB-853E-ACE60041C4FA@oracle.com>
References: <CFFC012D-28A8-4CEB-853E-ACE60041C4FA@oracle.com>
Message-ID: <CAE+3fja0nHhcG9wXKg48=EY+R_T9fqZRvPoF6Sy0=QFfjmvtHA@mail.gmail.com>

Hello!

Looks good to me, thanks!

With best regards,
Tagir Valeev.

9 ????. 2017 ?. 4:02 AM ???????????? "Paul Sandoz" <paul.sandoz at oracle.com>
???????:

> Hi,
>
> Please review this patch to ensure that a parallel stream obeys the
> parallelism of a custom fork join pool when it is executed within that pool:
>
>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-
> stream-custom-pool/webrev/ <http://cr.openjdk.java.net/~
> psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/>
>
> Streams currently do not support capabilities to control the level of
> parallelism and therefore resources utilised (tricky API design problem to
> get right).
>
> At the moment the trick is to run stream executions within a custom pool,
> however the number of fork join tasks created will be in proportion to the
> parallelism of the common pool thus the execution will be over-provisioned.
> This can be especially noticeable on large machines with many cores.
>
> Paul.

From sean.coffey at oracle.com  Fri Nov 10 15:59:40 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 10 Nov 2017 15:59:40 +0000
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
Message-ID: <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>

I think the OpenJDK mailing lists accept attachments if in patch format. 
If it's a simple short patch, it's acceptable to paste it into email body.

Easiest solution is to use webrev[1]. If you can't upload this to 
cr.openjdk.java.net - then one of your colleagues may be able to help.

[1] http://openjdk.java.net/guide/webrevHelp.html

Regards,
Sean.

On 10/11/17 12:18, Venkateswara R Chintala wrote:
> Looks like the patch attached earlier is not visible. As this is my 
> first contribution, please let me know how I can send the patch for 
> review.
>
>
> On 10/11/17 5:37 PM, Venkateswara R Chintala wrote:
>> Hi,
>>
>> In a multi-threaded environment, when java.util.SimpleTimeZone object 
>> is used to create a default timezone, there can be a race condition 
>> between the methods java.util.Timezone.getDefault() and 
>> java.util.Timezone.getDefaultRef() which can result in inconsistency 
>> of cache that is used to validate a particular time/date in DST.
>>
>> When a thread is cloning a default timezone object (SimpleTimeZone) 
>> and at the same time if a different thread modifies the time/year 
>> values, then the cache values (cacheYear, cacheStart, cacheEnd) can 
>> become inconsistent which leads to incorrect DST determination.
>>
>> We considered two approaches to fix the issue.
>>
>> 1)Synchronize access to cloning default timezone object when cache is 
>> being modified.
>>
>> 2)Invalidate the cache while returning the clone.
>>
>> We preferred the second option as synchronization is more expensive.
>>
>> We have attached the patch and jtreg testcase. Please review.
>>
>


From daniel.fuchs at oracle.com  Fri Nov 10 16:04:29 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 10 Nov 2017 16:04:29 +0000
Subject: Change in properties for logging: deliberate?
In-Reply-To: <DM5PR1801MB19458C8FEEEEABA67E21DBDE83570@DM5PR1801MB1945.namprd18.prod.outlook.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
 <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
 <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>
 <CAPYFHW0zNys6RwDLrCdw31oWbL7dZiHou7cMqXQSF5E5xk6Oug@mail.gmail.com>
 <59156c8a-8622-99b9-7a2f-b0c161868b4f@oracle.com>
 <5d3ffed1-6c0d-d2f2-a541-a82d5ed8ebd5@oracle.com>
 <f1d8e738-0516-cdda-da19-989ae479911e@oracle.com>
 <DM5PR1801MB19458C8FEEEEABA67E21DBDE83570@DM5PR1801MB1945.namprd18.prod.outlook.com>
Message-ID: <9d326eca-e94f-cfb2-6daf-e9db456050ff@oracle.com>

Hi Jason,

I have done a few tests with JDK 8 & 7.

I have created custom handlers and added some
debug traces in their constructors and debug methods.

Then I have added these two lines to my logging.properties:

handlers = custom.Handler
.handlers = custom.DotHandler

What I see is this:

- the first time the configuration is read, two handlers
   are added to the root logger:
   - an instance of DotHandler (first), then an instance
     of Handler (second).

Then if you call LogManager.readConfiguration() again,
both handlers are closed, and this time only one
instance of Handler is added to the root logger.
No instance of DotHandler is added.
 From now on the property is ignored.

This is because the root logger is a special beast:
it will not be removed (like all other loggers) when
LogManager.readConfiguration() is called.

And as it happens, handlers are added to loggers
when the loggers are added to the LogManager.
As it happens, the ".handlers" property is only parsed
and read when the root logger is added to the LogManager,
and thus only once.

The "handlers" property on the other hand is parsed
every time LogManager.readConfiguration() is called.

Given that, I suspect we should deprecate the use of
".handlers" for the root logger, as it appears that
it has never worked properly. I could work on a patch
for 10 (possibly backport it to 9 update) to preserve
the strange behavior of 7 & 8, but is it worth it?

What are your thoughts?

best regards,

-- daniel




On 09/11/2017 19:50, Jason Mehrens wrote:
> Daniel,
> 
> I would assume you would fix since it is advertised as a feature over here: https://docs.oracle.com/javase/1.5.0/docs/guide/logging/changes.html
> 
> If it helps, I've dug up a lot of the history on this over here a while back:
> https://stackoverflow.com/questions/36726431/in-a-java-util-logging-logging-properties-file-whats-the-difference-between-h
> 
> I've updated that to include the links to this new issue.  Now that I've linked this message thread to that message thread that should crash the internet. :)
> 
> Jason
> 
> ________________________________________
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Daniel Fuchs <daniel.fuchs at oracle.com>
> Sent: Thursday, November 9, 2017 1:29 PM
> To: mandy chung
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: Change in properties for logging: deliberate?
> 
> On 09/11/2017 19:16, mandy chung wrote:
>> Daniel - we should add this known issue in the release note and document
>> the workaround.
> 
> Hi Mandy,
> 
> Right, it either need to be fixed, or documented in the release
> notes. Let me first have a look at the issue though.
> 
> best regards,
> 
> -- daniel
> 


From ralph.goers at dslextreme.com  Fri Nov 10 17:06:48 2017
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Fri, 10 Nov 2017 10:06:48 -0700
Subject: Change in properties for logging: deliberate?
In-Reply-To: <9d326eca-e94f-cfb2-6daf-e9db456050ff@oracle.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
 <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
 <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>
 <CAPYFHW0zNys6RwDLrCdw31oWbL7dZiHou7cMqXQSF5E5xk6Oug@mail.gmail.com>
 <59156c8a-8622-99b9-7a2f-b0c161868b4f@oracle.com>
 <5d3ffed1-6c0d-d2f2-a541-a82d5ed8ebd5@oracle.com>
 <f1d8e738-0516-cdda-da19-989ae479911e@oracle.com>
 <DM5PR1801MB19458C8FEEEEABA67E21DBDE83570@DM5PR1801MB1945.namprd18.prod.outlook.com>
 <9d326eca-e94f-cfb2-6daf-e9db456050ff@oracle.com>
Message-ID: <EC653EDF-91AB-4133-B5F7-F5886CB511D9@dslextreme.com>

Can?t you just deprecate java.util.logging?

While I am half kidding, can someone explain why it doesn?t use a ServiceLoader to locate the LogManager implementation?

Ralph

> On Nov 10, 2017, at 9:04 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Jason,
> 
> I have done a few tests with JDK 8 & 7.
> 
> I have created custom handlers and added some
> debug traces in their constructors and debug methods.
> 
> Then I have added these two lines to my logging.properties:
> 
> handlers = custom.Handler
> .handlers = custom.DotHandler
> 
> What I see is this:
> 
> - the first time the configuration is read, two handlers
>  are added to the root logger:
>  - an instance of DotHandler (first), then an instance
>    of Handler (second).
> 
> Then if you call LogManager.readConfiguration() again,
> both handlers are closed, and this time only one
> instance of Handler is added to the root logger.
> No instance of DotHandler is added.
> From now on the property is ignored.
> 
> This is because the root logger is a special beast:
> it will not be removed (like all other loggers) when
> LogManager.readConfiguration() is called.
> 
> And as it happens, handlers are added to loggers
> when the loggers are added to the LogManager.
> As it happens, the ".handlers" property is only parsed
> and read when the root logger is added to the LogManager,
> and thus only once.
> 
> The "handlers" property on the other hand is parsed
> every time LogManager.readConfiguration() is called.
> 
> Given that, I suspect we should deprecate the use of
> ".handlers" for the root logger, as it appears that
> it has never worked properly. I could work on a patch
> for 10 (possibly backport it to 9 update) to preserve
> the strange behavior of 7 & 8, but is it worth it?
> 
> What are your thoughts?
> 
> best regards,
> 
> -- daniel
> 
> 
> 
> 
> On 09/11/2017 19:50, Jason Mehrens wrote:
>> Daniel,
>> I would assume you would fix since it is advertised as a feature over here: https://docs.oracle.com/javase/1.5.0/docs/guide/logging/changes.html
>> If it helps, I've dug up a lot of the history on this over here a while back:
>> https://stackoverflow.com/questions/36726431/in-a-java-util-logging-logging-properties-file-whats-the-difference-between-h
>> I've updated that to include the links to this new issue.  Now that I've linked this message thread to that message thread that should crash the internet. :)
>> Jason
>> ________________________________________
>> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Daniel Fuchs <daniel.fuchs at oracle.com>
>> Sent: Thursday, November 9, 2017 1:29 PM
>> To: mandy chung
>> Cc: core-libs-dev at openjdk.java.net
>> Subject: Re: Change in properties for logging: deliberate?
>> On 09/11/2017 19:16, mandy chung wrote:
>>> Daniel - we should add this known issue in the release note and document
>>> the workaround.
>> Hi Mandy,
>> Right, it either need to be fixed, or documented in the release
>> notes. Let me first have a look at the issue though.
>> best regards,
>> -- daniel
> 
> 



From mandy.chung at oracle.com  Fri Nov 10 19:58:04 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 10 Nov 2017 11:58:04 -0800
Subject: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only
 the permissions it really needs to expose the bean
In-Reply-To: <2138013.zvGs44vPXg@pracovni>
References: <2138013.zvGs44vPXg@pracovni>
Message-ID: <610c8d9d-9b01-d874-8794-1b99fc8a150e@oracle.com>



On 11/10/17 1:55 AM, Jaroslav Tulach wrote:
> Hi.
> I believe I have a fix for JDK-8189116 - the
> jdk.internal.vm.compiler.management needs only few permissions as shown in my
> webrev: http://cr.openjdk.java.net/~jtulach/8189116/webrev.01/

The change looks fine.? This mainly depends on the test coverage and 
also code inspection to find security-sensitive operations.
> I have executed all the tests I found and it seems none of them regressed.

You ran jdk_svc that should cover the management tests.?? I assume you 
also run Graal tests.
> Also the Graal Compiler MX bean is properly exposed when the built JDK is
> launched with
>
> ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
> +EnableJVMCI -XX:+UseJVMCICompiler -jar ...
>

You can also try running the above command with -Djava.security.manager 
as a sanity test (the application may need additional permissions) - 
just a sanity test.? Is there a way you can access Graal MBean in a VM 
with security manager enabled (locally is fine) to make sure it can be 
accessed as expected?

This is good to go as long as you verify the access to Graal MBean with 
security manager on.
Mandy

From jeremymanson at google.com  Fri Nov 10 20:48:58 2017
From: jeremymanson at google.com (Jeremy Manson)
Date: Fri, 10 Nov 2017 12:48:58 -0800
Subject: Change in properties for logging: deliberate?
In-Reply-To: <9d326eca-e94f-cfb2-6daf-e9db456050ff@oracle.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
 <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
 <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>
 <CAPYFHW0zNys6RwDLrCdw31oWbL7dZiHou7cMqXQSF5E5xk6Oug@mail.gmail.com>
 <59156c8a-8622-99b9-7a2f-b0c161868b4f@oracle.com>
 <5d3ffed1-6c0d-d2f2-a541-a82d5ed8ebd5@oracle.com>
 <f1d8e738-0516-cdda-da19-989ae479911e@oracle.com>
 <DM5PR1801MB19458C8FEEEEABA67E21DBDE83570@DM5PR1801MB1945.namprd18.prod.outlook.com>
 <9d326eca-e94f-cfb2-6daf-e9db456050ff@oracle.com>
Message-ID: <CAPYFHW3HP6O2UwPk95h=4z5j+ZGO2o0mT9tZ=U7a51abpdwwEA@mail.gmail.com>

Daniel,

Thanks for taking a look at this.  I'd like to disagree with the reasoning
here.

First, it isn't just JDKs 7 and 8 - the behavior is the same all the way
back to JDK 1.4, when the java.util.logging API was introduced.  So changes
affect 15 years' worth of logging configuration files.  For example, there
are no fewer than 350 instances of this pattern in our codebase.  Imagine
multiplying that across the entire world - everyone who is doing this has
to change their configuration.  That's a pretty big cost to introduce on
the developer community.

This is worse on legacy systems, because the handlers property was broken
for a long time, and people basically had to use .handlers:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6207335.

Second, it is inconsistent for ".level" to work for level for the root
logger, and ".handlers" not to work for handlers for the root logger.  The
empty string represents the root logger, and having it only represent the
root logger sometimes is (to me) counterintuitive.  Without checking, my
suspicion is that .level behaves the same way as .handlers (that is, it is
only loaded once).  If we can live with the inconsistency there, we can
live with it here.  You can even document that that is the difference.

Jeremy


On Fri, Nov 10, 2017 at 8:04 AM, Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Jason,
>
> I have done a few tests with JDK 8 & 7.
>
> I have created custom handlers and added some
> debug traces in their constructors and debug methods.
>
> Then I have added these two lines to my logging.properties:
>
> handlers = custom.Handler
> .handlers = custom.DotHandler
>
> What I see is this:
>
> - the first time the configuration is read, two handlers
>   are added to the root logger:
>   - an instance of DotHandler (first), then an instance
>     of Handler (second).
>
> Then if you call LogManager.readConfiguration() again,
> both handlers are closed, and this time only one
> instance of Handler is added to the root logger.
> No instance of DotHandler is added.
> From now on the property is ignored.
>
> This is because the root logger is a special beast:
> it will not be removed (like all other loggers) when
> LogManager.readConfiguration() is called.
>
> And as it happens, handlers are added to loggers
> when the loggers are added to the LogManager.
> As it happens, the ".handlers" property is only parsed
> and read when the root logger is added to the LogManager,
> and thus only once.
>
> The "handlers" property on the other hand is parsed
> every time LogManager.readConfiguration() is called.
>
> Given that, I suspect we should deprecate the use of
> ".handlers" for the root logger, as it appears that
> it has never worked properly. I could work on a patch
> for 10 (possibly backport it to 9 update) to preserve
> the strange behavior of 7 & 8, but is it worth it?
>
> What are your thoughts?
>
> best regards,
>
> -- daniel
>
>
>
>
>
> On 09/11/2017 19:50, Jason Mehrens wrote:
>
>> Daniel,
>>
>> I would assume you would fix since it is advertised as a feature over
>> here: https://docs.oracle.com/javase/1.5.0/docs/guide/logging/
>> changes.html
>>
>> If it helps, I've dug up a lot of the history on this over here a while
>> back:
>> https://stackoverflow.com/questions/36726431/in-a-java-util-
>> logging-logging-properties-file-whats-the-difference-between-h
>>
>> I've updated that to include the links to this new issue.  Now that I've
>> linked this message thread to that message thread that should crash the
>> internet. :)
>>
>> Jason
>>
>> ________________________________________
>> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf
>> of Daniel Fuchs <daniel.fuchs at oracle.com>
>> Sent: Thursday, November 9, 2017 1:29 PM
>> To: mandy chung
>> Cc: core-libs-dev at openjdk.java.net
>> Subject: Re: Change in properties for logging: deliberate?
>>
>> On 09/11/2017 19:16, mandy chung wrote:
>>
>>> Daniel - we should add this known issue in the release note and document
>>> the workaround.
>>>
>>
>> Hi Mandy,
>>
>> Right, it either need to be fixed, or documented in the release
>> notes. Let me first have a look at the issue though.
>>
>> best regards,
>>
>> -- daniel
>>
>>
>

From daniel.fuchs at oracle.com  Fri Nov 10 21:20:47 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 10 Nov 2017 21:20:47 +0000
Subject: Change in properties for logging: deliberate?
In-Reply-To: <CAPYFHW3HP6O2UwPk95h=4z5j+ZGO2o0mT9tZ=U7a51abpdwwEA@mail.gmail.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
 <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
 <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>
 <CAPYFHW0zNys6RwDLrCdw31oWbL7dZiHou7cMqXQSF5E5xk6Oug@mail.gmail.com>
 <59156c8a-8622-99b9-7a2f-b0c161868b4f@oracle.com>
 <5d3ffed1-6c0d-d2f2-a541-a82d5ed8ebd5@oracle.com>
 <f1d8e738-0516-cdda-da19-989ae479911e@oracle.com>
 <DM5PR1801MB19458C8FEEEEABA67E21DBDE83570@DM5PR1801MB1945.namprd18.prod.outlook.com>
 <9d326eca-e94f-cfb2-6daf-e9db456050ff@oracle.com>
 <CAPYFHW3HP6O2UwPk95h=4z5j+ZGO2o0mT9tZ=U7a51abpdwwEA@mail.gmail.com>
Message-ID: <01255c85-70f1-9860-dd86-a0a8434b3db6@oracle.com>

Hi Jeremy,

I will propose a fix then.

However be aware that logging configuration files that use ".handlers"
instead of "handlers" to configure the root logger are fragile, as it
seems that any subsequent call to LogManager.readConfiguration() will
remove this configuration. Though I agree this might not be an issue
if it has stayed unnoticed for 15 years.

I will need to verify the behavior of ".level".
Thanks for pointing that out. I don't think it has the same flaw but
I will need to make sure.

best regards,

-- daniel

On 10/11/17 20:48, Jeremy Manson wrote:
> Daniel,
> 
> Thanks for taking a look at this.? I'd like to disagree with the 
> reasoning here.
> 
> First, it isn't just JDKs 7 and 8 - the behavior is the same all the way 
> back to JDK 1.4, when the java.util.logging API was introduced.? So 
> changes affect 15 years' worth of logging configuration files.? For 
> example, there are no fewer than 350 instances of this pattern in our 
> codebase.? Imagine multiplying that across the entire world - everyone 
> who is doing this has to change their configuration.? That's a pretty 
> big cost to introduce on the developer community.
> 
> This is worse on legacy systems, because the handlers property was 
> broken for a long time, and people basically had to use .handlers: 
> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6207335.
> 
> Second, it is inconsistent for ".level" to work for level for the root 
> logger, and ".handlers" not to work for handlers for the root logger.  
> The empty string represents the root logger, and having it only 
> represent the root logger sometimes is (to me) counterintuitive.  
> Without checking, my suspicion is that .level behaves the same way as 
> .handlers (that is, it is only loaded once).? If we can live with the 
> inconsistency there, we can live with it here.? You can even document 
> that that is the difference.
> 
> Jeremy
> 
> 
> On Fri, Nov 10, 2017 at 8:04 AM, Daniel Fuchs <daniel.fuchs at oracle.com 
> <mailto:daniel.fuchs at oracle.com>> wrote:
> 
>     Hi Jason,
> 
>     I have done a few tests with JDK 8 & 7.
> 
>     I have created custom handlers and added some
>     debug traces in their constructors and debug methods.
> 
>     Then I have added these two lines to my logging.properties:
> 
>     handlers = custom.Handler
>     .handlers = custom.DotHandler
> 
>     What I see is this:
> 
>     - the first time the configuration is read, two handlers
>      ? are added to the root logger:
>      ? - an instance of DotHandler (first), then an instance
>      ? ? of Handler (second).
> 
>     Then if you call LogManager.readConfiguration() again,
>     both handlers are closed, and this time only one
>     instance of Handler is added to the root logger.
>     No instance of DotHandler is added.
>      From now on the property is ignored.
> 
>     This is because the root logger is a special beast:
>     it will not be removed (like all other loggers) when
>     LogManager.readConfiguration() is called.
> 
>     And as it happens, handlers are added to loggers
>     when the loggers are added to the LogManager.
>     As it happens, the ".handlers" property is only parsed
>     and read when the root logger is added to the LogManager,
>     and thus only once.
> 
>     The "handlers" property on the other hand is parsed
>     every time LogManager.readConfiguration() is called.
> 
>     Given that, I suspect we should deprecate the use of
>     ".handlers" for the root logger, as it appears that
>     it has never worked properly. I could work on a patch
>     for 10 (possibly backport it to 9 update) to preserve
>     the strange behavior of 7 & 8, but is it worth it?
> 
>     What are your thoughts?
> 
>     best regards,
> 
>     -- daniel
> 
> 
> 
> 
> 
>     On 09/11/2017 19:50, Jason Mehrens wrote:
> 
>         Daniel,
> 
>         I would assume you would fix since it is advertised as a feature
>         over here:
>         https://docs.oracle.com/javase/1.5.0/docs/guide/logging/changes.html
>         <https://docs.oracle.com/javase/1.5.0/docs/guide/logging/changes.html>
> 
>         If it helps, I've dug up a lot of the history on this over here
>         a while back:
>         https://stackoverflow.com/questions/36726431/in-a-java-util-logging-logging-properties-file-whats-the-difference-between-h
>         <https://stackoverflow.com/questions/36726431/in-a-java-util-logging-logging-properties-file-whats-the-difference-between-h>
> 
>         I've updated that to include the links to this new issue.? Now
>         that I've linked this message thread to that message thread that
>         should crash the internet. :)
> 
>         Jason
> 
>         ________________________________________
>         From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net
>         <mailto:core-libs-dev-bounces at openjdk.java.net>> on behalf of
>         Daniel Fuchs <daniel.fuchs at oracle.com
>         <mailto:daniel.fuchs at oracle.com>>
>         Sent: Thursday, November 9, 2017 1:29 PM
>         To: mandy chung
>         Cc: core-libs-dev at openjdk.java.net
>         <mailto:core-libs-dev at openjdk.java.net>
>         Subject: Re: Change in properties for logging: deliberate?
> 
>         On 09/11/2017 19:16, mandy chung wrote:
> 
>             Daniel - we should add this known issue in the release note
>             and document
>             the workaround.
> 
> 
>         Hi Mandy,
> 
>         Right, it either need to be fixed, or documented in the release
>         notes. Let me first have a look at the issue though.
> 
>         best regards,
> 
>         -- daniel
> 
> 
> 


From jeremymanson at google.com  Fri Nov 10 23:24:43 2017
From: jeremymanson at google.com (Jeremy Manson)
Date: Fri, 10 Nov 2017 15:24:43 -0800
Subject: Change in properties for logging: deliberate?
In-Reply-To: <01255c85-70f1-9860-dd86-a0a8434b3db6@oracle.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
 <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
 <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>
 <CAPYFHW0zNys6RwDLrCdw31oWbL7dZiHou7cMqXQSF5E5xk6Oug@mail.gmail.com>
 <59156c8a-8622-99b9-7a2f-b0c161868b4f@oracle.com>
 <5d3ffed1-6c0d-d2f2-a541-a82d5ed8ebd5@oracle.com>
 <f1d8e738-0516-cdda-da19-989ae479911e@oracle.com>
 <DM5PR1801MB19458C8FEEEEABA67E21DBDE83570@DM5PR1801MB1945.namprd18.prod.outlook.com>
 <9d326eca-e94f-cfb2-6daf-e9db456050ff@oracle.com>
 <CAPYFHW3HP6O2UwPk95h=4z5j+ZGO2o0mT9tZ=U7a51abpdwwEA@mail.gmail.com>
 <01255c85-70f1-9860-dd86-a0a8434b3db6@oracle.com>
Message-ID: <CAPYFHW3bA3gu_RM=SEWCD6+u9h=pyMpNky55OYNw_JueucLHvQ@mail.gmail.com>

Thanks for the attention, Daniel.  You may want to consider adjusting it so
that the behavior of .level and .handlers are consistent with each other,
if they aren't...  I don't think that should break anyone significantly.

Jeremy

On Fri, Nov 10, 2017 at 1:20 PM, Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Jeremy,
>
> I will propose a fix then.
>
> However be aware that logging configuration files that use ".handlers"
> instead of "handlers" to configure the root logger are fragile, as it
> seems that any subsequent call to LogManager.readConfiguration() will
> remove this configuration. Though I agree this might not be an issue
> if it has stayed unnoticed for 15 years.
>
> I will need to verify the behavior of ".level".
> Thanks for pointing that out. I don't think it has the same flaw but
> I will need to make sure.
>
> best regards,
>
> -- daniel
>
> On 10/11/17 20:48, Jeremy Manson wrote:
>
>> Daniel,
>>
>> Thanks for taking a look at this.  I'd like to disagree with the
>> reasoning here.
>>
>> First, it isn't just JDKs 7 and 8 - the behavior is the same all the way
>> back to JDK 1.4, when the java.util.logging API was introduced.  So changes
>> affect 15 years' worth of logging configuration files.  For example, there
>> are no fewer than 350 instances of this pattern in our codebase.  Imagine
>> multiplying that across the entire world - everyone who is doing this has
>> to change their configuration.  That's a pretty big cost to introduce on
>> the developer community.
>>
>> This is worse on legacy systems, because the handlers property was broken
>> for a long time, and people basically had to use .handlers:
>> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6207335.
>>
>> Second, it is inconsistent for ".level" to work for level for the root
>> logger, and ".handlers" not to work for handlers for the root logger.  The
>> empty string represents the root logger, and having it only represent the
>> root logger sometimes is (to me) counterintuitive.  Without checking, my
>> suspicion is that .level behaves the same way as .handlers (that is, it is
>> only loaded once).  If we can live with the inconsistency there, we can
>> live with it here.  You can even document that that is the difference.
>>
>> Jeremy
>>
>>
>> On Fri, Nov 10, 2017 at 8:04 AM, Daniel Fuchs <daniel.fuchs at oracle.com
>> <mailto:daniel.fuchs at oracle.com>> wrote:
>>
>>     Hi Jason,
>>
>>     I have done a few tests with JDK 8 & 7.
>>
>>     I have created custom handlers and added some
>>     debug traces in their constructors and debug methods.
>>
>>     Then I have added these two lines to my logging.properties:
>>
>>     handlers = custom.Handler
>>     .handlers = custom.DotHandler
>>
>>     What I see is this:
>>
>>     - the first time the configuration is read, two handlers
>>        are added to the root logger:
>>        - an instance of DotHandler (first), then an instance
>>          of Handler (second).
>>
>>     Then if you call LogManager.readConfiguration() again,
>>     both handlers are closed, and this time only one
>>     instance of Handler is added to the root logger.
>>     No instance of DotHandler is added.
>>      From now on the property is ignored.
>>
>>     This is because the root logger is a special beast:
>>     it will not be removed (like all other loggers) when
>>     LogManager.readConfiguration() is called.
>>
>>     And as it happens, handlers are added to loggers
>>     when the loggers are added to the LogManager.
>>     As it happens, the ".handlers" property is only parsed
>>     and read when the root logger is added to the LogManager,
>>     and thus only once.
>>
>>     The "handlers" property on the other hand is parsed
>>     every time LogManager.readConfiguration() is called.
>>
>>     Given that, I suspect we should deprecate the use of
>>     ".handlers" for the root logger, as it appears that
>>     it has never worked properly. I could work on a patch
>>     for 10 (possibly backport it to 9 update) to preserve
>>     the strange behavior of 7 & 8, but is it worth it?
>>
>>     What are your thoughts?
>>
>>     best regards,
>>
>>     -- daniel
>>
>>
>>
>>
>>
>>     On 09/11/2017 19:50, Jason Mehrens wrote:
>>
>>         Daniel,
>>
>>         I would assume you would fix since it is advertised as a feature
>>         over here:
>>         https://docs.oracle.com/javase/1.5.0/docs/guide/logging/
>> changes.html
>>         <https://docs.oracle.com/javase/1.5.0/docs/guide/logging/
>> changes.html>
>>
>>         If it helps, I've dug up a lot of the history on this over here
>>         a while back:
>>         https://stackoverflow.com/questions/36726431/in-a-java-util-
>> logging-logging-properties-file-whats-the-difference-between-h
>>         <https://stackoverflow.com/questions/36726431/in-a-java-util
>> -logging-logging-properties-file-whats-the-difference-between-h>
>>
>>         I've updated that to include the links to this new issue.  Now
>>         that I've linked this message thread to that message thread that
>>         should crash the internet. :)
>>
>>         Jason
>>
>>         ________________________________________
>>         From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net
>>         <mailto:core-libs-dev-bounces at openjdk.java.net>> on behalf of
>>         Daniel Fuchs <daniel.fuchs at oracle.com
>>         <mailto:daniel.fuchs at oracle.com>>
>>         Sent: Thursday, November 9, 2017 1:29 PM
>>         To: mandy chung
>>         Cc: core-libs-dev at openjdk.java.net
>>         <mailto:core-libs-dev at openjdk.java.net>
>>         Subject: Re: Change in properties for logging: deliberate?
>>
>>         On 09/11/2017 19:16, mandy chung wrote:
>>
>>             Daniel - we should add this known issue in the release note
>>             and document
>>             the workaround.
>>
>>
>>         Hi Mandy,
>>
>>         Right, it either need to be fixed, or documented in the release
>>         notes. Let me first have a look at the issue though.
>>
>>         best regards,
>>
>>         -- daniel
>>
>>
>>
>>
>

From daniel.fuchs at oracle.com  Sat Nov 11 00:22:32 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Sat, 11 Nov 2017 00:22:32 +0000
Subject: Change in properties for logging: deliberate?
In-Reply-To: <CAPYFHW3bA3gu_RM=SEWCD6+u9h=pyMpNky55OYNw_JueucLHvQ@mail.gmail.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
 <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
 <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>
 <CAPYFHW0zNys6RwDLrCdw31oWbL7dZiHou7cMqXQSF5E5xk6Oug@mail.gmail.com>
 <59156c8a-8622-99b9-7a2f-b0c161868b4f@oracle.com>
 <5d3ffed1-6c0d-d2f2-a541-a82d5ed8ebd5@oracle.com>
 <f1d8e738-0516-cdda-da19-989ae479911e@oracle.com>
 <DM5PR1801MB19458C8FEEEEABA67E21DBDE83570@DM5PR1801MB1945.namprd18.prod.outlook.com>
 <9d326eca-e94f-cfb2-6daf-e9db456050ff@oracle.com>
 <CAPYFHW3HP6O2UwPk95h=4z5j+ZGO2o0mT9tZ=U7a51abpdwwEA@mail.gmail.com>
 <01255c85-70f1-9860-dd86-a0a8434b3db6@oracle.com>
 <CAPYFHW3bA3gu_RM=SEWCD6+u9h=pyMpNky55OYNw_JueucLHvQ@mail.gmail.com>
Message-ID: <97a7afad-4a6c-04cb-14c5-6e428d570df4@oracle.com>

Hi Jeremy,

On 10/11/17 23:24, Jeremy Manson wrote:
> Thanks for the attention, Daniel.? You may want to consider adjusting it 
> so that the behavior of .level and .handlers are consistent with each 
> other, if they aren't...? I don't think that should break anyone 
> significantly.

I think the way .handlers works in 7 and 8 (and probably earlier) is
a bug. It should work like "handlers" - but I am not sure it should
be changed now as some applications might depend on it: it seems
safer to simply fix 10 and 9 to match the earlier behavior and have
all releases work the same.


best regards,

-- daniel

> 
> Jeremy
> 
> On Fri, Nov 10, 2017 at 1:20 PM, Daniel Fuchs <daniel.fuchs at oracle.com 
> <mailto:daniel.fuchs at oracle.com>> wrote:
> 
>     Hi Jeremy,
> 
>     I will propose a fix then.
> 
>     However be aware that logging configuration files that use ".handlers"
>     instead of "handlers" to configure the root logger are fragile, as it
>     seems that any subsequent call to LogManager.readConfiguration() will
>     remove this configuration. Though I agree this might not be an issue
>     if it has stayed unnoticed for 15 years.
> 
>     I will need to verify the behavior of ".level".
>     Thanks for pointing that out. I don't think it has the same flaw but
>     I will need to make sure.
> 
>     best regards,
> 
>     -- daniel
> 
>     On 10/11/17 20:48, Jeremy Manson wrote:
> 
>         Daniel,
> 
>         Thanks for taking a look at this.? I'd like to disagree with the
>         reasoning here.
> 
>         First, it isn't just JDKs 7 and 8 - the behavior is the same all
>         the way back to JDK 1.4, when the java.util.logging API was
>         introduced.? So changes affect 15 years' worth of logging
>         configuration files.? For example, there are no fewer than 350
>         instances of this pattern in our codebase.? Imagine multiplying
>         that across the entire world - everyone who is doing this has to
>         change their configuration.? That's a pretty big cost to
>         introduce on the developer community.
> 
>         This is worse on legacy systems, because the handlers property
>         was broken for a long time, and people basically had to use
>         .handlers:
>         http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6207335
>         <http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6207335>.
> 
>         Second, it is inconsistent for ".level" to work for level for
>         the root logger, and ".handlers" not to work for handlers for
>         the root logger.? The empty string represents the root logger,
>         and having it only represent the root logger sometimes is (to
>         me) counterintuitive.? Without checking, my suspicion is that
>         .level behaves the same way as .handlers (that is, it is only
>         loaded once).? If we can live with the inconsistency there, we
>         can live with it here.? You can even document that that is the
>         difference.
> 
>         Jeremy
> 
> 
>         On Fri, Nov 10, 2017 at 8:04 AM, Daniel Fuchs
>         <daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>
>         <mailto:daniel.fuchs at oracle.com
>         <mailto:daniel.fuchs at oracle.com>>> wrote:
> 
>          ? ? Hi Jason,
> 
>          ? ? I have done a few tests with JDK 8 & 7.
> 
>          ? ? I have created custom handlers and added some
>          ? ? debug traces in their constructors and debug methods.
> 
>          ? ? Then I have added these two lines to my logging.properties:
> 
>          ? ? handlers = custom.Handler
>          ? ? .handlers = custom.DotHandler
> 
>          ? ? What I see is this:
> 
>          ? ? - the first time the configuration is read, two handlers
>          ? ? ?? are added to the root logger:
>          ? ? ?? - an instance of DotHandler (first), then an instance
>          ? ? ?? ? of Handler (second).
> 
>          ? ? Then if you call LogManager.readConfiguration() again,
>          ? ? both handlers are closed, and this time only one
>          ? ? instance of Handler is added to the root logger.
>          ? ? No instance of DotHandler is added.
>          ? ? ?From now on the property is ignored.
> 
>          ? ? This is because the root logger is a special beast:
>          ? ? it will not be removed (like all other loggers) when
>          ? ? LogManager.readConfiguration() is called.
> 
>          ? ? And as it happens, handlers are added to loggers
>          ? ? when the loggers are added to the LogManager.
>          ? ? As it happens, the ".handlers" property is only parsed
>          ? ? and read when the root logger is added to the LogManager,
>          ? ? and thus only once.
> 
>          ? ? The "handlers" property on the other hand is parsed
>          ? ? every time LogManager.readConfiguration() is called.
> 
>          ? ? Given that, I suspect we should deprecate the use of
>          ? ? ".handlers" for the root logger, as it appears that
>          ? ? it has never worked properly. I could work on a patch
>          ? ? for 10 (possibly backport it to 9 update) to preserve
>          ? ? the strange behavior of 7 & 8, but is it worth it?
> 
>          ? ? What are your thoughts?
> 
>          ? ? best regards,
> 
>          ? ? -- daniel
> 
> 
> 
> 
> 
>          ? ? On 09/11/2017 19:50, Jason Mehrens wrote:
> 
>          ? ? ? ? Daniel,
> 
>          ? ? ? ? I would assume you would fix since it is advertised as
>         a feature
>          ? ? ? ? over here:
>         https://docs.oracle.com/javase/1.5.0/docs/guide/logging/changes.html
>         <https://docs.oracle.com/javase/1.5.0/docs/guide/logging/changes.html>
>                 
>         <https://docs.oracle.com/javase/1.5.0/docs/guide/logging/changes.html
>         <https://docs.oracle.com/javase/1.5.0/docs/guide/logging/changes.html>>
> 
>          ? ? ? ? If it helps, I've dug up a lot of the history on this
>         over here
>          ? ? ? ? a while back:
>         https://stackoverflow.com/questions/36726431/in-a-java-util-logging-logging-properties-file-whats-the-difference-between-h
>         <https://stackoverflow.com/questions/36726431/in-a-java-util-logging-logging-properties-file-whats-the-difference-between-h>
>                 
>         <https://stackoverflow.com/questions/36726431/in-a-java-util-logging-logging-properties-file-whats-the-difference-between-h
>         <https://stackoverflow.com/questions/36726431/in-a-java-util-logging-logging-properties-file-whats-the-difference-between-h>>
> 
>          ? ? ? ? I've updated that to include the links to this new
>         issue.? Now
>          ? ? ? ? that I've linked this message thread to that message
>         thread that
>          ? ? ? ? should crash the internet. :)
> 
>          ? ? ? ? Jason
> 
>          ? ? ? ? ________________________________________
>          ? ? ? ? From: core-libs-dev
>         <core-libs-dev-bounces at openjdk.java.net
>         <mailto:core-libs-dev-bounces at openjdk.java.net>
>          ? ? ? ? <mailto:core-libs-dev-bounces at openjdk.java.net
>         <mailto:core-libs-dev-bounces at openjdk.java.net>>> on behalf of
>          ? ? ? ? Daniel Fuchs <daniel.fuchs at oracle.com
>         <mailto:daniel.fuchs at oracle.com>
>          ? ? ? ? <mailto:daniel.fuchs at oracle.com
>         <mailto:daniel.fuchs at oracle.com>>>
>          ? ? ? ? Sent: Thursday, November 9, 2017 1:29 PM
>          ? ? ? ? To: mandy chung
>          ? ? ? ? Cc: core-libs-dev at openjdk.java.net
>         <mailto:core-libs-dev at openjdk.java.net>
>          ? ? ? ? <mailto:core-libs-dev at openjdk.java.net
>         <mailto:core-libs-dev at openjdk.java.net>>
>          ? ? ? ? Subject: Re: Change in properties for logging: deliberate?
> 
>          ? ? ? ? On 09/11/2017 19:16, mandy chung wrote:
> 
>          ? ? ? ? ? ? Daniel - we should add this known issue in the
>         release note
>          ? ? ? ? ? ? and document
>          ? ? ? ? ? ? the workaround.
> 
> 
>          ? ? ? ? Hi Mandy,
> 
>          ? ? ? ? Right, it either need to be fixed, or documented in the
>         release
>          ? ? ? ? notes. Let me first have a look at the issue though.
> 
>          ? ? ? ? best regards,
> 
>          ? ? ? ? -- daniel
> 
> 
> 
> 
> 


From venkatec at linux.vnet.ibm.com  Sat Nov 11 05:53:46 2017
From: venkatec at linux.vnet.ibm.com (Venkateswara R Chintala)
Date: Sat, 11 Nov 2017 11:23:46 +0530
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
Message-ID: <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>

Thanks Sean. I am pasting the patch here:

--- old/src/java.base/share/classes/java/util/SimpleTimeZone.java 
2017-11-11 11:17:38.643867420 +0530
+++ new/src/java.base/share/classes/java/util/SimpleTimeZone.java 
2017-11-11 11:17:38.375870421 +0530
@@ -868,7 +868,11 @@
 ????? */
 ???? public Object clone()
 ???? {
-??????? return super.clone();
+??????? // Invalidate the time zone cache while cloning as it
+??????? // can be inconsistent due to race condition.
+??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
+??????? tz.invalidateCache();
+??????? return tz;
 ???? }

 ???? /**
--- /dev/null??? 2017-11-02 17:09:59.155627814 +0530
+++ new/test/java/util/TimeZone/SimpleTimeZoneTest.java 2017-11-11 
11:17:38.867864912 +0530
@@ -0,0 +1,55 @@
+/*
+ * @test
+ * @summary Tests the race condition between 
java.util.TimeZone.getDefault() and java.util.GregorianCalendar()
+ * @run main SimpleTimeZoneTest
+*/
+
+import java.util.Calendar;
+import java.util.GregorianCalendar;
+import java.util.SimpleTimeZone;
+import java.util.TimeZone;
+
+public class SimpleTimeZoneTest extends Thread {
+??? Calendar cal;
+
+??? public SimpleTimeZoneTest (Calendar cal) {
+??????? this.cal = cal;
+??? }
+
+??? public static void main (String[] args) {
+??????? TimeZone stz = new SimpleTimeZone(7200000, "Asia/Jerusalem", 
Calendar.MARCH, 27, 0, 3600000, Calendar.SEPTEMBER, 16, 0, 3600000);
+??????? TimeZone.setDefault(stz);
+
+??????? SimpleTimeZoneTest stt = new SimpleTimeZoneTest(new 
GregorianCalendar());
+??????? stt.setDaemon(true);
+??????? stt.start();
+
+??????? for (int i = 0; i < 50000; i++) {
+??????????? Calendar cal = new GregorianCalendar();
+??????????? cal.clear();
+??????????? cal.getTimeInMillis();
+??????????? cal.set(2014, 2, 2);
+??????????? cal.clear();
+??????????? cal.getTimeInMillis();
+??????????? cal.set(1970, 2, 2);
+??????? }
+
+??? }
+
+??? public void run() {
+??????? while (true) {
+??????????? cal.setTimeZone(TimeZone.getDefault());
+??????????? cal.clear();
+??????????? cal.set(2008, 9, 9);
+??????????? Calendar calInst = java.util.Calendar.getInstance();
+??????????? calInst.setTimeInMillis(cal.getTimeInMillis());
+
+??????????? if (calInst.get(java.util.Calendar.HOUR_OF_DAY) != 
cal.get(java.util.Calendar.HOUR_OF_DAY) ||
+??????????????? calInst.get(java.util.Calendar.MINUTE) != 
cal.get(java.util.Calendar.MINUTE) ||
+??????????????? calInst.get(java.util.Calendar.SECOND) != 
cal.get(java.util.Calendar.SECOND) ||
+??????????????? calInst.get(java.util.Calendar.MILLISECOND) != 
cal.get(java.util.Calendar.MILLISECOND)) {
+??????????????????? throw new RuntimeException("Test failed");
+??????????? }
+??????? }
+??? }
+}


On 10/11/17 9:29 PM, Se?n Coffey wrote:
> I think the OpenJDK mailing lists accept attachments if in patch 
> format. If it's a simple short patch, it's acceptable to paste it into 
> email body.
>
> Easiest solution is to use webrev[1]. If you can't upload this to 
> cr.openjdk.java.net - then one of your colleagues may be able to help.
>
> [1] http://openjdk.java.net/guide/webrevHelp.html
>
> Regards,
> Sean.
>
> On 10/11/17 12:18, Venkateswara R Chintala wrote:
>> Looks like the patch attached earlier is not visible. As this is my 
>> first contribution, please let me know how I can send the patch for 
>> review.
>>
>>
>> On 10/11/17 5:37 PM, Venkateswara R Chintala wrote:
>>> Hi,
>>>
>>> In a multi-threaded environment, when java.util.SimpleTimeZone 
>>> object is used to create a default timezone, there can be a race 
>>> condition between the methods java.util.Timezone.getDefault() and 
>>> java.util.Timezone.getDefaultRef() which can result in inconsistency 
>>> of cache that is used to validate a particular time/date in DST.
>>>
>>> When a thread is cloning a default timezone object (SimpleTimeZone) 
>>> and at the same time if a different thread modifies the time/year 
>>> values, then the cache values (cacheYear, cacheStart, cacheEnd) can 
>>> become inconsistent which leads to incorrect DST determination.
>>>
>>> We considered two approaches to fix the issue.
>>>
>>> 1)Synchronize access to cloning default timezone object when cache 
>>> is being modified.
>>>
>>> 2)Invalidate the cache while returning the clone.
>>>
>>> We preferred the second option as synchronization is more expensive.
>>>
>>> We have attached the patch and jtreg testcase. Please review.
>>>
>>
>
>

-- 
Regards
-Venkat


From david.holmes at oracle.com  Sat Nov 11 06:51:45 2017
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 11 Nov 2017 16:51:45 +1000
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
Message-ID: <798167c6-c562-f247-b77b-b6da38bcce9e@oracle.com>

AFAICS SimpleTimeZone is simply not thread-safe. It has state that can 
be modified concurrently without synchronization and with fields not 
even declared volatile. Only the "cache" makes an attempt to use 
synchronization. So clone() is never guaranteed to actually produce a 
copy with valid/consistent field values.

The suggested patch certainly improves the situation by at least 
resetting the cache of the cloned instance before returning it.

David

On 11/11/2017 3:53 PM, Venkateswara R Chintala wrote:
> Thanks Sean. I am pasting the patch here:
> 
> --- old/src/java.base/share/classes/java/util/SimpleTimeZone.java 
> 2017-11-11 11:17:38.643867420 +0530
> +++ new/src/java.base/share/classes/java/util/SimpleTimeZone.java 
> 2017-11-11 11:17:38.375870421 +0530
> @@ -868,7 +868,11 @@
>  ????? */
>  ???? public Object clone()
>  ???? {
> -??????? return super.clone();
> +??????? // Invalidate the time zone cache while cloning as it
> +??????? // can be inconsistent due to race condition.
> +??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
> +??????? tz.invalidateCache();
> +??????? return tz;
>  ???? }
> 
>  ???? /**
> --- /dev/null??? 2017-11-02 17:09:59.155627814 +0530
> +++ new/test/java/util/TimeZone/SimpleTimeZoneTest.java 2017-11-11 
> 11:17:38.867864912 +0530
> @@ -0,0 +1,55 @@
> +/*
> + * @test
> + * @summary Tests the race condition between 
> java.util.TimeZone.getDefault() and java.util.GregorianCalendar()
> + * @run main SimpleTimeZoneTest
> +*/
> +
> +import java.util.Calendar;
> +import java.util.GregorianCalendar;
> +import java.util.SimpleTimeZone;
> +import java.util.TimeZone;
> +
> +public class SimpleTimeZoneTest extends Thread {
> +??? Calendar cal;
> +
> +??? public SimpleTimeZoneTest (Calendar cal) {
> +??????? this.cal = cal;
> +??? }
> +
> +??? public static void main (String[] args) {
> +??????? TimeZone stz = new SimpleTimeZone(7200000, "Asia/Jerusalem", 
> Calendar.MARCH, 27, 0, 3600000, Calendar.SEPTEMBER, 16, 0, 3600000);
> +??????? TimeZone.setDefault(stz);
> +
> +??????? SimpleTimeZoneTest stt = new SimpleTimeZoneTest(new 
> GregorianCalendar());
> +??????? stt.setDaemon(true);
> +??????? stt.start();
> +
> +??????? for (int i = 0; i < 50000; i++) {
> +??????????? Calendar cal = new GregorianCalendar();
> +??????????? cal.clear();
> +??????????? cal.getTimeInMillis();
> +??????????? cal.set(2014, 2, 2);
> +??????????? cal.clear();
> +??????????? cal.getTimeInMillis();
> +??????????? cal.set(1970, 2, 2);
> +??????? }
> +
> +??? }
> +
> +??? public void run() {
> +??????? while (true) {
> +??????????? cal.setTimeZone(TimeZone.getDefault());
> +??????????? cal.clear();
> +??????????? cal.set(2008, 9, 9);
> +??????????? Calendar calInst = java.util.Calendar.getInstance();
> +??????????? calInst.setTimeInMillis(cal.getTimeInMillis());
> +
> +??????????? if (calInst.get(java.util.Calendar.HOUR_OF_DAY) != 
> cal.get(java.util.Calendar.HOUR_OF_DAY) ||
> +??????????????? calInst.get(java.util.Calendar.MINUTE) != 
> cal.get(java.util.Calendar.MINUTE) ||
> +??????????????? calInst.get(java.util.Calendar.SECOND) != 
> cal.get(java.util.Calendar.SECOND) ||
> +??????????????? calInst.get(java.util.Calendar.MILLISECOND) != 
> cal.get(java.util.Calendar.MILLISECOND)) {
> +??????????????????? throw new RuntimeException("Test failed");
> +??????????? }
> +??????? }
> +??? }
> +}
> 
> 
> On 10/11/17 9:29 PM, Se?n Coffey wrote:
>> I think the OpenJDK mailing lists accept attachments if in patch 
>> format. If it's a simple short patch, it's acceptable to paste it into 
>> email body.
>>
>> Easiest solution is to use webrev[1]. If you can't upload this to 
>> cr.openjdk.java.net - then one of your colleagues may be able to help.
>>
>> [1] http://openjdk.java.net/guide/webrevHelp.html
>>
>> Regards,
>> Sean.
>>
>> On 10/11/17 12:18, Venkateswara R Chintala wrote:
>>> Looks like the patch attached earlier is not visible. As this is my 
>>> first contribution, please let me know how I can send the patch for 
>>> review.
>>>
>>>
>>> On 10/11/17 5:37 PM, Venkateswara R Chintala wrote:
>>>> Hi,
>>>>
>>>> In a multi-threaded environment, when java.util.SimpleTimeZone 
>>>> object is used to create a default timezone, there can be a race 
>>>> condition between the methods java.util.Timezone.getDefault() and 
>>>> java.util.Timezone.getDefaultRef() which can result in inconsistency 
>>>> of cache that is used to validate a particular time/date in DST.
>>>>
>>>> When a thread is cloning a default timezone object (SimpleTimeZone) 
>>>> and at the same time if a different thread modifies the time/year 
>>>> values, then the cache values (cacheYear, cacheStart, cacheEnd) can 
>>>> become inconsistent which leads to incorrect DST determination.
>>>>
>>>> We considered two approaches to fix the issue.
>>>>
>>>> 1)Synchronize access to cloning default timezone object when cache 
>>>> is being modified.
>>>>
>>>> 2)Invalidate the cache while returning the clone.
>>>>
>>>> We preferred the second option as synchronization is more expensive.
>>>>
>>>> We have attached the patch and jtreg testcase. Please review.
>>>>
>>>
>>
>>
> 

From peter.levart at gmail.com  Sat Nov 11 10:06:30 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 11 Nov 2017 11:06:30 +0100
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
Message-ID: <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>

Hi Venkateswara R Chintala,

I would like to remind that TimeZone.clone() is also in the code path of 
java.time.ZoneId.systemDefault() where it was relied on to be optimized 
by JIT to never actually allocate the cloned TimeZone object by 
employing escape analysis. It would be nice to verify if this patch 
keeps that behavior. To test this, consider a JMH benchmark that simply 
invokes ZoneId.systemDefault() and returns it from the test method. 1st 
verify that unmodified code, when JITed, performs no allocations. Then 
test with modified code by applying the patch and see if there's any 
difference. Hint: use "-prof gc" command line options to run the 
benchmarks.jar.

Regards, Peter


On 11/11/17 06:53, Venkateswara R Chintala wrote:
> Thanks Sean. I am pasting the patch here:
>
> --- old/src/java.base/share/classes/java/util/SimpleTimeZone.java 
> 2017-11-11 11:17:38.643867420 +0530
> +++ new/src/java.base/share/classes/java/util/SimpleTimeZone.java 
> 2017-11-11 11:17:38.375870421 +0530
> @@ -868,7 +868,11 @@
> ????? */
> ???? public Object clone()
> ???? {
> -??????? return super.clone();
> +??????? // Invalidate the time zone cache while cloning as it
> +??????? // can be inconsistent due to race condition.
> +??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
> +??????? tz.invalidateCache();
> +??????? return tz;
> ???? }
>
> ???? /**
> --- /dev/null??? 2017-11-02 17:09:59.155627814 +0530
> +++ new/test/java/util/TimeZone/SimpleTimeZoneTest.java 2017-11-11 
> 11:17:38.867864912 +0530
> @@ -0,0 +1,55 @@
> +/*
> + * @test
> + * @summary Tests the race condition between 
> java.util.TimeZone.getDefault() and java.util.GregorianCalendar()
> + * @run main SimpleTimeZoneTest
> +*/
> +
> +import java.util.Calendar;
> +import java.util.GregorianCalendar;
> +import java.util.SimpleTimeZone;
> +import java.util.TimeZone;
> +
> +public class SimpleTimeZoneTest extends Thread {
> +??? Calendar cal;
> +
> +??? public SimpleTimeZoneTest (Calendar cal) {
> +??????? this.cal = cal;
> +??? }
> +
> +??? public static void main (String[] args) {
> +??????? TimeZone stz = new SimpleTimeZone(7200000, "Asia/Jerusalem", 
> Calendar.MARCH, 27, 0, 3600000, Calendar.SEPTEMBER, 16, 0, 3600000);
> +??????? TimeZone.setDefault(stz);
> +
> +??????? SimpleTimeZoneTest stt = new SimpleTimeZoneTest(new 
> GregorianCalendar());
> +??????? stt.setDaemon(true);
> +??????? stt.start();
> +
> +??????? for (int i = 0; i < 50000; i++) {
> +??????????? Calendar cal = new GregorianCalendar();
> +??????????? cal.clear();
> +??????????? cal.getTimeInMillis();
> +??????????? cal.set(2014, 2, 2);
> +??????????? cal.clear();
> +??????????? cal.getTimeInMillis();
> +??????????? cal.set(1970, 2, 2);
> +??????? }
> +
> +??? }
> +
> +??? public void run() {
> +??????? while (true) {
> +??????????? cal.setTimeZone(TimeZone.getDefault());
> +??????????? cal.clear();
> +??????????? cal.set(2008, 9, 9);
> +??????????? Calendar calInst = java.util.Calendar.getInstance();
> +??????????? calInst.setTimeInMillis(cal.getTimeInMillis());
> +
> +??????????? if (calInst.get(java.util.Calendar.HOUR_OF_DAY) != 
> cal.get(java.util.Calendar.HOUR_OF_DAY) ||
> +??????????????? calInst.get(java.util.Calendar.MINUTE) != 
> cal.get(java.util.Calendar.MINUTE) ||
> +??????????????? calInst.get(java.util.Calendar.SECOND) != 
> cal.get(java.util.Calendar.SECOND) ||
> +??????????????? calInst.get(java.util.Calendar.MILLISECOND) != 
> cal.get(java.util.Calendar.MILLISECOND)) {
> +??????????????????? throw new RuntimeException("Test failed");
> +??????????? }
> +??????? }
> +??? }
> +}
>
>
> On 10/11/17 9:29 PM, Se?n Coffey wrote:
>> I think the OpenJDK mailing lists accept attachments if in patch 
>> format. If it's a simple short patch, it's acceptable to paste it 
>> into email body.
>>
>> Easiest solution is to use webrev[1]. If you can't upload this to 
>> cr.openjdk.java.net - then one of your colleagues may be able to help.
>>
>> [1] http://openjdk.java.net/guide/webrevHelp.html
>>
>> Regards,
>> Sean.
>>
>> On 10/11/17 12:18, Venkateswara R Chintala wrote:
>>> Looks like the patch attached earlier is not visible. As this is my 
>>> first contribution, please let me know how I can send the patch for 
>>> review.
>>>
>>>
>>> On 10/11/17 5:37 PM, Venkateswara R Chintala wrote:
>>>> Hi,
>>>>
>>>> In a multi-threaded environment, when java.util.SimpleTimeZone 
>>>> object is used to create a default timezone, there can be a race 
>>>> condition between the methods java.util.Timezone.getDefault() and 
>>>> java.util.Timezone.getDefaultRef() which can result in 
>>>> inconsistency of cache that is used to validate a particular 
>>>> time/date in DST.
>>>>
>>>> When a thread is cloning a default timezone object (SimpleTimeZone) 
>>>> and at the same time if a different thread modifies the time/year 
>>>> values, then the cache values (cacheYear, cacheStart, cacheEnd) can 
>>>> become inconsistent which leads to incorrect DST determination.
>>>>
>>>> We considered two approaches to fix the issue.
>>>>
>>>> 1)Synchronize access to cloning default timezone object when cache 
>>>> is being modified.
>>>>
>>>> 2)Invalidate the cache while returning the clone.
>>>>
>>>> We preferred the second option as synchronization is more expensive.
>>>>
>>>> We have attached the patch and jtreg testcase. Please review.
>>>>
>>>
>>
>>
>


From peter.levart at gmail.com  Sat Nov 11 10:40:42 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 11 Nov 2017 11:40:42 +0100
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
Message-ID: <28d54958-84f1-7bb6-8dd0-f07179eed818@gmail.com>

Hi Venkat,

On 11/10/17 13:07, Venkateswara R Chintala wrote:
> Hi,
>
> In a multi-threaded environment, when java.util.SimpleTimeZone object 
> is used to create a default timezone, there can be a race condition 
> between the methods java.util.Timezone.getDefault() and 
> java.util.Timezone.getDefaultRef() which can result in inconsistency 
> of cache that is used to validate a particular time/date in DST.
>
> When a thread is cloning a default timezone object (SimpleTimeZone) 
> and at the same time if a different thread modifies the time/year 
> values, then the cache values (cacheYear, cacheStart, cacheEnd) can 
> become inconsistent which leads to incorrect DST determination.
>
> We considered two approaches to fix the issue.
>
> 1)Synchronize access to cloning default timezone object when cache is 
> being modified.
>
> 2)Invalidate the cache while returning the clone.
>
> We preferred the second option as synchronization is more expensive.

Unfortunately, the SimpleTimeZone.invalidateCache() is also 
synchronized. So of the same cost, and it may inhibit JIT optimization.

Perhaps it would be best to synchronize cloning and then arrange the 
ZoneId.systemDefault() codepath to not involve cloning. I refrained from 
doing that in a patch for:

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

simply because it was easier and benchmarks showed that cloning is 
optimized away. But now we should reconsider that and use 
TimeZone.getDefaultRef() from the ZoneId.systemDefault() (introducing 
JavaUtilAccess into SharedSecrets mechanism)...


Regards, Peter


From david.holmes at oracle.com  Sat Nov 11 12:37:06 2017
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 11 Nov 2017 22:37:06 +1000
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>
Message-ID: <84ca56e0-67c8-3fbb-d558-4ebe797d513c@oracle.com>

Hi Peter,

On 11/11/2017 8:06 PM, Peter Levart wrote:
> Hi Venkateswara R Chintala,
> 
> I would like to remind that TimeZone.clone() is also in the code path of 
> java.time.ZoneId.systemDefault() where it was relied on to be optimized 
> by JIT to never actually allocate the cloned TimeZone object by 
> employing escape analysis.

remind? Where is this documented?

And given:

     public static TimeZone getDefault() {
         return (TimeZone) getDefaultRef().clone();
     }

how can it not allocate??

David
-----

> It would be nice to verify if this patch 
> keeps that behavior. To test this, consider a JMH benchmark that simply 
> invokes ZoneId.systemDefault() and returns it from the test method. 1st 
> verify that unmodified code, when JITed, performs no allocations. Then 
> test with modified code by applying the patch and see if there's any 
> difference. Hint: use "-prof gc" command line options to run the 
> benchmarks.jar.
> 
> Regards, Peter
> 
> 
> On 11/11/17 06:53, Venkateswara R Chintala wrote:
>> Thanks Sean. I am pasting the patch here:
>>
>> --- old/src/java.base/share/classes/java/util/SimpleTimeZone.java 
>> 2017-11-11 11:17:38.643867420 +0530
>> +++ new/src/java.base/share/classes/java/util/SimpleTimeZone.java 
>> 2017-11-11 11:17:38.375870421 +0530
>> @@ -868,7 +868,11 @@
>> ????? */
>> ???? public Object clone()
>> ???? {
>> -??????? return super.clone();
>> +??????? // Invalidate the time zone cache while cloning as it
>> +??????? // can be inconsistent due to race condition.
>> +??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>> +??????? tz.invalidateCache();
>> +??????? return tz;
>> ???? }
>>
>> ???? /**
>> --- /dev/null??? 2017-11-02 17:09:59.155627814 +0530
>> +++ new/test/java/util/TimeZone/SimpleTimeZoneTest.java 2017-11-11 
>> 11:17:38.867864912 +0530
>> @@ -0,0 +1,55 @@
>> +/*
>> + * @test
>> + * @summary Tests the race condition between 
>> java.util.TimeZone.getDefault() and java.util.GregorianCalendar()
>> + * @run main SimpleTimeZoneTest
>> +*/
>> +
>> +import java.util.Calendar;
>> +import java.util.GregorianCalendar;
>> +import java.util.SimpleTimeZone;
>> +import java.util.TimeZone;
>> +
>> +public class SimpleTimeZoneTest extends Thread {
>> +??? Calendar cal;
>> +
>> +??? public SimpleTimeZoneTest (Calendar cal) {
>> +??????? this.cal = cal;
>> +??? }
>> +
>> +??? public static void main (String[] args) {
>> +??????? TimeZone stz = new SimpleTimeZone(7200000, "Asia/Jerusalem", 
>> Calendar.MARCH, 27, 0, 3600000, Calendar.SEPTEMBER, 16, 0, 3600000);
>> +??????? TimeZone.setDefault(stz);
>> +
>> +??????? SimpleTimeZoneTest stt = new SimpleTimeZoneTest(new 
>> GregorianCalendar());
>> +??????? stt.setDaemon(true);
>> +??????? stt.start();
>> +
>> +??????? for (int i = 0; i < 50000; i++) {
>> +??????????? Calendar cal = new GregorianCalendar();
>> +??????????? cal.clear();
>> +??????????? cal.getTimeInMillis();
>> +??????????? cal.set(2014, 2, 2);
>> +??????????? cal.clear();
>> +??????????? cal.getTimeInMillis();
>> +??????????? cal.set(1970, 2, 2);
>> +??????? }
>> +
>> +??? }
>> +
>> +??? public void run() {
>> +??????? while (true) {
>> +??????????? cal.setTimeZone(TimeZone.getDefault());
>> +??????????? cal.clear();
>> +??????????? cal.set(2008, 9, 9);
>> +??????????? Calendar calInst = java.util.Calendar.getInstance();
>> +??????????? calInst.setTimeInMillis(cal.getTimeInMillis());
>> +
>> +??????????? if (calInst.get(java.util.Calendar.HOUR_OF_DAY) != 
>> cal.get(java.util.Calendar.HOUR_OF_DAY) ||
>> +??????????????? calInst.get(java.util.Calendar.MINUTE) != 
>> cal.get(java.util.Calendar.MINUTE) ||
>> +??????????????? calInst.get(java.util.Calendar.SECOND) != 
>> cal.get(java.util.Calendar.SECOND) ||
>> +??????????????? calInst.get(java.util.Calendar.MILLISECOND) != 
>> cal.get(java.util.Calendar.MILLISECOND)) {
>> +??????????????????? throw new RuntimeException("Test failed");
>> +??????????? }
>> +??????? }
>> +??? }
>> +}
>>
>>
>> On 10/11/17 9:29 PM, Se?n Coffey wrote:
>>> I think the OpenJDK mailing lists accept attachments if in patch 
>>> format. If it's a simple short patch, it's acceptable to paste it 
>>> into email body.
>>>
>>> Easiest solution is to use webrev[1]. If you can't upload this to 
>>> cr.openjdk.java.net - then one of your colleagues may be able to help.
>>>
>>> [1] http://openjdk.java.net/guide/webrevHelp.html
>>>
>>> Regards,
>>> Sean.
>>>
>>> On 10/11/17 12:18, Venkateswara R Chintala wrote:
>>>> Looks like the patch attached earlier is not visible. As this is my 
>>>> first contribution, please let me know how I can send the patch for 
>>>> review.
>>>>
>>>>
>>>> On 10/11/17 5:37 PM, Venkateswara R Chintala wrote:
>>>>> Hi,
>>>>>
>>>>> In a multi-threaded environment, when java.util.SimpleTimeZone 
>>>>> object is used to create a default timezone, there can be a race 
>>>>> condition between the methods java.util.Timezone.getDefault() and 
>>>>> java.util.Timezone.getDefaultRef() which can result in 
>>>>> inconsistency of cache that is used to validate a particular 
>>>>> time/date in DST.
>>>>>
>>>>> When a thread is cloning a default timezone object (SimpleTimeZone) 
>>>>> and at the same time if a different thread modifies the time/year 
>>>>> values, then the cache values (cacheYear, cacheStart, cacheEnd) can 
>>>>> become inconsistent which leads to incorrect DST determination.
>>>>>
>>>>> We considered two approaches to fix the issue.
>>>>>
>>>>> 1)Synchronize access to cloning default timezone object when cache 
>>>>> is being modified.
>>>>>
>>>>> 2)Invalidate the cache while returning the clone.
>>>>>
>>>>> We preferred the second option as synchronization is more expensive.
>>>>>
>>>>> We have attached the patch and jtreg testcase. Please review.
>>>>>
>>>>
>>>
>>>
>>
> 

From spliterator at gmail.com  Sat Nov 11 15:58:45 2017
From: spliterator at gmail.com (Stefan Zobel)
Date: Sat, 11 Nov 2017 16:58:45 +0100
Subject: RFR 8190974 Parallel stream execution within a custom
 ForkJoinPool should obey the parallelism
In-Reply-To: <CFFC012D-28A8-4CEB-853E-ACE60041C4FA@oracle.com>
References: <CFFC012D-28A8-4CEB-853E-ACE60041C4FA@oracle.com>
Message-ID: <CAPkkuSegTQeWus9ju+9T5iKg83metWX9-mvDUnoZtJNs03w+-w@mail.gmail.com>

In CustomFJPoolTest#testCustomPools()

>>    assertEquals(splitsForPC, splitsForPHalfC * 2);


I'm sure I'm slow on the uptake, but isn't this bound to
fail for every commonParallelism == 2^n + 1 in the closed
range [2, 127], i.e., for 3, 5, 9, 17, 33, 65?

Regards,
Stefan


2017-11-08 22:01 GMT+01:00 Paul Sandoz <paul.sandoz at oracle.com>:
> Hi,
>
> Please review this patch to ensure that a parallel stream obeys the parallelism of a custom fork join pool when it is executed within that pool:
>
>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/>
>
> Streams currently do not support capabilities to control the level of parallelism and therefore resources utilised (tricky API design problem to get right).
>
> At the moment the trick is to run stream executions within a custom pool, however the number of fork join tasks created will be in proportion to the parallelism of the common pool thus the execution will be over-provisioned. This can be especially noticeable on large machines with many cores.
>
> Paul.

From peter.levart at gmail.com  Sat Nov 11 20:15:10 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 11 Nov 2017 21:15:10 +0100
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <84ca56e0-67c8-3fbb-d558-4ebe797d513c@oracle.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>
 <84ca56e0-67c8-3fbb-d558-4ebe797d513c@oracle.com>
Message-ID: <8894f619-3510-acfa-3987-f013ca3638f3@gmail.com>

Hi David,

On 11/11/17 13:37, David Holmes wrote:
> Hi Peter,
>
> On 11/11/2017 8:06 PM, Peter Levart wrote:
>> Hi Venkateswara R Chintala,
>>
>> I would like to remind that TimeZone.clone() is also in the code path 
>> of java.time.ZoneId.systemDefault() where it was relied on to be 
>> optimized by JIT to never actually allocate the cloned TimeZone 
>> object by employing escape analysis.
>
> remind? Where is this documented?

Unfortunately it is not documented. My bad. I did test it at the time 
and determined that ZoneId.systemDefault(), with my patch applied, did 
not do allocations when JIT kicked-in. So we settled for an easier variant:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.04/

instead of a more complicated one that uses SharedSecrets to avoid cloning:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/

>
> And given:
>
> ??? public static TimeZone getDefault() {
> ??????? return (TimeZone) getDefaultRef().clone();
> ??? }
>
> how can it not allocate??

When JIT compiles some method and inlines called methods, it also 
analyses all allocations performed to see if some of them can be proved 
to not escape the invocation of that compiled method. It then eliminates 
allocations of such objects on heap and rather generates code that keeps 
their state in registers or stack.

For example, take the following method:

String defaultTZID() {
 ??? return TimeZone.getDefault().getID();
}

When JIT compiles it and inlines invocations to other methods within it, 
it can prove that cloned TimeZone instance never escapes the call to 
defaultTZID() and can therefore skip allocating the instance on heap.

But this is fragile. If code in invoked methods changes, they may not 
get inlined or EA may not be able to prove that the cloned instance 
can't escape and allocation may be introduced. ZoneId.systemDefault() is 
a hot method and it would be nice if we manage to keep it allocation free.

Regards, Peter

>
> David
> -----
>
>> It would be nice to verify if this patch keeps that behavior. To test 
>> this, consider a JMH benchmark that simply invokes 
>> ZoneId.systemDefault() and returns it from the test method. 1st 
>> verify that unmodified code, when JITed, performs no allocations. 
>> Then test with modified code by applying the patch and see if there's 
>> any difference. Hint: use "-prof gc" command line options to run the 
>> benchmarks.jar.
>>
>> Regards, Peter
>>
>>
>> On 11/11/17 06:53, Venkateswara R Chintala wrote:
>>> Thanks Sean. I am pasting the patch here:
>>>
>>> --- old/src/java.base/share/classes/java/util/SimpleTimeZone.java 
>>> 2017-11-11 11:17:38.643867420 +0530
>>> +++ new/src/java.base/share/classes/java/util/SimpleTimeZone.java 
>>> 2017-11-11 11:17:38.375870421 +0530
>>> @@ -868,7 +868,11 @@
>>> ????? */
>>> ???? public Object clone()
>>> ???? {
>>> -??????? return super.clone();
>>> +??????? // Invalidate the time zone cache while cloning as it
>>> +??????? // can be inconsistent due to race condition.
>>> +??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>> +??????? tz.invalidateCache();
>>> +??????? return tz;
>>> ???? }
>>>
>>> ???? /**
>>> --- /dev/null??? 2017-11-02 17:09:59.155627814 +0530
>>> +++ new/test/java/util/TimeZone/SimpleTimeZoneTest.java 2017-11-11 
>>> 11:17:38.867864912 +0530
>>> @@ -0,0 +1,55 @@
>>> +/*
>>> + * @test
>>> + * @summary Tests the race condition between 
>>> java.util.TimeZone.getDefault() and java.util.GregorianCalendar()
>>> + * @run main SimpleTimeZoneTest
>>> +*/
>>> +
>>> +import java.util.Calendar;
>>> +import java.util.GregorianCalendar;
>>> +import java.util.SimpleTimeZone;
>>> +import java.util.TimeZone;
>>> +
>>> +public class SimpleTimeZoneTest extends Thread {
>>> +??? Calendar cal;
>>> +
>>> +??? public SimpleTimeZoneTest (Calendar cal) {
>>> +??????? this.cal = cal;
>>> +??? }
>>> +
>>> +??? public static void main (String[] args) {
>>> +??????? TimeZone stz = new SimpleTimeZone(7200000, 
>>> "Asia/Jerusalem", Calendar.MARCH, 27, 0, 3600000, 
>>> Calendar.SEPTEMBER, 16, 0, 3600000);
>>> +??????? TimeZone.setDefault(stz);
>>> +
>>> +??????? SimpleTimeZoneTest stt = new SimpleTimeZoneTest(new 
>>> GregorianCalendar());
>>> +??????? stt.setDaemon(true);
>>> +??????? stt.start();
>>> +
>>> +??????? for (int i = 0; i < 50000; i++) {
>>> +??????????? Calendar cal = new GregorianCalendar();
>>> +??????????? cal.clear();
>>> +??????????? cal.getTimeInMillis();
>>> +??????????? cal.set(2014, 2, 2);
>>> +??????????? cal.clear();
>>> +??????????? cal.getTimeInMillis();
>>> +??????????? cal.set(1970, 2, 2);
>>> +??????? }
>>> +
>>> +??? }
>>> +
>>> +??? public void run() {
>>> +??????? while (true) {
>>> +??????????? cal.setTimeZone(TimeZone.getDefault());
>>> +??????????? cal.clear();
>>> +??????????? cal.set(2008, 9, 9);
>>> +??????????? Calendar calInst = java.util.Calendar.getInstance();
>>> +??????????? calInst.setTimeInMillis(cal.getTimeInMillis());
>>> +
>>> +??????????? if (calInst.get(java.util.Calendar.HOUR_OF_DAY) != 
>>> cal.get(java.util.Calendar.HOUR_OF_DAY) ||
>>> +??????????????? calInst.get(java.util.Calendar.MINUTE) != 
>>> cal.get(java.util.Calendar.MINUTE) ||
>>> +??????????????? calInst.get(java.util.Calendar.SECOND) != 
>>> cal.get(java.util.Calendar.SECOND) ||
>>> +??????????????? calInst.get(java.util.Calendar.MILLISECOND) != 
>>> cal.get(java.util.Calendar.MILLISECOND)) {
>>> +??????????????????? throw new RuntimeException("Test failed");
>>> +??????????? }
>>> +??????? }
>>> +??? }
>>> +}
>>>
>>>
>>> On 10/11/17 9:29 PM, Se?n Coffey wrote:
>>>> I think the OpenJDK mailing lists accept attachments if in patch 
>>>> format. If it's a simple short patch, it's acceptable to paste it 
>>>> into email body.
>>>>
>>>> Easiest solution is to use webrev[1]. If you can't upload this to 
>>>> cr.openjdk.java.net - then one of your colleagues may be able to help.
>>>>
>>>> [1] http://openjdk.java.net/guide/webrevHelp.html
>>>>
>>>> Regards,
>>>> Sean.
>>>>
>>>> On 10/11/17 12:18, Venkateswara R Chintala wrote:
>>>>> Looks like the patch attached earlier is not visible. As this is 
>>>>> my first contribution, please let me know how I can send the patch 
>>>>> for review.
>>>>>
>>>>>
>>>>> On 10/11/17 5:37 PM, Venkateswara R Chintala wrote:
>>>>>> Hi,
>>>>>>
>>>>>> In a multi-threaded environment, when java.util.SimpleTimeZone 
>>>>>> object is used to create a default timezone, there can be a race 
>>>>>> condition between the methods java.util.Timezone.getDefault() and 
>>>>>> java.util.Timezone.getDefaultRef() which can result in 
>>>>>> inconsistency of cache that is used to validate a particular 
>>>>>> time/date in DST.
>>>>>>
>>>>>> When a thread is cloning a default timezone object 
>>>>>> (SimpleTimeZone) and at the same time if a different thread 
>>>>>> modifies the time/year values, then the cache values (cacheYear, 
>>>>>> cacheStart, cacheEnd) can become inconsistent which leads to 
>>>>>> incorrect DST determination.
>>>>>>
>>>>>> We considered two approaches to fix the issue.
>>>>>>
>>>>>> 1)Synchronize access to cloning default timezone object when 
>>>>>> cache is being modified.
>>>>>>
>>>>>> 2)Invalidate the cache while returning the clone.
>>>>>>
>>>>>> We preferred the second option as synchronization is more expensive.
>>>>>>
>>>>>> We have attached the patch and jtreg testcase. Please review.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>


From peter.levart at gmail.com  Sat Nov 11 20:49:10 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 11 Nov 2017 21:49:10 +0100
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <8894f619-3510-acfa-3987-f013ca3638f3@gmail.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>
 <84ca56e0-67c8-3fbb-d558-4ebe797d513c@oracle.com>
 <8894f619-3510-acfa-3987-f013ca3638f3@gmail.com>
Message-ID: <b68da9c6-1ad4-6926-7c27-21680e3b73b0@gmail.com>

Hi David, Venkat,

On 11/11/17 21:15, Peter Levart wrote:
> For example, take the following method:
>
> String defaultTZID() {
> ??? return TimeZone.getDefault().getID();
> }
>
> When JIT compiles it and inlines invocations to other methods within 
> it, it can prove that cloned TimeZone instance never escapes the call 
> to defaultTZID() and can therefore skip allocating the instance on heap.
>
> But this is fragile. If code in invoked methods changes, they may not 
> get inlined or EA may not be able to prove that the cloned instance 
> can't escape and allocation may be introduced. ZoneId.systemDefault() 
> is a hot method and it would be nice if we manage to keep it 
> allocation free.

Well, I tried the following variant of SimpleTimeZone.clone() patch:

 ??? public Object clone()
 ??? {
 ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
 ??????? // like tz.invalidateCache() but without holding a lock on clone
 ??????? tz.cacheYear = tz.startYear - 1;
 ??????? tz.cacheStart = tz.cacheEnd = 0;
 ??????? return tz;
 ??? }


...and the JMH benchmark with gc profiling shows that 
ZoneId.systemDefault() still manages to get JIT-compiled without 
introducing allocation.

Even the following (original Venkat's) patch:

 ??? public Object clone()
 ??? {
 ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
 ??????? tz.invalidateCache();
 ??????? return tz;
 ??? }

...does the same and the locking in invalidateCache() is elided too. 
Allocation and lock-elision go hand-in-hand. When object doesn't escape, 
allocation on heap may be eliminated and locks on that instance elided.

So this is better than synchronizing on the original instance during 
.clone() execution as it has potential to avoid locking overhead.

So Venkat, go ahead. My fear was unjustified.

Regards, Peter


From matcdac at gmail.com  Sun Nov 12 16:26:34 2017
From: matcdac at gmail.com (Prakhar Makhija)
Date: Sun, 12 Nov 2017 21:56:34 +0530
Subject: Require some insight regarding Objects & Json
Message-ID: <CAPu805rCRqOmeGGD8_6-Gy_LEhHHXU2b1VpJLxx1YccMpMBTNA@mail.gmail.com>

Hi,


*Scenario*

Having 1.5 million json files of same structure (same keys).
Each file is of around 64 KB, which makes a total of 1 GB.

Created a class MyDummyJsonClass, having the attribute names same as the
keys in those json files.

Reading the json files, loading them into MyDummyJsonClass, using
ObjectMapper.


*Doubt 1*

Will the objects occupy the same amount of space in Java's Memory, as they
were occupying earlier as flat files?


*Doubt 2*

Does Java convert Objects to Enumerations at Runtime?

What I mean to ask is, does it enumerate the attribute names while creating
objects, in order to save the memory?

Because the Class is just a blueprint, and we create objects out of it over
and over again.


*Example*


class MyDummyJsonClass {

private Object meaningfulNameOfAttributeOne;
private String meaningfulNameOfAttributeTwo;
private Integer meaningfulNameOfAttributeThree;
private Float meaningfulNameOfAttributeFour;
private Double meaningfulNameOfAttributeFive;
private Long meaningfulNameOfAttributeSix;
private Byte meaningfulNameOfAttributeSeven;
private Boolean meaningfulNameOfAttributeEight;
private Character meaningfulNameOfAttributeNine;
private Short meaningfulNameOfAttributeTen;

// Contructors

// Getters & Setters

}


Here the field meaningfulNameOfAttributeOne is of 28 characters, and Java
uses Unicode, so internally just this attribute name will it be occupying
56 bytes of memory in every Object we create?

Or is meaningfulNameOfAttributeOne mapped to enum value 1, and will occupy
maybe just 1 byte, depending upon the number of fields?

If less than or equal to 256 fields in the class, allocate 1 byte enum,
else 2 bytes enum.

And some kind of Interceptor decides, to give it logical attribute name
mapping?

From ecki at zusammenkunft.net  Sun Nov 12 21:17:42 2017
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sun, 12 Nov 2017 22:17:42 +0100
Subject: Require some insight regarding Objects & Json
In-Reply-To: <CAPu805rCRqOmeGGD8_6-Gy_LEhHHXU2b1VpJLxx1YccMpMBTNA@mail.gmail.com>
References: <CAPu805rCRqOmeGGD8_6-Gy_LEhHHXU2b1VpJLxx1YccMpMBTNA@mail.gmail.com>
Message-ID: <5a08ba76.c1241c0a.d4b39.0114@mx.google.com>

Hello,

the Java Objects will occupy more (especially If the Parser does not provide a way to merge same-string-content objects.

It depends on the Parser what is converted (but I am not Aware of any which Support Enumerations out of the box, especially since JSON-P JSR is limited to generic (DOM-like) objects)

I also think the list here is a bit offtopic for such a question, what JSON-Parser do you plan to use?

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Prakhar Makhija
Gesendet: Sonntag, 12. November 2017 18:57
An: core-libs-dev at openjdk.java.net; core-libs-dev-request at openjdk.java.net
Betreff: Require some insight regarding Objects & Json

Hi,


*Scenario*

Having 1.5 million json files of same structure (same keys).
Each file is of around 64 KB, which makes a total of 1 GB.

Created a class MyDummyJsonClass, having the attribute names same as the
keys in those json files.

Reading the json files, loading them into MyDummyJsonClass, using
ObjectMapper.


*Doubt 1*

Will the objects occupy the same amount of space in Java's Memory, as they
were occupying earlier as flat files?


*Doubt 2*

Does Java convert Objects to Enumerations at Runtime?

What I mean to ask is, does it enumerate the attribute names while creating
objects, in order to save the memory?

Because the Class is just a blueprint, and we create objects out of it over
and over again.


*Example*


class MyDummyJsonClass {

private Object meaningfulNameOfAttributeOne;
private String meaningfulNameOfAttributeTwo;
private Integer meaningfulNameOfAttributeThree;
private Float meaningfulNameOfAttributeFour;
private Double meaningfulNameOfAttributeFive;
private Long meaningfulNameOfAttributeSix;
private Byte meaningfulNameOfAttributeSeven;
private Boolean meaningfulNameOfAttributeEight;
private Character meaningfulNameOfAttributeNine;
private Short meaningfulNameOfAttributeTen;

// Contructors

// Getters & Setters

}


Here the field meaningfulNameOfAttributeOne is of 28 characters, and Java
uses Unicode, so internally just this attribute name will it be occupying
56 bytes of memory in every Object we create?

Or is meaningfulNameOfAttributeOne mapped to enum value 1, and will occupy
maybe just 1 byte, depending upon the number of fields?

If less than or equal to 256 fields in the class, allocate 1 byte enum,
else 2 bytes enum.

And some kind of Interceptor decides, to give it logical attribute name
mapping?


From matcdac at gmail.com  Mon Nov 13 05:49:50 2017
From: matcdac at gmail.com (Prakhar Makhija)
Date: Mon, 13 Nov 2017 11:19:50 +0530
Subject: Require some insight regarding Objects & Json
In-Reply-To: <CAPu805rCRqOmeGGD8_6-Gy_LEhHHXU2b1VpJLxx1YccMpMBTNA@mail.gmail.com>
References: <CAPu805rCRqOmeGGD8_6-Gy_LEhHHXU2b1VpJLxx1YccMpMBTNA@mail.gmail.com>
Message-ID: <CAPu805ruO0VrJ3nnoLNY1yh2vt--nDsLoAVvALAbvfG+-95RWg@mail.gmail.com>

Corrections :


*Scenario*

Have 1.5 billion json files, Each file is of around 655 bytes, which makes
a total of around 937.5 MB.


*Example*

Or is meaningfulNameOfAttributeOne internally mapped to enum value 0, and
will occupy maybe just 1 byte, depending upon the number of fields?


On Sun, Nov 12, 2017 at 9:56 PM, Prakhar Makhija <matcdac at gmail.com> wrote:

> Hi,
>
>
> *Scenario*
>
> Having 1.5 million json files of same structure (same keys).
> Each file is of around 64 KB, which makes a total of 1 GB.
>
> Created a class MyDummyJsonClass, having the attribute names same as the
> keys in those json files.
>
> Reading the json files, loading them into MyDummyJsonClass, using
> ObjectMapper.
>
>
> *Doubt 1*
>
> Will the objects occupy the same amount of space in Java's Memory, as they
> were occupying earlier as flat files?
>
>
> *Doubt 2*
>
> Does Java convert Objects to Enumerations at Runtime?
>
> What I mean to ask is, does it enumerate the attribute names while
> creating objects, in order to save the memory?
>
> Because the Class is just a blueprint, and we create objects out of it
> over and over again.
>
>
> *Example*
>
>
> class MyDummyJsonClass {
>
> private Object meaningfulNameOfAttributeOne;
> private String meaningfulNameOfAttributeTwo;
> private Integer meaningfulNameOfAttributeThree;
> private Float meaningfulNameOfAttributeFour;
> private Double meaningfulNameOfAttributeFive;
> private Long meaningfulNameOfAttributeSix;
> private Byte meaningfulNameOfAttributeSeven;
> private Boolean meaningfulNameOfAttributeEight;
> private Character meaningfulNameOfAttributeNine;
> private Short meaningfulNameOfAttributeTen;
>
> // Contructors
>
> // Getters & Setters
>
> }
>
>
> Here the field meaningfulNameOfAttributeOne is of 28 characters, and Java
> uses Unicode, so internally just this attribute name will it be occupying
> 56 bytes of memory in every Object we create?
>
> Or is meaningfulNameOfAttributeOne mapped to enum value 1, and will
> occupy maybe just 1 byte, depending upon the number of fields?
>
> If less than or equal to 256 fields in the class, allocate 1 byte enum,
> else 2 bytes enum.
>
> And some kind of Interceptor decides, to give it logical attribute name
> mapping?
>
>

From venkatec at linux.vnet.ibm.com  Mon Nov 13 10:28:20 2017
From: venkatec at linux.vnet.ibm.com (Venkateswara R Chintala)
Date: Mon, 13 Nov 2017 15:58:20 +0530
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <b68da9c6-1ad4-6926-7c27-21680e3b73b0@gmail.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>
 <84ca56e0-67c8-3fbb-d558-4ebe797d513c@oracle.com>
 <8894f619-3510-acfa-3987-f013ca3638f3@gmail.com>
 <b68da9c6-1ad4-6926-7c27-21680e3b73b0@gmail.com>
Message-ID: <d74ffdce-793a-bfe9-7e5f-4964897c3553@linux.vnet.ibm.com>

Thanks David, Peter for your review and comments. As I am new to the 
community, can you please help me to open a bug and integrate the 
changes into code base?

-Venkat

On 12/11/17 2:19 AM, Peter Levart wrote:
> Hi David, Venkat,
>
> On 11/11/17 21:15, Peter Levart wrote:
>> For example, take the following method:
>>
>> String defaultTZID() {
>> ??? return TimeZone.getDefault().getID();
>> }
>>
>> When JIT compiles it and inlines invocations to other methods within 
>> it, it can prove that cloned TimeZone instance never escapes the call 
>> to defaultTZID() and can therefore skip allocating the instance on heap.
>>
>> But this is fragile. If code in invoked methods changes, they may not 
>> get inlined or EA may not be able to prove that the cloned instance 
>> can't escape and allocation may be introduced. ZoneId.systemDefault() 
>> is a hot method and it would be nice if we manage to keep it 
>> allocation free.
>
> Well, I tried the following variant of SimpleTimeZone.clone() patch:
>
> ??? public Object clone()
> ??? {
> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
> ??????? // like tz.invalidateCache() but without holding a lock on clone
> ??????? tz.cacheYear = tz.startYear - 1;
> ??????? tz.cacheStart = tz.cacheEnd = 0;
> ??????? return tz;
> ??? }
>
>
> ...and the JMH benchmark with gc profiling shows that 
> ZoneId.systemDefault() still manages to get JIT-compiled without 
> introducing allocation.
>
> Even the following (original Venkat's) patch:
>
> ??? public Object clone()
> ??? {
> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
> ??????? tz.invalidateCache();
> ??????? return tz;
> ??? }
>
> ...does the same and the locking in invalidateCache() is elided too. 
> Allocation and lock-elision go hand-in-hand. When object doesn't 
> escape, allocation on heap may be eliminated and locks on that 
> instance elided.
>
> So this is better than synchronizing on the original instance during 
> .clone() execution as it has potential to avoid locking overhead.
>
> So Venkat, go ahead. My fear was unjustified.
>
> Regards, Peter
>


From Roger.Riggs at Oracle.com  Mon Nov 13 14:35:52 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 13 Nov 2017 09:35:52 -0500
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <2D157CBB-65F0-41B1-8DB5-99F45BB8A412@reini.net>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
 <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
 <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>
 <8167AB26-7918-4920-A889-4FB2F2254BE5@reini.net>
 <3755dc7c-84b2-61a8-06a2-e45f5007f8b7@Oracle.com>
 <2D157CBB-65F0-41B1-8DB5-99F45BB8A412@reini.net>
Message-ID: <52b9afdc-4103-3bf8-c111-9b0310e1f913@Oracle.com>

Hi Patrick,

Comments on http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.02:

Readable.java:
74: "to an error" is a bit overloaded, perhaps "to an exception"

X-Buffer.java.template:

1567: "this buffer":? do you mean the "out buffer"

1578:? "The out buffer is this buffer": will read poorly out of context, 
perhaps:? "Illegal transfer of a buffer to itself"

1580: Perhaps confine "start" to the else case.

For the tests, an example of using RandomFactory is in 
test/jdk/java/io/InputStream/ReadNBytes.java.

Thanks, Roger



On 11/10/2017 4:42 AM, Patrick Reinhart wrote:
> An updated webrev:
>
> http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.01
>
>
>> A few comments:
>>
>> Readable.java:
>>   67: + it may be worth mentioning that the input might not fit in output (as seen in the CharBuffer case)
>> Though I see we didn?t call that out in the other transferTo description but here it is more likely that the output is bounded.
> I tried to mention that now.
>
>> 77: "The total amount will be added up by after the write method has been completed." should not be part
>> of the @implSpec.  It is untestable and unnecessary. If an exception occurs the value is lost.
> I see that point - removed
>
>> 96: ?in order not having the extra overhead creating" -> "to avoid the extra overhead of"
> done
>
>> X-Buffer.java.template:
>>
>> 1555: ?form" -> "from"
> done
>
>> 1554: I would avoid most of the details in the @implSpec since it is requiring a specific use of CharBuffer methods.
>> That's fine as an @ImplNote but restricts the implementation too much as spec.
>> (others will disagree)
>>
>> 1565:  in the code, perhaps it should use an explicit RequireNonNull(out, ?out") otherwise the NPE will be on put()/append().
> done
>
>> 1566: "insufficient space in this" refers to the source, not dest and it should only apply if out is a CharBuffer.
>>    Omit it or leave it more general;  that behavior is covered by the spec of the out Appendable.
>>
>> 1568: I don?t see code to enforce:  "if out is this buffer"
> done
>
>>
>> On the tests; had you considered using TestNG;
>> it provides some good structure and is preferred (AFAIK) for new tests.
> To be honest, no. The test for the Readable I basically copied from the InputStream and the one for CharBuffer I just did
> not think about? I will certainly consider that for the future :-)
>
>> As for Randomness, it is useful to be explicit about the seed used in the particular run so it can be
>> replayed if necessary.  There is a testlibrary function to do that if you don't want to code-your-own.
>> (test/jdk/test/lib/RandomFactory::getRandom())
> I will need some digging how to have the RandomFactory be added to the test class path?
>
>> Thanks, Roger
>>


From jason_mehrens at hotmail.com  Mon Nov 13 15:14:12 2017
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Mon, 13 Nov 2017 15:14:12 +0000
Subject: Change in properties for logging: deliberate?
In-Reply-To: <9d326eca-e94f-cfb2-6daf-e9db456050ff@oracle.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
 <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
 <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>
 <CAPYFHW0zNys6RwDLrCdw31oWbL7dZiHou7cMqXQSF5E5xk6Oug@mail.gmail.com>
 <59156c8a-8622-99b9-7a2f-b0c161868b4f@oracle.com>
 <5d3ffed1-6c0d-d2f2-a541-a82d5ed8ebd5@oracle.com>
 <f1d8e738-0516-cdda-da19-989ae479911e@oracle.com>
 <DM5PR1801MB19458C8FEEEEABA67E21DBDE83570@DM5PR1801MB1945.namprd18.prod.outlook.com>,
 <9d326eca-e94f-cfb2-6daf-e9db456050ff@oracle.com>
Message-ID: <DM5PR1801MB1945BC7174E6A67CC263F5C0832B0@DM5PR1801MB1945.namprd18.prod.outlook.com>

Hi Daniel,

Sorry for the late reply I was offline for the long weekend.

Hot reloads of the LogManager have always been a problem.  I think you are running into https://bugs.openjdk.java.net/browse/JDK-8033661 in your testing and that is going to give you troubling results on what is recreated after the call.  Make sure you test updateConfiguration which is the replacement everyone is to use going forward.

I think you'll want to make it so that "handlers" is just an alias name ".handlers".  That way empty string is just name of the root logger which enables consistent use of other properties like ".level" and ".filter".
If both are defined in the logging.properties, then install the union of the two lines.

Jason

________________________________________
From: Daniel Fuchs <daniel.fuchs at oracle.com>
Sent: Friday, November 10, 2017 10:04 AM
To: Jason Mehrens; mandy chung
Cc: core-libs-dev at openjdk.java.net
Subject: Re: Change in properties for logging: deliberate?

Hi Jason,

I have done a few tests with JDK 8 & 7.

I have created custom handlers and added some
debug traces in their constructors and debug methods.

Then I have added these two lines to my logging.properties:

handlers = custom.Handler
.handlers = custom.DotHandler

What I see is this:

- the first time the configuration is read, two handlers
   are added to the root logger:
   - an instance of DotHandler (first), then an instance
     of Handler (second).

Then if you call LogManager.readConfiguration() again,
both handlers are closed, and this time only one
instance of Handler is added to the root logger.
No instance of DotHandler is added.
 From now on the property is ignored.

This is because the root logger is a special beast:
it will not be removed (like all other loggers) when
LogManager.readConfiguration() is called.

And as it happens, handlers are added to loggers
when the loggers are added to the LogManager.
As it happens, the ".handlers" property is only parsed
and read when the root logger is added to the LogManager,
and thus only once.

The "handlers" property on the other hand is parsed
every time LogManager.readConfiguration() is called.

Given that, I suspect we should deprecate the use of
".handlers" for the root logger, as it appears that
it has never worked properly. I could work on a patch
for 10 (possibly backport it to 9 update) to preserve
the strange behavior of 7 & 8, but is it worth it?

What are your thoughts?

best regards,

-- daniel




On 09/11/2017 19:50, Jason Mehrens wrote:
> Daniel,
>
> I would assume you would fix since it is advertised as a feature over here: https://docs.oracle.com/javase/1.5.0/docs/guide/logging/changes.html
>
> If it helps, I've dug up a lot of the history on this over here a while back:
> https://stackoverflow.com/questions/36726431/in-a-java-util-logging-logging-properties-file-whats-the-difference-between-h
>
> I've updated that to include the links to this new issue.  Now that I've linked this message thread to that message thread that should crash the internet. :)
>
> Jason
>
> ________________________________________
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Daniel Fuchs <daniel.fuchs at oracle.com>
> Sent: Thursday, November 9, 2017 1:29 PM
> To: mandy chung
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: Change in properties for logging: deliberate?
>
> On 09/11/2017 19:16, mandy chung wrote:
>> Daniel - we should add this known issue in the release note and document
>> the workaround.
>
> Hi Mandy,
>
> Right, it either need to be fixed, or documented in the release
> notes. Let me first have a look at the issue though.
>
> best regards,
>
> -- daniel
>


From daniel.fuchs at oracle.com  Mon Nov 13 15:30:01 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 13 Nov 2017 15:30:01 +0000
Subject: Change in properties for logging: deliberate?
In-Reply-To: <DM5PR1801MB1945BC7174E6A67CC263F5C0832B0@DM5PR1801MB1945.namprd18.prod.outlook.com>
References: <CAPYFHW3w49MOg4UX8D=VS4qFtWGyG-5Sh0-s3Nwntrsb=-eFyQ@mail.gmail.com>
 <71981898-fa64-e69c-5e56-246eaed548f7@oracle.com>
 <9adc01cf-fe46-f1be-6d92-182cc9ddd3ef@oracle.com>
 <CAPYFHW0zNys6RwDLrCdw31oWbL7dZiHou7cMqXQSF5E5xk6Oug@mail.gmail.com>
 <59156c8a-8622-99b9-7a2f-b0c161868b4f@oracle.com>
 <5d3ffed1-6c0d-d2f2-a541-a82d5ed8ebd5@oracle.com>
 <f1d8e738-0516-cdda-da19-989ae479911e@oracle.com>
 <DM5PR1801MB19458C8FEEEEABA67E21DBDE83570@DM5PR1801MB1945.namprd18.prod.outlook.com>
 <9d326eca-e94f-cfb2-6daf-e9db456050ff@oracle.com>
 <DM5PR1801MB1945BC7174E6A67CC263F5C0832B0@DM5PR1801MB1945.namprd18.prod.outlook.com>
Message-ID: <628fd19f-b93b-ca66-b3b3-d65817bc8171@oracle.com>

Hi Jason,

On 13/11/2017 15:14, Jason Mehrens wrote:
> Hi Daniel,
> 
> Sorry for the late reply I was offline for the long weekend.
> 
> Hot reloads of the LogManager have always been a problem.  I think you are running into https://bugs.openjdk.java.net/browse/JDK-8033661 in your testing and that is going to give you troubling results on what is recreated after the call.  Make sure you test updateConfiguration which is the replacement everyone is to use going forward.

Yes - I know - I fixed that one ;-)

> I think you'll want to make it so that "handlers" is just an alias name ".handlers".  That way empty string is just name of the root logger which enables consistent use of other properties like ".level" and ".filter".
> If both are defined in the logging.properties, then install the union of the two line.

That's precisely where I didn't want to go.

When I fixed JDK-8033661 I choose to use "handlers" for the root logger
instead of ".handlers" when implementing updateConfiguration() because
"handlers" is explicitly documented in LogManager API documentation
and conf/logging.properties.

So for the root logger the mapping function will only consider
"handlers" but not ".handlers". Trying to change that would
add too much complexity IMHO.

best regards,

-- daniel

> 
> Jason
> 
> ________________________________________
> From: Daniel Fuchs <daniel.fuchs at oracle.com>
> Sent: Friday, November 10, 2017 10:04 AM
> To: Jason Mehrens; mandy chung
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: Change in properties for logging: deliberate?
> 
> Hi Jason,
> 
> I have done a few tests with JDK 8 & 7.
> 
> I have created custom handlers and added some
> debug traces in their constructors and debug methods.
> 
> Then I have added these two lines to my logging.properties:
> 
> handlers = custom.Handler
> .handlers = custom.DotHandler
> 
> What I see is this:
> 
> - the first time the configuration is read, two handlers
>     are added to the root logger:
>     - an instance of DotHandler (first), then an instance
>       of Handler (second).
> 
> Then if you call LogManager.readConfiguration() again,
> both handlers are closed, and this time only one
> instance of Handler is added to the root logger.
> No instance of DotHandler is added.
>   From now on the property is ignored.
> 
> This is because the root logger is a special beast:
> it will not be removed (like all other loggers) when
> LogManager.readConfiguration() is called.
> 
> And as it happens, handlers are added to loggers
> when the loggers are added to the LogManager.
> As it happens, the ".handlers" property is only parsed
> and read when the root logger is added to the LogManager,
> and thus only once.
> 
> The "handlers" property on the other hand is parsed
> every time LogManager.readConfiguration() is called.
> 
> Given that, I suspect we should deprecate the use of
> ".handlers" for the root logger, as it appears that
> it has never worked properly. I could work on a patch
> for 10 (possibly backport it to 9 update) to preserve
> the strange behavior of 7 & 8, but is it worth it?
> 
> What are your thoughts?
> 
> best regards,
> 
> -- daniel
> 
> 
> 
> 
> On 09/11/2017 19:50, Jason Mehrens wrote:
>> Daniel,
>>
>> I would assume you would fix since it is advertised as a feature over here: https://docs.oracle.com/javase/1.5.0/docs/guide/logging/changes.html
>>
>> If it helps, I've dug up a lot of the history on this over here a while back:
>> https://stackoverflow.com/questions/36726431/in-a-java-util-logging-logging-properties-file-whats-the-difference-between-h
>>
>> I've updated that to include the links to this new issue.  Now that I've linked this message thread to that message thread that should crash the internet. :)
>>
>> Jason
>>
>> ________________________________________
>> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Daniel Fuchs <daniel.fuchs at oracle.com>
>> Sent: Thursday, November 9, 2017 1:29 PM
>> To: mandy chung
>> Cc: core-libs-dev at openjdk.java.net
>> Subject: Re: Change in properties for logging: deliberate?
>>
>> On 09/11/2017 19:16, mandy chung wrote:
>>> Daniel - we should add this known issue in the release note and document
>>> the workaround.
>>
>> Hi Mandy,
>>
>> Right, it either need to be fixed, or documented in the release
>> notes. Let me first have a look at the issue though.
>>
>> best regards,
>>
>> -- daniel
>>
> 


From claes.redestad at oracle.com  Mon Nov 13 16:34:53 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 13 Nov 2017 17:34:53 +0100
Subject: RFR: 8184777: Factor out species generation logic from
 BoundMethodHandle
Message-ID: <16275878-b9a7-7b79-dc76-99d5d2f4ee41@oracle.com>

Hi,

 ?this patch factors out the BoundMethodHandle species data class
generation to a new ClassSpecializer facility.

 ?While currently semantically neutral, this will make it possible
to reuse the facility in other places.

 ?Webrev: http://cr.openjdk.java.net/~redestad/8184777/open.00/
 ?Bug: https://bugs.openjdk.java.net/browse/JDK-8184777

 ?Performance wise this adds a very small (~20k bytecode) amount
of work to the initialization costs of BMHs, which we expect will
be more than repaid as we apply the ClassSpecializer elsewhere.

 ?Thanks!

/Claes

From vladimir.x.ivanov at oracle.com  Mon Nov 13 16:38:44 2017
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 13 Nov 2017 19:38:44 +0300
Subject: RFR: 8184777: Factor out species generation logic from
 BoundMethodHandle
In-Reply-To: <16275878-b9a7-7b79-dc76-99d5d2f4ee41@oracle.com>
References: <16275878-b9a7-7b79-dc76-99d5d2f4ee41@oracle.com>
Message-ID: <2751f32f-4829-135e-0521-7f00bc016055@oracle.com>

Looks good!

Best regards,
Vladimir Ivanov

On 11/13/17 7:34 PM, Claes Redestad wrote:
> Hi,
> 
>  ?this patch factors out the BoundMethodHandle species data class
> generation to a new ClassSpecializer facility.
> 
>  ?While currently semantically neutral, this will make it possible
> to reuse the facility in other places.
> 
>  ?Webrev: http://cr.openjdk.java.net/~redestad/8184777/open.00/
>  ?Bug: https://bugs.openjdk.java.net/browse/JDK-8184777
> 
>  ?Performance wise this adds a very small (~20k bytecode) amount
> of work to the initialization costs of BMHs, which we expect will
> be more than repaid as we apply the ClassSpecializer elsewhere.
> 
>  ?Thanks!
> 
> /Claes

From claes.redestad at oracle.com  Mon Nov 13 16:41:14 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 13 Nov 2017 17:41:14 +0100
Subject: RFR: 8184777: Factor out species generation logic from
 BoundMethodHandle
In-Reply-To: <2751f32f-4829-135e-0521-7f00bc016055@oracle.com>
References: <16275878-b9a7-7b79-dc76-99d5d2f4ee41@oracle.com>
 <2751f32f-4829-135e-0521-7f00bc016055@oracle.com>
Message-ID: <1a8a0d8e-735e-9b28-24c2-efdad8e20060@oracle.com>

Thanks Vladimir!

/Claes

On 2017-11-13 17:38, Vladimir Ivanov wrote:
> Looks good!
>
> Best regards,
> Vladimir Ivanov
>
> On 11/13/17 7:34 PM, Claes Redestad wrote:
>> Hi,
>>
>> ??this patch factors out the BoundMethodHandle species data class
>> generation to a new ClassSpecializer facility.
>>
>> ??While currently semantically neutral, this will make it possible
>> to reuse the facility in other places.
>>
>> ??Webrev: http://cr.openjdk.java.net/~redestad/8184777/open.00/
>> ??Bug: https://bugs.openjdk.java.net/browse/JDK-8184777
>>
>> ??Performance wise this adds a very small (~20k bytecode) amount
>> of work to the initialization costs of BMHs, which we expect will
>> be more than repaid as we apply the ClassSpecializer elsewhere.
>>
>> ??Thanks!
>>
>> /Claes


From christoph.dreis at freenet.de  Mon Nov 13 17:56:06 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Mon, 13 Nov 2017 18:56:06 +0100
Subject: 8184777: Factor out species generation logic from
 BoundMethodHandle
In-Reply-To: <16275878-b9a7-7b79-dc76-99d5d2f4ee41@oracle.com>
References: <16275878-b9a7-7b79-dc76-99d5d2f4ee41@oracle.com>
Message-ID: <005501d35ca8$aed6cc10$0c846430$@freenet.de>

Hey Claes,

though far away from being an expert on the subject matter, I have some very minor comments if you don't mind.

ClassSpecializer.java
L510: * For example, a concrete species for two reference and one integral bound values have a shape like the following:
Should be imho:
L510: * For example, a concrete species for two references and one integral bound value has a shape like the following:

LambdaFormBuffer.java:
L333: if (oldFns.size() == 0)  return this;
Could be:
L333: if (oldFns.isEmpty())  return this;

Cheers,
Christoph

> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
> Behalf Of Claes Redestad
> Sent: Monday, November 13, 2017 5:35 PM
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Cc: mlvm-dev at openjdk.java.net
> Subject: RFR: 8184777: Factor out species generation logic from
> BoundMethodHandle
> 
> Hi,
> 
>   this patch factors out the BoundMethodHandle species data class
> generation to a new ClassSpecializer facility.
> 
>   While currently semantically neutral, this will make it possible to reuse the
> facility in other places.
> 
>   Webrev: http://cr.openjdk.java.net/~redestad/8184777/open.00/
>   Bug: https://bugs.openjdk.java.net/browse/JDK-8184777
> 
>   Performance wise this adds a very small (~20k bytecode) amount of work to
> the initialization costs of BMHs, which we expect will be more than repaid as
> we apply the ClassSpecializer elsewhere.
> 
>   Thanks!
> 
> /Claes


From joe.darcy at oracle.com  Mon Nov 13 18:25:09 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 13 Nov 2017 10:25:09 -0800
Subject: Faster Math ?
In-Reply-To: <06AB6270-7489-41CE-B82F-668C582C9D41@oracle.com>
References: <CAKjRUT7V1swPZJkEJKOtde-vZQgvAOg=_=uA-e9t+Z+QySMoVQ@mail.gmail.com>
 <CAKjRUT4j-R60NpCmEcs+x5-whmobyvBcAHSqecaH6PFG_NzaZA@mail.gmail.com>
 <CAKjRUT46GRnUqNgD-s81z_qYd0-_Rj-VQUgtVsMSUMKfHqJOxw@mail.gmail.com>
 <CAKjRUT5Ltn=4URTR2NXDgFis=b9s6e2TJS-FCK5qqqeyAXswuA@mail.gmail.com>
 <CAKjRUT7XkZevTau--k8avcUX6KE_bZmgRwJaGSx-2rt=Nz-4=Q@mail.gmail.com>
 <CAKjRUT668ng+Xh08a4VzJt4vPceuQp4VyOuRF2X=nZK+R4RHzw@mail.gmail.com>
 <CAKjRUT7K0evbnjY0ixzhMB54MEXiJxCkW4es_C1vLJ-hWywCaA@mail.gmail.com>
 <CAKjRUT6sbq8GoPLfZUtirvSX7okWSW+xOQ5B=rggOkYJ889PYQ@mail.gmail.com>
 <CAKjRUT48TpyU8XgHNewSu7Vt_GKMOS3-D7sKa6VuGTiNPERaSA@mail.gmail.com>
 <CAKjRUT6i8iSF07USPhY=jTPU5dc4g7rNn9WuA+DHRQioMS=1og@mail.gmail.com>
 <CAKjRUT4ezaSE5mPMNfXQaQfgu+3Y34+O1yBTvnbJ6Rmv+mkUyw@mail.gmail.com>
 <CAKjRUT4iFEZ1p-OLYAOiyKVmiTGLSPN0-HJVRwLGboxqgv4xkA@mail.gmail.com>
 <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>
 <06AB6270-7489-41CE-B82F-668C582C9D41@oracle.com>
Message-ID: <950a25aa-f9d8-6e7c-bce1-cd2a58bcf2c5@oracle.com>

Hello,

A few comments on this thread:

As Paul noted, a portion of fdlibm has been ported from C to Java. I do 
intend to finish the port at some point. The port gives an 
implementation speedup by avoiding Java -> C -> Java transition 
overheads. However, the same algorithms are being used of course.

The fdlibm code was first written several decades ago and there has been 
work in the interim on developing other algorithms for math libraries. 
One significant effort has focused on correctly rounded libraries, that 
is, libraries that have full floating-point accuracy. In particular 
Jean-Michel Muller and his students and collaborators have worked in 
this area and produce the crlibm package. If a specification for a 
StrictMath-style class were newly written today, I would recommend it be 
specified to be correctly rounded. Correct rounding is conceptually the 
"best" answer and it does not require the exact implementation 
algorithms to be specified to achieve reproducibility, unlike fdlibm.

However, the extra precise answer can come at the cost of extra time or 
space for the computation in some cases.

The notion of a "FastMath" library has been considered before (as well 
as the faster underlying numerics [1]). As also discussed earlier in the 
thread, specifying what degrees of inaccuracy is acceptable for what 
speed is non-obvious. (And offhand I don't know the error bounds of the 
other implementations being discussed.)

Working with Intel in OpenJDK, we are using optimized math library 
implementations for x64 for many interesting methods. For most math 
library methods, the trend has been to move to software-based 
implementations rather than having specialized hardware instructions. 
(Functionality like reciprocal square root is a counter-example, but we 
don't have that method in the Java math library.)

Note that since 1/3 is a repeating fraction in binary and decimal, 
pow(x, 1.0/3.0) is only approximately equivalent to cbrt(x).

Knowing which particular methods would be of interest for fast-but-loose 
math would be helpful. The sqrt method has long been intrinsified to the 
corresponding hardware instruction on many platforms so I don't think 
that would be a useful candidate in most circumstances.

In short, we might get a selection of looser but faster math methods at 
some point, but not immediately and not without more investigation.

Cheers,

-Joe

[1] Forward looking statements during "Forward to the Past: The Case for 
Uniformly Strict Floating Point Arithmetic on the JVM" 
https://youtu.be/qTKeU_3rhk4?t=2513


On 11/9/2017 9:19 AM, Paul Sandoz wrote:
> Hi Laurent,
>
> A Java method is a candidate for intrinsification if it is annotated with @HotSpotIntrinsicCandidate. When running Java code you can also use the HotSpot flags -XX:+PrintCompilarion -XX:+PrintInlining to show methods that are intrinsic (JIT watch, as mentioned, is also excellent in this regard).
>
> I recommend cloning OpenJDK and browsing the source.
>
> Some of the math functions are intrinsic in the interpreter and all the runtime compilers to ensure consistent results across interpretation and compilation.
>
> Work was done by Intel to improve many of the math functions. See:
>
>    Update for x86 sin and cos in the math lib
>    https://bugs.openjdk.java.net/browse/JDK-8143353
>
>    Update for x86 pow in the math lib
>    https://bugs.openjdk.java.net/browse/JDK-8145688
>    
>    (From these you can track related issues.)
>
> Other Math functions are not intrinsic like cbrt (non-native) and acos (native). There is ongoing work to turn native implementations into Java implementations (i don?t know if there would be any follow up on intrinsification).
>
>    https://bugs.openjdk.java.net/browse/JDK-8134780
>    https://bugs.openjdk.java.net/browse/JDK-8171407
>
> Joe knows more.
>
> ?
>
> As part of the Vector API effort we will likely need to investigate the support for less accurate but faster math functions. It?s too early to tell if something like a FastMath class will pop out of that, but FWIW i am sympathetic to that :-)
>
> I liked this tweet:
>
> https://twitter.com/FioraAeterna/status/926150700836405248
>
>    life as a gpu compiler dev is basically just fielding repeated complaints that
>    "fast math" isn't precise and "precise math" isn't fast
>
> as an indication of what we could be getting into :-)
>
> Paul.
>
>> On 9 Nov 2017, at 01:00, Laurent Bourg?s <bourges.laurent at gmail.com> wrote:
>>
>> Hi,
>>
>> The Marlin renderer (JEP265) uses few Math functions: sqrt, cbrt, acos...
>>
>> Could you check if the current JDK uses C2 intrinsics or libfdm (native /
>> JNI overhead?) and tell me if such functions are already highly optimized
>> in jdk9 or 10 ?
>>
>> Some people have implemented their own fast Math like Apache Commons Math
>> or JaFaMa libraries that are 10x faster for acos / cbrt.
>>
>> I wonder if I should implement my own cbrt function (cubics) in pure java
>> as I do not need the highest accuracy but SPEED.
>>
>> Would it sound possible to have a JDK FastMath public API (lots faster but
>> less accurate?)
>>
>> Do you know if recent CPU (intel?) have dedicated instructions for such
>> math operations ?
>> Why not use it instead?
>> Maybe that's part of the new Vectorization API (panama) ?
>>
>> Cheers,
>> Laurent Bourges


From jaroslav.tulach at oracle.com  Mon Nov 13 19:53:35 2017
From: jaroslav.tulach at oracle.com (Jaroslav Tulach)
Date: Mon, 13 Nov 2017 20:53:35 +0100
Subject: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only
 the permissions it really needs to expose the bean
In-Reply-To: <610c8d9d-9b01-d874-8794-1b99fc8a150e@oracle.com>
References: <2138013.zvGs44vPXg@pracovni>
 <610c8d9d-9b01-d874-8794-1b99fc8a150e@oracle.com>
Message-ID: <10208568.Zsd4Z32fDf@pracovni>

Hello Mandy,
this was a good test:

> > 
> > ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
> > +EnableJVMCI -XX:+UseJVMCICompiler -jar ...
> 
> You can also try running the above command with -Djava.security.manager
> as a sanity test (the application may need additional permissions) -
> just a sanity test. 

I've just tried:

$ ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
+EnableJVMCI -XX:+UseJVMCICompiler -Djava.security.manager -jar ~/
NetBeansProjects/sieve/java/algorithm/target/sieve-algorithm-1.0-SNAPSHOT.jar 

and it doesn't work. I am getting an error below, however the code is not 
running through my module at all. I don't understand the failure, I will have 
to investigate more.

-jt


Caused by: java.security.AccessControlException: access denied 
("java.lang.RuntimePermission" "accessClassInPackage.jdk.vm.ci.services")
        at java.base/
java.security.AccessControlContext.checkPermission(AccessControlContext.java:
472)
        at java.base/
java.security.AccessController.checkPermission(AccessController.java:895)
        at java.base/
java.lang.SecurityManager.checkPermission(SecurityManager.java:558)
        at java.base/
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1534)
        at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:680)
        at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:678)
        at java.base/java.security.AccessController.doPrivileged(Native 
Method)
        at java.base/
java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:678)
        at java.base/java.lang.ClassLoader.defineClass1(Native Method)
        at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1006)
        at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1085)
        at java.base/
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:206)
        at java.base/
jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:760)
        at java.base/jdk.internal.loader.BuiltinClassLoader.lambda
$findClassInModuleOrNull$2(BuiltinClassLoader.java:683)
        at java.base/java.security.AccessController.doPrivileged(Native 
Method)
        at java.base/
jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:
684)
        at java.base/
jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:562)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:607)
        at java.base/java.lang.Class.forName(Class.java:451)
        at java.base/java.util.ServiceLoader.lambda$loadProvider
$1(ServiceLoader.java:856)
        at java.base/java.security.AccessController.doPrivileged(Native 
Method)
        at java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:
858)


From patrick at reini.net  Mon Nov 13 22:23:40 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Mon, 13 Nov 2017 23:23:40 +0100
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <52b9afdc-4103-3bf8-c111-9b0310e1f913@Oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
 <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
 <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>
 <8167AB26-7918-4920-A889-4FB2F2254BE5@reini.net>
 <3755dc7c-84b2-61a8-06a2-e45f5007f8b7@Oracle.com>
 <2D157CBB-65F0-41B1-8DB5-99F45BB8A412@reini.net>
 <52b9afdc-4103-3bf8-c111-9b0310e1f913@Oracle.com>
Message-ID: <51486A9D-4982-47E3-9E64-4925E34BD488@reini.net>

Latest changes:

http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.03

-Patrick


> Am 13.11.2017 um 15:35 schrieb Roger Riggs <Roger.Riggs at Oracle.com>:
> 
> Hi Patrick,
> 
> Comments on http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.02:
> 
> Readable.java:
> 74: ?to an error" is a bit overloaded, perhaps "to an exception?
done

> 
> X-Buffer.java.template:
> 
> 1567: ?this buffer":  do you mean the "out buffer?
done

> 
> 1578:  "The out buffer is this buffer": will read poorly out of context, perhaps:  ?Illegal transfer of a buffer to itself?
done

> 
> 1580: Perhaps confine "start" to the else case.
> 
> For the tests, an example of using RandomFactory is in test/jdk/java/io/InputStream/ReadNBytes.java.
changed the test accordingly


> 
> Thanks, Roger
> 


From brian.burkhalter at oracle.com  Tue Nov 14 00:34:33 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 13 Nov 2017 16:34:33 -0800
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <51486A9D-4982-47E3-9E64-4925E34BD488@reini.net>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
 <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
 <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>
 <8167AB26-7918-4920-A889-4FB2F2254BE5@reini.net>
 <3755dc7c-84b2-61a8-06a2-e45f5007f8b7@Oracle.com>
 <2D157CBB-65F0-41B1-8DB5-99F45BB8A412@reini.net>
 <52b9afdc-4103-3bf8-c111-9b0310e1f913@Oracle.com>
 <51486A9D-4982-47E3-9E64-4925E34BD488@reini.net>
Message-ID: <AD985969-3146-4495-9328-4598C17653C0@oracle.com>

Hi Patrick,

More editorial comments ... ;-)

In Readable.java these lines

  73      * Depending on which class implements the appendable, there may be a limit
  74      * of data that can written to which in turn could lead to an exception.

are a bit unclear to me. Do you mean to say a limit on the amount of data, i.e., number of characters, which may be transferred? If so, then perhaps something like this?:

?Note that it is possible an implementing class may limit the number of characters which may be transferred and throw an exception if this limit is exceeded.?

In X-Buffer.java.template at lines 1556-1561 the following might be considered as an alternative wording:

?The implementation transfers data by one of two means. If the given {@link Appendable} is a {@link CharBuffer}, {@code put(CharBuffer)} is invoked on it with this buffer as parameter. Otherwise {@link Appendable#append(CharSequence, int, int)} is invoked on it with this buffer and its position and length as parameters.?

Thanks,

Brian

On Nov 13, 2017, at 2:23 PM, Patrick Reinhart <patrick at reini.net> wrote:

> Latest changes:
> 
> http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.03


From jaroslav.tulach at oracle.com  Tue Nov 14 06:22:05 2017
From: jaroslav.tulach at oracle.com (Jaroslav Tulach)
Date: Tue, 14 Nov 2017 07:22:05 +0100
Subject: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only
 the permissions it really needs to expose the bean
In-Reply-To: <10208568.Zsd4Z32fDf@pracovni>
References: <2138013.zvGs44vPXg@pracovni>
 <610c8d9d-9b01-d874-8794-1b99fc8a150e@oracle.com>
 <10208568.Zsd4Z32fDf@pracovni>
Message-ID: <2454131.31SKLb3dS1@pracovni>

I tried the same test with

changeset:   47679:d85284ccd1bd
user:        sspitsyn
date:        Fri Nov 03 17:09:25 2017 -0700
summary:     8189731: Disable CFLH when there are no transformers

and it also yields the exception. E.g. the problem is certainly not result of 
my changes. 

-jt

PS: I try full rebuild on d85284ccd1bd maybe it disappears...


On pond?l? 13. listopadu 2017 20:53:35 CET Jaroslav Tulach wrote:
> Hello Mandy,
> 
> this was a good test:
> > > ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
> > > +EnableJVMCI -XX:+UseJVMCICompiler -jar ...
> > 
> > You can also try running the above command with -Djava.security.manager
> > as a sanity test (the application may need additional permissions) -
> > just a sanity test.
> 
> I've just tried:
> 
> $ ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
> +EnableJVMCI -XX:+UseJVMCICompiler -Djava.security.manager -jar ~/
> NetBeansProjects/sieve/java/algorithm/target/sieve-algorithm-1.0-SNAPSHOT.ja
> r
> 
> and it doesn't work. I am getting an error below, however the code is not
> running through my module at all. I don't understand the failure, I will
> have to investigate more.
> 
> -jt
> 
> 
> Caused by: java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.vm.ci.services")
>         at java.base/
> java.security.AccessControlContext.checkPermission(AccessControlContext.java
> : 472)
>         at java.base/
> java.security.AccessController.checkPermission(AccessController.java:895)
>         at java.base/
> java.lang.SecurityManager.checkPermission(SecurityManager.java:558)
>         at java.base/
> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1534)
>         at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:680)
>         at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:678)
>         at java.base/java.security.AccessController.doPrivileged(Native
> Method)
>         at java.base/
> java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:678)
>         at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>         at
> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1006) at
> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1085) at
> java.base/
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:206)
>         at java.base/
> jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:7
> 60) at java.base/jdk.internal.loader.BuiltinClassLoader.lambda
> $findClassInModuleOrNull$2(BuiltinClassLoader.java:683)
>         at java.base/java.security.AccessController.doPrivileged(Native
> Method)
>         at java.base/
> jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassL
> oader.java: 684)
>         at java.base/
> jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:562
> ) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:607) at
> java.base/java.lang.Class.forName(Class.java:451)
>         at java.base/java.util.ServiceLoader.lambda$loadProvider
> $1(ServiceLoader.java:856)
>         at java.base/java.security.AccessController.doPrivileged(Native
> Method)
>         at
> java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java: 858)



From patrick at reini.net  Tue Nov 14 07:51:10 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 14 Nov 2017 08:51:10 +0100
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <AD985969-3146-4495-9328-4598C17653C0@oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
 <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
 <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>
 <8167AB26-7918-4920-A889-4FB2F2254BE5@reini.net>
 <3755dc7c-84b2-61a8-06a2-e45f5007f8b7@Oracle.com>
 <2D157CBB-65F0-41B1-8DB5-99F45BB8A412@reini.net>
 <52b9afdc-4103-3bf8-c111-9b0310e1f913@Oracle.com>
 <51486A9D-4982-47E3-9E64-4925E34BD488@reini.net>
 <AD985969-3146-4495-9328-4598C17653C0@oracle.com>
Message-ID: <8999FF83-ACA0-44B6-B60B-E6544F6D192E@reini.net>

Hi Brian

See latest changes here:

http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.03

-Patrick

> Am 14.11.2017 um 01:34 schrieb Brian Burkhalter <brian.burkhalter at oracle.com>:
> 
> Hi Patrick,
> 
> More editorial comments ... ;-)
> 

No problem :-)

> In Readable.java these lines
> 
>   73      * Depending on which class implements the appendable, there may be a limit
>   74      * of data that can written to which in turn could lead to an exception.
> 
> are a bit unclear to me. Do you mean to say a limit on the amount of data, i.e., number of characters, which may be transferred? If so, then perhaps something like this?:
> 
> ?Note that it is possible an implementing class may limit the number of characters which may be transferred and throw an exception if this limit is exceeded.?

That describes it better than the actual version and therefore changed

> 
> In X-Buffer.java.template at lines 1556-1561 the following might be considered as an alternative wording:
> 
> ?The implementation transfers data by one of two means. If the given {@link Appendable} is a {@link CharBuffer}, {@code put(CharBuffer)} is invoked on it with this buffer as parameter. Otherwise {@link Appendable#append(CharSequence, int, int)} is invoked on it with this buffer and its position and length as parameters.?
> 

Seems also improve the wording - changed

> Thanks,
> 
> Brian
> 
> On Nov 13, 2017, at 2:23 PM, Patrick Reinhart <patrick at reini.net> wrote:
> 
>> Latest changes:
>> 
>> http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.03
> 


From claes.redestad at oracle.com  Tue Nov 14 11:44:11 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 14 Nov 2017 12:44:11 +0100
Subject: 8184777: Factor out species generation logic from
 BoundMethodHandle
In-Reply-To: <005501d35ca8$aed6cc10$0c846430$@freenet.de>
References: <16275878-b9a7-7b79-dc76-99d5d2f4ee41@oracle.com>
 <005501d35ca8$aed6cc10$0c846430$@freenet.de>
Message-ID: <016627e6-da96-54f3-18a1-66ff79b8a132@oracle.com>

Hi Christoph,

On 2017-11-13 18:56, Christoph Dreis wrote:
> Hey Claes,
>
> though far away from being an expert on the subject matter, I have some very minor comments if you don't mind.
>
> ClassSpecializer.java
> L510: * For example, a concrete species for two reference and one integral bound values have a shape like the following:
> Should be imho:
> L510: * For example, a concrete species for two references and one integral bound value has a shape like the following:
>
> LambdaFormBuffer.java:
> L333: if (oldFns.size() == 0)  return this;
> Could be:
> L333: if (oldFns.isEmpty())  return this;

nice catches! Fixed and updated webrev in-place.

http://cr.openjdk.java.net/~redestad/8184777/open.00/

Thanks!

/Claes

From Alan.Bateman at oracle.com  Tue Nov 14 11:45:06 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Nov 2017 11:45:06 +0000
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <8999FF83-ACA0-44B6-B60B-E6544F6D192E@reini.net>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
 <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
 <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>
 <8167AB26-7918-4920-A889-4FB2F2254BE5@reini.net>
 <3755dc7c-84b2-61a8-06a2-e45f5007f8b7@Oracle.com>
 <2D157CBB-65F0-41B1-8DB5-99F45BB8A412@reini.net>
 <52b9afdc-4103-3bf8-c111-9b0310e1f913@Oracle.com>
 <51486A9D-4982-47E3-9E64-4925E34BD488@reini.net>
 <AD985969-3146-4495-9328-4598C17653C0@oracle.com>
 <8999FF83-ACA0-44B6-B60B-E6544F6D192E@reini.net>
Message-ID: <733069a3-33cb-3c68-0a51-6e33a7086f1b@oracle.com>

On 14/11/2017 07:51, Patrick Reinhart wrote:
> Hi Brian
>
> See latest changes here:
>
> http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.03
>
This version mostly looks quite good, a few comments:

- Readable "hence unspecified". In several other places, including 
InputStream.transferTo, we use "therefore unspecified" and it would be 
good to keep that consistent.

- Readable "Depending on which class implements the appendable ...". 
What would you think about replacing this sentence with: "If the 
destination is capacity bounded and has insufficient capacity to append 
all characters read from the source then an exception will be thrown 
after transferring zero or some bytes to the destination".

- CharBuffer. I don't think the first sentence in the @implSpec is 
needed, it's okay to start with "If the given Appendable ...". There's a 
typo in the second sentence "it's data if possible" -> "its data" (no 
"if possible" as it will use put unconditionally when the destination is 
a CharBuffer).

- CharBuffer. IOException is not possible when reading here, it's only 
writing.

- CharBuffer: NullPointerException is covered by the package 
description, the methods in this package do not specified NPE. It is not 
needed in the read method either.

- CharBuffer: The @param and @throws have a specific style in this 
package and probably best to keep that consistent if you can.

-Alan




From christoph.dreis at freenet.de  Tue Nov 14 14:29:27 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Tue, 14 Nov 2017 15:29:27 +0100
Subject: 8184777: Factor out species generation logic from
 BoundMethodHandle
In-Reply-To: <016627e6-da96-54f3-18a1-66ff79b8a132@oracle.com>
References: <16275878-b9a7-7b79-dc76-99d5d2f4ee41@oracle.com>
 <005501d35ca8$aed6cc10$0c846430$@freenet.de>
 <016627e6-da96-54f3-18a1-66ff79b8a132@oracle.com>
Message-ID: <000001d35d54$fa2d38a0$ee87a9e0$@freenet.de>

Hi Claes,

Thanks for incorporating this.

> > ClassSpecializer.java
> > L510: * For example, a concrete species for two reference and one integral
> bound values have a shape like the following:
> > Should be imho:
> > L510: * For example, a concrete species for two references and one
> integral bound value has a shape like the following:
> >
> > LambdaFormBuffer.java:
> > L333: if (oldFns.size() == 0)  return this; Could be:
> > L333: if (oldFns.isEmpty())  return this;
> 
> nice catches! Fixed and updated webrev in-place.
> 
> http://cr.openjdk.java.net/~redestad/8184777/open.00/

I still think it should be called "one integral bound value" instead of "values" and "has" instead of "have" (at least in case a singular species is meant).
You seem to have fixed the singular "reference" typo only in ClassSpecializer.java.

While looking at ClassSpecializer again, I found two additional editorial things I wanted to raise:

1.) 
364          * @return class name, which by default is {@code outer().topClass().getName() + "$Species_" + deriveTypeString(key)}
 365          */
 366         protected String deriveClassName() {
 367             return topClass.getName() + "$Species_" + deriveTypeString();
 368         }

The @return doesn't seem to match the implementation. This looks a bit weird at least.

2.)
328          * and produces a value of the required type.
Should be "produce a value" given that "supply" is used some lines above.

Again - I hope you don't mind these minor comments.

Cheers,
Christoph


From peter.levart at gmail.com  Tue Nov 14 15:02:59 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 14 Nov 2017 16:02:59 +0100
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <798167c6-c562-f247-b77b-b6da38bcce9e@oracle.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <798167c6-c562-f247-b77b-b6da38bcce9e@oracle.com>
Message-ID: <8d9b27b8-816c-3fbe-cff0-a17e5d0d7918@gmail.com>

Hi David,

On 11/11/2017 07:51 AM, David Holmes wrote:
> AFAICS SimpleTimeZone is simply not thread-safe. It has state that can 
> be modified concurrently without synchronization and with fields not 
> even declared volatile. Only the "cache" makes an attempt to use 
> synchronization. So clone() is never guaranteed to actually produce a 
> copy with valid/consistent field values.
>
> The suggested patch certainly improves the situation by at least 
> resetting the cache of the cloned instance before returning it.

The instance of SimpleTimeZone that is shared among threads (internally 
in JDK) is the defaultTimeZone instance (obtained through 
package-private TimeZone.getDefaultRef() method). I checked the usages 
and they seem to be "read-only" - not modifying the instance, just 
obtaining information from it. The cache OTOH, as you say, is synchronized.

TimeZone and subclasses seem to be designed to be modified by single 
thread only, but can be used from multiple threads to read the 
information from them, including lazily computed and cached information. 
Usage withing JDK seems to comply with that.

Venkat's patch therefore correctly fixes the remaining issue that is 
observed when the shared SimpleTimeZone instance is being cloned while 
also being accessed from multiple threads in read-only mode. 
Invalidating cache of the cloned instance just before returning it from 
clone() method means that instance obtained from TimeZone.getDefault() 
will never get cached state from original instance and will always have 
to re-compute it, but I think this is still better than synchronizing on 
the original instance which may never be optimized away (i.e. elided) by 
JIT.

Regards, Peter

>
> David
>
> On 11/11/2017 3:53 PM, Venkateswara R Chintala wrote:
>> Thanks Sean. I am pasting the patch here:
>>
>> --- old/src/java.base/share/classes/java/util/SimpleTimeZone.java 
>> 2017-11-11 11:17:38.643867420 +0530
>> +++ new/src/java.base/share/classes/java/util/SimpleTimeZone.java 
>> 2017-11-11 11:17:38.375870421 +0530
>> @@ -868,7 +868,11 @@
>> ?????? */
>> ????? public Object clone()
>> ????? {
>> -??????? return super.clone();
>> +??????? // Invalidate the time zone cache while cloning as it
>> +??????? // can be inconsistent due to race condition.
>> +??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>> +??????? tz.invalidateCache();
>> +??????? return tz;
>> ????? }
>>
>> ????? /**
>> --- /dev/null??? 2017-11-02 17:09:59.155627814 +0530
>> +++ new/test/java/util/TimeZone/SimpleTimeZoneTest.java 2017-11-11 
>> 11:17:38.867864912 +0530
>> @@ -0,0 +1,55 @@
>> +/*
>> + * @test
>> + * @summary Tests the race condition between 
>> java.util.TimeZone.getDefault() and java.util.GregorianCalendar()
>> + * @run main SimpleTimeZoneTest
>> +*/
>> +
>> +import java.util.Calendar;
>> +import java.util.GregorianCalendar;
>> +import java.util.SimpleTimeZone;
>> +import java.util.TimeZone;
>> +
>> +public class SimpleTimeZoneTest extends Thread {
>> +??? Calendar cal;
>> +
>> +??? public SimpleTimeZoneTest (Calendar cal) {
>> +??????? this.cal = cal;
>> +??? }
>> +
>> +??? public static void main (String[] args) {
>> +??????? TimeZone stz = new SimpleTimeZone(7200000, "Asia/Jerusalem", 
>> Calendar.MARCH, 27, 0, 3600000, Calendar.SEPTEMBER, 16, 0, 3600000);
>> +??????? TimeZone.setDefault(stz);
>> +
>> +??????? SimpleTimeZoneTest stt = new SimpleTimeZoneTest(new 
>> GregorianCalendar());
>> +??????? stt.setDaemon(true);
>> +??????? stt.start();
>> +
>> +??????? for (int i = 0; i < 50000; i++) {
>> +??????????? Calendar cal = new GregorianCalendar();
>> +??????????? cal.clear();
>> +??????????? cal.getTimeInMillis();
>> +??????????? cal.set(2014, 2, 2);
>> +??????????? cal.clear();
>> +??????????? cal.getTimeInMillis();
>> +??????????? cal.set(1970, 2, 2);
>> +??????? }
>> +
>> +??? }
>> +
>> +??? public void run() {
>> +??????? while (true) {
>> +??????????? cal.setTimeZone(TimeZone.getDefault());
>> +??????????? cal.clear();
>> +??????????? cal.set(2008, 9, 9);
>> +??????????? Calendar calInst = java.util.Calendar.getInstance();
>> +??????????? calInst.setTimeInMillis(cal.getTimeInMillis());
>> +
>> +??????????? if (calInst.get(java.util.Calendar.HOUR_OF_DAY) != 
>> cal.get(java.util.Calendar.HOUR_OF_DAY) ||
>> +??????????????? calInst.get(java.util.Calendar.MINUTE) != 
>> cal.get(java.util.Calendar.MINUTE) ||
>> +??????????????? calInst.get(java.util.Calendar.SECOND) != 
>> cal.get(java.util.Calendar.SECOND) ||
>> +??????????????? calInst.get(java.util.Calendar.MILLISECOND) != 
>> cal.get(java.util.Calendar.MILLISECOND)) {
>> +??????????????????? throw new RuntimeException("Test failed");
>> +??????????? }
>> +??????? }
>> +??? }
>> +}
>>
>>
>> On 10/11/17 9:29 PM, Se?n Coffey wrote:
>>> I think the OpenJDK mailing lists accept attachments if in patch 
>>> format. If it's a simple short patch, it's acceptable to paste it 
>>> into email body.
>>>
>>> Easiest solution is to use webrev[1]. If you can't upload this to 
>>> cr.openjdk.java.net - then one of your colleagues may be able to help.
>>>
>>> [1] http://openjdk.java.net/guide/webrevHelp.html
>>>
>>> Regards,
>>> Sean.
>>>
>>> On 10/11/17 12:18, Venkateswara R Chintala wrote:
>>>> Looks like the patch attached earlier is not visible. As this is my 
>>>> first contribution, please let me know how I can send the patch for 
>>>> review.
>>>>
>>>>
>>>> On 10/11/17 5:37 PM, Venkateswara R Chintala wrote:
>>>>> Hi,
>>>>>
>>>>> In a multi-threaded environment, when java.util.SimpleTimeZone 
>>>>> object is used to create a default timezone, there can be a race 
>>>>> condition between the methods java.util.Timezone.getDefault() and 
>>>>> java.util.Timezone.getDefaultRef() which can result in 
>>>>> inconsistency of cache that is used to validate a particular 
>>>>> time/date in DST.
>>>>>
>>>>> When a thread is cloning a default timezone object 
>>>>> (SimpleTimeZone) and at the same time if a different thread 
>>>>> modifies the time/year values, then the cache values (cacheYear, 
>>>>> cacheStart, cacheEnd) can become inconsistent which leads to 
>>>>> incorrect DST determination.
>>>>>
>>>>> We considered two approaches to fix the issue.
>>>>>
>>>>> 1)Synchronize access to cloning default timezone object when cache 
>>>>> is being modified.
>>>>>
>>>>> 2)Invalidate the cache while returning the clone.
>>>>>
>>>>> We preferred the second option as synchronization is more expensive.
>>>>>
>>>>> We have attached the patch and jtreg testcase. Please review.
>>>>>
>>>>
>>>
>>>
>>


From peter.levart at gmail.com  Tue Nov 14 15:16:53 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 14 Nov 2017 16:16:53 +0100
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <d74ffdce-793a-bfe9-7e5f-4964897c3553@linux.vnet.ibm.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>
 <84ca56e0-67c8-3fbb-d558-4ebe797d513c@oracle.com>
 <8894f619-3510-acfa-3987-f013ca3638f3@gmail.com>
 <b68da9c6-1ad4-6926-7c27-21680e3b73b0@gmail.com>
 <d74ffdce-793a-bfe9-7e5f-4964897c3553@linux.vnet.ibm.com>
Message-ID: <bef944fa-2a15-6c83-6730-ff7e32aa063f@gmail.com>

Hi Venkat,

I created the following issue:

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

I can also sponsor this patch and push it for JDK 10.

The patch that you are proposing looks good to me. Does anybody have 
anything else to say?

Regards, Peter


On 11/13/2017 11:28 AM, Venkateswara R Chintala wrote:
> Thanks David, Peter for your review and comments. As I am new to the 
> community, can you please help me to open a bug and integrate the 
> changes into code base?
>
> -Venkat
>
> On 12/11/17 2:19 AM, Peter Levart wrote:
>> Hi David, Venkat,
>>
>> On 11/11/17 21:15, Peter Levart wrote:
>>> For example, take the following method:
>>>
>>> String defaultTZID() {
>>> ??? return TimeZone.getDefault().getID();
>>> }
>>>
>>> When JIT compiles it and inlines invocations to other methods within 
>>> it, it can prove that cloned TimeZone instance never escapes the 
>>> call to defaultTZID() and can therefore skip allocating the instance 
>>> on heap.
>>>
>>> But this is fragile. If code in invoked methods changes, they may 
>>> not get inlined or EA may not be able to prove that the cloned 
>>> instance can't escape and allocation may be introduced. 
>>> ZoneId.systemDefault() is a hot method and it would be nice if we 
>>> manage to keep it allocation free.
>>
>> Well, I tried the following variant of SimpleTimeZone.clone() patch:
>>
>> ??? public Object clone()
>> ??? {
>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>> ??????? // like tz.invalidateCache() but without holding a lock on clone
>> ??????? tz.cacheYear = tz.startYear - 1;
>> ??????? tz.cacheStart = tz.cacheEnd = 0;
>> ??????? return tz;
>> ??? }
>>
>>
>> ...and the JMH benchmark with gc profiling shows that 
>> ZoneId.systemDefault() still manages to get JIT-compiled without 
>> introducing allocation.
>>
>> Even the following (original Venkat's) patch:
>>
>> ??? public Object clone()
>> ??? {
>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>> ??????? tz.invalidateCache();
>> ??????? return tz;
>> ??? }
>>
>> ...does the same and the locking in invalidateCache() is elided too. 
>> Allocation and lock-elision go hand-in-hand. When object doesn't 
>> escape, allocation on heap may be eliminated and locks on that 
>> instance elided.
>>
>> So this is better than synchronizing on the original instance during 
>> .clone() execution as it has potential to avoid locking overhead.
>>
>> So Venkat, go ahead. My fear was unjustified.
>>
>> Regards, Peter
>>
>


From peter.levart at gmail.com  Tue Nov 14 15:32:19 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 14 Nov 2017 16:32:19 +0100
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <1F53EBF0-AC41-4DDF-949A-BE6DA91CCA47@reini.net>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <CAE+3fjYzgEMmFFOge6hdN9wi3qS=5OCTKJKupeLbf-gaaPf9eQ@mail.gmail.com>
 <d02cf931-6bd4-3b99-3375-dbce6e8047c8@oracle.com>
 <2a20565b-83f5-a39d-8b31-ac70c64ff8b9@gmail.com>
 <c2137520-677d-2a7c-898a-2b8884df96f3@oracle.com>
 <1F53EBF0-AC41-4DDF-949A-BE6DA91CCA47@reini.net>
Message-ID: <cd692a24-ecc8-597c-a3f5-262ef3eeee66@gmail.com>

Hi Patrick,

On 11/10/2017 09:49 AM, Patrick Reinhart wrote:
> Hi Stuart,
>
> After having thought over your arguments about copyOf versus unmodifiableCopyOf length discussion (also with my colleague) I was thinking about why not create additional X.of(X) methods instead of X.copyOf(X). It would seem to me a logical enhancement in the sense of the existing API though.
>
> -Patrick

I'm sure Stuart thought of that, but decided against it because of usual 
ambiguity problems that occur when two candidate .of() methods apply at 
the same time, for example:

List<String> strings = List.of("a", "b", "c");

List<?> foo = List.of(strings);

What did programmer want to end up in foo, List<List<String>> or 
List<String>? What did javac choose? Answers may differ.

Regards, Peter

>
>> Am 02.11.2017 um 23:04 schrieb Stuart Marks <stuart.marks at oracle.com>:
>>
>>
>>> Why not using:
>>>
>>>      coll.stream().collect(Collectors.toImmutableSet())
>>>
>>> As Collectors.toImmutableSet() is currently implemented, with serial Stream it will create a single HashSet, add all the elements to it and call Set.of(HashSet.toArray()) with it. Pretty much the same as what Tagir proposes, but the Collector could be made more efficient in the future and with it, the optimization would automatically extend to Set.copyOf()...
>> This is mainly about whether Set.copyOf() is implemented in terms of Collectors.toUnmodifiableSet(), or vice-versa, which then calls Set.of(T[]) to do the actual creation. Some future optimization will probably replace both of these implementations with calls to JDK internal methods that can bypass the extra copying, so it doesn't really matter which one of these calls the other right now.
>>
>> s'marks
>>


From brian.burkhalter at oracle.com  Tue Nov 14 15:33:00 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 14 Nov 2017 07:33:00 -0800
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <733069a3-33cb-3c68-0a51-6e33a7086f1b@oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
 <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
 <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>
 <8167AB26-7918-4920-A889-4FB2F2254BE5@reini.net>
 <3755dc7c-84b2-61a8-06a2-e45f5007f8b7@Oracle.com>
 <2D157CBB-65F0-41B1-8DB5-99F45BB8A412@reini.net>
 <52b9afdc-4103-3bf8-c111-9b0310e1f913@Oracle.com>
 <51486A9D-4982-47E3-9E64-4925E34BD488@reini.net>
 <AD985969-3146-4495-9328-4598C17653C0@oracle.com>
 <8999FF83-ACA0-44B6-B60B-E6544F6D192E@reini.net>
 <733069a3-33cb-3c68-0a51-6e33a7086f1! b@oracle.com>
Message-ID: <28639443-48BF-4C74-AA4C-17433E202F00@oracle.com>


On Nov 14, 2017, at 3:45 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> - Readable "hence unspecified". In several other places, including InputStream.transferTo, we use "therefore unspecified" and it would be good to keep that consistent.

Mea culpa on the ?hence.?

> - Readable "Depending on which class implements the appendable ...". What would you think about replacing this sentence with: "If the destination is capacity bounded and has insufficient capacity to append all characters read from the source then an exception will be thrown after transferring zero or some bytes to the destination".

s/zero or some/zero or more/

Brian

From patrick at reini.net  Tue Nov 14 16:59:26 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 14 Nov 2017 17:59:26 +0100
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <28639443-48BF-4C74-AA4C-17433E202F00@oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
 <e1b48961-8030-6ba9-061f-c6e9b9a4a246@oracle.com>
 <484ae491-9988-b977-1ddc-aded096b3784@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
 <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
 <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>
 <8167AB26-7918-4920-A889-4FB2F2254BE5@reini.net>
 <3755dc7c-84b2-61a8-06a2-e45f5007f8b7@Oracle.com>
 <2D157CBB-65F0-41B1-8DB5-99F45BB8A412@reini.net>
 <52b9afdc-4103-3bf8-c111-9b0310e1f913@Oracle.com>
 <51486A9D-4982-47E3-9E64-4925E34BD488@reini.net>
 <AD985969-3146-4495-9328-4598C17653C0@oracle.com>
 <8999FF83-ACA0-44B6-B60B-E6544F6D192E@reini.net>
 <733069a3-33cb-3c68-0a51-6e33a7086f1! b@oracle.com>
 <28639443-48BF-4C74-AA4C-17433E202F00@oracle.com>
Message-ID: <0E5B3DBE-20DF-4B68-857B-6BA8DECD8C13@reini.net>



> Am 14.11.2017 um 16:33 schrieb Brian Burkhalter <brian.burkhalter at oracle.com>:
> 
> 
> On Nov 14, 2017, at 3:45 AM, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
> 
>> - Readable "hence unspecified". In several other places, including InputStream.transferTo, we use "therefore unspecified" and it would be good to keep that consistent.
> 
> Mea culpa on the ?hence.?

So I will change ?hence unspecified? back to ?therefore unspecified? here..

> 
>> - Readable "Depending on which class implements the appendable ...". What would you think about replacing this sentence with: "If the destination is capacity bounded and has insufficient capacity to append all characters read from the source then an exception will be thrown after transferring zero or some bytes to the destination".
> 
> s/zero or some/zero or more/
> 

And what should it be then here? I?m a bit confused now?

-Patrick


From aph at redhat.com  Tue Nov 14 17:30:27 2017
From: aph at redhat.com (Andrew Haley)
Date: Tue, 14 Nov 2017 17:30:27 +0000
Subject: Faster Math ?
In-Reply-To: <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>
References: <CAKjRUT7V1swPZJkEJKOtde-vZQgvAOg=_=uA-e9t+Z+QySMoVQ@mail.gmail.com>
 <CAKjRUT7wdnuGnX=n4YA0TnQuCe98tHorCBqAvhFbAFS=W1+4ag@mail.gmail.com>
 <CAKjRUT4j-R60NpCmEcs+x5-whmobyvBcAHSqecaH6PFG_NzaZA@mail.gmail.com>
 <CAKjRUT46GRnUqNgD-s81z_qYd0-_Rj-VQUgtVsMSUMKfHqJOxw@mail.gmail.com>
 <CAKjRUT5Ltn=4URTR2NXDgFis=b9s6e2TJS-FCK5qqqeyAXswuA@mail.gmail.com>
 <CAKjRUT7XkZevTau--k8avcUX6KE_bZmgRwJaGSx-2rt=Nz-4=Q@mail.gmail.com>
 <CAKjRUT668ng+Xh08a4VzJt4vPceuQp4VyOuRF2X=nZK+R4RHzw@mail.gmail.com>
 <CAKjRUT7K0evbnjY0ixzhMB54MEXiJxCkW4es_C1vLJ-hWywCaA@mail.gmail.com>
 <CAKjRUT6sbq8GoPLfZUtirvSX7okWSW+xOQ5B=rggOkYJ889PYQ@mail.gmail.com>
 <CAKjRUT48TpyU8XgHNewSu7Vt_GKMOS3-D7sKa6VuGTiNPERaSA@mail.gmail.com>
 <CAKjRUT6i8iSF07USPhY=jTPU5dc4g7rNn9WuA+DHRQioMS=1og@mail.gmail.com>
 <CAKjRUT4ezaSE5mPMNfXQaQfgu+3Y34+O1yBTvnbJ6Rmv+mkUyw@mail.gmail.com>
 <CAKjRUT4iFEZ1p-OLYAOiyKVmiTGLSPN0-HJVRwLGboxqgv4xkA@mail.gmail.com>
 <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>
Message-ID: <f32e0096-ca56-7f9a-1643-4e10f7e00f2a@redhat.com>

On 09/11/17 09:00, Laurent Bourg?s wrote:

> The Marlin renderer (JEP265) uses few Math functions: sqrt, cbrt, acos...
> 
> Could you check if the current JDK uses C2 intrinsics or libfdm (native /
> JNI overhead?) and tell me if such functions are already highly optimized
> in jdk9 or 10 ?
> 
> Some people have implemented their own fast Math like Apache Commons Math
> or JaFaMa libraries that are 10x faster for acos / cbrt.

I'm not seeing that with Apache Commons Math.  I'm seeing this:

Benchmark                   Mode  Cnt   Score   Error  Units
MathBenchmark.fastMathCbrt  avgt    5  33.199 ? 0.122  ns/op
MathBenchmark.mathCbrt      avgt    5  43.124 ? 0.162  ns/op
MathBenchmark.fastMathAcos  avgt    5  85.985 ? 4.586  ns/op
MathBenchmark.mathAcos      avgt    5  28.326 ? 0.044  ns/op

It's nice, but it certainly isn't 10x.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From claes.redestad at oracle.com  Tue Nov 14 17:35:30 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 14 Nov 2017 18:35:30 +0100
Subject: 8184777: Factor out species generation logic from
 BoundMethodHandle
In-Reply-To: <000001d35d54$fa2d38a0$ee87a9e0$@freenet.de>
References: <16275878-b9a7-7b79-dc76-99d5d2f4ee41@oracle.com>
 <005501d35ca8$aed6cc10$0c846430$@freenet.de>
 <016627e6-da96-54f3-18a1-66ff79b8a132@oracle.com>
 <000001d35d54$fa2d38a0$ee87a9e0$@freenet.de>
Message-ID: <fe0c8e59-06b0-328e-3fba-6b2c9f6a63c4@oracle.com>

Hi Christoph,

On 2017-11-14 15:29, Christoph Dreis wrote:
> I still think it should be called "one integral bound value" instead of "values" and "has" instead of "have" (at least in case a singular species is meant).
> You seem to have fixed the singular "reference" typo only in ClassSpecializer.java.

I read your comment too fast. Fixed!

>
> While looking at ClassSpecializer again, I found two additional editorial things I wanted to raise:
>
> 1.)
> 364          * @return class name, which by default is {@code outer().topClass().getName() + "$Species_" + deriveTypeString(key)}
>   365          */
>   366         protected String deriveClassName() {
>   367             return topClass.getName() + "$Species_" + deriveTypeString();
>   368         }
>
> The @return doesn't seem to match the implementation. This looks a bit weird at least.

Updated code to match documentation.

>
> 2.)
> 328          * and produces a value of the required type.
> Should be "produce a value" given that "supply" is used some lines above.

Fixed!

>
> Again - I hope you don't mind these minor comments.

Don't mind at all. Some of the typos here were pre-existing, and while 
this is
internal code, it surely doesn't hurt cleaning up comments.

http://cr.openjdk.java.net/~redestad/8184777/open.01/

Thanks!

/Claes

From sean.mullan at oracle.com  Tue Nov 14 20:02:43 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 14 Nov 2017 15:02:43 -0500
Subject: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only
 the permissions it really needs to expose the bean
In-Reply-To: <2454131.31SKLb3dS1@pracovni>
References: <2138013.zvGs44vPXg@pracovni>
 <610c8d9d-9b01-d874-8794-1b99fc8a150e@oracle.com>
 <10208568.Zsd4Z32fDf@pracovni> <2454131.31SKLb3dS1@pracovni>
Message-ID: <715d933a-a747-8aac-620b-fba12f4236e0@oracle.com>

Try running with -Djava.security.debug=access:domain:failure

This will tell you what ProtectionDomain caused the 
AccessControlException, which should give you a better idea of where the 
problem is. Look for messages that start with "domain that failed ".

--Sean


On 11/14/17 1:22 AM, Jaroslav Tulach wrote:
> I tried the same test with
> 
> changeset:   47679:d85284ccd1bd
> user:        sspitsyn
> date:        Fri Nov 03 17:09:25 2017 -0700
> summary:     8189731: Disable CFLH when there are no transformers
> 
> and it also yields the exception. E.g. the problem is certainly not result of
> my changes.
> 
> -jt
> 
> PS: I try full rebuild on d85284ccd1bd maybe it disappears...
> 
> 
> On pond?l? 13. listopadu 2017 20:53:35 CET Jaroslav Tulach wrote:
>> Hello Mandy,
>>
>> this was a good test:
>>>> ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
>>>> +EnableJVMCI -XX:+UseJVMCICompiler -jar ...
>>>
>>> You can also try running the above command with -Djava.security.manager
>>> as a sanity test (the application may need additional permissions) -
>>> just a sanity test.
>>
>> I've just tried:
>>
>> $ ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
>> +EnableJVMCI -XX:+UseJVMCICompiler -Djava.security.manager -jar ~/
>> NetBeansProjects/sieve/java/algorithm/target/sieve-algorithm-1.0-SNAPSHOT.ja
>> r
>>
>> and it doesn't work. I am getting an error below, however the code is not
>> running through my module at all. I don't understand the failure, I will
>> have to investigate more.
>>
>> -jt
>>
>>
>> Caused by: java.security.AccessControlException: access denied
>> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.vm.ci.services")
>>          at java.base/
>> java.security.AccessControlContext.checkPermission(AccessControlContext.java
>> : 472)
>>          at java.base/
>> java.security.AccessController.checkPermission(AccessController.java:895)
>>          at java.base/
>> java.lang.SecurityManager.checkPermission(SecurityManager.java:558)
>>          at java.base/
>> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1534)
>>          at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:680)
>>          at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:678)
>>          at java.base/java.security.AccessController.doPrivileged(Native
>> Method)
>>          at java.base/
>> java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:678)
>>          at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>>          at
>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1006) at
>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1085) at
>> java.base/
>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:206)
>>          at java.base/
>> jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:7
>> 60) at java.base/jdk.internal.loader.BuiltinClassLoader.lambda
>> $findClassInModuleOrNull$2(BuiltinClassLoader.java:683)
>>          at java.base/java.security.AccessController.doPrivileged(Native
>> Method)
>>          at java.base/
>> jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassL
>> oader.java: 684)
>>          at java.base/
>> jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:562
>> ) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:607) at
>> java.base/java.lang.Class.forName(Class.java:451)
>>          at java.base/java.util.ServiceLoader.lambda$loadProvider
>> $1(ServiceLoader.java:856)
>>          at java.base/java.security.AccessController.doPrivileged(Native
>> Method)
>>          at
>> java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java: 858)
> 
> 

From Roger.Riggs at Oracle.com  Tue Nov 14 21:28:00 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 14 Nov 2017 16:28:00 -0500
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
Message-ID: <9d79807d-1b45-4961-7f35-a8335098302c@Oracle.com>

Hi Naoto,

A few comments, there is lots here to review.

tools/cldrconverter/LDMLParseHandler.java:
- 948: TODO?


DateFormatSymbols.java:
 ?- 88: "overriden" -> "overridden"

DecimalFormatSymbols:
 ?- 60: "rg" -> "nu"?
 ?- 62: "overriden" -> "overridden"

NumberFormat.java:
 ?- 106: "a <code>NumberFormat</code>" ->? "{@code NumberFormat}

java/time/format/DateTimeFormatter.java:
 ?- 136, 561, 589, 1463: "overriden" -> "overridden"

- 1486: long line, wrap please

DateTimeFormatterBuilder.java:
- 2168,2194:? - 62: "overriden" -> "overridden"

java/util/Calendar.java:

138 * They may also be specified explicitly through the methods for 
setting their
139 * values.

java/util/spi/LocaleNameProvider.java:
 ?167, 193: looks a bit odd to return null but maybe that's the default 
if not overridden

It looks like a few misc changes are included too:
 ?- LauncherHelper:? 271: getDisplayName()...


CalendarDataProviderImpl.java:
 ?- 51, 58:? Should these limit the value to 0-6 to avoid odd 
arithmetic;? (Throw an exception if out of range)

LocaleNameProviderImpl.java:
 ?- 176/186:? Did you want to call super to do the RequiresNonNull 
checks? Or will the NPEs happen naturally.

SPILocaleProviderAdapter.java:
- 578,? 585: assert seems like of useless here;? if null, will NPE; only 
if asserts are enabled behavior will change to AssertError

(I have not looked at the tests)

Regards, Roger



On 11/9/2017 6:34 PM, Naoto Sato wrote:
> Kindly requesting reviews. I incorporated a fix to the following issue 
> raised by the test team:
>
> https://bugs.openjdk.java.net/browse/JDK-8190918
>
> Here is the updated webrev:
>
> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/
>
> And the webrev since the one below (to address 8190918):
>
> http://cr.openjdk.java.net/~naoto/8190918/
>
> Naoto
>
>
>
> On 11/2/17 2:42 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the proposed changes for the following issues:
>>
>> 8176841: Additional Unicode Language-Tag Extensions
>> 8189134: New system properties for the default Locale extensions
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
>>
>> This serves as the implementation of JEP 314.
>>
>> Naoto
>>
>>
>>


From david.holmes at oracle.com  Tue Nov 14 21:28:20 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 15 Nov 2017 07:28:20 +1000
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <8d9b27b8-816c-3fbe-cff0-a17e5d0d7918@gmail.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <798167c6-c562-f247-b77b-b6da38bcce9e@oracle.com>
 <8d9b27b8-816c-3fbe-cff0-a17e5d0d7918@gmail.com>
Message-ID: <352f9bb5-77b6-af47-dad2-95ebf1ba7660@oracle.com>

Hi Peter,

On 15/11/2017 1:02 AM, Peter Levart wrote:
> Hi David,
> 
> On 11/11/2017 07:51 AM, David Holmes wrote:
>> AFAICS SimpleTimeZone is simply not thread-safe. It has state that can 
>> be modified concurrently without synchronization and with fields not 
>> even declared volatile. Only the "cache" makes an attempt to use 
>> synchronization. So clone() is never guaranteed to actually produce a 
>> copy with valid/consistent field values.
>>
>> The suggested patch certainly improves the situation by at least 
>> resetting the cache of the cloned instance before returning it.
> 
> The instance of SimpleTimeZone that is shared among threads (internally 
> in JDK) is the defaultTimeZone instance (obtained through 
> package-private TimeZone.getDefaultRef() method). I checked the usages 
> and they seem to be "read-only" - not modifying the instance, just 
> obtaining information from it. The cache OTOH, as you say, is synchronized.

The initial problem statement was:

"When a thread is cloning a default timezone object (SimpleTimeZone) and 
at the same time if a different thread modifies the time/year values, ..."

so that doesn't seem to be read-only. Though perhaps it is a very 
specific race.

> TimeZone and subclasses seem to be designed to be modified by single 
> thread only, but can be used from multiple threads to read the 
> information from them, including lazily computed and cached information. 
> Usage withing JDK seems to comply with that.

There's certainly no documentation of any such intent, or design. Seems 
more like the synchronization has been added (or not) based on how it is 
used within JDK rather than considering the actual API of the public types.

> 
> Venkat's patch therefore correctly fixes the remaining issue that is 

Okay. As I said it certainly makes things better.

Cheers,
David

> observed when the shared SimpleTimeZone instance is being cloned while 
> also being accessed from multiple threads in read-only mode. 
> Invalidating cache of the cloned instance just before returning it from 
> clone() method means that instance obtained from TimeZone.getDefault() 
> will never get cached state from original instance and will always have 
> to re-compute it, but I think this is still better than synchronizing on 
> the original instance which may never be optimized away (i.e. elided) by 
> JIT.
> 
> Regards, Peter
> 
>>
>> David
>>
>> On 11/11/2017 3:53 PM, Venkateswara R Chintala wrote:
>>> Thanks Sean. I am pasting the patch here:
>>>
>>> --- old/src/java.base/share/classes/java/util/SimpleTimeZone.java 
>>> 2017-11-11 11:17:38.643867420 +0530
>>> +++ new/src/java.base/share/classes/java/util/SimpleTimeZone.java 
>>> 2017-11-11 11:17:38.375870421 +0530
>>> @@ -868,7 +868,11 @@
>>> ?????? */
>>> ????? public Object clone()
>>> ????? {
>>> -??????? return super.clone();
>>> +??????? // Invalidate the time zone cache while cloning as it
>>> +??????? // can be inconsistent due to race condition.
>>> +??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>> +??????? tz.invalidateCache();
>>> +??????? return tz;
>>> ????? }
>>>
>>> ????? /**
>>> --- /dev/null??? 2017-11-02 17:09:59.155627814 +0530
>>> +++ new/test/java/util/TimeZone/SimpleTimeZoneTest.java 2017-11-11 
>>> 11:17:38.867864912 +0530
>>> @@ -0,0 +1,55 @@
>>> +/*
>>> + * @test
>>> + * @summary Tests the race condition between 
>>> java.util.TimeZone.getDefault() and java.util.GregorianCalendar()
>>> + * @run main SimpleTimeZoneTest
>>> +*/
>>> +
>>> +import java.util.Calendar;
>>> +import java.util.GregorianCalendar;
>>> +import java.util.SimpleTimeZone;
>>> +import java.util.TimeZone;
>>> +
>>> +public class SimpleTimeZoneTest extends Thread {
>>> +??? Calendar cal;
>>> +
>>> +??? public SimpleTimeZoneTest (Calendar cal) {
>>> +??????? this.cal = cal;
>>> +??? }
>>> +
>>> +??? public static void main (String[] args) {
>>> +??????? TimeZone stz = new SimpleTimeZone(7200000, "Asia/Jerusalem", 
>>> Calendar.MARCH, 27, 0, 3600000, Calendar.SEPTEMBER, 16, 0, 3600000);
>>> +??????? TimeZone.setDefault(stz);
>>> +
>>> +??????? SimpleTimeZoneTest stt = new SimpleTimeZoneTest(new 
>>> GregorianCalendar());
>>> +??????? stt.setDaemon(true);
>>> +??????? stt.start();
>>> +
>>> +??????? for (int i = 0; i < 50000; i++) {
>>> +??????????? Calendar cal = new GregorianCalendar();
>>> +??????????? cal.clear();
>>> +??????????? cal.getTimeInMillis();
>>> +??????????? cal.set(2014, 2, 2);
>>> +??????????? cal.clear();
>>> +??????????? cal.getTimeInMillis();
>>> +??????????? cal.set(1970, 2, 2);
>>> +??????? }
>>> +
>>> +??? }
>>> +
>>> +??? public void run() {
>>> +??????? while (true) {
>>> +??????????? cal.setTimeZone(TimeZone.getDefault());
>>> +??????????? cal.clear();
>>> +??????????? cal.set(2008, 9, 9);
>>> +??????????? Calendar calInst = java.util.Calendar.getInstance();
>>> +??????????? calInst.setTimeInMillis(cal.getTimeInMillis());
>>> +
>>> +??????????? if (calInst.get(java.util.Calendar.HOUR_OF_DAY) != 
>>> cal.get(java.util.Calendar.HOUR_OF_DAY) ||
>>> +??????????????? calInst.get(java.util.Calendar.MINUTE) != 
>>> cal.get(java.util.Calendar.MINUTE) ||
>>> +??????????????? calInst.get(java.util.Calendar.SECOND) != 
>>> cal.get(java.util.Calendar.SECOND) ||
>>> +??????????????? calInst.get(java.util.Calendar.MILLISECOND) != 
>>> cal.get(java.util.Calendar.MILLISECOND)) {
>>> +??????????????????? throw new RuntimeException("Test failed");
>>> +??????????? }
>>> +??????? }
>>> +??? }
>>> +}
>>>
>>>
>>> On 10/11/17 9:29 PM, Se?n Coffey wrote:
>>>> I think the OpenJDK mailing lists accept attachments if in patch 
>>>> format. If it's a simple short patch, it's acceptable to paste it 
>>>> into email body.
>>>>
>>>> Easiest solution is to use webrev[1]. If you can't upload this to 
>>>> cr.openjdk.java.net - then one of your colleagues may be able to help.
>>>>
>>>> [1] http://openjdk.java.net/guide/webrevHelp.html
>>>>
>>>> Regards,
>>>> Sean.
>>>>
>>>> On 10/11/17 12:18, Venkateswara R Chintala wrote:
>>>>> Looks like the patch attached earlier is not visible. As this is my 
>>>>> first contribution, please let me know how I can send the patch for 
>>>>> review.
>>>>>
>>>>>
>>>>> On 10/11/17 5:37 PM, Venkateswara R Chintala wrote:
>>>>>> Hi,
>>>>>>
>>>>>> In a multi-threaded environment, when java.util.SimpleTimeZone 
>>>>>> object is used to create a default timezone, there can be a race 
>>>>>> condition between the methods java.util.Timezone.getDefault() and 
>>>>>> java.util.Timezone.getDefaultRef() which can result in 
>>>>>> inconsistency of cache that is used to validate a particular 
>>>>>> time/date in DST.
>>>>>>
>>>>>> When a thread is cloning a default timezone object 
>>>>>> (SimpleTimeZone) and at the same time if a different thread 
>>>>>> modifies the time/year values, then the cache values (cacheYear, 
>>>>>> cacheStart, cacheEnd) can become inconsistent which leads to 
>>>>>> incorrect DST determination.
>>>>>>
>>>>>> We considered two approaches to fix the issue.
>>>>>>
>>>>>> 1)Synchronize access to cloning default timezone object when cache 
>>>>>> is being modified.
>>>>>>
>>>>>> 2)Invalidate the cache while returning the clone.
>>>>>>
>>>>>> We preferred the second option as synchronization is more expensive.
>>>>>>
>>>>>> We have attached the patch and jtreg testcase. Please review.
>>>>>>
>>>>>
>>>>
>>>>
>>>
> 

From fundasecgin33 at gmail.com  Tue Nov 14 20:37:00 2017
From: fundasecgin33 at gmail.com (Funda Secgin)
Date: Tue, 14 Nov 2017 20:37:00 +0000
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
Message-ID: <CABdidKVUZRQ6eYi-gZF14VEDaNCiy21i3wsFxAYVX8EGwGrA+A@mail.gmail.com>

-- 

Fs

From lance.andersen at oracle.com  Tue Nov 14 22:34:41 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 14 Nov 2017 17:34:41 -0500
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <9d79807d-1b45-4961-7f35-a8335098302c@Oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <9d79807d-1b45-4961-7f35-a8335098302c@Oracle.com>
Message-ID: <FF441B3C-E37D-4C8F-A1F9-A9F3BA335867@oracle.com>

Hi Naoto

DateTimeFormatter.java, DateTimeFormatterBuilder.java, WeekFields.java., Calendar.java, Currency.java (and others)

??????
 136  * the chronology and/or the zone are also overriden. If both "ca" and "rg" are
 137  * specified, the chronology from "ca" extension supersedes the implicit one
 138  * from "rg" extension.
????????

I would consider changing 137 ?? from the ?ca extension? and ?? from the ?rg? extension"


I agree wth Rogers suggestion to use @{code} for the new javadoc if at all possible

The tests look reasonable.  I was curious why a few of the new tests such as CalendarDataTest.java are not using TestNG where others are.

> On Nov 14, 2017, at 4:28 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Hi Naoto,
> 
> A few comments, there is lots here to review.
> 
> tools/cldrconverter/LDMLParseHandler.java:
> - 948: TODO?
> 
> 
> DateFormatSymbols.java:
>  - 88: "overriden" -> "overridden"
> 
> DecimalFormatSymbols:
>  - 60: "rg" -> "nu"?
>  - 62: "overriden" -> "overridden"
> 
> NumberFormat.java:
>  - 106: "a <code>NumberFormat</code>" ->  "{@code NumberFormat}
> 
> java/time/format/DateTimeFormatter.java:
>  - 136, 561, 589, 1463: "overriden" -> "overridden"
> 
> - 1486: long line, wrap please
> 
> DateTimeFormatterBuilder.java:
> - 2168,2194:  - 62: "overriden" -> "overridden"
> 
> java/util/Calendar.java:
> 
> 138 * They may also be specified explicitly through the methods for setting their
> 139 * values.
> 
> java/util/spi/LocaleNameProvider.java:
>  167, 193: looks a bit odd to return null but maybe that's the default if not overridden

Yeah, could you explain when null would not be returned, or is this just stubbed out code for now?
> 
> It looks like a few misc changes are included too:
>  - LauncherHelper:  271: getDisplayName()...
> 
> 
> CalendarDataProviderImpl.java:
>  - 51, 58:  Should these limit the value to 0-6 to avoid odd arithmetic;  (Throw an exception if out of range)
> 
> LocaleNameProviderImpl.java:
>  - 176/186:  Did you want to call super to do the RequiresNonNull checks? Or will the NPEs happen naturally.
> 
> SPILocaleProviderAdapter.java:
> - 578,  585: assert seems like of useless here;  if null, will NPE; only if asserts are enabled behavior will change to AssertError
> 
> (I have not looked at the tests)
> 
> Regards, Roger
> 
> 
> 
> On 11/9/2017 6:34 PM, Naoto Sato wrote:
>> Kindly requesting reviews. I incorporated a fix to the following issue raised by the test team:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8190918
>> 
>> Here is the updated webrev:
>> 
>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/
>> 
>> And the webrev since the one below (to address 8190918):
>> 
>> http://cr.openjdk.java.net/~naoto/8190918/
>> 
>> Naoto
>> 
>> 
>> 
>> On 11/2/17 2:42 PM, Naoto Sato wrote:
>>> Hello,
>>> 
>>> Please review the proposed changes for the following issues:
>>> 
>>> 8176841: Additional Unicode Language-Tag Extensions
>>> 8189134: New system properties for the default Locale extensions
>>> 
>>> The proposed changeset is located at:
>>> 
>>> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
>>> 
>>> This serves as the implementation of JEP 314.
>>> 
>>> Naoto
>>> 
>>> 
>>> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From scolebourne at joda.org  Tue Nov 14 23:22:58 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 14 Nov 2017 23:22:58 +0000
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
Message-ID: <CACzrW9C+GekWNRdWVi1AhVs_CiPgWksde-6iRT1Z68-RhkziZw@mail.gmail.com>

I'd missed that this affects java.time.*

I believe that the changes to DateTimeFormatter are a mistake and will
cause confusion. Currently, each withXxx() method is independent -
they do not interact and operate on a single piece of state.

Currently, these two pieces of code have the same effect:

 formatter = formatter.withZone(zone).withLocale(locale);
 formatter = formatter.withLocale(locale).withZone(zone);

With the webrev, that is no longer true.

While I understand the desire of the change, I believe it would be a
serious mistake and a cause of end-user bugs.

The best I can suggest is adding a new method withLocalization(Locale)
or applyLocalization(Locale) or localized(Locale), which is documented
to replace multiple parts of the state in one go.


There are other oddities.
 DateTimeFormatterBuilder.getLocalizedDateTimePattern() takes in a
Chronology, thus the calendar system in the locale is ignored.
Probably correct, but not called out in the docs.

 DateTimeFormatterBuilder.toFormatter(Locale, ResolverStyle,
Chronology) has new logic to override the chronology. But this method
is used indirectly from ofLocalizedTime() and friends which require
the output to be ISO chronology. Thus the webrev would break the
specification of those methods.

TimeZoneNameUtility.convertLDMLShortID() is followed by ZoneId.of()
which assumes that a full set of time-zones is loaded. But, the ZoneId
initialization system allows the whole set of time-zones to be
replaced, making this logic suspect, or at the very least needing
extra consideration/testing.

I think there is a case for
CalendarDataUtility.retrieveFirstDayOfWeek() to return DayOfWeek, not
int, but perhaps that is a separate change.

Stephen


On 9 November 2017 at 23:34, Naoto Sato <naoto.sato at oracle.com> wrote:
> Kindly requesting reviews. I incorporated a fix to the following issue
> raised by the test team:
>
> https://bugs.openjdk.java.net/browse/JDK-8190918
>
> Here is the updated webrev:
>
> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/
>
> And the webrev since the one below (to address 8190918):
>
> http://cr.openjdk.java.net/~naoto/8190918/
>
> Naoto
>
>
>
>
> On 11/2/17 2:42 PM, Naoto Sato wrote:
>>
>> Hello,
>>
>> Please review the proposed changes for the following issues:
>>
>> 8176841: Additional Unicode Language-Tag Extensions
>> 8189134: New system properties for the default Locale extensions
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
>>
>> This serves as the implementation of JEP 314.
>>
>> Naoto
>>
>>
>>
>

From naoto.sato at oracle.com  Tue Nov 14 23:45:53 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 14 Nov 2017 15:45:53 -0800
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <9d79807d-1b45-4961-7f35-a8335098302c@Oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <9d79807d-1b45-4961-7f35-a8335098302c@Oracle.com>
Message-ID: <bd6038d3-79ef-e7eb-e77d-185acfbb76ef@oracle.com>

Thanks, Roger.

On 11/14/17 1:28 PM, Roger Riggs wrote:
> Hi Naoto,
> 
> A few comments, there is lots here to review.
> 
> tools/cldrconverter/LDMLParseHandler.java:
> - 948: TODO?

Will remove it.

> DateFormatSymbols.java:
>  ?- 88: "overriden" -> "overridden"
> 
> DecimalFormatSymbols:
>  ?- 60: "rg" -> "nu"?

"nu" is mentioned in each constructor. "rg" is correct here.

>  ?- 62: "overriden" -> "overridden"
> 
> NumberFormat.java:
>  ?- 106: "a <code>NumberFormat</code>" ->? "{@code NumberFormat}
> 
> java/time/format/DateTimeFormatter.java:
>  ?- 136, 561, 589, 1463: "overriden" -> "overridden"
> 
> - 1486: long line, wrap please
> 
> DateTimeFormatterBuilder.java:
> - 2168,2194:? - 62: "overriden" -> "overridden"

All of those typos will be corrected.

> 
> java/util/Calendar.java:
> 
> 138 * They may also be specified explicitly through the methods for 
> setting their
> 139 * values.

What do you suggest here?

> 
> java/util/spi/LocaleNameProvider.java:
>  ?167, 193: looks a bit odd to return null but maybe that's the default 
> if not overridden

Yes, that's the default, and if it's null, then fall back to other 
possibilities, either parent locale or other locale provider.

> 
> It looks like a few misc changes are included too:
>  ?- LauncherHelper:? 271: getDisplayName()...

I had discussed this with Kumar, and he agreed to fix this.

> 
> 
> CalendarDataProviderImpl.java:
>  ?- 51, 58:? Should these limit the value to 0-6 to avoid odd 
> arithmetic;? (Throw an exception if out of range)
> 
> LocaleNameProviderImpl.java:
>  ?- 176/186:? Did you want to call super to do the RequiresNonNull 
> checks? Or will the NPEs happen naturally.
> 
> SPILocaleProviderAdapter.java:
> - 578,? 585: assert seems like of useless here;? if null, will NPE; only 
> if asserts are enabled behavior will change to AssertError

Will address those in the next webrev.

Naoto

> 
> (I have not looked at the tests)
> 
> Regards, Roger
> 
> 
> 
> On 11/9/2017 6:34 PM, Naoto Sato wrote:
>> Kindly requesting reviews. I incorporated a fix to the following issue 
>> raised by the test team:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8190918
>>
>> Here is the updated webrev:
>>
>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/
>>
>> And the webrev since the one below (to address 8190918):
>>
>> http://cr.openjdk.java.net/~naoto/8190918/
>>
>> Naoto
>>
>>
>>
>> On 11/2/17 2:42 PM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the proposed changes for the following issues:
>>>
>>> 8176841: Additional Unicode Language-Tag Extensions
>>> 8189134: New system properties for the default Locale extensions
>>>
>>> The proposed changeset is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
>>>
>>> This serves as the implementation of JEP 314.
>>>
>>> Naoto
>>>
>>>
>>>
> 

From naoto.sato at oracle.com  Tue Nov 14 23:49:58 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 14 Nov 2017 15:49:58 -0800
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <FF441B3C-E37D-4C8F-A1F9-A9F3BA335867@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <9d79807d-1b45-4961-7f35-a8335098302c@Oracle.com>
 <FF441B3C-E37D-4C8F-A1F9-A9F3BA335867@oracle.com>
Message-ID: <00f4a60d-05d1-1abd-b8f5-6737473c78d4@oracle.com>

Thanks, Lance.

On 11/14/17 2:34 PM, Lance Andersen wrote:
> Hi Naoto
> 
> DateTimeFormatter.java,?DateTimeFormatterBuilder.java,?WeekFields.java., 
> Calendar.java, Currency.java (and others)
> 
> ??????
> 
> 136 * the chronology and/or the zone are also overriden. If both "ca" 
> and "rg" are
> 137 * specified, the chronology from "ca" extension supersedes the 
> implicit one
> 138 * from "rg" extension.
> 
> ????????
> 
> I would consider changing 137 ?? from the ?ca extension? and ?? from the 
> ?rg? extension"
> 
> 
> I agree wth Rogers suggestion to use @{code} for the new javadoc if at 
> all possible
Will change them.

> 
> The tests look reasonable. ?I was curious why a few of the new tests 
> such as?CalendarDataTest.java are not using TestNG where others are.

For the new tests in the new "bcp47" directory, I used TestNG, for other 
tests in existing directories, I followed the test method in those 
directories. Not from any definitive reason.

Naoto

> 
>> On Nov 14, 2017, at 4:28 PM, Roger Riggs <Roger.Riggs at oracle.com 
>> <mailto:Roger.Riggs at oracle.com>> wrote:
>>
>> Hi Naoto,
>>
>> A few comments, there is lots here to review.
>>
>> tools/cldrconverter/LDMLParseHandler.java:
>> - 948: TODO?
>>
>>
>> DateFormatSymbols.java:
>> ?- 88: "overriden" -> "overridden"
>>
>> DecimalFormatSymbols:
>> ?- 60: "rg" -> "nu"?
>> ?- 62: "overriden" -> "overridden"
>>
>> NumberFormat.java:
>> ?- 106: "a <code>NumberFormat</code>" ->? "{@code NumberFormat}
>>
>> java/time/format/DateTimeFormatter.java:
>> ?- 136, 561, 589, 1463: "overriden" -> "overridden"
>>
>> - 1486: long line, wrap please
>>
>> DateTimeFormatterBuilder.java:
>> - 2168,2194:? - 62: "overriden" -> "overridden"
>>
>> java/util/Calendar.java:
>>
>> 138 * They may also be specified explicitly through the methods for 
>> setting their
>> 139 * values.
>>
>> java/util/spi/LocaleNameProvider.java:
>> ?167, 193: looks a bit odd to return null but maybe that's the default 
>> if not overridden
> 
> Yeah, could you explain when null would not be returned, or is this just 
> stubbed out code for now?
>>
>> It looks like a few misc changes are included too:
>> ?- LauncherHelper:? 271: getDisplayName()...
>>
>>
>> CalendarDataProviderImpl.java:
>> ?- 51, 58:? Should these limit the value to 0-6 to avoid odd 
>> arithmetic;? (Throw an exception if out of range)
>>
>> LocaleNameProviderImpl.java:
>> ?- 176/186:? Did you want to call super to do the RequiresNonNull 
>> checks? Or will the NPEs happen naturally.
>>
>> SPILocaleProviderAdapter.java:
>> - 578,? 585: assert seems like of useless here;? if null, will NPE; 
>> only if asserts are enabled behavior will change to AssertError
>>
>> (I have not looked at the tests)
>>
>> Regards, Roger
>>
>>
>>
>> On 11/9/2017 6:34 PM, Naoto Sato wrote:
>>> Kindly requesting reviews. I incorporated a fix to the following 
>>> issue raised by the test team:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8190918
>>>
>>> Here is the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/
>>>
>>> And the webrev since the one below (to address 8190918):
>>>
>>> http://cr.openjdk.java.net/~naoto/8190918/
>>>
>>> Naoto
>>>
>>>
>>>
>>> On 11/2/17 2:42 PM, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the proposed changes for the following issues:
>>>>
>>>> 8176841: Additional Unicode Language-Tag Extensions
>>>> 8189134: New system properties for the default Locale extensions
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
>>>>
>>>> This serves as the implementation of JEP 314.
>>>>
>>>> Naoto
>>>>
>>>>
>>>>
>>
> 
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| 
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> 
> 
> 

From naoto.sato at oracle.com  Tue Nov 14 23:58:52 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 14 Nov 2017 15:58:52 -0800
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <CACzrW9C+GekWNRdWVi1AhVs_CiPgWksde-6iRT1Z68-RhkziZw@mail.gmail.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <CACzrW9C+GekWNRdWVi1AhVs_CiPgWksde-6iRT1Z68-RhkziZw@mail.gmail.com>
Message-ID: <098fb447-9d89-2d2d-20a8-06b85d128020@oracle.com>

Thanks, Stephen.

On 11/14/17 3:22 PM, Stephen Colebourne wrote:
> I'd missed that this affects java.time.*
> 
> I believe that the changes to DateTimeFormatter are a mistake and will
> cause confusion. Currently, each withXxx() method is independent -
> they do not interact and operate on a single piece of state.
> 
> Currently, these two pieces of code have the same effect:
> 
>   formatter = formatter.withZone(zone).withLocale(locale);
>   formatter = formatter.withLocale(locale).withZone(zone);
> 
> With the webrev, that is no longer true.

OK.

> 
> While I understand the desire of the change, I believe it would be a
> serious mistake and a cause of end-user bugs.
> 
> The best I can suggest is adding a new method withLocalization(Locale)
> or applyLocalization(Locale) or localized(Locale), which is documented
> to replace multiple parts of the state in one go.

So even with the new suggested method,

formatter.withZone(locale).withLocalization(locale)
formatter.withLocalization(locale).withZone(locale)

would produce different formatters. Would it be OK, assuming along with 
some proper documentation?

> 
> 
> There are other oddities.
>   DateTimeFormatterBuilder.getLocalizedDateTimePattern() takes in a
> Chronology, thus the calendar system in the locale is ignored.
> Probably correct, but not called out in the docs.

Will document it.

> 
>   DateTimeFormatterBuilder.toFormatter(Locale, ResolverStyle,
> Chronology) has new logic to override the chronology. But this method
> is used indirectly from ofLocalizedTime() and friends which require
> the output to be ISO chronology. Thus the webrev would break the
> specification of those methods.

Would you suggest not interpreting extensions in this method? I am now 
inclined to just interpret locale extensions in the new suggested method 
for the java.time package.

> 
> TimeZoneNameUtility.convertLDMLShortID() is followed by ZoneId.of()
> which assumes that a full set of time-zones is loaded. But, the ZoneId
> initialization system allows the whole set of time-zones to be
> replaced, making this logic suspect, or at the very least needing
> extra consideration/testing.

Sure.

> 
> I think there is a case for
> CalendarDataUtility.retrieveFirstDayOfWeek() to return DayOfWeek, not
> int, but perhaps that is a separate change.

Agree.

Naoto

> 
> Stephen
> 
> 
> On 9 November 2017 at 23:34, Naoto Sato <naoto.sato at oracle.com> wrote:
>> Kindly requesting reviews. I incorporated a fix to the following issue
>> raised by the test team:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8190918
>>
>> Here is the updated webrev:
>>
>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/
>>
>> And the webrev since the one below (to address 8190918):
>>
>> http://cr.openjdk.java.net/~naoto/8190918/
>>
>> Naoto
>>
>>
>>
>>
>> On 11/2/17 2:42 PM, Naoto Sato wrote:
>>>
>>> Hello,
>>>
>>> Please review the proposed changes for the following issues:
>>>
>>> 8176841: Additional Unicode Language-Tag Extensions
>>> 8189134: New system properties for the default Locale extensions
>>>
>>> The proposed changeset is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
>>>
>>> This serves as the implementation of JEP 314.
>>>
>>> Naoto
>>>
>>>
>>>
>>

From zheng.jun.li at oracle.com  Wed Nov 15 00:05:09 2017
From: zheng.jun.li at oracle.com (Jack Li)
Date: Wed, 15 Nov 2017 08:05:09 +0800
Subject: RFR: 8187954 Update JAX-WS RI integration to latest version
In-Reply-To: <06DBFD86-3710-4211-8C00-087DE4F90C04@oracle.com>
References: <12668CC3-A8DB-4BDC-9F21-5068CA559DA8@oracle.com>
 <DE008EE6-ABC3-455F-85D0-C83239CD4622@oracle.com>
 <A9736FE3-E30D-4EDD-839F-6FFAB6A4BF38@oracle.com>
 <B53D7902-137F-4082-930F-713D427E3CDF@oracle.com>
 <95066DA9-03A6-4BF1-8895-6A442548EC60@oracle.com>
 <50F96A1B-78C3-4FC4-82E5-691E06749F29@oracle.com>
 <A6E211A7-10B2-4242-939E-F6CEB6BFC726@oracle.com>
 <68A33758-0DA4-4B8A-8692-2A382AC63652@oracle.com>
 <BB9DBC59-0733-42FB-9D0A-27B1C06F555C@oracle.com>
 <8CE70301-1DFA-4C5B-B1E8-A557BE68EE08@oracle.com>
 <06DBFD86-3710-4211-8C00-087DE4F90C04@oracle.com>
Message-ID: <70FBA9A5-33CA-4064-AA3E-2F8E2B28A3A8@oracle.com>

Hi Lance

Is there any other issue about it? can you approve it to merge?

> On Nov 6, 2017, at 07:59, ZhengJun Li <zheng.jun.li at oracle.com> wrote:
> 
> 
> Yes, all the tests are passed.
> 
> 
> ? 2017?11?6??05:05?Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> ???
> 
>> Hi Jack,
>> 
>> Overall looks OK.  I am assuming all of the test suites are passing?
>> 
>> Best
>> Lance
>>> On Nov 2, 2017, at 7:34 AM, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>>> 
>>> Hi Jack
>>> 
>>> Its on my list to finish by the end of the week. 
>>> 
>>> Best
>>> Lance
>>>> On Nov 2, 2017, at 4:34 AM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>> 
>>>> Hi Lance
>>>> 
>>>> Is there anything wrong in the new webrev?
>>>> 
>>>> 
>>>>> On Oct 25, 2017, at 10:00, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com> <mailto:zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>>> wrote:
>>>>> 
>>>>> Hi Lance,
>>>>> 
>>>>> The webrev is updated, can you please review it again?
>>>>> 
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>> 
>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01 <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01 <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01>>
>>>>> 
>>>>> Summary of changes:
>>>>> 
>>>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>>>> 
>>>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>>>> 
>>>>> 
>>>>> Patch also contains several small bugfixes, not tracked in JBS.
>>>>> 
>>>>>> On Oct 11, 2017, at 18:47, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com> <mailto:lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>>> wrote:
>>>>>> 
>>>>>> Hi Jack,
>>>>>> 
>>>>>> I would prefer to see an updated webrev so that we do not inadvertently
>>>>>> push these changes.
>>>>>> 
>>>>>> Best
>>>>>> Lance
>>>>>>> On Oct 11, 2017, at 3:26 AM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com> <mailto:zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>>> wrote:
>>>>>>> 
>>>>>>> Hi Lance
>>>>>>> 
>>>>>>> I will update them in Metro repository, do I need to regenerate webrev?
>>>>>>> or can you skip the files this time and I fix it in next integration?
>>>>>>> 
>>>>>>>> On Oct 9, 2017, at 19:35, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com> <mailto:lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>>> wrote:
>>>>>>>> 
>>>>>>>> Hi Jack,
>>>>>>>> 
>>>>>>>> UnMarshaller also has the same issue.  I would update the webrev given the number of places to help sanity check for omissions
>>>>>>>> 
>>>>>>>> Best
>>>>>>>> Lance
>>>>>>>>> On Oct 8, 2017, at 9:22 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com> <mailto:zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Lance,
>>>>>>>>> 
>>>>>>>>> the change is incorrect, it should be ?javax/xml/bind?.
>>>>>>>>> thanks a lot for your finding, do you think I need to fix it and resubmit the webrev this time?
>>>>>>>>> or can you skip this file this time and I fix it in next integration?
>>>>>>>>> 
>>>>>>>>>> On Oct 4, 2017, at 02:09, Lance Andersen <Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Jack,
>>>>>>>>>> 
>>>>>>>>>> Is this change correct:
>>>>>>>>>> 
>>>>>>>>>> -------------
>>>>>>>>>> --- old/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.968185273 +0100
>>>>>>>>>> +++ new/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.676185267 +0100
>>>>>>>>>> @@ -373,7 +373,7 @@
>>>>>>>>>>      *      If the {@link ValidationEventHandler ValidationEventHandler}
>>>>>>>>>>      *      returns false from its {@code handleEvent} method or the
>>>>>>>>>>      *      {@code Marshaller} is unable to marshal {@code jaxbElement} (or any
>>>>>>>>>> -     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/javax/xml/bind/Marshaller.html#elementMarshalling">
>>>>>>>>>> +     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/java/xml/bind/Marshaller.html#elementMarshalling">
>>>>>>>>>>      *      Marshalling a JAXB element</a>.
>>>>>>>>>> 
>>>>>>>>>> ------------
>>>>>>>>>> 
>>>>>>>>>> The URL that is being changed currently works
>>>>>>>>>> 
>>>>>>>>>> Best
>>>>>>>>>> Lance
>>>>>>>>>> On Sep 29, 2017, at 10:55 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com> <mailto:zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>>>>>>>>> 
>>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>>>
>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>>>
>>>>>>>>>>> 
>>>>>>>>>>> Summary of changes:
>>>>>>>>>>> 
>>>>>>>>>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>>>>>>>>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>>>>>>>>>> 
>>>>>>>>>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>>>>>>>>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>>>>>>>>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Patch also contains several small bugfixes, not tracked in JBS.
>>>>>>>>>>> 
>>>>>>>>>>> ----------------
>>>>>>>>>>> Best regards
>>>>>>>>>>> Jack Li
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> <oracle_sig_logo.gif>
>>>>>>>>>> 
>>>>>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>>>>> Oracle Java Engineering 
>>>>>>>>>> 1 Network Drive 
>>>>>>>>>> Burlington, MA 01803
>>>>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
>>>>>>>>> 
>>>>>>>>> ----------------
>>>>>>>>> Best regards
>>>>>>>>> Jack Li
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>>> Oracle Java Engineering 
>>>>>>>> 1 Network Drive 
>>>>>>>> Burlington, MA 01803
>>>>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ----------------
>>>>>>> Best regards
>>>>>>> Jack Li
>>>>>> 
>>>>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>> Oracle Java Engineering 
>>>>>> 1 Network Drive 
>>>>>> Burlington, MA 01803
>>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> ----------------
>>>>> Best regards
>>>>> Jack Li
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> ----------------
>>>> Best regards
>>>> Jack Li
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering 
>>> 1 Network Drive 
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
>>> 
>>> 
>>> 
>> 
>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>> 
>> 
>> 


----------------
Best regards
Jack Li







From paul.sandoz at oracle.com  Wed Nov 15 00:34:13 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 14 Nov 2017 16:34:13 -0800
Subject: RFR 8190974 Parallel stream execution within a custom
 ForkJoinPool should obey the parallelism
In-Reply-To: <CAPkkuSegTQeWus9ju+9T5iKg83metWX9-mvDUnoZtJNs03w+-w@mail.gmail.com>
References: <CFFC012D-28A8-4CEB-853E-ACE60041C4FA@oracle.com>
 <CAPkkuSegTQeWus9ju+9T5iKg83metWX9-mvDUnoZtJNs03w+-w@mail.gmail.com>
Message-ID: <BF654F78-FA6F-48EE-920F-9FBF9FD17C95@oracle.com>



> On 11 Nov 2017, at 07:58, Stefan Zobel <spliterator at gmail.com> wrote:
> 
> In CustomFJPoolTest#testCustomPools()
> 
>>>   assertEquals(splitsForPC, splitsForPHalfC * 2);
> 
> 
> I'm sure I'm slow on the uptake, but isn't this bound to
> fail for every commonParallelism == 2^n + 1 in the closed
> range [2, 127], i.e., for 3, 5, 9, 17, 33, 65?
> 

Ooops! yes, thanks for catching that.

I updated the test to do this:

  assertTrue(splitsForPHalfC < splitsForPC);
  assertEquals(splitsForPC / splitsForPHalfC,
               nearestPowerOfTwo(commonParallelism) / nearestPowerOfTwo(commonParallelism / 2));

http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-pool/webrev/test/jdk/java/util/stream/CustomFJPoolTest.java.html

Paul.

From scolebourne at joda.org  Wed Nov 15 00:44:50 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 15 Nov 2017 00:44:50 +0000
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <098fb447-9d89-2d2d-20a8-06b85d128020@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <CACzrW9C+GekWNRdWVi1AhVs_CiPgWksde-6iRT1Z68-RhkziZw@mail.gmail.com>
 <098fb447-9d89-2d2d-20a8-06b85d128020@oracle.com>
Message-ID: <CACzrW9CbB9TOto1UgNmiFfN7pB8D7gKVQBb89t1x_J20NoGpMg@mail.gmail.com>

On 14 November 2017 at 23:58, Naoto Sato <naoto.sato at oracle.com> wrote:
> So even with the new suggested method,
>
> formatter.withZone(locale).withLocalization(locale)
> formatter.withLocalization(locale).withZone(locale)
>
> would produce different formatters. Would it be OK, assuming along with some
> proper documentation?

Thats why I suggested perhaps a different method name is needed, not
withXxx() to highlight the larger impact. eg. localizedBy(Locale)

>>   DateTimeFormatterBuilder.toFormatter(Locale, ResolverStyle,
>> Chronology) has new logic to override the chronology. But this method
>> is used indirectly from ofLocalizedTime() and friends which require
>> the output to be ISO chronology. Thus the webrev would break the
>> specification of those methods.
>
> Would you suggest not interpreting extensions in this method? I am now
> inclined to just interpret locale extensions in the new suggested method for
> the java.time package.

Fundamentally, the tags you are processing are a problem for the
design of java.time formatters. The existing API is structured around
a narrow meaning of Locale for text input/output within the formatting
API.

Changing the behaviour of DateTimeFormatterBuilder.toFormatter(...)
methods could have some odd effects for end-user code. Where they are
currently just expecting the locale to be set to control text
input/output, it would suddenly affect the calendar system and
time-zone, which could break code/compatibility in certain cases.

I think that its OK to use the unicode tags in places like
WeekFields.of() or Chronology.of(). But for formatting, the change in
meaning is too great. Adding a single method (name TBD) makes more
sense.

There is a case to add ZoneId.ofLocale(Locale) to match
Chronology.ofLocale(Locale). However, the expectation would be that it
figures out a suitable time-zone for the country/region as well as
considering the -u-tz- tag, and I don't think you've got that data
available at present (but it would make a good follow on change).

Stephen

From paul.sandoz at oracle.com  Wed Nov 15 00:49:45 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 14 Nov 2017 16:49:45 -0800
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <e9dad599-2e49-d66d-4236-59191a52320b@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com>
 <26336F4F-0A21-4A08-AFA3-23CA972CAD93@oracle.com>
 <e9dad599-2e49-d66d-4236-59191a52320b@oracle.com>
Message-ID: <130F7E94-9408-4C49-9C23-840361B4B379@oracle.com>



> On 10 Nov 2017, at 01:36, stanislav lukyanov <stanislav.lukyanov at oracle.com> wrote:
> 
> On 10.11.2017 0:13, Paul Sandoz wrote:
>> <...>
>> I would prefer to follow up later on with more non-normative explanatory text. It will take some careful crafting and i don?t want that to side-track the review for the moment (including guidance on what forms of computed constants are acceptable).
> Fair. Does it make sense to add a sub-task for this to JDK-8185992 to keep it on the radar?

You would mind adding a sub-task with a tbd minor target?


>> <...>
>> 
>> And adjusted the invoke method:
>> 
>> * @param args the arguments to pass to the method handle, as if with
>> * {@link MethodHandle#invokeWithArguments}.  Each argument may be
>> * {@code null}.
>> ...
>> * @throws NullPointerException if {@code args} is {@code null}
>> * (each argument of {@code args} may be {@code null}).
> I think the `@throws NPE` is not needed, at least not from the normative perspective.
> The class-level text about NPE doesn't assume anything about the contents of objects passed to the methods,
> and the second part of the `@param args` already clarifies the behavior for this particular case.
> Arguably having this `@throws` might improve clarity, but I would rather remove it.

Ok, if you are fine with that i will remove it.


>> 
>> We have been fleshing out the NPE behaviour because we know you will log bugs against us later on if we don?t :-)
> Yep, that's sounds familiar :)
> 
> <...>
> 
> Thanks for the updates!
> 
> Also, javac isn't going to use `::primitiveClass` instead of `getstatic Integer.TYPE` to load int.class, right?
> If it is, int.class probably needs to be changed to Integer.TYPE in sun.invoke.util.Wrapper to avoid cycles.
> 

Yes, i noticed that too :-)

There are no plans in this patch to update javac code generation for primitive classes but if we do we may need to modify the wrapper implementation as you point out. There are might other areas within the base module (specifically in j.l.invoke) where referring to say int.class may cause class initialization issues early in the startup. That?s awkward (just like we cannot use lambda expressions in certain cases), we might need to retain the old translation strategy just for code within the base module or support a compilation error.

Paul.

From mandy.chung at oracle.com  Wed Nov 15 03:34:45 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 14 Nov 2017 21:34:45 -0600
Subject: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only
 the permissions it really needs to expose the bean
In-Reply-To: <715d933a-a747-8aac-620b-fba12f4236e0@oracle.com>
References: <2138013.zvGs44vPXg@pracovni>
 <610c8d9d-9b01-d874-8794-1b99fc8a150e@oracle.com>
 <10208568.Zsd4Z32fDf@pracovni> <2454131.31SKLb3dS1@pracovni>
 <715d933a-a747-8aac-620b-fba12f4236e0@oracle.com>
Message-ID: <7b03728a-a3ad-e392-db1b-dd0807e1ffeb@oracle.com>

I am wondering this ACE comes from Graal accessing jdk.vm.ci.services 
from JVMCI which is defined to the boot loader versus Graal is defined 
to the platform class loader.

 ?java.security.AccessControlException: access denied
("java.lang.RuntimePermission" "accessClassInPackage.jdk.vm.ci.services")

However Graal grants with AllPermissions.

In any case, if this is an existing issue, I am okay if you file a 
separate issue to track this.

Mandy

On 11/14/17 2:02 PM, Sean Mullan wrote:
> Try running with -Djava.security.debug=access:domain:failure
>
> This will tell you what ProtectionDomain caused the 
> AccessControlException, which should give you a better idea of where 
> the problem is. Look for messages that start with "domain that failed ".
>
> --Sean
>
>
> On 11/14/17 1:22 AM, Jaroslav Tulach wrote:
>> I tried the same test with
>>
>> changeset:?? 47679:d85284ccd1bd
>> user:??????? sspitsyn
>> date:??????? Fri Nov 03 17:09:25 2017 -0700
>> summary:???? 8189731: Disable CFLH when there are no transformers
>>
>> and it also yields the exception. E.g. the problem is certainly not 
>> result of
>> my changes.
>>
>> -jt
>>
>> PS: I try full rebuild on d85284ccd1bd maybe it disappears...
>>
>>
>> On pond?l? 13. listopadu 2017 20:53:35 CET Jaroslav Tulach wrote:
>>> Hello Mandy,
>>>
>>> this was a good test:
>>>>> ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
>>>>> +EnableJVMCI -XX:+UseJVMCICompiler -jar ...
>>>>
>>>> You can also try running the above command with 
>>>> -Djava.security.manager
>>>> as a sanity test (the application may need additional permissions) -
>>>> just a sanity test.
>>>
>>> I've just tried:
>>>
>>> $ ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
>>> +EnableJVMCI -XX:+UseJVMCICompiler -Djava.security.manager -jar ~/
>>> NetBeansProjects/sieve/java/algorithm/target/sieve-algorithm-1.0-SNAPSHOT.ja 
>>>
>>> r
>>>
>>> and it doesn't work. I am getting an error below, however the code 
>>> is not
>>> running through my module at all. I don't understand the failure, I 
>>> will
>>> have to investigate more.
>>>
>>> -jt
>>>
>>>
>>> Caused by: java.security.AccessControlException: access denied
>>> ("java.lang.RuntimePermission" 
>>> "accessClassInPackage.jdk.vm.ci.services")
>>> ???????? at java.base/
>>> java.security.AccessControlContext.checkPermission(AccessControlContext.java 
>>>
>>> : 472)
>>> ???????? at java.base/
>>> java.security.AccessController.checkPermission(AccessController.java:895) 
>>>
>>> ???????? at java.base/
>>> java.lang.SecurityManager.checkPermission(SecurityManager.java:558)
>>> ???????? at java.base/
>>> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1534)
>>> ???????? at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:680)
>>> ???????? at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:678)
>>> ???????? at 
>>> java.base/java.security.AccessController.doPrivileged(Native
>>> Method)
>>> ???????? at java.base/
>>> java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:678)
>>> ???????? at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>>> ???????? at
>>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1006) at
>>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1085) at
>>> java.base/
>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:206)
>>> ???????? at java.base/
>>> jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:7 
>>>
>>> 60) at java.base/jdk.internal.loader.BuiltinClassLoader.lambda
>>> $findClassInModuleOrNull$2(BuiltinClassLoader.java:683)
>>> ???????? at 
>>> java.base/java.security.AccessController.doPrivileged(Native
>>> Method)
>>> ???????? at java.base/
>>> jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassL 
>>>
>>> oader.java: 684)
>>> ???????? at java.base/
>>> jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:562 
>>>
>>> ) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:607) at
>>> java.base/java.lang.Class.forName(Class.java:451)
>>> ???????? at java.base/java.util.ServiceLoader.lambda$loadProvider
>>> $1(ServiceLoader.java:856)
>>> ???????? at 
>>> java.base/java.security.AccessController.doPrivileged(Native
>>> Method)
>>> ???????? at
>>> java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java: 858)
>>
>>


From amaembo at gmail.com  Wed Nov 15 03:52:27 2017
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 15 Nov 2017 10:52:27 +0700
Subject: Collections.emptyList().sort() does nothing
Message-ID: <CAE+3fjYhx1jwTyudEM3sEed9qtNap0-2xppvJ-b9AWZWJyamNw@mail.gmail.com>

Hello!

According to `List.sort` specification [1] "This list must be modifiable".
According to `Collections.emptyList` specification [2] "Returns an
empty list (immutable)."

So I assume that `List.sort` cannot be called on
`Collections.emptyList` result. However in fact this call is allowed
doing nothing. Is this behavior documented somehow? Can I rely that it
will not change in future Java updates?

It's even more strange with `Collections.singletonList` [3] which
"Returns an immutable list containing only the specified object".
Obviously I cannot do:

List<String> list = Collections.singletonList("foo");
ListIterator<String> it = list.listIterator();
it.next();
it.set("bar"); // UOE

However list.sort(null) works perfectly. On the other hand [1] clearly says:

Throws: UnsupportedOperationException - if the list's list-iterator
does not support the set operation.

To me it seems that emptyList and (especially) singletonList
implementation does not follow the specification. Am I missing
something?

With best regards,
Tagir Valeev.

[1] https://docs.oracle.com/javase/9/docs/api/java/util/List.html#sort-java.util.Comparator-
[2] https://docs.oracle.com/javase/9/docs/api/java/util/Collections.html#emptyList--
[3] https://docs.oracle.com/javase/9/docs/api/java/util/Collections.html#singletonList-T-

From martinrb at google.com  Wed Nov 15 04:10:06 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 14 Nov 2017 20:10:06 -0800
Subject: Collections.emptyList().sort() does nothing
In-Reply-To: <CAE+3fjYhx1jwTyudEM3sEed9qtNap0-2xppvJ-b9AWZWJyamNw@mail.gmail.com>
References: <CAE+3fjYhx1jwTyudEM3sEed9qtNap0-2xppvJ-b9AWZWJyamNw@mail.gmail.com>
Message-ID: <CA+kOe0-xNkVgw0t2BFPLG3_xUg4+qV7qaqz0k_9oOOsws47N9Q@mail.gmail.com>

Different maintainers of the core library differed on whether it's
important to pedantically check for such corner case mistakes.  Recently
the trend has been to check for all errors up front, even if it ends up
making no difference.  Users should not depend on the library implementer's
mood or vigilance, unless they're professional testers.

On Tue, Nov 14, 2017 at 7:52 PM, Tagir Valeev <amaembo at gmail.com> wrote:

> Hello!
>
> According to `List.sort` specification [1] "This list must be modifiable".
> According to `Collections.emptyList` specification [2] "Returns an
> empty list (immutable)."
>
> So I assume that `List.sort` cannot be called on
> `Collections.emptyList` result. However in fact this call is allowed
> doing nothing. Is this behavior documented somehow? Can I rely that it
> will not change in future Java updates?
>
> It's even more strange with `Collections.singletonList` [3] which
> "Returns an immutable list containing only the specified object".
> Obviously I cannot do:
>
> List<String> list = Collections.singletonList("foo");
> ListIterator<String> it = list.listIterator();
> it.next();
> it.set("bar"); // UOE
>
> However list.sort(null) works perfectly. On the other hand [1] clearly
> says:
>
> Throws: UnsupportedOperationException - if the list's list-iterator
> does not support the set operation.
>
> To me it seems that emptyList and (especially) singletonList
> implementation does not follow the specification. Am I missing
> something?
>
> With best regards,
> Tagir Valeev.
>
> [1] https://docs.oracle.com/javase/9/docs/api/java/util/
> List.html#sort-java.util.Comparator-
> [2] https://docs.oracle.com/javase/9/docs/api/java/util/
> Collections.html#emptyList--
> [3] https://docs.oracle.com/javase/9/docs/api/java/util/Collections.html#
> singletonList-T-
>

From stanislav.lukyanov at oracle.com  Wed Nov 15 04:48:53 2017
From: stanislav.lukyanov at oracle.com (stanislav lukyanov)
Date: Wed, 15 Nov 2017 10:18:53 +0530
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <130F7E94-9408-4C49-9C23-840361B4B379@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com>
 <26336F4F-0A21-4A08-AFA3-23CA972CAD93@oracle.com>
 <e9dad599-2e49-d66d-4236-59191a52320b@oracle.com>
 <130F7E94-9408-4C49-9C23-840361B4B379@oracle.com>
Message-ID: <ad4ecc92-6c33-1ab3-1608-e0fa4f6ebf4f@oracle.com>

On 15.11.2017 6:19, Paul Sandoz wrote:
>> On 10 Nov 2017, at 01:36, stanislav lukyanov <stanislav.lukyanov at oracle.com> wrote:
>>
>> On 10.11.2017 0:13, Paul Sandoz wrote:
>>> <...>
>>> I would prefer to follow up later on with more non-normative explanatory text. It will take some careful crafting and i don?t want that to side-track the review for the moment (including guidance on what forms of computed constants are acceptable).
>> Fair. Does it make sense to add a sub-task for this to JDK-8185992 to keep it on the radar?
> You would mind adding a sub-task with a tbd minor target?
TBD_Minor would mean an update release, right?
I think it can't be a TBD_Minor then since it is technically a 
specification change and should happen in a Java SE release (maybe 11?), 
but maybe I'm wrong.
Anyway, as long as that's logged and not completely forgotten, I'm happy :)

Thanks,
Stas
>
>
>>> <...>
>>>
>>> And adjusted the invoke method:
>>>
>>> * @param args the arguments to pass to the method handle, as if with
>>> * {@link MethodHandle#invokeWithArguments}.  Each argument may be
>>> * {@code null}.
>>> ...
>>> * @throws NullPointerException if {@code args} is {@code null}
>>> * (each argument of {@code args} may be {@code null}).
>> I think the `@throws NPE` is not needed, at least not from the normative perspective.
>> The class-level text about NPE doesn't assume anything about the contents of objects passed to the methods,
>> and the second part of the `@param args` already clarifies the behavior for this particular case.
>> Arguably having this `@throws` might improve clarity, but I would rather remove it.
> Ok, if you are fine with that i will remove it.
>
>
>>> We have been fleshing out the NPE behaviour because we know you will log bugs against us later on if we don?t :-)
>> Yep, that's sounds familiar :)
>>
>> <...>
>>
>> Thanks for the updates!
>>
>> Also, javac isn't going to use `::primitiveClass` instead of `getstatic Integer.TYPE` to load int.class, right?
>> If it is, int.class probably needs to be changed to Integer.TYPE in sun.invoke.util.Wrapper to avoid cycles.
>>
> Yes, i noticed that too :-)
>
> There are no plans in this patch to update javac code generation for primitive classes but if we do we may need to modify the wrapper implementation as you point out. There are might other areas within the base module (specifically in j.l.invoke) where referring to say int.class may cause class initialization issues early in the startup. That?s awkward (just like we cannot use lambda expressions in certain cases), we might need to retain the old translation strategy just for code within the base module or support a compilation error.
>
> Paul.


From ecki at zusammenkunft.net  Wed Nov 15 06:04:45 2017
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 15 Nov 2017 06:04:45 +0000
Subject: Collections.emptyList().sort() does nothing
In-Reply-To: <CA+kOe0-xNkVgw0t2BFPLG3_xUg4+qV7qaqz0k_9oOOsws47N9Q@mail.gmail.com>
References: <CAE+3fjYhx1jwTyudEM3sEed9qtNap0-2xppvJ-b9AWZWJyamNw@mail.gmail.com>,
 <CA+kOe0-xNkVgw0t2BFPLG3_xUg4+qV7qaqz0k_9oOOsws47N9Q@mail.gmail.com>
Message-ID: <AM4PR08MB121989D338005EEF06C55628FF290@AM4PR08MB1219.eurprd08.prod.outlook.com>

I would however vote for allowing an empty list to be sorted. This is such a common case to return a replacement empty list that it will not only introduce changed behavior but also forces ugly code.

For singleton list I can kind of understand that you want to fail early, but it could be made the same argument as for the empty case.

In the end, if we allow one or both, it requires to be spelled out explicitely (unfortunately a spec change, even when it is the more likely usage already)

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Martin Buchholz <martinrb at google.com>
Sent: Wednesday, November 15, 2017 5:10:06 AM
To: Tagir Valeev
Cc: core-libs-dev
Subject: Re: Collections.emptyList().sort() does nothing

Different maintainers of the core library differed on whether it's
important to pedantically check for such corner case mistakes.  Recently
the trend has been to check for all errors up front, even if it ends up
making no difference.  Users should not depend on the library implementer's
mood or vigilance, unless they're professional testers.

On Tue, Nov 14, 2017 at 7:52 PM, Tagir Valeev <amaembo at gmail.com> wrote:

> Hello!
>
> According to `List.sort` specification [1] "This list must be modifiable".
> According to `Collections.emptyList` specification [2] "Returns an
> empty list (immutable)."
>
> So I assume that `List.sort` cannot be called on
> `Collections.emptyList` result. However in fact this call is allowed
> doing nothing. Is this behavior documented somehow? Can I rely that it
> will not change in future Java updates?
>
> It's even more strange with `Collections.singletonList` [3] which
> "Returns an immutable list containing only the specified object".
> Obviously I cannot do:
>
> List<String> list = Collections.singletonList("foo");
> ListIterator<String> it = list.listIterator();
> it.next();
> it.set("bar"); // UOE
>
> However list.sort(null) works perfectly. On the other hand [1] clearly
> says:
>
> Throws: UnsupportedOperationException - if the list's list-iterator
> does not support the set operation.
>
> To me it seems that emptyList and (especially) singletonList
> implementation does not follow the specification. Am I missing
> something?
>
> With best regards,
> Tagir Valeev.
>
> [1] https://docs.oracle.com/javase/9/docs/api/java/util/
> List.html#sort-java.util.Comparator-
> [2] https://docs.oracle.com/javase/9/docs/api/java/util/
> Collections.html#emptyList--
> [3] https://docs.oracle.com/javase/9/docs/api/java/util/Collections.html#
> singletonList-T-
>

From peter.levart at gmail.com  Wed Nov 15 10:02:20 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 15 Nov 2017 11:02:20 +0100
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <352f9bb5-77b6-af47-dad2-95ebf1ba7660@oracle.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <798167c6-c562-f247-b77b-b6da38bcce9e@oracle.com>
 <8d9b27b8-816c-3fbe-cff0-a17e5d0d7918@gmail.com>
 <352f9bb5-77b6-af47-dad2-95ebf1ba7660@oracle.com>
Message-ID: <0ee8d2f8-4d3b-2c98-8d5a-d291d45edd95@gmail.com>

Hi David,

On 11/14/2017 10:28 PM, David Holmes wrote:
> Hi Peter,
>
> On 15/11/2017 1:02 AM, Peter Levart wrote:
>> Hi David,
>>
>> On 11/11/2017 07:51 AM, David Holmes wrote:
>>> AFAICS SimpleTimeZone is simply not thread-safe. It has state that 
>>> can be modified concurrently without synchronization and with fields 
>>> not even declared volatile. Only the "cache" makes an attempt to use 
>>> synchronization. So clone() is never guaranteed to actually produce 
>>> a copy with valid/consistent field values.
>>>
>>> The suggested patch certainly improves the situation by at least 
>>> resetting the cache of the cloned instance before returning it.
>>
>> The instance of SimpleTimeZone that is shared among threads 
>> (internally in JDK) is the defaultTimeZone instance (obtained through 
>> package-private TimeZone.getDefaultRef() method). I checked the 
>> usages and they seem to be "read-only" - not modifying the instance, 
>> just obtaining information from it. The cache OTOH, as you say, is 
>> synchronized.
>
> The initial problem statement was:
>
> "When a thread is cloning a default timezone object (SimpleTimeZone) 
> and at the same time if a different thread modifies the time/year 
> values, ..."
>
> so that doesn't seem to be read-only. Though perhaps it is a very 
> specific race.

User code may do that with its own instances, but that would be invalid 
usage. There is no evidence (at least I haven't spotted it yet) that JDK 
code does the same too. As far as I have checked, internal JDK code is 
aware of the fact that defaultTimeZone instance is a shared instance. 
For example, take a protected java.util.Calendar no-arg constructor. It 
initializes the Calendar instance with the result of 
TimeZone.getDefaultRef() which returns a shared instance. But it also 
sets Calendar's 'sharedZone' flag, marking that the TimeZone instance it 
references is a shared instance. Methods that would expose such instance 
to user code are careful not to do that. For example:

 ??? public TimeZone getTimeZone()
 ??? {
 ??????? // If the TimeZone object is shared by other Calendar 
instances, then
 ??????? // create a clone.
 ??????? if (sharedZone) {
 ??????????? zone = (TimeZone) zone.clone();
 ??????????? sharedZone = false;
 ??????? }
 ??????? return zone;
 ??? }

(BTW, this method may expose shared instance to user code if it is 
invoked concurrently from multiple threads on the same Calendar instance 
- there's no attempt to prevent writes to zone and sharedZone fields to 
be observed in non-program order by some concurrent thread)

So I believe the situation is not so critical as it seemed at first. 
There may be other concurrency bugs like in above getTimeZone() method 
lurking, but the real problem here is cache* fields that may be modified 
while using "read-only" part of API. All such accesses are synchronized, 
except in the Object.clone() which reads them without holding the lock.

>
>> TimeZone and subclasses seem to be designed to be modified by single 
>> thread only, but can be used from multiple threads to read the 
>> information from them, including lazily computed and cached 
>> information. Usage withing JDK seems to comply with that.
>
> There's certainly no documentation of any such intent, or design. 
> Seems more like the synchronization has been added (or not) based on 
> how it is used within JDK rather than considering the actual API of 
> the public types.

Mercurial history does not go that far in the past to be able to see if 
synchronization for cache* fields was added at some point and why. My 
conclusions are based solely on the state of current code.

Regards, Peter

>
>>
>> Venkat's patch therefore correctly fixes the remaining issue that is 
>
> Okay. As I said it certainly makes things better.
>
> Cheers,
> David
>
>> observed when the shared SimpleTimeZone instance is being cloned 
>> while also being accessed from multiple threads in read-only mode. 
>> Invalidating cache of the cloned instance just before returning it 
>> from clone() method means that instance obtained from 
>> TimeZone.getDefault() will never get cached state from original 
>> instance and will always have to re-compute it, but I think this is 
>> still better than synchronizing on the original instance which may 
>> never be optimized away (i.e. elided) by JIT.
>>
>> Regards, Peter
>>
>>>
>>> David
>>>
>>> On 11/11/2017 3:53 PM, Venkateswara R Chintala wrote:
>>>> Thanks Sean. I am pasting the patch here:
>>>>
>>>> --- old/src/java.base/share/classes/java/util/SimpleTimeZone.java 
>>>> 2017-11-11 11:17:38.643867420 +0530
>>>> +++ new/src/java.base/share/classes/java/util/SimpleTimeZone.java 
>>>> 2017-11-11 11:17:38.375870421 +0530
>>>> @@ -868,7 +868,11 @@
>>>> ?????? */
>>>> ????? public Object clone()
>>>> ????? {
>>>> -??????? return super.clone();
>>>> +??????? // Invalidate the time zone cache while cloning as it
>>>> +??????? // can be inconsistent due to race condition.
>>>> +??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>>> +??????? tz.invalidateCache();
>>>> +??????? return tz;
>>>> ????? }
>>>>
>>>> ????? /**
>>>> --- /dev/null??? 2017-11-02 17:09:59.155627814 +0530
>>>> +++ new/test/java/util/TimeZone/SimpleTimeZoneTest.java 2017-11-11 
>>>> 11:17:38.867864912 +0530
>>>> @@ -0,0 +1,55 @@
>>>> +/*
>>>> + * @test
>>>> + * @summary Tests the race condition between 
>>>> java.util.TimeZone.getDefault() and java.util.GregorianCalendar()
>>>> + * @run main SimpleTimeZoneTest
>>>> +*/
>>>> +
>>>> +import java.util.Calendar;
>>>> +import java.util.GregorianCalendar;
>>>> +import java.util.SimpleTimeZone;
>>>> +import java.util.TimeZone;
>>>> +
>>>> +public class SimpleTimeZoneTest extends Thread {
>>>> +??? Calendar cal;
>>>> +
>>>> +??? public SimpleTimeZoneTest (Calendar cal) {
>>>> +??????? this.cal = cal;
>>>> +??? }
>>>> +
>>>> +??? public static void main (String[] args) {
>>>> +??????? TimeZone stz = new SimpleTimeZone(7200000, 
>>>> "Asia/Jerusalem", Calendar.MARCH, 27, 0, 3600000, 
>>>> Calendar.SEPTEMBER, 16, 0, 3600000);
>>>> +??????? TimeZone.setDefault(stz);
>>>> +
>>>> +??????? SimpleTimeZoneTest stt = new SimpleTimeZoneTest(new 
>>>> GregorianCalendar());
>>>> +??????? stt.setDaemon(true);
>>>> +??????? stt.start();
>>>> +
>>>> +??????? for (int i = 0; i < 50000; i++) {
>>>> +??????????? Calendar cal = new GregorianCalendar();
>>>> +??????????? cal.clear();
>>>> +??????????? cal.getTimeInMillis();
>>>> +??????????? cal.set(2014, 2, 2);
>>>> +??????????? cal.clear();
>>>> +??????????? cal.getTimeInMillis();
>>>> +??????????? cal.set(1970, 2, 2);
>>>> +??????? }
>>>> +
>>>> +??? }
>>>> +
>>>> +??? public void run() {
>>>> +??????? while (true) {
>>>> +??????????? cal.setTimeZone(TimeZone.getDefault());
>>>> +??????????? cal.clear();
>>>> +??????????? cal.set(2008, 9, 9);
>>>> +??????????? Calendar calInst = java.util.Calendar.getInstance();
>>>> +??????????? calInst.setTimeInMillis(cal.getTimeInMillis());
>>>> +
>>>> +??????????? if (calInst.get(java.util.Calendar.HOUR_OF_DAY) != 
>>>> cal.get(java.util.Calendar.HOUR_OF_DAY) ||
>>>> +??????????????? calInst.get(java.util.Calendar.MINUTE) != 
>>>> cal.get(java.util.Calendar.MINUTE) ||
>>>> +??????????????? calInst.get(java.util.Calendar.SECOND) != 
>>>> cal.get(java.util.Calendar.SECOND) ||
>>>> +??????????????? calInst.get(java.util.Calendar.MILLISECOND) != 
>>>> cal.get(java.util.Calendar.MILLISECOND)) {
>>>> +??????????????????? throw new RuntimeException("Test failed");
>>>> +??????????? }
>>>> +??????? }
>>>> +??? }
>>>> +}
>>>>
>>>>
>>>> On 10/11/17 9:29 PM, Se?n Coffey wrote:
>>>>> I think the OpenJDK mailing lists accept attachments if in patch 
>>>>> format. If it's a simple short patch, it's acceptable to paste it 
>>>>> into email body.
>>>>>
>>>>> Easiest solution is to use webrev[1]. If you can't upload this to 
>>>>> cr.openjdk.java.net - then one of your colleagues may be able to 
>>>>> help.
>>>>>
>>>>> [1] http://openjdk.java.net/guide/webrevHelp.html
>>>>>
>>>>> Regards,
>>>>> Sean.
>>>>>
>>>>> On 10/11/17 12:18, Venkateswara R Chintala wrote:
>>>>>> Looks like the patch attached earlier is not visible. As this is 
>>>>>> my first contribution, please let me know how I can send the 
>>>>>> patch for review.
>>>>>>
>>>>>>
>>>>>> On 10/11/17 5:37 PM, Venkateswara R Chintala wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> In a multi-threaded environment, when java.util.SimpleTimeZone 
>>>>>>> object is used to create a default timezone, there can be a race 
>>>>>>> condition between the methods java.util.Timezone.getDefault() 
>>>>>>> and java.util.Timezone.getDefaultRef() which can result in 
>>>>>>> inconsistency of cache that is used to validate a particular 
>>>>>>> time/date in DST.
>>>>>>>
>>>>>>> When a thread is cloning a default timezone object 
>>>>>>> (SimpleTimeZone) and at the same time if a different thread 
>>>>>>> modifies the time/year values, then the cache values (cacheYear, 
>>>>>>> cacheStart, cacheEnd) can become inconsistent which leads to 
>>>>>>> incorrect DST determination.
>>>>>>>
>>>>>>> We considered two approaches to fix the issue.
>>>>>>>
>>>>>>> 1)Synchronize access to cloning default timezone object when 
>>>>>>> cache is being modified.
>>>>>>>
>>>>>>> 2)Invalidate the cache while returning the clone.
>>>>>>>
>>>>>>> We preferred the second option as synchronization is more 
>>>>>>> expensive.
>>>>>>>
>>>>>>> We have attached the patch and jtreg testcase. Please review.
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>


From andrej.golovnin at gmail.com  Wed Nov 15 10:03:14 2017
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Wed, 15 Nov 2017 11:03:14 +0100
Subject: Collections.emptyList().sort() does nothing
In-Reply-To: <AM4PR08MB121989D338005EEF06C55628FF290@AM4PR08MB1219.eurprd08.prod.outlook.com>
References: <CAE+3fjYhx1jwTyudEM3sEed9qtNap0-2xppvJ-b9AWZWJyamNw@mail.gmail.com>
 <CA+kOe0-xNkVgw0t2BFPLG3_xUg4+qV7qaqz0k_9oOOsws47N9Q@mail.gmail.com>
 <AM4PR08MB121989D338005EEF06C55628FF290@AM4PR08MB1219.eurprd08.prod.outlook.com>
Message-ID: <CAM6ZMz8Q-zVA+pgUYg5wkTe5RwGEYpAg4LA3Y=dJ1tYPB5cHnA@mail.gmail.com>

Hi Bernd,

On Wed, Nov 15, 2017 at 7:04 AM, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
> I would however vote for allowing an empty list to be sorted. This is such a common case to return a replacement empty list that it will not only introduce changed behavior but also forces ugly code.

I think we would need to write ugly code in any case as Java 9 has now
two empty list implementations: Collections.emptyList() and List.of().

Collections.emptyList().sort() does not throw an exception.

List.of().sort() throws an exception.

Best regards,
Andrej Golovnin

>
> For singleton list I can kind of understand that you want to fail early, but it could be made the same argument as for the empty case.
>
> In the end, if we allow one or both, it requires to be spelled out explicitely (unfortunately a spec change, even when it is the more likely usage already)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Martin Buchholz <martinrb at google.com>
> Sent: Wednesday, November 15, 2017 5:10:06 AM
> To: Tagir Valeev
> Cc: core-libs-dev
> Subject: Re: Collections.emptyList().sort() does nothing
>
> Different maintainers of the core library differed on whether it's
> important to pedantically check for such corner case mistakes.  Recently
> the trend has been to check for all errors up front, even if it ends up
> making no difference.  Users should not depend on the library implementer's
> mood or vigilance, unless they're professional testers.
>
> On Tue, Nov 14, 2017 at 7:52 PM, Tagir Valeev <amaembo at gmail.com> wrote:
>
>> Hello!
>>
>> According to `List.sort` specification [1] "This list must be modifiable".
>> According to `Collections.emptyList` specification [2] "Returns an
>> empty list (immutable)."
>>
>> So I assume that `List.sort` cannot be called on
>> `Collections.emptyList` result. However in fact this call is allowed
>> doing nothing. Is this behavior documented somehow? Can I rely that it
>> will not change in future Java updates?
>>
>> It's even more strange with `Collections.singletonList` [3] which
>> "Returns an immutable list containing only the specified object".
>> Obviously I cannot do:
>>
>> List<String> list = Collections.singletonList("foo");
>> ListIterator<String> it = list.listIterator();
>> it.next();
>> it.set("bar"); // UOE
>>
>> However list.sort(null) works perfectly. On the other hand [1] clearly
>> says:
>>
>> Throws: UnsupportedOperationException - if the list's list-iterator
>> does not support the set operation.
>>
>> To me it seems that emptyList and (especially) singletonList
>> implementation does not follow the specification. Am I missing
>> something?
>>
>> With best regards,
>> Tagir Valeev.
>>
>> [1] https://docs.oracle.com/javase/9/docs/api/java/util/
>> List.html#sort-java.util.Comparator-
>> [2] https://docs.oracle.com/javase/9/docs/api/java/util/
>> Collections.html#emptyList--
>> [3] https://docs.oracle.com/javase/9/docs/api/java/util/Collections.html#
>> singletonList-T-
>>

From aph at redhat.com  Wed Nov 15 10:06:16 2017
From: aph at redhat.com (Andrew Haley)
Date: Wed, 15 Nov 2017 10:06:16 +0000
Subject: Collections.emptyList().sort() does nothing
In-Reply-To: <CAM6ZMz8Q-zVA+pgUYg5wkTe5RwGEYpAg4LA3Y=dJ1tYPB5cHnA@mail.gmail.com>
References: <CAE+3fjYhx1jwTyudEM3sEed9qtNap0-2xppvJ-b9AWZWJyamNw@mail.gmail.com>
 <CA+kOe0-xNkVgw0t2BFPLG3_xUg4+qV7qaqz0k_9oOOsws47N9Q@mail.gmail.com>
 <AM4PR08MB121989D338005EEF06C55628FF290@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <CAM6ZMz8Q-zVA+pgUYg5wkTe5RwGEYpAg4LA3Y=dJ1tYPB5cHnA@mail.gmail.com>
Message-ID: <0a8735dd-be3b-0383-4315-3209e8ab8f71@redhat.com>

On 15/11/17 10:03, Andrej Golovnin wrote:
> I think we would need to write ugly code in any case as Java 9 has now
> two empty list implementations: Collections.emptyList() and List.of().
> 
> Collections.emptyList().sort() does not throw an exception.
> 
> List.of().sort() throws an exception.

Well, that's a bug.  Sorting an empty list is perfectly valid, and application
programmers shouldn't have to special-case it.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From andrej.golovnin at gmail.com  Wed Nov 15 10:21:06 2017
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Wed, 15 Nov 2017 11:21:06 +0100
Subject: Collections.emptyList().sort() does nothing
In-Reply-To: <0a8735dd-be3b-0383-4315-3209e8ab8f71@redhat.com>
References: <CAE+3fjYhx1jwTyudEM3sEed9qtNap0-2xppvJ-b9AWZWJyamNw@mail.gmail.com>
 <CA+kOe0-xNkVgw0t2BFPLG3_xUg4+qV7qaqz0k_9oOOsws47N9Q@mail.gmail.com>
 <AM4PR08MB121989D338005EEF06C55628FF290@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <CAM6ZMz8Q-zVA+pgUYg5wkTe5RwGEYpAg4LA3Y=dJ1tYPB5cHnA@mail.gmail.com>
 <0a8735dd-be3b-0383-4315-3209e8ab8f71@redhat.com>
Message-ID: <CAM6ZMz-AtyMnQE5_vwsGbwHmb7gSdHub5E8ugMQUr25eUggSOg@mail.gmail.com>

> On 15/11/17 10:03, Andrej Golovnin wrote:
>> I think we would need to write ugly code in any case as Java 9 has now
>> two empty list implementations: Collections.emptyList() and List.of().
>>
>> Collections.emptyList().sort() does not throw an exception.
>>
>> List.of().sort() throws an exception.
>
> Well, that's a bug.  Sorting an empty list is perfectly valid, and application
> programmers shouldn't have to special-case it.

I don't think so. I would say that the implementation of
Collections.emptyList() is broken. Collections.emptyList() and
List.of() are not only empty lists. They are also immutable per
specification.

Here is another example of an unsortable empty list:

Collections.unmodifiableList(Collections.emptyList()).sort() throws an
exception.

>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From Alan.Bateman at oracle.com  Wed Nov 15 11:18:29 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 15 Nov 2017 11:18:29 +0000
Subject: Collections.emptyList().sort() does nothing
In-Reply-To: <CAM6ZMz8Q-zVA+pgUYg5wkTe5RwGEYpAg4LA3Y=dJ1tYPB5cHnA@mail.gmail.com>
References: <CAE+3fjYhx1jwTyudEM3sEed9qtNap0-2xppvJ-b9AWZWJyamNw@mail.gmail.com>
 <CA+kOe0-xNkVgw0t2BFPLG3_xUg4+qV7qaqz0k_9oOOsws47N9Q@mail.gmail.com>
 <AM4PR08MB121989D338005EEF06C55628FF290@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <CAM6ZMz8Q-zVA+pgUYg5wkTe5RwGEYpAg4LA3Y=dJ1tYPB5cHnA@mail.gmail.com>
Message-ID: <6b920929-38d6-2954-ae17-c48579c1fa12@oracle.com>

On 15/11/2017 10:03, Andrej Golovnin wrote:
> Hi Bernd,
>
> On Wed, Nov 15, 2017 at 7:04 AM, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
>> I would however vote for allowing an empty list to be sorted. This is such a common case to return a replacement empty list that it will not only introduce changed behavior but also forces ugly code.
> I think we would need to write ugly code in any case as Java 9 has now
> two empty list implementations: Collections.emptyList() and List.of().
>
> Collections.emptyList().sort() does not throw an exception.
>
> List.of().sort() throws an exception.
>
>
There are indeed inconsistencies and likely other examples due to List 
implementations not overriding sort (and so dependent on the default 
implementation which cannot say if an empty or already sorted list is 
modifiable or not). As Collections.emptyList() is around a long time 
then it would likely break existing code to change it now. It might be 
saner to change List0 to be consistent. In any case, the sort javadoc 
will likely need some adjustment to allow for long standing behavior.

-Alan

From vitalyd at gmail.com  Wed Nov 15 11:18:59 2017
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 15 Nov 2017 11:18:59 +0000
Subject: Collections.emptyList().sort() does nothing
In-Reply-To: <CAM6ZMz-AtyMnQE5_vwsGbwHmb7gSdHub5E8ugMQUr25eUggSOg@mail.gmail.com>
References: <CAE+3fjYhx1jwTyudEM3sEed9qtNap0-2xppvJ-b9AWZWJyamNw@mail.gmail.com>
 <CA+kOe0-xNkVgw0t2BFPLG3_xUg4+qV7qaqz0k_9oOOsws47N9Q@mail.gmail.com>
 <AM4PR08MB121989D338005EEF06C55628FF290@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <CAM6ZMz8Q-zVA+pgUYg5wkTe5RwGEYpAg4LA3Y=dJ1tYPB5cHnA@mail.gmail.com>
 <0a8735dd-be3b-0383-4315-3209e8ab8f71@redhat.com>
 <CAM6ZMz-AtyMnQE5_vwsGbwHmb7gSdHub5E8ugMQUr25eUggSOg@mail.gmail.com>
Message-ID: <CAHjP37FBWkwb-oqVPyaW7BC63Qzofs7pkCcuYBbyXNeG2KQjgw@mail.gmail.com>

On Wed, Nov 15, 2017 at 5:21 AM Andrej Golovnin <andrej.golovnin at gmail.com>
wrote:

> > On 15/11/17 10:03, Andrej Golovnin wrote:
> >> I think we would need to write ugly code in any case as Java 9 has now
> >> two empty list implementations: Collections.emptyList() and List.of().
> >>
> >> Collections.emptyList().sort() does not throw an exception.
> >>
> >> List.of().sort() throws an exception.
> >
> > Well, that's a bug.  Sorting an empty list is perfectly valid, and
> application
> > programmers shouldn't have to special-case it.
>
> I don't think so. I would say that the implementation of
> Collections.emptyList() is broken. Collections.emptyList() and
> List.of() are not only empty lists. They are also immutable per
> specification.
>
> Here is another example of an unsortable empty list:
>
> Collections.unmodifiableList(Collections.emptyList()).sort() throws an
> exception.

One can argue that since those are empty by construction/design, sorting
them is not a bug.  That?s different from, say, trying to sort an
unmodifiable list that happens to be empty and not failing in that case.

>From a user?s perspective, I agree it?s annoying to have to special case
these.  This is particularly so because immutability is not expressed in
the types or type system.

>
>
> >
> > --
> > Andrew Haley
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <https://www.redhat.com>
> > EAC8 43EB D3EF DB98 C
> <https://maps.google.com/?q=EF+DB98+C&entry=gmail&source=g>C77 2FAD A5CD
> 6035 332F A671
>
-- 
Sent from my phone

From Alan.Bateman at oracle.com  Wed Nov 15 11:22:37 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 15 Nov 2017 11:22:37 +0000
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <0E5B3DBE-20DF-4B68-857B-6BA8DECD8C13@reini.net>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
 <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
 <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>
 <8167AB26-7918-4920-A889-4FB2F2254BE5@reini.net>
 <3755dc7c-84b2-61a8-06a2-e45f5007f8b7@Oracle.com>
 <2D157CBB-65F0-41B1-8DB5-99F45BB8A412@reini.net>
 <52b9afdc-4103-3bf8-c111-9b0310e1f913@Oracle.com>
 <51486A9D-4982-47E3-9E64-4925E34BD488@reini.net>
 <AD985969-3146-4495-9328-4598C17653C0@oracle.com>
 <8999FF83-ACA0-44B6-B60B-E6544F6D192E@reini.net>
 <733069a3-33cb-3c68-0a51-6e33a7086f1! b@oracle.com>
 <28639443-48BF-4C74-AA4C-17433E202F00@oracle.com>
 <0E5B3DBE-20DF-4B68-857B-6BA8DECD8C13@reini.net>
Message-ID: <fcf121e8-290c-2544-4e9f-23634c478383@oracle.com>



On 14/11/2017 16:59, Patrick Reinhart wrote:
> :
>
> And what should it be then here? I?m a bit confused now?
>
Sorry, there was a typo in my mail that Brian picked up on. I think we 
are converging on:

"If the destination is capacity bounded and has insufficient capacity to 
append all characters read from the source then the exception may be 
thrown after transferring some characters to the destination".

-Alan

From jaroslav.tulach at oracle.com  Wed Nov 15 13:44:38 2017
From: jaroslav.tulach at oracle.com (Jaroslav Tulach)
Date: Wed, 15 Nov 2017 14:44:38 +0100
Subject: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only
 the permissions it really needs to expose the bean
In-Reply-To: <7b03728a-a3ad-e392-db1b-dd0807e1ffeb@oracle.com>
References: <2138013.zvGs44vPXg@pracovni>
 <715d933a-a747-8aac-620b-fba12f4236e0@oracle.com>
 <7b03728a-a3ad-e392-db1b-dd0807e1ffeb@oracle.com>
Message-ID: <1750350.QVl7KHXjYn@pracovni>

On ?ter? 14. listopadu 2017 21:34:45 CET mandy chung wrote:
> I am wondering this ACE comes from Graal accessing jdk.vm.ci.services
> from JVMCI which is defined to the boot loader versus Graal is defined
> to the platform class loader.
> 
>   java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.vm.ci.services")
> 
> However Graal grants with AllPermissions.
> 
> In any case, if this is an existing issue, I am okay if you file a
> separate issue to track this.

Hello Mandy,
yes, it looks like issue unrelated to my changes. I have reported: https://
bugs.openjdk.java.net/browse/JDK-8191320

I hope I haven't messed up something on my disk and others will be able to 
reproduce my problem.
-jt


> 
> Mandy
> 
> On 11/14/17 2:02 PM, Sean Mullan wrote:
> > Try running with -Djava.security.debug=access:domain:failure
> > 
> > This will tell you what ProtectionDomain caused the
> > AccessControlException, which should give you a better idea of where
> > the problem is. Look for messages that start with "domain that failed ".
> > 
> > --Sean
> > 
> > On 11/14/17 1:22 AM, Jaroslav Tulach wrote:
> >> I tried the same test with
> >> 
> >> changeset:   47679:d85284ccd1bd
> >> user:        sspitsyn
> >> date:        Fri Nov 03 17:09:25 2017 -0700
> >> summary:     8189731: Disable CFLH when there are no transformers
> >> 
> >> and it also yields the exception. E.g. the problem is certainly not
> >> result of
> >> my changes.
> >> 
> >> -jt
> >> 
> >> PS: I try full rebuild on d85284ccd1bd maybe it disappears...
> >> 
> >> On pond?l? 13. listopadu 2017 20:53:35 CET Jaroslav Tulach wrote:
> >>> Hello Mandy,
> >>> 
> >>> this was a good test:
> >>>>> ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
> >>>>> +EnableJVMCI -XX:+UseJVMCICompiler -jar ...
> >>>> 
> >>>> You can also try running the above command with
> >>>> -Djava.security.manager
> >>>> as a sanity test (the application may need additional permissions) -
> >>>> just a sanity test.
> >>> 
> >>> I've just tried:
> >>> 
> >>> $ ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
> >>> +EnableJVMCI -XX:+UseJVMCICompiler -Djava.security.manager -jar ~/
> >>> NetBeansProjects/sieve/java/algorithm/target/sieve-algorithm-1.0-SNAPSHO
> >>> T.ja
> >>> 
> >>> r
> >>> 
> >>> and it doesn't work. I am getting an error below, however the code
> >>> is not
> >>> running through my module at all. I don't understand the failure, I
> >>> will
> >>> have to investigate more.
> >>> 
> >>> -jt
> >>> 
> >>> 
> >>> Caused by: java.security.AccessControlException: access denied
> >>> ("java.lang.RuntimePermission"
> >>> "accessClassInPackage.jdk.vm.ci.services")
> >>>          at java.base/
> >>> java.security.AccessControlContext.checkPermission(AccessControlContext.
> >>> java>>> 
> >>> : 472)
> >>> 
> >>>          at java.base/
> >>> java.security.AccessController.checkPermission(AccessController.java:895
> >>> )
> >>> 
> >>>          at java.base/
> >>> java.lang.SecurityManager.checkPermission(SecurityManager.java:558)
> >>>          at java.base/
> >>> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1534)
> >>>          at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:680)
> >>>          at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:678)
> >>>          at
> >>> java.base/java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>          at java.base/
> >>> java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:678)
> >>>          at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> >>>          at
> >>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1006) at
> >>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1085) at
> >>> java.base/
> >>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:206)
> >>>          at java.base/
> >>> jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.ja
> >>> va:7
> >>> 
> >>> 60) at java.base/jdk.internal.loader.BuiltinClassLoader.lambda
> >>> $findClassInModuleOrNull$2(BuiltinClassLoader.java:683)
> >>>          at
> >>> java.base/java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>          at java.base/
> >>> jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinCl
> >>> assL
> >>> 
> >>> oader.java: 684)
> >>>          at java.base/
> >>> jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java
> >>> :562
> >>> 
> >>> ) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:607) at
> >>> java.base/java.lang.Class.forName(Class.java:451)
> >>>          at java.base/java.util.ServiceLoader.lambda$loadProvider
> >>> $1(ServiceLoader.java:856)
> >>>          at
> >>> java.base/java.security.AccessController.doPrivileged(Native
> >>> Method)
> >>>          at
> >>> java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java: 858)



From dmitry.chuyko at bell-sw.com  Wed Nov 15 15:27:13 2017
From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko)
Date: Wed, 15 Nov 2017 18:27:13 +0300
Subject: RFR (S): JDK-8191328: Avoid unnecessary overhead in CRC32C
Message-ID: <6f8d38e5-f609-e885-5990-945decbe6e9b@bell-sw.com>

Hello,

Please review a performance enhancement for java.util.CRC32C pure Java 
implementation.

rfe: https://bugs.openjdk.java.net/browse/JDK-8191328
webrev: http://cr.openjdk.java.net/~dchuyko/8191328/webrev.00/
some results: 
https://bugs.openjdk.java.net/browse/JDK-8191328?focusedCommentId=14131194&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14131194
mail thread on original implementation: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-October/029187.html

I made 2 changes:

* Move ByteOrder.nativeOrder() branches outside of main loops.

* Break xors and loads into independent pairs.

In some specific cases like -Xcomp it gives 2-7x boost. The code size 
has not increased significantly.

Changes were checked by comparison with golden checksums on different 
lengths of arrays and buffers, on x86 and aarch64, though both 64-bit 
Little-Endian.

-Dmitry


From Roger.Riggs at Oracle.com  Wed Nov 15 15:36:54 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 15 Nov 2017 10:36:54 -0500
Subject: Review request: JDK-8157246 MHs.arrayLength,
 arrayElementGetter/Setter, arrayConstructor need to specify invocation-time
 behavior
In-Reply-To: <87e6fd45-6a82-b3c6-4536-df7c2cfae4ba@oracle.com>
References: <aeb0d6af-e148-55ec-cbb6-05f3a46eb0b6@oracle.com>
 <2DEB8EC2-7A14-4492-AA34-9E83B8EAD6B1@oracle.com>
 <328d482f-4d2e-7e2b-905d-44eef27581a8@oracle.com>
 <0214446A-B18C-475D-88D3-73A5F8F924BB@oracle.com>
 <9ed49215-49f4-c188-1bd9-7e5f8d6aa044@Oracle.com>
 <87e6fd45-6a82-b3c6-4536-df7c2cfae4ba@oracle.com>
Message-ID: <4c30815d-6344-be8f-bee5-c66c242db1f1@Oracle.com>

Looks fine.

Nothing more from me,?? Roger

On 11/8/2017 6:52 PM, mandy chung wrote:
> Hi Roger,
>
> Updated version:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.02/index.html 
>
>
> On 11/8/17 11:37 AM, Roger Riggs wrote:
>> Hi Mandy,
>>
>> A few editorial suggestions:
>>
>> MethodHandle.java:
>> 891: "accepts**a** zero-length trailing array argument
>
> Fixed
>> 895: "if **the* *{@code array} does"
>>
>
> {@code array} is referred to the parameter name where I don't use 
> article.? I drop the {@code...} and change it to "If the array".
>
>> MethodHandleImpl.java:
>> 667:? hard to follow indentation; perhaps adding the "else" will help.
>>
>
> I revised it to the following:
>
> ??????? if (av == null && n == 0) {
> ??????????? return;
> ??????? } else if (av == null) {
> ??????????? throw new NullPointerException("null array reference");
>
>> MethodHandles.java:
>> 2517: "Produces a method handle *for* constructing arrays..."
>
> It reads fine without "for" and the other arrayXXX factory methods are 
> similar.? I leave it for the original author to follow up.
>
>> 2523: "array size, *a* {@code NegativeArraySizeException} will be 
>> thrown."
>> 2550: "array reference, *a* {@code NullPointerPointer} exception will 
>> be thrown."
>> 2573 & 2598 & 2641: "*A* {@code NullPointerPointer} *exception* will 
>> be thrown if the array reference
>>
>> Is there a test for asSpreader(null, 0) and asSpreader(null, 1)? (The 
>> new exception thrown at MethodHandleImpl:667)
>>
>
> The new exception is thrown when the MethodHandle returned by 
> MethodHandle::asSpreader.? The test cases are covered by the new 
> InvokeMethodHandleWithBadArgument test.
>
> asSpreader(null, 0) and asSpreader(null, 1) are not related to this 
> issue.? The check is done by MethodHandle::asSpreaderChecks. Since 
> this gets my attention, I add the test cases in an existing test 
> SpreadCollectTest.java.
>
> Mandy


From Alan.Bateman at oracle.com  Wed Nov 15 15:38:40 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 15 Nov 2017 15:38:40 +0000
Subject: RFR (S): JDK-8191328: Avoid unnecessary overhead in CRC32C
In-Reply-To: <6f8d38e5-f609-e885-5990-945decbe6e9b@bell-sw.com>
References: <6f8d38e5-f609-e885-5990-945decbe6e9b@bell-sw.com>
Message-ID: <0fd60794-b23a-1818-dea4-e72007f7cdd6@oracle.com>



On 15/11/2017 15:27, Dmitry Chuyko wrote:
> Hello,
>
> Please review a performance enhancement for java.util.CRC32C pure Java 
> implementation.
Moving the nativeOrder out of the loop make sense but I'm curious about 
the context for improving this implementation. You mentioned it helps 
-Xcomp but that is typically for testing. Is there some environment that 
is disabling the HotSpot intrinsic?

-Alan

From dmitry.chuyko at bell-sw.com  Wed Nov 15 16:17:44 2017
From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko)
Date: Wed, 15 Nov 2017 19:17:44 +0300
Subject: RFR (S): JDK-8191328: Avoid unnecessary overhead in CRC32C
In-Reply-To: <0fd60794-b23a-1818-dea4-e72007f7cdd6@oracle.com>
References: <6f8d38e5-f609-e885-5990-945decbe6e9b@bell-sw.com>
 <0fd60794-b23a-1818-dea4-e72007f7cdd6@oracle.com>
Message-ID: <bbc5be57-94e7-b7f8-7e95-7c0adc10f3b0@bell-sw.com>

On 11/15/2017 06:38 PM, Alan Bateman wrote:
>
>
> On 15/11/2017 15:27, Dmitry Chuyko wrote:
>> Hello,
>>
>> Please review a performance enhancement for java.util.CRC32C pure 
>> Java implementation.
> Moving the nativeOrder out of the loop make sense but I'm curious 
> about the context for improving this implementation. You mentioned it 
> helps -Xcomp but that is typically for testing. Is there some 
> environment that is disabling the HotSpot intrinsic?
There may be no intrinsic (zero, arm) or there may be no Hotspot (J9, 
Excelsior, Android).
But I spotted it in -Xcomp because it was unclear why people make their 
own pure Java implementations instead of using and contributing to 
core-lib classes.

-Dmitry
>
> -Alan


From paul.sandoz at oracle.com  Wed Nov 15 17:03:29 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 15 Nov 2017 09:03:29 -0800
Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants
In-Reply-To: <ad4ecc92-6c33-1ab3-1608-e0fa4f6ebf4f@oracle.com>
References: <AE7CEFD5-9FFE-45CB-9423-D287C33256A1@oracle.com>
 <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com>
 <26336F4F-0A21-4A08-AFA3-23CA972CAD93@oracle.com>
 <e9dad599-2e49-d66d-4236-59191a52320b@oracle.com>
 <130F7E94-9408-4C49-9C23-840361B4B379@oracle.com>
 <ad4ecc92-6c33-1ab3-1608-e0fa4f6ebf4f@oracle.com>
Message-ID: <C49886C5-8F01-4CB1-AE55-0309D6E06863@oracle.com>



> On 14 Nov 2017, at 20:48, stanislav lukyanov <stanislav.lukyanov at oracle.com> wrote:
> 
> On 15.11.2017 6:19, Paul Sandoz wrote:
>>> On 10 Nov 2017, at 01:36, stanislav lukyanov <stanislav.lukyanov at oracle.com> wrote:
>>> 
>>> On 10.11.2017 0:13, Paul Sandoz wrote:
>>>> <...>
>>>> I would prefer to follow up later on with more non-normative explanatory text. It will take some careful crafting and i don?t want that to side-track the review for the moment (including guidance on what forms of computed constants are acceptable).
>>> Fair. Does it make sense to add a sub-task for this to JDK-8185992 to keep it on the radar?
>> You would mind adding a sub-task with a tbd minor target?
> TBD_Minor would mean an update release, right?
> I think it can't be a TBD_Minor then since it is technically a specification change and should happen in a Java SE release (maybe 11?), but maybe I'm wrong.

I was thinking this issue would be just for non-normative text in an @apiNote. Whether that maps to tbd_x or not with the new release process i dunno. Let?s just use tbd_major for now.

Paul.

> Anyway, as long as that's logged and not completely forgotten, I'm happy :)
> 
> Thanks,
> Stas


From aph at redhat.com  Wed Nov 15 17:40:26 2017
From: aph at redhat.com (Andrew Haley)
Date: Wed, 15 Nov 2017 17:40:26 +0000
Subject: RFR (S): JDK-8191328: Avoid unnecessary overhead in CRC32C
In-Reply-To: <0fd60794-b23a-1818-dea4-e72007f7cdd6@oracle.com>
References: <6f8d38e5-f609-e885-5990-945decbe6e9b@bell-sw.com>
 <0fd60794-b23a-1818-dea4-e72007f7cdd6@oracle.com>
Message-ID: <67f55a91-2e9d-c401-c213-df93b62188c1@redhat.com>

On 15/11/17 15:38, Alan Bateman wrote:
> Moving the nativeOrder out of the loop make sense but I'm curious about 
> the context for improving this implementation.

I wonder about lifting ByteOrder.nativeOrder().  Maybe it fails to
inline because the method is too large: if that happens, we really
lose.  I'm not seeing that, though: it seems to be inlined just fine,
and has no effect.

In any case, this patch doesn't help anything on my test hardware.

Before:
CRC.crc    avgt    5  1050.374 ? 1.533  ns/op

After:
CRC.crc    avgt    5  1088.962 ? 0.212  ns/op

And here, for the sake of anyone interested, is the AArch64 code,
before:

 ;; B10: #	B10 B11 <- B9 B10 	Loop: B10-B10 inner main of N120 Freq: 127.001

  0x000003ffa4bb5900: ldr	x2, [x11,w3,sxtw]  ;*invokevirtual getLong {reexecute=0 rethrow=0 return_oop=0}
                                                ; - java.util.zip.CRC32C::updateBytes at 147 (line 237)

  0x000003ffa4bb5904: eor	w4, w2, w1      ;*ixor {reexecute=0 rethrow=0 return_oop=0}
                                                ; - java.util.zip.CRC32C::updateBytes at 193 (line 246)

  0x000003ffa4bb5908: lsr	x2, x2, #32
  0x000003ffa4bb590c: ubfiz	x5, x4, #2, #8
  0x000003ffa4bb5910: mov	w19, w2         ;*l2i {reexecute=0 rethrow=0 return_oop=0}
                                                ; - java.util.zip.CRC32C::updateBytes at 171 (line 240)

  0x000003ffa4bb5914: ubfx	w2, w4, #16, #8
  0x000003ffa4bb5918: ubfx	w1, w4, #8, #8
  0x000003ffa4bb591c: ldr	w6, [x15,x5]
  0x000003ffa4bb5920: lsr	w5, w4, #24
  0x000003ffa4bb5924: ldr	w4, [x16,w2,sxtw #2]
  0x000003ffa4bb5928: ldr	w1, [x14,w1,sxtw #2]
  0x000003ffa4bb592c: ldr	w2, [x17,w5,sxtw #2]
  0x000003ffa4bb5930: eor	w5, w1, w6
  0x000003ffa4bb5934: ubfiz	x23, x19, #2, #8
  0x000003ffa4bb5938: ubfx	w6, w19, #8, #8
  0x000003ffa4bb593c: eor	w4, w5, w4
  0x000003ffa4bb5940: ubfx	w5, w19, #16, #8
  0x000003ffa4bb5944: ldr	w1, [x18,x23]
  0x000003ffa4bb5948: eor	w2, w4, w2
  0x000003ffa4bb594c: ldr	w6, [x0,w6,sxtw #2]
  0x000003ffa4bb5950: lsr	w4, w19, #24
  0x000003ffa4bb5954: ldr	w19, [x13,w5,sxtw #2]
  0x000003ffa4bb5958: eor	w2, w2, w1
  0x000003ffa4bb595c: add	w5, w3, #0x8
  0x000003ffa4bb5960: ldr	w1, [x12,w4,sxtw #2]
  0x000003ffa4bb5964: eor	w29, w2, w6
  0x000003ffa4bb5968: eor	w4, w29, w19

and after:

 ;; B10: #	B10 B11 <- B9 B10 	Loop: B10-B10 inner main of N121 Freq: 127.001

  0x000003ff8cb98200: ldr	x10, [x21,w3,sxtw]
                                                ;*invokevirtual getLong {reexecute=0 rethrow=0 return_oop=0}
                                                ; - java.util.zip.CRC32C::updateBytes at 359 (line 264)

  0x000003ff8cb98204: eor	w1, w10, w1     ;*ixor {reexecute=0 rethrow=0 return_oop=0}
                                                ; - java.util.zip.CRC32C::updateBytes at 380 (line 268)

  0x000003ff8cb98208: ubfx	w2, w1, #8, #8
  0x000003ff8cb9820c: lsr	x10, x10, #32
  0x000003ff8cb98210: ubfx	w5, w1, #16, #8
  0x000003ff8cb98214: mov	w10, w10        ;*l2i {reexecute=0 rethrow=0 return_oop=0}
                                                ; - java.util.zip.CRC32C::updateBytes at 374 (line 266)

  0x000003ff8cb98218: ldr	w0, [x15,w2,sxtw #2]
  0x000003ff8cb9821c: lsr	w6, w1, #24
  0x000003ff8cb98220: ubfiz	x4, x1, #2, #8
  0x000003ff8cb98224: ubfx	w1, w10, #8, #8
  0x000003ff8cb98228: ldr	w2, [x17,w5,sxtw #2]
  0x000003ff8cb9822c: ubfiz	x20, x10, #2, #8
  0x000003ff8cb98230: lsr	w5, w10, #24
  0x000003ff8cb98234: ubfx	w19, w10, #16, #8
  0x000003ff8cb98238: ldr	w10, [x13,w1,sxtw #2]
  0x000003ff8cb9823c: ldr	w6, [x18,w6,sxtw #2]
  0x000003ff8cb98240: ldr	w4, [x16,x4]
  0x000003ff8cb98244: ldr	w1, [x12,w19,sxtw #2]
  0x000003ff8cb98248: ldr	w7, [x14,x20]
  0x000003ff8cb9824c: eor	w6, w2, w6
  0x000003ff8cb98250: eor	w0, w0, w4
  0x000003ff8cb98254: ldr	w19, [x11,w5,sxtw #2]
  0x000003ff8cb98258: add	w20, w3, #0x8
  0x000003ff8cb9825c: eor	w29, w0, w6
  0x000003ff8cb98260: eor	w10, w10, w7
  0x000003ff8cb98264: eor	w0, w1, w19
  0x000003ff8cb98268: eor	w1, w10, w29

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From naoto.sato at oracle.com  Wed Nov 15 18:06:59 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 15 Nov 2017 10:06:59 -0800
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <CACzrW9CbB9TOto1UgNmiFfN7pB8D7gKVQBb89t1x_J20NoGpMg@mail.gmail.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <CACzrW9C+GekWNRdWVi1AhVs_CiPgWksde-6iRT1Z68-RhkziZw@mail.gmail.com>
 <098fb447-9d89-2d2d-20a8-06b85d128020@oracle.com>
 <CACzrW9CbB9TOto1UgNmiFfN7pB8D7gKVQBb89t1x_J20NoGpMg@mail.gmail.com>
Message-ID: <1a518134-57a5-6ac9-40eb-c948b15b88b9@oracle.com>

On 11/14/17 4:44 PM, Stephen Colebourne wrote:
> On 14 November 2017 at 23:58, Naoto Sato <naoto.sato at oracle.com> wrote:
>> So even with the new suggested method,
>>
>> formatter.withZone(locale).withLocalization(locale)
>> formatter.withLocalization(locale).withZone(locale)
>>
>> would produce different formatters. Would it be OK, assuming along with some
>> proper documentation?
> 
> Thats why I suggested perhaps a different method name is needed, not
> withXxx() to highlight the larger impact. eg. localizedBy(Locale)

OK. Will come up with a draft. Essentially what the new method does is 
what withLocale() does, plus replacing fields specified with Unicode 
extensions (calendar/timezone/region override)

> 
>>>    DateTimeFormatterBuilder.toFormatter(Locale, ResolverStyle,
>>> Chronology) has new logic to override the chronology. But this method
>>> is used indirectly from ofLocalizedTime() and friends which require
>>> the output to be ISO chronology. Thus the webrev would break the
>>> specification of those methods.
>>
>> Would you suggest not interpreting extensions in this method? I am now
>> inclined to just interpret locale extensions in the new suggested method for
>> the java.time package.
> 
> Fundamentally, the tags you are processing are a problem for the
> design of java.time formatters. The existing API is structured around
> a narrow meaning of Locale for text input/output within the formatting
> API.
> 
> Changing the behaviour of DateTimeFormatterBuilder.toFormatter(...)
> methods could have some odd effects for end-user code. Where they are
> currently just expecting the locale to be set to control text
> input/output, it would suddenly affect the calendar system and
> time-zone, which could break code/compatibility in certain cases.

I've decided to retract changes in 
DateTimeFormatter/DateTimeFormatterBuilder currently in the webrev, with 
adding some text noting Unicode extensions are ignored in those methods.

> 
> I think that its OK to use the unicode tags in places like
> WeekFields.of() or Chronology.of(). But for formatting, the change in
> meaning is too great. Adding a single method (name TBD) makes more
> sense
Will keep the changes in WeekFields.of()/Chronology.of()

> 
> There is a case to add ZoneId.ofLocale(Locale) to match
> Chronology.ofLocale(Locale). However, the expectation would be that it
> figures out a suitable time-zone for the country/region as well as
> considering the -u-tz- tag, and I don't think you've got that data
> available at present (but it would make a good follow on change).

Yes, we don't yet have that mechanism to derive time zone based on the 
region. I think that's out of this JEP's scope.

Naoto

From brian.burkhalter at oracle.com  Wed Nov 15 18:07:32 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 15 Nov 2017 10:07:32 -0800
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <fcf121e8-290c-2544-4e9f-23634c478383@oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <e56261b2-31e5-3e29-02e3-365a2bacc105@oracle.com>
 <4FFD45C9-91E3-4130-9112-E2717834749D@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
 <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
 <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>
 <8167AB26-7918-4920-A889-4FB2F2254BE5@reini.net>
 <3755dc7c-84b2-61a8-06a2-e45f5007f8b7@Oracle.com>
 <2D157CBB-65F0-41B1-8DB5-99F45BB8A412@reini.net>
 <52b9afdc-4103-3bf8-c111-9b0310e1f913@Oracle.com>
 <51486A9D-4982-47E3-9E64-4925E34BD488@reini.net>
 <AD985969-3146-4495-9328-4598C17653C0@oracle.com>
 <8999FF83-ACA0-44B6-B60B-E6544F6D192E@reini.net>
 <733069a3-33cb-3c68-0a51-6e33a7086f1! b@oracle.com>
 <28639443-48BF-4C74-AA4C-17433E202F00@oracle.com>
 <0E5B3DBE-20DF-4B68-857B-6BA8DECD8C13@reini.net>
 <fcf121e8-290c-2544-4e9f-23634c478! 383@oracle.com>
Message-ID: <0645B0CB-A032-41B6-85B6-EE0FDB1F78F0@oracle.com>

On Nov 15, 2017, at 3:22 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> "If the destination is capacity bounded and has insufficient capacity to append all characters read from the source then the exception may be thrown after transferring some characters to the destination".

Could ?is capacity-bounded and? be removed?

Brian

From vitalyd at gmail.com  Wed Nov 15 18:38:16 2017
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 15 Nov 2017 13:38:16 -0500
Subject: RFR (S): JDK-8191328: Avoid unnecessary overhead in CRC32C
In-Reply-To: <67f55a91-2e9d-c401-c213-df93b62188c1@redhat.com>
References: <6f8d38e5-f609-e885-5990-945decbe6e9b@bell-sw.com>
 <0fd60794-b23a-1818-dea4-e72007f7cdd6@oracle.com>
 <67f55a91-2e9d-c401-c213-df93b62188c1@redhat.com>
Message-ID: <CAHjP37Htvo-C7Q3PmCbujLbratwRJcYpB2puQikghjhWWzObfg@mail.gmail.com>

On Wed, Nov 15, 2017 at 12:40 PM, Andrew Haley <aph at redhat.com> wrote:
> On 15/11/17 15:38, Alan Bateman wrote:
>> Moving the nativeOrder out of the loop make sense but I'm curious about
>> the context for improving this implementation.
>
> I wonder about lifting ByteOrder.nativeOrder().  Maybe it fails to
> inline because the method is too large: if that happens, we really
> lose.  I'm not seeing that, though: it seems to be inlined just fine,
> and has no effect.
>
> In any case, this patch doesn't help anything on my test hardware.
Is this with -Xcomp though? That can generate crap code because
there's no profiling information.  Not that -Xcomp should be the way
to test peak performance IMO, but that is the setting that was used I
believe.
>
> Before:
> CRC.crc    avgt    5  1050.374 ? 1.533  ns/op
>
> After:
> CRC.crc    avgt    5  1088.962 ? 0.212  ns/op
>
> And here, for the sake of anyone interested, is the AArch64 code,
> before:
>
>  ;; B10: #      B10 B11 <- B9 B10       Loop: B10-B10 inner main of N120 Freq: 127.001
>
>   0x000003ffa4bb5900: ldr       x2, [x11,w3,sxtw]  ;*invokevirtual getLong {reexecute=0 rethrow=0 return_oop=0}
>                                                 ; - java.util.zip.CRC32C::updateBytes at 147 (line 237)
>
>   0x000003ffa4bb5904: eor       w4, w2, w1      ;*ixor {reexecute=0 rethrow=0 return_oop=0}
>                                                 ; - java.util.zip.CRC32C::updateBytes at 193 (line 246)
>
>   0x000003ffa4bb5908: lsr       x2, x2, #32
>   0x000003ffa4bb590c: ubfiz     x5, x4, #2, #8
>   0x000003ffa4bb5910: mov       w19, w2         ;*l2i {reexecute=0 rethrow=0 return_oop=0}
>                                                 ; - java.util.zip.CRC32C::updateBytes at 171 (line 240)
>
>   0x000003ffa4bb5914: ubfx      w2, w4, #16, #8
>   0x000003ffa4bb5918: ubfx      w1, w4, #8, #8
>   0x000003ffa4bb591c: ldr       w6, [x15,x5]
>   0x000003ffa4bb5920: lsr       w5, w4, #24
>   0x000003ffa4bb5924: ldr       w4, [x16,w2,sxtw #2]
>   0x000003ffa4bb5928: ldr       w1, [x14,w1,sxtw #2]
>   0x000003ffa4bb592c: ldr       w2, [x17,w5,sxtw #2]
>   0x000003ffa4bb5930: eor       w5, w1, w6
>   0x000003ffa4bb5934: ubfiz     x23, x19, #2, #8
>   0x000003ffa4bb5938: ubfx      w6, w19, #8, #8
>   0x000003ffa4bb593c: eor       w4, w5, w4
>   0x000003ffa4bb5940: ubfx      w5, w19, #16, #8
>   0x000003ffa4bb5944: ldr       w1, [x18,x23]
>   0x000003ffa4bb5948: eor       w2, w4, w2
>   0x000003ffa4bb594c: ldr       w6, [x0,w6,sxtw #2]
>   0x000003ffa4bb5950: lsr       w4, w19, #24
>   0x000003ffa4bb5954: ldr       w19, [x13,w5,sxtw #2]
>   0x000003ffa4bb5958: eor       w2, w2, w1
>   0x000003ffa4bb595c: add       w5, w3, #0x8
>   0x000003ffa4bb5960: ldr       w1, [x12,w4,sxtw #2]
>   0x000003ffa4bb5964: eor       w29, w2, w6
>   0x000003ffa4bb5968: eor       w4, w29, w19
>
> and after:
>
>  ;; B10: #      B10 B11 <- B9 B10       Loop: B10-B10 inner main of N121 Freq: 127.001
>
>   0x000003ff8cb98200: ldr       x10, [x21,w3,sxtw]
>                                                 ;*invokevirtual getLong {reexecute=0 rethrow=0 return_oop=0}
>                                                 ; - java.util.zip.CRC32C::updateBytes at 359 (line 264)
>
>   0x000003ff8cb98204: eor       w1, w10, w1     ;*ixor {reexecute=0 rethrow=0 return_oop=0}
>                                                 ; - java.util.zip.CRC32C::updateBytes at 380 (line 268)
>
>   0x000003ff8cb98208: ubfx      w2, w1, #8, #8
>   0x000003ff8cb9820c: lsr       x10, x10, #32
>   0x000003ff8cb98210: ubfx      w5, w1, #16, #8
>   0x000003ff8cb98214: mov       w10, w10        ;*l2i {reexecute=0 rethrow=0 return_oop=0}
>                                                 ; - java.util.zip.CRC32C::updateBytes at 374 (line 266)
>
>   0x000003ff8cb98218: ldr       w0, [x15,w2,sxtw #2]
>   0x000003ff8cb9821c: lsr       w6, w1, #24
>   0x000003ff8cb98220: ubfiz     x4, x1, #2, #8
>   0x000003ff8cb98224: ubfx      w1, w10, #8, #8
>   0x000003ff8cb98228: ldr       w2, [x17,w5,sxtw #2]
>   0x000003ff8cb9822c: ubfiz     x20, x10, #2, #8
>   0x000003ff8cb98230: lsr       w5, w10, #24
>   0x000003ff8cb98234: ubfx      w19, w10, #16, #8
>   0x000003ff8cb98238: ldr       w10, [x13,w1,sxtw #2]
>   0x000003ff8cb9823c: ldr       w6, [x18,w6,sxtw #2]
>   0x000003ff8cb98240: ldr       w4, [x16,x4]
>   0x000003ff8cb98244: ldr       w1, [x12,w19,sxtw #2]
>   0x000003ff8cb98248: ldr       w7, [x14,x20]
>   0x000003ff8cb9824c: eor       w6, w2, w6
>   0x000003ff8cb98250: eor       w0, w0, w4
>   0x000003ff8cb98254: ldr       w19, [x11,w5,sxtw #2]
>   0x000003ff8cb98258: add       w20, w3, #0x8
>   0x000003ff8cb9825c: eor       w29, w0, w6
>   0x000003ff8cb98260: eor       w10, w10, w7
>   0x000003ff8cb98264: eor       w0, w1, w19
>   0x000003ff8cb98268: eor       w1, w10, w29
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Wed Nov 15 18:44:13 2017
From: aph at redhat.com (Andrew Haley)
Date: Wed, 15 Nov 2017 18:44:13 +0000
Subject: RFR (S): JDK-8191328: Avoid unnecessary overhead in CRC32C
In-Reply-To: <CAHjP37Htvo-C7Q3PmCbujLbratwRJcYpB2puQikghjhWWzObfg@mail.gmail.com>
References: <6f8d38e5-f609-e885-5990-945decbe6e9b@bell-sw.com>
 <0fd60794-b23a-1818-dea4-e72007f7cdd6@oracle.com>
 <67f55a91-2e9d-c401-c213-df93b62188c1@redhat.com>
 <CAHjP37Htvo-C7Q3PmCbujLbratwRJcYpB2puQikghjhWWzObfg@mail.gmail.com>
Message-ID: <1db026bf-b3eb-2ff6-8132-fbd31f881bbb@redhat.com>

On 15/11/17 18:38, Vitaly Davidovich wrote:
> On Wed, Nov 15, 2017 at 12:40 PM, Andrew Haley <aph at redhat.com> wrote:
>> On 15/11/17 15:38, Alan Bateman wrote:
>>> Moving the nativeOrder out of the loop make sense but I'm curious about
>>> the context for improving this implementation.
>>
>> I wonder about lifting ByteOrder.nativeOrder().  Maybe it fails to
>> inline because the method is too large: if that happens, we really
>> lose.  I'm not seeing that, though: it seems to be inlined just fine,
>> and has no effect.
>>
>> In any case, this patch doesn't help anything on my test hardware.
> Is this with -Xcomp though? That can generate crap code because
> there's no profiling information.  Not that -Xcomp should be the way
> to test peak performance IMO, but that is the setting that was used I
> believe.

Shrug; maybe.  We shouldn't mess the code up for -Xcomp.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From patrick at reini.net  Wed Nov 15 19:55:41 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 15 Nov 2017 20:55:41 +0100
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <0645B0CB-A032-41B6-85B6-EE0FDB1F78F0@oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
 <066527d7-9469-2fc4-21e9-7a3fe6248a98@oracle.com>
 <D75C1278-794F-4DB8-9E7C-1113805A5A9B@reini.net>
 <9a7fbe49-740a-6f23-b387-903979d1d915@oracle.com>
 <14D15B2B-1323-430B-9707-8384FD3B8CAC@oracle.com>
 <972AD5AD-4DA8-4D14-94B9-D9387EDAA559@reini.net>
 <AD94A2C0-EEBD-40F1-94B2-F32478FAA961@oracle.com>
 <8167AB26-7918-4920-A889-4FB2F2254BE5@reini.net>
 <3755dc7c-84b2-61a8-06a2-e45f5007f8b7@Oracle.com>
 <2D157CBB-65F0-41B1-8DB5-99F45BB8A412@reini.net>
 <52b9afdc-4103-3bf8-c111-9b0310e1f913@Oracle.com>
 <51486A9D-4982-47E3-9E64-4925E34BD488@reini.net>
 <AD985969-3146-4495-9328-4598C17653C0@oracle.com>
 <8999FF83-ACA0-44B6-B60B-E6544F6D192E@reini.net>
 <733069a3-33cb-3c68-0a51-6e33a7086f1! b@oracle.com>
 <28639443-48BF-4C74-AA4C-17433E202F00@oracle.com>
 <0E5B3DBE-20DF-4B68-857B-6BA8DECD8C13@reini.net>
 <fcf121e8-290c-2544-4e9f-23634c478! 383@oracle.com>
 <0645B0CB-A032-41B6-85B6-EE0FDB1F78F0@oracle.com>
Message-ID: <36dd7891-558d-777b-270e-271ec54091f0@reini.net>


Just to see if I picked up the Discussion so far. The discussion is
about that original sentence
from: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.03

"Depending on which class implements the appendable, there may be a
limit of data
that can written to which in turn could lead to an exception."

And your current suggestion would look like:

1) "If the destination is capacity bounded and has insufficient capacity
to append all characters
read from the source then the exception may be thrown after transferring
some characters
to the destination"

At the version from:
http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.04
I got the version from Brian Burkhalter suggested earlier:

2) "Note that it is possible an implementing class may limit the number of
characters which may be transferred and throw an exception if this limit
is exceeded."


Now looking at both versions, the version 1 seems a bit more declarative
than version 2 and I
would go for the first one...

-Patrick



Am 15.11.2017 um 19:07 schrieb Brian Burkhalter:
> On Nov 15, 2017, at 3:22 AM, Alan Bateman <Alan.Bateman at oracle.com
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>> .
>
> Could ?is capacity-bounded and? be removed?
>
> Brian



From naoto.sato at oracle.com  Wed Nov 15 21:18:26 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 15 Nov 2017 13:18:26 -0800
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <1a518134-57a5-6ac9-40eb-c948b15b88b9@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <CACzrW9C+GekWNRdWVi1AhVs_CiPgWksde-6iRT1Z68-RhkziZw@mail.gmail.com>
 <098fb447-9d89-2d2d-20a8-06b85d128020@oracle.com>
 <CACzrW9CbB9TOto1UgNmiFfN7pB8D7gKVQBb89t1x_J20NoGpMg@mail.gmail.com>
 <1a518134-57a5-6ac9-40eb-c948b15b88b9@oracle.com>
Message-ID: <3c3c8b89-9a47-9df4-61b8-cdb59850d88e@oracle.com>

Here is the proposed spec changes:

http://cr.openjdk.java.net/~naoto/8191349/specdiff.00/overview-summary.html

Naoto


On 11/15/17 10:06 AM, Naoto Sato wrote:
> On 11/14/17 4:44 PM, Stephen Colebourne wrote:
>> On 14 November 2017 at 23:58, Naoto Sato <naoto.sato at oracle.com> wrote:
>>> So even with the new suggested method,
>>>
>>> formatter.withZone(locale).withLocalization(locale)
>>> formatter.withLocalization(locale).withZone(locale)
>>>
>>> would produce different formatters. Would it be OK, assuming along 
>>> with some
>>> proper documentation?
>>
>> Thats why I suggested perhaps a different method name is needed, not
>> withXxx() to highlight the larger impact. eg. localizedBy(Locale)
> 
> OK. Will come up with a draft. Essentially what the new method does is 
> what withLocale() does, plus replacing fields specified with Unicode 
> extensions (calendar/timezone/region override)
> 
>>
>>>> ?? DateTimeFormatterBuilder.toFormatter(Locale, ResolverStyle,
>>>> Chronology) has new logic to override the chronology. But this method
>>>> is used indirectly from ofLocalizedTime() and friends which require
>>>> the output to be ISO chronology. Thus the webrev would break the
>>>> specification of those methods.
>>>
>>> Would you suggest not interpreting extensions in this method? I am now
>>> inclined to just interpret locale extensions in the new suggested 
>>> method for
>>> the java.time package.
>>
>> Fundamentally, the tags you are processing are a problem for the
>> design of java.time formatters. The existing API is structured around
>> a narrow meaning of Locale for text input/output within the formatting
>> API.
>>
>> Changing the behaviour of DateTimeFormatterBuilder.toFormatter(...)
>> methods could have some odd effects for end-user code. Where they are
>> currently just expecting the locale to be set to control text
>> input/output, it would suddenly affect the calendar system and
>> time-zone, which could break code/compatibility in certain cases.
> 
> I've decided to retract changes in 
> DateTimeFormatter/DateTimeFormatterBuilder currently in the webrev, with 
> adding some text noting Unicode extensions are ignored in those methods.
> 
>>
>> I think that its OK to use the unicode tags in places like
>> WeekFields.of() or Chronology.of(). But for formatting, the change in
>> meaning is too great. Adding a single method (name TBD) makes more
>> sense
> Will keep the changes in WeekFields.of()/Chronology.of()
> 
>>
>> There is a case to add ZoneId.ofLocale(Locale) to match
>> Chronology.ofLocale(Locale). However, the expectation would be that it
>> figures out a suitable time-zone for the country/region as well as
>> considering the -u-tz- tag, and I don't think you've got that data
>> available at present (but it would make a good follow on change).
> 
> Yes, we don't yet have that mechanism to derive time zone based on the 
> region. I think that's out of this JEP's scope.
> 
> Naoto

From Roger.Riggs at Oracle.com  Wed Nov 15 22:06:41 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 15 Nov 2017 17:06:41 -0500
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <3c3c8b89-9a47-9df4-61b8-cdb59850d88e@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <CACzrW9C+GekWNRdWVi1AhVs_CiPgWksde-6iRT1Z68-RhkziZw@mail.gmail.com>
 <098fb447-9d89-2d2d-20a8-06b85d128020@oracle.com>
 <CACzrW9CbB9TOto1UgNmiFfN7pB8D7gKVQBb89t1x_J20NoGpMg@mail.gmail.com>
 <1a518134-57a5-6ac9-40eb-c948b15b88b9@oracle.com>
 <3c3c8b89-9a47-9df4-61b8-cdb59850d88e@oracle.com>
Message-ID: <34441778-1df2-259f-2d7a-8143f37650d8@Oracle.com>

Hi Naoto,

- The word "designated" is unnecessary and inconsistent with the rest of 
the java.time API doc.
 ?? "designated locale" -> "locale"
 ??? I would have written: "Unicode extensions in the locale are ignored."

- localizedBy(Locale):
 ? The first sentence should be more specific.
 ?? " Returns a copy of this formatter with localized values of the 
locale, calendar, region and/or timezone, that supercede values in this 
formatter."
 ?? to make it clearer that is is not a simple Locale substitution.
 ? And update the @return to say the same

 ? I would omit the example, to avoid the reader puzzling over what it 
is that is changed.? Or update the comment
 ? to reinforce the point that the values are replaced when the 
formatter is copied.

$.02, Roger


On 11/15/2017 4:18 PM, Naoto Sato wrote:
> Here is the proposed spec changes:
>
> http://cr.openjdk.java.net/~naoto/8191349/specdiff.00/overview-summary.html 
>
>
> Naoto
>
>
> On 11/15/17 10:06 AM, Naoto Sato wrote:
>> On 11/14/17 4:44 PM, Stephen Colebourne wrote:
>>> On 14 November 2017 at 23:58, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>> So even with the new suggested method,
>>>>
>>>> formatter.withZone(locale).withLocalization(locale)
>>>> formatter.withLocalization(locale).withZone(locale)
>>>>
>>>> would produce different formatters. Would it be OK, assuming along 
>>>> with some
>>>> proper documentation?
>>>
>>> Thats why I suggested perhaps a different method name is needed, not
>>> withXxx() to highlight the larger impact. eg. localizedBy(Locale)
>>
>> OK. Will come up with a draft. Essentially what the new method does 
>> is what withLocale() does, plus replacing fields specified with 
>> Unicode extensions (calendar/timezone/region override)
>>
>>>
>>>>> DateTimeFormatterBuilder.toFormatter(Locale, ResolverStyle,
>>>>> Chronology) has new logic to override the chronology. But this method
>>>>> is used indirectly from ofLocalizedTime() and friends which require
>>>>> the output to be ISO chronology. Thus the webrev would break the
>>>>> specification of those methods.
>>>>
>>>> Would you suggest not interpreting extensions in this method? I am now
>>>> inclined to just interpret locale extensions in the new suggested 
>>>> method for
>>>> the java.time package.
>>>
>>> Fundamentally, the tags you are processing are a problem for the
>>> design of java.time formatters. The existing API is structured around
>>> a narrow meaning of Locale for text input/output within the formatting
>>> API.
>>>
>>> Changing the behaviour of DateTimeFormatterBuilder.toFormatter(...)
>>> methods could have some odd effects for end-user code. Where they are
>>> currently just expecting the locale to be set to control text
>>> input/output, it would suddenly affect the calendar system and
>>> time-zone, which could break code/compatibility in certain cases.
>>
>> I've decided to retract changes in 
>> DateTimeFormatter/DateTimeFormatterBuilder currently in the webrev, 
>> with adding some text noting Unicode extensions are ignored in those 
>> methods.
>>
>>>
>>> I think that its OK to use the unicode tags in places like
>>> WeekFields.of() or Chronology.of(). But for formatting, the change in
>>> meaning is too great. Adding a single method (name TBD) makes more
>>> sense
>> Will keep the changes in WeekFields.of()/Chronology.of()
>>
>>>
>>> There is a case to add ZoneId.ofLocale(Locale) to match
>>> Chronology.ofLocale(Locale). However, the expectation would be that it
>>> figures out a suitable time-zone for the country/region as well as
>>> considering the -u-tz- tag, and I don't think you've got that data
>>> available at present (but it would make a good follow on change).
>>
>> Yes, we don't yet have that mechanism to derive time zone based on 
>> the region. I think that's out of this JEP's scope.
>>
>> Naoto


From naoto.sato at oracle.com  Wed Nov 15 22:36:21 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 15 Nov 2017 14:36:21 -0800
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <34441778-1df2-259f-2d7a-8143f37650d8@Oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <CACzrW9C+GekWNRdWVi1AhVs_CiPgWksde-6iRT1Z68-RhkziZw@mail.gmail.com>
 <098fb447-9d89-2d2d-20a8-06b85d128020@oracle.com>
 <CACzrW9CbB9TOto1UgNmiFfN7pB8D7gKVQBb89t1x_J20NoGpMg@mail.gmail.com>
 <1a518134-57a5-6ac9-40eb-c948b15b88b9@oracle.com>
 <3c3c8b89-9a47-9df4-61b8-cdb59850d88e@oracle.com>
 <34441778-1df2-259f-2d7a-8143f37650d8@Oracle.com>
Message-ID: <15a5bd09-a811-0ee2-9ef5-e48672a70c02@oracle.com>

Thanks, Roger. Updated the specdiff as suggested:

http://cr.openjdk.java.net/~naoto/8191349/specdiff.01/overview-summary.html

Naoto

On 11/15/17 2:06 PM, Roger Riggs wrote:
> Hi Naoto,
> 
> - The word "designated" is unnecessary and inconsistent with the rest of 
> the java.time API doc.
>  ?? "designated locale" -> "locale"
>  ??? I would have written: "Unicode extensions in the locale are ignored."
> 
> - localizedBy(Locale):
>  ? The first sentence should be more specific.
>  ?? " Returns a copy of this formatter with localized values of the 
> locale, calendar, region and/or timezone, that supercede values in this 
> formatter."
>  ?? to make it clearer that is is not a simple Locale substitution.
>  ? And update the @return to say the same
> 
>  ? I would omit the example, to avoid the reader puzzling over what it 
> is that is changed.? Or update the comment
>  ? to reinforce the point that the values are replaced when the 
> formatter is copied.
> 
> $.02, Roger
> 
> 
> On 11/15/2017 4:18 PM, Naoto Sato wrote:
>> Here is the proposed spec changes:
>>
>> http://cr.openjdk.java.net/~naoto/8191349/specdiff.00/overview-summary.html 
>>
>>
>> Naoto
>>
>>
>> On 11/15/17 10:06 AM, Naoto Sato wrote:
>>> On 11/14/17 4:44 PM, Stephen Colebourne wrote:
>>>> On 14 November 2017 at 23:58, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>>> So even with the new suggested method,
>>>>>
>>>>> formatter.withZone(locale).withLocalization(locale)
>>>>> formatter.withLocalization(locale).withZone(locale)
>>>>>
>>>>> would produce different formatters. Would it be OK, assuming along 
>>>>> with some
>>>>> proper documentation?
>>>>
>>>> Thats why I suggested perhaps a different method name is needed, not
>>>> withXxx() to highlight the larger impact. eg. localizedBy(Locale)
>>>
>>> OK. Will come up with a draft. Essentially what the new method does 
>>> is what withLocale() does, plus replacing fields specified with 
>>> Unicode extensions (calendar/timezone/region override)
>>>
>>>>
>>>>>> DateTimeFormatterBuilder.toFormatter(Locale, ResolverStyle,
>>>>>> Chronology) has new logic to override the chronology. But this method
>>>>>> is used indirectly from ofLocalizedTime() and friends which require
>>>>>> the output to be ISO chronology. Thus the webrev would break the
>>>>>> specification of those methods.
>>>>>
>>>>> Would you suggest not interpreting extensions in this method? I am now
>>>>> inclined to just interpret locale extensions in the new suggested 
>>>>> method for
>>>>> the java.time package.
>>>>
>>>> Fundamentally, the tags you are processing are a problem for the
>>>> design of java.time formatters. The existing API is structured around
>>>> a narrow meaning of Locale for text input/output within the formatting
>>>> API.
>>>>
>>>> Changing the behaviour of DateTimeFormatterBuilder.toFormatter(...)
>>>> methods could have some odd effects for end-user code. Where they are
>>>> currently just expecting the locale to be set to control text
>>>> input/output, it would suddenly affect the calendar system and
>>>> time-zone, which could break code/compatibility in certain cases.
>>>
>>> I've decided to retract changes in 
>>> DateTimeFormatter/DateTimeFormatterBuilder currently in the webrev, 
>>> with adding some text noting Unicode extensions are ignored in those 
>>> methods.
>>>
>>>>
>>>> I think that its OK to use the unicode tags in places like
>>>> WeekFields.of() or Chronology.of(). But for formatting, the change in
>>>> meaning is too great. Adding a single method (name TBD) makes more
>>>> sense
>>> Will keep the changes in WeekFields.of()/Chronology.of()
>>>
>>>>
>>>> There is a case to add ZoneId.ofLocale(Locale) to match
>>>> Chronology.ofLocale(Locale). However, the expectation would be that it
>>>> figures out a suitable time-zone for the country/region as well as
>>>> considering the -u-tz- tag, and I don't think you've got that data
>>>> available at present (but it would make a good follow on change).
>>>
>>> Yes, we don't yet have that mechanism to derive time zone based on 
>>> the region. I think that's out of this JEP's scope.
>>>
>>> Naoto
> 

From lance.andersen at oracle.com  Wed Nov 15 23:06:11 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 15 Nov 2017 18:06:11 -0500
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <15a5bd09-a811-0ee2-9ef5-e48672a70c02@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <CACzrW9C+GekWNRdWVi1AhVs_CiPgWksde-6iRT1Z68-RhkziZw@mail.gmail.com>
 <098fb447-9d89-2d2d-20a8-06b85d128020@oracle.com>
 <CACzrW9CbB9TOto1UgNmiFfN7pB8D7gKVQBb89t1x_J20NoGpMg@mail.gmail.com>
 <1a518134-57a5-6ac9-40eb-c948b15b88b9@oracle.com>
 <3c3c8b89-9a47-9df4-61b8-cdb59850d88e@oracle.com>
 <34441778-1df2-259f-2d7a-8143f37650d8@Oracle.com>
 <15a5bd09-a811-0ee2-9ef5-e48672a70c02@oracle.com>
Message-ID: <9ECB04EF-B9ED-4913-AF69-EB383783F6B7@oracle.com>

Hi Naoto

localizedBy, i would suggest changing:

-   ?If the new locale contains ?ca???  to ?if the new locale contains the ?ca???
- ?Unlike withLocale method? to Unlike the withLocale method?

Best
Lance
> On Nov 15, 2017, at 5:36 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~naoto/8191349/specdiff.01/overview-summary.html <http://cr.openjdk.java.net/~naoto/8191349/specdiff.01/overview-summary.html>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From naoto.sato at oracle.com  Wed Nov 15 23:31:08 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 15 Nov 2017 15:31:08 -0800
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <9ECB04EF-B9ED-4913-AF69-EB383783F6B7@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <CACzrW9C+GekWNRdWVi1AhVs_CiPgWksde-6iRT1Z68-RhkziZw@mail.gmail.com>
 <098fb447-9d89-2d2d-20a8-06b85d128020@oracle.com>
 <CACzrW9CbB9TOto1UgNmiFfN7pB8D7gKVQBb89t1x_J20NoGpMg@mail.gmail.com>
 <1a518134-57a5-6ac9-40eb-c948b15b88b9@oracle.com>
 <3c3c8b89-9a47-9df4-61b8-cdb59850d88e@oracle.com>
 <34441778-1df2-259f-2d7a-8143f37650d8@Oracle.com>
 <15a5bd09-a811-0ee2-9ef5-e48672a70c02@oracle.com>
 <9ECB04EF-B9ED-4913-AF69-EB383783F6B7@oracle.com>
Message-ID: <7b90a838-b5bd-5483-8ec8-a183c44b2c82@oracle.com>

Thanks, Lance. Corrected as suggested.

http://cr.openjdk.java.net/~naoto/8191349/specdiff.02/overview-summary.html

Also, I inserted "@since 10."

Naoto

On 11/15/17 3:06 PM, Lance Andersen wrote:
> Hi Naoto
> 
> localizedBy, i would suggest changing:
> 
> - ? ?If the new locale contains ?ca??? ?to ?if the new locale contains 
> the ?ca???
> - ?Unlike withLocale method? to Unlike the withLocale method?
> 
> Best
> Lance
>> On Nov 15, 2017, at 5:36 PM, Naoto Sato <naoto.sato at oracle.com 
>> <mailto:naoto.sato at oracle.com>> wrote:
>>
>> http://cr.openjdk.java.net/~naoto/8191349/specdiff.01/overview-summary.html
> 
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| 
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> 
> 
> 

From stuart.marks at oracle.com  Thu Nov 16 06:35:15 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 15 Nov 2017 22:35:15 -0800
Subject: Collections.emptyList().sort() does nothing
In-Reply-To: <CAE+3fjYhx1jwTyudEM3sEed9qtNap0-2xppvJ-b9AWZWJyamNw@mail.gmail.com>
References: <CAE+3fjYhx1jwTyudEM3sEed9qtNap0-2xppvJ-b9AWZWJyamNw@mail.gmail.com>
Message-ID: <b6a50951-ab8f-b35b-0853-eaf260fc8476@oracle.com>



On 11/14/17 7:52 PM, Tagir Valeev wrote:
> According to `List.sort` specification [1] "This list must be modifiable".
> According to `Collections.emptyList` specification [2] "Returns an
> empty list (immutable)."
> 
> So I assume that `List.sort` cannot be called on
> `Collections.emptyList` result. However in fact this call is allowed
> doing nothing. Is this behavior documented somehow? Can I rely that it
> will not change in future Java updates?
> 
> It's even more strange with `Collections.singletonList` [3] which
> "Returns an immutable list containing only the specified object".
> ...
> To me it seems that emptyList and (especially) singletonList
> implementation does not follow the specification. Am I missing
> something?

Hi Tagir,

This is indeed an inconsistency. As Martin noted, different maintainers of the 
collections framework took different approaches on how strict to be in these cases.

Note also that

     Collections.emptyList().addAll(List.of())

is a no-op, whereas

     Collections.unmodifiableList(new ArrayList<String>()).addAll(List.of())
     List.of().addAll(List.of())

both throw UnsupportedOperationException.

The issue is whether a collection that considers itself unmodifiable allows 
mutator methods to be called, if the operation wouldn't actually make a change 
(lenient); or if it unconditionally throws UOE even if the operation wouldn't 
actually make a change (strict).

The Collections.unmodifiableX implementations are strict, as are the new 
List.of/Set.of/Map.of implementations I added in JDK 9.

As you've noticed, certain special-case collections like Collections.emptyList() 
and singletonList() are described as "immutable" (really, unmodifiable), but 
they are lenient. While this isn't guaranteed by the spec, changing these at 
this point would be a behavioral incompatibility, so we're unlikely ever to 
change them.

My view is that it's preferable for collections implementations to be strict. If 
I'm handing out an unmodifiable List, it should always be illegal for the callee 
to attempt to sort it, even if it has zero or one elements.

s'marks


From amaembo at gmail.com  Thu Nov 16 07:52:32 2017
From: amaembo at gmail.com (Tagir Valeev)
Date: Thu, 16 Nov 2017 14:52:32 +0700
Subject: Collections.emptyList().sort() does nothing
In-Reply-To: <b6a50951-ab8f-b35b-0853-eaf260fc8476@oracle.com>
References: <CAE+3fjYhx1jwTyudEM3sEed9qtNap0-2xppvJ-b9AWZWJyamNw@mail.gmail.com>
 <b6a50951-ab8f-b35b-0853-eaf260fc8476@oracle.com>
Message-ID: <CAE+3fjbDrf82zo-t_oTFueV=PWM0W7DJbe0Dk0h2REhPu9sjUg@mail.gmail.com>

Hello!

> My view is that it's preferable for collections implementations to be
> strict. If I'm handing out an unmodifiable List, it should always be illegal
> for the callee to attempt to sort it, even if it has zero or one elements.

Thank you, this totally makes sence.

> While this isn't guaranteed by the spec, changing these at this point would be a behavioral incompatibility, so we're unlikely ever to change them.

But this behavior will not be specified as well, right?

With best regards,
Tagir Valeev.

From sshamaia at in.ibm.com  Thu Nov 16 09:23:02 2017
From: sshamaia at in.ibm.com (Srividya Shamaiah)
Date: Thu, 16 Nov 2017 14:53:02 +0530
Subject: JDK-8190919 :StaX buffers do not really close underlying buffers
Message-ID: <OFB7DBF29B.579C5B61-ON002581DA.003361BA-652581DA.00338C1A@notes.na.collabserv.com>



Hello,

Am not sure to which mailing-list, I can send issues related to xml-jaxp. I
found couple of xml-jaxp issues discussed in this mailing-list. Hence, am
sending to this group. Please let me know the correct mailing-list if this
is not the right one.

I had a brief analysis on?the subject?issue and identified?that the StaX
buffers were?not closed as the?close method implemented for XMLStreamWriter
in ?XMLStreamWriterImpl.java does not call the close on the underlying
writer and instead calls?only flush() ?on the writer.

Interestingly the close call was in fact coded but?commented out. We looked
into the history of?XMLStreamWriterImpl.java and found that the same code
exists from Java 6 GA or even before. Hence, we could not find the bug
which really introduced/commented out the close call.

I tested with close uncommented and it resolve the issue. I did not run the
jtreg and other tests as I could see that ?the bug?is already assigned
to?Joe Wang.

@Joe, please let me know whether you will continue with the analysis or you
want me to do other tests and contribute the patch.

With Thanks and Regards,
Srividya S

From Alan.Bateman at oracle.com  Thu Nov 16 09:46:25 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 16 Nov 2017 09:46:25 +0000
Subject: JDK-8190919 :StaX buffers do not really close underlying buffers
In-Reply-To: <OFB7DBF29B.579C5B61-ON002581DA.003361BA-652581DA.00338C1A@notes.na.collabserv.com>
References: <OFB7DBF29B.579C5B61-ON002581DA.003361BA-652581DA.00338C1A@notes.na.collabserv.com>
Message-ID: <93d8dc9a-9815-46a6-6342-d43028ac46bd@oracle.com>

On 16/11/2017 09:23, Srividya Shamaiah wrote:
>
> Hello,
>
> Am not sure to which mailing-list, I can send issues related to xml-jaxp. I
> found couple of xml-jaxp issues discussed in this mailing-list. Hence, am
> sending to this group. Please let me know the correct mailing-list if this
> is not the right one.
>
> I had a brief analysis on?the subject?issue and identified?that the StaX
> buffers were?not closed as the?close method implemented for XMLStreamWriter
> in ?XMLStreamWriterImpl.java does not call the close on the underlying
> writer and instead calls?only flush() ?on the writer.
>
> Interestingly the close call was in fact coded but?commented out. We looked
> into the history of?XMLStreamWriterImpl.java and found that the same code
> exists from Java 6 GA or even before. Hence, we could not find the bug
> which really introduced/commented out the close call.
>
There isn't a specific mailing list for XML issues so this mailing list 
is fine. I don't know the history of XMLStreamWriterImpl but its close 
implementation does look suspect.

-Alan.

From nishit.jain at oracle.com  Thu Nov 16 11:47:11 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Thu, 16 Nov 2017 17:17:11 +0530
Subject: [10] RFR 8191404: Upgrading JDK with latest available LSR data from
 IANA.
Message-ID: <38d7fa00-252f-cd42-500a-deda1fef843f@oracle.com>

Hi,

Please review the fix for JDK-8191404

Bug: https://bugs.openjdk.java.net/browse/JDK-8191404
Webrev: http://cr.openjdk.java.net/~nishjain/8191404/webrev.00/

Fix: Updated the LSR data with the version: 2017-08-15

Regards,
Nishit Jain

From piotr.findeisen at gmail.com  Thu Nov 16 12:49:12 2017
From: piotr.findeisen at gmail.com (Piotr Findeisen)
Date: Thu, 16 Nov 2017 13:49:12 +0100
Subject: Is Collections.sort(List) still stable (java 8, 9..)?
Message-ID: <CAPSxwTZ4RjkZuYZMn2hyAtRtMT8u+m7Rp36gDBozxZ6B9aydsg@mail.gmail.com>

Hi,

I just realised the Collections.sort(List) method ceased to be stable as of
Java 8 (sort of).

Although the method's documentation still promises stable sort, the
implementation delegates to List.sort(Comparator) and that interface method
bears no constraint that an implementation must sort stable.

Is "stable" missing from List.sort's documentation?
Or, instead, should it be now no longer promised by Collections.sort? (oh,
no!)
Or, what am i missing?

Best regards,
Piotr

From peter.levart at gmail.com  Thu Nov 16 13:55:22 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 16 Nov 2017 14:55:22 +0100
Subject: Collections.emptyList().sort() does nothing
In-Reply-To: <CAHjP37FBWkwb-oqVPyaW7BC63Qzofs7pkCcuYBbyXNeG2KQjgw@mail.gmail.com>
References: <CAE+3fjYhx1jwTyudEM3sEed9qtNap0-2xppvJ-b9AWZWJyamNw@mail.gmail.com>
 <CA+kOe0-xNkVgw0t2BFPLG3_xUg4+qV7qaqz0k_9oOOsws47N9Q@mail.gmail.com>
 <AM4PR08MB121989D338005EEF06C55628FF290@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <CAM6ZMz8Q-zVA+pgUYg5wkTe5RwGEYpAg4LA3Y=dJ1tYPB5cHnA@mail.gmail.com>
 <0a8735dd-be3b-0383-4315-3209e8ab8f71@redhat.com>
 <CAM6ZMz-AtyMnQE5_vwsGbwHmb7gSdHub5E8ugMQUr25eUggSOg@mail.gmail.com>
 <CAHjP37FBWkwb-oqVPyaW7BC63Qzofs7pkCcuYBbyXNeG2KQjgw@mail.gmail.com>
Message-ID: <51609f23-b4a0-bf22-a16b-6df4beabe8c3@gmail.com>

Hi,

On 11/15/2017 12:18 PM, Vitaly Davidovich wrote:
> On Wed, Nov 15, 2017 at 5:21 AM Andrej Golovnin <andrej.golovnin at gmail.com>
> wrote:
>
>>> On 15/11/17 10:03, Andrej Golovnin wrote:
>>>> I think we would need to write ugly code in any case as Java 9 has now
>>>> two empty list implementations: Collections.emptyList() and List.of().
>>>>
>>>> Collections.emptyList().sort() does not throw an exception.
>>>>
>>>> List.of().sort() throws an exception.
>>> Well, that's a bug.  Sorting an empty list is perfectly valid, and
>> application
>>> programmers shouldn't have to special-case it.
>> I don't think so. I would say that the implementation of
>> Collections.emptyList() is broken. Collections.emptyList() and
>> List.of() are not only empty lists. They are also immutable per
>> specification.
>>
>> Here is another example of an unsortable empty list:
>>
>> Collections.unmodifiableList(Collections.emptyList()).sort() throws an
>> exception.
> One can argue that since those are empty by construction/design, sorting
> them is not a bug.  That?s different from, say, trying to sort an
> unmodifiable list that happens to be empty and not failing in that case.
>
>  From a user?s perspective, I agree it?s annoying to have to special case
> these.  This is particularly so because immutability is not expressed in
> the types or type system.

There are 3 kinds of List(s) in JDK according to which optional methods 
are supported and which throw UOE:

A - normal mutable lists (ala ArrayList)
B - immutable/unmodifiable lists (ala Collections.unmodifiableList(...), 
List.of(...))
C - structurally unmodifiable mutable lists (ala Arrays.asList(...))

What is Collections.emptyList()? In terms of the original (as of jdk 1.2 
API), it can be either B or C. Additional (default) List methods added 
later may blur this distinction, but they can only do that "artificially".

Suppose that you have and API where you want to return List(s) of type C 
to the user, so that user may choose to consume them as-is or sort them 
1st in-place. What list would you return when you have 0 elements to 
return? Would you return Collections.emptyList() and instruct the user 
that he may not blindly sort any given List he gets, but only those that 
are not empty? Would you rather return Arrays.asList() and create new 
object every time? Why can't I have both?

Well, I can have both:

 ??? private static final List<T> EMPTY_LIST = Arrays.asList();

 ??? ...
 ??? return EMPTY_LIST;
}


But this is complicated and has to be done over and over again. It's 
like the story of empty array(s) that have to be declared as a private 
static final field in each and every class which wants to optimize empty 
returns.

Not to mention that changing Collections.emptyList().sort() to throw UOE 
is an incompatible change. Programs may already use emptyList() as kind 
C list and depend on it. So why would not Collections.emptyList() be 
simply declared to be of kind C and that's it. No code to change and no 
code to break. If one wants to get an empty list of type B, he should 
use List.of().

Regards, Peter

>
>>
>>> --
>>> Andrew Haley
>>> Java Platform Lead Engineer
>>> Red Hat UK Ltd. <https://www.redhat.com>
>>> EAC8 43EB D3EF DB98 C
>> <https://maps.google.com/?q=EF+DB98+C&entry=gmail&source=g>C77 2FAD A5CD
>> 6035 332F A671
>>


From dmitry.chuyko at bell-sw.com  Thu Nov 16 16:42:01 2017
From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko)
Date: Thu, 16 Nov 2017 19:42:01 +0300
Subject: RFR (S): JDK-8191328: Avoid unnecessary overhead in CRC32C
In-Reply-To: <1db026bf-b3eb-2ff6-8132-fbd31f881bbb@redhat.com>
References: <6f8d38e5-f609-e885-5990-945decbe6e9b@bell-sw.com>
 <0fd60794-b23a-1818-dea4-e72007f7cdd6@oracle.com>
 <67f55a91-2e9d-c401-c213-df93b62188c1@redhat.com>
 <CAHjP37Htvo-C7Q3PmCbujLbratwRJcYpB2puQikghjhWWzObfg@mail.gmail.com>
 <1db026bf-b3eb-2ff6-8132-fbd31f881bbb@redhat.com>
Message-ID: <991c7172-d46d-6ea2-73f1-d3ba3ac64811@bell-sw.com>

On 11/15/2017 09:44 PM, Andrew Haley wrote:
> On 15/11/17 18:38, Vitaly Davidovich wrote:
>> On Wed, Nov 15, 2017 at 12:40 PM, Andrew Haley <aph at redhat.com> wrote:
>>> On 15/11/17 15:38, Alan Bateman wrote:
>>>> Moving the nativeOrder out of the loop make sense but I'm curious about
>>>> the context for improving this implementation.
>>> I wonder about lifting ByteOrder.nativeOrder().  Maybe it fails to
>>> inline because the method is too large: if that happens, we really
>>> lose.  I'm not seeing that, though: it seems to be inlined just fine,
>>> and has no effect.
Sure, it is the effect of missing inlining. But you can relatively 
easily break it by your tiered JIT settings. Not sure about AOT. Like 
(in Hotspot):
-XX:-Inline, -XX:MaxInlineLevel=0 (no wonder to meet this one in wild), 
-XX:FreqInlineSize=3, -XX:InlineSmallCode=15..
>>>
>>> In any case, this patch doesn't help anything on my test hardware.
>> Is this with -Xcomp though? That can generate crap code because
>> there's no profiling information.  Not that -Xcomp should be the way
>> to test peak performance IMO, but that is the setting that was used I
>> believe.
Another noticeable case is -Xint where absolute times of CRC calculation 
are quite long.

Here is a benchmark that is easier to experiment with (no need to build 
jdk or to turn off intrinsics):

http://cr.openjdk.java.net/~dchuyko/8191328/CRC32CAltBench.java

Some x86 results:

default tiered
before? 380.957 ? 11.621? ns/op
after?? 350.838 ?? 5.149? ns/op

-XX:MaxInlineLevel=0
before? 656.791 ? 8.216? ns/op
after? 340.999 ? 2.686? ns/op

-Xint
before? 36113.441 ? 197.716? ns/op
after?? 26928.593 ? 133.309? ns/op

-Dmitry

> Shrug; maybe.  We shouldn't mess the code up for -Xcomp.
>


From paul.sandoz at oracle.com  Thu Nov 16 16:54:34 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 16 Nov 2017 08:54:34 -0800
Subject: Is Collections.sort(List) still stable (java 8, 9..)?
In-Reply-To: <CAPSxwTZ4RjkZuYZMn2hyAtRtMT8u+m7Rp36gDBozxZ6B9aydsg@mail.gmail.com>
References: <CAPSxwTZ4RjkZuYZMn2hyAtRtMT8u+m7Rp36gDBozxZ6B9aydsg@mail.gmail.com>
Message-ID: <AD09B73F-013D-4CD5-B59C-81DF7F53C40B@oracle.com>

Hi Piotr,

In Java 9 we moved some documentation from Collectors.sort(List ) to List.sort, then back ported it. For more details see https://bugs.openjdk.java.net/browse/JDK-8030848 <https://bugs.openjdk.java.net/browse/JDK-8030848>

On List.sort:

* @implNote
* This implementation is a stable, adaptive, iterative mergesort that
* requires far fewer than n lg(n) comparisons when the input array is
* partially sorted, while offering the performance of a traditional
* mergesort when the input array is randomly ordered.  If the input array
* is nearly sorted, the implementation requires approximately n
* comparisons.  Temporary storage requirements vary from a small constant
* for nearly sorted input arrays to n/2 object references for randomly
* ordered input arrays.

Overall specification has not changed with regards to stable sorting.


> On 16 Nov 2017, at 04:49, Piotr Findeisen <piotr.findeisen at gmail.com> wrote:
> 
> Hi,
> 
> I just realised the Collections.sort(List) method ceased to be stable as of
> Java 8 (sort of).
> 

Do you have a specific bug or are you unsure with regards to the specification?

Paul.

> Although the method's documentation still promises stable sort, the
> implementation delegates to List.sort(Comparator) and that interface method
> bears no constraint that an implementation must sort stable.
> 
> Is "stable" missing from List.sort's documentation?
> Or, instead, should it be now no longer promised by Collections.sort? (oh,
> no!)
> Or, what am i missing?
> 
> Best regards,
> Piotr


From alexandre.iline at oracle.com  Thu Nov 16 17:20:01 2017
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Thu, 16 Nov 2017 09:20:01 -0800
Subject: RFR 8176838: Remove :compact1, :compact2. :compact3, :needs_jre test
 groups.
Message-ID: <70B3F2D1-B1D4-4DFA-A173-A2C42FBDBBE4@oracle.com>

Hi.

Please take a look on suggested change of removing obsolete test groups.

Bug: https://bugs.openjdk.java.net/browse/JDK-8176838
Webrev: http://cr.openjdk.java.net/~shurailine/8176838/webrev.01

Thank you

Shura

From huizhe.wang at oracle.com  Thu Nov 16 17:23:42 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 16 Nov 2017 09:23:42 -0800
Subject: JDK-8190919 :StaX buffers do not really close underlying buffers
In-Reply-To: <OFB7DBF29B.579C5B61-ON002581DA.003361BA-652581DA.00338C1A@notes.na.collabserv.com>
References: <OFB7DBF29B.579C5B61-ON002581DA.003361BA-652581DA.00338C1A@notes.na.collabserv.com>
Message-ID: <dde7d57a-9234-bc2a-c2b2-3d35f8c5c9af@oracle.com>

Hi Srividya,

There had been for and against XMLStreamWriter/Reader closing the 
underlying stream, about 10 years ago, both had use cases. There is a 
legitimate argument that the XML writer/reader shall be consistent with 
java.io. Unfortunately, the later (not closing) won because that's 
indeed what the spec? (JSR 173 1.0) required: "This must not close the 
underlying output stream." [1]?? Given the spec, I'll close the bug 
(8190919) as not-an-issue.

[1] 
https://docs.oracle.com/javase/8/docs/api/javax/xml/stream/XMLStreamWriter.html#close--

Regards,
Joe

On 11/16/2017 1:23 AM, Srividya Shamaiah wrote:
>
> Hello,
>
> Am not sure to which mailing-list, I can send issues related to xml-jaxp. I
> found couple of xml-jaxp issues discussed in this mailing-list. Hence, am
> sending to this group. Please let me know the correct mailing-list if this
> is not the right one.
>
> I had a brief analysis on?the subject?issue and identified?that the StaX
> buffers were?not closed as the?close method implemented for XMLStreamWriter
> in ?XMLStreamWriterImpl.java does not call the close on the underlying
> writer and instead calls?only flush() ?on the writer.
>
> Interestingly the close call was in fact coded but?commented out. We looked
> into the history of?XMLStreamWriterImpl.java and found that the same code
> exists from Java 6 GA or even before. Hence, we could not find the bug
> which really introduced/commented out the close call.
>
> I tested with close uncommented and it resolve the issue. I did not run the
> jtreg and other tests as I could see that ?the bug?is already assigned
> to?Joe Wang.
>
> @Joe, please let me know whether you will continue with the analysis or you
> want me to do other tests and contribute the patch.
>
> With Thanks and Regards,
> Srividya S


From piotr.findeisen at gmail.com  Thu Nov 16 17:28:54 2017
From: piotr.findeisen at gmail.com (Piotr Findeisen)
Date: Thu, 16 Nov 2017 18:28:54 +0100
Subject: Is Collections.sort(List) still stable (java 8, 9..)?
In-Reply-To: <AD09B73F-013D-4CD5-B59C-81DF7F53C40B@oracle.com>
References: <CAPSxwTZ4RjkZuYZMn2hyAtRtMT8u+m7Rp36gDBozxZ6B9aydsg@mail.gmail.com>
 <AD09B73F-013D-4CD5-B59C-81DF7F53C40B@oracle.com>
Message-ID: <CAPSxwTanSv0EOsmJy005P-sjL_gq32DNZFvHTYdn7c586FT+hw@mail.gmail.com>

Hi Paul,

I think this is also how it looks like in Java 8 (but I also checked docs &
code in 9 before posting).
Basically, in List.sort docs, the word "stable" is @implNote for *default
implementation*, not a contract that a subclass implementor must obey.
At least I understand this that way.

Thus, for List not having specialised sort implementation,
Collections.sort(List) will be stable sort.
For a List that has specialised sort implementation (that happens not to be
stable),  Collections.sort(List)  will not be stable as well, even though
javadoc expressly promises that.

Best regards,
Piotr




On Thu, Nov 16, 2017 at 5:54 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi Piotr,
>
> In Java 9 we moved some documentation from Collectors.sort(List ) to
> List.sort, then back ported it. For more details see
> https://bugs.openjdk.java.net/browse/JDK-8030848
>
> On List.sort:
>
> * @implNote
> * This implementation is a stable, adaptive, iterative mergesort that
> * requires far fewer than n lg(n) comparisons when the input array is
> * partially sorted, while offering the performance of a traditional
> * mergesort when the input array is randomly ordered.  If the input array
> * is nearly sorted, the implementation requires approximately n
> * comparisons.  Temporary storage requirements vary from a small constant
> * for nearly sorted input arrays to n/2 object references for randomly
> * ordered input arrays.
>
>
> Overall specification has not changed with regards to stable sorting.
>
>
> On 16 Nov 2017, at 04:49, Piotr Findeisen <piotr.findeisen at gmail.com>
> wrote:
>
> Hi,
>
> I just realised the Collections.sort(List) method ceased to be stable as of
> Java 8 (sort of).
>
>
> Do you have a specific bug or are you unsure with regards to the
> specification?
>
> Paul.
>
> Although the method's documentation still promises stable sort, the
> implementation delegates to List.sort(Comparator) and that interface method
> bears no constraint that an implementation must sort stable.
>
> Is "stable" missing from List.sort's documentation?
>
> Or, instead, should it be now no longer promised by Collections.sort? (oh,
> no!)
> Or, what am i missing?
>
> Best regards,
> Piotr
>
>
>

From paul.sandoz at oracle.com  Thu Nov 16 17:56:00 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 16 Nov 2017 09:56:00 -0800
Subject: Is Collections.sort(List) still stable (java 8, 9..)?
In-Reply-To: <CAPSxwTanSv0EOsmJy005P-sjL_gq32DNZFvHTYdn7c586FT+hw@mail.gmail.com>
References: <CAPSxwTZ4RjkZuYZMn2hyAtRtMT8u+m7Rp36gDBozxZ6B9aydsg@mail.gmail.com>
 <AD09B73F-013D-4CD5-B59C-81DF7F53C40B@oracle.com>
 <CAPSxwTanSv0EOsmJy005P-sjL_gq32DNZFvHTYdn7c586FT+hw@mail.gmail.com>
Message-ID: <447DBCE4-DEB4-4268-A744-4F6CF536C7DF@oracle.com>



> On 16 Nov 2017, at 09:28, Piotr Findeisen <piotr.findeisen at gmail.com> wrote:
> 
> Hi Paul,
> 
> I think this is also how it looks like in Java 8

Yes.


> (but I also checked docs & code in 9 before posting).

Ok.


> Basically, in List.sort docs, the word "stable" is @implNote for *default implementation*, not a contract that a subclass implementor must obey.
> At least I understand this that way.
> 

Yes.


> Thus, for List not having specialised sort implementation, Collections.sort(List) will be stable sort.
> For a List that has specialised sort implementation (that happens not to be stable),  Collections.sort(List)  will not be stable as well, even though javadoc expressly promises that.
> 

Agreed, we need to specify the stability on List.sort (as we do for ordered streams on Stream.sorted).

I logged this issue:

  https://bugs.openjdk.java.net/browse/JDK-8191429 <https://bugs.openjdk.java.net/browse/JDK-8191429>

Thanks for reporting this,
Paul.

From huizhe.wang at oracle.com  Thu Nov 16 18:51:40 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 16 Nov 2017 10:51:40 -0800
Subject: RFR (JDK10/JAXP) 8191161: Reconsider generification of
 XPathFunction.evaluate
Message-ID: <eeaa81d0-866d-e784-fafb-42788537b3d3@oracle.com>

Hi,

Please review a quick catch-up fix on 8181150: the raw type List was 
changed to List<Object> when it would have been more favorable if? it 
was List<?>:

src/java.xml/share/classes/javax/xml/xpath/XPathFunction.java

|- public Object evaluate(List<Object> args) + public Object 
evaluate(List<?> args) JBS: 
https://bugs.openjdk.java.net/browse/JDK-8191161 Thanks, Joe |


From Roger.Riggs at Oracle.com  Thu Nov 16 18:58:02 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 16 Nov 2017 13:58:02 -0500
Subject: RFR (JDK10/JAXP) 8191161: Reconsider generification of
 XPathFunction.evaluate
In-Reply-To: <eeaa81d0-866d-e784-fafb-42788537b3d3@oracle.com>
References: <eeaa81d0-866d-e784-fafb-42788537b3d3@oracle.com>
Message-ID: <a4c90ea6-a8cd-6d2f-b59b-545d24e895ca@Oracle.com>

Hi Joe,

The html formatting got removed (don't use it in openjdk email) but if I 
read this correctly,
the change from List<Object> -> List<?> looks fine.

Roger


On 11/16/2017 1:51 PM, huizhe wang wrote:
> Hi,
>
> Please review a quick catch-up fix on 8181150: the raw type List was 
> changed to List<Object> when it would have been more favorable if? it 
> was List<?>:
>
> src/java.xml/share/classes/javax/xml/xpath/XPathFunction.java
>
> |- public Object evaluate(List<Object> args) + public Object 
> evaluate(List<?> args) JBS: 
> https://bugs.openjdk.java.net/browse/JDK-8191161 Thanks, Joe |
>


From lance.andersen at oracle.com  Thu Nov 16 19:00:08 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 16 Nov 2017 14:00:08 -0500
Subject: RFR (JDK10/JAXP) 8191161: Reconsider generification of
 XPathFunction.evaluate
In-Reply-To: <eeaa81d0-866d-e784-fafb-42788537b3d3@oracle.com>
References: <eeaa81d0-866d-e784-fafb-42788537b3d3@oracle.com>
Message-ID: <8B95DB3C-E305-409B-B9F7-3C48872FE740@oracle.com>

Hi Joe,

Yes  List<?>  makes sense


> On Nov 16, 2017, at 1:51 PM, huizhe wang <huizhe.wang at oracle.com> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8191161 <https://bugs.openjdk.java.net/browse/JDK-8191161>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From huizhe.wang at oracle.com  Thu Nov 16 19:04:27 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 16 Nov 2017 11:04:27 -0800
Subject: RFR (JDK10/JAXP) 8191161: Reconsider generification of
 XPathFunction.evaluate
In-Reply-To: <8B95DB3C-E305-409B-B9F7-3C48872FE740@oracle.com>
References: <eeaa81d0-866d-e784-fafb-42788537b3d3@oracle.com>
 <8B95DB3C-E305-409B-B9F7-3C48872FE740@oracle.com>
Message-ID: <e5492eca-22a8-455d-e8be-191e568104d3@oracle.com>

Thanks Lance, Roger!? Yep, it appeared that html formatting was only 
good in my mail editor.

-Joe

On 11/16/2017 11:00 AM, Lance Andersen wrote:
> Hi Joe,
>
> Yes ?List<?> ?makes sense
>
>
>> On Nov 16, 2017, at 1:51 PM, huizhe wang <huizhe.wang at oracle.com 
>> <mailto:huizhe.wang at oracle.com>> wrote:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8191161
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>


From paul.sandoz at oracle.com  Thu Nov 16 21:48:45 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 16 Nov 2017 13:48:45 -0800
Subject: RFR 8191429 List.sort should specify the sort is stable
Message-ID: <359BF55B-1752-475E-972E-86E61D314044@oracle.com>

Hi,

Please review the change in specification of List.sort to state the sort must be stable (CSR is already approved):

Thanks,
Paul.

diff -r e0041b182e31 src/java.base/share/classes/java/util/List.java
--- a/src/java.base/share/classes/java/util/List.java	Wed Nov 08 10:27:10 2017 -0800
+++ b/src/java.base/share/classes/java/util/List.java	Thu Nov 16 13:47:46 2017 -0800
@@ -442,7 +442,8 @@

     /**
      * Sorts this list according to the order induced by the specified
-     * {@link Comparator}.
+     * {@link Comparator}.  The sort is <i>stable</i>: this method must not
+     * reorder equal elements.
      *
      * <p>All elements in this list must be <i>mutually comparable</i> using the
      * specified comparator (that is, {@code c.compare(e1, e2)} must not throw

From claes.redestad at oracle.com  Thu Nov 16 23:54:44 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 17 Nov 2017 00:54:44 +0100
Subject: RFR(XS): 8191442: Regression in LambdaFormBuffer.replaceFunctions
Message-ID: <223be06a-aead-3ebf-1dc4-58ebcb24229f@oracle.com>

Hi,

in JDK-8184777, we accidentally changed behavior of replaceFunctions 
from testing
identity to testing equality, causing a small startup regression on some 
sensitive
benchmarks in the process[1].

Patch to salvage the recently orphaned helper function:

http://cr.openjdk.java.net/~redestad/8191442/open.00/

Thanks!

/Claes

[1] Made worse by https://bugs.openjdk.java.net/browse/JDK-8191418



From david.holmes at oracle.com  Fri Nov 17 02:17:52 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 17 Nov 2017 12:17:52 +1000
Subject: RFR 8176838: Remove :compact1, :compact2. :compact3, :needs_jre
 test groups.
In-Reply-To: <70B3F2D1-B1D4-4DFA-A173-A2C42FBDBBE4@oracle.com>
References: <70B3F2D1-B1D4-4DFA-A173-A2C42FBDBBE4@oracle.com>
Message-ID: <55756bd4-ce72-c24d-545f-38f71111ba90@oracle.com>

Hi Shura,

This looks fine.

Thanks,
David

On 17/11/2017 3:20 AM, Alexandre (Shura) Iline wrote:
> Hi.
> 
> Please take a look on suggested change of removing obsolete test groups.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8176838
> Webrev: http://cr.openjdk.java.net/~shurailine/8176838/webrev.01
> 
> Thank you
> 
> Shura
> 

From xueming.shen at oracle.com  Fri Nov 17 02:18:43 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 16 Nov 2017 18:18:43 -0800
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
Message-ID: <5A0E4703.3040409@oracle.com>

Hi,

Please help review the change for JDK-8189611.

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


Notes:

(1) To add three public methods to help iterating/streaming the 
versioned entries
for multi-release jar file support (CSR is to be filed)

JavaFile.versionedStream()
JavaFile.getRealName()
ZipFile.entryNameStream()
   -- a convenient method for use scenario that only the entry name is 
interested.

(2) To update jdk code( jlink, module, loader, where currently the 
internal/private
methods are used) to use the new public methods for "versionedStream()" and
"getRealName()" need. (jdeps is not being updated for now as it is now 
compiled
by boot jdk).

(3) To cleanup the way how the JarFileEntry and its corresponding 
versioned one
are searched and created. By pushing the JarFileEntry constructor into 
ZipFile via
SharedSecrets, we are now using much less memory (almost half) for 
JarFileEntry
creation and have a slightly faster iteration (around 10% by jmh simple 
benchmark).

(4) To add a fast-path in ZipCoder for UTF8 charset+ascii-only entry 
name. To
take the advantage of the compact String to remove the unnecessary 
char[] usage.
This is related to JDK-8184947: ZipCoder performance improvements

(5) Two snapshots of the JFR recording of the memory usages for simply 
looping the
JarFile.stream() on old rt.jar for 60s,  before and after the change of 
(3)/(4)

http://cr.openjdk.java.net/~sherman/8189611/mem_before.png
http://cr.openjdk.java.net/~sherman/8189611/mem_after.png

Thanks,
Sherman



From nishit.jain at oracle.com  Fri Nov 17 06:52:36 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Fri, 17 Nov 2017 12:22:36 +0530
Subject: [10] RFR 6354947: [Fmt-*] DecimalFormat ignores FieldPosition
 settings on input, contrary to Javadocs
Message-ID: <156741f0-36df-03cb-e30f-e2c41d0fc3ef@oracle.com>

Hi,

Please review the fix for JDK-6354947

Bug: https://bugs.openjdk.java.net/browse/JDK-6354947
Webrev: http://cr.openjdk.java.net/~nishjain/6354947/webrev.02/
CSR: https://bugs.openjdk.java.net/browse/JDK-8191014

Fix: Clarified handling of the FieldPosition settings in the 
java.text.Format APIs specification.

Regards,
Nishit Jain

From stuart.marks at oracle.com  Fri Nov 17 07:14:32 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 16 Nov 2017 23:14:32 -0800
Subject: Collections.emptyList().sort() does nothing
In-Reply-To: <CAE+3fjbDrf82zo-t_oTFueV=PWM0W7DJbe0Dk0h2REhPu9sjUg@mail.gmail.com>
References: <CAE+3fjYhx1jwTyudEM3sEed9qtNap0-2xppvJ-b9AWZWJyamNw@mail.gmail.com>
 <b6a50951-ab8f-b35b-0853-eaf260fc8476@oracle.com>
 <CAE+3fjbDrf82zo-t_oTFueV=PWM0W7DJbe0Dk0h2REhPu9sjUg@mail.gmail.com>
Message-ID: <1ba7a774-1e82-894f-6ece-72ee2731db5a@oracle.com>



On 11/15/17 11:52 PM, Tagir Valeev wrote:
>> While this isn't guaranteed by the spec, changing these at this point would be a behavioral incompatibility, so we're unlikely ever to change them.
> 
> But this behavior will not be specified as well, right?

I don't have any plans to change the docs to specify that these particular 
implementations allow calling a no-op mutator method (i.e., they do not throw an 
exception).

The Collection class specification allows for flexibility in how implementations 
deal with such cases. See the paragraph that begins ?The "destructive" 
methods....? My copyOf proposal, recently reviewed, rewords this somewhat but 
keeps this flexibility.

s'marks

From stuart.marks at oracle.com  Fri Nov 17 07:15:38 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 16 Nov 2017 23:15:38 -0800
Subject: RFR 8191429 List.sort should specify the sort is stable
In-Reply-To: <359BF55B-1752-475E-972E-86E61D314044@oracle.com>
References: <359BF55B-1752-475E-972E-86E61D314044@oracle.com>
Message-ID: <9c7ba9e3-ded0-bd73-a21b-582d9a4f006e@oracle.com>

Hi Paul,

The change looks good.

s'marks

On 11/16/17 1:48 PM, Paul Sandoz wrote:
> Hi,
> 
> Please review the change in specification of List.sort to state the sort must be stable (CSR is already approved):
> 
> Thanks,
> Paul.
> 
> diff -r e0041b182e31 src/java.base/share/classes/java/util/List.java
> --- a/src/java.base/share/classes/java/util/List.java	Wed Nov 08 10:27:10 2017 -0800
> +++ b/src/java.base/share/classes/java/util/List.java	Thu Nov 16 13:47:46 2017 -0800
> @@ -442,7 +442,8 @@
> 
>       /**
>        * Sorts this list according to the order induced by the specified
> -     * {@link Comparator}.
> +     * {@link Comparator}.  The sort is <i>stable</i>: this method must not
> +     * reorder equal elements.
>        *
>        * <p>All elements in this list must be <i>mutually comparable</i> using the
>        * specified comparator (that is, {@code c.compare(e1, e2)} must not throw
> 

From Alan.Bateman at oracle.com  Fri Nov 17 08:21:16 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 17 Nov 2017 08:21:16 +0000
Subject: RFR 8176838: Remove :compact1, :compact2. :compact3, :needs_jre
 test groups.
In-Reply-To: <70B3F2D1-B1D4-4DFA-A173-A2C42FBDBBE4@oracle.com>
References: <70B3F2D1-B1D4-4DFA-A173-A2C42FBDBBE4@oracle.com>
Message-ID: <39d8423c-8476-a9c1-547a-d480b17b0f3e@oracle.com>

On 16/11/2017 17:20, Alexandre (Shura) Iline wrote:
> Hi.
>
> Please take a look on suggested change of removing obsolete test groups.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8176838
> Webrev: http://cr.openjdk.java.net/~shurailine/8176838/webrev.01
>
Looks good (and great to see this going away as it was impossible to 
keep up to date).

-Alan

From bourges.laurent at gmail.com  Fri Nov 17 10:08:36 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 17 Nov 2017 11:08:36 +0100
Subject: Faster Math ?
In-Reply-To: <950a25aa-f9d8-6e7c-bce1-cd2a58bcf2c5@oracle.com>
References: <CAKjRUT7V1swPZJkEJKOtde-vZQgvAOg=_=uA-e9t+Z+QySMoVQ@mail.gmail.com>
 <CAKjRUT4j-R60NpCmEcs+x5-whmobyvBcAHSqecaH6PFG_NzaZA@mail.gmail.com>
 <CAKjRUT46GRnUqNgD-s81z_qYd0-_Rj-VQUgtVsMSUMKfHqJOxw@mail.gmail.com>
 <CAKjRUT5Ltn=4URTR2NXDgFis=b9s6e2TJS-FCK5qqqeyAXswuA@mail.gmail.com>
 <CAKjRUT7XkZevTau--k8avcUX6KE_bZmgRwJaGSx-2rt=Nz-4=Q@mail.gmail.com>
 <CAKjRUT668ng+Xh08a4VzJt4vPceuQp4VyOuRF2X=nZK+R4RHzw@mail.gmail.com>
 <CAKjRUT7K0evbnjY0ixzhMB54MEXiJxCkW4es_C1vLJ-hWywCaA@mail.gmail.com>
 <CAKjRUT6sbq8GoPLfZUtirvSX7okWSW+xOQ5B=rggOkYJ889PYQ@mail.gmail.com>
 <CAKjRUT48TpyU8XgHNewSu7Vt_GKMOS3-D7sKa6VuGTiNPERaSA@mail.gmail.com>
 <CAKjRUT6i8iSF07USPhY=jTPU5dc4g7rNn9WuA+DHRQioMS=1og@mail.gmail.com>
 <CAKjRUT4ezaSE5mPMNfXQaQfgu+3Y34+O1yBTvnbJ6Rmv+mkUyw@mail.gmail.com>
 <CAKjRUT4iFEZ1p-OLYAOiyKVmiTGLSPN0-HJVRwLGboxqgv4xkA@mail.gmail.com>
 <CAKjRUT4mYpifFvxa7anKQTfZ4vCjPqVhykm_LMwzOGkNCLmt9A@mail.gmail.com>
 <06AB6270-7489-41CE-B82F-668C582C9D41@oracle.com>
 <950a25aa-f9d8-6e7c-bce1-cd2a58bcf2c5@oracle.com>
Message-ID: <CAKjRUT74Mdj7i8WA3mm3nuvZBNtOF+C06SZf6abfFtQM2m_Nmg@mail.gmail.com>

Hello,

Some context first:
- Marlin renderer is now the default JDK & JFX renderer. Please consider
improving the performance of following 2 Math functions: cbrt, acos.
- I work for the public research in astrophysics by making software for
astronomy as java desktop apps (javaws + scientific computations) see
http://jmmc.fr . It is hard to promote Java in science as both Python &
Julia languages are wide spread.

Please consider any change making Java more competitive for Science:
- faster math, more math functions (matrix & vector API), FFT, GPU
computing... the Panama project is very important to me
- struct (value type) & Friend interface (fast native lib reuse) are
promising features ... Vahalla ?

Now I answer below:

Thanks for your feedback



As Paul noted, a portion of fdlibm has been ported from C to Java. I do
intend to finish the port at some point. The port gives an implementation
speedup by avoiding Java -> C -> Java transition overheads. However, the
same algorithms are being used of course.

The fdlibm code was first written several decades ago and there has been
work in the interim on developing other algorithms for math libraries. One
significant effort has focused on correctly rounded libraries, that is,
libraries that have full floating-point accuracy. In particular Jean-Michel
Muller and his students and collaborators have worked in this area and
produce the crlibm package. If a specification for a StrictMath-style class
were newly written today, I would recommend it be specified to be correctly
rounded. Correct rounding is conceptually the "best" answer and it does not
require the exact implementation algorithms to be specified to achieve
reproducibility, unlike fdlibm.


Accuracy is important but what is the cost ? Java has 2 Math
implementations: Math & StrictMath... but also the strictfp keyword.

So the Math class is the JDK fast math... compared to StrictMath.
Maybe it could give results less accurate: 1 or 2 last digits ... maybe 10
or 100 ulps ?


However, the extra precise answer can come at the cost of extra time or
space for the computation in some cases.

The notion of a "FastMath" library has been considered before (as well as
the faster underlying numerics [1]). As also discussed earlier in the
thread, specifying what degrees of inaccuracy is acceptable for what speed
is non-obvious. (And offhand I don't know the error bounds of the other
implementations being discussed.)


Please look JaFaMa @ github whose FastMath gives correct results at 1e-15
precision and is very fast.

I will give you my benchmark results on jdk9...


Working with Intel in OpenJDK, we are using optimized math library
implementations for x64 for many interesting methods. For most math library
methods, the trend has been to move to software-based implementations
rather than having specialized hardware instructions. (Functionality like
reciprocal square root is a counter-example, but we don't have that method
in the Java math library.)


Please port all maths in java first, delete fdlibm native code and later
make intrinsics for most used methods (any math used within jdk or jfx...)
Who could help ?


Note that since 1/3 is a repeating fraction in binary and decimal, pow(x,
1.0/3.0) is only approximately equivalent to cbrt(x).

Knowing which particular methods would be of interest for fast-but-loose
math would be helpful. The sqrt method has long been intrinsified to the
corresponding hardware instruction on many platforms so I don't think that
would be a useful candidate in most circumstances.


Yes but no CBRT intrinsics ! It is important for our cubics curve solver.
ACOS / ASIN are still slow.
I could make the port... in java.


In short, we might get a selection of looser but faster math methods at
some point, but not immediately and not without more investigation.


Of course.

Cheers,
Laurent


[1] Forward looking statements during "Forward to the Past: The Case for
Uniformly Strict Floating Point Arithmetic on the JVM"
https://youtu.be/qTKeU_3rhk4?t=2513



On 11/9/2017 9:19 AM, Paul Sandoz wrote:

> Hi Laurent,
>
> A Java method is a candidate for intrinsification if it is annotated with
> @HotSpotIntrinsicCandidate. When running Java code you can also use the
> HotSpot flags -XX:+PrintCompilarion -XX:+PrintInlining to show methods that
> are intrinsic (JIT watch, as mentioned, is also excellent in this regard).
>
> I recommend cloning OpenJDK and browsing the source.
>
> Some of the math functions are intrinsic in the interpreter and all the
> runtime compilers to ensure consistent results across interpretation and
> compilation.
>
> Work was done by Intel to improve many of the math functions. See:
>
>    Update for x86 sin and cos in the math lib
>    https://bugs.openjdk.java.net/browse/JDK-8143353
>
>    Update for x86 pow in the math lib
>    https://bugs.openjdk.java.net/browse/JDK-8145688
>       (From these you can track related issues.)
>
> Other Math functions are not intrinsic like cbrt (non-native) and acos
> (native). There is ongoing work to turn native implementations into Java
> implementations (i don?t know if there would be any follow up on
> intrinsification).
>
>    https://bugs.openjdk.java.net/browse/JDK-8134780
>    https://bugs.openjdk.java.net/browse/JDK-8171407
>
> Joe knows more.
>
> ?
>
> As part of the Vector API effort we will likely need to investigate the
> support for less accurate but faster math functions. It?s too early to tell
> if something like a FastMath class will pop out of that, but FWIW i am
> sympathetic to that :-)
>
> I liked this tweet:
>
> https://twitter.com/FioraAeterna/status/926150700836405248
>
>    life as a gpu compiler dev is basically just fielding repeated
> complaints that
>    "fast math" isn't precise and "precise math" isn't fast
>
> as an indication of what we could be getting into :-)
>
> Paul.
>
> On 9 Nov 2017, at 01:00, Laurent Bourg?s <bourges.laurent at gmail.com>
>> wrote:
>>
>> Hi,
>>
>> The Marlin renderer (JEP265) uses few Math functions: sqrt, cbrt, acos...
>>
>> Could you check if the current JDK uses C2 intrinsics or libfdm (native /
>> JNI overhead?) and tell me if such functions are already highly optimized
>> in jdk9 or 10 ?
>>
>> Some people have implemented their own fast Math like Apache Commons Math
>> or JaFaMa libraries that are 10x faster for acos / cbrt.
>>
>> I wonder if I should implement my own cbrt function (cubics) in pure java
>> as I do not need the highest accuracy but SPEED.
>>
>> Would it sound possible to have a JDK FastMath public API (lots faster but
>> less accurate?)
>>
>> Do you know if recent CPU (intel?) have dedicated instructions for such
>> math operations ?
>> Why not use it instead?
>> Maybe that's part of the new Vectorization API (panama) ?
>>
>> Cheers,
>> Laurent Bourges
>>
>

From goetz.lindenmaier at sap.com  Fri Nov 17 11:23:04 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 17 Nov 2017 11:23:04 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
Message-ID: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>

Hi,

please review this change. I also filed a CSR for this:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
CSR: https://bugs.openjdk.java.net/browse/JDK-8191477

See the webrev for a detailed description of the changes.

If required, I'll make break-out changes to be reviewed separately.

I had posted a RFR before, but improved the change to 
give a more complete overview of currently supported flags
for the CSR:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html

Best regards,
  Goetz.


From Alan.Bateman at oracle.com  Fri Nov 17 11:35:14 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 17 Nov 2017 11:35:14 +0000
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
In-Reply-To: <5A0E4703.3040409@oracle.com>
References: <5A0E4703.3040409@oracle.com>
Message-ID: <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>

On 17/11/2017 02:18, Xueming Shen wrote:
> Hi,
>
> Please help review the change for JDK-8189611.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8189611
> webrev: http://cr.openjdk.java.net/~sherman/8189611/webrev
Just a few initial comments/questions on the API additions:

1. getRealName is very welcome but I think it should be a no-arg method 
on JarEntry, not JarFile. That would make it easier to use and also 
avoids the temptation to call JarFile.getRealName with an entry in a 
different JAR file.

2. JarFile.versionedStream() is very welcome too but the javadoc says 
"latest versioned entry" when it really means the highest version that 
is less than or equal to the runtime version that the JarFile was opened 
with. I suspect this one might take a few iterations to get the wording 
smooth.

3. Is ZipFile.entryNameStream really needed? Just asking because 
zf.stream().map(ZipEntry::getName) is possible today.

-Alan


From vladimir.x.ivanov at oracle.com  Fri Nov 17 12:52:39 2017
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 17 Nov 2017 15:52:39 +0300
Subject: RFR(XS): 8191442: Regression in LambdaFormBuffer.replaceFunctions
In-Reply-To: <223be06a-aead-3ebf-1dc4-58ebcb24229f@oracle.com>
References: <223be06a-aead-3ebf-1dc4-58ebcb24229f@oracle.com>
Message-ID: <bbdc1339-b895-7dda-73d5-2b3609db420c@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 11/17/17 2:54 AM, Claes Redestad wrote:
> Hi,
> 
> in JDK-8184777, we accidentally changed behavior of replaceFunctions 
> from testing
> identity to testing equality, causing a small startup regression on some 
> sensitive
> benchmarks in the process[1].
> 
> Patch to salvage the recently orphaned helper function:
> 
> http://cr.openjdk.java.net/~redestad/8191442/open.00/
> 
> Thanks!
> 
> /Claes
> 
> [1] Made worse by https://bugs.openjdk.java.net/browse/JDK-8191418
> 
> 

From claes.redestad at oracle.com  Fri Nov 17 14:41:33 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 17 Nov 2017 15:41:33 +0100
Subject: RFR(XS): 8191442: Regression in LambdaFormBuffer.replaceFunctions
In-Reply-To: <bbdc1339-b895-7dda-73d5-2b3609db420c@oracle.com>
References: <223be06a-aead-3ebf-1dc4-58ebcb24229f@oracle.com>
 <bbdc1339-b895-7dda-73d5-2b3609db420c@oracle.com>
Message-ID: <8a8ce00c-b099-7a19-1298-9f1c08342eb2@oracle.com>

Thanks for reviewing!

/Claes

On 2017-11-17 13:52, Vladimir Ivanov wrote:
> Looks good.
>
> Best regards,
> Vladimir Ivanov
>
> On 11/17/17 2:54 AM, Claes Redestad wrote:
>> Hi,
>>
>> in JDK-8184777, we accidentally changed behavior of replaceFunctions 
>> from testing
>> identity to testing equality, causing a small startup regression on 
>> some sensitive
>> benchmarks in the process[1].
>>
>> Patch to salvage the recently orphaned helper function:
>>
>> http://cr.openjdk.java.net/~redestad/8191442/open.00/
>>
>> Thanks!
>>
>> /Claes
>>
>> [1] Made worse by https://bugs.openjdk.java.net/browse/JDK-8191418
>>
>>


From xueming.shen at oracle.com  Fri Nov 17 16:53:19 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 17 Nov 2017 08:53:19 -0800
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
In-Reply-To: <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>
References: <5A0E4703.3040409@oracle.com>
 <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>
Message-ID: <5A0F13FF.8090406@oracle.com>

On 11/17/17, 3:35 AM, Alan Bateman wrote:
> On 17/11/2017 02:18, Xueming Shen wrote:
>> Hi,
>>
>> Please help review the change for JDK-8189611.
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8189611
>> webrev: http://cr.openjdk.java.net/~sherman/8189611/webrev
> Just a few initial comments/questions on the API additions:
>
> 1. getRealName is very welcome but I think it should be a no-arg 
> method on JarEntry, not JarFile. That would make it easier to use and 
> also avoids the temptation to call JarFile.getRealName with an entry 
> in a different JAR file.
>

I was considering to put it into JarEntry. The only concern is that all 
mr jarfile related stuff
are in JarFile, it's kinda easy/convenient to refer to the concept "if 
multi-release is..." in
JarFile than JarEntry, especially considering mr jarfile normally should 
only be interested/
used by limited group of developer, it might be better to simply put it 
near those mr related
methods. But I don't have a strong opinion about it. I can move it into 
JarEntry, if it's desired.


> 2. JarFile.versionedStream() is very welcome too but the javadoc says 
> "latest versioned entry" when it really means the highest version that 
> is less than or equal to the runtime version that the JarFile was 
> opened with. I suspect this one might take a few iterations to get the 
> wording smooth.

sure. will see if I can find better wording.
>
> 3. Is ZipFile.entryNameStream really needed? Just asking because 
> zf.stream().map(ZipEntry::getName) is possible today.
>
It's not a "must" for sure. The motivation behind this is that my 
observation of most normal use scenario
inside JDK is that only the "name" info is interested/collect/used. The 
use pattern usually is

zf.stream().map(ZipEntry::getName)

same for the old Enumeration case, only the "name" is used and the 
"entry" object is thrown away mostly.

Other than the memory consumption (showed in those two snapshots), it's 
also relatively costly to create
the ZipEntry especially its "esxdostime" calculation. The jmh numbers 
from a simple benchmark test
suggests the entryNameStream is about 15-20% faster. So, the only reason 
it's there is for better
performance. And hope it might be useful/convenient for the end user as 
well. If it's a concern, I can
hide it into the SharedSecrets, or simply use the 
zf.stream().map(ZipEntry::getName) instead.

--------------------------------------
JarFileBenchmark.jf_entries          avgt   20  0.871 ? 0.079  ms/op
JarFileBenchmark.jf_entryNameStream  avgt   20  0.786 ? 0.165  ms/op
JarFileBenchmark.jf_getEntry         avgt   20  6.805 ? 0.615  ms/op
JarFileBenchmark.jf_stream           avgt   20  0.915 ? 0.096  ms/op
JarFileBenchmark.jf_versionedStream  avgt   20  9.412 ? 0.642  ms/op
JarFileBenchmark.zf_entries          avgt   20  0.877 ? 0.092  ms/op
JarFileBenchmark.zf_entryNameStream  avgt   20  0.730 ? 0.123  ms/op
JarFileBenchmark.zf_getEntry         avgt   20  1.805 ? 0.177  ms/op
JarFileBenchmark.zf_stream           avgt   20  0.926 ? 0.167  ms/op
---------------------------------------

Thanks!
-Sherman



From paul.sandoz at oracle.com  Fri Nov 17 17:48:49 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 17 Nov 2017 09:48:49 -0800
Subject: RFR 8180437 Remaining renames of CAS misnomer "swap" => "set"
Message-ID: <83B10C9E-5099-4FBD-85B2-4D07F538D551@oracle.com>

Please review a minor cleanup of internal naming:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8180437-cas-swap-to-set/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8180437-cas-swap-to-set/webrev/>

Paul.

From patrick at reini.net  Fri Nov 17 18:12:32 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Fri, 17 Nov 2017 19:12:32 +0100
Subject: RFR: 8066870 Add Readable::transferTo(Appendable)
Message-ID: <0FD2C7CD-D69E-4206-B0E6-0B95A21EEDEF@reini.net>

Hi Roger and Alan,

I incorporated the latest feedback using version 1) from this latest post:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050004.html


The actual webrev is here:

http://cr.openjdk.java.net/~reinhapa/reviews/8066870/webrev.00


-Patrick

From jonathan.gibbons at oracle.com  Fri Nov 17 18:29:52 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 17 Nov 2017 10:29:52 -0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
Message-ID: <5A0F2AA0.8020906@oracle.com>

Goetz,

I understand why you might want to ensure that a basic set of help 
options is supported,
but I don't understand why that justifies removing older options, like 
"-help" for many tools.

In addition, I notice the CSR says:

> *Compatibility Risk Description:* 
> <https://bugs.openjdk.java.net/browse/JDK-8191477#> Only new flags are 
> added, none removed.

But that is not true, since your edits for javac and javadoc remove the 
option completely.

Also, in the CSR, look for these typos:
     serveral
     deperecation
     OpenJdk (should be OpenJDK)


Also, I note that you've changed localized resource files. The usual 
procedure is to never
touch those files, since they get updated later by Oracle's localization 
team.

-- Jon

On 11/17/2017 03:23 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> please review this change. I also filed a CSR for this:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>
> See the webrev for a detailed description of the changes.
>
> If required, I'll make break-out changes to be reviewed separately.
>
> I had posted a RFR before, but improved the change to
> give a more complete overview of currently supported flags
> for the CSR:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html
>
> Best regards,
>    Goetz.
>


From martinrb at google.com  Fri Nov 17 18:35:25 2017
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 17 Nov 2017 10:35:25 -0800
Subject: RFR 8180437 Remaining renames of CAS misnomer "swap" => "set"
In-Reply-To: <83B10C9E-5099-4FBD-85B2-4D07F538D551@oracle.com>
References: <83B10C9E-5099-4FBD-85B2-4D07F538D551@oracle.com>
Message-ID: <CA+kOe0-Ea-Vhbb=90VjQ5zrL43YygknetqTXgvUJ1QFiwfajng@mail.gmail.com>

Looks good to me!

On Fri, Nov 17, 2017 at 9:48 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Please review a minor cleanup of internal naming:
>
>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8180437-cas-
> swap-to-set/webrev/
>
> Paul.
>

From xueming.shen at oracle.com  Fri Nov 17 18:54:59 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 17 Nov 2017 10:54:59 -0800
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
In-Reply-To: <5A0F13FF.8090406@oracle.com>
References: <5A0E4703.3040409@oracle.com>
 <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>
 <5A0F13FF.8090406@oracle.com>
Message-ID: <5A0F3083.9080807@oracle.com>

On 11/17/2017 08:53 AM, Xueming Shen wrote:
>>
>> 3. Is ZipFile.entryNameStream really needed? Just asking because zf.stream().map(ZipEntry::getName) is possible today.
>>
> It's not a "must" for sure. The motivation behind this is that my observation of most normal use scenario
> inside JDK is that only the "name" info is interested/collect/used. The use pattern usually is
>
> zf.stream().map(ZipEntry::getName)
>
> same for the old Enumeration case, only the "name" is used and the "entry" object is thrown away mostly.
>
> Other than the memory consumption (showed in those two snapshots), it's also relatively costly to create
> the ZipEntry especially its "esxdostime" calculation. The jmh numbers from a simple benchmark test
> suggests the entryNameStream is about 15-20% faster. So, the only reason it's there is for better
> performance. And hope it might be useful/convenient for the end user as well. If it's a concern, I can
> hide it into the SharedSecrets, or simply use the zf.stream().map(ZipEntry::getName) instead.
>
> --------------------------------------
> JarFileBenchmark.jf_entries          avgt   20  0.871 ? 0.079  ms/op
> JarFileBenchmark.jf_entryNameStream  avgt   20  0.786 ? 0.165  ms/op
> JarFileBenchmark.jf_getEntry         avgt   20  6.805 ? 0.615  ms/op
> JarFileBenchmark.jf_stream           avgt   20  0.915 ? 0.096  ms/op
> JarFileBenchmark.jf_versionedStream  avgt   20  9.412 ? 0.642  ms/op
> JarFileBenchmark.zf_entries          avgt   20  0.877 ? 0.092  ms/op
> JarFileBenchmark.zf_entryNameStream  avgt   20  0.730 ? 0.123  ms/op
> JarFileBenchmark.zf_getEntry         avgt   20  1.805 ? 0.177  ms/op
> JarFileBenchmark.zf_stream           avgt   20  0.926 ? 0.167  ms/op
> ---------------------------------------

above is the numbers from a mr-jar file. here is the numbers for a normal jar.
similar difference.

# Run complete. Total time: 00:06:10

Benchmark                            Mode  Cnt  Score   Error  Units
JarFileBenchmark.jf_entries          avgt   20  0.857 ? 0.075  ms/op
JarFileBenchmark.jf_entryNameStream  avgt   20  0.691 ? 0.064  ms/op
JarFileBenchmark.jf_getEntry         avgt   20  1.868 ? 0.151  ms/op
JarFileBenchmark.jf_stream           avgt   20  0.857 ? 0.056  ms/op
JarFileBenchmark.jf_versionedStream  avgt   20  0.875 ? 0.103  ms/op
JarFileBenchmark.zf_entries          avgt   20  0.811 ? 0.061  ms/op
JarFileBenchmark.zf_entryNameStream  avgt   20  0.662 ? 0.064  ms/op
JarFileBenchmark.zf_getEntry         avgt   20  1.907 ? 0.259  ms/op
JarFileBenchmark.zf_stream           avgt   20  0.806 ? 0.075  ms/op

sherman



From robert.field at oracle.com  Fri Nov 17 19:06:57 2017
From: robert.field at oracle.com (Robert Field)
Date: Fri, 17 Nov 2017 11:06:57 -0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
Message-ID: <6C0CD3C8-D6DD-4A37-97DE-F4EF2E1A2D7A@oracle.com>

JShell changes ?

The code change is fine.

The help change in the properties file is not consistent with the other items, note:        --help-extra, -X      Print help on?
      so this should be:      ?help, -h, -?
Or, if there is a tool-wide standard, then the ?help-extra entry should be changed.

The tests of ??help? should be updated to include the now documented ?-h? and ?-??

As Jon noted, the _ja and _zh_CN properties should not be touched.

-Robert

> On Nov 17, 2017, at 3:23 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi,
> 
> please review this change. I also filed a CSR for this:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> 
> See the webrev for a detailed description of the changes.
> 
> If required, I'll make break-out changes to be reviewed separately.
> 
> I had posted a RFR before, but improved the change to 
> give a more complete overview of currently supported flags
> for the CSR:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html
> 
> Best regards,
>  Goetz.
> 


From paul.sandoz at oracle.com  Fri Nov 17 20:02:55 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 17 Nov 2017 12:02:55 -0800
Subject: 8181175 Stream.concat behaves like terminal operation
Message-ID: <7A97602E-196A-49EF-B83F-086ACC591BA6@oracle.com>

Hi,

Please review this small specification classification for Stream.concat:

http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8181175-concat-eager-binding/webrev/src/java.base/share/classes/java/util/stream/Stream.java.sdiff.html

A CSR will be created.

I decided to call out that Stream.concat binds to its input stream sources rather than hedging bets and being ambiguous.

If we choose to add a var args concat method then it is highly unlikely we will be able to optimize for three or more streams in the same manner as we do for two streams  and it would in effect be (as in the api note i added) implemented using a flat map. In that case such a method can be called out as not binding and concatenating two streams can be performed by passing an empty stream as the third argument.

Thanks,
Paul.

diff -r 52bcd99c60f8 src/java.base/share/classes/java/util/stream/Stream.java
--- a/src/java.base/share/classes/java/util/stream/Stream.java	Fri Nov 17 11:56:48 2017 -0800
+++ b/src/java.base/share/classes/java/util/stream/Stream.java	Fri Nov 17 12:02:13 2017 -0800
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2012, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -1341,6 +1341,10 @@
      * streams is parallel.  When the resulting stream is closed, the close
      * handlers for both input streams are invoked.
      *
+     * <p>This method operates on the two input streams and binds each stream
+     * its source.  As a result subsequent modifications to an input stream
+     * source may not be reflected in the concatenated stream result.
+     *
      * @implNote
      * Use caution when constructing streams from repeated concatenation.
      * Accessing an element of a deeply concatenated stream can result in deep
@@ -1349,6 +1353,15 @@
      * <p>Subsequent changes to the sequential/parallel execution mode of the
      * returned stream are not guaranteed to be propagated to the input streams.
      *
+     * @apiNote
+     * This method will produce an optimal concatenated stream.  To achieve this
+     * only two input streams are accepted and each is bound to its source.
+     * If such restrictions are an issue then consider the alternative: create a
+     * stream of streams and flat-map with the identity function, for example:
+     * <pre>{@code
+     *     Stream<T> concat = Stream.of(s1, s2, s3, s4).flatMap(s -> s);
+     * }</pre>
+     *
      * @param <T> The type of stream elements
      * @param a the first stream
      * @param b the second stream


From naoto.sato at oracle.com  Sat Nov 18 00:21:37 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 17 Nov 2017 16:21:37 -0800
Subject: <i18n dev> [10] RFR 6354947: [Fmt-*] DecimalFormat ignores
 FieldPosition settings on input, contrary to Javadocs
In-Reply-To: <156741f0-36df-03cb-e30f-e2c41d0fc3ef@oracle.com>
References: <156741f0-36df-03cb-e30f-e2c41d0fc3ef@oracle.com>
Message-ID: <91cfcd2f-97ba-dda8-eb2d-9c4bd0f05f29@oracle.com>

+1

Naoto

On 11/16/17 10:52 PM, Nishit Jain wrote:
> Hi,
> 
> Please review the fix for JDK-6354947
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-6354947
> Webrev: http://cr.openjdk.java.net/~nishjain/6354947/webrev.02/
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191014
> 
> Fix: Clarified handling of the FieldPosition settings in the 
> java.text.Format APIs specification.
> 
> Regards,
> Nishit Jain

From stuart.marks at oracle.com  Sat Nov 18 01:18:04 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 17 Nov 2017 17:18:04 -0800
Subject: 8181175 Stream.concat behaves like terminal operation
In-Reply-To: <7A97602E-196A-49EF-B83F-086ACC591BA6@oracle.com>
References: <7A97602E-196A-49EF-B83F-086ACC591BA6@oracle.com>
Message-ID: <3dcdae3d-0706-8f5b-2be3-0f934e5dc285@oracle.com>

Hi Paul,

The normative text about binding to the source and subsequent modifications to 
the source possibly not being reflected in the stream makes sense.

I'm having trouble understanding the API note though. What does "optimal" mean? 
What about concatenating multiple streams would not be optimal?

s'marks

On 11/17/17 12:02 PM, Paul Sandoz wrote:
> Hi,
> 
> Please review this small specification classification for Stream.concat:
> 
> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8181175-concat-eager-binding/webrev/src/java.base/share/classes/java/util/stream/Stream.java.sdiff.html
> 
> A CSR will be created.
> 
> I decided to call out that Stream.concat binds to its input stream sources rather than hedging bets and being ambiguous.
> 
> If we choose to add a var args concat method then it is highly unlikely we will be able to optimize for three or more streams in the same manner as we do for two streams  and it would in effect be (as in the api note i added) implemented using a flat map. In that case such a method can be called out as not binding and concatenating two streams can be performed by passing an empty stream as the third argument.
> 
> Thanks,
> Paul.
> 
> diff -r 52bcd99c60f8 src/java.base/share/classes/java/util/stream/Stream.java
> --- a/src/java.base/share/classes/java/util/stream/Stream.java	Fri Nov 17 11:56:48 2017 -0800
> +++ b/src/java.base/share/classes/java/util/stream/Stream.java	Fri Nov 17 12:02:13 2017 -0800
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2012, 2016, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>    *
>    * This code is free software; you can redistribute it and/or modify it
> @@ -1341,6 +1341,10 @@
>        * streams is parallel.  When the resulting stream is closed, the close
>        * handlers for both input streams are invoked.
>        *
> +     * <p>This method operates on the two input streams and binds each stream
> +     * its source.  As a result subsequent modifications to an input stream
> +     * source may not be reflected in the concatenated stream result.
> +     *
>        * @implNote
>        * Use caution when constructing streams from repeated concatenation.
>        * Accessing an element of a deeply concatenated stream can result in deep
> @@ -1349,6 +1353,15 @@
>        * <p>Subsequent changes to the sequential/parallel execution mode of the
>        * returned stream are not guaranteed to be propagated to the input streams.
>        *
> +     * @apiNote
> +     * This method will produce an optimal concatenated stream.  To achieve this
> +     * only two input streams are accepted and each is bound to its source.
> +     * If such restrictions are an issue then consider the alternative: create a
> +     * stream of streams and flat-map with the identity function, for example:
> +     * <pre>{@code
> +     *     Stream<T> concat = Stream.of(s1, s2, s3, s4).flatMap(s -> s);
> +     * }</pre>
> +     *
>        * @param <T> The type of stream elements
>        * @param a the first stream
>        * @param b the second stream
> 

From john.r.rose at oracle.com  Sat Nov 18 05:43:01 2017
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 18 Nov 2017 00:43:01 -0500
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <3eeefa3a-fffa-138d-fecb-29e22a00d4c0@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <CAPkkuSctDbApfZDxi-CcJLYAU0KuvNCg28BYA-rj_9yUeTSd9A@mail.gmail.com>
 <3eeefa3a-fffa-138d-fecb-29e22a00d4c0@oracle.com>
Message-ID: <4273A1A8-F160-42DB-B13C-7EE041429829@oracle.com>

Late to the party, but these lines rub me the wrong way:

@return the new {@code List}
@return the new {@code Set}
@return the new {@code Map}

The word "new" is a loaded term, which usually means
(or can be easily mistaken to mean) that a new object
identity is guaranteed.  Thus, "new" shouldn't be used
to specify the behavior of value-based classes.

Given that that the underlying objects are of VBCs,
and that we are encouraging programmers to rely on
the efficiency of chained copies, it should say something
like this instead:

@return a {@code List} containing the same elements as the given collection
@return a {@code Set} containing the same elements as the given collection
@return a {@code Map} containing the same mappings as the given map

(Or even s/return a/return an unmodifiable/.)

? John

From john.r.rose at oracle.com  Sat Nov 18 06:40:05 2017
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 18 Nov 2017 01:40:05 -0500
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <ad9c1a86-9ff0-4247-ddcb-00e4d6e80f65@reini.net>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <AM4PR08MB12199717DB39BAA682DE5B3BFF5F0@AM4PR08MB1219.eurprd08.prod.outlook.com>
 <3ea78605-b083-1fcc-3cb8-1adc6d76d045@oracle.com>
 <1B0724CA-ADB2-432A-9004-B0A9C6B74F6E@reini.net>
 <CAGB9EW-Zpd4D5Hc1ri4vPjnVQQ1zG7hifHoe=6cYr7zEB2r0Gg@mail.gmail.com>
 <85BE47B6-2214-43AD-B7D0-01F846E42EED@reini.net>
 <a76d535f-7e92-5700-8cb9-2b254eee2153@Oracle.com>
 <ad9c1a86-9ff0-4247-ddcb-00e4d6e80f65@reini.net>
Message-ID: <4F504EDD-204F-40BE-B477-82132F564C9E@oracle.com>

On Nov 3, 2017, at 1:26 AM, Patrick Reinhart <patrick at reini.net> wrote:
> 
>> 
>> On 11/1/2017 4:29 PM, Patrick Reinhart wrote:
>>> In this case I would prefer a non static copyOf() method on the list
>>> to create a unmodifiable list/set/map, where the optimal factory
>>> method can be called. This would also solve the problem of a
>>> concurrent implementation.

Such methods would, unfortunately, be a disastrous mistake.

We are encouraging users to rely on the unmodifiability of the
value-based lists, sets, and maps returned by copyOf, the
same way they rely on the unmodifiability of Strings.  But
if we made copyOf be non-static, then an attacker (or just
a buggy program) could introduce a broken implementation
of List that returned a time-varying List.  This would break
the contract of copyOf, but it would be impossible to detect.
The result would be a less reliable copyOf API, and
eventually some TOCTTOU security vulnerabilities.
This kind of surprise mutability is red meat for security
researchers.

So it's got to be a static method, although if List were a
class we could also choose to make copyOf be a final method.

I said "unfortunately" above because I too would prefer
fluent syntax like ls.unmodifiableCopy() or ls.frozen()
instead of List.copyOf(ls), since fluent syntax reads
and composes cleanly from left to right.

I think a good way to get what we want may be to
introduce a way for selected methods of an interface
to mark themselves (somehow) as "fluent statics",
meaning that they can be invoked with their first
argument in receiver position, before the dot.
In effect, they would act like "final default" methods
but without having to damage interfaces with final
methods.

I don't have a syntax in mind for defining a "fluent
static", but I have thought for some time that allowing
such sugar for interface statics is the best way to
adapt the notion of class final methods to interfaces.

This is not easy to do, since it is a language change,
and only applies to a small (though influential) number of
methods, those which should *not* be overridable but
*should* (for some reason of API design) support virtual
(fluent, postfix, left-to-right) notation.

For more details please see JDK-8191530 and if you
think of a good use case for these thingies, let me know
so I can add it to the write-up.

? John

From Alan.Bateman at oracle.com  Sat Nov 18 08:41:47 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 18 Nov 2017 08:41:47 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
Message-ID: <71c9130c-a8b6-c811-b14f-564b6f38574e@oracle.com>

On 17/11/2017 11:23, Lindenmaier, Goetz wrote:
> Hi,
>
> please review this change. I also filed a CSR for this:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>
> See the webrev for a detailed description of the changes.
>
A question for Jon Gibbons: In JEP 293 the guideline is that tools 
should support `--help`. Do you think this should be expanded to include 
`-help`, and `-?` (and maybe `-h` where it make sense)?

As regards the webrev then the changes to the localized resources can be 
dropped. As Jon noted, we don't usually edit these directly as they are 
bulk updated/replaced by translation drops that usually happen late in 
each release.

It's not clear to me that it's wroth trying to update the JAXB, JAX-WS, 
and CORBA tools. One reason the corresponding tool modules are 
deprecated-for-removal and there is a draft JEP to remove them 
completely [1]. In addition, the JAXB ad JAX-WS tools are problematic to 
change as they are owned by upstream projects on the Java EE github - 
any changes to the code in these modules needs to coordinated to avoid 
having a fork here.

-Alan

[1] http://openjdk.java.net/jeps/8189188

From forax at univ-mlv.fr  Sat Nov 18 10:41:29 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 18 Nov 2017 11:41:29 +0100 (CET)
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <4F504EDD-204F-40BE-B477-82132F564C9E@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <3ea78605-b083-1fcc-3cb8-1adc6d76d045@oracle.com>
 <1B0724CA-ADB2-432A-9004-B0A9C6B74F6E@reini.net>
 <CAGB9EW-Zpd4D5Hc1ri4vPjnVQQ1zG7hifHoe=6cYr7zEB2r0Gg@mail.gmail.com>
 <85BE47B6-2214-43AD-B7D0-01F846E42EED@reini.net>
 <a76d535f-7e92-5700-8cb9-2b254eee2153@Oracle.com>
 <ad9c1a86-9ff0-4247-ddcb-00e4d6e80f65@reini.net>
 <4F504EDD-204F-40BE-B477-82132F564C9E@oracle.com>
Message-ID: <2116128804.2837720.1511001689546.JavaMail.zimbra@u-pem.fr>

Hi John,
i strongly believe that static fluent methods have no place in a blue collar language, we can do better, in fact the have already done better by introducing default method instead of extension methods like in C# or Kotlin*.

The main issue with this kind of method is that it quacks like a duck but it's not a duck, i.e. you call those static methods as virtual methods but there are no virtual methods because you can not override them. 

Adding extension methods as feature is like a black hole, extension methods allow you to write clunky DSLs so it's a feature that will force the language to move to add more new features to be able to write decent DSLs (think implicit object as an example), and so on. So it sucks your design budget like a black hole.

In term of performance, the code inside a static extension methods tends to become megamorphic, in C#, Data Link (Link for Collection API) is slow because of that, in Kotlin you can workaround that by using the keyword inline which will copy the code into the callsite avoiding profile pollution.

So in my opinion, the only possible option is to introduce final default methods, i fully understand that this is non trivial to introduce this kind of methods in the VM but this discussion is a good use case for their introduction. 

regards,
R?mi

* i will not criticize Kotlin designers on that, they wanted to enhance Java APIs without owning them so they had little options.

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> ?: "Patrick Reinhart" <patrick at reini.net>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Samedi 18 Novembre 2017 07:40:05
> Objet: Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

> On Nov 3, 2017, at 1:26 AM, Patrick Reinhart <patrick at reini.net> wrote:
>> 
>>> 
>>> On 11/1/2017 4:29 PM, Patrick Reinhart wrote:
>>>> In this case I would prefer a non static copyOf() method on the list
>>>> to create a unmodifiable list/set/map, where the optimal factory
>>>> method can be called. This would also solve the problem of a
>>>> concurrent implementation.
> 
> Such methods would, unfortunately, be a disastrous mistake.
> 
> We are encouraging users to rely on the unmodifiability of the
> value-based lists, sets, and maps returned by copyOf, the
> same way they rely on the unmodifiability of Strings.  But
> if we made copyOf be non-static, then an attacker (or just
> a buggy program) could introduce a broken implementation
> of List that returned a time-varying List.  This would break
> the contract of copyOf, but it would be impossible to detect.
> The result would be a less reliable copyOf API, and
> eventually some TOCTTOU security vulnerabilities.
> This kind of surprise mutability is red meat for security
> researchers.
> 
> So it's got to be a static method, although if List were a
> class we could also choose to make copyOf be a final method.
> 
> I said "unfortunately" above because I too would prefer
> fluent syntax like ls.unmodifiableCopy() or ls.frozen()
> instead of List.copyOf(ls), since fluent syntax reads
> and composes cleanly from left to right.
> 
> I think a good way to get what we want may be to
> introduce a way for selected methods of an interface
> to mark themselves (somehow) as "fluent statics",
> meaning that they can be invoked with their first
> argument in receiver position, before the dot.
> In effect, they would act like "final default" methods
> but without having to damage interfaces with final
> methods.
> 
> I don't have a syntax in mind for defining a "fluent
> static", but I have thought for some time that allowing
> such sugar for interface statics is the best way to
> adapt the notion of class final methods to interfaces.
> 
> This is not easy to do, since it is a language change,
> and only applies to a small (though influential) number of
> methods, those which should *not* be overridable but
> *should* (for some reason of API design) support virtual
> (fluent, postfix, left-to-right) notation.
> 
> For more details please see JDK-8191530 and if you
> think of a good use case for these thingies, let me know
> so I can add it to the write-up.
> 
> ? John

From brian.goetz at oracle.com  Sat Nov 18 16:10:27 2017
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 18 Nov 2017 11:10:27 -0500
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <2116128804.2837720.1511001689546.JavaMail.zimbra@u-pem.fr>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <3ea78605-b083-1fcc-3cb8-1adc6d76d045@oracle.com>
 <1B0724CA-ADB2-432A-9004-B0A9C6B74F6E@reini.net>
 <CAGB9EW-Zpd4D5Hc1ri4vPjnVQQ1zG7hifHoe=6cYr7zEB2r0Gg@mail.gmail.com>
 <85BE47B6-2214-43AD-B7D0-01F846E42EED@reini.net>
 <a76d535f-7e92-5700-8cb9-2b254eee2153@Oracle.com>
 <ad9c1a86-9ff0-4247-ddcb-00e4d6e80f65@reini.net>
 <4F504EDD-204F-40BE-B477-82132F564C9E@oracle.com>
 <2116128804.2837720.1511001689546.JavaMail.zimbra@u-pem.fr>
Message-ID: <1DE20B8F-8A35-43E9-AB8C-5C662FAFFD22@oracle.com>

I'm with Remi on this.  

Sent from my MacBook Wheel

> On Nov 18, 2017, at 5:41 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi John,
> i strongly believe that static fluent methods have no place in a blue collar language, we can do better, in fact the have already done better by introducing default method instead of extension methods like in C# or Kotlin*.
> 
> The main issue with this kind of method is that it quacks like a duck but it's not a duck, i.e. you call those static methods as virtual methods but there are no virtual methods because you can not override them. 
> 
> Adding extension methods as feature is like a black hole, extension methods allow you to write clunky DSLs so it's a feature that will force the language to move to add more new features to be able to write decent DSLs (think implicit object as an example), and so on. So it sucks your design budget like a black hole.
> 
> In term of performance, the code inside a static extension methods tends to become megamorphic, in C#, Data Link (Link for Collection API) is slow because of that, in Kotlin you can workaround that by using the keyword inline which will copy the code into the callsite avoiding profile pollution.
> 
> So in my opinion, the only possible option is to introduce final default methods, i fully understand that this is non trivial to introduce this kind of methods in the VM but this discussion is a good use case for their introduction. 
> 
> regards,
> R?mi
> 
> * i will not criticize Kotlin designers on that, they wanted to enhance Java APIs without owning them so they had little options.
> 
> ----- Mail original -----
>> De: "John Rose" <john.r.rose at oracle.com>
>> ?: "Patrick Reinhart" <patrick at reini.net>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoy?: Samedi 18 Novembre 2017 07:40:05
>> Objet: Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map
> 
>>> On Nov 3, 2017, at 1:26 AM, Patrick Reinhart <patrick at reini.net> wrote:
>>> 
>>>> 
>>>>> On 11/1/2017 4:29 PM, Patrick Reinhart wrote:
>>>>> In this case I would prefer a non static copyOf() method on the list
>>>>> to create a unmodifiable list/set/map, where the optimal factory
>>>>> method can be called. This would also solve the problem of a
>>>>> concurrent implementation.
>> 
>> Such methods would, unfortunately, be a disastrous mistake.
>> 
>> We are encouraging users to rely on the unmodifiability of the
>> value-based lists, sets, and maps returned by copyOf, the
>> same way they rely on the unmodifiability of Strings.  But
>> if we made copyOf be non-static, then an attacker (or just
>> a buggy program) could introduce a broken implementation
>> of List that returned a time-varying List.  This would break
>> the contract of copyOf, but it would be impossible to detect.
>> The result would be a less reliable copyOf API, and
>> eventually some TOCTTOU security vulnerabilities.
>> This kind of surprise mutability is red meat for security
>> researchers.
>> 
>> So it's got to be a static method, although if List were a
>> class we could also choose to make copyOf be a final method.
>> 
>> I said "unfortunately" above because I too would prefer
>> fluent syntax like ls.unmodifiableCopy() or ls.frozen()
>> instead of List.copyOf(ls), since fluent syntax reads
>> and composes cleanly from left to right.
>> 
>> I think a good way to get what we want may be to
>> introduce a way for selected methods of an interface
>> to mark themselves (somehow) as "fluent statics",
>> meaning that they can be invoked with their first
>> argument in receiver position, before the dot.
>> In effect, they would act like "final default" methods
>> but without having to damage interfaces with final
>> methods.
>> 
>> I don't have a syntax in mind for defining a "fluent
>> static", but I have thought for some time that allowing
>> such sugar for interface statics is the best way to
>> adapt the notion of class final methods to interfaces.
>> 
>> This is not easy to do, since it is a language change,
>> and only applies to a small (though influential) number of
>> methods, those which should *not* be overridable but
>> *should* (for some reason of API design) support virtual
>> (fluent, postfix, left-to-right) notation.
>> 
>> For more details please see JDK-8191530 and if you
>> think of a good use case for these thingies, let me know
>> so I can add it to the write-up.
>> 
>> ? John


From john.r.rose at oracle.com  Sat Nov 18 16:12:16 2017
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 18 Nov 2017 11:12:16 -0500
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <1DE20B8F-8A35-43E9-AB8C-5C662FAFFD22@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <3ea78605-b083-1fcc-3cb8-1adc6d76d045@oracle.com>
 <1B0724CA-ADB2-432A-9004-B0A9C6B74F6E@reini.net>
 <CAGB9EW-Zpd4D5Hc1ri4vPjnVQQ1zG7hifHoe=6cYr7zEB2r0Gg@mail.gmail.com>
 <85BE47B6-2214-43AD-B7D0-01F846E42EED@reini.net>
 <a76d535f-7e92-5700-8cb9-2b254eee2153@Oracle.com>
 <ad9c1a86-9ff0-4247-ddcb-00e4d6e80f65@reini.net>
 <4F504EDD-204F-40BE-B477-82132F564C9E@oracle.com>
 <2116128804.2837720.1511001689546.JavaMail.zimbra@u-pem.fr>
 <1DE20B8F-8A35-43E9-AB8C-5C662FAFFD22@oracle.com>
Message-ID: <E365EBEC-CAFF-41C3-9411-5A58574285A1@oracle.com>

On Nov 18, 2017, at 11:10 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> I'm with Remi on this.  

Which suggestion of his two?  Blue-collar language with bad DSLs,
or final defaults?

? John

From brian.goetz at oracle.com  Sat Nov 18 16:16:02 2017
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 18 Nov 2017 11:16:02 -0500
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <E365EBEC-CAFF-41C3-9411-5A58574285A1@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <3ea78605-b083-1fcc-3cb8-1adc6d76d045@oracle.com>
 <1B0724CA-ADB2-432A-9004-B0A9C6B74F6E@reini.net>
 <CAGB9EW-Zpd4D5Hc1ri4vPjnVQQ1zG7hifHoe=6cYr7zEB2r0Gg@mail.gmail.com>
 <85BE47B6-2214-43AD-B7D0-01F846E42EED@reini.net>
 <a76d535f-7e92-5700-8cb9-2b254eee2153@Oracle.com>
 <ad9c1a86-9ff0-4247-ddcb-00e4d6e80f65@reini.net>
 <4F504EDD-204F-40BE-B477-82132F564C9E@oracle.com>
 <2116128804.2837720.1511001689546.JavaMail.zimbra@u-pem.fr>
 <1DE20B8F-8A35-43E9-AB8C-5C662FAFFD22@oracle.com>
 <E365EBEC-CAFF-41C3-9411-5A58574285A1@oracle.com>
Message-ID: <BCD2733E-27BC-45FA-8B15-BEDAA0470A06@oracle.com>

Use-site static extension methods = bad.  

Sent from my MacBook Wheel

> On Nov 18, 2017, at 11:12 AM, John Rose <john.r.rose at oracle.com> wrote:
> 
>> On Nov 18, 2017, at 11:10 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> I'm with Remi on this.  
> 
> Which suggestion of his two?  Blue-collar language with bad DSLs,
> or final defaults?
> 
> ? John

From john.r.rose at oracle.com  Sat Nov 18 16:19:55 2017
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 18 Nov 2017 11:19:55 -0500
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <BCD2733E-27BC-45FA-8B15-BEDAA0470A06@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <3ea78605-b083-1fcc-3cb8-1adc6d76d045@oracle.com>
 <1B0724CA-ADB2-432A-9004-B0A9C6B74F6E@reini.net>
 <CAGB9EW-Zpd4D5Hc1ri4vPjnVQQ1zG7hifHoe=6cYr7zEB2r0Gg@mail.gmail.com>
 <85BE47B6-2214-43AD-B7D0-01F846E42EED@reini.net>
 <a76d535f-7e92-5700-8cb9-2b254eee2153@Oracle.com>
 <ad9c1a86-9ff0-4247-ddcb-00e4d6e80f65@reini.net>
 <4F504EDD-204F-40BE-B477-82132F564C9E@oracle.com>
 <2116128804.2837720.1511001689546.JavaMail.zimbra@u-pem.fr>
 <1DE20B8F-8A35-43E9-AB8C-5C662FAFFD22@oracle.com>
 <E365EBEC-CAFF-41C3-9411-5A58574285A1@oracle.com>
 <BCD2733E-27BC-45FA-8B15-BEDAA0470A06@oracle.com>
Message-ID: <89EBB369-0B76-4657-A190-1AF8E6AC4A44@oracle.com>

On Nov 18, 2017, at 11:16 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> Use-site static extension methods = bad.  

Right; that wasn't on the table from either Remy or me.
All def-site stuff, so the designer of the defining interface
has full control of the DSL.  JDK-8191530 is def-site extension
methods, a compromise that meets most or all of our requirements.

(Side note:  We could enable third-party DSL stuff with value types
and specialization by using the value object as a view, and the
real type of the extended object/value as a generic parameter.
The value type acts just like a C++ smart pointer and can warp
the original API around however it likes.)


> Sent from my MacBook Wheel
> 
> On Nov 18, 2017, at 11:12 AM, John Rose <john.r.rose at oracle.com <mailto:john.r.rose at oracle.com>> wrote:
> 
>> On Nov 18, 2017, at 11:10 AM, Brian Goetz <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
>>> 
>>> I'm with Remi on this.  
>> 
>> Which suggestion of his two?  Blue-collar language with bad DSLs,
>> or final defaults?
>> 
>> ? John


From weijun.wang at oracle.com  Sun Nov 19 00:28:01 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sun, 19 Nov 2017 08:28:01 +0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
Message-ID: <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>

I am OK with all commands supporting --help, but I am not sure if every tool should show it on the help screen if the tools's other options are still using the old single-"-" style. It looks like the tools are half-converted.

Is there a timetable to add "--" support to all tools?

Thanks
Max

> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi,
> 
> please review this change. I also filed a CSR for this:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> 
> See the webrev for a detailed description of the changes.
> 
> If required, I'll make break-out changes to be reviewed separately.
> 
> I had posted a RFR before, but improved the change to 
> give a more complete overview of currently supported flags
> for the CSR:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html
> 
> Best regards,
>  Goetz.
> 


From john.r.rose at oracle.com  Sun Nov 19 03:34:12 2017
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 18 Nov 2017 22:34:12 -0500
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
Message-ID: <E3598621-C8A0-4ECA-9EFB-8D8F6381AF18@oracle.com>

On Oct 30, 2017, at 6:50 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> (also includes 8184690: add Collectors for collecting into unmodifiable List, Set, and Map)

Now I'm going to be picky about the names of the Collectors;
please bear with me a moment.  Consider `toUnmodifiableList`
and its two cousins (`toUSet`, `toUMap`).

The most natural names `toList` (etc.) are already taken.
They mean "do whatever is most useful for the collector,
perhaps returning unmodifiable or modifiable results".

So the problem here is giving the user the option to say,
"no, I really want a value-based-class-style list here; I know
you can do this for me".

`Collectors.toList` can't ever be upgraded in place, since
the programmer is getting a Collector's Choice result,
and programmers will be inadvertently relying on whatever
that (undocumented) choice happens to be.

I think this makes the name `toList` significantly less useful,
and I for one will never want to use `toList` again, once
`toUnmodifiableList` is available.

Meanwhile, `toUnmodifiableList` is so ugly to the ear,
eye, and fingers that it will be less used just because of
its long spelling.

Users should be allowed to code as if unmodifiability is a
common practice, not something that must be re-announced
every time I make a new temporary list.  That's why `copyOf`
and not `unmodifiableCopyOf` is the right move, and
`toUnmodifiableList` is not.

(See also Gafter's blog[1] on making NEW FEATURES look NEW.
The NEW UNMODIFIABILITY will soon cease to be new but in
its present form it will shout forever like an aging rocker.)

To get out of this bind, I suggest picking a shorter name that
emphasizes that the result is the _elements_ in the list, not the
list object per se.  This is a VBC[2] move, one which we need to
learn to make more often, especially as value types arrive.
So I suggest these names for the collectors:  `elements` (for
a list), `elementSet`, and `elementMap`.  Same signatures,
of course.

Another approach to this, which recycles the old names but
doesn't have the VBC vibe, is to create a second set of
factories for list/set/map collectors that look just like the
old ones, but behave more predictably.

For example, one might try to add methods to `Collector`
named `asModifiable` and `asUnmodifiable`, so people can
write `toList().asModifiable()`.  I don't think this works, nor
is it very pretty (looks too "NEW"), although it provides a
more principled fix to the Collector's Choice problem.

If we go forward with the change as written, I think people will
only want to remember the one `toList` and forget about his ugly
brother.  Only zealots like me will remember to add the extra
incantation ("NEW!  now Unmodifiable!").

Another, better way to recycle the name `toList` is to provide
`Collectors.Modifiable` and `Collectors.Unmodifiable`, and then
have users import `Collectors.Unmodifiable.toList`.  This at least
would move the shouting up to the static imports list and out of
real code.

But I think `toList` is broken and should be avoided.  So I
think it should be `elements`, `elementSet`, and `elementMap`.

Even if you think that unmodifiability should be mentioned every
time a collector collects some stuff, observe that `toUnmodifiableList`
is not a strong parallel with the older API point, `Collections.unmodifiableList`.
That guy creates a _view_ while `copyOf` and `elements` (my name)
create non-view unmodifiable (VBC, shallowly immutable) lists.
So `Collectors.toUnmodifiableList` is both ugly and ill-sorted with `copyOf`.

? John

[1]: http://gafter.blogspot.com/2017/06/making-new-language-features-stand-out.html
[2]: https://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html


From brian.goetz at oracle.com  Sun Nov 19 13:42:38 2017
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 19 Nov 2017 08:42:38 -0500
Subject: RFR: 8066870 Add Readable::transferTo(Appendable)
In-Reply-To: <0FD2C7CD-D69E-4206-B0E6-0B95A21EEDEF@reini.net>
References: <0FD2C7CD-D69E-4206-B0E6-0B95A21EEDEF@reini.net>
Message-ID: <274aa1fc-176a-f379-82ab-fd625e568b34@oracle.com>

Late to this thread, but ...

TL;DR: I think this method, as proposed, is fatally flawed; it should be 
a static method rather than a default method.


We need to be very, very careful about adding default methods like this 
to highly abstract interfaces like Readable (the -able suffix is often 
the giveaway that you're in murky waters wrt default methods).? There 
are many pitfalls one can run into here; the one that gets us here is 
that attempted overrides can easily and accidentally become overloads.

DIGRESSION -- A LESSON FROM 8

By way of background, we added Function.compose(...) in Java 8, when 
both functional interfaces and default methods were new, and this turned 
out to be a mistake.? This seemed a no-brainer (in j.l.f.Function), but 
didn't turn out so well.? We added:

intf Function<T,U> {
 ??? <V> Function<T,V> compose(Function<U,V> g);
}

But note also that

intf BinaryOperator<T> extends Function<T,T> {
}

As such, binOp.compose(binOp) yields a Function<T,T>, not a BinOp<T>.? 
Oops, that's not what we wanted!? If we try and override it:

intf BinaryOperator<T> extends Function<T,T> {
 ??? BinaryOperator<T> compose(BinaryOperator<T> g);
}

we haven't really overridden compose(), but instead we've overloaded 
it.? And now we have potential ambiguities in overload resolution because

 ? f.compose(t -> t)

is compatible with both overrides of compose().? And since we don't have 
overloading on return types, we can't even use the return type to 
disambiguate:

 ? BinaryOperator<T> composed = f.compose(t -> t) // nope

The siren song here was the desire for fluency; this was just the wrong 
place to put a compose() method.? This method interacted with 
inheritance in two ways; it could be overridden, and it was also 
desirable for it to have distinguished behavior for distinguished 
subtypes of its argument types.? This was just too many degrees of 
freedom, and it painted us into a corner. Function was too general a 
place to put a default method like compose() that had such potential to 
interact with inheritance, but we were so excited about the prospects of 
saying "f.compose(g)" that we didn't think it through.

RETURNING TO THE CURRENT ISSUE

Now, while you could claim this is not an exact analogy (i.e., 
transferTo doesn't take a lambda, which was one ingredient of the 
problems with compose), the reality is that the higher up in the 
hierarchy you go, the more risky adding defaults is.? There still is a 
big interaction risk here.

In this case, the risk is that both Readable and Appendable are "too 
general."? In particular, it means that overriding in a subclass won't 
mean what you might think it means.? Think of the overridings that are 
actually likely to happen -- those where you know something more about 
both what kind of Readable and Appendable you've got.

Let's say that Reader does:

 ??? class Reader {
 ??????? long transferTo(Writer out) { ... }
 ??? }

This is a totally sensible thing to want to do, since Writer has more 
flexibility than Appendable, and so such an implementation could be 
better than the default.

The problem is: **this is not an override, but an overload**. Which 
means that

 ??? Reader r = ...
 ??? Writer.w = ...
 ??? r.transferTo(w)

will not mean the same thing as

 ??? Readable rr = r;
 ??? Appendable ww = w;
 ??? r.transferTo(ww);

Because InputStream.transferTo() is not an override of 
Readable.appendTo().? This is serious puzzler-bait!? Instance method 
dispatch is not supposed to depend on the static types involved, but 
that's sure what it looks like is happening here.

**IMO, this is a fatal API design error for this method**. Instead, 
Readable.transferTo() should probably be a static method, so that it 
does not give the illusion of being overridable.

I know default methods on highly abstract interfaces are very tempting, 
and the siren song of fluency calls to us, but we should be very, very 
careful about adding default methods to interfaces like Iterable or 
Readable -- essentially any of the Xxxable interfaces.

I think it is much better to make this a static method, and put concrete 
methods (with better implementations, that can take advantage of bulk 
write abilities, which Appendable lacks) on Reader as needed.? 
(InputStream already has this method.)


On 11/17/2017 1:12 PM, Patrick Reinhart wrote:
> Hi Roger and Alan,
>
> I incorporated the latest feedback using version 1) from this latest post:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050004.html
>
>
> The actual webrev is here:
>
> http://cr.openjdk.java.net/~reinhapa/reviews/8066870/webrev.00
>
>
> -Patrick


From jonathan.gibbons at oracle.com  Sun Nov 19 18:07:13 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sun, 19 Nov 2017 10:07:13 -0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <71c9130c-a8b6-c811-b14f-564b6f38574e@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <71c9130c-a8b6-c811-b14f-564b6f38574e@oracle.com>
Message-ID: <44b0343b-7534-9908-3884-56d25dce90d7@oracle.com>



On 11/18/17 12:41 AM, Alan Bateman wrote:
>>
> A question for Jon Gibbons: In JEP 293 the guideline is that tools 
> should support `--help`. Do you think this should be expanded to 
> include `-help`, and `-?` (and maybe `-h` where it make sense)? 
I think we should standardize on --help, and -h where possible, as the 
standard options.

I think we should continue to allow -help where it has previously been 
accepted. I don't think we should add -help for new tools.

I wasn't aware that -? is in common usage. If it is, it makes sense to 
allow it.

-- Jon

From jonathan.gibbons at oracle.com  Sun Nov 19 18:12:17 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sun, 19 Nov 2017 10:12:17 -0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
Message-ID: <00717f78-f393-b406-da71-423c17acaf21@oracle.com>

We are already in a hybrid world of old-style and new-style options :-(

All the new module-related options added in JDK 9 are "new style", 
following the guidelines of JEP 293.

It does not make sense to add "--" to some of the older tools, that may 
be going away at some point, and while we may be able to add the ability 
for other tools to accept "--" options, we have to be careful about 
removing support for existing options.

-- Jon


On 11/18/17 4:28 PM, Weijun Wang wrote:
> I am OK with all commands supporting --help, but I am not sure if every tool should show it on the help screen if the tools's other options are still using the old single-"-" style. It looks like the tools are half-converted.
>
> Is there a timetable to add "--" support to all tools?
>
> Thanks
> Max
>
>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
>>
>> Hi,
>>
>> please review this change. I also filed a CSR for this:
>> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>>
>> See the webrev for a detailed description of the changes.
>>
>> If required, I'll make break-out changes to be reviewed separately.
>>
>> I had posted a RFR before, but improved the change to
>> give a more complete overview of currently supported flags
>> for the CSR:
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html
>>
>> Best regards,
>>   Goetz.
>>


From patrick at reini.net  Sun Nov 19 20:01:38 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Sun, 19 Nov 2017 21:01:38 +0100
Subject: RFR: 8066870 Add Readable::transferTo(Appendable)
In-Reply-To: <274aa1fc-176a-f379-82ab-fd625e568b34@oracle.com>
References: <0FD2C7CD-D69E-4206-B0E6-0B95A21EEDEF@reini.net>
 <274aa1fc-176a-f379-82ab-fd625e568b34@oracle.com>
Message-ID: <BDD11B34-B857-4250-93E0-D32C69BDE18B@reini.net>

Having a static method on Appendable instead of a default one seem reasonable to me too.

Would it be a problem to have an additional transferTo() method on Readable as in your overload example though similar to IntputStream? My researches of the JDK code base found at least 30 places where a simple transferTo on a Reader could have been used to transfer all data to a Writer. Also some less usages where a combination of Reader -> CharBuffer or CharBuffer -> Appendable could have been used to. This analysis lead to the idea to have a default method for those use cases instead may be use a separate static method for Readable/Appendable and one on a Reader as on the InputStream

-Patrick


> Am 19.11.2017 um 14:42 schrieb Brian Goetz <brian.goetz at oracle.com>:
> 
> Late to this thread, but ...
> 
> TL;DR: I think this method, as proposed, is fatally flawed; it should be a static method rather than a default method.
> 
> 
> We need to be very, very careful about adding default methods like this to highly abstract interfaces like Readable (the -able suffix is often the giveaway that you're in murky waters wrt default methods).  There are many pitfalls one can run into here; the one that gets us here is that attempted overrides can easily and accidentally become overloads.
> 
> DIGRESSION -- A LESSON FROM 8
> 
> By way of background, we added Function.compose(...) in Java 8, when both functional interfaces and default methods were new, and this turned out to be a mistake.  This seemed a no-brainer (in j.l.f.Function), but didn't turn out so well.  We added:
> 
> intf Function<T,U> {
>     <V> Function<T,V> compose(Function<U,V> g);
> }
> 
> But note also that
> 
> intf BinaryOperator<T> extends Function<T,T> {
> }
> 
> As such, binOp.compose(binOp) yields a Function<T,T>, not a BinOp<T>.  Oops, that's not what we wanted!  If we try and override it:
> 
> intf BinaryOperator<T> extends Function<T,T> {
>     BinaryOperator<T> compose(BinaryOperator<T> g);
> }
> 
> we haven't really overridden compose(), but instead we've overloaded it.  And now we have potential ambiguities in overload resolution because
> 
>   f.compose(t -> t)
> 
> is compatible with both overrides of compose().  And since we don't have overloading on return types, we can't even use the return type to disambiguate:
> 
>   BinaryOperator<T> composed = f.compose(t -> t) // nope
> 
> The siren song here was the desire for fluency; this was just the wrong place to put a compose() method.  This method interacted with inheritance in two ways; it could be overridden, and it was also desirable for it to have distinguished behavior for distinguished subtypes of its argument types.  This was just too many degrees of freedom, and it painted us into a corner. Function was too general a place to put a default method like compose() that had such potential to interact with inheritance, but we were so excited about the prospects of saying "f.compose(g)" that we didn't think it through.
> 
> RETURNING TO THE CURRENT ISSUE
> 
> Now, while you could claim this is not an exact analogy (i.e., transferTo doesn't take a lambda, which was one ingredient of the problems with compose), the reality is that the higher up in the hierarchy you go, the more risky adding defaults is.  There still is a big interaction risk here.
> 
> In this case, the risk is that both Readable and Appendable are "too general."  In particular, it means that overriding in a subclass won't mean what you might think it means.  Think of the overridings that are actually likely to happen -- those where you know something more about both what kind of Readable and Appendable you've got.
> 
> Let's say that Reader does:
> 
>     class Reader {
>         long transferTo(Writer out) { ... }
>     }
> 
> This is a totally sensible thing to want to do, since Writer has more flexibility than Appendable, and so such an implementation could be better than the default.
> 
> The problem is: **this is not an override, but an overload**. Which means that
> 
>     Reader r = ...
>     Writer.w = ...
>     r.transferTo(w)
> 
> will not mean the same thing as
> 
>     Readable rr = r;
>     Appendable ww = w;
>     r.transferTo(ww);
> 
> Because InputStream.transferTo() is not an override of Readable.appendTo().  This is serious puzzler-bait!  Instance method dispatch is not supposed to depend on the static types involved, but that's sure what it looks like is happening here.
> 
> **IMO, this is a fatal API design error for this method**. Instead, Readable.transferTo() should probably be a static method, so that it does not give the illusion of being overridable.
> 
> I know default methods on highly abstract interfaces are very tempting, and the siren song of fluency calls to us, but we should be very, very careful about adding default methods to interfaces like Iterable or Readable -- essentially any of the Xxxable interfaces.
> 
> I think it is much better to make this a static method, and put concrete methods (with better implementations, that can take advantage of bulk write abilities, which Appendable lacks) on Reader as needed.  (InputStream already has this method.)
> 
> 
> On 11/17/2017 1:12 PM, Patrick Reinhart wrote:
>> Hi Roger and Alan,
>> 
>> I incorporated the latest feedback using version 1) from this latest post:
>> 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050004.html
>> 
>> 
>> The actual webrev is here:
>> 
>> http://cr.openjdk.java.net/~reinhapa/reviews/8066870/webrev.00
>> 
>> 
>> -Patrick
> 


From brian.goetz at oracle.com  Sun Nov 19 22:14:17 2017
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 19 Nov 2017 17:14:17 -0500
Subject: RFR: 8066870 Add Readable::transferTo(Appendable)
In-Reply-To: <BDD11B34-B857-4250-93E0-D32C69BDE18B@reini.net>
References: <0FD2C7CD-D69E-4206-B0E6-0B95A21EEDEF@reini.net>
 <274aa1fc-176a-f379-82ab-fd625e568b34@oracle.com>
 <BDD11B34-B857-4250-93E0-D32C69BDE18B@reini.net>
Message-ID: <e3adbda1-49c9-9cd4-17d7-7f62aea420c1@oracle.com>

I presume you mean Reader.transferTo(Writer)?? This seems fine, and you 
can have a much better implementation for Reader->Writer than for 
Readable->Appendable.? (Do we get patches for those 30 places too?)



On 11/19/2017 3:01 PM, Patrick Reinhart wrote:
> Having a static method on Appendable instead of a default one seem reasonable to me too.
>
> Would it be a problem to have an additional transferTo() method on Readable as in your overload example though similar to IntputStream? My researches of the JDK code base found at least 30 places where a simple transferTo on a Reader could have been used to transfer all data to a Writer. Also some less usages where a combination of Reader -> CharBuffer or CharBuffer -> Appendable could have been used to. This analysis lead to the idea to have a default method for those use cases instead may be use a separate static method for Readable/Appendable and one on a Reader as on the InputStream
>
> -Patrick
>
>
>> Am 19.11.2017 um 14:42 schrieb Brian Goetz <brian.goetz at oracle.com>:
>>
>> Late to this thread, but ...
>>
>> TL;DR: I think this method, as proposed, is fatally flawed; it should be a static method rather than a default method.
>>
>>
>> We need to be very, very careful about adding default methods like this to highly abstract interfaces like Readable (the -able suffix is often the giveaway that you're in murky waters wrt default methods).  There are many pitfalls one can run into here; the one that gets us here is that attempted overrides can easily and accidentally become overloads.
>>
>> DIGRESSION -- A LESSON FROM 8
>>
>> By way of background, we added Function.compose(...) in Java 8, when both functional interfaces and default methods were new, and this turned out to be a mistake.  This seemed a no-brainer (in j.l.f.Function), but didn't turn out so well.  We added:
>>
>> intf Function<T,U> {
>>      <V> Function<T,V> compose(Function<U,V> g);
>> }
>>
>> But note also that
>>
>> intf BinaryOperator<T> extends Function<T,T> {
>> }
>>
>> As such, binOp.compose(binOp) yields a Function<T,T>, not a BinOp<T>.  Oops, that's not what we wanted!  If we try and override it:
>>
>> intf BinaryOperator<T> extends Function<T,T> {
>>      BinaryOperator<T> compose(BinaryOperator<T> g);
>> }
>>
>> we haven't really overridden compose(), but instead we've overloaded it.  And now we have potential ambiguities in overload resolution because
>>
>>    f.compose(t -> t)
>>
>> is compatible with both overrides of compose().  And since we don't have overloading on return types, we can't even use the return type to disambiguate:
>>
>>    BinaryOperator<T> composed = f.compose(t -> t) // nope
>>
>> The siren song here was the desire for fluency; this was just the wrong place to put a compose() method.  This method interacted with inheritance in two ways; it could be overridden, and it was also desirable for it to have distinguished behavior for distinguished subtypes of its argument types.  This was just too many degrees of freedom, and it painted us into a corner. Function was too general a place to put a default method like compose() that had such potential to interact with inheritance, but we were so excited about the prospects of saying "f.compose(g)" that we didn't think it through.
>>
>> RETURNING TO THE CURRENT ISSUE
>>
>> Now, while you could claim this is not an exact analogy (i.e., transferTo doesn't take a lambda, which was one ingredient of the problems with compose), the reality is that the higher up in the hierarchy you go, the more risky adding defaults is.  There still is a big interaction risk here.
>>
>> In this case, the risk is that both Readable and Appendable are "too general."  In particular, it means that overriding in a subclass won't mean what you might think it means.  Think of the overridings that are actually likely to happen -- those where you know something more about both what kind of Readable and Appendable you've got.
>>
>> Let's say that Reader does:
>>
>>      class Reader {
>>          long transferTo(Writer out) { ... }
>>      }
>>
>> This is a totally sensible thing to want to do, since Writer has more flexibility than Appendable, and so such an implementation could be better than the default.
>>
>> The problem is: **this is not an override, but an overload**. Which means that
>>
>>      Reader r = ...
>>      Writer.w = ...
>>      r.transferTo(w)
>>
>> will not mean the same thing as
>>
>>      Readable rr = r;
>>      Appendable ww = w;
>>      r.transferTo(ww);
>>
>> Because InputStream.transferTo() is not an override of Readable.appendTo().  This is serious puzzler-bait!  Instance method dispatch is not supposed to depend on the static types involved, but that's sure what it looks like is happening here.
>>
>> **IMO, this is a fatal API design error for this method**. Instead, Readable.transferTo() should probably be a static method, so that it does not give the illusion of being overridable.
>>
>> I know default methods on highly abstract interfaces are very tempting, and the siren song of fluency calls to us, but we should be very, very careful about adding default methods to interfaces like Iterable or Readable -- essentially any of the Xxxable interfaces.
>>
>> I think it is much better to make this a static method, and put concrete methods (with better implementations, that can take advantage of bulk write abilities, which Appendable lacks) on Reader as needed.  (InputStream already has this method.)
>>
>>
>> On 11/17/2017 1:12 PM, Patrick Reinhart wrote:
>>> Hi Roger and Alan,
>>>
>>> I incorporated the latest feedback using version 1) from this latest post:
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050004.html
>>>
>>>
>>> The actual webrev is here:
>>>
>>> http://cr.openjdk.java.net/~reinhapa/reviews/8066870/webrev.00
>>>
>>>
>>> -Patrick


From patrick at reini.net  Sun Nov 19 22:46:03 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Sun, 19 Nov 2017 23:46:03 +0100
Subject: RFR: 8066870 Add Readable::transferTo(Appendable)
In-Reply-To: <e3adbda1-49c9-9cd4-17d7-7f62aea420c1@oracle.com>
References: <0FD2C7CD-D69E-4206-B0E6-0B95A21EEDEF@reini.net>
 <274aa1fc-176a-f379-82ab-fd625e568b34@oracle.com>
 <BDD11B34-B857-4250-93E0-D32C69BDE18B@reini.net>
 <e3adbda1-49c9-9cd4-17d7-7f62aea420c1@oracle.com>
Message-ID: <37EA04C0-EBE6-4E16-883C-96EE3D426CA3@reini.net>

Yes, I meant the Reader.transferTo(Writer), and no I just did a quick search over the JDK code base and I would to takle them as a second step. I would make a couple of different patches for the various places due the fact that they are in different parts of the JDK?

The question would be if I should proceed with the Reader.transferTo(Writer) together with the static method on Readable.transferTo(Appendable)?

-Patrick


> Am 19.11.2017 um 23:14 schrieb Brian Goetz <brian.goetz at oracle.com>:
> 
> I presume you mean Reader.transferTo(Writer)?  This seems fine, and you can have a much better implementation for Reader->Writer than for Readable->Appendable.  (Do we get patches for those 30 places too?)
> 
> 
> 
> On 11/19/2017 3:01 PM, Patrick Reinhart wrote:
>> Having a static method on Appendable instead of a default one seem reasonable to me too.
>> 
>> Would it be a problem to have an additional transferTo() method on Readable as in your overload example though similar to IntputStream? My researches of the JDK code base found at least 30 places where a simple transferTo on a Reader could have been used to transfer all data to a Writer. Also some less usages where a combination of Reader -> CharBuffer or CharBuffer -> Appendable could have been used to. This analysis lead to the idea to have a default method for those use cases instead may be use a separate static method for Readable/Appendable and one on a Reader as on the InputStream
>> 
>> -Patrick
>> 
>> 
>>> Am 19.11.2017 um 14:42 schrieb Brian Goetz <brian.goetz at oracle.com>:
>>> 
>>> Late to this thread, but ...
>>> 
>>> TL;DR: I think this method, as proposed, is fatally flawed; it should be a static method rather than a default method.
>>> 
>>> 
>>> We need to be very, very careful about adding default methods like this to highly abstract interfaces like Readable (the -able suffix is often the giveaway that you're in murky waters wrt default methods).  There are many pitfalls one can run into here; the one that gets us here is that attempted overrides can easily and accidentally become overloads.
>>> 
>>> DIGRESSION -- A LESSON FROM 8
>>> 
>>> By way of background, we added Function.compose(...) in Java 8, when both functional interfaces and default methods were new, and this turned out to be a mistake.  This seemed a no-brainer (in j.l.f.Function), but didn't turn out so well.  We added:
>>> 
>>> intf Function<T,U> {
>>>     <V> Function<T,V> compose(Function<U,V> g);
>>> }
>>> 
>>> But note also that
>>> 
>>> intf BinaryOperator<T> extends Function<T,T> {
>>> }
>>> 
>>> As such, binOp.compose(binOp) yields a Function<T,T>, not a BinOp<T>.  Oops, that's not what we wanted!  If we try and override it:
>>> 
>>> intf BinaryOperator<T> extends Function<T,T> {
>>>     BinaryOperator<T> compose(BinaryOperator<T> g);
>>> }
>>> 
>>> we haven't really overridden compose(), but instead we've overloaded it.  And now we have potential ambiguities in overload resolution because
>>> 
>>>   f.compose(t -> t)
>>> 
>>> is compatible with both overrides of compose().  And since we don't have overloading on return types, we can't even use the return type to disambiguate:
>>> 
>>>   BinaryOperator<T> composed = f.compose(t -> t) // nope
>>> 
>>> The siren song here was the desire for fluency; this was just the wrong place to put a compose() method.  This method interacted with inheritance in two ways; it could be overridden, and it was also desirable for it to have distinguished behavior for distinguished subtypes of its argument types.  This was just too many degrees of freedom, and it painted us into a corner. Function was too general a place to put a default method like compose() that had such potential to interact with inheritance, but we were so excited about the prospects of saying "f.compose(g)" that we didn't think it through.
>>> 
>>> RETURNING TO THE CURRENT ISSUE
>>> 
>>> Now, while you could claim this is not an exact analogy (i.e., transferTo doesn't take a lambda, which was one ingredient of the problems with compose), the reality is that the higher up in the hierarchy you go, the more risky adding defaults is.  There still is a big interaction risk here.
>>> 
>>> In this case, the risk is that both Readable and Appendable are "too general."  In particular, it means that overriding in a subclass won't mean what you might think it means.  Think of the overridings that are actually likely to happen -- those where you know something more about both what kind of Readable and Appendable you've got.
>>> 
>>> Let's say that Reader does:
>>> 
>>>     class Reader {
>>>         long transferTo(Writer out) { ... }
>>>     }
>>> 
>>> This is a totally sensible thing to want to do, since Writer has more flexibility than Appendable, and so such an implementation could be better than the default.
>>> 
>>> The problem is: **this is not an override, but an overload**. Which means that
>>> 
>>>     Reader r = ...
>>>     Writer.w = ...
>>>     r.transferTo(w)
>>> 
>>> will not mean the same thing as
>>> 
>>>     Readable rr = r;
>>>     Appendable ww = w;
>>>     r.transferTo(ww);
>>> 
>>> Because InputStream.transferTo() is not an override of Readable.appendTo().  This is serious puzzler-bait!  Instance method dispatch is not supposed to depend on the static types involved, but that's sure what it looks like is happening here.
>>> 
>>> **IMO, this is a fatal API design error for this method**. Instead, Readable.transferTo() should probably be a static method, so that it does not give the illusion of being overridable.
>>> 
>>> I know default methods on highly abstract interfaces are very tempting, and the siren song of fluency calls to us, but we should be very, very careful about adding default methods to interfaces like Iterable or Readable -- essentially any of the Xxxable interfaces.
>>> 
>>> I think it is much better to make this a static method, and put concrete methods (with better implementations, that can take advantage of bulk write abilities, which Appendable lacks) on Reader as needed.  (InputStream already has this method.)
>>> 
>>> 
>>> On 11/17/2017 1:12 PM, Patrick Reinhart wrote:
>>>> Hi Roger and Alan,
>>>> 
>>>> I incorporated the latest feedback using version 1) from this latest post:
>>>> 
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050004.html
>>>> 
>>>> 
>>>> The actual webrev is here:
>>>> 
>>>> http://cr.openjdk.java.net/~reinhapa/reviews/8066870/webrev.00
>>>> 
>>>> 
>>>> -Patrick
> 


From goetz.lindenmaier at sap.com  Mon Nov 20 11:21:57 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 20 Nov 2017 11:21:57 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <5A0F2AA0.8020906@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <5A0F2AA0.8020906@oracle.com>
Message-ID: <367811cf4e0248298c9125f5bdece730@sap.com>

Hi Jon, 

thanks for your feedback.

Sorry for getting the javac/Javadoc wrong, I missed that. 
The point is that the option implementation there does not have
the possibility to accept an option but not document it.

javac:
I'd like to propose to add -help again.  javac else prints:
  javac: invalid flag: -help
  Usage: javac <options> <source files>
  use --help for a list of possible options
Which isn't that nice.

Javadoc:
I'd prefer to remove -help because then it's not documented
which is more streamlined with the overall idea of this change. And Javadoc
behaves "friendly": Javadoc -help prints the usage but exits with 
return code '1'.  I don't think that's a major problem.

I'll update the CSR accordingly once we decide on this.

I'm happy not to edit the properties files :) I'll revert that.
(Although I would have liked to edit some of the German translations.)

I fixed the typos in the CSR.

Best regards,
  Goetz

Change to javac:

--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java	Tue Oct 10 14:39:45 2017 +0200
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java	Mon Nov 20 12:19:49 2017 +0100
@@ -360,7 +360,7 @@
     },
 
     // Note: -h is already taken for "native header output directory".
-    HELP("-? --help", "opt.help", STANDARD, INFO) {
+    HELP("-? --help -help", "opt.help", STANDARD, INFO) {
         @Override
         public void process(OptionHelper helper, String option) throws InvalidValueException {
             Log log = helper.getLog();






> -----Original Message-----
> From: Jonathan Gibbons [mailto:jonathan.gibbons at oracle.com]
> Sent: Freitag, 17. November 2017 19:30
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; core-libs-
> dev at openjdk.java.net; 'compiler-dev at openjdk.java.net' <compiler-
> dev at openjdk.java.net>; serviceability-dev (serviceability-
> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Goetz,
> 
> I understand why you might want to ensure that a basic set of help options is
> supported,
> but I don't understand why that justifies removing older options, like "-help"
> for many tools.
> 
> In addition, I notice the CSR says:
> 
> 
> 
> 	Compatibility Risk Description:
> <https://bugs.openjdk.java.net/browse/JDK-8191477#> Only new flags are
> added, none removed.
> 
> 
> 
> But that is not true, since your edits for javac and javadoc remove the option
> completely.
> 
> Also, in the CSR, look for these typos:
>     serveral
>     deperecation
>     OpenJdk (should be OpenJDK)
> 
> 
> Also, I note that you've changed localized resource files. The usual procedure
> is to never
> touch those files, since they get updated later by Oracle's localization team.
> 
> -- Jon
> 
> 
> On 11/17/2017 03:23 AM, Lindenmaier, Goetz wrote:
> 
> 
> 	Hi,
> 
> 	please review this change. I also filed a CSR for this:
> 	http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> 	CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> 
> 	See the webrev for a detailed description of the changes.
> 
> 	If required, I'll make break-out changes to be reviewed separately.
> 
> 	I had posted a RFR before, but improved the change to
> 	give a more complete overview of currently supported flags
> 	for the CSR:
> 	http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> 
> 	Best regards,
> 	  Goetz.
> 
> 


From goetz.lindenmaier at sap.com  Mon Nov 20 11:57:11 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 20 Nov 2017 11:57:11 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <6C0CD3C8-D6DD-4A37-97DE-F4EF2E1A2D7A@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <6C0CD3C8-D6DD-4A37-97DE-F4EF2E1A2D7A@oracle.com>
Message-ID: <5c565f49102c4d79b44d514a0227eb16@sap.com>


Hi Robert, 

thanks for looking at my change.

I'm fine with listing the flags in a different order, but 
it's ambiguous. Java itslef lists "-? -h --help" therefore
I chose this for most of the tools, too.
But just tell me how to put it.
Below, I list all the option help messages for the 
tools on linux. --help-extra is quite consistent.

Best regards,
  Goetz.
  
  
 --help-extra, -X             Print help on extra options
 --help-extra, -X
 --help-extra, -X      Print help on non-standard options and exit
 -X                   print help on extra options to the output stream
 --help-extra  print help on extra options to the output stream
 --help-extra                         Print help on extra options           
 --help-extra           Give help on extra options


-? -h --help               display this help message
-? -h --help              display this help message
-h, --help (Print this help message.)
-?, --help                   Print this help message
-? -h --help                 Print this help message
--help, -h, -?  Display command line options and exit
-? -h --help                     Print this help message
-h -? --help                  Print this help message
-? -h --help
-? -h --help          : display this help message and exit
-? -h --help       :  display this help message and exit
-? -h --help      print this help message and exit
-? | -h | --help     to print this help message
jmap -? -h --help  to print this help message
usage: jps [-? -h --help]
-? -h --help to print this help message
-? -h --help  Prints this help message.
-? -h --help print this help message
-? -h --help          Print this synopsis of standard options and exit
Use "keytool -? -h or --help" for all available commands
--help        print this help message to the output stream
-?, -h, --help                       Print this help message
-h, --help, -?                        Print this help message
-?, -h, --help                       Print this help message
-? -h --help         Print this help message and exit
-?, -h, --help                  print this help message
-?, -h, --help                print this help message
-? -h --help           Print this help message
-?, -h, --help[:compat]    Give this, or optionally the compatibility, help
[-? -h --help]              Print this help message
jstatd -?|-h|--help


> -----Original Message-----
> From: Robert Field [mailto:robert.field at oracle.com]
> Sent: Freitag, 17. November 2017 20:07
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
> dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> JShell changes ?
> 
> The code change is fine.
> 
> The help change in the properties file is not consistent with the other items,
> note:        --help-extra, -X      Print help on?
>       so this should be:      ?help, -h, -?
> Or, if there is a tool-wide standard, then the ?help-extra entry should be
> changed.
> 
> The tests of ??help? should be updated to include the now documented ?-
> h? and ?-??
> 
> As Jon noted, the _ja and _zh_CN properties should not be touched.
> 
> -Robert
> 
> > On Nov 17, 2017, at 3:23 AM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi,
> >
> > please review this change. I also filed a CSR for this:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >
> > See the webrev for a detailed description of the changes.
> >
> > If required, I'll make break-out changes to be reviewed separately.
> >
> > I had posted a RFR before, but improved the change to
> > give a more complete overview of currently supported flags
> > for the CSR:
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> >
> > Best regards,
> >  Goetz.
> >


From scolebourne at joda.org  Mon Nov 20 13:27:38 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 20 Nov 2017 13:27:38 +0000
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <7b90a838-b5bd-5483-8ec8-a183c44b2c82@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <CACzrW9C+GekWNRdWVi1AhVs_CiPgWksde-6iRT1Z68-RhkziZw@mail.gmail.com>
 <098fb447-9d89-2d2d-20a8-06b85d128020@oracle.com>
 <CACzrW9CbB9TOto1UgNmiFfN7pB8D7gKVQBb89t1x_J20NoGpMg@mail.gmail.com>
 <1a518134-57a5-6ac9-40eb-c948b15b88b9@oracle.com>
 <3c3c8b89-9a47-9df4-61b8-cdb59850d88e@oracle.com>
 <34441778-1df2-259f-2d7a-8143f37650d8@Oracle.com>
 <15a5bd09-a811-0ee2-9ef5-e48672a70c02@oracle.com>
 <9ECB04EF-B9ED-4913-AF69-EB383783F6B7@oracle.com>
 <7b90a838-b5bd-5483-8ec8-a183c44b2c82@oracle.com>
Message-ID: <CACzrW9DbkT+adq-HCgZP119XQxwgf5OuQOgSmiBtXb+ysD1_uA@mail.gmail.com>

I've had a longer think about how to integrate this. Its very tricky,
as the unicode extensions create complex conflicts.

In general, my view is that Locale is too complex and overloaded with
different levels of meaning. Perhaps a different class should have
been added for more complex localization settings. It seems like an
are rife for puzzlers/security issues as unicode extensions are going
to be hugely undertested. (Most developers think of a Locale as
language+territory, and will only test for that, if they test at all).
It will be all too easy for text to appear on web pages or reports in
an unexpected calendar system or time-zone as a result of this change.
It also means that numbers might be output in an unexpected numbering
system or currency.

The tension is between what the developer has thought of and tested
for, and what a user might pass in. The mechanism for passing in these
extensions is partly subtle, being via the default locale. Although
even via an explicit locale, I suspect very few developers will be
sanitizing a Locale input from a user.

AFAICT, unicode extensions are not widely used at present. I can only
find use of "ca" in Chronology.ofLocale() and Calendar.getInstance().
So this is the key moment for deciding how they are used.

We are discussing 6 unicode extensions: "ca" (calendar system), "tz"
(time-zone), "cu" (currency), "nu" (numbering system), "fw" (first day
of week) and "rg" (region override).

Chronology, ZoneId, TimeZone and Currency ("ca", "tz", "cu") are not
really aspects of formatting at all, they are explicit aspects of the
associated value. eg. a ZonedDateTime explicitly has a chronology of
IsoChronology and a specific time zone. A Money class (Java will have
one at some point, probably after value types are added) explicitly
has a Currency.

You *really, really, really* don't want a unicode extension locale to
be changing the format of a Money object - turning $300 to ?300 just
because the user had -u-cu-gbp in their locale. The same applies to
the formatting of dates and times - the chronology and time-zone are
part of the value being formatted, not the format.

This just leaves "nu" (numbering system) where there is a case for the
unicode extension to be picked up directly. But doing so would cause a
LocalDate to be output as ????-??-?? (where ? is the digit for another
numbering system), While I think that should be supported, should it
be picked up automatically via the locale? No, it should be explicitly
selected by using DateTimeFormatter.withDecimalStyle() - which the
webrev does do.

The distinction here is that DateTimeFormatter (and our theoretical
MoneyFormatter) are formatting the whole state of the value object,
whereas DateFormatter and NumberFormatter essentially just format a
single number, using extra information alongside to help.

So, what to do? Some of these are new changes, some just need testing:

1) The changes to `Calendar.getInstance()` are not documented wrt
"tz". Currently it says it results in the "default time zone", which
isn't true anymore. I think this may be a behavioural compatibility
issue.

2) `DecimalStyle.ofLocale(Locale)` should use "nu" but does not.

3) `DateTimeFormatter.localizedBy(Locale)` should use "ca" to call
`withChronology`, `tz` to call `withZoneId` and `nu` to call
`withDecimalStyle`. This is a change to the CSR.

4) The phrase "Unicode extensions in the locale are ignored." would
apply to lots of methods across the JDK. In particular for this
webrev, it would need to be added to a lot more methods, such as the
default locale methods. Perhaps the phrase could be "If the locale has
unicode extensions, they are not used", which is slightly easier to
read. Or perhaps it shouldn't be added at all in most cases (ie.
unless unicode extensions are mentioned, assume that they are not
used.)

5) The withLocale(Locale) change should say "The locale is stored as
passed in, without further processing. If the locale has unicode
extensions, they may be used later in text processing. To set the
chronology, time-zone and decimal style from unicode extensions, see
localizedBy()."

6) The "rg" extension (and no other extensions) should be used when
looking up data to output these:
- DateTimeFormatterBuilder.appendText()
- DateTimeFormatterBuilder.appendLocalizedOffset()
- DateTimeFormatterBuilder.appendZoneText()
- DateTimeFormatterBuilder.appendChronologyText()
- DateTimeFormatterBuilder.appendLocalized()
- DateTimeFormatterBuilder.getLocalizedDateTimePattern()
This may be the case, but tests should ensure it.

7) WeekBasedFieldPrinterParser should use "fw"/"rg", which it already
does via WeekFields.of(Locale)

8) For clarity of future code, two additional methods would be useful:
- DateTimeFormatterBuilder.toFormatterIsoRoot()
- DateTimeFormatterBuilder.toFormatterIso(Locale)
These would set the chronology of the resulting DTF to be
IsoChronology.INSTANCE. The "root" variant would use `Locale.ROOT`.

9) Consider more generally what happens if TimeZone.getDefault() does
not match the "tz" extension of Locale.getDefault().

10) Consider how localizedBy(Locale) operates. Is it the same as
formatter
  .withChronology(Chronology.ofLocale(loc))
  .withZoneId(ZoneId.ofLocale(loc))
  .withDecimalStyle(DecimalStyle.of(loc))
or does it only set the chronology if "ca" if found, and only set
time-zone if "tz" is found and only set decimal style if "nu" is
found.

Perhaps this webrev should be broken into two or more parts, as it is
very large?


In summary, going forward it should be recognised that there is a
separation/difference between formatters of full values
(Money/Temporal) and old-style formatters of single numbers
(DateFormat, NumberFormat). Some extensions, "ca", "tz", "cu", are
part of the value in Money/Temporal, and so can't be overridden by the
locale. Methods like Chronology.ofLocale or ZoneId.of(Locale) are good
places to use the extensions, as they are explicit about what happens.

Stephen


On 15 November 2017 at 23:31, Naoto Sato <naoto.sato at oracle.com> wrote:
> Thanks, Lance. Corrected as suggested.
>
> http://cr.openjdk.java.net/~naoto/8191349/specdiff.02/overview-summary.html
> Also, I inserted "@since 10."
>
> Naoto
>
> On 11/15/17 3:06 PM, Lance Andersen wrote:
>>
>> Hi Naoto
>>
>> localizedBy, i would suggest changing:
>>
>> -   ?If the new locale contains ?ca???  to ?if the new locale contains the
>> ?ca???
>> - ?Unlike withLocale method? to Unlike the withLocale method?
>>
>> Best
>> Lance
>>>
>>> On Nov 15, 2017, at 5:36 PM, Naoto Sato <naoto.sato at oracle.com
>>> <mailto:naoto.sato at oracle.com>> wrote:
>>>
>>>
>>> http://cr.openjdk.java.net/~naoto/8191349/specdiff.01/overview-summary.html
>>
>>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
>> Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>
>>
>>
>

From goetz.lindenmaier at sap.com  Mon Nov 20 13:41:33 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 20 Nov 2017 13:41:33 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <71c9130c-a8b6-c811-b14f-564b6f38574e@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <71c9130c-a8b6-c811-b14f-564b6f38574e@oracle.com>
Message-ID: <c8eb03f177ed4a5d90aa2c98c6168ef2@sap.com>

Hi Alan, 

thanks for looking at my change.

Thanks for pointing to JEP 293. I see my change mostly
follows its ideas.
As Jon, I don't think asking for support of -help makes sense
as it's not according to the gnu style, and it's not that
hard to get it right anyways.

I'll remove the edits to the properties files.

The deprecated tools are
  orbd, 
  wsgen
  wsimport
  schemagen
Is that correct?
I'll remove them from my change.  The test has a list of tools not to test, 
I'll add them there.

Best regards,
  Goetz.



> -----Original Message-----
> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> Sent: Samstag, 18. November 2017 09:42
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; core-libs-
> dev at openjdk.java.net; 'compiler-dev at openjdk.java.net' <compiler-
> dev at openjdk.java.net>; serviceability-dev (serviceability-
> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> On 17/11/2017 11:23, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > please review this change. I also filed a CSR for this:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >
> > See the webrev for a detailed description of the changes.
> >
> A question for Jon Gibbons: In JEP 293 the guideline is that tools
> should support `--help`. Do you think this should be expanded to include
> `-help`, and `-?` (and maybe `-h` where it make sense)?
> 
> As regards the webrev then the changes to the localized resources can be
> dropped. As Jon noted, we don't usually edit these directly as they are
> bulk updated/replaced by translation drops that usually happen late in
> each release.
> 
> It's not clear to me that it's wroth trying to update the JAXB, JAX-WS,
> and CORBA tools. One reason the corresponding tool modules are
> deprecated-for-removal and there is a draft JEP to remove them
> completely [1]. In addition, the JAXB ad JAX-WS tools are problematic to
> change as they are owned by upstream projects on the Java EE github -
> any changes to the code in these modules needs to coordinated to avoid
> having a fork here.
> 
> -Alan
> 
> [1] http://openjdk.java.net/jeps/8189188

From goetz.lindenmaier at sap.com  Mon Nov 20 13:46:49 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 20 Nov 2017 13:46:49 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
Message-ID: <f0be5806bf4442eeb5802df736210ead@sap.com>

Hi Max, 

I think there are so many tools mixing both kinds of
options, that it's rather a gain if all at least document
the same, up to date help message, than if the documentation 
is skipped for some.

After my change, all the help messages are quite similar.
I updated them to use the same wording while trying to
keep the sentence structure in accordance with the other
documented flags, see below.

Best regards,
  Goetz.


 
-? -h --help               display this help message
-? -h --help              display this help message
-h, --help (Print this help message.)
-?, --help                   Print this help message
-? -h --help                 Print this help message
--help, -h, -?  Display command line options and exit
-? -h --help                     Print this help message
-h -? --help                  Print this help message
-? -h --help
-? -h --help          : display this help message and exit
-? -h --help       :  display this help message and exit
-? -h --help      print this help message and exit
-? | -h | --help     to print this help message
jmap -? -h --help  to print this help message
usage: jps [-? -h --help]
-? -h --help to print this help message
-? -h --help  Prints this help message.
-? -h --help print this help message
-? -h --help          Print this synopsis of standard options and exit
Use "keytool -? -h or --help" for all available commands
--help        print this help message to the output stream
-?, -h, --help                       Print this help message
-h, --help, -?                        Print this help message
-?, -h, --help                       Print this help message
-? -h --help         Print this help message and exit
-?, -h, --help                  print this help message
-?, -h, --help                print this help message
-? -h --help           Print this help message
-?, -h, --help[:compat]    Give this, or optionally the compatibility, help
[-? -h --help]              Print this help message
jstatd -?|-h|--help


> -----Original Message-----
> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> Sent: Sonntag, 19. November 2017 01:28
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
> dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> I am OK with all commands supporting --help, but I am not sure if every tool
> should show it on the help screen if the tools's other options are still using
> the old single-"-" style. It looks like the tools are half-converted.
> 
> Is there a timetable to add "--" support to all tools?
> 
> Thanks
> Max
> 
> > On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi,
> >
> > please review this change. I also filed a CSR for this:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >
> > See the webrev for a detailed description of the changes.
> >
> > If required, I'll make break-out changes to be reviewed separately.
> >
> > I had posted a RFR before, but improved the change to
> > give a more complete overview of currently supported flags
> > for the CSR:
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> >
> > Best regards,
> >  Goetz.
> >


From Alan.Bateman at oracle.com  Mon Nov 20 14:05:57 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 20 Nov 2017 14:05:57 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <c8eb03f177ed4a5d90aa2c98c6168ef2@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <71c9130c-a8b6-c811-b14f-564b6f38574e@oracle.com>
 <c8eb03f177ed4a5d90aa2c98c6168ef2@sap.com>
Message-ID: <191cb8f3-8c15-d98f-0650-516c1f5a51b6@oracle.com>

On 20/11/2017 13:41, Lindenmaier, Goetz wrote:
> :
>
> The deprecated tools are
>    orbd,
>    wsgen
>    wsimport
>    schemagen
> Is that correct?
>
Yes, plus xjc, idlj, servertool and tnameserv (the full list is in the 
draft JEP that I linked to).

-Alan

From Alan.Bateman at oracle.com  Mon Nov 20 14:42:03 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 20 Nov 2017 14:42:03 +0000
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
In-Reply-To: <5A0F13FF.8090406@oracle.com>
References: <5A0E4703.3040409@oracle.com>
 <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>
 <5A0F13FF.8090406@oracle.com>
Message-ID: <4c1656fa-657c-ca96-6c34-36bd36634092@oracle.com>



On 17/11/2017 16:53, Xueming Shen wrote:
> On 11/17/17, 3:35 AM, Alan Bateman wrote:
>> :
>>
>> 1. getRealName is very welcome but I think it should be a no-arg 
>> method on JarEntry, not JarFile. That would make it easier to use and 
>> also avoids the temptation to call JarFile.getRealName with an entry 
>> in a different JAR file.
>>
>
> I was considering to put it into JarEntry. The only concern is that 
> all mr jarfile related stuff
> are in JarFile, it's kinda easy/convenient to refer to the concept "if 
> multi-release is..." in
> JarFile than JarEntry, especially considering mr jarfile normally 
> should only be interested/
> used by limited group of developer, it might be better to simply put 
> it near those mr related
> methods. But I don't have a strong opinion about it. I can move it 
> into JarEntry, if it's desired.
The existing JarFile methods yield objects or streams of JarEntry. It 
would be a bit inconsistent to introduce a method that returns an entry 
name as a String. In the opposite corner, JarEntry defines getName and 
it shouldn't be a surprise to have it define getRealName too.

The other awkward issue with getRealName(JarEntry) is that it has to 
deal with the case that someone calls it with a JarEntry from a 
different JarFile. And like getInputStream(JarEntry), it needs to be 
concerned with a closed JarFile.

So I think on balance JarEntry::getRealName is better. It does mean that 
the javadoc needs to reference the MR text in JarFile.

-Alan.

From weijun.wang at oracle.com  Mon Nov 20 14:48:37 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 20 Nov 2017 22:48:37 +0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <f0be5806bf4442eeb5802df736210ead@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
 <f0be5806bf4442eeb5802df736210ead@sap.com>
Message-ID: <C882395B-87CF-428B-A74D-707490930E07@oracle.com>

Hi Goetz

I understand your intention.

If the reason is that one day every tool will switch to this new style, please at least do not include kinit, klist and ktab. These Windows-only commands are meant to emulate MIT krb5 tools with the same names and we need to keep the option (and maybe the help screen) as similar as possible.

I am OK with supporting the --help option undocumented.

Thanks
Max

> On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi Max, 
> 
> I think there are so many tools mixing both kinds of
> options, that it's rather a gain if all at least document
> the same, up to date help message, than if the documentation 
> is skipped for some.
> 
> After my change, all the help messages are quite similar.
> I updated them to use the same wording while trying to
> keep the sentence structure in accordance with the other
> documented flags, see below.
> 
> Best regards,
>  Goetz.
> 
> 
> 
> -? -h --help               display this help message
> -? -h --help              display this help message
> -h, --help (Print this help message.)
> -?, --help                   Print this help message
> -? -h --help                 Print this help message
> --help, -h, -?  Display command line options and exit
> -? -h --help                     Print this help message
> -h -? --help                  Print this help message
> -? -h --help
> -? -h --help          : display this help message and exit
> -? -h --help       :  display this help message and exit
> -? -h --help      print this help message and exit
> -? | -h | --help     to print this help message
> jmap -? -h --help  to print this help message
> usage: jps [-? -h --help]
> -? -h --help to print this help message
> -? -h --help  Prints this help message.
> -? -h --help print this help message
> -? -h --help          Print this synopsis of standard options and exit
> Use "keytool -? -h or --help" for all available commands
> --help        print this help message to the output stream
> -?, -h, --help                       Print this help message
> -h, --help, -?                        Print this help message
> -?, -h, --help                       Print this help message
> -? -h --help         Print this help message and exit
> -?, -h, --help                  print this help message
> -?, -h, --help                print this help message
> -? -h --help           Print this help message
> -?, -h, --help[:compat]    Give this, or optionally the compatibility, help
> [-? -h --help]              Print this help message
> jstatd -?|-h|--help
> 
> 
>> -----Original Message-----
>> From: Weijun Wang [mailto:weijun.wang at oracle.com]
>> Sent: Sonntag, 19. November 2017 01:28
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
>> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
>> dev at openjdk.java.net>
>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
>> 
>> I am OK with all commands supporting --help, but I am not sure if every tool
>> should show it on the help screen if the tools's other options are still using
>> the old single-"-" style. It looks like the tools are half-converted.
>> 
>> Is there a timetable to add "--" support to all tools?
>> 
>> Thanks
>> Max
>> 
>>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com> wrote:
>>> 
>>> Hi,
>>> 
>>> please review this change. I also filed a CSR for this:
>>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
>> helpMessage/webrev.02/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>>> 
>>> See the webrev for a detailed description of the changes.
>>> 
>>> If required, I'll make break-out changes to be reviewed separately.
>>> 
>>> I had posted a RFR before, but improved the change to
>>> give a more complete overview of currently supported flags
>>> for the CSR:
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
>> October/028615.html
>>> 
>>> Best regards,
>>> Goetz.
>>> 
> 


From Alan.Bateman at oracle.com  Mon Nov 20 15:27:43 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 20 Nov 2017 15:27:43 +0000
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
In-Reply-To: <5A0F13FF.8090406@oracle.com>
References: <5A0E4703.3040409@oracle.com>
 <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>
 <5A0F13FF.8090406@oracle.com>
Message-ID: <1c71e540-88a2-4f6f-5f2b-06b62b955df7@oracle.com>

On 17/11/2017 16:53, Xueming Shen wrote:
> :
>>
>> 3. Is ZipFile.entryNameStream really needed? Just asking because 
>> zf.stream().map(ZipEntry::getName) is possible today.
>>
> It's not a "must" for sure. The motivation behind this is that my 
> observation of most normal use scenario
> inside JDK is that only the "name" info is interested/collect/used. 
> The use pattern usually is
>
> zf.stream().map(ZipEntry::getName)
>
> same for the old Enumeration case, only the "name" is used and the 
> "entry" object is thrown away mostly.
>
> Other than the memory consumption (showed in those two snapshots), 
> it's also relatively costly to create
> the ZipEntry especially its "esxdostime" calculation. The jmh numbers 
> from a simple benchmark test
> suggests the entryNameStream is about 15-20% faster. So, the only 
> reason it's there is for better
> performance.
I can believe that it is faster but it does loose the ability to filter 
(it requires checking for a trailing "/" to filter out directories for 
example). I guess I don't object to adding this but it feels like it an 
opportunity beyond JDK-8189611.

-Alan

From xueming.shen at oracle.com  Mon Nov 20 18:27:28 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 20 Nov 2017 10:27:28 -0800
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
In-Reply-To: <1c71e540-88a2-4f6f-5f2b-06b62b955df7@oracle.com>
References: <5A0E4703.3040409@oracle.com>
 <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>
 <5A0F13FF.8090406@oracle.com>
 <1c71e540-88a2-4f6f-5f2b-06b62b955df7@oracle.com>
Message-ID: <5A131E90.6090509@oracle.com>

Hi Alan,

Here is the updated webrev with

(1) to move JarFile.getRealName into JarEntry
(2) to hide ZipFile.entryNameStream() from the public
(3) to reword the JarFile.versionedStream() to scope the "latest versined"

http://cr.openjdk.java.net/~sherman/8189611/webrev

thanks,
Sherman

On 11/20/17, 7:27 AM, Alan Bateman wrote:
> On 17/11/2017 16:53, Xueming Shen wrote:
>> :
>>>
>>> 3. Is ZipFile.entryNameStream really needed? Just asking because 
>>> zf.stream().map(ZipEntry::getName) is possible today.
>>>
>> It's not a "must" for sure. The motivation behind this is that my 
>> observation of most normal use scenario
>> inside JDK is that only the "name" info is interested/collect/used. 
>> The use pattern usually is
>>
>> zf.stream().map(ZipEntry::getName)
>>
>> same for the old Enumeration case, only the "name" is used and the 
>> "entry" object is thrown away mostly.
>>
>> Other than the memory consumption (showed in those two snapshots), 
>> it's also relatively costly to create
>> the ZipEntry especially its "esxdostime" calculation. The jmh numbers 
>> from a simple benchmark test
>> suggests the entryNameStream is about 15-20% faster. So, the only 
>> reason it's there is for better
>> performance.
> I can believe that it is faster but it does loose the ability to 
> filter (it requires checking for a trailing "/" to filter out 
> directories for example). I guess I don't object to adding this but it 
> feels like it an opportunity beyond JDK-8189611.
>
> -Alan


From paul.sandoz at oracle.com  Mon Nov 20 18:34:22 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 20 Nov 2017 10:34:22 -0800
Subject: 8181175 Stream.concat behaves like terminal operation
In-Reply-To: <3dcdae3d-0706-8f5b-2be3-0f934e5dc285@oracle.com>
References: <7A97602E-196A-49EF-B83F-086ACC591BA6@oracle.com>
 <3dcdae3d-0706-8f5b-2be3-0f934e5dc285@oracle.com>
Message-ID: <376868E1-F513-4FC6-8895-F27F5CB9A204@oracle.com>



> On 17 Nov 2017, at 17:18, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Hi Paul,
> 
> The normative text about binding to the source and subsequent modifications to the source possibly not being reflected in the stream makes sense.
> 
> I'm having trouble understanding the API note though. What does "optimal" mean? What about concatenating multiple streams would not be optimal?
> 

Yeah, you are in good company pointing that out :-)

I updated to:

* @apiNote
* To preserve optimization opportunities this method binds each stream to
* its source and accepts only two streams as parameters.  For example, the
* exact size of the concatenated stream source can be computed if the exact
* size of each input stream source is known.
* To concatenate more streams without binding, or nested calls to this
* method, try creating a stream of streams and flat-mapping with the
* identity function, for example:
* <pre>{@code
*     Stream<T> concat = Stream.of(s1, s2, s3, s4).flatMap(s -> s);
* }</pre>

We could support three or more streams while preserving some characteristics, that complicates the concatenating spliterator a little bit. Each stream would still need to be bound.

Patch updated to include the primitive streams:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8181175-concat-eager-binding/webrev/

Thanks,
Paul.

From paul.sandoz at oracle.com  Mon Nov 20 19:56:42 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 20 Nov 2017 11:56:42 -0800
Subject: Moving dynamic constants to 11 <was> Re: [10] RFR 8186046 Minimal
 ConstantDynamic support
In-Reply-To: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
Message-ID: <15A29A84-1420-4E69-A715-A68B2DF436AA@oracle.com>

Hi,

The schedule of dynamic constants has been adjusted, the JEP is currently proposed to target for 11.

There is risk to integrating a change such as constant dynamic this late in the 10 release schedule. Instead it's better, and more aligned with the new release process, to integrate early on into the main repository so it has time to bake.

I don?t anticipate there will be significant changes to the existing reviews in progress (code, CSRs, VM specification), so we can keep the momentum, integrate, then iterate.

Thanks,
Paul.

> On 26 Oct 2017, at 10:03, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
> Hi,
> 
> Please review the following patch for minimal dynamic constant support:
> 
>  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>
> 
>  https://bugs.openjdk.java.net/browse/JDK-8186046 <https://bugs.openjdk.java.net/browse/JDK-8186046>
>  https://bugs.openjdk.java.net/browse/JDK-8186209 <https://bugs.openjdk.java.net/browse/JDK-8186209>
> 
> This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good.
> 
> By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex.
> 
> A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository).
> 
> Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments.
> 
> The CSR for the VM specification is here:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8189199 <https://bugs.openjdk.java.net/browse/JDK-8189199>
> 
> the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles).
> 
> Any AoT-related work will be deferred to a future release.
> 
> ?
> 
> This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte).
> 
> We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches.
> 
> ?
> 
> Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants.
> 
> One test uses class file bytes produced from a modified version of asmtools.  The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test.
> 
> ?
> 
> Paul.


From mark.reinhold at oracle.com  Mon Nov 20 20:14:04 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 20 Nov 2017 12:14:04 -0800
Subject: Moving dynamic constants to 11 <was> Re: [10] RFR 8186046 Minimal
 ConstantDynamic support
In-Reply-To: <15A29A84-1420-4E69-A715-A68B2DF436AA@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <15A29A84-1420-4E69-A715-A68B2DF436AA@oracle.com>
Message-ID: <20171120121404.172170633@eggemoggin.niobe.net>

2017/11/20 11:56:42 -0800, paul.sandoz at oracle.com:
> The schedule of dynamic constants has been adjusted, the JEP is
> currently proposed to target for 11.
> 
> There is risk to integrating a change such as constant dynamic this
> late in the 10 release schedule. Instead it's better, and more aligned
> with the new release process, to integrate early on into the main
> repository so it has time to bake.

Thanks for the update.  It's too bad that JEP 309 won't make JDK 10,
but this sounds like the right decision.

- Mark

From brian.burkhalter at oracle.com  Tue Nov 21 00:53:56 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 20 Nov 2017 16:53:56 -0800
Subject: RFR 8191516: OutputStream.write(byte[], int,
 int) could have fewer parameter bounds checks
Message-ID: <2177CFA1-A5B3-4F5B-9A57-25E5AF7D06DE@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8191516
http://cr.openjdk.java.net/~bpb/8191516/webrev.00/

Change OutputStream.write(byte[],int,int) to use the same three parameter bounds checks used by InputStream.read(byte[],int,int) instead of the five checks currently used. This change is covered by the existing test jdk/java/io/OutputStream/WriteParams.java.

Thanks,

Brian

From naoto.sato at oracle.com  Tue Nov 21 01:45:50 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 20 Nov 2017 17:45:50 -0800
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <CACzrW9DbkT+adq-HCgZP119XQxwgf5OuQOgSmiBtXb+ysD1_uA@mail.gmail.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <CACzrW9C+GekWNRdWVi1AhVs_CiPgWksde-6iRT1Z68-RhkziZw@mail.gmail.com>
 <098fb447-9d89-2d2d-20a8-06b85d128020@oracle.com>
 <CACzrW9CbB9TOto1UgNmiFfN7pB8D7gKVQBb89t1x_J20NoGpMg@mail.gmail.com>
 <1a518134-57a5-6ac9-40eb-c948b15b88b9@oracle.com>
 <3c3c8b89-9a47-9df4-61b8-cdb59850d88e@oracle.com>
 <34441778-1df2-259f-2d7a-8143f37650d8@Oracle.com>
 <15a5bd09-a811-0ee2-9ef5-e48672a70c02@oracle.com>
 <9ECB04EF-B9ED-4913-AF69-EB383783F6B7@oracle.com>
 <7b90a838-b5bd-5483-8ec8-a183c44b2c82@oracle.com>
 <CACzrW9DbkT+adq-HCgZP119XQxwgf5OuQOgSmiBtXb+ysD1_uA@mail.gmail.com>
Message-ID: <c6d595c3-15df-9b12-567a-4ae1a1e4bfdd@oracle.com>

Hi Stephen, please see my comments below.

On 11/20/17 5:27 AM, Stephen Colebourne wrote:
> I've had a longer think about how to integrate this. Its very tricky,
> as the unicode extensions create complex conflicts.
> 
> In general, my view is that Locale is too complex and overloaded with
> different levels of meaning. Perhaps a different class should have
> been added for more complex localization settings. It seems like an
> are rife for puzzlers/security issues as unicode extensions are going
> to be hugely undertested. (Most developers think of a Locale as
> language+territory, and will only test for that, if they test at all).
> It will be all too easy for text to appear on web pages or reports in
> an unexpected calendar system or time-zone as a result of this change.
> It also means that numbers might be output in an unexpected numbering
> system or currency.
> 
> The tension is between what the developer has thought of and tested
> for, and what a user might pass in. The mechanism for passing in these
> extensions is partly subtle, being via the default locale. Although
> even via an explicit locale, I suspect very few developers will be
> sanitizing a Locale input from a user.
> 
> AFAICT, unicode extensions are not widely used at present. I can only
> find use of "ca" in Chronology.ofLocale() and Calendar.getInstance().
> So this is the key moment for deciding how they are used.
> 
> We are discussing 6 unicode extensions: "ca" (calendar system), "tz"
> (time-zone), "cu" (currency), "nu" (numbering system), "fw" (first day
> of week) and "rg" (region override).
> 
> Chronology, ZoneId, TimeZone and Currency ("ca", "tz", "cu") are not
> really aspects of formatting at all, they are explicit aspects of the
> associated value. eg. a ZonedDateTime explicitly has a chronology of
> IsoChronology and a specific time zone. A Money class (Java will have
> one at some point, probably after value types are added) explicitly
> has a Currency.
> 
> You *really, really, really* don't want a unicode extension locale to
> be changing the format of a Money object - turning $300 to ?300 just
> because the user had -u-cu-gbp in their locale. The same applies to
> the formatting of dates and times - the chronology and time-zone are
> part of the value being formatted, not the format.
> 
> This just leaves "nu" (numbering system) where there is a case for the
> unicode extension to be picked up directly. But doing so would cause a
> LocalDate to be output as ????-??-?? (where ? is the digit for another
> numbering system), While I think that should be supported, should it
> be picked up automatically via the locale? No, it should be explicitly
> selected by using DateTimeFormatter.withDecimalStyle() - which the
> webrev does do.
> 
> The distinction here is that DateTimeFormatter (and our theoretical
> MoneyFormatter) are formatting the whole state of the value object,
> whereas DateFormatter and NumberFormatter essentially just format a
> single number, using extra information alongside to help.
> 
> So, what to do? Some of these are new changes, some just need testing:
> 
> 1) The changes to `Calendar.getInstance()` are not documented wrt
> "tz". Currently it says it results in the "default time zone", which
> isn't true anymore. I think this may be a behavioural compatibility
> issue.

Explicitly document that it will use the time zone in locale.

> 
> 2) `DecimalStyle.ofLocale(Locale)` should use "nu" but does not.

Document it in the javadoc.

> 
> 3) `DateTimeFormatter.localizedBy(Locale)` should use "ca" to call
> `withChronology`, `tz` to call `withZoneId` and `nu` to call
> `withDecimalStyle`. This is a change to the CSR.

Besides that "nu" needs to be spec'ed out, isn't calling withXXXX() an 
implementation note?

> 
> 4) The phrase "Unicode extensions in the locale are ignored." would
> apply to lots of methods across the JDK. In particular for this
> webrev, it would need to be added to a lot more methods, such as the
> default locale methods. Perhaps the phrase could be "If the locale has
> unicode extensions, they are not used", which is slightly easier to
> read. Or perhaps it shouldn't be added at all in most cases (ie.
> unless unicode extensions are mentioned, assume that they are not
> used.)

Removed the phrase.

> 
> 5) The withLocale(Locale) change should say "The locale is stored as
> passed in, without further processing. If the locale has unicode
> extensions, they may be used later in text processing. To set the
> chronology, time-zone and decimal style from unicode extensions, see
> localizedBy()."

Added.

> 
> 6) The "rg" extension (and no other extensions) should be used when
> looking up data to output these:
> - DateTimeFormatterBuilder.appendText()
> - DateTimeFormatterBuilder.appendLocalizedOffset()
> - DateTimeFormatterBuilder.appendZoneText()
> - DateTimeFormatterBuilder.appendChronologyText()
> - DateTimeFormatterBuilder.appendLocalized()
> - DateTimeFormatterBuilder.getLocalizedDateTimePattern()
> This may be the case, but tests should ensure it.

Will need to add tests.

> 
> 7) WeekBasedFieldPrinterParser should use "fw"/"rg", which it already
> does via WeekFields.of(Locale)

Not sure what this means. Where is the file located?

> 
> 8) For clarity of future code, two additional methods would be useful:
> - DateTimeFormatterBuilder.toFormatterIsoRoot()
> - DateTimeFormatterBuilder.toFormatterIso(Locale)
> These would set the chronology of the resulting DTF to be
> IsoChronology.INSTANCE. The "root" variant would use `Locale.ROOT`.

This would be a nice addition.

> 
> 9) Consider more generally what happens if TimeZone.getDefault() does
> not match the "tz" extension of Locale.getDefault().

This should be considered case by case, and document on each occasion 
which would be honored.

> 
> 10) Consider how localizedBy(Locale) operates. Is it the same as
> formatter
>    .withChronology(Chronology.ofLocale(loc))
>    .withZoneId(ZoneId.ofLocale(loc))
>    .withDecimalStyle(DecimalStyle.of(loc))
> or does it only set the chronology if "ca" if found, and only set
> time-zone if "tz" is found and only set decimal style if "nu" is
> found.

IIRC, the localizedBy() is added so that withLocale() would behave as it 
is now. I think localizedBy() should also have the same effect as 
withLocale if the specified locale do not contain any 
calendar/timezone/numberingSystem extensions. Otherwise, say 
localizedBy(Locale.JAPAN) would be no-operation.

As we discussed in the previous email, we don't have ZoneId.ofLocale() yet.

> 
> Perhaps this webrev should be broken into two or more parts, as it is
> very large?
> 
> 
> In summary, going forward it should be recognised that there is a
> separation/difference between formatters of full values
> (Money/Temporal) and old-style formatters of single numbers
> (DateFormat, NumberFormat). Some extensions, "ca", "tz", "cu", are
> part of the value in Money/Temporal, and so can't be overridden by the
> locale. Methods like Chronology.ofLocale or ZoneId.of(Locale) are good
> places to use the extensions, as they are explicit about what happens.

Here is the spec diff from the previous one. Please let me know your 
thought.

http://cr.openjdk.java.net/~naoto/8191349/specdiff.03/overview-summary.html

Naoto

> 
> Stephen
> 
> 
> On 15 November 2017 at 23:31, Naoto Sato <naoto.sato at oracle.com> wrote:
>> Thanks, Lance. Corrected as suggested.
>>
>> http://cr.openjdk.java.net/~naoto/8191349/specdiff.02/overview-summary.html
>> Also, I inserted "@since 10."
>>
>> Naoto
>>
>> On 11/15/17 3:06 PM, Lance Andersen wrote:
>>>
>>> Hi Naoto
>>>
>>> localizedBy, i would suggest changing:
>>>
>>> -   ?If the new locale contains ?ca???  to ?if the new locale contains the
>>> ?ca???
>>> - ?Unlike withLocale method? to Unlike the withLocale method?
>>>
>>> Best
>>> Lance
>>>>
>>>> On Nov 15, 2017, at 5:36 PM, Naoto Sato <naoto.sato at oracle.com
>>>> <mailto:naoto.sato at oracle.com>> wrote:
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8191349/specdiff.01/overview-summary.html
>>>
>>>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
>>> Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>
>>>
>>>
>>

From paul.sandoz at oracle.com  Tue Nov 21 02:04:35 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 20 Nov 2017 18:04:35 -0800
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
In-Reply-To: <5A131E90.6090509@oracle.com>
References: <5A0E4703.3040409@oracle.com>
 <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>
 <5A0F13FF.8090406@oracle.com>
 <1c71e540-88a2-4f6f-5f2b-06b62b955df7@oracle.com>
 <5A131E90.6090509@oracle.com>
Message-ID: <BE9EE092-1BDD-4A34-A8CF-C9F93094D3DE@oracle.com>



> On 20 Nov 2017, at 10:27, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi Alan,
> 
> Here is the updated webrev with
> 
> (1) to move JarFile.getRealName into JarEntry
> (2) to hide ZipFile.entryNameStream() from the public
> (3) to reword the JarFile.versionedStream() to scope the "latest versined"
> 
> http://cr.openjdk.java.net/~sherman/8189611/webrev
> 

JarFile
?

 170     private static final JavaUtilZipFileAccess juzfa;

Convert to capitals?


 684         JarFileEntry asBasename(String name) {

s/asBasename/withBasename


 610     // placeholder for now
 611     String getRealName(JarEntry entry) {
 612         return entry.getRealName();
 613     }

No longer required? I dunno what calls it...


1123         final Enumeration<JarEntry> enum_ =
1124                 juzfa.entries(JarFile.this, JarFileEntry::new);

s/enum_/unfilteredEntries

You can also LVTI and replace the left hand type declaration with var if you like.

Same comments for JarVerifier


ZipFile
?

 592             return StreamSupport.stream(new EntrySpliterator<ZipEntry>(0, zsrc.total,
...
 623                 new EntrySpliterator<String>(0, zsrc.total, this::getEntryName), false);

Can you use <> ? Not sure of the type inference will work here.


Paul.

From paul.sandoz at oracle.com  Tue Nov 21 02:32:29 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 20 Nov 2017 18:32:29 -0800
Subject: RFR 8191516: OutputStream.write(byte[], int, int) could have
 fewer parameter bounds checks
In-Reply-To: <2177CFA1-A5B3-4F5B-9A57-25E5AF7D06DE@oracle.com>
References: <2177CFA1-A5B3-4F5B-9A57-25E5AF7D06DE@oracle.com>
Message-ID: <A4D0138F-9D6B-47A2-AB05-C762A4DCAE7B@oracle.com>



> On 20 Nov 2017, at 16:53, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8191516
> http://cr.openjdk.java.net/~bpb/8191516/webrev.00/
> 
> Change OutputStream.write(byte[],int,int) to use the same three parameter bounds checks used by InputStream.read(byte[],int,int) instead of the five checks currently used. This change is covered by the existing test jdk/java/io/OutputStream/WriteParams.java.
> 

See also Objects.checkFromIndexSize if you wanna use that instead.

Also the if len == 0 check is probably redundant, i doubt it makes any difference given the condition needs to be checked before entering the loop.

Paul.

From xueming.shen at oracle.com  Tue Nov 21 02:58:42 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 20 Nov 2017 18:58:42 -0800
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
In-Reply-To: <BE9EE092-1BDD-4A34-A8CF-C9F93094D3DE@oracle.com>
References: <5A0E4703.3040409@oracle.com>
 <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>
 <5A0F13FF.8090406@oracle.com>
 <1c71e540-88a2-4f6f-5f2b-06b62b955df7@oracle.com>
 <5A131E90.6090509@oracle.com>
 <BE9EE092-1BDD-4A34-A8CF-C9F93094D3DE@oracle.com>
Message-ID: <5A139662.2030105@oracle.com>

Thanks Paul!

Webrev has been updated as suggested.

http://cr.openjdk.java.net/~sherman/8189611/webrev

jdeps' VersionHelper.java still accesses the "getRealName()" via the 
SharedSecrets.
Since jdeps is being compiled/built with the bootjdk, I'm leaving it 
untouched for
now.

----------------------
  610 // placeholder for now
  611 String getRealName(JarEntry entry) {
  612 return entry.getRealName();
  613 } No longer required?

  I dunno what calls it...
---------------------------

sherman

From philipp.kunz at paratix.ch  Tue Nov 21 06:18:55 2017
From: philipp.kunz at paratix.ch (Philipp Kunz)
Date: Tue, 21 Nov 2017 07:18:55 +0100
Subject: JDK-6372077: JarFile.getManifest() should handle manifest
 attribute names up to 70 bytes
In-Reply-To: <88b89995-cfe0-d439-d63d-699c628e2315@paratix.ch>
References: <9a4edee0-4edd-caaa-9970-61df083d39df@paratix.ch>
 <02abcb68-2294-c733-5048-b1f81ee99435@oracle.com>
 <88b89995-cfe0-d439-d63d-699c628e2315@paratix.ch>
Message-ID: <a44d4a4c-88b8-9773-75e5-b2ca979bdec1@paratix.ch>

Hi everyone,

I haven't got any reply now for around three weeks and now i start to 
wonder if I just missed it or if I should refine my approach to find a 
sponsor or if it helped if I presented a ready patch or if noone 
considers this important enough or anything else whatever. This is only 
my second contribution hence I don't know the procedure well.

One point maybe worth to point out again is that I don't want to support 
manifest headers longer than 70 character, just up to 70, which has 
always been the intention but has only worked up to 68. This might have 
been written confusingly in my last email.

As far as I understood, I should first get a sponsor. In any case, is 
there any suggestion for how to proceed?

Regards,
Philipp



On 03.11.2017 00:04, Philipp Kunz wrote:
> Hi Sean and Max and all others,
>
> Thank you Sean for the hint about the right mailing list. And thanks 
> also for his hint to Max to make smaller portions of changes.
>
> I would like to contribute a fix for JDK-6372077 which is about 
> JarFile.getManifest() should handle manifest attribute name[s longer 
> than] 70 bytes.
>
> It looks like the bug is caused by Manifest.make72Safe breaking lines 
> at 70 bytes instead of 72 despite its comment and name 
> (http://hg.openjdk.java.net/jdk10/master/file/tip/src/java.base/share/classes/java/util/jar/Manifest.java#l176).The 
> resulting StringBuffer has then lines of 72 bytes maximum each 
> including the following line break. Without the line break that leaves 
> 70 bytes of characters per line. On the other hand, header names can 
> be up to 70 bytes (only single-byte utf-8 characters) and cannot be 
> broken across a line break and need to be followed by a colon and a 
> space which must be on the same line too according to the 
> specification. When breaking at 70 bytes excluding the line break, 
> however, long header names don't fit in one line together with the 
> colon space delimiter because there is not sufficient space.
> Manifests with names up to 70 bytes long can still be written without 
> immediate exception but the resulting manifests are illegal in my 
> opinion. When later reading such manifests 
> (http://hg.openjdk.java.net/jdk10/master/file/tip/src/java.base/share/classes/java/util/jar/Attributes.java#l406), 
> an error occurs as a consequence of the bad manifest. This is more or 
> less the current situation and also what JDK-6372077 already knew.
>
>  --> After all, in order to fix it, i'd like to propose to make 
> manifest file lines wider by two bytes.
>
> The only proper alternative that came into my mind would be to change 
> the manifest specification and reduce the maximum header name length 
> there by two and also in the code. If that would break any existing 
> code i guess that would affect code only that produced invalid 
> manifests and would be acceptable.
>
> Supporting all existing and possibly invalid manifests would mean to 
> add support for reading headers the delimiters of which are broken 
> onto the next line which I consider too complex with respect to the 
> value added and even more so considering that those invalid manifest 
> can be assumed to have been detected as such by reading them and also 
> because it would be a feature that would be used less and less over 
> time if the code to write manifest is changed at the same time to 
> produce only valid manifests in the discussed respect here. I don't 
> think this should be actually done.
>
> Before I actually do the leg work, i'd like to ask, if there are 
> concerns or objections or tips for such a change or if anyone can or 
> cannot follow the reasoning and the conclusion to make manifests 2 
> bytes wider or if i missed an important point altogether.
>
> In case there will be a consent about how to solve this, would someone 
> volunteer to sponsor? That may be less urgent at the moment than the 
> question above about how to proceed.
>
> Philipp
>
>
> On 12.10.2017 22:32, Sean Mullan wrote:
>> Hi Phillip,
>>
>> All of these bugs are in the core-libs area, so I am copying the 
>> core-libs-dev list since that is where they should be discussed and 
>> reviewed. I have -bcc-ed security-dev (where this was originally 
>> posted).
>>
>> --Sean
>>
>> On 10/2/17 1:24 PM, Philipp Kunz wrote:
>>> Hi,
>>>
>>> While fixing JDK-6695402 I came across other related bugs to 
>>> manifests such as JDK-6372077, JDK-6202130, JDK-8176843, 
>>> JDK-4842483, and JDK-6443578 which all relate to manifest reading 
>>> and writing. Somewhere bug 7071055 is mentioned but I cannot find 
>>> anywhere. Another group of bugs, JDK-6910466, JDK-4935610, and 
>>> JDK-4271239 concern the mandatory manifest main attributes 
>>> Manifest-Version or Signature-Version and at first glance are 
>>> duplicates. If you know of more known bugs, not necessarily present 
>>> in jira, I'd be glad to get notified.
>>>
>>> There are also some comments about utf handling and line breaking in 
>>> the code of Manifest:
>>> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l299 
>>>
>>> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l327 
>>>
>>> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l370 
>>>
>>>
>>> Furthermore, Attributes.map should declare appropriate type parameters:
>>> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l61 
>>>
>>> The specification would also require that `header names must not 
>>> start with _, - or "From"` 
>>> (http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Section-Specification) 
>>> but I would opt not to add this as a hard restriction because I 
>>> guess it can be assumed that such names are in use now after having 
>>> been working for years. A warning to a logger might be conceivable 
>>> such as in
>>> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l424 
>>>
>>> Attribute values are never checked at all and invalid characters 
>>> such as line breaks are never detected except that when reading the 
>>> manifest again the values are cut off.
>>> The tab character (U+0008) does not work in manifest values.
>>> I suspect that there are also issues regarding the iteration order 
>>> but I haven't got a prove yet unlike for the other points above:
>>> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Manifest.java#l54 
>>>
>>> There is duplicated or very similar code in Attributes and Manifest: 
>>> Attributes.write-Manifest.write-Attributes.writeMain and 
>>> Attributes.read-Manifest.read.
>>> Resolving JDK-6202130 would have the additional benefit to be able 
>>> to view manifests with any utf-8 capable editor even if multi-byte 
>>> characters break across lines.
>>>
>>> Fixing these issues individually looks like more complicated work 
>>> than fixing them all at once, I guess, also because of a very low 
>>> current test coverage. So I'd suggest to add some thorough tests 
>>> along with fixing these issues. But before I start I would like to 
>>> get some guidance, assistance or at least confirmation on how to 
>>> proceed. I'm new to open jdk and have submitted only one patch so far.
>>>
>>> Is it ok to add tests for things that have worked before?
>>> Is it ok to refactor duplicated code just for the added value to 
>>> reduce effort for testing?
>>> I assume compatibility to and from existing manifests is the highest 
>>> priority, correct? This would also be the hard part in adding as 
>>> complete test coverage as possible. What would be acceptable 
>>> criteria to meet?
>>> Why does Attributes not extend LinkedHashMap and why does Manifest 
>>> not extend HashMap? Any objection?
>>> While I would not want to write code that looks slow or change more 
>>> than necessary one can never know before having performance actually 
>>> measured. Is there some way this is dealt with or should I wait for 
>>> such feedback until after patch submission?
>>>
>>> Would someone sponsor?
>>>
>>> Regards,
>>> Philipp
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>>
>>>
>>> Paratix GmbH
>>> St Peterhofstatt 11
>>> 8001 Z?rich
>>>
>>> +41 (0)76 397 79 35
>>> philipp.kunz at paratix.ch <mailto:philipp.kunz at paratix.ch>
>
> -- 
>
>
> Gruss Philipp
>
>
>
> ------------------------------------------------------------------------
>
>
>
> Paratix GmbH
> St Peterhofstatt 11
> 8001 Z?rich
>
> +41 (0)76 397 79 35
> philipp.kunz at paratix.ch <mailto:philipp.kunz at paratix.ch>

-- 


Gruss Philipp



------------------------------------------------------------------------



Paratix GmbH
St Peterhofstatt 11
8001 Z?rich

+41 (0)76 397 79 35
philipp.kunz at paratix.ch <mailto:philipp.kunz at paratix.ch>

From venkatec at linux.vnet.ibm.com  Tue Nov 21 09:14:33 2017
From: venkatec at linux.vnet.ibm.com (Venkateswara R Chintala)
Date: Tue, 21 Nov 2017 14:44:33 +0530
Subject: Incorrect validation of DST in java.util.SimpleTimeZone
In-Reply-To: <bef944fa-2a15-6c83-6730-ff7e32aa063f@gmail.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>
 <84ca56e0-67c8-3fbb-d558-4ebe797d513c@oracle.com>
 <8894f619-3510-acfa-3987-f013ca3638f3@gmail.com>
 <b68da9c6-1ad4-6926-7c27-21680e3b73b0@gmail.com>
 <d74ffdce-793a-bfe9-7e5f-4964897c3553@linux.vnet.ibm.com>
 <bef944fa-2a15-6c83-6730-ff7e32aa063f@gmail.com>
Message-ID: <72a7efe3-ac34-1534-3a9b-146c647e1292@linux.vnet.ibm.com>

Thanks Peter for sponsoring this patch. Is there anything else that 
needs to be done from my end for this patch to be integrated? Please let 
me know.

-Venkat


On 14/11/17 8:46 PM, Peter Levart wrote:
> Hi Venkat,
>
> I created the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8191216
>
> I can also sponsor this patch and push it for JDK 10.
>
> The patch that you are proposing looks good to me. Does anybody have 
> anything else to say?
>
> Regards, Peter
>
>
> On 11/13/2017 11:28 AM, Venkateswara R Chintala wrote:
>> Thanks David, Peter for your review and comments. As I am new to the 
>> community, can you please help me to open a bug and integrate the 
>> changes into code base?
>>
>> -Venkat
>>
>> On 12/11/17 2:19 AM, Peter Levart wrote:
>>> Hi David, Venkat,
>>>
>>> On 11/11/17 21:15, Peter Levart wrote:
>>>> For example, take the following method:
>>>>
>>>> String defaultTZID() {
>>>> ??? return TimeZone.getDefault().getID();
>>>> }
>>>>
>>>> When JIT compiles it and inlines invocations to other methods 
>>>> within it, it can prove that cloned TimeZone instance never escapes 
>>>> the call to defaultTZID() and can therefore skip allocating the 
>>>> instance on heap.
>>>>
>>>> But this is fragile. If code in invoked methods changes, they may 
>>>> not get inlined or EA may not be able to prove that the cloned 
>>>> instance can't escape and allocation may be introduced. 
>>>> ZoneId.systemDefault() is a hot method and it would be nice if we 
>>>> manage to keep it allocation free.
>>>
>>> Well, I tried the following variant of SimpleTimeZone.clone() patch:
>>>
>>> ??? public Object clone()
>>> ??? {
>>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>> ??????? // like tz.invalidateCache() but without holding a lock on 
>>> clone
>>> ??????? tz.cacheYear = tz.startYear - 1;
>>> ??????? tz.cacheStart = tz.cacheEnd = 0;
>>> ??????? return tz;
>>> ??? }
>>>
>>>
>>> ...and the JMH benchmark with gc profiling shows that 
>>> ZoneId.systemDefault() still manages to get JIT-compiled without 
>>> introducing allocation.
>>>
>>> Even the following (original Venkat's) patch:
>>>
>>> ??? public Object clone()
>>> ??? {
>>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>> ??????? tz.invalidateCache();
>>> ??????? return tz;
>>> ??? }
>>>
>>> ...does the same and the locking in invalidateCache() is elided too. 
>>> Allocation and lock-elision go hand-in-hand. When object doesn't 
>>> escape, allocation on heap may be eliminated and locks on that 
>>> instance elided.
>>>
>>> So this is better than synchronizing on the original instance during 
>>> .clone() execution as it has potential to avoid locking overhead.
>>>
>>> So Venkat, go ahead. My fear was unjustified.
>>>
>>> Regards, Peter
>>>
>>
>
>

-- 
Regards
-Venkat


From scolebourne at joda.org  Tue Nov 21 09:35:41 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 21 Nov 2017 09:35:41 +0000
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <c6d595c3-15df-9b12-567a-4ae1a1e4bfdd@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <CACzrW9C+GekWNRdWVi1AhVs_CiPgWksde-6iRT1Z68-RhkziZw@mail.gmail.com>
 <098fb447-9d89-2d2d-20a8-06b85d128020@oracle.com>
 <CACzrW9CbB9TOto1UgNmiFfN7pB8D7gKVQBb89t1x_J20NoGpMg@mail.gmail.com>
 <1a518134-57a5-6ac9-40eb-c948b15b88b9@oracle.com>
 <3c3c8b89-9a47-9df4-61b8-cdb59850d88e@oracle.com>
 <34441778-1df2-259f-2d7a-8143f37650d8@Oracle.com>
 <15a5bd09-a811-0ee2-9ef5-e48672a70c02@oracle.com>
 <9ECB04EF-B9ED-4913-AF69-EB383783F6B7@oracle.com>
 <7b90a838-b5bd-5483-8ec8-a183c44b2c82@oracle.com>
 <CACzrW9DbkT+adq-HCgZP119XQxwgf5OuQOgSmiBtXb+ysD1_uA@mail.gmail.com>
 <c6d595c3-15df-9b12-567a-4ae1a1e4bfdd@oracle.com>
Message-ID: <CACzrW9AP6_G3bs0m9axu-ai0oK6ERS0R5YM2HXLVLmwGB5UmkA@mail.gmail.com>

On 21 November 2017 at 01:45, Naoto Sato <naoto.sato at oracle.com> wrote:
>> 2) `DecimalStyle.ofLocale(Locale)` should use "nu" but does not.
>
> Document it in the javadoc.

Javadoc looks good, but the webrev didn't contain matching code last
time I looked.

>> 3) `DateTimeFormatter.localizedBy(Locale)` should use "ca" to call
>> `withChronology`, `tz` to call `withZoneId` and `nu` to call
>> `withDecimalStyle`. This is a change to the CSR.
>
> Besides that "nu" needs to be spec'ed out, isn't calling withXXXX() an
> implementation note?

The revised text ends with "Same is true for the "nu" extension.", but
doesn't mention the case where both "tz" and "rg" are present.

>> 7) WeekBasedFieldPrinterParser should use "fw"/"rg", which it already
>> does via WeekFields.of(Locale)
>
> Not sure what this means. Where is the file located?

WeekBasedFieldPrinterParser is an inner class of DateTimeFormatterBuilder

>> 10) Consider how localizedBy(Locale) operates.
>
> IIRC, the localizedBy() is added so that withLocale() would behave as it is
> now. I think localizedBy() should also have the same effect as withLocale if
> the specified locale do not contain any calendar/timezone/numberingSystem
> extensions. Otherwise, say localizedBy(Locale.JAPAN) would be no-operation.

OK, I agree. localizedBy(locale) is the same as withLocale(locale)
unless there are "ca", "tz" or "nu", in which case the matching
element is updated.

thanks
Stephen

From Alan.Bateman at oracle.com  Tue Nov 21 11:25:06 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Nov 2017 11:25:06 +0000
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
In-Reply-To: <5A139662.2030105@oracle.com>
References: <5A0E4703.3040409@oracle.com>
 <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>
 <5A0F13FF.8090406@oracle.com>
 <1c71e540-88a2-4f6f-5f2b-06b62b955df7@oracle.com>
 <5A131E90.6090509@oracle.com>
 <BE9EE092-1BDD-4A34-A8CF-C9F93094D3DE@oracle.com>
 <5A139662.2030105@oracle.com>
Message-ID: <dc1aba6d-5461-2887-8f2f-671164a24f76@oracle.com>

On 21/11/2017 02:58, Xueming Shen wrote:
> :
>
> http://cr.openjdk.java.net/~sherman/8189611/webrev
>
> jdeps' VersionHelper.java still accesses the "getRealName()" via the 
> SharedSecrets.
> Since jdeps is being compiled/built with the bootjdk, I'm leaving it 
> untouched for
> now.
>
I think we need to create an issue in JIRA to get jdeps updated. It 
actually has two issues, the other is the usage of 
jdk.internal.util.jar.VersionedStream. I'm surprised that there are 
issues with the boot JDK because it uses both in JDK 9 when the boot JDK 
is JDK 8. No issue with keeping this separate to the current effort.

I've skimmed through the latest webrev and it looks good good. The 
JarEntry::getRealName and JarFile::versionedStream APIs look good.

The update to jlink to use the standard API should mean that java.base 
no longer needs to export jdk.internal.util.jar to jdk.jlink.

JarFile is updated to import LinkedHashMap, I don't think that is needed 
in this version.

I think that is all I have for now.

-Alan

From brian.burkhalter at oracle.com  Tue Nov 21 16:47:07 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 21 Nov 2017 08:47:07 -0800
Subject: RFR 8191516: OutputStream.write(byte[], int,
 int) could have fewer parameter bounds checks
In-Reply-To: <A4D0138F-9D6B-47A2-AB05-C762A4DCAE7B@oracle.com>
References: <2177CFA1-A5B3-4F5B-9A57-25E5AF7D06DE@oracle.com>
 <A4D0138F-9D6B-47A2-AB05-C762A4DCAE7B@oracle.com>
Message-ID: <E7A67EAA-1386-43A2-99DD-DEEF4BC0184E@oracle.com>


On Nov 20, 2017, at 6:32 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> See also Objects.checkFromIndexSize if you wanna use that instead.
> 
> Also the if len == 0 check is probably redundant, i doubt it makes any difference given the condition needs to be checked before entering the loop.

Both good points. Updated accordingly: http://cr.openjdk.java.net/~bpb/8191516/webrev.01/.

Thanks,

Brian

From naoto.sato at oracle.com  Tue Nov 21 16:51:28 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 21 Nov 2017 08:51:28 -0800
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <CACzrW9AP6_G3bs0m9axu-ai0oK6ERS0R5YM2HXLVLmwGB5UmkA@mail.gmail.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <CACzrW9C+GekWNRdWVi1AhVs_CiPgWksde-6iRT1Z68-RhkziZw@mail.gmail.com>
 <098fb447-9d89-2d2d-20a8-06b85d128020@oracle.com>
 <CACzrW9CbB9TOto1UgNmiFfN7pB8D7gKVQBb89t1x_J20NoGpMg@mail.gmail.com>
 <1a518134-57a5-6ac9-40eb-c948b15b88b9@oracle.com>
 <3c3c8b89-9a47-9df4-61b8-cdb59850d88e@oracle.com>
 <34441778-1df2-259f-2d7a-8143f37650d8@Oracle.com>
 <15a5bd09-a811-0ee2-9ef5-e48672a70c02@oracle.com>
 <9ECB04EF-B9ED-4913-AF69-EB383783F6B7@oracle.com>
 <7b90a838-b5bd-5483-8ec8-a183c44b2c82@oracle.com>
 <CACzrW9DbkT+adq-HCgZP119XQxwgf5OuQOgSmiBtXb+ysD1_uA@mail.gmail.com>
 <c6d595c3-15df-9b12-567a-4ae1a1e4bfdd@oracle.com>
 <CACzrW9AP6_G3bs0m9axu-ai0oK6ERS0R5YM2HXLVLmwGB5UmkA@mail.gmail.com>
Message-ID: <f648653d-ec23-f125-2bab-bcbf9a804180@oracle.com>

Thanks, Stephen.

On 11/21/17 1:35 AM, Stephen Colebourne wrote:
> On 21 November 2017 at 01:45, Naoto Sato <naoto.sato at oracle.com> wrote:
>>> 2) `DecimalStyle.ofLocale(Locale)` should use "nu" but does not.
>>
>> Document it in the javadoc.
> 
> Javadoc looks good, but the webrev didn't contain matching code last
> time I looked.

I haven't updated the webrev yet, since it will involve new test cases. 
I wanted to make sure the direction of the change was correct. Will 
update the webrev soon.

> 
>>> 3) `DateTimeFormatter.localizedBy(Locale)` should use "ca" to call
>>> `withChronology`, `tz` to call `withZoneId` and `nu` to call
>>> `withDecimalStyle`. This is a change to the CSR.
>>
>> Besides that "nu" needs to be spec'ed out, isn't calling withXXXX() an
>> implementation note?
> 
> The revised text ends with "Same is true for the "nu" extension.", but
> doesn't mention the case where both "tz" and "rg" are present.

Since there is no ZoneId.ofLocale(rg), a region does not designate a 
time zone (yet). So there would be no conflict between "tz" and "rg" 
extensions.

> 
>>> 7) WeekBasedFieldPrinterParser should use "fw"/"rg", which it already
>>> does via WeekFields.of(Locale)
>>
>> Not sure what this means. Where is the file located?
> 
> WeekBasedFieldPrinterParser is an inner class of DateTimeFormatterBuilder

OK, thanks.

> 
>>> 10) Consider how localizedBy(Locale) operates.
>>
>> IIRC, the localizedBy() is added so that withLocale() would behave as it is
>> now. I think localizedBy() should also have the same effect as withLocale if
>> the specified locale do not contain any calendar/timezone/numberingSystem
>> extensions. Otherwise, say localizedBy(Locale.JAPAN) would be no-operation.
> 
> OK, I agree. localizedBy(locale) is the same as withLocale(locale)
> unless there are "ca", "tz" or "nu", in which case the matching
> element is updated.

Good.

Naoto

From paul.sandoz at oracle.com  Tue Nov 21 17:16:59 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 21 Nov 2017 09:16:59 -0800
Subject: RFR 8191516: OutputStream.write(byte[], int, int) could have
 fewer parameter bounds checks
In-Reply-To: <E7A67EAA-1386-43A2-99DD-DEEF4BC0184E@oracle.com>
References: <2177CFA1-A5B3-4F5B-9A57-25E5AF7D06DE@oracle.com>
 <A4D0138F-9D6B-47A2-AB05-C762A4DCAE7B@oracle.com>
 <E7A67EAA-1386-43A2-99DD-DEEF4BC0184E@oracle.com>
Message-ID: <00A5D5EF-FA0E-4154-A240-6322FA4A3AFB@oracle.com>



> On 21 Nov 2017, at 08:47, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> 
> On Nov 20, 2017, at 6:32 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
> 
>> See also Objects.checkFromIndexSize if you wanna use that instead.
>> 
>> Also the if len == 0 check is probably redundant, i doubt it makes any difference given the condition needs to be checked before entering the loop.
> 
> Both good points. Updated accordingly: http://cr.openjdk.java.net/~bpb/8191516/webrev.01/ <http://cr.openjdk.java.net/~bpb/8191516/webrev.01/>.
> 

Looks good. How about updating the read method as well to use the bounds check method? (the len == 0 check makes sense there)?

Paul.


From brian.burkhalter at oracle.com  Tue Nov 21 17:21:01 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 21 Nov 2017 09:21:01 -0800
Subject: RFR 8191516: OutputStream.write(byte[], int,
 int) could have fewer parameter bounds checks
In-Reply-To: <00A5D5EF-FA0E-4154-A240-6322FA4A3AFB@oracle.com>
References: <2177CFA1-A5B3-4F5B-9A57-25E5AF7D06DE@oracle.com>
 <A4D0138F-9D6B-47A2-AB05-C762A4DCAE7B@oracle.com>
 <E7A67EAA-1386-43A2-99DD-DEEF4BC0184E@oracle.com>
 <00A5D5EF-FA0E-4154-A240-6322FA4A3AFB@oracle.com>
Message-ID: <F70DE91C-6296-46EC-B776-720243E6A68D@oracle.com>

On Nov 21, 2017, at 9:16 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>> Both good points. Updated accordingly: http://cr.openjdk.java.net/~bpb/8191516/webrev.01/.
>> 
> 
> Looks good. How about updating the read method as well to use the bounds check method? (the len == 0 check makes sense there)?

Probably might as well expand it a little to see where else similar changes might be made.

Thanks,

Brian

From paul.sandoz at oracle.com  Tue Nov 21 17:27:09 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 21 Nov 2017 09:27:09 -0800
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
In-Reply-To: <5A139662.2030105@oracle.com>
References: <5A0E4703.3040409@oracle.com>
 <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>
 <5A0F13FF.8090406@oracle.com>
 <1c71e540-88a2-4f6f-5f2b-06b62b955df7@oracle.com>
 <5A131E90.6090509@oracle.com>
 <BE9EE092-1BDD-4A34-A8CF-C9F93094D3DE@oracle.com>
 <5A139662.2030105@oracle.com>
Message-ID: <1E6B6A53-A4FC-479D-AF55-CE84FE23CBE4@oracle.com>



> On 20 Nov 2017, at 18:58, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Thanks Paul!
> 
> Webrev has been updated as suggested.
> 
> http://cr.openjdk.java.net/~sherman/8189611/webrev
> 
> jdeps' VersionHelper.java still accesses the "getRealName()" via the SharedSecrets.
> Since jdeps is being compiled/built with the bootjdk, I'm leaving it untouched for
> now.
> 
> ----------------------
> 610 // placeholder for now
> 611 String getRealName(JarEntry entry) {
> 612 return entry.getRealName();
> 613 } No longer required?
> 
> I dunno what calls it...
> ?????????????
> 

Ok, I suggest adding a comment as to why it is still needed. No need for another review round.

Thanks,
Paul.

From patrick at reini.net  Tue Nov 21 19:56:01 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 21 Nov 2017 20:56:01 +0100
Subject: JDK-8191706: Proposal to add Reader::transferTo(Writer)
Message-ID: <0d53fe18-9443-201d-c4bd-7f9c973b0602@reini.net>

Hi there out a the review [1] for? JDK-8066870, that will need some more
working on, I created this specific issue to add an transferTo method to
the java.io.Reader as it seems more clear as of the similarity to
java.io.InputStream.transferTo(java.io.OutputStream) in terms of the API.

To start the discussion I got the proposed API:

/**
?* Reads all characters from this reader and writes the characters to the
?* given writer in the order that they are read. On return, this reader
?* will be at end of the data. This method does not close either reader
?* or writer.
?* <p>
?* This method may block indefinitely reading from the reader, or
?* writing to the writer. The behavior for the case where the reader
?* and/or writer is <i>asynchronously closed</i>, or the thread
?* interrupted during the transfer, is highly reader and writer
?* specific, and therefore not specified.
?* <p>
?* If an I/O error occurs reading from the reader or writing to the
?* writer, then it may do so after some characters have been read or
?* written. Consequently the reader may not be at end of the data and
?* one, or both, streams may be in an inconsistent state. It is strongly
?* recommended that both streams be promptly closed if an I/O error occurs.
?*
?* @param? out the writer, non-null
?* @return the number of characters transferred
?* @throws IOException if an I/O error occurs when reading or writing
?* @throws NullPointerException if {@code out} is {@code null}
?*
?* @since 10
?*/
public long transferTo(Writer out) throws IOException {
....
}


-Patrick


[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050064.html





From brian.burkhalter at oracle.com  Tue Nov 21 20:30:30 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 21 Nov 2017 12:30:30 -0800
Subject: RFR 8191516: OutputStream.write(byte[], int,
 int) could have fewer parameter bounds checks
In-Reply-To: <F70DE91C-6296-46EC-B776-720243E6A68D@oracle.com>
References: <2177CFA1-A5B3-4F5B-9A57-25E5AF7D06DE@oracle.com>
 <A4D0138F-9D6B-47A2-AB05-C762A4DCAE7B@oracle.com>
 <E7A67EAA-1386-43A2-99DD-DEEF4BC0184E@oracle.com>
 <00A5D5EF-FA0E-4154-A240-6322FA4A3AFB@oracle.com>
 <F70DE91C-6296-46EC-B776-720243E6A68D@oracle.com>
Message-ID: <D0217A99-62B9-4A35-89BB-024D0EBEB0F6@oracle.com>

On Nov 21, 2017, at 9:21 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

>> Looks good. How about updating the read method as well to use the bounds check method? (the len == 0 check makes sense there)?
> 
> Probably might as well expand it a little to see where else similar changes might be made.

Expanded to InputStream: http://cr.openjdk.java.net/~bpb/8191516/webrev.02/. The test java/io/InputStream/ReadParams verifies the changes to IS.

Thanks,

Brian

From brent.christian at oracle.com  Tue Nov 21 20:41:44 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 21 Nov 2017 12:41:44 -0800
Subject: RFR 8191173 : (cl) Clarify or remove "for delegation" in ClassLoader
 spec
Message-ID: <04a91618-7dba-17dd-8360-7f81369c3be1@oracle.com>

Hi,

Please review my change to this small bit of ClassLoader spec that can 
be tidied up, as noticed by Martin.

Issue:
https://bugs.openjdk.java.net/browse/JDK-8191173
Webrev:
http://cr.openjdk.java.net/~bchristi/8191173/webrev.00/

In java.lang.ClassLoader these methods:
   getParent()
   getPlatformClassLoader()
   getSystemClassLoader()
all state that the returned classloader is, "for delegation."

For getParent() this makes sense to mention.  But it seems unnecessary 
for the other two methods, which are static, and designed to always 
return the indicated classloader.  The getSystemClassLoader() docs go on 
to immediately mention that the system classloader is the default 
delegation parent.

Omitting the phrase makes the spec more concise.

Thanks,
-Brent

From brian.burkhalter at oracle.com  Tue Nov 21 20:50:57 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 21 Nov 2017 12:50:57 -0800
Subject: JDK-8191706: Proposal to add Reader::transferTo(Writer)
In-Reply-To: <0d53fe18-9443-201d-c4bd-7f9c973b0602@reini.net>
References: <0d53fe18-9443-201d-c4bd-7f9c973b0602@reini.net>
Message-ID: <F18A089C-B6B1-41C6-A4D2-2912E0F2AF19@oracle.com>

Hi Patrick,

This looks fine from my point of view. It exactly mirrors InputStream.transferTo(OutputStream) with which I expect everyone will concur.

Thanks,

Brian

On Nov 21, 2017, at 11:56 AM, Patrick Reinhart <patrick at reini.net> wrote:

> Hi there out a the review [1] for  JDK-8066870, that will need some more
> working on, I created this specific issue to add an transferTo method to
> the java.io.Reader as it seems more clear as of the similarity to
> java.io.InputStream.transferTo(java.io.OutputStream) in terms of the API.
> 
> To start the discussion I got the proposed API:
> 
> /**
>  * Reads all characters from this reader and writes the characters to the
>  * given writer in the order that they are read. On return, this reader
>  * will be at end of the data. This method does not close either reader
>  * or writer.
>  * <p>
>  * This method may block indefinitely reading from the reader, or
>  * writing to the writer. The behavior for the case where the reader
>  * and/or writer is <i>asynchronously closed</i>, or the thread
>  * interrupted during the transfer, is highly reader and writer
>  * specific, and therefore not specified.
>  * <p>
>  * If an I/O error occurs reading from the reader or writing to the
>  * writer, then it may do so after some characters have been read or
>  * written. Consequently the reader may not be at end of the data and
>  * one, or both, streams may be in an inconsistent state. It is strongly
>  * recommended that both streams be promptly closed if an I/O error occurs.
>  *
>  * @param  out the writer, non-null
>  * @return the number of characters transferred
>  * @throws IOException if an I/O error occurs when reading or writing
>  * @throws NullPointerException if {@code out} is {@code null}
>  *
>  * @since 10
>  */
> public long transferTo(Writer out) throws IOException {
> ....
> }
> 
> 
> -Patrick
> 
> 
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050064.html
> 
> 
> 
> 


From paul.sandoz at oracle.com  Tue Nov 21 21:01:09 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 21 Nov 2017 13:01:09 -0800
Subject: RFR 8191516: OutputStream.write(byte[], int, int) could have
 fewer parameter bounds checks
In-Reply-To: <D0217A99-62B9-4A35-89BB-024D0EBEB0F6@oracle.com>
References: <2177CFA1-A5B3-4F5B-9A57-25E5AF7D06DE@oracle.com>
 <A4D0138F-9D6B-47A2-AB05-C762A4DCAE7B@oracle.com>
 <E7A67EAA-1386-43A2-99DD-DEEF4BC0184E@oracle.com>
 <00A5D5EF-FA0E-4154-A240-6322FA4A3AFB@oracle.com>
 <F70DE91C-6296-46EC-B776-720243E6A68D@oracle.com>
 <D0217A99-62B9-4A35-89BB-024D0EBEB0F6@oracle.com>
Message-ID: <D4533923-9111-4CDF-AB71-F123F7B78B89@oracle.com>



> On 21 Nov 2017, at 12:30, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> On Nov 21, 2017, at 9:21 AM, Brian Burkhalter <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
> 
>>> Looks good. How about updating the read method as well to use the bounds check method? (the len == 0 check makes sense there)?
>> 
>> Probably might as well expand it a little to see where else similar changes might be made.
> 
> Expanded to InputStream: http://cr.openjdk.java.net/~bpb/8191516/webrev.02/ <http://cr.openjdk.java.net/~bpb/8191516/webrev.02/>. The test java/io/InputStream/ReadParams verifies the changes to IS.
> 

+1

Paul.

From martinrb at google.com  Tue Nov 21 21:03:57 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 21 Nov 2017 13:03:57 -0800
Subject: RFR 8191173 : (cl) Clarify or remove "for delegation" in
 ClassLoader spec
In-Reply-To: <04a91618-7dba-17dd-8360-7f81369c3be1@oracle.com>
References: <04a91618-7dba-17dd-8360-7f81369c3be1@oracle.com>
Message-ID: <CA+kOe0_bXHXzTO8ed1zBMun1C4WtdxLccNzuSjo6U0-JY03+tQ@mail.gmail.com>

Looks good!

On Tue, Nov 21, 2017 at 12:41 PM, Brent Christian <
brent.christian at oracle.com> wrote:

> Hi,
>
> Please review my change to this small bit of ClassLoader spec that can be
> tidied up, as noticed by Martin.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8191173
> Webrev:
> http://cr.openjdk.java.net/~bchristi/8191173/webrev.00/
>
> In java.lang.ClassLoader these methods:
>   getParent()
>   getPlatformClassLoader()
>   getSystemClassLoader()
> all state that the returned classloader is, "for delegation."
>
> For getParent() this makes sense to mention.  But it seems unnecessary for
> the other two methods, which are static, and designed to always return the
> indicated classloader.  The getSystemClassLoader() docs go on to
> immediately mention that the system classloader is the default delegation
> parent.
>
> Omitting the phrase makes the spec more concise.
>
> Thanks,
> -Brent
>

From david.holmes at oracle.com  Tue Nov 21 21:48:21 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 22 Nov 2017 07:48:21 +1000
Subject: RFR 8191173 : (cl) Clarify or remove "for delegation" in
 ClassLoader spec
In-Reply-To: <04a91618-7dba-17dd-8360-7f81369c3be1@oracle.com>
References: <04a91618-7dba-17dd-8360-7f81369c3be1@oracle.com>
Message-ID: <9fcf8e67-a2e2-c1c9-9878-435ed63d5646@oracle.com>

Seems fine.

Thanks,
David

On 22/11/2017 6:41 AM, Brent Christian wrote:
> Hi,
> 
> Please review my change to this small bit of ClassLoader spec that can 
> be tidied up, as noticed by Martin.
> 
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8191173
> Webrev:
> http://cr.openjdk.java.net/~bchristi/8191173/webrev.00/
> 
> In java.lang.ClassLoader these methods:
>  ? getParent()
>  ? getPlatformClassLoader()
>  ? getSystemClassLoader()
> all state that the returned classloader is, "for delegation."
> 
> For getParent() this makes sense to mention.? But it seems unnecessary 
> for the other two methods, which are static, and designed to always 
> return the indicated classloader.? The getSystemClassLoader() docs go on 
> to immediately mention that the system classloader is the default 
> delegation parent.
> 
> Omitting the phrase makes the spec more concise.
> 
> Thanks,
> -Brent

From brian.goetz at oracle.com  Tue Nov 21 22:07:23 2017
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 21 Nov 2017 17:07:23 -0500
Subject: JDK-8191706: Proposal to add Reader::transferTo(Writer)
In-Reply-To: <0d53fe18-9443-201d-c4bd-7f9c973b0602@reini.net>
References: <0d53fe18-9443-201d-c4bd-7f9c973b0602@reini.net>
Message-ID: <552dddd0-f911-60d7-128c-80701be41575@oracle.com>

Looks good.

On 11/21/2017 2:56 PM, Patrick Reinhart wrote:
> Hi there out a the review [1] for? JDK-8066870, that will need some more
> working on, I created this specific issue to add an transferTo method to
> the java.io.Reader as it seems more clear as of the similarity to
> java.io.InputStream.transferTo(java.io.OutputStream) in terms of the API.
>
> To start the discussion I got the proposed API:
>
> /**
>  ?* Reads all characters from this reader and writes the characters to the
>  ?* given writer in the order that they are read. On return, this reader
>  ?* will be at end of the data. This method does not close either reader
>  ?* or writer.
>  ?* <p>
>  ?* This method may block indefinitely reading from the reader, or
>  ?* writing to the writer. The behavior for the case where the reader
>  ?* and/or writer is <i>asynchronously closed</i>, or the thread
>  ?* interrupted during the transfer, is highly reader and writer
>  ?* specific, and therefore not specified.
>  ?* <p>
>  ?* If an I/O error occurs reading from the reader or writing to the
>  ?* writer, then it may do so after some characters have been read or
>  ?* written. Consequently the reader may not be at end of the data and
>  ?* one, or both, streams may be in an inconsistent state. It is strongly
>  ?* recommended that both streams be promptly closed if an I/O error occurs.
>  ?*
>  ?* @param? out the writer, non-null
>  ?* @return the number of characters transferred
>  ?* @throws IOException if an I/O error occurs when reading or writing
>  ?* @throws NullPointerException if {@code out} is {@code null}
>  ?*
>  ?* @since 10
>  ?*/
> public long transferTo(Writer out) throws IOException {
> ....
> }
>
>
> -Patrick
>
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050064.html
>
>
>
>


From patrick at reini.net  Tue Nov 21 22:33:49 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 21 Nov 2017 23:33:49 +0100
Subject: RFR: JDK-8191706: Add Reader::transferTo(Writer)
In-Reply-To: <552dddd0-f911-60d7-128c-80701be41575@oracle.com>
References: <0d53fe18-9443-201d-c4bd-7f9c973b0602@reini.net>
 <552dddd0-f911-60d7-128c-80701be41575@oracle.com>
Message-ID: <c0849cea-0c97-ed23-3705-50ee5acd8916@reini.net>

Here's the implementation and test..

http://cr.openjdk.java.net/~reinhapa/reviews/8191706/webrev.00

-Patrick

Am 21.11.2017 um 23:07 schrieb Brian Goetz:
> Looks good.
>
> On 11/21/2017 2:56 PM, Patrick Reinhart wrote:
>> Hi there out a the review [1] for? JDK-8066870, that will need some more
>> working on, I created this specific issue to add an transferTo method to
>> the java.io.Reader as it seems more clear as of the similarity to
>> java.io.InputStream.transferTo(java.io.OutputStream) in terms of the
>> API.
>>
>> To start the discussion I got the proposed API:
>>
>> /**
>> ??* Reads all characters from this reader and writes the characters
>> to the
>> ??* given writer in the order that they are read. On return, this reader
>> ??* will be at end of the data. This method does not close either reader
>> ??* or writer.
>> ??* <p>
>> ??* This method may block indefinitely reading from the reader, or
>> ??* writing to the writer. The behavior for the case where the reader
>> ??* and/or writer is <i>asynchronously closed</i>, or the thread
>> ??* interrupted during the transfer, is highly reader and writer
>> ??* specific, and therefore not specified.
>> ??* <p>
>> ??* If an I/O error occurs reading from the reader or writing to the
>> ??* writer, then it may do so after some characters have been read or
>> ??* written. Consequently the reader may not be at end of the data and
>> ??* one, or both, streams may be in an inconsistent state. It is
>> strongly
>> ??* recommended that both streams be promptly closed if an I/O error
>> occurs.
>> ??*
>> ??* @param? out the writer, non-null
>> ??* @return the number of characters transferred
>> ??* @throws IOException if an I/O error occurs when reading or writing
>> ??* @throws NullPointerException if {@code out} is {@code null}
>> ??*
>> ??* @since 10
>> ??*/
>> public long transferTo(Writer out) throws IOException {
>> ....
>> }
>>
>>
>> -Patrick
>>
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050064.html
>>
>>
>>
>>
>>
>



From brian.burkhalter at oracle.com  Tue Nov 21 22:41:06 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 21 Nov 2017 14:41:06 -0800
Subject: RFR: JDK-8191706: Add Reader::transferTo(Writer)
In-Reply-To: <c0849cea-0c97-ed23-3705-50ee5acd8916@reini.net>
References: <0d53fe18-9443-201d-c4bd-7f9c973b0602@reini.net>
 <552dddd0-f911-60d7-128c-80701be41575@oracle.com>
 <c0849cea-0c97-ed23-3705-50ee5acd8916@reini.net>
Message-ID: <C598A367-778D-4DFB-8547-E8D113D4FDD5@oracle.com>

Looks good.

Of course a corresponding CSR will need to be filed and eventually approved.

Thanks,

Brian

On Nov 21, 2017, at 2:33 PM, Patrick Reinhart <patrick at reini.net> wrote:

> Here's the implementation and test..
> 
> http://cr.openjdk.java.net/~reinhapa/reviews/8191706/webrev.00
> 
> -Patrick
> 
> Am 21.11.2017 um 23:07 schrieb Brian Goetz:
>> Looks good.


From patrick at reini.net  Tue Nov 21 22:57:58 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 21 Nov 2017 23:57:58 +0100
Subject: RFR: JDK-8191706: Add Reader::transferTo(Writer)
In-Reply-To: <C598A367-778D-4DFB-8547-E8D113D4FDD5@oracle.com>
References: <0d53fe18-9443-201d-c4bd-7f9c973b0602@reini.net>
 <552dddd0-f911-60d7-128c-80701be41575@oracle.com>
 <c0849cea-0c97-ed23-3705-50ee5acd8916@reini.net>
 <C598A367-778D-4DFB-8547-E8D113D4FDD5@oracle.com>
Message-ID: <40f21612-cdfd-4224-1479-5a4e07365f34@reini.net>

Created

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

Any additions welcome

-Patrick


Am 21.11.2017 um 23:41 schrieb Brian Burkhalter:
> Looks good.
>
> Of course a corresponding CSR will need to be filed and eventually
> approved.
>
> Thanks,
>
> Brian
>
> On Nov 21, 2017, at 2:33 PM, Patrick Reinhart <patrick at reini.net
> <mailto:patrick at reini.net>> wrote:
>
>> Here's the implementation and test..
>>
>> http://cr.openjdk.java.net/~reinhapa/reviews/8191706/webrev.00
>> <http://cr.openjdk.java.net/%7Ereinhapa/reviews/8191706/webrev.00>
>>
>> -Patrick
>>
>> Am 21.11.2017 um 23:07 schrieb Brian Goetz:
>>> Looks good.
>



From naoto.sato at oracle.com  Tue Nov 21 23:17:42 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 21 Nov 2017 15:17:42 -0800
Subject: <i18n dev> [10] RFR 8191404: Upgrading JDK with latest available
 LSR data from IANA.
In-Reply-To: <38d7fa00-252f-cd42-500a-deda1fef843f@oracle.com>
References: <38d7fa00-252f-cd42-500a-deda1fef843f@oracle.com>
Message-ID: <a528efb8-12d2-8a3c-e802-64e3d7355042@oracle.com>

Hi Nishit,

One nit in the test. At line 71, probably the original intention of 
"str" is to list the accept languages in alphabetic order. Would you 
change it?

I have not looked into actual tags in the test. Did  you modify them 
manually? If so, it would be desirable to make it automated.

Naoto

On 11/16/17 3:47 AM, Nishit Jain wrote:
> Hi,
> 
> Please review the fix for JDK-8191404
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191404
> Webrev: http://cr.openjdk.java.net/~nishjain/8191404/webrev.00/
> 
> Fix: Updated the LSR data with the version: 2017-08-15
> 
> Regards,
> Nishit Jain

From vladimir.kozlov at oracle.com  Tue Nov 21 23:26:33 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 21 Nov 2017 15:26:33 -0800
Subject: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only
 the permissions it really needs to expose the bean
In-Reply-To: <1750350.QVl7KHXjYn@pracovni>
References: <2138013.zvGs44vPXg@pracovni>
 <715d933a-a747-8aac-620b-fba12f4236e0@oracle.com>
 <7b03728a-a3ad-e392-db1b-dd0807e1ffeb@oracle.com>
 <1750350.QVl7KHXjYn@pracovni>
Message-ID: <bec7f66f-d801-7c52-0eae-8b371b265f4d@oracle.com>

Do we have consensus about changes? I can sponsor and push it.

These changes passed Hotspot pre-integration testing and additional 
requested tests.

Thanks,
Vladimir

On 11/15/17 5:44 AM, Jaroslav Tulach wrote:
> On ?ter? 14. listopadu 2017 21:34:45 CET mandy chung wrote:
>> I am wondering this ACE comes from Graal accessing jdk.vm.ci.services
>> from JVMCI which is defined to the boot loader versus Graal is defined
>> to the platform class loader.
>>
>>    java.security.AccessControlException: access denied
>> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.vm.ci.services")
>>
>> However Graal grants with AllPermissions.
>>
>> In any case, if this is an existing issue, I am okay if you file a
>> separate issue to track this.
> 
> Hello Mandy,
> yes, it looks like issue unrelated to my changes. I have reported: https://
> bugs.openjdk.java.net/browse/JDK-8191320
> 
> I hope I haven't messed up something on my disk and others will be able to
> reproduce my problem.
> -jt
> 
> 
>>
>> Mandy
>>
>> On 11/14/17 2:02 PM, Sean Mullan wrote:
>>> Try running with -Djava.security.debug=access:domain:failure
>>>
>>> This will tell you what ProtectionDomain caused the
>>> AccessControlException, which should give you a better idea of where
>>> the problem is. Look for messages that start with "domain that failed ".
>>>
>>> --Sean
>>>
>>> On 11/14/17 1:22 AM, Jaroslav Tulach wrote:
>>>> I tried the same test with
>>>>
>>>> changeset:   47679:d85284ccd1bd
>>>> user:        sspitsyn
>>>> date:        Fri Nov 03 17:09:25 2017 -0700
>>>> summary:     8189731: Disable CFLH when there are no transformers
>>>>
>>>> and it also yields the exception. E.g. the problem is certainly not
>>>> result of
>>>> my changes.
>>>>
>>>> -jt
>>>>
>>>> PS: I try full rebuild on d85284ccd1bd maybe it disappears...
>>>>
>>>> On pond?l? 13. listopadu 2017 20:53:35 CET Jaroslav Tulach wrote:
>>>>> Hello Mandy,
>>>>>
>>>>> this was a good test:
>>>>>>> ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
>>>>>>> +EnableJVMCI -XX:+UseJVMCICompiler -jar ...
>>>>>>
>>>>>> You can also try running the above command with
>>>>>> -Djava.security.manager
>>>>>> as a sanity test (the application may need additional permissions) -
>>>>>> just a sanity test.
>>>>>
>>>>> I've just tried:
>>>>>
>>>>> $ ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
>>>>> +EnableJVMCI -XX:+UseJVMCICompiler -Djava.security.manager -jar ~/
>>>>> NetBeansProjects/sieve/java/algorithm/target/sieve-algorithm-1.0-SNAPSHO
>>>>> T.ja
>>>>>
>>>>> r
>>>>>
>>>>> and it doesn't work. I am getting an error below, however the code
>>>>> is not
>>>>> running through my module at all. I don't understand the failure, I
>>>>> will
>>>>> have to investigate more.
>>>>>
>>>>> -jt
>>>>>
>>>>>
>>>>> Caused by: java.security.AccessControlException: access denied
>>>>> ("java.lang.RuntimePermission"
>>>>> "accessClassInPackage.jdk.vm.ci.services")
>>>>>           at java.base/
>>>>> java.security.AccessControlContext.checkPermission(AccessControlContext.
>>>>> java>>>
>>>>> : 472)
>>>>>
>>>>>           at java.base/
>>>>> java.security.AccessController.checkPermission(AccessController.java:895
>>>>> )
>>>>>
>>>>>           at java.base/
>>>>> java.lang.SecurityManager.checkPermission(SecurityManager.java:558)
>>>>>           at java.base/
>>>>> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1534)
>>>>>           at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:680)
>>>>>           at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:678)
>>>>>           at
>>>>> java.base/java.security.AccessController.doPrivileged(Native
>>>>> Method)
>>>>>           at java.base/
>>>>> java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:678)
>>>>>           at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>>>>>           at
>>>>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1006) at
>>>>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1085) at
>>>>> java.base/
>>>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:206)
>>>>>           at java.base/
>>>>> jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.ja
>>>>> va:7
>>>>>
>>>>> 60) at java.base/jdk.internal.loader.BuiltinClassLoader.lambda
>>>>> $findClassInModuleOrNull$2(BuiltinClassLoader.java:683)
>>>>>           at
>>>>> java.base/java.security.AccessController.doPrivileged(Native
>>>>> Method)
>>>>>           at java.base/
>>>>> jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinCl
>>>>> assL
>>>>>
>>>>> oader.java: 684)
>>>>>           at java.base/
>>>>> jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java
>>>>> :562
>>>>>
>>>>> ) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:607) at
>>>>> java.base/java.lang.Class.forName(Class.java:451)
>>>>>           at java.base/java.util.ServiceLoader.lambda$loadProvider
>>>>> $1(ServiceLoader.java:856)
>>>>>           at
>>>>> java.base/java.security.AccessController.doPrivileged(Native
>>>>> Method)
>>>>>           at
>>>>> java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java: 858)
> 
> 

From alexandre.iline at oracle.com  Tue Nov 21 23:58:29 2017
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Tue, 21 Nov 2017 15:58:29 -0800
Subject: RFR 8191736: replace javah w/ javac in jdk tests
Message-ID: <56417F20-CEEB-4CC5-B632-ADEEEA492081@oracle.com>

Hi.

Please take look on this quick fix of removing remains of javah usages from test/jdk.

Bug: https://bugs.openjdk.java.net/browse/JDK-8191736
Webrev: http://cr.openjdk.java.net/~shurailine/8191736/webrev.00/

Thank you.

Shura


From jonathan.gibbons at oracle.com  Wed Nov 22 00:09:44 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 21 Nov 2017 16:09:44 -0800
Subject: RFR 8191736: replace javah w/ javac in jdk tests
In-Reply-To: <56417F20-CEEB-4CC5-B632-ADEEEA492081@oracle.com>
References: <56417F20-CEEB-4CC5-B632-ADEEEA492081@oracle.com>
Message-ID: <41750050-dcda-6243-7922-43d4da3bb64a@oracle.com>

Shura,

Looks OK to me, although I'm not normally a Reviewer for AWT tests.

-- Jon


On 11/21/17 3:58 PM, Alexandre (Shura) Iline wrote:
> Hi.
>
> Please take look on this quick fix of removing remains of javah usages from test/jdk.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191736
> Webrev: http://cr.openjdk.java.net/~shurailine/8191736/webrev.00/
>
> Thank you.
>
> Shura
>


From Sergey.Bylokhov at oracle.com  Wed Nov 22 02:19:07 2017
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 21 Nov 2017 18:19:07 -0800
Subject: <AWT Dev> RFR 8191736: replace javah w/ javac in jdk tests
In-Reply-To: <41750050-dcda-6243-7922-43d4da3bb64a@oracle.com>
References: <56417F20-CEEB-4CC5-B632-ADEEEA492081@oracle.com>
 <41750050-dcda-6243-7922-43d4da3bb64a@oracle.com>
Message-ID: <03eb9abb-d588-cea9-ac33-60178f0ee387@oracle.com>

Looks fine.

On 21/11/2017 16:09, Jonathan Gibbons wrote:
> Shura,
> 
> Looks OK to me, although I'm not normally a Reviewer for AWT tests.
> 
> -- Jon
> 
> 
> On 11/21/17 3:58 PM, Alexandre (Shura) Iline wrote:
>> Hi.
>>
>> Please take look on this quick fix of removing remains of javah usages 
>> from test/jdk.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191736
>> Webrev: http://cr.openjdk.java.net/~shurailine/8191736/webrev.00/
>>
>> Thank you.
>>
>> Shura
>>
> 


-- 
Best regards, Sergey.

From john.r.rose at oracle.com  Wed Nov 22 03:05:24 2017
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 21 Nov 2017 19:05:24 -0800
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <E3598621-C8A0-4ECA-9EFB-8D8F6381AF18@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <E3598621-C8A0-4ECA-9EFB-8D8F6381AF18@oracle.com>
Message-ID: <3C4E9D94-34CA-46E0-AC45-EF80FEB0AF99@oracle.com>

On Nov 18, 2017, at 7:34 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Oct 30, 2017, at 6:50 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
>> 
>> (also includes 8184690: add Collectors for collecting into unmodifiable List, Set, and Map)
> 
> Now I'm going to be picky about the names of the Collectors;
> please bear with me a moment.  Consider `toUnmodifiableList`
> and its two cousins (`toUSet`, `toUMap`).
> 
> The most natural names `toList` (etc.) are already taken.
> They mean "do whatever is most useful for the collector,
> perhaps returning unmodifiable or modifiable results".

Let me adjust my position here, FTR.  I am now aware (thanks
Brian) that `toList` is not broken but intentionally under-specified,
pending future changes.  It is my personal hope that the future
changes will specify that the result of `toList` is safely publishable
and an unmodifiable non-view.  This issue is tracked as JDK-8180352.

(Logically possible alternatives would seem to include an otherwise
unconstrained mutable list, an ArrayList, or a continuation of the
"Chef's Choice" policy in effect today.  I suspect we could find
advocates for all of those positions, as evidenced by comments
on JDK-8180352.  I just added mine for the record.)

If at some point in the future `toList` does produce the same
kind of safe list as `List.of`, then I won't have anything to be
picky about.  Other folks can use `toCollection(ArrayList::new)`
or some other explicit op-in for mutability.

For now, a security-conscious user like me can work with
`Collections.toUnmodifiableList`.  That API point will (I hope)
have a short career, ending when `toList` does something at
least as useful.

If at some point in the future `toList` switches to guarantee
the mutable ArrayList (as it seems to supply today), then the
hope for a simple and safe `toList` will be dashed, and we
will have to look for something else that is explicitly oriented
towards value based classes, such as `Collectors.valueList`
and/or `Stream.values`.

Value-based classes are an important "attractor" for API
design, because they can be simultaneously safe and
performant, compared to Java arrays and ArrayList.

(The performance comes from the elimination of copies
under the hood, as well as structure flattening, optimizations
which potential modification makes impossible.  The safety
comes from reduction of difficult-to-find TOCTTOU attack
surfaces, as beyond the usual claimed benefits of "FP style".)

When we get to Valhalla value types, there will be many
more value-based classes in the world, since a value
type cannot be anything other than a value-based class.
Whatever we do with `toList` in the future, it should take
into account value-based usages.  They are here and
more are coming.

One more point:  When programming with value-based
classes, the container is almost irrelevant, and the contents
are the whole story.  Thus, API points which return value-based
multiple values should probably not mention the container
type (List) unless there is a real danger of ambiguity.
If I have a tree node type and I want to use a value-based
List to encode its children, it should look like this:

   List<Node> children() { return this.children; }

or this:

   List<Node> children() { return List.copyOf(this.children); }

not these:

   List<Node> childrenList() ...
   List<Node> listOfChildren() ...
   List<Node> childrenUnmodifiableList() ...
   private List<Node> secretChildrenArray() ...

(etc.)

An API in the value-based style could say, in a class header or
package intro page, that collection values are value-based if not
otherwise specified, and then simply use unmodifiable building
blocks everywhere.

In any case, I think the de-emphasis of container identity enabled
by value-based types provides a subtle but strong push on API
design, towards plural nouns, and away from explicit discussion
of container details.

? John

P.S. Ten years ago I designed the MethodType API, which talks 
about a single return type and multiple parameter types.  The
corresponding API points are returnType and (not parameterTypes
but) parameterList *and* parameterArray.  Because at the time
arrays and lists were both heavily used carriers for multiple values,
we had to focus on the box types (List, Array).  Also we didn't
have VBC rules yet.  In the future I hope similar API designs can
(a) ignore legacy arrays, and (b) just use VBC lists, and then
(c) be a little less noisy about how the data is carried around.

P.P.S. Fully retiring arrays will require dislodging them from
their favored position with varargs and similar spots in the stack.


From john.r.rose at oracle.com  Wed Nov 22 03:31:52 2017
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 21 Nov 2017 19:31:52 -0800
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <1DE20B8F-8A35-43E9-AB8C-5C662FAFFD22@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <3ea78605-b083-1fcc-3cb8-1adc6d76d045@oracle.com>
 <1B0724CA-ADB2-432A-9004-B0A9C6B74F6E@reini.net>
 <CAGB9EW-Zpd4D5Hc1ri4vPjnVQQ1zG7hifHoe=6cYr7zEB2r0Gg@mail.gmail.com>
 <85BE47B6-2214-43AD-B7D0-01F846E42EED@reini.net>
 <a76d535f-7e92-5700-8cb9-2b254eee2153@Oracle.com>
 <ad9c1a86-9ff0-4247-ddcb-00e4d6e80f65@reini.net>
 <4F504EDD-204F-40BE-B477-82132F564C9E@oracle.com>
 <2116128804.2837720.1511001689546.JavaMail.zimbra@u-pem.fr>
 <1DE20B8F-8A35-43E9-AB8C-5C662FAFFD22@oracle.com>
Message-ID: <C618F00F-110E-4200-B707-A63F1707A765@oracle.com>

On Nov 18, 2017, at 8:10 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> I'm with Remi on this.  
> 
> Sent from my MacBook Wheel
> 
>> On Nov 18, 2017, at 5:41 AM, Remi Forax <forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>> wrote:
>> 
>> Hi John,
>> i strongly believe that static fluent methods have no place in a blue collar language
>> ...

>> So in my opinion, the only possible option is to introduce final default methods, i fully understand that this is non trivial to introduce this kind of methods in the VM but this discussion is a good use case for their introduction. 

We have four choices on the table with respect to the occasional
need for securable API points in fluent APIs:

0. Blue collar language:  Pick only one of fluency or security.

1. Secure a default method by marking it final.

2. Secure a fluent API point by binding to a static in the same type.

4. Extension methods:  Anybody can "import" new statics into any type.

I think #0 hurts security, which is why I keep objecting to it.

Brian thinks #1 puts too many restrictions on implementors.

Although it would seem to allow everybody to do whatever they want,
#4 is not a fit for Java.  APIs in java.base are carefully curated,
and allowing third parties to add "nice" methods would interfere
with that curation.

Option #2 has the known good properties of C# extension methods
(decoupling from receiver dispatch, natural notation), without the known
bad properties of C# extension methods (lack of curation).

So #2 is the least ugly solution for an ugly problem, except possibly #1
Which I would accept also.  I would also be glad to see a #5 that would
please everybody.

? John

P.S. Security is a big concern for us developers of java.base.  And it is
surely a concern for everyone else, at least in part.  If you program
behind only a firewall, consider that program integrity and robustness
are corollaries of security.  Your past self and teammates are throwing
buggy code at your present self; you want to be secure from that
even if you don't fear nefarious attackers.  When we secure the
Java stack from nefarious attackers we are also preventing large
numbers of unintentional bugs.


From zheng.jun.li at oracle.com  Wed Nov 22 06:03:26 2017
From: zheng.jun.li at oracle.com (Jack Li)
Date: Wed, 22 Nov 2017 14:03:26 +0800
Subject: RFR: 8187954 Update JAX-WS RI integration to latest version
In-Reply-To: <70FBA9A5-33CA-4064-AA3E-2F8E2B28A3A8@oracle.com>
References: <12668CC3-A8DB-4BDC-9F21-5068CA559DA8@oracle.com>
 <DE008EE6-ABC3-455F-85D0-C83239CD4622@oracle.com>
 <A9736FE3-E30D-4EDD-839F-6FFAB6A4BF38@oracle.com>
 <B53D7902-137F-4082-930F-713D427E3CDF@oracle.com>
 <95066DA9-03A6-4BF1-8895-6A442548EC60@oracle.com>
 <50F96A1B-78C3-4FC4-82E5-691E06749F29@oracle.com>
 <A6E211A7-10B2-4242-939E-F6CEB6BFC726@oracle.com>
 <68A33758-0DA4-4B8A-8692-2A382AC63652@oracle.com>
 <BB9DBC59-0733-42FB-9D0A-27B1C06F555C@oracle.com>
 <8CE70301-1DFA-4C5B-B1E8-A557BE68EE08@oracle.com>
 <06DBFD86-3710-4211-8C00-087DE4F90C04@oracle.com>
 <70FBA9A5-33CA-4064-AA3E-2F8E2B28A3A8@oracle.com>
Message-ID: <F572CE56-AD0C-4D6E-91C1-AB2C9A935DB0@oracle.com>

Hi,

any response?

> On Nov 15, 2017, at 08:05, Jack Li <zheng.jun.li at oracle.com> wrote:
> 
> Hi Lance
> 
> Is there any other issue about it? can you approve it to merge?
> 
>> On Nov 6, 2017, at 07:59, ZhengJun Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>> 
>> 
>> Yes, all the tests are passed.
>> 
>> 
>> ? 2017?11?6??05:05?Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> ???
>> 
>>> Hi Jack,
>>> 
>>> Overall looks OK.  I am assuming all of the test suites are passing?
>>> 
>>> Best
>>> Lance
>>>> On Nov 2, 2017, at 7:34 AM, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>>>> 
>>>> Hi Jack
>>>> 
>>>> Its on my list to finish by the end of the week. 
>>>> 
>>>> Best
>>>> Lance
>>>>> On Nov 2, 2017, at 4:34 AM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>>> 
>>>>> Hi Lance
>>>>> 
>>>>> Is there anything wrong in the new webrev?
>>>>> 
>>>>> 
>>>>>> On Oct 25, 2017, at 10:00, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com> <mailto:zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>>> wrote:
>>>>>> 
>>>>>> Hi Lance,
>>>>>> 
>>>>>> The webrev is updated, can you please review it again?
>>>>>> 
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>> 
>>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01 <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01 <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01>>
>>>>>> 
>>>>>> Summary of changes:
>>>>>> 
>>>>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>>>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>>>>> 
>>>>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>>>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>>>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>>>>> 
>>>>>> 
>>>>>> Patch also contains several small bugfixes, not tracked in JBS.
>>>>>> 
>>>>>>> On Oct 11, 2017, at 18:47, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com> <mailto:lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>>> wrote:
>>>>>>> 
>>>>>>> Hi Jack,
>>>>>>> 
>>>>>>> I would prefer to see an updated webrev so that we do not inadvertently
>>>>>>> push these changes.
>>>>>>> 
>>>>>>> Best
>>>>>>> Lance
>>>>>>>> On Oct 11, 2017, at 3:26 AM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com> <mailto:zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>>> wrote:
>>>>>>>> 
>>>>>>>> Hi Lance
>>>>>>>> 
>>>>>>>> I will update them in Metro repository, do I need to regenerate webrev?
>>>>>>>> or can you skip the files this time and I fix it in next integration?
>>>>>>>> 
>>>>>>>>> On Oct 9, 2017, at 19:35, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com> <mailto:lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Jack,
>>>>>>>>> 
>>>>>>>>> UnMarshaller also has the same issue.  I would update the webrev given the number of places to help sanity check for omissions
>>>>>>>>> 
>>>>>>>>> Best
>>>>>>>>> Lance
>>>>>>>>>> On Oct 8, 2017, at 9:22 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com> <mailto:zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Lance,
>>>>>>>>>> 
>>>>>>>>>> the change is incorrect, it should be ?javax/xml/bind?.
>>>>>>>>>> thanks a lot for your finding, do you think I need to fix it and resubmit the webrev this time?
>>>>>>>>>> or can you skip this file this time and I fix it in next integration?
>>>>>>>>>> 
>>>>>>>>>>> On Oct 4, 2017, at 02:09, Lance Andersen <Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi Jack,
>>>>>>>>>>> 
>>>>>>>>>>> Is this change correct:
>>>>>>>>>>> 
>>>>>>>>>>> -------------
>>>>>>>>>>> --- old/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.968185273 +0100
>>>>>>>>>>> +++ new/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.676185267 +0100
>>>>>>>>>>> @@ -373,7 +373,7 @@
>>>>>>>>>>>      *      If the {@link ValidationEventHandler ValidationEventHandler}
>>>>>>>>>>>      *      returns false from its {@code handleEvent} method or the
>>>>>>>>>>>      *      {@code Marshaller} is unable to marshal {@code jaxbElement} (or any
>>>>>>>>>>> -     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/javax/xml/bind/Marshaller.html#elementMarshalling">
>>>>>>>>>>> +     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/java/xml/bind/Marshaller.html#elementMarshalling">
>>>>>>>>>>>      *      Marshalling a JAXB element</a>.
>>>>>>>>>>> 
>>>>>>>>>>> ------------
>>>>>>>>>>> 
>>>>>>>>>>> The URL that is being changed currently works
>>>>>>>>>>> 
>>>>>>>>>>> Best
>>>>>>>>>>> Lance
>>>>>>>>>>> On Sep 29, 2017, at 10:55 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com> <mailto:zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>>>>>>>>>> 
>>>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>>>
>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>>>
>>>>>>>>>>>> 
>>>>>>>>>>>> Summary of changes:
>>>>>>>>>>>> 
>>>>>>>>>>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>>>>>>>>>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>>>>>>>>>>> 
>>>>>>>>>>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>>>>>>>>>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>>>>>>>>>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Patch also contains several small bugfixes, not tracked in JBS.
>>>>>>>>>>>> 
>>>>>>>>>>>> ----------------
>>>>>>>>>>>> Best regards
>>>>>>>>>>>> Jack Li
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> <oracle_sig_logo.gif>
>>>>>>>>>>> 
>>>>>>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>>>>>> Oracle Java Engineering 
>>>>>>>>>>> 1 Network Drive 
>>>>>>>>>>> Burlington, MA 01803
>>>>>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
>>>>>>>>>> 
>>>>>>>>>> ----------------
>>>>>>>>>> Best regards
>>>>>>>>>> Jack Li
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>>>> Oracle Java Engineering 
>>>>>>>>> 1 Network Drive 
>>>>>>>>> Burlington, MA 01803
>>>>>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ----------------
>>>>>>>> Best regards
>>>>>>>> Jack Li
>>>>>>> 
>>>>>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>> Oracle Java Engineering 
>>>>>>> 1 Network Drive 
>>>>>>> Burlington, MA 01803
>>>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ----------------
>>>>>> Best regards
>>>>>> Jack Li
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> ----------------
>>>>> Best regards
>>>>> Jack Li
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle Java Engineering 
>>>> 1 Network Drive 
>>>> Burlington, MA 01803
>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
>>>> 
>>>> 
>>>> 
>>> 
>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering 
>>> 1 Network Drive 
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>> 
>>> 
>>> 
> 
> 
> ----------------
> Best regards
> Jack Li
> 
> 
> 
> 
> 
> 


----------------
Best regards
Jack Li







From goetz.lindenmaier at sap.com  Wed Nov 22 06:53:18 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 22 Nov 2017 06:53:18 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <C882395B-87CF-428B-A74D-707490930E07@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
 <f0be5806bf4442eeb5802df736210ead@sap.com>
 <C882395B-87CF-428B-A74D-707490930E07@oracle.com>
Message-ID: <ff1b4c1650cd48f28fa8d1cd38f18579@sap.com>

Hi Max, 

while removing the comments from the k-tools, I saw this:

--- a/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java	Tue Oct 10 14:39:45 2017 +0200
+++ b/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java	Tue Nov 21 13:09:17 2017 +0100
@@ -356,7 +358,6 @@
         System.out.println("\t-t \t shows keytab entry timestamps");
         System.out.println("\t-K \t shows keytab entry key value");
         System.out.println("\t-e \t shows keytab entry key type");
-        System.out.println("\nUsage: java sun.security.krb5.tools.Klist " +
-                           "-help for help.");
+        System.out.println("\n-? -h --help print this help message and exit");
     }
 }

I don't think the old comment is in the original program :) and anyways, -help
is not supported by Klist.  It prints the usage called with the flag, but just because
it prints it on any wrong flag.

So should I replace the comment here?
Or at least remove it?

Best regards,
  Goetz

> -----Original Message-----
> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> Sent: Monday, November 20, 2017 3:49 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
> dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Hi Goetz
> 
> I understand your intention.
> 
> If the reason is that one day every tool will switch to this new style, please at
> least do not include kinit, klist and ktab. These Windows-only commands are
> meant to emulate MIT krb5 tools with the same names and we need to keep
> the option (and maybe the help screen) as similar as possible.
> 
> I am OK with supporting the --help option undocumented.
> 
> Thanks
> Max
> 
> > On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi Max,
> >
> > I think there are so many tools mixing both kinds of
> > options, that it's rather a gain if all at least document
> > the same, up to date help message, than if the documentation
> > is skipped for some.
> >
> > After my change, all the help messages are quite similar.
> > I updated them to use the same wording while trying to
> > keep the sentence structure in accordance with the other
> > documented flags, see below.
> >
> > Best regards,
> >  Goetz.
> >
> >
> >
> > -? -h --help               display this help message
> > -? -h --help              display this help message
> > -h, --help (Print this help message.)
> > -?, --help                   Print this help message
> > -? -h --help                 Print this help message
> > --help, -h, -?  Display command line options and exit
> > -? -h --help                     Print this help message
> > -h -? --help                  Print this help message
> > -? -h --help
> > -? -h --help          : display this help message and exit
> > -? -h --help       :  display this help message and exit
> > -? -h --help      print this help message and exit
> > -? | -h | --help     to print this help message
> > jmap -? -h --help  to print this help message
> > usage: jps [-? -h --help]
> > -? -h --help to print this help message
> > -? -h --help  Prints this help message.
> > -? -h --help print this help message
> > -? -h --help          Print this synopsis of standard options and exit
> > Use "keytool -? -h or --help" for all available commands
> > --help        print this help message to the output stream
> > -?, -h, --help                       Print this help message
> > -h, --help, -?                        Print this help message
> > -?, -h, --help                       Print this help message
> > -? -h --help         Print this help message and exit
> > -?, -h, --help                  print this help message
> > -?, -h, --help                print this help message
> > -? -h --help           Print this help message
> > -?, -h, --help[:compat]    Give this, or optionally the compatibility, help
> > [-? -h --help]              Print this help message
> > jstatd -?|-h|--help
> >
> >
> >> -----Original Message-----
> >> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> >> Sent: Sonntag, 19. November 2017 01:28
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
> >> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
> >> dev at openjdk.java.net>
> >> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> >>
> >> I am OK with all commands supporting --help, but I am not sure if every
> tool
> >> should show it on the help screen if the tools's other options are still using
> >> the old single-"-" style. It looks like the tools are half-converted.
> >>
> >> Is there a timetable to add "--" support to all tools?
> >>
> >> Thanks
> >> Max
> >>
> >>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz
> >> <goetz.lindenmaier at sap.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> please review this change. I also filed a CSR for this:
> >>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
> >> helpMessage/webrev.02/
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >>>
> >>> See the webrev for a detailed description of the changes.
> >>>
> >>> If required, I'll make break-out changes to be reviewed separately.
> >>>
> >>> I had posted a RFR before, but improved the change to
> >>> give a more complete overview of currently supported flags
> >>> for the CSR:
> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> >> October/028615.html
> >>>
> >>> Best regards,
> >>> Goetz.
> >>>
> >


From weijun.wang at oracle.com  Wed Nov 22 07:07:51 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 22 Nov 2017 15:07:51 +0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <ff1b4c1650cd48f28fa8d1cd38f18579@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
 <f0be5806bf4442eeb5802df736210ead@sap.com>
 <C882395B-87CF-428B-A74D-707490930E07@oracle.com>
 <ff1b4c1650cd48f28fa8d1cd38f18579@sap.com>
Message-ID: <5143F580-CDB0-4970-AC7A-038608E59FAA@oracle.com>

Hi Goetz

I would just remove it.

Thanks
Max

> On Nov 22, 2017, at 2:53 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi Max, 
> 
> while removing the comments from the k-tools, I saw this:
> 
> --- a/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java	Tue Oct 10 14:39:45 2017 +0200
> +++ b/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java	Tue Nov 21 13:09:17 2017 +0100
> @@ -356,7 +358,6 @@
>         System.out.println("\t-t \t shows keytab entry timestamps");
>         System.out.println("\t-K \t shows keytab entry key value");
>         System.out.println("\t-e \t shows keytab entry key type");
> -        System.out.println("\nUsage: java sun.security.krb5.tools.Klist " +
> -                           "-help for help.");
> +        System.out.println("\n-? -h --help print this help message and exit");
>     }
> }
> 
> I don't think the old comment is in the original program :) and anyways, -help
> is not supported by Klist.  It prints the usage called with the flag, but just because
> it prints it on any wrong flag.
> 
> So should I replace the comment here?
> Or at least remove it?
> 
> Best regards,
>  Goetz
> 
>> -----Original Message-----
>> From: Weijun Wang [mailto:weijun.wang at oracle.com]
>> Sent: Monday, November 20, 2017 3:49 PM
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
>> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
>> dev at openjdk.java.net>
>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
>> 
>> Hi Goetz
>> 
>> I understand your intention.
>> 
>> If the reason is that one day every tool will switch to this new style, please at
>> least do not include kinit, klist and ktab. These Windows-only commands are
>> meant to emulate MIT krb5 tools with the same names and we need to keep
>> the option (and maybe the help screen) as similar as possible.
>> 
>> I am OK with supporting the --help option undocumented.
>> 
>> Thanks
>> Max
>> 
>>> On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com> wrote:
>>> 
>>> Hi Max,
>>> 
>>> I think there are so many tools mixing both kinds of
>>> options, that it's rather a gain if all at least document
>>> the same, up to date help message, than if the documentation
>>> is skipped for some.
>>> 
>>> After my change, all the help messages are quite similar.
>>> I updated them to use the same wording while trying to
>>> keep the sentence structure in accordance with the other
>>> documented flags, see below.
>>> 
>>> Best regards,
>>> Goetz.
>>> 
>>> 
>>> 
>>> -? -h --help               display this help message
>>> -? -h --help              display this help message
>>> -h, --help (Print this help message.)
>>> -?, --help                   Print this help message
>>> -? -h --help                 Print this help message
>>> --help, -h, -?  Display command line options and exit
>>> -? -h --help                     Print this help message
>>> -h -? --help                  Print this help message
>>> -? -h --help
>>> -? -h --help          : display this help message and exit
>>> -? -h --help       :  display this help message and exit
>>> -? -h --help      print this help message and exit
>>> -? | -h | --help     to print this help message
>>> jmap -? -h --help  to print this help message
>>> usage: jps [-? -h --help]
>>> -? -h --help to print this help message
>>> -? -h --help  Prints this help message.
>>> -? -h --help print this help message
>>> -? -h --help          Print this synopsis of standard options and exit
>>> Use "keytool -? -h or --help" for all available commands
>>> --help        print this help message to the output stream
>>> -?, -h, --help                       Print this help message
>>> -h, --help, -?                        Print this help message
>>> -?, -h, --help                       Print this help message
>>> -? -h --help         Print this help message and exit
>>> -?, -h, --help                  print this help message
>>> -?, -h, --help                print this help message
>>> -? -h --help           Print this help message
>>> -?, -h, --help[:compat]    Give this, or optionally the compatibility, help
>>> [-? -h --help]              Print this help message
>>> jstatd -?|-h|--help
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Weijun Wang [mailto:weijun.wang at oracle.com]
>>>> Sent: Sonntag, 19. November 2017 01:28
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
>>>> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
>>>> dev at openjdk.java.net>
>>>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
>>>> 
>>>> I am OK with all commands supporting --help, but I am not sure if every
>> tool
>>>> should show it on the help screen if the tools's other options are still using
>>>> the old single-"-" style. It looks like the tools are half-converted.
>>>> 
>>>> Is there a timetable to add "--" support to all tools?
>>>> 
>>>> Thanks
>>>> Max
>>>> 
>>>>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz
>>>> <goetz.lindenmaier at sap.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> please review this change. I also filed a CSR for this:
>>>>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
>>>> helpMessage/webrev.02/
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>>>>> 
>>>>> See the webrev for a detailed description of the changes.
>>>>> 
>>>>> If required, I'll make break-out changes to be reviewed separately.
>>>>> 
>>>>> I had posted a RFR before, but improved the change to
>>>>> give a more complete overview of currently supported flags
>>>>> for the CSR:
>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
>>>> October/028615.html
>>>>> 
>>>>> Best regards,
>>>>> Goetz.
>>>>> 
>>> 
> 


From goetz.lindenmaier at sap.com  Wed Nov 22 07:13:39 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 22 Nov 2017 07:13:39 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <5143F580-CDB0-4970-AC7A-038608E59FAA@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com>
 <f0be5806bf4442eeb5802df736210ead@sap.com>
 <C882395B-87CF-428B-A74D-707490930E07@oracle.com>
 <ff1b4c1650cd48f28fa8d1cd38f18579@sap.com>
 <5143F580-CDB0-4970-AC7A-038608E59FAA@oracle.com>
Message-ID: <8f6273ffa9cc4b119f0004052f29c711@sap.com>

OK, thanks!

Best regards,
  Goetz.

> -----Original Message-----
> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> Sent: Wednesday, November 22, 2017 8:08 AM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
> dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Hi Goetz
> 
> I would just remove it.
> 
> Thanks
> Max
> 
> > On Nov 22, 2017, at 2:53 PM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi Max,
> >
> > while removing the comments from the k-tools, I saw this:
> >
> > ---
> a/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Kl
> ist.java	Tue Oct 10 14:39:45 2017 +0200
> > +++
> b/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Kl
> ist.java	Tue Nov 21 13:09:17 2017 +0100
> > @@ -356,7 +358,6 @@
> >         System.out.println("\t-t \t shows keytab entry timestamps");
> >         System.out.println("\t-K \t shows keytab entry key value");
> >         System.out.println("\t-e \t shows keytab entry key type");
> > -        System.out.println("\nUsage: java sun.security.krb5.tools.Klist " +
> > -                           "-help for help.");
> > +        System.out.println("\n-? -h --help print this help message and exit");
> >     }
> > }
> >
> > I don't think the old comment is in the original program :) and anyways, -
> help
> > is not supported by Klist.  It prints the usage called with the flag, but just
> because
> > it prints it on any wrong flag.
> >
> > So should I replace the comment here?
> > Or at least remove it?
> >
> > Best regards,
> >  Goetz
> >
> >> -----Original Message-----
> >> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> >> Sent: Monday, November 20, 2017 3:49 PM
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
> >> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
> >> dev at openjdk.java.net>
> >> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> >>
> >> Hi Goetz
> >>
> >> I understand your intention.
> >>
> >> If the reason is that one day every tool will switch to this new style, please
> at
> >> least do not include kinit, klist and ktab. These Windows-only commands
> are
> >> meant to emulate MIT krb5 tools with the same names and we need to
> keep
> >> the option (and maybe the help screen) as similar as possible.
> >>
> >> I am OK with supporting the --help option undocumented.
> >>
> >> Thanks
> >> Max
> >>
> >>> On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz
> >> <goetz.lindenmaier at sap.com> wrote:
> >>>
> >>> Hi Max,
> >>>
> >>> I think there are so many tools mixing both kinds of
> >>> options, that it's rather a gain if all at least document
> >>> the same, up to date help message, than if the documentation
> >>> is skipped for some.
> >>>
> >>> After my change, all the help messages are quite similar.
> >>> I updated them to use the same wording while trying to
> >>> keep the sentence structure in accordance with the other
> >>> documented flags, see below.
> >>>
> >>> Best regards,
> >>> Goetz.
> >>>
> >>>
> >>>
> >>> -? -h --help               display this help message
> >>> -? -h --help              display this help message
> >>> -h, --help (Print this help message.)
> >>> -?, --help                   Print this help message
> >>> -? -h --help                 Print this help message
> >>> --help, -h, -?  Display command line options and exit
> >>> -? -h --help                     Print this help message
> >>> -h -? --help                  Print this help message
> >>> -? -h --help
> >>> -? -h --help          : display this help message and exit
> >>> -? -h --help       :  display this help message and exit
> >>> -? -h --help      print this help message and exit
> >>> -? | -h | --help     to print this help message
> >>> jmap -? -h --help  to print this help message
> >>> usage: jps [-? -h --help]
> >>> -? -h --help to print this help message
> >>> -? -h --help  Prints this help message.
> >>> -? -h --help print this help message
> >>> -? -h --help          Print this synopsis of standard options and exit
> >>> Use "keytool -? -h or --help" for all available commands
> >>> --help        print this help message to the output stream
> >>> -?, -h, --help                       Print this help message
> >>> -h, --help, -?                        Print this help message
> >>> -?, -h, --help                       Print this help message
> >>> -? -h --help         Print this help message and exit
> >>> -?, -h, --help                  print this help message
> >>> -?, -h, --help                print this help message
> >>> -? -h --help           Print this help message
> >>> -?, -h, --help[:compat]    Give this, or optionally the compatibility, help
> >>> [-? -h --help]              Print this help message
> >>> jstatd -?|-h|--help
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> >>>> Sent: Sonntag, 19. November 2017 01:28
> >>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >>>> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net;
> >>>> serviceability-dev (serviceability-dev at openjdk.java.net) <serviceability-
> >>>> dev at openjdk.java.net>
> >>>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> >>>>
> >>>> I am OK with all commands supporting --help, but I am not sure if every
> >> tool
> >>>> should show it on the help screen if the tools's other options are still
> using
> >>>> the old single-"-" style. It looks like the tools are half-converted.
> >>>>
> >>>> Is there a timetable to add "--" support to all tools?
> >>>>
> >>>> Thanks
> >>>> Max
> >>>>
> >>>>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz
> >>>> <goetz.lindenmaier at sap.com> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> please review this change. I also filed a CSR for this:
> >>>>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
> >>>> helpMessage/webrev.02/
> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >>>>>
> >>>>> See the webrev for a detailed description of the changes.
> >>>>>
> >>>>> If required, I'll make break-out changes to be reviewed separately.
> >>>>>
> >>>>> I had posted a RFR before, but improved the change to
> >>>>> give a more complete overview of currently supported flags
> >>>>> for the CSR:
> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> >>>> October/028615.html
> >>>>>
> >>>>> Best regards,
> >>>>> Goetz.
> >>>>>
> >>>
> >


From Alan.Bateman at oracle.com  Wed Nov 22 07:35:23 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 22 Nov 2017 07:35:23 +0000
Subject: RFR 8191173 : (cl) Clarify or remove "for delegation" in
 ClassLoader spec
In-Reply-To: <04a91618-7dba-17dd-8360-7f81369c3be1@oracle.com>
References: <04a91618-7dba-17dd-8360-7f81369c3be1@oracle.com>
Message-ID: <fc8f9b0c-74df-6c0c-9c96-6c5d5346d78e@oracle.com>



On 21/11/2017 20:41, Brent Christian wrote:
> Hi,
>
> Please review my change to this small bit of ClassLoader spec that can 
> be tidied up, as noticed by Martin.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8191173
> Webrev:
> http://cr.openjdk.java.net/~bchristi/8191173/webrev.00/
This looks okay. One could argue that getParent should be changed too as 
there is never any guarantee that delegation will be to the parent but 
what you have is fine.

-Alan

From nishit.jain at oracle.com  Wed Nov 22 08:13:01 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Wed, 22 Nov 2017 13:43:01 +0530
Subject: <i18n dev> [10] RFR 8191404: Upgrading JDK with latest available
 LSR data from IANA.
In-Reply-To: <a528efb8-12d2-8a3c-e802-64e3d7355042@oracle.com>
References: <38d7fa00-252f-cd42-500a-deda1fef843f@oracle.com>
 <a528efb8-12d2-8a3c-e802-64e3d7355042@oracle.com>
Message-ID: <194793aa-d9b3-2d1d-5772-62b05cad7ff8@oracle.com>

Thanks Naoto,

 > One nit in the test. At line 71, probably the original intention of 
"str" is to list the accept languages in alphabetic order. Would you 
change it?
Yes, it is sorted according to weight then alphabetically. Updated the 
test case.

http://cr.openjdk.java.net/~nishjain/8191404/webrev.01/

 > I have not looked into actual tags in the test. Did you modify them 
manually? If so, it would be desirable to make it automated.
Yes, currently the updated tags are added in the test case manually. 
Making it automated is in the target list, will file/take it as a 
separate issue.
I would like to bring one point to notice that, I have not added all the 
new tags (which are added in this version) in the test case, just few of 
them are added to test that LocaleEquivalentMaps are properly updated. 
Hope that is fine.

Regards,
Nishit Jain
On 22-11-2017 04:47, Naoto Sato wrote:
> Hi Nishit,
>
> One nit in the test. At line 71, probably the original intention of 
> "str" is to list the accept languages in alphabetic order. Would you 
> change it?
>
> I have not looked into actual tags in the test. Did? you modify them 
> manually? If so, it would be desirable to make it automated.
>
> Naoto
>
> On 11/16/17 3:47 AM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8191404
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191404
>> Webrev: http://cr.openjdk.java.net/~nishjain/8191404/webrev.00/
>>
>> Fix: Updated the LSR data with the version: 2017-08-15
>>
>> Regards,
>> Nishit Jain


From Alan.Bateman at oracle.com  Wed Nov 22 08:23:51 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 22 Nov 2017 08:23:51 +0000
Subject: JDK-8191706: Proposal to add Reader::transferTo(Writer)
In-Reply-To: <0d53fe18-9443-201d-c4bd-7f9c973b0602@reini.net>
References: <0d53fe18-9443-201d-c4bd-7f9c973b0602@reini.net>
Message-ID: <ae4d9788-49d0-49fc-f406-f10cc486d147@oracle.com>



On 21/11/2017 19:56, Patrick Reinhart wrote:
> Hi there out a the review [1] for? JDK-8066870, that will need some more
> working on, I created this specific issue to add an transferTo method to
> the java.io.Reader as it seems more clear as of the similarity to
> java.io.InputStream.transferTo(java.io.OutputStream) in terms of the API.
>
The updated proposal looks good. One minor nit on the javadoc is that it 
says "end of the data". The existing read methods use "end of the 
stream" so best to keep that consistent.

-Alan.

From sean.coffey at oracle.com  Wed Nov 22 09:59:59 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 22 Nov 2017 09:59:59 +0000
Subject: RFR: 8189789: tomcat gzip-compressed response bodies appear to be
 broken in update 151
Message-ID: <d9854879-115b-ddd6-a3f1-cfba04bca9ea@oracle.com>

Looking to fix a recent regression that appeared in 8u151. Thanks goes 
to Sherman for the src patch. Paul Hohensee has also helped by provided 
some test code. I've been able to modify an existing test to mimic the 
behaviour seen with FlushableGZIPOutputStream which is found in Tomcat 7.x.

Sherman is working on a patch for JDK 10. For unix OSes, JDK 10 operates 
with the zlib version found on the OS.

bug : https://bugs.openjdk.java.net/browse/JDK-8189789
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/

regards,
Sean.


From lance.andersen at oracle.com  Wed Nov 22 11:31:21 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 22 Nov 2017 06:31:21 -0500
Subject: RFR: 8187954 Update JAX-WS RI integration to latest version
In-Reply-To: <F572CE56-AD0C-4D6E-91C1-AB2C9A935DB0@oracle.com>
References: <12668CC3-A8DB-4BDC-9F21-5068CA559DA8@oracle.com>
 <DE008EE6-ABC3-455F-85D0-C83239CD4622@oracle.com>
 <A9736FE3-E30D-4EDD-839F-6FFAB6A4BF38@oracle.com>
 <B53D7902-137F-4082-930F-713D427E3CDF@oracle.com>
 <95066DA9-03A6-4BF1-8895-6A442548EC60@oracle.com>
 <50F96A1B-78C3-4FC4-82E5-691E06749F29@oracle.com>
 <A6E211A7-10B2-4242-939E-F6CEB6BFC726@oracle.com>
 <68A33758-0DA4-4B8A-8692-2A382AC63652@oracle.com>
 <BB9DBC59-0733-42FB-9D0A-27B1C06F555C@oracle.com>
 <8CE70301-1DFA-4C5B-B1E8-A557BE68EE08@oracle.com>
 <06DBFD86-3710-4211-8C00-087DE4F90C04@oracle.com>
 <70FBA9A5-33CA-4064-AA3E-2F8E2B28A3A8@oracle.com>
 <F572CE56-AD0C-4D6E-91C1-AB2C9A935DB0@oracle.com>
Message-ID: <A120C974-6BF9-46F5-80B8-3D4A2640F9C4@oracle.com>

Hi Jack

I said previously that the last round of changes were OK so you are good to go

> On Nov 22, 2017, at 1:03 AM, Jack Li <zheng.jun.li at oracle.com> wrote:
> 
> Hi,
> 
> any response?
> 
>> On Nov 15, 2017, at 08:05, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>> 
>> Hi Lance
>> 
>> Is there any other issue about it? can you approve it to merge?
>> 
>>> On Nov 6, 2017, at 07:59, ZhengJun Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>> 
>>> 
>>> Yes, all the tests are passed.
>>> 
>>> 
>>> ? 2017?11?6??05:05?Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> ???
>>> 
>>>> Hi Jack,
>>>> 
>>>> Overall looks OK.  I am assuming all of the test suites are passing?
>>>> 
>>>> Best
>>>> Lance
>>>>> On Nov 2, 2017, at 7:34 AM, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>>>>> 
>>>>> Hi Jack
>>>>> 
>>>>> Its on my list to finish by the end of the week. 
>>>>> 
>>>>> Best
>>>>> Lance
>>>>>> On Nov 2, 2017, at 4:34 AM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>>>> 
>>>>>> Hi Lance
>>>>>> 
>>>>>> Is there anything wrong in the new webrev?
>>>>>> 
>>>>>> 
>>>>>>> On Oct 25, 2017, at 10:00, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com> <mailto:zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>>> wrote:
>>>>>>> 
>>>>>>> Hi Lance,
>>>>>>> 
>>>>>>> The webrev is updated, can you please review it again?
>>>>>>> 
>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>> 
>>>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01 <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01 <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01>>
>>>>>>> 
>>>>>>> Summary of changes:
>>>>>>> 
>>>>>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>>>>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>>>>>> 
>>>>>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>>>>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>>>>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>>>>>> 
>>>>>>> 
>>>>>>> Patch also contains several small bugfixes, not tracked in JBS.
>>>>>>> 
>>>>>>>> On Oct 11, 2017, at 18:47, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com> <mailto:lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>>> wrote:
>>>>>>>> 
>>>>>>>> Hi Jack,
>>>>>>>> 
>>>>>>>> I would prefer to see an updated webrev so that we do not inadvertently
>>>>>>>> push these changes.
>>>>>>>> 
>>>>>>>> Best
>>>>>>>> Lance
>>>>>>>>> On Oct 11, 2017, at 3:26 AM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com> <mailto:zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Lance
>>>>>>>>> 
>>>>>>>>> I will update them in Metro repository, do I need to regenerate webrev?
>>>>>>>>> or can you skip the files this time and I fix it in next integration?
>>>>>>>>> 
>>>>>>>>>> On Oct 9, 2017, at 19:35, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com> <mailto:lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Jack,
>>>>>>>>>> 
>>>>>>>>>> UnMarshaller also has the same issue.  I would update the webrev given the number of places to help sanity check for omissions
>>>>>>>>>> 
>>>>>>>>>> Best
>>>>>>>>>> Lance
>>>>>>>>>>> On Oct 8, 2017, at 9:22 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com> <mailto:zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi Lance,
>>>>>>>>>>> 
>>>>>>>>>>> the change is incorrect, it should be ?javax/xml/bind?.
>>>>>>>>>>> thanks a lot for your finding, do you think I need to fix it and resubmit the webrev this time?
>>>>>>>>>>> or can you skip this file this time and I fix it in next integration?
>>>>>>>>>>> 
>>>>>>>>>>>> On Oct 4, 2017, at 02:09, Lance Andersen <Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Jack,
>>>>>>>>>>>> 
>>>>>>>>>>>> Is this change correct:
>>>>>>>>>>>> 
>>>>>>>>>>>> -------------
>>>>>>>>>>>> --- old/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.968185273 +0100
>>>>>>>>>>>> +++ new/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.676185267 +0100
>>>>>>>>>>>> @@ -373,7 +373,7 @@
>>>>>>>>>>>>      *      If the {@link ValidationEventHandler ValidationEventHandler}
>>>>>>>>>>>>      *      returns false from its {@code handleEvent} method or the
>>>>>>>>>>>>      *      {@code Marshaller} is unable to marshal {@code jaxbElement} (or any
>>>>>>>>>>>> -     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/javax/xml/bind/Marshaller.html#elementMarshalling">
>>>>>>>>>>>> +     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/java/xml/bind/Marshaller.html#elementMarshalling">
>>>>>>>>>>>>      *      Marshalling a JAXB element</a>.
>>>>>>>>>>>> 
>>>>>>>>>>>> ------------
>>>>>>>>>>>> 
>>>>>>>>>>>> The URL that is being changed currently works
>>>>>>>>>>>> 
>>>>>>>>>>>> Best
>>>>>>>>>>>> Lance
>>>>>>>>>>>> On Sep 29, 2017, at 10:55 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com> <mailto:zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>>>
>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>>>
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Summary of changes:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>>>>>>>>>>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>>>>>>>>>>>> 
>>>>>>>>>>>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>>>>>>>>>>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>>>>>>>>>>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Patch also contains several small bugfixes, not tracked in JBS.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ----------------
>>>>>>>>>>>>> Best regards
>>>>>>>>>>>>> Jack Li
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> <oracle_sig_logo.gif>
>>>>>>>>>>>> 
>>>>>>>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>>>>>>> Oracle Java Engineering 
>>>>>>>>>>>> 1 Network Drive 
>>>>>>>>>>>> Burlington, MA 01803
>>>>>>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
>>>>>>>>>>> 
>>>>>>>>>>> ----------------
>>>>>>>>>>> Best regards
>>>>>>>>>>> Jack Li
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>>>>> Oracle Java Engineering 
>>>>>>>>>> 1 Network Drive 
>>>>>>>>>> Burlington, MA 01803
>>>>>>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ----------------
>>>>>>>>> Best regards
>>>>>>>>> Jack Li
>>>>>>>> 
>>>>>>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>>> Oracle Java Engineering 
>>>>>>>> 1 Network Drive 
>>>>>>>> Burlington, MA 01803
>>>>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ----------------
>>>>>>> Best regards
>>>>>>> Jack Li
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ----------------
>>>>>> Best regards
>>>>>> Jack Li
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>> Oracle Java Engineering 
>>>>> 1 Network Drive 
>>>>> Burlington, MA 01803
>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> <oracle_sig_logo.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle Java Engineering 
>>>> 1 Network Drive 
>>>> Burlington, MA 01803
>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>> 
>>>> 
>>>> 
>> 
>> 
>> ----------------
>> Best regards
>> Jack Li
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> ----------------
> Best regards
> Jack Li
> 
> 
> 
> 
> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From forax at univ-mlv.fr  Wed Nov 22 11:40:45 2017
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 22 Nov 2017 12:40:45 +0100 (CET)
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <C618F00F-110E-4200-B707-A63F1707A765@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <85BE47B6-2214-43AD-B7D0-01F846E42EED@reini.net>
 <a76d535f-7e92-5700-8cb9-2b254eee2153@Oracle.com>
 <ad9c1a86-9ff0-4247-ddcb-00e4d6e80f65@reini.net>
 <4F504EDD-204F-40BE-B477-82132F564C9E@oracle.com>
 <2116128804.2837720.1511001689546.JavaMail.zimbra@u-pem.fr>
 <1DE20B8F-8A35-43E9-AB8C-5C662FAFFD22@oracle.com>
 <C618F00F-110E-4200-B707-A63F1707A765@oracle.com>
Message-ID: <690160043.1192195.1511350845295.JavaMail.zimbra@u-pem.fr>

> De: "John Rose" <john.r.rose at oracle.com>
> ?: "Brian Goetz" <brian.goetz at oracle.com>, "R?mi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mercredi 22 Novembre 2017 04:31:52
> Objet: Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set,
> Map

> On Nov 18, 2017, at 8:10 AM, Brian Goetz < [ mailto:brian.goetz at oracle.com |
> brian.goetz at oracle.com ] > wrote:

>> I'm with Remi on this.

>> Sent from my MacBook Wheel

>>> On Nov 18, 2017, at 5:41 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>>> forax at univ-mlv.fr ] > wrote:

>>> Hi John,
>>> i strongly believe that static fluent methods have no place in a blue collar
>>> language
>>> ...
>>> So in my opinion, the only possible option is to introduce final default
>>> methods, i fully understand that this is non trivial to introduce this kind of
>>> methods in the VM but this discussion is a good use case for their
>>> introduction.

> We have four choices on the table with respect to the occasional
> need for securable API points in fluent APIs:

> 0. Blue collar language: Pick only one of fluency or security.

> 1. Secure a default method by marking it final.

> 2. Secure a fluent API point by binding to a static in the same type.

> 4. Extension methods: Anybody can "import" new statics into any type.

> I think #0 hurts security, which is why I keep objecting to it.

> Brian thinks #1 puts too many restrictions on implementors.

The whole point of final on methods is to add security and as a side effect, it bother the implementors. Security always bother people that doesn't have to handle security issues. 
So you can have security even in a blue collar language. 

I do not see the point to add a new semantics if you have a way to solve the current issue by applying a know semantics 'final' on an already existing feature 'default method'. 

> Although it would seem to allow everybody to do whatever they want,
> #4 is not a fit for Java. APIs in java.base are carefully curated,
> and allowing third parties to add "nice" methods would interfere
> with that curation.

> Option #2 has the known good properties of C# extension methods
> (decoupling from receiver dispatch, natural notation), without the known
> bad properties of C# extension methods (lack of curation).

> So #2 is the least ugly solution for an ugly problem, except possibly #1
> Which I would accept also.

#2 also works by accident, the fact that by inheritance you can see static method is ugly. 
The lambda EG has made clear that the fact that you can see a static method by inheritance was a mistake by making static methods in interface non visible by inheritance. 

> I would also be glad to see a #5 that would please everybody.

or a #3, there is no #3 in your list. 

> ? John

R?mi 

> P.S. Security is a big concern for us developers of java.base. And it is
> surely a concern for everyone else, at least in part. If you program
> behind only a firewall, consider that program integrity and robustness
> are corollaries of security. Your past self and teammates are throwing
> buggy code at your present self; you want to be secure from that
> even if you don't fear nefarious attackers. When we secure the
> Java stack from nefarious attackers we are also preventing large
> numbers of unintentional bugs.

I think everybody on this list agree about that point. 

From scolebourne at joda.org  Wed Nov 22 15:42:56 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 22 Nov 2017 15:42:56 +0000
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <E3598621-C8A0-4ECA-9EFB-8D8F6381AF18@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <E3598621-C8A0-4ECA-9EFB-8D8F6381AF18@oracle.com>
Message-ID: <CACzrW9DibVN=ajMJBSQhZzNdZDWM1LPsXPH6M=ryt28kgZS3ag@mail.gmail.com>

On 19 November 2017 at 03:34, John Rose <john.r.rose at oracle.com> wrote:
> Meanwhile, `toUnmodifiableList` is so ugly to the ear,
> eye, and fingers that it will be less used just because of
> its long spelling.

Many developers are already using Google Guava which has added
toImmutableList() and friends. More widely, we use the toXxx() form
for all the collectors we've written (in OpenGamma Strata). As such, I
think the toXxx() naming is well established at this point, and
toUnmodifiableList() will be fine.

Stephen

From hohensee at amazon.com  Wed Nov 22 15:46:26 2017
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 22 Nov 2017 15:46:26 +0000
Subject: 8189789: tomcat gzip-compressed response bodies appear to be
 broken in update 151
In-Reply-To: <d9854879-115b-ddd6-a3f1-cfba04bca9ea@oracle.com>
References: <d9854879-115b-ddd6-a3f1-cfba04bca9ea@oracle.com>
Message-ID: <330832F9-E047-41B9-82BD-44BD75EA9CCA@amazon.com>

If the fix is from the zlib project, then ignore the following, since it?s their code.

In Deflater.c: the existing significant code duplication between the arms of the if-else gives one pause. E.g., in the new file, compare lines 148/183 and 155/190. Might be bugs lurking at 183 and 190.

In deflate.c: the old code had ?s->last_flush = Z_NO_FLUSH?, the new has ?-2?. Should ?-2? be symbolic instead?

Thanks,

Paul

On 11/22/17, 2:00 AM, "core-libs-dev on behalf of Se?n Coffey" <core-libs-dev-bounces at openjdk.java.net on behalf of sean.coffey at oracle.com> wrote:

    Looking to fix a recent regression that appeared in 8u151. Thanks goes 
    to Sherman for the src patch. Paul Hohensee has also helped by provided 
    some test code. I've been able to modify an existing test to mimic the 
    behaviour seen with FlushableGZIPOutputStream which is found in Tomcat 7.x.
    
    Sherman is working on a patch for JDK 10. For unix OSes, JDK 10 operates 
    with the zlib version found on the OS.
    
    bug : https://bugs.openjdk.java.net/browse/JDK-8189789
    webrev : http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/
    
    regards,
    Sean.
    
    


From forax at univ-mlv.fr  Wed Nov 22 16:45:15 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 22 Nov 2017 17:45:15 +0100 (CET)
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <CACzrW9DibVN=ajMJBSQhZzNdZDWM1LPsXPH6M=ryt28kgZS3ag@mail.gmail.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <E3598621-C8A0-4ECA-9EFB-8D8F6381AF18@oracle.com>
 <CACzrW9DibVN=ajMJBSQhZzNdZDWM1LPsXPH6M=ryt28kgZS3ag@mail.gmail.com>
Message-ID: <31772934.1447977.1511369115414.JavaMail.zimbra@u-pem.fr>

I think i prefer toImmutableList() than toUnmodifiableList() because the List is truly immutable and not an unmodifiable proxy in front of a mutable List (like Collections.unmodifiableList() does).

R?mi

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mercredi 22 Novembre 2017 16:42:56
> Objet: Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

> On 19 November 2017 at 03:34, John Rose <john.r.rose at oracle.com> wrote:
>> Meanwhile, `toUnmodifiableList` is so ugly to the ear,
>> eye, and fingers that it will be less used just because of
>> its long spelling.
> 
> Many developers are already using Google Guava which has added
> toImmutableList() and friends. More widely, we use the toXxx() form
> for all the collectors we've written (in OpenGamma Strata). As such, I
> think the toXxx() naming is well established at this point, and
> toUnmodifiableList() will be fine.
> 
> Stephen

From naoto.sato at oracle.com  Wed Nov 22 17:18:27 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 22 Nov 2017 09:18:27 -0800
Subject: <i18n dev> [10] RFR 8191404: Upgrading JDK with latest available
 LSR data from IANA.
In-Reply-To: <194793aa-d9b3-2d1d-5772-62b05cad7ff8@oracle.com>
References: <38d7fa00-252f-cd42-500a-deda1fef843f@oracle.com>
 <a528efb8-12d2-8a3c-e802-64e3d7355042@oracle.com>
 <194793aa-d9b3-2d1d-5772-62b05cad7ff8@oracle.com>
Message-ID: <1e987494-0ecd-8446-3cef-48b0aa5920dc@oracle.com>

Looks good. As long as sampling the test data is meaningful, I think 
it's OK.

Naoto

On 11/22/17 12:13 AM, Nishit Jain wrote:
> Thanks Naoto,
> 
>  > One nit in the test. At line 71, probably the original intention of 
> "str" is to list the accept languages in alphabetic order. Would you 
> change it?
> Yes, it is sorted according to weight then alphabetically. Updated the 
> test case.
> 
> http://cr.openjdk.java.net/~nishjain/8191404/webrev.01/
> 
>  > I have not looked into actual tags in the test. Did you modify them 
> manually? If so, it would be desirable to make it automated.
> Yes, currently the updated tags are added in the test case manually. 
> Making it automated is in the target list, will file/take it as a 
> separate issue.
> I would like to bring one point to notice that, I have not added all the 
> new tags (which are added in this version) in the test case, just few of 
> them are added to test that LocaleEquivalentMaps are properly updated. 
> Hope that is fine.
> 
> Regards,
> Nishit Jain
> On 22-11-2017 04:47, Naoto Sato wrote:
>> Hi Nishit,
>>
>> One nit in the test. At line 71, probably the original intention of 
>> "str" is to list the accept languages in alphabetic order. Would you 
>> change it?
>>
>> I have not looked into actual tags in the test. Did? you modify them 
>> manually? If so, it would be desirable to make it automated.
>>
>> Naoto
>>
>> On 11/16/17 3:47 AM, Nishit Jain wrote:
>>> Hi,
>>>
>>> Please review the fix for JDK-8191404
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191404
>>> Webrev: http://cr.openjdk.java.net/~nishjain/8191404/webrev.00/
>>>
>>> Fix: Updated the LSR data with the version: 2017-08-15
>>>
>>> Regards,
>>> Nishit Jain
> 

From goetz.lindenmaier at sap.com  Wed Nov 22 17:28:09 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 22 Nov 2017 17:28:09 +0000
Subject: 8189102: All tools should support -?, -h and --help
In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
Message-ID: <2ab914b725d54100bb5c99c1537da1df@sap.com>

Hi,

I prepared a new webrev trying to incorporate all change requests:
 * I removed changes to non-english property files.
 * I removed help texts from ktab, kinit, klist
 * I removed changes to corba tools
 * I added test cases for new flags to tool specific tests (to the ones I spotted)
 * I added -help back to javac
I left the removal of -help from Javadoc, as Javadoc just prints the help message
anyways. 

New webrev:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/index.html

I uploaded the parts of the patch I removed within the webrev:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/help_in_property_files.patch
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/KinitKtabKlist_help_message.patch
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/corba_help_message.patch

Best regards,
  Goetz.


> -----Original Message-----
> From: serviceability-dev [mailto:serviceability-dev-
> bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
> Sent: Friday, November 17, 2017 12:23 PM
> To: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net'
> <compiler-dev at openjdk.java.net>; serviceability-dev (serviceability-
> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> Subject: RFR: 8189102: All tools should support -?, -h and --help
> 
> Hi,
> 
> please review this change. I also filed a CSR for this:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> 
> See the webrev for a detailed description of the changes.
> 
> If required, I'll make break-out changes to be reviewed separately.
> 
> I had posted a RFR before, but improved the change to
> give a more complete overview of currently supported flags
> for the CSR:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> 
> Best regards,
>   Goetz.


From sean.coffey at oracle.com  Wed Nov 22 17:42:19 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 22 Nov 2017 17:42:19 +0000
Subject: 8189789: tomcat gzip-compressed response bodies appear to be
 broken in update 151
In-Reply-To: <330832F9-E047-41B9-82BD-44BD75EA9CCA@amazon.com>
References: <d9854879-115b-ddd6-a3f1-cfba04bca9ea@oracle.com>
 <330832F9-E047-41B9-82BD-44BD75EA9CCA@amazon.com>
Message-ID: <dcabc1c2-0170-43e7-788b-1f7d7fefeff4@oracle.com>


On 22/11/2017 15:46, Hohensee, Paul wrote:
> If the fix is from the zlib project, then ignore the following, since it?s their code.
>
> In Deflater.c: the existing significant code duplication between the arms of the if-else gives one pause. E.g., in the new file, compare lines 148/183 and 155/190. Might be bugs lurking at 183 and 190.
There might be some room for optimizing alright. The different length 
variables are measuring the available input and output length values. 
Different action is taken if we encounter exceptions when setting up 
memory for related operations. Maybe we can bring more consistent length 
checks to both blocks. I'd have to check why we check for native 
exception handling in one block and not the other.
>
> In deflate.c: the old code had ?s->last_flush = Z_NO_FLUSH?, the new has ?-2?. Should ?-2? be symbolic instead?
Sherman is following the code from the main zlib repo for that change [1]

regards,
Sean.

[1] https://github.com/madler/zlib/issues/275
>
> Thanks,
>
> Paul
>
> On 11/22/17, 2:00 AM, "core-libs-dev on behalf of Se?n Coffey" <core-libs-dev-bounces at openjdk.java.net on behalf of sean.coffey at oracle.com> wrote:
>
>      Looking to fix a recent regression that appeared in 8u151. Thanks goes
>      to Sherman for the src patch. Paul Hohensee has also helped by provided
>      some test code. I've been able to modify an existing test to mimic the
>      behaviour seen with FlushableGZIPOutputStream which is found in Tomcat 7.x.
>      
>      Sherman is working on a patch for JDK 10. For unix OSes, JDK 10 operates
>      with the zlib version found on the OS.
>      
>      bug : https://bugs.openjdk.java.net/browse/JDK-8189789
>      webrev : http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/
>      
>      regards,
>      Sean.
>      
>      
>


From patrick at reini.net  Wed Nov 22 18:36:32 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 22 Nov 2017 19:36:32 +0100
Subject: JDK-8191706: Proposal to add Reader::transferTo(Writer)
In-Reply-To: <ae4d9788-49d0-49fc-f406-f10cc486d147@oracle.com>
References: <0d53fe18-9443-201d-c4bd-7f9c973b0602@reini.net>
 <ae4d9788-49d0-49fc-f406-f10cc486d147@oracle.com>
Message-ID: <c338dcb4-6a15-45c4-6610-22e1c9892cce@reini.net>

Webrev and CSR updated accordingly...

-Patrick

Am 22.11.2017 um 09:23 schrieb Alan Bateman:
>
>
> On 21/11/2017 19:56, Patrick Reinhart wrote:
>> Hi there out a the review [1] for? JDK-8066870, that will need some more
>> working on, I created this specific issue to add an transferTo method to
>> the java.io.Reader as it seems more clear as of the similarity to
>> java.io.InputStream.transferTo(java.io.OutputStream) in terms of the
>> API.
>>
> The updated proposal looks good. One minor nit on the javadoc is that
> it says "end of the data". The existing read methods use "end of the
> stream" so best to keep that consistent.
>
> -Alan.




From naoto.sato at oracle.com  Wed Nov 22 19:04:39 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 22 Nov 2017 11:04:39 -0800
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
Message-ID: <03d177e8-ae43-6692-80f5-34dcc402ae51@oracle.com>

I revised the proposed changes, including java.time changes suggested by 
Stephen (CSR is still in progress):

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

The entire webrev is located at:

http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.05/

And the diff webrev from the last one is located at:

http://cr.openjdk.java.net/~naoto/8191349/webrev.04-05/

I'd appreciate your reviews.

Naoto


On 11/9/17 3:34 PM, Naoto Sato wrote:
> Kindly requesting reviews. I incorporated a fix to the following issue 
> raised by the test team:
> 
> https://bugs.openjdk.java.net/browse/JDK-8190918
> 
> Here is the updated webrev:
> 
> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/
> 
> And the webrev since the one below (to address 8190918):
> 
> http://cr.openjdk.java.net/~naoto/8190918/
> 
> Naoto
> 
> 
> 
> On 11/2/17 2:42 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the proposed changes for the following issues:
>>
>> 8176841: Additional Unicode Language-Tag Extensions
>> 8189134: New system properties for the default Locale extensions
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
>>
>> This serves as the implementation of JEP 314.
>>
>> Naoto
>>
>>
>>

From scolebourne at joda.org  Thu Nov 23 16:13:00 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 23 Nov 2017 16:13:00 +0000
Subject: <i18n dev> [10] RFR 8176841: Additional Unicode Language-Tag
 Extensions
In-Reply-To: <03d177e8-ae43-6692-80f5-34dcc402ae51@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <03d177e8-ae43-6692-80f5-34dcc402ae51@oracle.com>
Message-ID: <CACzrW9A6GAWv=UUAsJ-xHivGp-RkjJvv2riXjYhyaoC-u4TeuQ@mail.gmail.com>

In DateTimeFormatter line 1508, this would be preferred:

  return  new DateTimeFormatter(printerParser, locale, ds,
resolverStyle, resolverFields, c, z);

In DateTimeFormatterBuilder.getLocalizedDateTimePattern() there is no
spec change wrt using "rg".

Should findRegionOverride() just return a Locale instead of am
Optional<Locale>? It always seems to have an orElse(locale).

Java-Time tests look good.

thanks
Stephen


On 22 November 2017 at 19:04, Naoto Sato <naoto.sato at oracle.com> wrote:
> I revised the proposed changes, including java.time changes suggested by
> Stephen (CSR is still in progress):
>
> https://bugs.openjdk.java.net/browse/JDK-8191349
>
> The entire webrev is located at:
>
> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.05/
>
> And the diff webrev from the last one is located at:
>
> http://cr.openjdk.java.net/~naoto/8191349/webrev.04-05/
>
> I'd appreciate your reviews.
>
> Naoto
>
>
>
> On 11/9/17 3:34 PM, Naoto Sato wrote:
>>
>> Kindly requesting reviews. I incorporated a fix to the following issue
>> raised by the test team:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8190918
>>
>> Here is the updated webrev:
>>
>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/
>>
>> And the webrev since the one below (to address 8190918):
>>
>> http://cr.openjdk.java.net/~naoto/8190918/
>>
>> Naoto
>>
>>
>>
>> On 11/2/17 2:42 PM, Naoto Sato wrote:
>>>
>>> Hello,
>>>
>>> Please review the proposed changes for the following issues:
>>>
>>> 8176841: Additional Unicode Language-Tag Extensions
>>> 8189134: New system properties for the default Locale extensions
>>>
>>> The proposed changeset is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
>>>
>>> This serves as the implementation of JEP 314.
>>>
>>> Naoto
>>>
>>>
>>>
>

From mandy.chung at oracle.com  Fri Nov 24 00:56:29 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 23 Nov 2017 16:56:29 -0800
Subject: RFR 8191173 : (cl) Clarify or remove "for delegation" in
 ClassLoader spec
In-Reply-To: <04a91618-7dba-17dd-8360-7f81369c3be1@oracle.com>
References: <04a91618-7dba-17dd-8360-7f81369c3be1@oracle.com>
Message-ID: <f8de07e6-db8d-38be-f872-6933fc462e61@oracle.com>



On 11/21/17 12:41 PM, Brent Christian wrote:
> Hi,
>
> Please review my change to this small bit of ClassLoader spec that can 
> be tidied up, as noticed by Martin.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8191173
> Webrev:
> http://cr.openjdk.java.net/~bchristi/8191173/webrev.00/
>
> In java.lang.ClassLoader these methods:
> ? getParent()
> ? getPlatformClassLoader()
> ? getSystemClassLoader()
> all state that the returned classloader is, "for delegation."
>
> For getParent() this makes sense to mention.? But it seems unnecessary 
> for the other two methods, which are static, and designed to always 
> return the indicated classloader.? The getSystemClassLoader() docs go 
> on to immediately mention that the system classloader is the default 
> delegation parent.

Looks good.

As Alan points out, the parent class loader is only used for delegation 
when that class loader follows the delegation model.? The getParent 
method as well as the constructors could be made clear but I would leave 
it as is.

Mandy

From mandy.chung at oracle.com  Fri Nov 24 01:33:01 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 23 Nov 2017 17:33:01 -0800
Subject: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only
 the permissions it really needs to expose the bean
In-Reply-To: <bec7f66f-d801-7c52-0eae-8b371b265f4d@oracle.com>
References: <2138013.zvGs44vPXg@pracovni>
 <715d933a-a747-8aac-620b-fba12f4236e0@oracle.com>
 <7b03728a-a3ad-e392-db1b-dd0807e1ffeb@oracle.com>
 <1750350.QVl7KHXjYn@pracovni>
 <bec7f66f-d801-7c52-0eae-8b371b265f4d@oracle.com>
Message-ID: <8dbd6b66-f87f-fa7d-0f83-de094d98d312@oracle.com>

I'm okay with this fix.

Mandy

On 11/21/17 3:26 PM, Vladimir Kozlov wrote:
> Do we have consensus about changes? I can sponsor and push it.
>
> These changes passed Hotspot pre-integration testing and additional 
> requested tests.
>
> Thanks,
> Vladimir
>
> On 11/15/17 5:44 AM, Jaroslav Tulach wrote:
>> On ?ter? 14. listopadu 2017 21:34:45 CET mandy chung wrote:
>>> I am wondering this ACE comes from Graal accessing jdk.vm.ci.services
>>> from JVMCI which is defined to the boot loader versus Graal is defined
>>> to the platform class loader.
>>>
>>> ?? java.security.AccessControlException: access denied
>>> ("java.lang.RuntimePermission" 
>>> "accessClassInPackage.jdk.vm.ci.services")
>>>
>>> However Graal grants with AllPermissions.
>>>
>>> In any case, if this is an existing issue, I am okay if you file a
>>> separate issue to track this.
>>
>> Hello Mandy,
>> yes, it looks like issue unrelated to my changes. I have reported: 
>> https://
>> bugs.openjdk.java.net/browse/JDK-8191320
>>
>> I hope I haven't messed up something on my disk and others will be 
>> able to
>> reproduce my problem.
>> -jt
>>
>>
>>>
>>> Mandy
>>>
>>> On 11/14/17 2:02 PM, Sean Mullan wrote:
>>>> Try running with -Djava.security.debug=access:domain:failure
>>>>
>>>> This will tell you what ProtectionDomain caused the
>>>> AccessControlException, which should give you a better idea of where
>>>> the problem is. Look for messages that start with "domain that 
>>>> failed ".
>>>>
>>>> --Sean
>>>>
>>>> On 11/14/17 1:22 AM, Jaroslav Tulach wrote:
>>>>> I tried the same test with
>>>>>
>>>>> changeset:?? 47679:d85284ccd1bd
>>>>> user:??????? sspitsyn
>>>>> date:??????? Fri Nov 03 17:09:25 2017 -0700
>>>>> summary:???? 8189731: Disable CFLH when there are no transformers
>>>>>
>>>>> and it also yields the exception. E.g. the problem is certainly not
>>>>> result of
>>>>> my changes.
>>>>>
>>>>> -jt
>>>>>
>>>>> PS: I try full rebuild on d85284ccd1bd maybe it disappears...
>>>>>
>>>>> On pond?l? 13. listopadu 2017 20:53:35 CET Jaroslav Tulach wrote:
>>>>>> Hello Mandy,
>>>>>>
>>>>>> this was a good test:
>>>>>>>> ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions 
>>>>>>>> -XX:
>>>>>>>> +EnableJVMCI -XX:+UseJVMCICompiler -jar ...
>>>>>>>
>>>>>>> You can also try running the above command with
>>>>>>> -Djava.security.manager
>>>>>>> as a sanity test (the application may need additional 
>>>>>>> permissions) -
>>>>>>> just a sanity test.
>>>>>>
>>>>>> I've just tried:
>>>>>>
>>>>>> $ ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions 
>>>>>> -XX:
>>>>>> +EnableJVMCI -XX:+UseJVMCICompiler -Djava.security.manager -jar ~/
>>>>>> NetBeansProjects/sieve/java/algorithm/target/sieve-algorithm-1.0-SNAPSHO 
>>>>>>
>>>>>> T.ja
>>>>>>
>>>>>> r
>>>>>>
>>>>>> and it doesn't work. I am getting an error below, however the code
>>>>>> is not
>>>>>> running through my module at all. I don't understand the failure, I
>>>>>> will
>>>>>> have to investigate more.
>>>>>>
>>>>>> -jt
>>>>>>
>>>>>>
>>>>>> Caused by: java.security.AccessControlException: access denied
>>>>>> ("java.lang.RuntimePermission"
>>>>>> "accessClassInPackage.jdk.vm.ci.services")
>>>>>> ????????? at java.base/
>>>>>> java.security.AccessControlContext.checkPermission(AccessControlContext. 
>>>>>>
>>>>>> java>>>
>>>>>> : 472)
>>>>>>
>>>>>> ????????? at java.base/
>>>>>> java.security.AccessController.checkPermission(AccessController.java:895 
>>>>>>
>>>>>> )
>>>>>>
>>>>>> ????????? at java.base/
>>>>>> java.lang.SecurityManager.checkPermission(SecurityManager.java:558)
>>>>>> ????????? at java.base/
>>>>>> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1534) 
>>>>>>
>>>>>> ????????? at 
>>>>>> java.base/java.lang.ClassLoader$1.run(ClassLoader.java:680)
>>>>>> ????????? at 
>>>>>> java.base/java.lang.ClassLoader$1.run(ClassLoader.java:678)
>>>>>> ????????? at
>>>>>> java.base/java.security.AccessController.doPrivileged(Native
>>>>>> Method)
>>>>>> ????????? at java.base/
>>>>>> java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:678)
>>>>>> ????????? at java.base/java.lang.ClassLoader.defineClass1(Native 
>>>>>> Method)
>>>>>> ????????? at
>>>>>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1006) 
>>>>>> at
>>>>>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1085) 
>>>>>> at
>>>>>> java.base/
>>>>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:206) 
>>>>>>
>>>>>> ????????? at java.base/
>>>>>> jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.ja 
>>>>>>
>>>>>> va:7
>>>>>>
>>>>>> 60) at java.base/jdk.internal.loader.BuiltinClassLoader.lambda
>>>>>> $findClassInModuleOrNull$2(BuiltinClassLoader.java:683)
>>>>>> ????????? at
>>>>>> java.base/java.security.AccessController.doPrivileged(Native
>>>>>> Method)
>>>>>> ????????? at java.base/
>>>>>> jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinCl 
>>>>>>
>>>>>> assL
>>>>>>
>>>>>> oader.java: 684)
>>>>>> ????????? at java.base/
>>>>>> jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java 
>>>>>>
>>>>>> :562
>>>>>>
>>>>>> ) at 
>>>>>> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:607) at
>>>>>> java.base/java.lang.Class.forName(Class.java:451)
>>>>>> ????????? at java.base/java.util.ServiceLoader.lambda$loadProvider
>>>>>> $1(ServiceLoader.java:856)
>>>>>> ????????? at
>>>>>> java.base/java.security.AccessController.doPrivileged(Native
>>>>>> Method)
>>>>>> ????????? at
>>>>>> java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java: 
>>>>>> 858)
>>
>>


From jaroslav.tulach at oracle.com  Fri Nov 24 03:40:39 2017
From: jaroslav.tulach at oracle.com (Jaroslav Tulach)
Date: Fri, 24 Nov 2017 04:40:39 +0100
Subject: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only
 the permissions it really needs to expose the bean
In-Reply-To: <8dbd6b66-f87f-fa7d-0f83-de094d98d312@oracle.com>
References: <2138013.zvGs44vPXg@pracovni>
 <715d933a-a747-8aac-620b-fba12f4236e0@oracle.com>
 <7b03728a-a3ad-e392-db1b-dd0807e1ffeb@oracle.com>
 <1750350.QVl7KHXjYn@pracovni>
 <bec7f66f-d801-7c52-0eae-8b371b265f4d@oracle.com>
 <8dbd6b66-f87f-fa7d-0f83-de094d98d312@oracle.com>
Message-ID: <7CC15F2A-53F3-4E7C-87A5-6BE8061D72F6@oracle.com>

24. 11. 2017 v 2:33, mandy chung <mandy.chung at oracle.com>:

> I'm okay with this fix.

Just for the record: I am also fine with integrating my change.
-jt

> 
>> On 11/21/17 3:26 PM, Vladimir Kozlov wrote:
>> Do we have consensus about changes? I can sponsor and push it. 
>> 
>> These changes passed Hotspot pre-integration testing and additional requested tests. 
>> 
>> Thanks, 
>> Vladimir 
>> 
>>> On 11/15/17 5:44 AM, Jaroslav Tulach wrote: 
>>>> On ?ter? 14. listopadu 2017 21:34:45 CET mandy chung wrote: 
>>>> I am wondering this ACE comes from Graal accessing jdk.vm.ci.services 
>>>> from JVMCI which is defined to the boot loader versus Graal is defined 
>>>> to the platform class loader. 
>>>> 
>>>>    java.security.AccessControlException: access denied 
>>>> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.vm.ci.services") 
>>>> 
>>>> However Graal grants with AllPermissions. 
>>>> 
>>>> In any case, if this is an existing issue, I am okay if you file a 
>>>> separate issue to track this. 
>>> 
>>> Hello Mandy, 
>>> yes, it looks like issue unrelated to my changes. I have reported: https:// 
>>> bugs.openjdk.java.net/browse/JDK-8191320 
>>> 
>>> I hope I haven't messed up something on my disk and others will be able to 
>>> reproduce my problem. 
>>> -jt 
>>> 
>>> 
>>>> 
>>>> Mandy 
>>>> 
>>>>> On 11/14/17 2:02 PM, Sean Mullan wrote: 
>>>>> Try running with -Djava.security.debug=access:domain:failure 
>>>>> 
>>>>> This will tell you what ProtectionDomain caused the 
>>>>> AccessControlException, which should give you a better idea of where 
>>>>> the problem is. Look for messages that start with "domain that failed ". 
>>>>> 
>>>>> --Sean 
>>>>> 
>>>>>> On 11/14/17 1:22 AM, Jaroslav Tulach wrote: 
>>>>>> I tried the same test with 
>>>>>> 
>>>>>> changeset:   47679:d85284ccd1bd 
>>>>>> user:        sspitsyn 
>>>>>> date:        Fri Nov 03 17:09:25 2017 -0700 
>>>>>> summary:     8189731: Disable CFLH when there are no transformers 
>>>>>> 
>>>>>> and it also yields the exception. E.g. the problem is certainly not 
>>>>>> result of 
>>>>>> my changes. 
>>>>>> 
>>>>>> -jt 
>>>>>> 
>>>>>> PS: I try full rebuild on d85284ccd1bd maybe it disappears... 
>>>>>> 
>>>>>>> On pond?l? 13. listopadu 2017 20:53:35 CET Jaroslav Tulach wrote: 
>>>>>>> Hello Mandy, 
>>>>>>> 
>>>>>>> this was a good test: 
>>>>>>>>> ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX: 
>>>>>>>>> +EnableJVMCI -XX:+UseJVMCICompiler -jar ... 
>>>>>>>> 
>>>>>>>> You can also try running the above command with 
>>>>>>>> -Djava.security.manager 
>>>>>>>> as a sanity test (the application may need additional permissions) - 
>>>>>>>> just a sanity test. 
>>>>>>> 
>>>>>>> I've just tried: 
>>>>>>> 
>>>>>>> $ ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX: 
>>>>>>> +EnableJVMCI -XX:+UseJVMCICompiler -Djava.security.manager -jar ~/ 
>>>>>>> NetBeansProjects/sieve/java/algorithm/target/sieve-algorithm-1.0-SNAPSHO 
>>>>>>> T.ja 
>>>>>>> 
>>>>>>> r 
>>>>>>> 
>>>>>>> and it doesn't work. I am getting an error below, however the code 
>>>>>>> is not 
>>>>>>> running through my module at all. I don't understand the failure, I 
>>>>>>> will 
>>>>>>> have to investigate more. 
>>>>>>> 
>>>>>>> -jt 
>>>>>>> 
>>>>>>> 
>>>>>>> Caused by: java.security.AccessControlException: access denied 
>>>>>>> ("java.lang.RuntimePermission" 
>>>>>>> "accessClassInPackage.jdk.vm.ci.services") 
>>>>>>>           at java.base/ 
>>>>>>> java.security.AccessControlContext.checkPermission(AccessControlContext. 
>>>>>>> java>>> 
>>>>>>> : 472) 
>>>>>>> 
>>>>>>>           at java.base/ 
>>>>>>> java.security.AccessController.checkPermission(AccessController.java:895 
>>>>>>> ) 
>>>>>>> 
>>>>>>>           at java.base/ 
>>>>>>> java.lang.SecurityManager.checkPermission(SecurityManager.java:558) 
>>>>>>>           at java.base/ 
>>>>>>> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1534) 
>>>>>>>           at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:680) 
>>>>>>>           at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:678) 
>>>>>>>           at 
>>>>>>> java.base/java.security.AccessController.doPrivileged(Native 
>>>>>>> Method) 
>>>>>>>           at java.base/ 
>>>>>>> java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:678) 
>>>>>>>           at java.base/java.lang.ClassLoader.defineClass1(Native Method) 
>>>>>>>           at 
>>>>>>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1006) at 
>>>>>>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1085) at 
>>>>>>> java.base/ 
>>>>>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:206) 
>>>>>>>           at java.base/ 
>>>>>>> jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.ja 
>>>>>>> va:7 
>>>>>>> 
>>>>>>> 60) at java.base/jdk.internal.loader.BuiltinClassLoader.lambda 
>>>>>>> $findClassInModuleOrNull$2(BuiltinClassLoader.java:683) 
>>>>>>>           at 
>>>>>>> java.base/java.security.AccessController.doPrivileged(Native 
>>>>>>> Method) 
>>>>>>>           at java.base/ 
>>>>>>> jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinCl 
>>>>>>> assL 
>>>>>>> 
>>>>>>> oader.java: 684) 
>>>>>>>           at java.base/ 
>>>>>>> jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java 
>>>>>>> :562 
>>>>>>> 
>>>>>>> ) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:607) at 
>>>>>>> java.base/java.lang.Class.forName(Class.java:451) 
>>>>>>>           at java.base/java.util.ServiceLoader.lambda$loadProvider 
>>>>>>> $1(ServiceLoader.java:856) 
>>>>>>>           at 
>>>>>>> java.base/java.security.AccessController.doPrivileged(Native 
>>>>>>> Method) 
>>>>>>>           at 
>>>>>>> java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java: 858) 
>>> 
>>> 
> 

From goetz.lindenmaier at sap.com  Fri Nov 24 08:46:48 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 24 Nov 2017 08:46:48 +0000
Subject: Which test groups to run instead of :jdk (8176838)
Message-ID: <b61c05248fec4dc198e3dbfdece3d16c@sap.com>

Hi,

we used to run test target :jdk.
This has been removed in 8176838.

Which target should we run now to get the same or similar set of tests?

Best regards,
  Goetz.

From volker.simonis at gmail.com  Fri Nov 24 09:38:24 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 24 Nov 2017 10:38:24 +0100
Subject: Which test groups to run instead of :jdk (8176838)
In-Reply-To: <b61c05248fec4dc198e3dbfdece3d16c@sap.com>
References: <b61c05248fec4dc198e3dbfdece3d16c@sap.com>
Message-ID: <CA+3eh12JEh4Bjm_mBAyiLZN21MbbFTt0wxJJ-VC52WgKx9H_wA@mail.gmail.com>

http://download.java.net/openjdk/testresults/10/docs/howtoruntests.html
documents that Oracle seems to use :jdk_stable for running the jdk
JTreg tests.

Regards,
Volker


On Fri, Nov 24, 2017 at 9:46 AM, Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
> Hi,
>
> we used to run test target :jdk.
> This has been removed in 8176838.
>
> Which target should we run now to get the same or similar set of tests?
>
> Best regards,
>   Goetz.

From goetz.lindenmaier at sap.com  Fri Nov 24 10:02:07 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 24 Nov 2017 10:02:07 +0000
Subject: Which test groups to run instead of :jdk (8176838)
In-Reply-To: <CA+3eh12JEh4Bjm_mBAyiLZN21MbbFTt0wxJJ-VC52WgKx9H_wA@mail.gmail.com>
References: <b61c05248fec4dc198e3dbfdece3d16c@sap.com>
 <CA+3eh12JEh4Bjm_mBAyiLZN21MbbFTt0wxJJ-VC52WgKx9H_wA@mail.gmail.com>
Message-ID: <120d2c88de0944cbb3759b52d24769ee@sap.com>

HI Volker, 

this might be what Oracle is running, but it is not the same as 
the target jdk.

E.g., jdk used to include jdk_awt, which is not included by jdk_stable.

Also, that page is outdated, it talks about tests in jdk/test etc, 
while these directories don't exist any more.

Best regards,
  Goez.



> -----Original Message-----
> From: Volker Simonis [mailto:volker.simonis at gmail.com]
> Sent: Freitag, 24. November 2017 10:38
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: alexandre.iline at oracle.com; core-libs-dev at openjdk.java.net
> Subject: Re: Which test groups to run instead of :jdk (8176838)
> 
> http://download.java.net/openjdk/testresults/10/docs/howtoruntests.html
> documents that Oracle seems to use :jdk_stable for running the jdk
> JTreg tests.
> 
> Regards,
> Volker
> 
> 
> On Fri, Nov 24, 2017 at 9:46 AM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> > Hi,
> >
> > we used to run test target :jdk.
> > This has been removed in 8176838.
> >
> > Which target should we run now to get the same or similar set of tests?
> >
> > Best regards,
> >   Goetz.

From rahul.v.raghavan at oracle.com  Fri Nov 24 11:16:23 2017
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Fri, 24 Nov 2017 16:46:23 +0530
Subject: [10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in tier1
Message-ID: <e11bf848-ce2c-0ef9-6649-756f0cbb2f62@oracle.com>

Hi,

Please review the following fix proposal for 8191813.

webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/


jbs - https://bugs.openjdk.java.net/browse/JDK-8191813

-- reported issue - After the latest sync from jdk/jdk the test 
SpreadNullArg started to fail in tier1 on all platforms.

-- Found this SpreadNullArg.java failure Caused after JDK-8157246 fix.
jbs - https://bugs.openjdk.java.net/browse/JDK-8157246.
'MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to 
specify invocation-time behavior'.
changeset - http://hg.openjdk.java.net/jdk/jdk/rev/76519338df34

- So now with 8157246 fix, if method handle is invoked with a null array 
reference, NullPointerException will be thrown. (Not 
IllegalArgumentException)

- So above fix proposal in SpreadNullArg.java to expect 
NullPointerException after 8157246 changes.


Thanks,
Rahul

From per.liden at oracle.com  Fri Nov 24 13:13:47 2017
From: per.liden at oracle.com (Per Liden)
Date: Fri, 24 Nov 2017 14:13:47 +0100
Subject: RFR(s): 8191859: SoftReference clock/timestamp should be declared
 volatile
Message-ID: <22953aa6-6eb0-f2a5-82ac-f6f700d4f5e5@oracle.com>

The clock and timestamp fields in SoftReference should be declared 
volatile. These fields are read or updated by the VM, (possibly) 
concurrently with the execution of Java threads.

To be more specific, the timestamp field is read by the GC during 
reference discovery, e.g. during G1/CMS concurrent mark. The clock is 
updated by the GC, typically after reference processing has completed.

Webrev: http://cr.openjdk.java.net/~pliden/8191859/webrev.0/
Bug: https://bugs.openjdk.java.net/browse/JDK-8191859

/Per

From volker.simonis at gmail.com  Fri Nov 24 14:31:48 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 24 Nov 2017 15:31:48 +0100
Subject: Which test groups to run instead of :jdk (8176838)
In-Reply-To: <120d2c88de0944cbb3759b52d24769ee@sap.com>
References: <b61c05248fec4dc198e3dbfdece3d16c@sap.com>
 <CA+3eh12JEh4Bjm_mBAyiLZN21MbbFTt0wxJJ-VC52WgKx9H_wA@mail.gmail.com>
 <120d2c88de0944cbb3759b52d24769ee@sap.com>
Message-ID: <CA+3eh122Nr2YpCsrgneVPvg9-kGabH-YiuPNUygZvhqQ+GZ_TA@mail.gmail.com>

On Fri, Nov 24, 2017 at 11:02 AM, Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
> HI Volker,
>
> this might be what Oracle is running, but it is not the same as
> the target jdk.
>
> E.g., jdk used to include jdk_awt, which is not included by jdk_stable.
>
> Also, that page is outdated, it talks about tests in jdk/test etc,
> while these directories don't exist any more.
>

I know and I've already reported it. Rory promised to fix it soon :)

> Best regards,
>   Goez.
>
>
>
>> -----Original Message-----
>> From: Volker Simonis [mailto:volker.simonis at gmail.com]
>> Sent: Freitag, 24. November 2017 10:38
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Cc: alexandre.iline at oracle.com; core-libs-dev at openjdk.java.net
>> Subject: Re: Which test groups to run instead of :jdk (8176838)
>>
>> http://download.java.net/openjdk/testresults/10/docs/howtoruntests.html
>> documents that Oracle seems to use :jdk_stable for running the jdk
>> JTreg tests.
>>
>> Regards,
>> Volker
>>
>>
>> On Fri, Nov 24, 2017 at 9:46 AM, Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com> wrote:
>> > Hi,
>> >
>> > we used to run test target :jdk.
>> > This has been removed in 8176838.
>> >
>> > Which target should we run now to get the same or similar set of tests?
>> >
>> > Best regards,
>> >   Goetz.

From schaef at amazon.com  Fri Nov 24 14:53:02 2017
From: schaef at amazon.com (Schaef, Martin)
Date: Fri, 24 Nov 2017 14:53:02 +0000
Subject: Fix inconsistent behavior of
 java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
In-Reply-To: <B0D097BB-76CA-4213-A2AB-C11E4028A710@amazon.com>
References: <B0D097BB-76CA-4213-A2AB-C11E4028A710@amazon.com>
Message-ID: <2327919D-564F-41C6-9354-641BEEC32D3C@amazon.com>

We are experiencing a problem with the following test case:
https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java#L364

Depending on which gcc version we use to compile OpenJDK, the assertion in https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java#L397 fails.
That is, the methods java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
and java.io.File.lastModified() return results with a different precision.

We root-caused it to the following code block in UnixNativeDispatcher.c:
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/07011844584f/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c#l456

The test case at the bottom of this email can be used to reproduce the behavior. When using a JDK compiled with gcc 4.1.2, the test prints:
nio 1511387180000
io 1511387180000
But when using a JDK compiled with gcc 4.4.6, the code returns:
nio 1511387187817
io 1511387187000
Exception in thread "main" java.lang.RuntimeException: 1511387187817 != 1511387187000
                at Issue225.testLastModified(Issue225.java:33)
                at Issue225.main(Issue225.java:11)

In comparison, the OracleJDK binaries as downloaded from the website behave like the gcc 4.1.2 compiled binaries. To avoid confusion, and to ensure that both methods behave the same, we propose to remove the block in UnixNativeDispatcher.c (see attached patch).

Cheers,
Martin

### Test code to witness the behavior difference ###

import java.io.File;
import java.io.IOException;
import java.nio.file.LinkOption;
import java.nio.file.Path;
import java.nio.file.attribute.BasicFileAttributeView;
import java.nio.file.attribute.BasicFileAttributes;

public class Issue225 {

  public static void main(String[] args) throws IOException {
    (new Issue225()).testLastModified();
  }

  public void testLastModified() throws IOException {
    File file = File.createTempFile("Test", ".txt");
    file.deleteOnExit();

    Path nioPath = file.toPath();
    BasicFileAttributes readAttributes = nioPath
        .getFileSystem().provider()
        .getFileAttributeView(nioPath,
            BasicFileAttributeView.class,
            LinkOption.NOFOLLOW_LINKS
        ).readAttributes();

    System.out.println(readAttributes.getClass());

    System.out.println("nio " + readAttributes.lastModifiedTime().toMillis());
    System.out.println("io " + file.lastModified() );
    if (readAttributes.lastModifiedTime().toMillis() != file.lastModified()) {
      throw new RuntimeException(readAttributes.lastModifiedTime().toMillis()
          + " != "
          + file.lastModified());
    }
  }
}




From daniel.daugherty at oracle.com  Fri Nov 24 15:26:08 2017
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 24 Nov 2017 10:26:08 -0500
Subject: [10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in
 tier1
In-Reply-To: <e11bf848-ce2c-0ef9-6649-756f0cbb2f62@oracle.com>
References: <e11bf848-ce2c-0ef9-6649-756f0cbb2f62@oracle.com>
Message-ID: <752a4e80-9141-6115-dee6-2bbd0ec99e92@oracle.com>

On 11/24/17 6:16 AM, Rahul Raghavan wrote:
> Hi,
>
> Please review the following fix proposal for 8191813.
>
> webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/

test/hotspot/jtreg/compiler/runtime/SpreadNullArg.java
 ??? No comments.

So this style of call:

 ??? mh_spreadInvoker.invokeExact(mh_spread_target, (Object[]) null);

was changed from throwing IllegalArgumentException due to the "null"
parameter to throwing NullPointerException. You've updated the test
cleanly to switch from one exception to the other.

Thumbs up! I believe this patch qualifies as trivial and does not
need to wait for 24 hours. I leave it up to you whether you wait
for a Compiler team member review also.

Dan


>
>
> jbs - https://bugs.openjdk.java.net/browse/JDK-8191813
>
> -- reported issue - After the latest sync from jdk/jdk the test 
> SpreadNullArg started to fail in tier1 on all platforms.
>
> -- Found this SpreadNullArg.java failure Caused after JDK-8157246 fix.
> jbs - https://bugs.openjdk.java.net/browse/JDK-8157246.
> 'MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to 
> specify invocation-time behavior'.
> changeset - http://hg.openjdk.java.net/jdk/jdk/rev/76519338df34
>
> - So now with 8157246 fix, if method handle is invoked with a null 
> array reference, NullPointerException will be thrown. (Not 
> IllegalArgumentException)
>
> - So above fix proposal in SpreadNullArg.java to expect 
> NullPointerException after 8157246 changes.
>
>
> Thanks,
> Rahul


From Alan.Bateman at oracle.com  Fri Nov 24 15:53:30 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 24 Nov 2017 15:53:30 +0000
Subject: Fix inconsistent behavior of
 java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
In-Reply-To: <2327919D-564F-41C6-9354-641BEEC32D3C@amazon.com>
References: <B0D097BB-76CA-4213-A2AB-C11E4028A710@amazon.com>
 <2327919D-564F-41C6-9354-641BEEC32D3C@amazon.com>
Message-ID: <41a78184-f609-bdf7-98f8-ae037bb07366@oracle.com>

On 24/11/2017 14:53, Schaef, Martin wrote:
> We are experiencing a problem with the following test case:
> https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java#L364
>
> Depending on which gcc version we use to compile OpenJDK, the assertion in https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java#L397 fails.
> That is, the methods java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
> and java.io.File.lastModified() return results with a different precision.
>
> We root-caused it to the following code block in UnixNativeDispatcher.c:
> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/07011844584f/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c#l456
>
> The test case at the bottom of this email can be used to reproduce the behavior. When using a JDK compiled with gcc 4.1.2, the test prints:
> nio 1511387180000
> io 1511387180000
> But when using a JDK compiled with gcc 4.4.6, the code returns:
> nio 1511387187817
> io 1511387187000
> Exception in thread "main" java.lang.RuntimeException: 1511387187817 != 1511387187000
>                  at Issue225.testLastModified(Issue225.java:33)
>                  at Issue225.main(Issue225.java:11)
>
> In comparison, the OracleJDK binaries as downloaded from the website behave like the gcc 4.1.2 compiled binaries. To avoid confusion, and to ensure that both methods behave the same, we propose to remove the block in UnixNativeDispatcher.c (see attached patch).
>
We should the higher precision time stamps when available, it's just 
awkward that it gets compiled or not depending on the header files.

It sounds like you are looking to drop this support (I can't quite tell 
as your patch was dropped by the mailing list). Instead it would be 
better to see if we can change File.lastLastModifiedTime to use the 
higher precision timestamp if possible. It will of course need to be 
converted to millis.

-Alan

From vyom.tewari at oracle.com  Fri Nov 24 16:02:09 2017
From: vyom.tewari at oracle.com (vyom tewari)
Date: Fri, 24 Nov 2017 21:32:09 +0530
Subject: Fix inconsistent behavior of
 java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
In-Reply-To: <2327919D-564F-41C6-9354-641BEEC32D3C@amazon.com>
References: <B0D097BB-76CA-4213-A2AB-C11E4028A710@amazon.com>
 <2327919D-564F-41C6-9354-641BEEC32D3C@amazon.com>
Message-ID: <adb7f375-e7bf-5fa8-61bf-9b03e218de8b@oracle.com>

Hi Martin,

which specific Operating system are you observing this issue ?. Mostly 
all modern OS's supports higher precision time stamp.

Thanks,

Vyom


On Friday 24 November 2017 08:23 PM, Schaef, Martin wrote:
> We are experiencing a problem with the following test case:
> https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java#L364
>
> Depending on which gcc version we use to compile OpenJDK, the assertion in https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java#L397 fails.
> That is, the methods java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
> and java.io.File.lastModified() return results with a different precision.
>
> We root-caused it to the following code block in UnixNativeDispatcher.c:
> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/07011844584f/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c#l456
>
> The test case at the bottom of this email can be used to reproduce the behavior. When using a JDK compiled with gcc 4.1.2, the test prints:
> nio 1511387180000
> io 1511387180000
> But when using a JDK compiled with gcc 4.4.6, the code returns:
> nio 1511387187817
> io 1511387187000
> Exception in thread "main" java.lang.RuntimeException: 1511387187817 != 1511387187000
>                  at Issue225.testLastModified(Issue225.java:33)
>                  at Issue225.main(Issue225.java:11)
>
> In comparison, the OracleJDK binaries as downloaded from the website behave like the gcc 4.1.2 compiled binaries. To avoid confusion, and to ensure that both methods behave the same, we propose to remove the block in UnixNativeDispatcher.c (see attached patch).
>
> Cheers,
> Martin
>
> ### Test code to witness the behavior difference ###
>
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.LinkOption;
> import java.nio.file.Path;
> import java.nio.file.attribute.BasicFileAttributeView;
> import java.nio.file.attribute.BasicFileAttributes;
>
> public class Issue225 {
>
>    public static void main(String[] args) throws IOException {
>      (new Issue225()).testLastModified();
>    }
>
>    public void testLastModified() throws IOException {
>      File file = File.createTempFile("Test", ".txt");
>      file.deleteOnExit();
>
>      Path nioPath = file.toPath();
>      BasicFileAttributes readAttributes = nioPath
>          .getFileSystem().provider()
>          .getFileAttributeView(nioPath,
>              BasicFileAttributeView.class,
>              LinkOption.NOFOLLOW_LINKS
>          ).readAttributes();
>
>      System.out.println(readAttributes.getClass());
>
>      System.out.println("nio " + readAttributes.lastModifiedTime().toMillis());
>      System.out.println("io " + file.lastModified() );
>      if (readAttributes.lastModifiedTime().toMillis() != file.lastModified()) {
>        throw new RuntimeException(readAttributes.lastModifiedTime().toMillis()
>            + " != "
>            + file.lastModified());
>      }
>    }
> }
>
>
>


From dmcmanam at gmail.com  Fri Nov 24 16:32:59 2017
From: dmcmanam at gmail.com (David McManamon)
Date: Fri, 24 Nov 2017 11:32:59 -0500
Subject: Replacement of dual-pivot quicksort in java.util.Arrays with new
 3-pivot quicksort?
Message-ID: <CAN-rbk2qGuhw8tbGq_mwn7a4S6c=pu9ccBhhrs1Q=qa+iT3e_w@mail.gmail.com>

Hi,

I found the 2009 discussion and work surrounding dual-pivot quicksort
fascinating.  At that time, 3-pivot quicksort was described as slower;
however, since then a new 3-pivot partition algorithm was published and if
you want the fastest sorting time for primitives then the results are again
very interesting.

For an array with 10 million elements number of swaps switching to
insertion sort at 47 and then not counting swaps:
~74 million 3-pivot quicksort
~74 million dual-pivot quicksort

Yet the 3-pivot is 10-15% faster - cache misses are fewer and so are
comparisons.

Unfortunately as we follow this path some of the original elegance of the
algorithm is lost so I pasted the partition algorithm below for reference.

If you need faster sorting of primitives then run the code:

https://github.com/dmcmanam/quicksort/blob/master/src/Quicksort.java

And just uncomment the Arrays.sort line to compare against the current
dual-pivot you are using.

--David





// Pointers a and b initially point to the first element of the array while
c
// and d initially point to the last element of the array.
int a = lo + 2;
int b = lo + 2;
int c = hi - 1;
int d = hi - 1;
while (b <= c) {
while (A[b] < q && b <= c) {
if (A[b] < p) {
swap(A, a, b);
a++;
}
b++;
}
while (A[c] > q && b <= c) {
if (A[c] > r) {
swap(A, c, d);
d--;
}
c--;
}
if (b <= c) {
if (A[b] > r) {
if (A[c] < p) {
swap(A, b, a); swap(A, a, c);
a++;
} else {
swap(A, b, c);
}
swap(A, c, d);
b++; c--; d--;
} else {
if (A[c] < p) {
swap(A, b, a); swap(A, a, c);
a++;
} else {
swap(A, b, c);
}
b++; c--;
}
}
}
// swap the pivots to their correct positions
a--; b--; c++; d++;
swap(A, lo + 1, a);
swap(A, a, b);
a--;
swap(A, lo, a);
swap(A, hi, d);

From thomas.schatzl at oracle.com  Fri Nov 24 17:11:00 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 24 Nov 2017 18:11:00 +0100
Subject: RFR(s): 8191859: SoftReference clock/timestamp should be
 declared volatile
In-Reply-To: <22953aa6-6eb0-f2a5-82ac-f6f700d4f5e5@oracle.com>
References: <22953aa6-6eb0-f2a5-82ac-f6f700d4f5e5@oracle.com>
Message-ID: <1511543460.2917.2.camel@oracle.com>

Hi,

On Fri, 2017-11-24 at 14:13 +0100, Per Liden wrote:
> The clock and timestamp fields in SoftReference should be declared 
> volatile. These fields are read or updated by the VM, (possibly) 
> concurrently with the execution of Java threads.
> 
> To be more specific, the timestamp field is read by the GC during 
> reference discovery, e.g. during G1/CMS concurrent mark. The clock
> is updated by the GC, typically after reference processing has
> completed.
> 
> Webrev: http://cr.openjdk.java.net/~pliden/8191859/webrev.0/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191859
> 

  looks good to me.

Thomas


From schaef at amazon.com  Fri Nov 24 17:29:32 2017
From: schaef at amazon.com (Schaef, Martin)
Date: Fri, 24 Nov 2017 17:29:32 +0000
Subject: Fix inconsistent behavior of
 java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
In-Reply-To: <41a78184-f609-bdf7-98f8-ae037bb07366@oracle.com>
References: <B0D097BB-76CA-4213-A2AB-C11E4028A710@amazon.com>
 <2327919D-564F-41C6-9354-641BEEC32D3C@amazon.com>
 <41a78184-f609-bdf7-98f8-ae037bb07366@oracle.com>
Message-ID: <6BA6AA5C-B16C-42B7-92FC-633138CC72D6@amazon.com>

There is a fix in Java 10 that increases the precision for File.lastModified (https://bugs.openjdk.java.net/browse/JDK-8177809 ). My issue is that the two methods (File.lastModified and BasicFileAttributes.lastModifiedTime) behave differently depending on the gcc version. And this is not addressed by the JDK 10 patch either.

Find my original patch below. It addresses the Java 8 issue but would work if JDK-8177809 is back-ported.

Cheers,
Martin

diff --new-file --unified --recursive --exclude='*.autotools' --exclude='*.cproject' --exclude='*.project' ./jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c /home/schaef/jgitevidence/8src/src/OpenJDK8Src/edit-src/jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
--- ./jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c	2017-10-20 20:28:26.000000000 +0000
+++ /home/schaef/jgitevidence/8src/src/OpenJDK8Src/edit-src/jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c	2017-11-15 22:04:25.103588607 +0000
@@ -453,11 +453,11 @@
     (*env)->SetLongField(env, attrs, attrs_st_birthtime_sec, (jlong)buf->st_birthtime);
 #endif
 
-#if (_POSIX_C_SOURCE >= 200809L) || defined(__solaris__)
-    (*env)->SetLongField(env, attrs, attrs_st_atime_nsec, (jlong)buf->st_atim.tv_nsec);
-    (*env)->SetLongField(env, attrs, attrs_st_mtime_nsec, (jlong)buf->st_mtim.tv_nsec);
-    (*env)->SetLongField(env, attrs, attrs_st_ctime_nsec, (jlong)buf->st_ctim.tv_nsec);
-#endif
+//if (_POSIX_C_SOURCE >= 200809L) || defined(__solaris__)
+    // (*env)->SetLongField(env, attrs, attrs_st_atime_nsec, (jlong)buf->st_atim.tv_nsec);
+    // (*env)->SetLongField(env, attrs, attrs_st_mtime_nsec, (jlong)buf->st_mtim.tv_nsec);
+    // (*env)->SetLongField(env, attrs, attrs_st_ctime_nsec, (jlong)buf->st_ctim.tv_nsec);
+//endif
 }
 
 JNIEXPORT void JNICALL





On 11/24/17, 10:54 AM, "Alan Bateman" <Alan.Bateman at oracle.com> wrote:

    On 24/11/2017 14:53, Schaef, Martin wrote:
    > We are experiencing a problem with the following test case:
    > https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java#L364
    >
    > Depending on which gcc version we use to compile OpenJDK, the assertion in https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java#L397 fails.
    > That is, the methods java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
    > and java.io.File.lastModified() return results with a different precision.
    >
    > We root-caused it to the following code block in UnixNativeDispatcher.c:
    > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/07011844584f/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c#l456
    >
    > The test case at the bottom of this email can be used to reproduce the behavior. When using a JDK compiled with gcc 4.1.2, the test prints:
    > nio 1511387180000
    > io 1511387180000
    > But when using a JDK compiled with gcc 4.4.6, the code returns:
    > nio 1511387187817
    > io 1511387187000
    > Exception in thread "main" java.lang.RuntimeException: 1511387187817 != 1511387187000
    >                  at Issue225.testLastModified(Issue225.java:33)
    >                  at Issue225.main(Issue225.java:11)
    >
    > In comparison, the OracleJDK binaries as downloaded from the website behave like the gcc 4.1.2 compiled binaries. To avoid confusion, and to ensure that both methods behave the same, we propose to remove the block in UnixNativeDispatcher.c (see attached patch).
    >
    We should the higher precision time stamps when available, it's just 
    awkward that it gets compiled or not depending on the header files.
    
    It sounds like you are looking to drop this support (I can't quite tell 
    as your patch was dropped by the mailing list). Instead it would be 
    better to see if we can change File.lastLastModifiedTime to use the 
    higher precision timestamp if possible. It will of course need to be 
    converted to millis.
    
    -Alan
    


From mandy.chung at oracle.com  Fri Nov 24 17:41:34 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 24 Nov 2017 09:41:34 -0800
Subject: [10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in
 tier1
In-Reply-To: <e11bf848-ce2c-0ef9-6649-756f0cbb2f62@oracle.com>
References: <e11bf848-ce2c-0ef9-6649-756f0cbb2f62@oracle.com>
Message-ID: <792dadfc-89d3-054c-d3f2-303a69346be6@oracle.com>

Looks good.? Thanks for fixing the test, Rahul.

Mandy

On 11/24/17 3:16 AM, Rahul Raghavan wrote:
> Hi,
>
> Please review the following fix proposal for 8191813.
>
> webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/
>
>
> jbs - https://bugs.openjdk.java.net/browse/JDK-8191813
>
> -- reported issue - After the latest sync from jdk/jdk the test 
> SpreadNullArg started to fail in tier1 on all platforms.
>
> -- Found this SpreadNullArg.java failure Caused after JDK-8157246 fix.
> jbs - https://bugs.openjdk.java.net/browse/JDK-8157246.
> 'MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to 
> specify invocation-time behavior'.
> changeset - http://hg.openjdk.java.net/jdk/jdk/rev/76519338df34
>
> - So now with 8157246 fix, if method handle is invoked with a null 
> array reference, NullPointerException will be thrown. (Not 
> IllegalArgumentException)
>
> - So above fix proposal in SpreadNullArg.java to expect 
> NullPointerException after 8157246 changes.
>
>
> Thanks,
> Rahul


From Alan.Bateman at oracle.com  Fri Nov 24 18:24:01 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 24 Nov 2017 18:24:01 +0000
Subject: Fix inconsistent behavior of
 java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
In-Reply-To: <6BA6AA5C-B16C-42B7-92FC-633138CC72D6@amazon.com>
References: <B0D097BB-76CA-4213-A2AB-C11E4028A710@amazon.com>
 <2327919D-564F-41C6-9354-641BEEC32D3C@amazon.com>
 <41a78184-f609-bdf7-98f8-ae037bb07366@oracle.com>
 <6BA6AA5C-B16C-42B7-92FC-633138CC72D6@amazon.com>
Message-ID: <0ea7f597-e92a-2499-2596-e06957808c83@oracle.com>

On 24/11/2017 17:29, Schaef, Martin wrote:
> There is a fix in Java 10 that increases the precision for File.lastModified (https://bugs.openjdk.java.net/browse/JDK-8177809 ). My issue is that the two methods (File.lastModified and BasicFileAttributes.lastModifiedTime) behave differently depending on the gcc version. And this is not addressed by the JDK 10 patch either.
>
> Find my original patch below. It addresses the Java 8 issue but would work if JDK-8177809 is back-ported.
>
Your patch removes the code for high precision timestamps from all 
platforms, I don't think we want that.

If you backport JDK-8177809 and build with any recent gcc then you 
should find that the results are consistent. If you really need to 
build? gcc 4.1.x (2006) then the changes for JDK-8177809 would require 
#ifdef so that they aren't compiled in.

I realize your interest is jdk8u but for the main line then we do need 
to re-examine the dusty #ifdef in UnixNativeDispatcher.c. I think Oracle 
builds of jDK 10 use gcc 4.9.2, I believe others are probably building 
with newer versions.

-Alan



From martinrb at google.com  Fri Nov 24 22:56:40 2017
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 24 Nov 2017 14:56:40 -0800
Subject: RFR(s): 8191859: SoftReference clock/timestamp should be declared
 volatile
In-Reply-To: <22953aa6-6eb0-f2a5-82ac-f6f700d4f5e5@oracle.com>
References: <22953aa6-6eb0-f2a5-82ac-f6f700d4f5e5@oracle.com>
Message-ID: <CA+kOe098mzPV8joRcRV=CNX53VBC4CAVEA6xfyPzUQsNxni0HA@mail.gmail.com>

These fields have been this way for a very long time, probably
intentionally non-volatile.
Is there an observable problem being solved here?
I see that out-of-thin-air longs are theoretically possible, but very rare
in practice on current platforms.
If all you're trying to do is to ensure atomicity and that the reads/writes
don't get optimized away by the jit, then consider using "opaque"
VarHandles instead.

I was surprised there was no bug subcomponent for java.lang.ref

On Fri, Nov 24, 2017 at 5:13 AM, Per Liden <per.liden at oracle.com> wrote:

> The clock and timestamp fields in SoftReference should be declared
> volatile. These fields are read or updated by the VM, (possibly)
> concurrently with the execution of Java threads.
>
> To be more specific, the timestamp field is read by the GC during
> reference discovery, e.g. during G1/CMS concurrent mark. The clock is
> updated by the GC, typically after reference processing has completed.
>
> Webrev: http://cr.openjdk.java.net/~pliden/8191859/webrev.0/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191859
>
> /Per
>

From peter.levart at gmail.com  Fri Nov 24 23:32:13 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 25 Nov 2017 00:32:13 +0100
Subject: RFR 8191216: SimpleTimeZone.clone() has a data race on cache fields
In-Reply-To: <72a7efe3-ac34-1534-3a9b-146c647e1292@linux.vnet.ibm.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>
 <84ca56e0-67c8-3fbb-d558-4ebe797d513c@oracle.com>
 <8894f619-3510-acfa-3987-f013ca3638f3@gmail.com>
 <b68da9c6-1ad4-6926-7c27-21680e3b73b0@gmail.com>
 <d74ffdce-793a-bfe9-7e5f-4964897c3553@linux.vnet.ibm.com>
 <bef944fa-2a15-6c83-6730-ff7e32aa063f@gmail.com>
 <72a7efe3-ac34-1534-3a9b-146c647e1292@linux.vnet.ibm.com>
Message-ID: <017c44ce-a3e2-a03d-d437-98e08655a6a1@gmail.com>

Hi,

@Venkat: Sorry for late response, but I had to try something 1st.

This is an official request for reviewing a patch for fixing a data race 
between cloning a SimpleTimeZone object and lazily initializing its 3 
cache fields which may produce a clone with inconsistent cache state. 
Here's Jira issue with details:

 ??? https://bugs.openjdk.java.net/browse/JDK-8191216

Venkat has proposed to simply call invalidateCache() on the clone before 
returning it from SimpleTimeZone.clone() method:

 ??? public Object clone()
 ??? {
 ??????? SimpleTimeZone clone = (SimpleTimeZone) super.clone();
 ??????? clone.invalidateCache();
 ??????? return clone;
 ??? }

This fixes the issue and for the case of TimeZone.getDefault() which is 
called from ZoneId.systemDefault() even elides synchronization in 
clone.invalidateCache() and allocation of the clone, so JITed 
ZoneId.systemDefault() is unaffected by the patch. Initially I was 
satisfied with the fix, but then I tested something. Suppose someone 
sets default zone to SimpleTimeZone:

 ??????? TimeZone.setDefault(
 ??????????? new SimpleTimeZone(3600000,
 ?????????????????????????????? "Europe/Paris",
 ?????????????????????????????? Calendar.MARCH, -1, Calendar.SUNDAY,
 ?????????????????????????????? 3600000, SimpleTimeZone.UTC_TIME,
 ?????????????????????????????? Calendar.OCTOBER, -1, Calendar.SUNDAY,
 ?????????????????????????????? 3600000, SimpleTimeZone.UTC_TIME,
 ?????????????????????????????? 3600000)
 ??????? );

And then calls some methods that initialize the cache of the internal 
shared TimeZone.defaultTimeZone instance:

 ??? new Date().toString();

The code which after that tries to obtain default time zone and 
calculate the offset from UTC at some current point in time, for example:

 ??? TimeZone.getDefault().getOffset(now)

can't use the cached state because it has been invalidated in the 
returned clone. Such code has to re-compute the offset every time it 
gets new clone. I measured this with a JMH benchmark and got the 
following result:

Default:

Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? ns/op
ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? ns/op

Venkat's patch - invalidateCache():

Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 179,476 ? 1,942? ns/op
ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,538 ? 0,073? ns/op

We see that ZoneId.systemDefault() is unaffected, but 
TimeZone.getDefault().getOffset(now) becomes 3x slower.

This is not good, so I tried an alternative fix for the issue - simply 
making the SimpleTimeZone.clone() synchronized. Access to cache fields 
is already synchronized, so this should fix the race. Here's the JMH result:

Default:

Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? ns/op
ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? ns/op

Synchronized clone():

Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 58,103 ? 0,936? ns/op
ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 4,154 ? 0,034? ns/op

We see that caching works again, but synchronization has some overhead 
which is not big for single-threaded access, but might get bigger when 
multiple threads try to get default zone concurrently.

So I created a 3rd variant of the fix which I'm presenting here and 
requesting a review for:

http://cr.openjdk.java.net/~plevart/jdk10-dev/8191216_SimpleTimeZone_clone_race/webrev.01/

The JMH benchmark shows this:

Default:

Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? ns/op
ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? ns/op

Cache object:

Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 42,860 ? 0,274? ns/op
ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,545 ? 0,057? ns/op

Not only does the fix not affect ZoneId.systemDefault() which is not 
surprising, but it also speeds-up cache lookup in single-threaded 
benchmark and certainly eliminates possible contention among threads 
looking up the shared instance.

I have run the test/jdk/java/util/TimeZone and 
test/jdk/java/util/Calendar jtreg tests and there were 7 failures caused 
by compilation errors (package sun.util.locale.provider is not visible), 
while 59 other tests pass.

So, what do you think?

Regards, Peter


Venkateswara R Chintala je 21. 11. 2017 ob 10:14?napisal:
> Thanks Peter for sponsoring this patch. Is there anything else that 
> needs to be done from my end for this patch to be integrated? Please 
> let me know.
>
> -Venkat
>
>
> On 14/11/17 8:46 PM, Peter Levart wrote:
>> Hi Venkat,
>>
>> I created the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8191216
>>
>> I can also sponsor this patch and push it for JDK 10.
>>
>> The patch that you are proposing looks good to me. Does anybody have 
>> anything else to say?
>>
>> Regards, Peter
>>
>>
>> On 11/13/2017 11:28 AM, Venkateswara R Chintala wrote:
>>> Thanks David, Peter for your review and comments. As I am new to the 
>>> community, can you please help me to open a bug and integrate the 
>>> changes into code base?
>>>
>>> -Venkat
>>>
>>> On 12/11/17 2:19 AM, Peter Levart wrote:
>>>> Hi David, Venkat,
>>>>
>>>> On 11/11/17 21:15, Peter Levart wrote:
>>>>> For example, take the following method:
>>>>>
>>>>> String defaultTZID() {
>>>>> ??? return TimeZone.getDefault().getID();
>>>>> }
>>>>>
>>>>> When JIT compiles it and inlines invocations to other methods 
>>>>> within it, it can prove that cloned TimeZone instance never 
>>>>> escapes the call to defaultTZID() and can therefore skip 
>>>>> allocating the instance on heap.
>>>>>
>>>>> But this is fragile. If code in invoked methods changes, they may 
>>>>> not get inlined or EA may not be able to prove that the cloned 
>>>>> instance can't escape and allocation may be introduced. 
>>>>> ZoneId.systemDefault() is a hot method and it would be nice if we 
>>>>> manage to keep it allocation free.
>>>>
>>>> Well, I tried the following variant of SimpleTimeZone.clone() patch:
>>>>
>>>> ??? public Object clone()
>>>> ??? {
>>>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>>> ??????? // like tz.invalidateCache() but without holding a lock on 
>>>> clone
>>>> ??????? tz.cacheYear = tz.startYear - 1;
>>>> ??????? tz.cacheStart = tz.cacheEnd = 0;
>>>> ??????? return tz;
>>>> ??? }
>>>>
>>>>
>>>> ...and the JMH benchmark with gc profiling shows that 
>>>> ZoneId.systemDefault() still manages to get JIT-compiled without 
>>>> introducing allocation.
>>>>
>>>> Even the following (original Venkat's) patch:
>>>>
>>>> ??? public Object clone()
>>>> ??? {
>>>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>>> ??????? tz.invalidateCache();
>>>> ??????? return tz;
>>>> ??? }
>>>>
>>>> ...does the same and the locking in invalidateCache() is elided 
>>>> too. Allocation and lock-elision go hand-in-hand. When object 
>>>> doesn't escape, allocation on heap may be eliminated and locks on 
>>>> that instance elided.
>>>>
>>>> So this is better than synchronizing on the original instance 
>>>> during .clone() execution as it has potential to avoid locking 
>>>> overhead.
>>>>
>>>> So Venkat, go ahead. My fear was unjustified.
>>>>
>>>> Regards, Peter
>>>>
>>>
>>
>>
>


From rahul.v.raghavan at oracle.com  Sun Nov 26 17:09:36 2017
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Sun, 26 Nov 2017 22:39:36 +0530
Subject: [10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in
 tier1
In-Reply-To: <752a4e80-9141-6115-dee6-2bbd0ec99e92@oracle.com>
References: <e11bf848-ce2c-0ef9-6649-756f0cbb2f62@oracle.com>
 <752a4e80-9141-6115-dee6-2bbd0ec99e92@oracle.com>
Message-ID: <9e8de2ad-8ea2-3e66-7ea1-bd5d90acf936@oracle.com>

Thank you Dan for the review.

Rahul

On Friday 24 November 2017 08:56 PM, Daniel D. Daugherty wrote:
> On 11/24/17 6:16 AM, Rahul Raghavan wrote:
>> Hi,
>>
>> Please review the following fix proposal for 8191813.
>>
>> webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/
> 
> test/hotspot/jtreg/compiler/runtime/SpreadNullArg.java
>  ??? No comments.
> 
> So this style of call:
> 
>  ??? mh_spreadInvoker.invokeExact(mh_spread_target, (Object[]) null);
> 
> was changed from throwing IllegalArgumentException due to the "null"
> parameter to throwing NullPointerException. You've updated the test
> cleanly to switch from one exception to the other.
> 
> Thumbs up! I believe this patch qualifies as trivial and does not
> need to wait for 24 hours. I leave it up to you whether you wait
> for a Compiler team member review also.
> 
> Dan
> 
> 
>>
>>
>> jbs - https://bugs.openjdk.java.net/browse/JDK-8191813
>>
>> -- reported issue - After the latest sync from jdk/jdk the test 
>> SpreadNullArg started to fail in tier1 on all platforms.
>>
>> -- Found this SpreadNullArg.java failure Caused after JDK-8157246 fix.
>> jbs - https://bugs.openjdk.java.net/browse/JDK-8157246.
>> 'MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to 
>> specify invocation-time behavior'.
>> changeset - http://hg.openjdk.java.net/jdk/jdk/rev/76519338df34
>>
>> - So now with 8157246 fix, if method handle is invoked with a null 
>> array reference, NullPointerException will be thrown. (Not 
>> IllegalArgumentException)
>>
>> - So above fix proposal in SpreadNullArg.java to expect 
>> NullPointerException after 8157246 changes.
>>
>>
>> Thanks,
>> Rahul
> 

From rahul.v.raghavan at oracle.com  Sun Nov 26 17:10:21 2017
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Sun, 26 Nov 2017 22:40:21 +0530
Subject: [10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in
 tier1
In-Reply-To: <792dadfc-89d3-054c-d3f2-303a69346be6@oracle.com>
References: <e11bf848-ce2c-0ef9-6649-756f0cbb2f62@oracle.com>
 <792dadfc-89d3-054c-d3f2-303a69346be6@oracle.com>
Message-ID: <011150aa-9a29-2786-522f-c755469f0335@oracle.com>

Thank you Mandy for review.

On Friday 24 November 2017 11:11 PM, mandy chung wrote:
> Looks good.? Thanks for fixing the test, Rahul.
> 
> Mandy
> 
> On 11/24/17 3:16 AM, Rahul Raghavan wrote:
>> Hi,
>>
>> Please review the following fix proposal for 8191813.
>>
>> webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/
>>
>>
>> jbs - https://bugs.openjdk.java.net/browse/JDK-8191813
>>
>> -- reported issue - After the latest sync from jdk/jdk the test 
>> SpreadNullArg started to fail in tier1 on all platforms.
>>
>> -- Found this SpreadNullArg.java failure Caused after JDK-8157246 fix.
>> jbs - https://bugs.openjdk.java.net/browse/JDK-8157246.
>> 'MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to 
>> specify invocation-time behavior'.
>> changeset - http://hg.openjdk.java.net/jdk/jdk/rev/76519338df34
>>
>> - So now with 8157246 fix, if method handle is invoked with a null 
>> array reference, NullPointerException will be thrown. (Not 
>> IllegalArgumentException)
>>
>> - So above fix proposal in SpreadNullArg.java to expect 
>> NullPointerException after 8157246 changes.
>>
>>
>> Thanks,
>> Rahul
> 

From abdul.kolarkunnu at oracle.com  Mon Nov 27 08:17:57 2017
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Mon, 27 Nov 2017 00:17:57 -0800 (PST)
Subject: RFR: JDK8U Backport of 8154017: Shutdown hooks are racing against
 shutdown sequence, if System.exit()-calling thread is interrupted
Message-ID: <2c2babeb-b437-42b1-a12c-0a6a3b310eed@default>

Hi All,
 
Please review this webrev for jdk8u backport.
Webrev: http://cr.openjdk.java.net/~akolarkunnu/8191289/webrev.00/
 
Main Bug: https://bugs.openjdk.java.net/browse/JDK-8154017
JDK10 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041952.html
JDK10 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ceeea7370651
 
Change w.r.t JDK9 changeset: Changed only throws Exception to throws Throwable in test case,  as jdk.testlibrary.ProcessTools.executeProcess() throws Throwable in JDK8.
public static void main(String[] args) throws Throwable {
 
Testing: Tested new regression test and all core-libs regression tests on all platforms - there are no new failures.
 
Regards,
Muneer

From per.liden at oracle.com  Mon Nov 27 10:25:44 2017
From: per.liden at oracle.com (Per Liden)
Date: Mon, 27 Nov 2017 11:25:44 +0100
Subject: RFR(s): 8191859: SoftReference clock/timestamp should be declared
 volatile
In-Reply-To: <CA+kOe098mzPV8joRcRV=CNX53VBC4CAVEA6xfyPzUQsNxni0HA@mail.gmail.com>
References: <22953aa6-6eb0-f2a5-82ac-f6f700d4f5e5@oracle.com>
 <CA+kOe098mzPV8joRcRV=CNX53VBC4CAVEA6xfyPzUQsNxni0HA@mail.gmail.com>
Message-ID: <ccc1562b-426d-ba59-0aad-3fb1f699a0f4@oracle.com>

Hi Martin,

On 2017-11-24 23:56, Martin Buchholz wrote:
> These fields have been this way for a very long time, probably
> intentionally non-volatile.
> Is there an observable problem being solved here?

Sorry for not being more clear about that. Having them non-volatile can 
lead to the timestamp going backwards (e.g. in C2, if a clock load is 
cached over a safepoint), which in turn can lead to incorrect decision 
being made by the GC SoftRef policy about whether the referent should be 
cleared or not. While an incorrect decision is sub-optimal, it's not 
catastrophic. Worst case is that we clear a soft ref per-maturely.

However, after some discussions here we realized that the suggested fix 
isn't enough to prevent this from happening, e.g. when the interpreter 
is running without thread local safepoint polling. A robust fix for this 
would likely need a CAS to prevent the timestamp from going backwards.

For these reasons, I'm withdrawing my suggested change for now. I need 
to think more about the implication of a robust fix, or if we should 
just live with this issue.

cheers,
Per

> I see that out-of-thin-air longs are theoretically possible, but very
> rare in practice on current platforms.
> If all you're trying to do is to ensure atomicity and that the
> reads/writes don't get optimized away by the jit, then consider using
> "opaque" VarHandles instead.
>
> I was surprised there was no bug subcomponent for java.lang.ref
>
> On Fri, Nov 24, 2017 at 5:13 AM, Per Liden <per.liden at oracle.com
> <mailto:per.liden at oracle.com>> wrote:
>
>     The clock and timestamp fields in SoftReference should be declared
>     volatile. These fields are read or updated by the VM, (possibly)
>     concurrently with the execution of Java threads.
>
>     To be more specific, the timestamp field is read by the GC during
>     reference discovery, e.g. during G1/CMS concurrent mark. The clock
>     is updated by the GC, typically after reference processing has
>     completed.
>
>     Webrev: http://cr.openjdk.java.net/~pliden/8191859/webrev.0/
>     <http://cr.openjdk.java.net/~pliden/8191859/webrev.0/>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8191859
>     <https://bugs.openjdk.java.net/browse/JDK-8191859>
>
>     /Per
>
>

From Alan.Bateman at oracle.com  Mon Nov 27 14:37:14 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 27 Nov 2017 14:37:14 +0000
Subject: JDK-8191706: Proposal to add Reader::transferTo(Writer)
In-Reply-To: <c338dcb4-6a15-45c4-6610-22e1c9892cce@reini.net>
References: <0d53fe18-9443-201d-c4bd-7f9c973b0602@reini.net>
 <ae4d9788-49d0-49fc-f406-f10cc486d147@oracle.com>
 <c338dcb4-6a15-45c4-6610-22e1c9892cce@reini.net>
Message-ID: <a8e8f52f-030b-f49e-a9ff-b940276a877c@oracle.com>

On 22/11/2017 18:36, Patrick Reinhart wrote:
> Webrev and CSR updated accordingly...
>
> -Patrick
>
Spec and implementation looks good.

-Alan

From sean.coffey at oracle.com  Mon Nov 27 15:30:15 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 27 Nov 2017 15:30:15 +0000
Subject: RFR: JDK8U Backport of 8154017: Shutdown hooks are racing against
 shutdown sequence, if System.exit()-calling thread is interrupted
In-Reply-To: <2c2babeb-b437-42b1-a12c-0a6a3b310eed@default>
References: <2c2babeb-b437-42b1-a12c-0a6a3b310eed@default>
Message-ID: <318cff95-4eef-1ac7-93b6-edd69737fc4f@oracle.com>

Looks fine.

Regards,
Sean.

On 27/11/17 08:17, Muneer Kolarkunnu wrote:
> Hi All,
>   
> Please review this webrev for jdk8u backport.
> Webrev: http://cr.openjdk.java.net/~akolarkunnu/8191289/webrev.00/
>   
> Main Bug: https://bugs.openjdk.java.net/browse/JDK-8154017
> JDK10 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041952.html
> JDK10 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ceeea7370651
>   
> Change w.r.t JDK9 changeset: Changed only throws Exception to throws Throwable in test case,  as jdk.testlibrary.ProcessTools.executeProcess() throws Throwable in JDK8.
> public static void main(String[] args) throws Throwable {
>   
> Testing: Tested new regression test and all core-libs regression tests on all platforms - there are no new failures.
>   
> Regards,
> Muneer


From xueming.shen at oracle.com  Mon Nov 27 16:37:09 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 27 Nov 2017 08:37:09 -0800
Subject: RFR: 8189789: tomcat gzip-compressed response bodies appear to
 be broken in update 151
In-Reply-To: <d9854879-115b-ddd6-a3f1-cfba04bca9ea@oracle.com>
References: <d9854879-115b-ddd6-a3f1-cfba04bca9ea@oracle.com>
Message-ID: <5A1C3F35.3050908@oracle.com>

+1

On 11/22/17, 1:59 AM, Se?n Coffey wrote:
> Looking to fix a recent regression that appeared in 8u151. Thanks goes 
> to Sherman for the src patch. Paul Hohensee has also helped by 
> provided some test code. I've been able to modify an existing test to 
> mimic the behaviour seen with FlushableGZIPOutputStream which is found 
> in Tomcat 7.x.
>
> Sherman is working on a patch for JDK 10. For unix OSes, JDK 10 
> operates with the zlib version found on the OS.
>
> bug : https://bugs.openjdk.java.net/browse/JDK-8189789
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/
>
> regards,
> Sean.
>


From kumar.x.srinivasan at oracle.com  Mon Nov 27 16:42:41 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 27 Nov 2017 08:42:41 -0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
Message-ID: <5A1C4081.2090107@oracle.com>

Hi,

I looked at some of the components I maintain, and they look good.

Wrt. the test:

1. The local variables/fields don't comply with the coding conventions, 
we have been
      following in the JDK.

2.  Hmm, someone parked a .ini file in bin directory, later removed,
      perhaps on windows simply check for .exe ? Should a check exist
      to verify if file has executable permissions ?"File.canExecute".

  171     // Returns true if the file is not a tool.
  172     static boolean notATool(String file) {
  173         file = file.toLowerCase();
  174         if (file.endsWith(".dll") ||
  175             file.endsWith(".map") ||
  176             file.endsWith(".pdb") ||
  177             file.equals("server")) {  // server subdir on windows.
  178             return true;
  179         }
  180         return false;
  181     }


3.  Typo in comment

201     // Check whether 'flag' appears in 'line' as a word of itself. I must not

s/I must/It must/


4. There is a method to check for isEnglishLocale in TestHelper, perhaps 
use it
to have the test bale out in non english locales as early as possible ?

5.  Has this been tested on all platforms ? do you need help testing it ?

Kumar


On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> please review this change. I also filed a CSR for this:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>
> See the webrev for a detailed description of the changes.
>
> If required, I'll make break-out changes to be reviewed separately.
>
> I had posted a RFR before, but improved the change to
> give a more complete overview of currently supported flags
> for the CSR:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html
>
> Best regards,
>    Goetz.
>


From vladimir.kozlov at oracle.com  Mon Nov 27 18:00:24 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 27 Nov 2017 10:00:24 -0800
Subject: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only
 the permissions it really needs to expose the bean
In-Reply-To: <7CC15F2A-53F3-4E7C-87A5-6BE8061D72F6@oracle.com>
References: <2138013.zvGs44vPXg@pracovni>
 <715d933a-a747-8aac-620b-fba12f4236e0@oracle.com>
 <7b03728a-a3ad-e392-db1b-dd0807e1ffeb@oracle.com>
 <1750350.QVl7KHXjYn@pracovni>
 <bec7f66f-d801-7c52-0eae-8b371b265f4d@oracle.com>
 <8dbd6b66-f87f-fa7d-0f83-de094d98d312@oracle.com>
 <7CC15F2A-53F3-4E7C-87A5-6BE8061D72F6@oracle.com>
Message-ID: <7165bf3b-2738-0600-5b5d-533a9cfae0e3@oracle.com>

Thanks! I pushed it.

Vladimir

On 11/23/17 7:40 PM, Jaroslav Tulach wrote:
> 24. 11. 2017 v?2:33, mandy chung <mandy.chung at oracle.com <mailto:mandy.chung at oracle.com>>:
> 
>> I'm okay with this fix.
> 
> Just for the record: I am also fine with integrating my change.
> -jt
> 
>>
>> On 11/21/17 3:26 PM, Vladimir Kozlov wrote:
>>> Do we have consensus about changes? I can sponsor and push it.
>>>
>>> These changes passed Hotspot pre-integration testing and additional requested tests.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 11/15/17 5:44 AM, Jaroslav Tulach wrote:
>>>> On ?ter? 14. listopadu 2017 21:34:45 CET mandy chung wrote:
>>>>> I am wondering this ACE comes from Graal accessing jdk.vm.ci.services
>>>>> from JVMCI which is defined to the boot loader versus Graal is defined
>>>>> to the platform class loader.
>>>>>
>>>>> ?? java.security.AccessControlException: access denied
>>>>> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.vm.ci.services")
>>>>>
>>>>> However Graal grants with AllPermissions.
>>>>>
>>>>> In any case, if this is an existing issue, I am okay if you file a
>>>>> separate issue to track this.
>>>>
>>>> Hello Mandy,
>>>> yes, it looks like issue unrelated to my changes. I have reported: https://
>>>> bugs.openjdk.java.net/browse/JDK-8191320 <http://bugs.openjdk.java.net/browse/JDK-8191320>
>>>>
>>>> I hope I haven't messed up something on my disk and others will be able to
>>>> reproduce my problem.
>>>> -jt
>>>>
>>>>
>>>>>
>>>>> Mandy
>>>>>
>>>>> On 11/14/17 2:02 PM, Sean Mullan wrote:
>>>>>> Try running with -Djava.security.debug=access:domain:failure
>>>>>>
>>>>>> This will tell you what ProtectionDomain caused the
>>>>>> AccessControlException, which should give you a better idea of where
>>>>>> the problem is. Look for messages that start with "domain that failed ".
>>>>>>
>>>>>> --Sean
>>>>>>
>>>>>> On 11/14/17 1:22 AM, Jaroslav Tulach wrote:
>>>>>>> I tried the same test with
>>>>>>>
>>>>>>> changeset:?? 47679:d85284ccd1bd
>>>>>>> user:??????? sspitsyn
>>>>>>> date:??????? Fri Nov 03 17:09:25 2017 -0700
>>>>>>> summary:???? 8189731: Disable CFLH when there are no transformers
>>>>>>>
>>>>>>> and it also yields the exception. E.g. the problem is certainly not
>>>>>>> result of
>>>>>>> my changes.
>>>>>>>
>>>>>>> -jt
>>>>>>>
>>>>>>> PS: I try full rebuild on d85284ccd1bd maybe it disappears...
>>>>>>>
>>>>>>> On pond?l? 13. listopadu 2017 20:53:35 CET Jaroslav Tulach wrote:
>>>>>>>> Hello Mandy,
>>>>>>>>
>>>>>>>> this was a good test:
>>>>>>>>>> ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
>>>>>>>>>> +EnableJVMCI -XX:+UseJVMCICompiler -jar ...
>>>>>>>>>
>>>>>>>>> You can also try running the above command with
>>>>>>>>> -Djava.security.manager
>>>>>>>>> as a sanity test (the application may need additional permissions) -
>>>>>>>>> just a sanity test.
>>>>>>>>
>>>>>>>> I've just tried:
>>>>>>>>
>>>>>>>> $ ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:
>>>>>>>> +EnableJVMCI -XX:+UseJVMCICompiler -Djava.security.manager -jar ~/
>>>>>>>> NetBeansProjects/sieve/java/algorithm/target/sieve-algorithm-1.0-SNAPSHO
>>>>>>>> T.ja
>>>>>>>>
>>>>>>>> r
>>>>>>>>
>>>>>>>> and it doesn't work. I am getting an error below, however the code
>>>>>>>> is not
>>>>>>>> running through my module at all. I don't understand the failure, I
>>>>>>>> will
>>>>>>>> have to investigate more.
>>>>>>>>
>>>>>>>> -jt
>>>>>>>>
>>>>>>>>
>>>>>>>> Caused by: java.security.AccessControlException: access denied
>>>>>>>> ("java.lang.RuntimePermission"
>>>>>>>> "accessClassInPackage.jdk.vm.ci.services")
>>>>>>>> ????????? at java.base/
>>>>>>>> java.security.AccessControlContext.checkPermission(AccessControlContext.
>>>>>>>> java>>>
>>>>>>>> : 472)
>>>>>>>>
>>>>>>>> ????????? at java.base/
>>>>>>>> java.security.AccessController.checkPermission(AccessController.java:895
>>>>>>>> )
>>>>>>>>
>>>>>>>> ????????? at java.base/
>>>>>>>> java.lang.SecurityManager.checkPermission(SecurityManager.java:558)
>>>>>>>> ????????? at java.base/
>>>>>>>> java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1534)
>>>>>>>> ????????? at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:680)
>>>>>>>> ????????? at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:678)
>>>>>>>> ????????? at
>>>>>>>> java.base/java.security.AccessController.doPrivileged(Native
>>>>>>>> Method)
>>>>>>>> ????????? at java.base/
>>>>>>>> java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:678)
>>>>>>>> ????????? at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>>>>>>>> ????????? at
>>>>>>>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1006) at
>>>>>>>> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1085) at
>>>>>>>> java.base/
>>>>>>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:206)
>>>>>>>> ????????? at java.base/
>>>>>>>> jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.ja
>>>>>>>> va:7
>>>>>>>>
>>>>>>>> 60) at java.base/jdk.internal.loader.BuiltinClassLoader.lambda
>>>>>>>> $findClassInModuleOrNull$2(BuiltinClassLoader.java:683)
>>>>>>>> ????????? at
>>>>>>>> java.base/java.security.AccessController.doPrivileged(Native
>>>>>>>> Method)
>>>>>>>> ????????? at java.base/
>>>>>>>> jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinCl
>>>>>>>> assL
>>>>>>>>
>>>>>>>> oader.java: 684)
>>>>>>>> ????????? at java.base/
>>>>>>>> jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java
>>>>>>>> :562
>>>>>>>>
>>>>>>>> ) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:607) at
>>>>>>>> java.base/java.lang.Class.forName(Class.java:451)
>>>>>>>> ????????? at java.base/java.util.ServiceLoader.lambda$loadProvider
>>>>>>>> $1(ServiceLoader.java:856)
>>>>>>>> ????????? at
>>>>>>>> java.base/java.security.AccessController.doPrivileged(Native
>>>>>>>> Method)
>>>>>>>> ????????? at
>>>>>>>> java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java: 858)
>>>>
>>>>
>>

From hohensee at amazon.com  Mon Nov 27 20:18:57 2017
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 27 Nov 2017 20:18:57 +0000
Subject: 8189789: tomcat gzip-compressed response bodies appear to be
 broken in update 151
In-Reply-To: <dcabc1c2-0170-43e7-788b-1f7d7fefeff4@oracle.com>
References: <d9854879-115b-ddd6-a3f1-cfba04bca9ea@oracle.com>
 <330832F9-E047-41B9-82BD-44BD75EA9CCA@amazon.com>
 <dcabc1c2-0170-43e7-788b-1f7d7fefeff4@oracle.com>
Message-ID: <2F7977ED-FFA6-4CE1-9A8A-3ED1510E1A45@amazon.com>

I?d file an RFE to refactor the Deflater.c code.

Following the zlib code is the right thing to do in order to stay consistent, even if it?s a bit rough.

So, ship it.

On 11/22/17, 9:43 AM, "Se?n Coffey" <sean.coffey at oracle.com> wrote:

    
    On 22/11/2017 15:46, Hohensee, Paul wrote:
    > If the fix is from the zlib project, then ignore the following, since it?s their code.
    >
    > In Deflater.c: the existing significant code duplication between the arms of the if-else gives one pause. E.g., in the new file, compare lines 148/183 and 155/190. Might be bugs lurking at 183 and 190.
    There might be some room for optimizing alright. The different length 
    variables are measuring the available input and output length values. 
    Different action is taken if we encounter exceptions when setting up 
    memory for related operations. Maybe we can bring more consistent length 
    checks to both blocks. I'd have to check why we check for native 
    exception handling in one block and not the other.
    >
    > In deflate.c: the old code had ?s->last_flush = Z_NO_FLUSH?, the new has ?-2?. Should ?-2? be symbolic instead?
    Sherman is following the code from the main zlib repo for that change [1]
    
    regards,
    Sean.
    
    [1] https://github.com/madler/zlib/issues/275
    >
    > Thanks,
    >
    > Paul
    >
    > On 11/22/17, 2:00 AM, "core-libs-dev on behalf of Se?n Coffey" <core-libs-dev-bounces at openjdk.java.net on behalf of sean.coffey at oracle.com> wrote:
    >
    >      Looking to fix a recent regression that appeared in 8u151. Thanks goes
    >      to Sherman for the src patch. Paul Hohensee has also helped by provided
    >      some test code. I've been able to modify an existing test to mimic the
    >      behaviour seen with FlushableGZIPOutputStream which is found in Tomcat 7.x.
    >      
    >      Sherman is working on a patch for JDK 10. For unix OSes, JDK 10 operates
    >      with the zlib version found on the OS.
    >      
    >      bug : https://bugs.openjdk.java.net/browse/JDK-8189789
    >      webrev : http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/
    >      
    >      regards,
    >      Sean.
    >      
    >      
    >
    
    


From brian.burkhalter at oracle.com  Mon Nov 27 20:43:18 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 27 Nov 2017 12:43:18 -0800
Subject: Fix inconsistent behavior of
 java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
In-Reply-To: <0ea7f597-e92a-2499-2596-e06957808c83@oracle.com>
References: <B0D097BB-76CA-4213-A2AB-C11E4028A710@amazon.com>
 <2327919D-564F-41C6-9354-641BEEC32D3C@amazon.com>
 <41a78184-f609-bdf7-98f8-ae037bb07366@oracle.com>
 <6BA6AA5C-B16C-42B7-92FC-633138CC72D6@amazon.com>
 <0ea7f597-e92a-2499-2596-e06957808c83@oracle.com>
Message-ID: <1D286486-00B0-4B0C-889B-A60E0C2F7ECA@oracle.com>

On Nov 24, 2017, at 10:24 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> If you backport JDK-8177809 and build with any recent gcc then you should find that the results are consistent. If you really need to build  gcc 4.1.x (2006) then the changes for JDK-8177809 would require #ifdef so that they aren't compiled in.
> 
> I realize your interest is jdk8u but for the main line then we do need to re-examine the dusty #ifdef in UnixNativeDispatcher.c. I think Oracle builds of jDK 10 use gcc 4.9.2, I believe others are probably building with newer versions.

Seems like one or the other of the foregoing should be done, i.e., adding the same conditional compilation directive to the patch for JDK-8177809, or removing it altogether from UnixNativeDispatcher.c.

Brian

From naoto.sato at oracle.com  Mon Nov 27 20:54:17 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 27 Nov 2017 12:54:17 -0800
Subject: <i18n dev> [10] RFR 8176841: Additional Unicode Language-Tag
 Extensions
In-Reply-To: <CACzrW9A6GAWv=UUAsJ-xHivGp-RkjJvv2riXjYhyaoC-u4TeuQ@mail.gmail.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <03d177e8-ae43-6692-80f5-34dcc402ae51@oracle.com>
 <CACzrW9A6GAWv=UUAsJ-xHivGp-RkjJvv2riXjYhyaoC-u4TeuQ@mail.gmail.com>
Message-ID: <f32d69be-effa-d08e-6745-c3beb5b86504@oracle.com>

Thanks, Stephen. Here is the updated webrev:

http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.06/

Naoto

On 11/23/17 8:13 AM, Stephen Colebourne wrote:
> In DateTimeFormatter line 1508, this would be preferred:
> 
>    return  new DateTimeFormatter(printerParser, locale, ds,
> resolverStyle, resolverFields, c, z);
> 
> In DateTimeFormatterBuilder.getLocalizedDateTimePattern() there is no
> spec change wrt using "rg".
> 
> Should findRegionOverride() just return a Locale instead of am
> Optional<Locale>? It always seems to have an orElse(locale).
> 
> Java-Time tests look good.
> 
> thanks
> Stephen
> 
> 
> On 22 November 2017 at 19:04, Naoto Sato <naoto.sato at oracle.com> wrote:
>> I revised the proposed changes, including java.time changes suggested by
>> Stephen (CSR is still in progress):
>>
>> https://bugs.openjdk.java.net/browse/JDK-8191349
>>
>> The entire webrev is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.05/
>>
>> And the diff webrev from the last one is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8191349/webrev.04-05/
>>
>> I'd appreciate your reviews.
>>
>> Naoto
>>
>>
>>
>> On 11/9/17 3:34 PM, Naoto Sato wrote:
>>>
>>> Kindly requesting reviews. I incorporated a fix to the following issue
>>> raised by the test team:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8190918
>>>
>>> Here is the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/
>>>
>>> And the webrev since the one below (to address 8190918):
>>>
>>> http://cr.openjdk.java.net/~naoto/8190918/
>>>
>>> Naoto
>>>
>>>
>>>
>>> On 11/2/17 2:42 PM, Naoto Sato wrote:
>>>>
>>>> Hello,
>>>>
>>>> Please review the proposed changes for the following issues:
>>>>
>>>> 8176841: Additional Unicode Language-Tag Extensions
>>>> 8189134: New system properties for the default Locale extensions
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
>>>>
>>>> This serves as the implementation of JEP 314.
>>>>
>>>> Naoto
>>>>
>>>>
>>>>
>>

From scolebourne at joda.org  Mon Nov 27 21:26:55 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 27 Nov 2017 21:26:55 +0000
Subject: <i18n dev> [10] RFR 8176841: Additional Unicode Language-Tag
 Extensions
In-Reply-To: <f32d69be-effa-d08e-6745-c3beb5b86504@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <03d177e8-ae43-6692-80f5-34dcc402ae51@oracle.com>
 <CACzrW9A6GAWv=UUAsJ-xHivGp-RkjJvv2riXjYhyaoC-u4TeuQ@mail.gmail.com>
 <f32d69be-effa-d08e-6745-c3beb5b86504@oracle.com>
Message-ID: <CACzrW9AiYD9whXokNvCqyXf_+F+PyNpEXWGSLOqLzv3-NfjW4A@mail.gmail.com>

This fixes my previous points, so fine by me. But I am not an OpenJDK reviewer.
Stephen

On 27 November 2017 at 20:54, Naoto Sato <naoto.sato at oracle.com> wrote:
> Thanks, Stephen. Here is the updated webrev:
>
> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.06/
>
> Naoto
>
>
> On 11/23/17 8:13 AM, Stephen Colebourne wrote:
>>
>> In DateTimeFormatter line 1508, this would be preferred:
>>
>>    return  new DateTimeFormatter(printerParser, locale, ds,
>> resolverStyle, resolverFields, c, z);
>>
>> In DateTimeFormatterBuilder.getLocalizedDateTimePattern() there is no
>> spec change wrt using "rg".
>>
>> Should findRegionOverride() just return a Locale instead of am
>> Optional<Locale>? It always seems to have an orElse(locale).
>>
>> Java-Time tests look good.
>>
>> thanks
>> Stephen
>>
>>
>> On 22 November 2017 at 19:04, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>
>>> I revised the proposed changes, including java.time changes suggested by
>>> Stephen (CSR is still in progress):
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8191349
>>>
>>> The entire webrev is located at:
>>>
>>>
>>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.05/
>>>
>>> And the diff webrev from the last one is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8191349/webrev.04-05/
>>>
>>> I'd appreciate your reviews.
>>>
>>> Naoto
>>>
>>>
>>>
>>> On 11/9/17 3:34 PM, Naoto Sato wrote:
>>>>
>>>>
>>>> Kindly requesting reviews. I incorporated a fix to the following issue
>>>> raised by the test team:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8190918
>>>>
>>>> Here is the updated webrev:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/
>>>>
>>>> And the webrev since the one below (to address 8190918):
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8190918/
>>>>
>>>> Naoto
>>>>
>>>>
>>>>
>>>> On 11/2/17 2:42 PM, Naoto Sato wrote:
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> Please review the proposed changes for the following issues:
>>>>>
>>>>> 8176841: Additional Unicode Language-Tag Extensions
>>>>> 8189134: New system properties for the default Locale extensions
>>>>>
>>>>> The proposed changeset is located at:
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
>>>>>
>>>>> This serves as the implementation of JEP 314.
>>>>>
>>>>> Naoto
>>>>>
>>>>>
>>>>>
>>>
>

From alexandre.iline at oracle.com  Mon Nov 27 21:56:24 2017
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Mon, 27 Nov 2017 13:56:24 -0800
Subject: Which test groups to run instead of :jdk (8176838)
In-Reply-To: <b61c05248fec4dc198e3dbfdece3d16c@sap.com>
References: <b61c05248fec4dc198e3dbfdece3d16c@sap.com>
Message-ID: <14806114-7B65-4EDA-BAA1-FEEFC7789C04@oracle.com>

Hi, Goetz.

:jdk, when created, was supposed to include tests which could be run by full JDK, which is, well, all the tests. Over the time there could have been new tests added which were not included in the :jdk group.

In fact, I have just now rolled the repository back to before the 8176838 change and checked test count in :jdk test group vs. full test suite.

$jtreg ? -l test/jdk/:jdk
?
Tests found: 8,563
$jtreg ? -l test/jdk
?
Tests found: 8,583

The difference consists in these tests:

> native_sanity/simplenativelauncher/ProgramTest.java
> native_sanity/simplenativelib2/NativeLib.java
> native_sanity/simplenativelib/NativeLib.java
> org/omg/CORBA/OrbPropertiesTest.java
> sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java
> sanity/client/SwingSet/src/ButtonDemoTest.java
> sanity/client/SwingSet/src/ComboBoxDemoTest.java
> sanity/client/SwingSet/src/DialogDemoTest.java
> sanity/client/SwingSet/src/ListDemoTest.java
> sanity/client/SwingSet/src/OptionPaneDemoTest.java
> sanity/client/SwingSet/src/ProgressBarDemoTest.java
> sanity/client/SwingSet/src/ScrollPaneDemoTest.java
> sanity/client/SwingSet/src/SliderDemoTest.java
> sanity/client/SwingSet/src/SpinnerDemoTest.java
> sanity/client/SwingSet/src/SplitPaneDemoTest.java
> sanity/client/SwingSet/src/TabbedPaneDemoTest.java
> sanity/client/SwingSet/src/TextFieldDemoTest.java
> sanity/client/SwingSet/src/ToggleButtonDemoTest.java
> sanity/client/SwingSet/src/TreeDemoTest.java
> sanity/client/SwingSet/src/WindowDemoTest.java

Shura



> On Nov 24, 2017, at 12:46 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi,
> 
> we used to run test target :jdk.
> This has been removed in 8176838.
> 
> Which target should we run now to get the same or similar set of tests?
> 
> Best regards,
>  Goetz.


From mandy.chung at oracle.com  Mon Nov 27 22:02:39 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 27 Nov 2017 14:02:39 -0800
Subject: Review Request: JDK-8190911: tools/jdeps/MultiReleaseJar.java failed
 with java.lang.IllegalThreadStateException
Message-ID: <ec228606-010c-6cd2-bf14-02a1e8c1a202@oracle.com>

This is a simple test fix. The test fails because it calls 
Process.exitValue() but the process hasn't exited.? The test should wait 
for the process to terminate or let it to timeout if something goes wrong.

Webrev:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8190911/webrev.00/

Mandy

From brian.burkhalter at oracle.com  Mon Nov 27 22:27:36 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 27 Nov 2017 14:27:36 -0800
Subject: Review Request: JDK-8190911: tools/jdeps/MultiReleaseJar.java
 failed with java.lang.IllegalThreadStateException
In-Reply-To: <ec228606-010c-6cd2-bf14-02a1e8c1a202@oracle.com>
References: <ec228606-010c-6cd2-bf14-02a1e8c1a202@oracle.com>
Message-ID: <46E6AE20-FDD1-4292-BAC8-5A9664C709C7@oracle.com>

Looks good.

Brian

On Nov 27, 2017, at 2:02 PM, mandy chung <mandy.chung at oracle.com> wrote:

> This is a simple test fix. The test fails because it calls Process.exitValue() but the process hasn't exited.  The test should wait for the process to terminate or let it to timeout if something goes wrong.
> 
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8190911/webrev.00/
> 
> Mandy


From stuart.marks at oracle.com  Mon Nov 27 22:38:00 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 27 Nov 2017 14:38:00 -0800
Subject: 8181175 Stream.concat behaves like terminal operation
In-Reply-To: <376868E1-F513-4FC6-8895-F27F5CB9A204@oracle.com>
References: <7A97602E-196A-49EF-B83F-086ACC591BA6@oracle.com>
 <3dcdae3d-0706-8f5b-2be3-0f934e5dc285@oracle.com>
 <376868E1-F513-4FC6-8895-F27F5CB9A204@oracle.com>
Message-ID: <9fc9aa78-7529-998d-83c3-2a07418efbdd@oracle.com>

On 11/20/17 10:34 AM, Paul Sandoz wrote:
> 
> 
>> On 17 Nov 2017, at 17:18, Stuart Marks <stuart.marks at oracle.com> wrote:
>> The normative text about binding to the source and subsequent modifications to the source possibly not being reflected in the stream makes sense.
>>
>> I'm having trouble understanding the API note though. What does "optimal" mean? What about concatenating multiple streams would not be optimal?
> 
> I updated to:
> 
> * @apiNote
> * To preserve optimization opportunities this method binds each stream to
> * its source and accepts only two streams as parameters.  For example, the
> * exact size of the concatenated stream source can be computed if the exact
> * size of each input stream source is known.
> * To concatenate more streams without binding, or nested calls to this
> * method, try creating a stream of streams and flat-mapping with the
> * identity function, for example:
> * <pre>{@code
> *     Stream<T> concat = Stream.of(s1, s2, s3, s4).flatMap(s -> s);
> * }</pre>
> 
> We could support three or more streams while preserving some characteristics, that complicates the concatenating spliterator a little bit. Each stream would still need to be bound.
> 
> Patch updated to include the primitive streams:
> 
>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8181175-concat-eager-binding/webrev/

OK, this makes a lot more sense. Just a small wording change:

1361      * To concatenate more streams without binding, or nested calls to this
1362      * method, try creating a stream of streams and flat-mapping with the
1363      * identity function, for example:

I think this would read more clearly if it were changed to "... without binding, 
or without nested calls to this method, ...." I think this applies in all four 
occurrences.

Thanks,

s'marks

From paul.sandoz at oracle.com  Mon Nov 27 23:18:35 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 27 Nov 2017 15:18:35 -0800
Subject: 8181175 Stream.concat behaves like terminal operation
In-Reply-To: <9fc9aa78-7529-998d-83c3-2a07418efbdd@oracle.com>
References: <7A97602E-196A-49EF-B83F-086ACC591BA6@oracle.com>
 <3dcdae3d-0706-8f5b-2be3-0f934e5dc285@oracle.com>
 <376868E1-F513-4FC6-8895-F27F5CB9A204@oracle.com>
 <9fc9aa78-7529-998d-83c3-2a07418efbdd@oracle.com>
Message-ID: <5932A989-4BDB-45A6-8B82-CF990CC66FBB@oracle.com>



> On 27 Nov 2017, at 14:38, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> On 11/20/17 10:34 AM, Paul Sandoz wrote:
>>> On 17 Nov 2017, at 17:18, Stuart Marks <stuart.marks at oracle.com> wrote:
>>> The normative text about binding to the source and subsequent modifications to the source possibly not being reflected in the stream makes sense.
>>> 
>>> I'm having trouble understanding the API note though. What does "optimal" mean? What about concatenating multiple streams would not be optimal?
>> I updated to:
>> * @apiNote
>> * To preserve optimization opportunities this method binds each stream to
>> * its source and accepts only two streams as parameters.  For example, the
>> * exact size of the concatenated stream source can be computed if the exact
>> * size of each input stream source is known.
>> * To concatenate more streams without binding, or nested calls to this
>> * method, try creating a stream of streams and flat-mapping with the
>> * identity function, for example:
>> * <pre>{@code
>> *     Stream<T> concat = Stream.of(s1, s2, s3, s4).flatMap(s -> s);
>> * }</pre>
>> We could support three or more streams while preserving some characteristics, that complicates the concatenating spliterator a little bit. Each stream would still need to be bound.
>> Patch updated to include the primitive streams:
>>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8181175-concat-eager-binding/webrev/
> 
> OK, this makes a lot more sense. Just a small wording change:
> 
> 1361      * To concatenate more streams without binding, or nested calls to this
> 1362      * method, try creating a stream of streams and flat-mapping with the
> 1363      * identity function, for example:
> 
> I think this would read more clearly if it were changed to "... without binding, or without nested calls to this method, ...." I think this applies in all four occurrences.
> 

Ok, updated in place, thanks,
Paul.


From mandy.chung at oracle.com  Tue Nov 28 01:43:35 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 27 Nov 2017 17:43:35 -0800
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
In-Reply-To: <5A139662.2030105@oracle.com>
References: <5A0E4703.3040409@oracle.com>
 <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>
 <5A0F13FF.8090406@oracle.com>
 <1c71e540-88a2-4f6f-5f2b-06b62b955df7@oracle.com>
 <5A131E90.6090509@oracle.com>
 <BE9EE092-1BDD-4A34-A8CF-C9F93094D3DE@oracle.com>
 <5A139662.2030105@oracle.com>
Message-ID: <f9aa9a4b-d399-14e1-d38e-81eec3e0ab9d@oracle.com>

Hi Sherman,

My apology for the belated review.? I just return from vacation.

On 11/20/17 6:58 PM, Xueming Shen wrote:
>
> http://cr.openjdk.java.net/~sherman/8189611/webrev
>
Just passing comments.

140 * that {@link getName()} returns. should be #getName(). There are a 
couple other @link missing #.

src/java.base/share/classes/module-info.java
 ??? line 214: the semi-colon is missing.?? It didn't fail the 
compilation because gensrc/java.base/module-info.java is generated to 
append the OS-specific module declaration and the build tool appends the 
semi-colon.? The build tool should catch this.

> jdeps' VersionHelper.java still accesses the "getRealName()" via the 
> SharedSecrets.
> Since jdeps is being compiled/built with the bootjdk, I'm leaving it 
> untouched for
> now.

I have filed JDK-8191942 for this.?? jdeps is not needed as the interim 
module (which runs on the boot JDK runtime).? CreateSymbols depends on 
com.sun.tools.classfile library that is in jdk.jdeps module.? We can 
modify the build to include com.sun.tools.classfile in the create symbol 
build tool classes to avoid compiling jdk.jdeps interim module.

I will start a review thread for JDK-8191942 that I can push soon after 
you push this fix.

Mandy



From mandy.chung at oracle.com  Tue Nov 28 01:50:04 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 27 Nov 2017 17:50:04 -0800
Subject: Review Request: JDK-8191942: Replace jdeps use of
 jdk.internal.util.jar.VersionedStream with new public API
Message-ID: <5a63eef2-3272-1b38-63f6-70cfe30a7cfb@oracle.com>

This is a follow-up on JDK-8189611 that defines a new public API to 
return a stream of versioned entries and to return the real name of a 
JAR entry.? JDK-8189611 leaves jdeps untouched because jdeps is compiled 
with the boot JDK.

This patch includes:
(1) changes the build not to build jdk.jdeps interim module but include 
com.sun.tools.classfile classes in the CreateSymbol buildtool
(2) replace the use of internal API with the public APIs defined by 
JDK-8191942
(3) remove jdk.internal.util.jar.VersonedStream class

Webrev:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8191942/webrev.00/

Thanks
Mandy

From paul.sandoz at oracle.com  Tue Nov 28 02:08:19 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 27 Nov 2017 18:08:19 -0800
Subject: RFR 8187237: Need to define the behaviour for 0 and 1 argument method
 type in StringConcatFactory.makeConcat
Message-ID: <ADC32E0B-9657-412A-B5D3-0F3E6DE63AF7@oracle.com>

8186737: Lookup argument for StringConcatFactory.makeConcat & makeConcatWithConstants cannot have privileges less than PRIVATE

Please review these minor specification updates to the StringConcat bootstrap methods to clarify behaviour:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186737-8187237-string-concat-bsm-spec-updates/webrev/

(I also updated the lambda bootstrap methods in the context of 8186737)

Thanks,
Paul.

From xueming.shen at oracle.com  Tue Nov 28 02:57:15 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 27 Nov 2017 18:57:15 -0800
Subject: RFR: JDK-8186087: jar tool fails to create a multi-release jar when
 validating nested classes
Message-ID: <5A1CD08B.9060906@oracle.com>

Hi

Please help review the change for #8186087

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

The proposed change is to handle the "outer class" of a  nested class 
correctly, instead of simply
relying on "top level" class. Other than that, a "minor" change is to 
also stop trying to "validate"
the non-class/resource entries, for example, if you have a resource 
"foo" both in the base and
versioned directory, and with different "content", currently 
implementation throws a warning
message, which does not appear to be desired and appropriate.

There is a "known/open" issue during discussion regarding how to handle 
the entry that its class
name does not match its entry name (for example, class p.foo.class is 
located at bar/p/foo.class,
currently jar.validator fails the validation with error msg). It appears 
to be a separate issue, so
I'm leaving that one of this one for now.

Thanks,
Sherman

From mandy.chung at oracle.com  Tue Nov 28 03:22:34 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 27 Nov 2017 19:22:34 -0800
Subject: RFR 8187237: Need to define the behaviour for 0 and 1 argument
 method type in StringConcatFactory.makeConcat
In-Reply-To: <ADC32E0B-9657-412A-B5D3-0F3E6DE63AF7@oracle.com>
References: <ADC32E0B-9657-412A-B5D3-0F3E6DE63AF7@oracle.com>
Message-ID: <08d9d7b5-9bb7-c0ee-aa3d-943bbd4ef744@oracle.com>

On 11/27/17 6:08 PM, Paul Sandoz wrote:
> 8186737: Lookup argument for StringConcatFactory.makeConcat & makeConcatWithConstants cannot have privileges less than PRIVATE
>
> Please review these minor specification updates to the StringConcat bootstrap methods to clarify behaviour:
>
>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186737-8187237-string-concat-bsm-spec-updates/webrev/

Looks fine to me.

Mandy


From martinrb at google.com  Tue Nov 28 04:19:56 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 27 Nov 2017 20:19:56 -0800
Subject: RFR: jsr166 jdk10 integration wave 6
Message-ID: <CA+kOe08MhHLgF7EGA2xAumMEzd1rA0EV85uFKSX_StetkCPrCw@mail.gmail.com>

http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/overview.html

Thanks to D?vid Karnok and Pavel Rappo for help with SubmissionPublisher.

8191937: Lost interrupt in AbstractQueuedSynchronizer when tryAcquire
methods throw
8187947: A race condition in SubmissionPublisher
8191069: Miscellaneous changes imported from jsr166 CVS 2017-12

From martinrb at google.com  Tue Nov 28 04:19:55 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 27 Nov 2017 20:19:55 -0800
Subject: RFR: jsr166 jdk10 integration wave 6
Message-ID: <CA+kOe0-yJ+9EX+U32zHAvMjo9LSJ9rKeKTmsrTskqk5uSBue4w@mail.gmail.com>

http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/overview.html

Thanks to D?vid Karnok and Pavel Rappo for help with SubmissionPublisher.

8191937: Lost interrupt in AbstractQueuedSynchronizer when tryAcquire
methods throw
8187947: A race condition in SubmissionPublisher
8191069: Miscellaneous changes imported from jsr166 CVS 2017-12

From david.holmes at oracle.com  Tue Nov 28 07:17:00 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 28 Nov 2017 17:17:00 +1000
Subject: RFR 8191216: SimpleTimeZone.clone() has a data race on cache
 fields
In-Reply-To: <017c44ce-a3e2-a03d-d437-98e08655a6a1@gmail.com>
References: <c49e479b-96c9-b80c-b400-8ce4c9617490@linux.vnet.ibm.com>
 <53644ce5-7c7c-18ff-4da9-7dfacd5b678d@linux.vnet.ibm.com>
 <c69a5064-c4ca-15aa-2678-d2dd0b2daa5b@oracle.com>
 <576cd10d-c75e-c7e2-ecb9-e28d09e059cf@linux.vnet.ibm.com>
 <caa8984e-1e71-fa07-de18-8e92599aebd4@gmail.com>
 <84ca56e0-67c8-3fbb-d558-4ebe797d513c@oracle.com>
 <8894f619-3510-acfa-3987-f013ca3638f3@gmail.com>
 <b68da9c6-1ad4-6926-7c27-21680e3b73b0@gmail.com>
 <d74ffdce-793a-bfe9-7e5f-4964897c3553@linux.vnet.ibm.com>
 <bef944fa-2a15-6c83-6730-ff7e32aa063f@gmail.com>
 <72a7efe3-ac34-1534-3a9b-146c647e1292@linux.vnet.ibm.com>
 <017c44ce-a3e2-a03d-d437-98e08655a6a1@gmail.com>
Message-ID: <d86e99d1-75c9-8c6e-d5ac-57b4cbff8431@oracle.com>

Hi Peter,

I like what you have done here. That said the general thread-unsafeness 
of the code in SimpleTimeZone still causes me concern - but what you are 
doing is not breaking anything more than it is already broken.

David

On 25/11/2017 9:32 AM, Peter Levart wrote:
> Hi,
> 
> @Venkat: Sorry for late response, but I had to try something 1st.
> 
> This is an official request for reviewing a patch for fixing a data race 
> between cloning a SimpleTimeZone object and lazily initializing its 3 
> cache fields which may produce a clone with inconsistent cache state. 
> Here's Jira issue with details:
> 
> https://bugs.openjdk.java.net/browse/JDK-8191216
> 
> Venkat has proposed to simply call invalidateCache() on the clone before 
> returning it from SimpleTimeZone.clone() method:
> 
>  ??? public Object clone()
>  ??? {
>  ??????? SimpleTimeZone clone = (SimpleTimeZone) super.clone();
>  ??????? clone.invalidateCache();
>  ??????? return clone;
>  ??? }
> 
> This fixes the issue and for the case of TimeZone.getDefault() which is 
> called from ZoneId.systemDefault() even elides synchronization in 
> clone.invalidateCache() and allocation of the clone, so JITed 
> ZoneId.systemDefault() is unaffected by the patch. Initially I was 
> satisfied with the fix, but then I tested something. Suppose someone 
> sets default zone to SimpleTimeZone:
> 
>  ??????? TimeZone.setDefault(
>  ??????????? new SimpleTimeZone(3600000,
>  ?????????????????????????????? "Europe/Paris",
>  ?????????????????????????????? Calendar.MARCH, -1, Calendar.SUNDAY,
>  ?????????????????????????????? 3600000, SimpleTimeZone.UTC_TIME,
>  ?????????????????????????????? Calendar.OCTOBER, -1, Calendar.SUNDAY,
>  ?????????????????????????????? 3600000, SimpleTimeZone.UTC_TIME,
>  ?????????????????????????????? 3600000)
>  ??????? );
> 
> And then calls some methods that initialize the cache of the internal 
> shared TimeZone.defaultTimeZone instance:
> 
>  ??? new Date().toString();
> 
> The code which after that tries to obtain default time zone and 
> calculate the offset from UTC at some current point in time, for example:
> 
>  ??? TimeZone.getDefault().getOffset(now)
> 
> can't use the cached state because it has been invalidated in the 
> returned clone. Such code has to re-compute the offset every time it 
> gets new clone. I measured this with a JMH benchmark and got the 
> following result:
> 
> Default:
> 
> Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? ns/op
> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? ns/op
> 
> Venkat's patch - invalidateCache():
> 
> Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 179,476 ? 1,942? ns/op
> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,538 ? 0,073? ns/op
> 
> We see that ZoneId.systemDefault() is unaffected, but 
> TimeZone.getDefault().getOffset(now) becomes 3x slower.
> 
> This is not good, so I tried an alternative fix for the issue - simply 
> making the SimpleTimeZone.clone() synchronized. Access to cache fields 
> is already synchronized, so this should fix the race. Here's the JMH result:
> 
> Default:
> 
> Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? ns/op
> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? ns/op
> 
> Synchronized clone():
> 
> Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 58,103 ? 0,936? ns/op
> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 4,154 ? 0,034? ns/op
> 
> We see that caching works again, but synchronization has some overhead 
> which is not big for single-threaded access, but might get bigger when 
> multiple threads try to get default zone concurrently.
> 
> So I created a 3rd variant of the fix which I'm presenting here and 
> requesting a review for:
> 
> http://cr.openjdk.java.net/~plevart/jdk10-dev/8191216_SimpleTimeZone_clone_race/webrev.01/
> 
> The JMH benchmark shows this:
> 
> Default:
> 
> Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 57,168 ? 0,501? ns/op
> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,558 ? 0,040? ns/op
> 
> Cache object:
> 
> Benchmark????????????????????????????????? Mode? Cnt Score?? Error? Units
> ZoneIdBench.TimeZone_getDefault_getOffset? avgt?? 10 42,860 ? 0,274? ns/op
> ZoneIdBench.ZoneId_systemDefault?????????? avgt?? 10 3,545 ? 0,057? ns/op
> 
> Not only does the fix not affect ZoneId.systemDefault() which is not 
> surprising, but it also speeds-up cache lookup in single-threaded 
> benchmark and certainly eliminates possible contention among threads 
> looking up the shared instance.
> 
> I have run the test/jdk/java/util/TimeZone and 
> test/jdk/java/util/Calendar jtreg tests and there were 7 failures caused 
> by compilation errors (package sun.util.locale.provider is not visible), 
> while 59 other tests pass.
> 
> So, what do you think?
> 
> Regards, Peter
> 
> 
> Venkateswara R Chintala je 21. 11. 2017 ob 10:14?napisal:
>> Thanks Peter for sponsoring this patch. Is there anything else that 
>> needs to be done from my end for this patch to be integrated? Please 
>> let me know.
>>
>> -Venkat
>>
>>
>> On 14/11/17 8:46 PM, Peter Levart wrote:
>>> Hi Venkat,
>>>
>>> I created the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8191216
>>>
>>> I can also sponsor this patch and push it for JDK 10.
>>>
>>> The patch that you are proposing looks good to me. Does anybody have 
>>> anything else to say?
>>>
>>> Regards, Peter
>>>
>>>
>>> On 11/13/2017 11:28 AM, Venkateswara R Chintala wrote:
>>>> Thanks David, Peter for your review and comments. As I am new to the 
>>>> community, can you please help me to open a bug and integrate the 
>>>> changes into code base?
>>>>
>>>> -Venkat
>>>>
>>>> On 12/11/17 2:19 AM, Peter Levart wrote:
>>>>> Hi David, Venkat,
>>>>>
>>>>> On 11/11/17 21:15, Peter Levart wrote:
>>>>>> For example, take the following method:
>>>>>>
>>>>>> String defaultTZID() {
>>>>>> ??? return TimeZone.getDefault().getID();
>>>>>> }
>>>>>>
>>>>>> When JIT compiles it and inlines invocations to other methods 
>>>>>> within it, it can prove that cloned TimeZone instance never 
>>>>>> escapes the call to defaultTZID() and can therefore skip 
>>>>>> allocating the instance on heap.
>>>>>>
>>>>>> But this is fragile. If code in invoked methods changes, they may 
>>>>>> not get inlined or EA may not be able to prove that the cloned 
>>>>>> instance can't escape and allocation may be introduced. 
>>>>>> ZoneId.systemDefault() is a hot method and it would be nice if we 
>>>>>> manage to keep it allocation free.
>>>>>
>>>>> Well, I tried the following variant of SimpleTimeZone.clone() patch:
>>>>>
>>>>> ??? public Object clone()
>>>>> ??? {
>>>>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>>>> ??????? // like tz.invalidateCache() but without holding a lock on 
>>>>> clone
>>>>> ??????? tz.cacheYear = tz.startYear - 1;
>>>>> ??????? tz.cacheStart = tz.cacheEnd = 0;
>>>>> ??????? return tz;
>>>>> ??? }
>>>>>
>>>>>
>>>>> ...and the JMH benchmark with gc profiling shows that 
>>>>> ZoneId.systemDefault() still manages to get JIT-compiled without 
>>>>> introducing allocation.
>>>>>
>>>>> Even the following (original Venkat's) patch:
>>>>>
>>>>> ??? public Object clone()
>>>>> ??? {
>>>>> ??????? SimpleTimeZone tz = (SimpleTimeZone) super.clone();
>>>>> ??????? tz.invalidateCache();
>>>>> ??????? return tz;
>>>>> ??? }
>>>>>
>>>>> ...does the same and the locking in invalidateCache() is elided 
>>>>> too. Allocation and lock-elision go hand-in-hand. When object 
>>>>> doesn't escape, allocation on heap may be eliminated and locks on 
>>>>> that instance elided.
>>>>>
>>>>> So this is better than synchronizing on the original instance 
>>>>> during .clone() execution as it has potential to avoid locking 
>>>>> overhead.
>>>>>
>>>>> So Venkat, go ahead. My fear was unjustified.
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>
>>>
>>>
>>
> 

From goetz.lindenmaier at sap.com  Tue Nov 28 07:56:23 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 28 Nov 2017 07:56:23 +0000
Subject: Which test groups to run instead of :jdk (8176838)
In-Reply-To: <14806114-7B65-4EDA-BAA1-FEEFC7789C04@oracle.com>
References: <b61c05248fec4dc198e3dbfdece3d16c@sap.com>
 <14806114-7B65-4EDA-BAA1-FEEFC7789C04@oracle.com>
Message-ID: <dfcc58e83d53429d94ed7e616e1f4e61@sap.com>

Hi Shura, 

thanks for your advice!  So we'll run all of them. The number of additional
tests is small enough to handle in case they fail.

Do you mind if I put this advice into a comment in the bug?

Best regards,
  Goetz.

> -----Original Message-----
> From: Alexandre (Shura) Iline [mailto:alexandre.iline at oracle.com]
> Sent: Montag, 27. November 2017 22:56
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: Which test groups to run instead of :jdk (8176838)
> 
> Hi, Goetz.
> 
> :jdk, when created, was supposed to include tests which could be run by full
> JDK, which is, well, all the tests. Over the time there could have been new
> tests added which were not included in the :jdk group.
> 
> In fact, I have just now rolled the repository back to before the 8176838
> change and checked test count in :jdk test group vs. full test suite.
> 
> $jtreg ? -l test/jdk/:jdk
> ?
> Tests found: 8,563
> $jtreg ? -l test/jdk
> ?
> Tests found: 8,583
> 
> The difference consists in these tests:
> 
> > native_sanity/simplenativelauncher/ProgramTest.java
> > native_sanity/simplenativelib2/NativeLib.java
> > native_sanity/simplenativelib/NativeLib.java
> > org/omg/CORBA/OrbPropertiesTest.java
> > sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java
> > sanity/client/SwingSet/src/ButtonDemoTest.java
> > sanity/client/SwingSet/src/ComboBoxDemoTest.java
> > sanity/client/SwingSet/src/DialogDemoTest.java
> > sanity/client/SwingSet/src/ListDemoTest.java
> > sanity/client/SwingSet/src/OptionPaneDemoTest.java
> > sanity/client/SwingSet/src/ProgressBarDemoTest.java
> > sanity/client/SwingSet/src/ScrollPaneDemoTest.java
> > sanity/client/SwingSet/src/SliderDemoTest.java
> > sanity/client/SwingSet/src/SpinnerDemoTest.java
> > sanity/client/SwingSet/src/SplitPaneDemoTest.java
> > sanity/client/SwingSet/src/TabbedPaneDemoTest.java
> > sanity/client/SwingSet/src/TextFieldDemoTest.java
> > sanity/client/SwingSet/src/ToggleButtonDemoTest.java
> > sanity/client/SwingSet/src/TreeDemoTest.java
> > sanity/client/SwingSet/src/WindowDemoTest.java
> 
> Shura
> 
> 
> 
> > On Nov 24, 2017, at 12:46 AM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi,
> >
> > we used to run test target :jdk.
> > This has been removed in 8176838.
> >
> > Which target should we run now to get the same or similar set of tests?
> >
> > Best regards,
> >  Goetz.


From goetz.lindenmaier at sap.com  Tue Nov 28 08:50:22 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 28 Nov 2017 08:50:22 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <5A1C4081.2090107@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <5A1C4081.2090107@oracle.com>
Message-ID: <6d28cb7eaeb24d3daa39f78b97368a08@sap.com>

Hi Kumar, 

Thanks for looking at my change!
 
> I looked at some of the components I maintain, and they look good.
May I ask which these are? So I can account whether all parts have been 
reviewed?

> 1. The local variables/fields don't comply with the coding conventions,
> we have been
>       following in the JDK.
Removed all '_' from fields.  Anything else?  TOOLS_NOT_TO_TEST
is formatted as the similar list in VersionCheck.java.

> 2.  Hmm, someone parked a .ini file in bin directory, later removed,
>       perhaps on windows simply check for .exe ? Should a check exist
>       to verify if file has executable permissions ?"File.canExecute".
> 
>   171     // Returns true if the file is not a tool.
>   172     static boolean notATool(String file) {
>   173         file = file.toLowerCase();
>   174         if (file.endsWith(".dll") ||
>   175             file.endsWith(".map") ||
>   176             file.endsWith(".pdb") ||
>   177             file.equals("server")) {  // server subdir on windows.
>   178             return true;
>   179         }
>   180         return false;
>   181     } 
I anyways wondered why .dll + friends are in the exe directory and 
not in the lib directory.  But a check for executable file is better
than this list. Changed.

> 3.  Typo in comment
Fixed. 

> 4. There is a method to check for isEnglishLocale in TestHelper, perhaps
> use it to have the test bale out in non english locales as early as possible ?
I added a bailout at the beginning of the test. Thanks for the advice!
But thinking about this a @requires englishLocale would be useful here.
 
> 5.  Has this been tested on all platforms ? do you need help testing it ?
Our testing is on ntamd64, linuxppc64, linuxppc64le, linuxs390x, linuxx86_64,
sun_64 and aixppc64. I run the jdk jtreg tests on these platforms. I once ran 
the change with the jdk-hs repo, where we test test/hotspot/jtreg and most jck 
tests.  All passed.
I don't think this is very platform dependent (most differences are
between unix/windows) so this platform coverage should suffice 
I think.

I'll post a new webrev later on.

Best regards,
  Goetz.


> 
> Kumar
> 
> 
> On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > please review this change. I also filed a CSR for this:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >
> > See the webrev for a detailed description of the changes.
> >
> > If required, I'll make break-out changes to be reviewed separately.
> >
> > I had posted a RFR before, but improved the change to
> > give a more complete overview of currently supported flags
> > for the CSR:
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> >
> > Best regards,
> >    Goetz.
> >


From goetz.lindenmaier at sap.com  Tue Nov 28 11:16:45 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 28 Nov 2017 11:16:45 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <5A1C4081.2090107@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <5A1C4081.2090107@oracle.com>
Message-ID: <badb6f618f5b489ca634adb6b545b152@sap.com>

Hi,

I uploaded a new webrev:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.04/

This includes the changes 
  - to jshell requested by Robert
  - to the test as requested by Kumar.

See also incremental patch and the test output including all the
help messages referenced in the webrev.

Best regards,
  Goetz.

> -----Original Message-----
> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com]
> Sent: Montag, 27. November 2017 17:43
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net'
> <compiler-dev at openjdk.java.net>; serviceability-dev (serviceability-
> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Hi,
> 
> I looked at some of the components I maintain, and they look good.
> 
> Wrt. the test:
> 
> 1. The local variables/fields don't comply with the coding conventions,
> we have been
>       following in the JDK.
> 
> 2.  Hmm, someone parked a .ini file in bin directory, later removed,
>       perhaps on windows simply check for .exe ? Should a check exist
>       to verify if file has executable permissions ?"File.canExecute".
> 
>   171     // Returns true if the file is not a tool.
>   172     static boolean notATool(String file) {
>   173         file = file.toLowerCase();
>   174         if (file.endsWith(".dll") ||
>   175             file.endsWith(".map") ||
>   176             file.endsWith(".pdb") ||
>   177             file.equals("server")) {  // server subdir on windows.
>   178             return true;
>   179         }
>   180         return false;
>   181     }
> 
> 
> 3.  Typo in comment
> 
> 201     // Check whether 'flag' appears in 'line' as a word of itself. I must not
> 
> s/I must/It must/
> 
> 
> 4. There is a method to check for isEnglishLocale in TestHelper, perhaps
> use it
> to have the test bale out in non english locales as early as possible ?
> 
> 5.  Has this been tested on all platforms ? do you need help testing it ?
> 
> Kumar
> 
> 
> On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > please review this change. I also filed a CSR for this:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >
> > See the webrev for a detailed description of the changes.
> >
> > If required, I'll make break-out changes to be reviewed separately.
> >
> > I had posted a RFR before, but improved the change to
> > give a more complete overview of currently supported flags
> > for the CSR:
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> >
> > Best regards,
> >    Goetz.
> >


From Alan.Bateman at oracle.com  Tue Nov 28 14:17:18 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 28 Nov 2017 14:17:18 +0000
Subject: Review Request: JDK-8191942: Replace jdeps use of
 jdk.internal.util.jar.VersionedStream with new public API
In-Reply-To: <5a63eef2-3272-1b38-63f6-70cfe30a7cfb@oracle.com>
References: <5a63eef2-3272-1b38-63f6-70cfe30a7cfb@oracle.com>
Message-ID: <569d6f16-0d7c-f289-39b4-431666a50090@oracle.com>

On 28/11/2017 01:50, mandy chung wrote:
> This is a follow-up on JDK-8189611 that defines a new public API to 
> return a stream of versioned entries and to return the real name of a 
> JAR entry.? JDK-8189611 leaves jdeps untouched because jdeps is 
> compiled with the boot JDK.
>
> This patch includes:
> (1) changes the build not to build jdk.jdeps interim module but 
> include com.sun.tools.classfile classes in the CreateSymbol buildtool
> (2) replace the use of internal API with the public APIs defined by 
> JDK-8191942
> (3) remove jdk.internal.util.jar.VersonedStream class
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8191942/webrev.00/
Looks good.

-Alan

From dmitry.chuyko at bell-sw.com  Tue Nov 28 15:35:47 2017
From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko)
Date: Tue, 28 Nov 2017 18:35:47 +0300
Subject: RFR (S): JDK-8191328: Avoid unnecessary overhead in CRC32C
In-Reply-To: <991c7172-d46d-6ea2-73f1-d3ba3ac64811@bell-sw.com>
References: <6f8d38e5-f609-e885-5990-945decbe6e9b@bell-sw.com>
 <0fd60794-b23a-1818-dea4-e72007f7cdd6@oracle.com>
 <67f55a91-2e9d-c401-c213-df93b62188c1@redhat.com>
 <CAHjP37Htvo-C7Q3PmCbujLbratwRJcYpB2puQikghjhWWzObfg@mail.gmail.com>
 <1db026bf-b3eb-2ff6-8132-fbd31f881bbb@redhat.com>
 <991c7172-d46d-6ea2-73f1-d3ba3ac64811@bell-sw.com>
Message-ID: <4cae7cb4-67a6-ea57-41e6-737dda3964a6@bell-sw.com>

Initial version of the patch made worse C1 code because of additionally 
introduced locals, this may be important for client (arm32). I fixed 
this by just coupling xors with brackets. Also I made measurements with 
Graal and AOT. Note, in case of tiered with AOT compiled java.base the 
intrinsic is used if present.

Updated webrev: http://cr.openjdk.java.net/~dchuyko/8191328/webrev.01/
Updated benchmark: 
http://cr.openjdk.java.net/~dchuyko/8191328/webrev.01/CRC32CAltBench.java

Results on my x86 laptop and JDK 10:

Tiered
before? 375 ? 6? ns/op
after?? 334 ? 3? ns/op 11%

Tiered with Graal (JVMCI)
before? 356 ? 7? ns/op
after?? 327 ? 6? ns/op 8%

Tiered with AOT compiled benchmark (non-tiered)
before? 1308 ? 58? ns/op
after?? 1010 ?? 8? ns/op 1.3x

Tiered with -XX:MaxInlineLevel=0
before? 660 ? 4? ns/op
after?? 338 ? 3? ns/op 1.9x

C1
before? 498 ? 4? ns/op
after?? 495 ? 4? ns/op same

Interpreter
before? 40844 ? 333? ns/op
after?? 24777 ? 624? ns/op 1.7x

-Dmitry


On 11/16/2017 07:42 PM, Dmitry Chuyko wrote:
> On 11/15/2017 09:44 PM, Andrew Haley wrote:
>> On 15/11/17 18:38, Vitaly Davidovich wrote:
>>> On Wed, Nov 15, 2017 at 12:40 PM, Andrew Haley <aph at redhat.com> wrote:
>>>> On 15/11/17 15:38, Alan Bateman wrote:
>>>>> Moving the nativeOrder out of the loop make sense but I'm curious 
>>>>> about
>>>>> the context for improving this implementation.
>>>> I wonder about lifting ByteOrder.nativeOrder().? Maybe it fails to
>>>> inline because the method is too large: if that happens, we really
>>>> lose.? I'm not seeing that, though: it seems to be inlined just fine,
>>>> and has no effect.
> Sure, it is the effect of missing inlining. But you can relatively 
> easily break it by your tiered JIT settings. Not sure about AOT. Like 
> (in Hotspot):
> -XX:-Inline, -XX:MaxInlineLevel=0 (no wonder to meet this one in 
> wild), -XX:FreqInlineSize=3, -XX:InlineSmallCode=15..
>>>>
>>>> In any case, this patch doesn't help anything on my test hardware.
>>> Is this with -Xcomp though? That can generate crap code because
>>> there's no profiling information.? Not that -Xcomp should be the way
>>> to test peak performance IMO, but that is the setting that was used I
>>> believe.
> Another noticeable case is -Xint where absolute times of CRC 
> calculation are quite long.
>
> Here is a benchmark that is easier to experiment with (no need to 
> build jdk or to turn off intrinsics):
>
> http://cr.openjdk.java.net/~dchuyko/8191328/CRC32CAltBench.java
>
> Some x86 results:
>
> default tiered
> before? 380.957 ? 11.621? ns/op
> after?? 350.838 ?? 5.149? ns/op
>
> -XX:MaxInlineLevel=0
> before? 656.791 ? 8.216? ns/op
> after? 340.999 ? 2.686? ns/op
>
> -Xint
> before? 36113.441 ? 197.716? ns/op
> after?? 26928.593 ? 133.309? ns/op
>
> -Dmitry
>
>> Shrug; maybe.? We shouldn't mess the code up for -Xcomp.
>>
>


From alexandre.iline at oracle.com  Tue Nov 28 16:59:09 2017
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Tue, 28 Nov 2017 08:59:09 -0800
Subject: Which test groups to run instead of :jdk (8176838)
In-Reply-To: <dfcc58e83d53429d94ed7e616e1f4e61@sap.com>
References: <b61c05248fec4dc198e3dbfdece3d16c@sap.com>
 <14806114-7B65-4EDA-BAA1-FEEFC7789C04@oracle.com>
 <dfcc58e83d53429d94ed7e616e1f4e61@sap.com>
Message-ID: <C7282AD4-65A4-4FED-8C07-B21A369DDFCD@oracle.com>



> On Nov 27, 2017, at 11:56 PM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi Shura, 
> 
> thanks for your advice!  So we'll run all of them. The number of additional
> tests is small enough to handle in case they fail.
> 
> Do you mind if I put this advice into a comment in the bug?

I would appreciate it!

Thanks you.

Shura


> 
> Best regards,
>  Goetz.
> 
>> -----Original Message-----
>> From: Alexandre (Shura) Iline [mailto:alexandre.iline at oracle.com]
>> Sent: Montag, 27. November 2017 22:56
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Cc: core-libs-dev at openjdk.java.net
>> Subject: Re: Which test groups to run instead of :jdk (8176838)
>> 
>> Hi, Goetz.
>> 
>> :jdk, when created, was supposed to include tests which could be run by full
>> JDK, which is, well, all the tests. Over the time there could have been new
>> tests added which were not included in the :jdk group.
>> 
>> In fact, I have just now rolled the repository back to before the 8176838
>> change and checked test count in :jdk test group vs. full test suite.
>> 
>> $jtreg ? -l test/jdk/:jdk
>> ?
>> Tests found: 8,563
>> $jtreg ? -l test/jdk
>> ?
>> Tests found: 8,583
>> 
>> The difference consists in these tests:
>> 
>>> native_sanity/simplenativelauncher/ProgramTest.java
>>> native_sanity/simplenativelib2/NativeLib.java
>>> native_sanity/simplenativelib/NativeLib.java
>>> org/omg/CORBA/OrbPropertiesTest.java
>>> sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java
>>> sanity/client/SwingSet/src/ButtonDemoTest.java
>>> sanity/client/SwingSet/src/ComboBoxDemoTest.java
>>> sanity/client/SwingSet/src/DialogDemoTest.java
>>> sanity/client/SwingSet/src/ListDemoTest.java
>>> sanity/client/SwingSet/src/OptionPaneDemoTest.java
>>> sanity/client/SwingSet/src/ProgressBarDemoTest.java
>>> sanity/client/SwingSet/src/ScrollPaneDemoTest.java
>>> sanity/client/SwingSet/src/SliderDemoTest.java
>>> sanity/client/SwingSet/src/SpinnerDemoTest.java
>>> sanity/client/SwingSet/src/SplitPaneDemoTest.java
>>> sanity/client/SwingSet/src/TabbedPaneDemoTest.java
>>> sanity/client/SwingSet/src/TextFieldDemoTest.java
>>> sanity/client/SwingSet/src/ToggleButtonDemoTest.java
>>> sanity/client/SwingSet/src/TreeDemoTest.java
>>> sanity/client/SwingSet/src/WindowDemoTest.java
>> 
>> Shura
>> 
>> 
>> 
>>> On Nov 24, 2017, at 12:46 AM, Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com> wrote:
>>> 
>>> Hi,
>>> 
>>> we used to run test target :jdk.
>>> This has been removed in 8176838.
>>> 
>>> Which target should we run now to get the same or similar set of tests?
>>> 
>>> Best regards,
>>> Goetz.
> 


From erik.joelsson at oracle.com  Tue Nov 28 17:24:44 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 28 Nov 2017 09:24:44 -0800
Subject: Review Request: JDK-8191942: Replace jdeps use of
 jdk.internal.util.jar.VersionedStream with new public API
In-Reply-To: <5a63eef2-3272-1b38-63f6-70cfe30a7cfb@oracle.com>
References: <5a63eef2-3272-1b38-63f6-70cfe30a7cfb@oracle.com>
Message-ID: <fd2315fc-b360-4280-7a25-5e1960663f8a@oracle.com>

Build change looks good.

/Erik

On 2017-11-27 17:50, mandy chung wrote:
> This is a follow-up on JDK-8189611 that defines a new public API to 
> return a stream of versioned entries and to return the real name of a 
> JAR entry.? JDK-8189611 leaves jdeps untouched because jdeps is 
> compiled with the boot JDK.
>
> This patch includes:
> (1) changes the build not to build jdk.jdeps interim module but 
> include com.sun.tools.classfile classes in the CreateSymbol buildtool
> (2) replace the use of internal API with the public APIs defined by 
> JDK-8191942
> (3) remove jdk.internal.util.jar.VersonedStream class
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8191942/webrev.00/
>
> Thanks
> Mandy


From paul.sandoz at oracle.com  Tue Nov 28 17:50:15 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 28 Nov 2017 09:50:15 -0800
Subject: RFR: jsr166 jdk10 integration wave 6
In-Reply-To: <CA+kOe0-yJ+9EX+U32zHAvMjo9LSJ9rKeKTmsrTskqk5uSBue4w@mail.gmail.com>
References: <CA+kOe0-yJ+9EX+U32zHAvMjo9LSJ9rKeKTmsrTskqk5uSBue4w@mail.gmail.com>
Message-ID: <07D7F68F-1C6C-4B30-BBE8-C678FC3F042A@oracle.com>



> On 27 Nov 2017, at 20:19, Martin Buchholz <martinrb at google.com> wrote:
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/overview.html
> 
> Thanks to D?vid Karnok and Pavel Rappo for help with SubmissionPublisher.
> 
> 8191937: Lost interrupt in AbstractQueuedSynchronizer when tryAcquire methods throw

AbstractQueuedSynchronizerTest.java
?

1296     public void XXXXtestCancelCancelRace() throws InterruptedException {

Suggest ?DISABLED_? prefix rather than ?XXXX?


> 8187947: A race condition in SubmissionPublisher

Need some more time to look at this; it is pleasing to see use of VH.getAndBitwiseOr :-)


> 8191069: Miscellaneous changes imported from jsr166 CVS 2017-12

+1

Paul.


From Roger.Riggs at Oracle.com  Tue Nov 28 18:11:09 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 28 Nov 2017 13:11:09 -0500
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <708689cc-6752-e457-16c7-56c34540e232@Oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
 <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
 <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>
 <e83dd002-89a5-1e03-9593-dc09a1db3d66@oracle.com>
 <6db5bef5-e373-709e-edf6-de2a312020da@gmail.com>
 <c4ddb1aa-c115-560b-419e-6742257a4416@oracle.com>
 <792aa967-d3b0-a461-7647-84a4ece34a72@gmail.com>
 <ce05cb58-0504-4af1-44e5-e7a54295f8e3@oracle.com>
 <8f4033f5-4e3d-6185-4f2c-5a8b46542a04@gmail.com>
 <DM5PR1801MB194509CD70639B9F57562056835C0@DM5PR1801MB1945.namprd18.prod.outlook.com>
 <f2afcaf5-fc77-9671-89b5-b171a289c151@gmail.com>
 <708689cc-6752-e457-16c7-56c34540e232@Oracle.com>
Message-ID: <2e52ce4f-0e4a-9887-b8f0-ecec32fb23a2@Oracle.com>

Hi,

So this thread died out a while ago with some alternatives discussed and 
no clear short term solution.
I'd be happy if someone closer to the ThreadPoolExecutor would be able 
to take another look at the issues.
For the time being, it is lower down on my priorities.

Thanks, Roger

[1] 8190324 ThreadPoolExecutor should not specify a dependency on 
finalization <https://bugs.openjdk.java.net/browse/JDK-8190324>



From huizhe.wang at oracle.com  Tue Nov 28 18:11:56 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 28 Nov 2017 10:11:56 -0800
Subject: RFR (JDK10/JAXP) 8191938: Fix lint warnings in JAXP repo: a few
 Deprecation warrnings and enable -Xlint:all
Message-ID: <5A1DA6EC.6080702@oracle.com>

Hi,

Please review a fix for a few more deprecation warnings. Compiling with 
-Xlint:all showed that these were the last few warnings. We can then 
enable -Xlint:all for the java.xml module.

JBS: https://bugs.openjdk.java.net/browse/JDK-8191938
webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/

Thanks,
Joe

From dl at cs.oswego.edu  Tue Nov 28 18:13:35 2017
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 28 Nov 2017 13:13:35 -0500
Subject: RFR: jsr166 jdk10 integration wave 6
In-Reply-To: <07D7F68F-1C6C-4B30-BBE8-C678FC3F042A@oracle.com>
References: <CA+kOe0-yJ+9EX+U32zHAvMjo9LSJ9rKeKTmsrTskqk5uSBue4w@mail.gmail.com>
 <07D7F68F-1C6C-4B30-BBE8-C678FC3F042A@oracle.com>
Message-ID: <d9defab4-d5b8-d0d9-94af-11c5848c14ed@cs.oswego.edu>

On 11/28/2017 12:50 PM, Paul Sandoz wrote:

> 
>> 8187947: A race condition in SubmissionPublisher
> 
> Need some more time to look at this; it is pleasing to see use of VH.getAndBitwiseOr :-)
> 
> 

Yes; not only is it the technique that allows covering this
borderline-misuse case without slowing down others, but it also
makes for simpler code.
And even on those machines not natively supporting, the internal
CAS or LL/SC loops to implement are likely faster than what we can do
from Java. I plan to update some other j.u.c classes to use it when
applicable (although not immediately).

-Doug


From dl at cs.oswego.edu  Tue Nov 28 18:14:48 2017
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 28 Nov 2017 13:14:48 -0500
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <2e52ce4f-0e4a-9887-b8f0-ecec32fb23a2@Oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
 <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
 <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>
 <e83dd002-89a5-1e03-9593-dc09a1db3d66@oracle.com>
 <6db5bef5-e373-709e-edf6-de2a312020da@gmail.com>
 <c4ddb1aa-c115-560b-419e-6742257a4416@oracle.com>
 <792aa967-d3b0-a461-7647-84a4ece34a72@gmail.com>
 <ce05cb58-0504-4af1-44e5-e7a54295f8e3@oracle.com>
 <8f4033f5-4e3d-6185-4f2c-5a8b46542a04@gmail.com>
 <DM5PR1801MB194509CD70639B9F57562056835C0@DM5PR1801MB1945.namprd18.prod.outlook.com>
 <f2afcaf5-fc77-9671-89b5-b171a289c151@gmail.com>
 <708689cc-6752-e457-16c7-56c34540e232@Oracle.com>
 <2e52ce4f-0e4a-9887-b8f0-ecec32fb23a2@Oracle.com>
Message-ID: <b0d36937-979d-2adb-8d23-fd3332bd634a@cs.oswego.edu>

On 11/28/2017 01:11 PM, Roger Riggs wrote:
> Hi,
> 
> So this thread died out a while ago with some alternatives discussed and
> no clear short term solution.
> I'd be happy if someone closer to the ThreadPoolExecutor would be able
> to take another look at the issues.
> For the time being, it is lower down on my priorities.

I still think the best move is to delete the method, and
tweak the documentation.

-Doug


From joe.darcy at oracle.com  Tue Nov 28 18:19:23 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 28 Nov 2017 10:19:23 -0800
Subject: RFR (JDK10/JAXP) 8191938: Fix lint warnings in JAXP repo: a few
 Deprecation warrnings and enable -Xlint:all
In-Reply-To: <5A1DA6EC.6080702@oracle.com>
References: <5A1DA6EC.6080702@oracle.com>
Message-ID: <eb39d13b-561b-f8ac-48ec-6813ef9684b3@oracle.com>

Hi Joe,

The code changes look fine, but the copyright blocks should *not* be 
updated to include a "@LastModified: Nov 2017" comment.

Cheers,

-Joe


On 11/28/2017 10:11 AM, Joe Wang wrote:
> Hi,
>
> Please review a fix for a few more deprecation warnings. Compiling 
> with -Xlint:all showed that these were the last few warnings. We can 
> then enable -Xlint:all for the java.xml module.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8191938
> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/
>
> Thanks,
> Joe


From lance.andersen at oracle.com  Tue Nov 28 19:50:42 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 28 Nov 2017 14:50:42 -0500
Subject: [10] RFR 8176841: Additional Unicode Language-Tag Extensions
In-Reply-To: <03d177e8-ae43-6692-80f5-34dcc402ae51@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <03d177e8-ae43-6692-80f5-34dcc402ae51@oracle.com>
Message-ID: <DF76AB8D-9A50-4345-B718-736216C547EA@oracle.com>

+1
> On Nov 22, 2017, at 2:04 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> I revised the proposed changes, including java.time changes suggested by Stephen (CSR is still in progress):
> 
> https://bugs.openjdk.java.net/browse/JDK-8191349
> 
> The entire webrev is located at:
> 
> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.05/
> 
> And the diff webrev from the last one is located at:
> 
> http://cr.openjdk.java.net/~naoto/8191349/webrev.04-05/
> 
> I'd appreciate your reviews.
> 
> Naoto
> 
> 
> On 11/9/17 3:34 PM, Naoto Sato wrote:
>> Kindly requesting reviews. I incorporated a fix to the following issue raised by the test team:
>> https://bugs.openjdk.java.net/browse/JDK-8190918
>> Here is the updated webrev:
>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/
>> And the webrev since the one below (to address 8190918):
>> http://cr.openjdk.java.net/~naoto/8190918/
>> Naoto
>> On 11/2/17 2:42 PM, Naoto Sato wrote:
>>> Hello,
>>> 
>>> Please review the proposed changes for the following issues:
>>> 
>>> 8176841: Additional Unicode Language-Tag Extensions
>>> 8189134: New system properties for the default Locale extensions
>>> 
>>> The proposed changeset is located at:
>>> 
>>> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
>>> 
>>> This serves as the implementation of JEP 314.
>>> 
>>> Naoto
>>> 
>>> 
>>> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From huizhe.wang at oracle.com  Tue Nov 28 20:20:50 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 28 Nov 2017 12:20:50 -0800
Subject: RFR (JDK10/JAXP) 8191938: Fix lint warnings in JAXP repo: a few
 Deprecation warrnings and enable -Xlint:all
In-Reply-To: <eb39d13b-561b-f8ac-48ec-6813ef9684b3@oracle.com>
References: <5A1DA6EC.6080702@oracle.com>
 <eb39d13b-561b-f8ac-48ec-6813ef9684b3@oracle.com>
Message-ID: <3a6de692-c260-5a52-1a69-85d33d8d9c39@oracle.com>

Thanks for reviewing!

For the last modified part, we can discuss updating the header script 
offline. Many of the classes have already used this format, I hope 
you're okay with me checking in this changeset.

Thanks,
Joe

On 11/28/2017 10:19 AM, joe darcy wrote:
> Hi Joe,
>
> The code changes look fine, but the copyright blocks should *not* be 
> updated to include a "@LastModified: Nov 2017" comment.
>
> Cheers,
>
> -Joe
>
>
> On 11/28/2017 10:11 AM, Joe Wang wrote:
>> Hi,
>>
>> Please review a fix for a few more deprecation warnings. Compiling 
>> with -Xlint:all showed that these were the last few warnings. We can 
>> then enable -Xlint:all for the java.xml module.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8191938
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/
>>
>> Thanks,
>> Joe
>


From david.holmes at oracle.com  Tue Nov 28 21:05:24 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 29 Nov 2017 07:05:24 +1000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <b0d36937-979d-2adb-8d23-fd3332bd634a@cs.oswego.edu>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
 <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>
 <c4048a30-8652-6b38-94c9-9ac928e5a946@oracle.com>
 <beb47ce6-5c8f-a457-517a-987e0ba95f62@gmail.com>
 <42cdf7a5-de4b-ebfd-2668-905ae15a36fc@oracle.com>
 <982604c2-5f0e-0601-7a5e-2b7e9b555e87@gmail.com>
 <e83dd002-89a5-1e03-9593-dc09a1db3d66@oracle.com>
 <6db5bef5-e373-709e-edf6-de2a312020da@gmail.com>
 <c4ddb1aa-c115-560b-419e-6742257a4416@oracle.com>
 <792aa967-d3b0-a461-7647-84a4ece34a72@gmail.com>
 <ce05cb58-0504-4af1-44e5-e7a54295f8e3@oracle.com>
 <8f4033f5-4e3d-6185-4f2c-5a8b46542a04@gmail.com>
 <DM5PR1801MB194509CD70639B9F57562056835C0@DM5PR1801MB1945.namprd18.prod.outlook.com>
 <f2afcaf5-fc77-9671-89b5-b171a289c151@gmail.com>
 <708689cc-6752-e457-16c7-56c34540e232@Oracle.com>
 <2e52ce4f-0e4a-9887-b8f0-ecec32fb23a2@Oracle.com>
 <b0d36937-979d-2adb-8d23-fd3332bd634a@cs.oswego.edu>
Message-ID: <333087aa-47c8-c0b6-a07a-34fe0a4aeb41@oracle.com>

+1

David

On 29/11/2017 4:14 AM, Doug Lea wrote:
> On 11/28/2017 01:11 PM, Roger Riggs wrote:
>> Hi,
>>
>> So this thread died out a while ago with some alternatives discussed and
>> no clear short term solution.
>> I'd be happy if someone closer to the ThreadPoolExecutor would be able
>> to take another look at the issues.
>> For the time being, it is lower down on my priorities.
> 
> I still think the best move is to delete the method, and
> tweak the documentation.
> 
> -Doug
> 

From martinrb at google.com  Tue Nov 28 21:48:44 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 28 Nov 2017 13:48:44 -0800
Subject: RFR: jsr166 jdk10 integration wave 6
In-Reply-To: <07D7F68F-1C6C-4B30-BBE8-C678FC3F042A@oracle.com>
References: <CA+kOe0-yJ+9EX+U32zHAvMjo9LSJ9rKeKTmsrTskqk5uSBue4w@mail.gmail.com>
 <07D7F68F-1C6C-4B30-BBE8-C678FC3F042A@oracle.com>
Message-ID: <CA+kOe09ncqqLDkKhE8qxkSuAETyLdjwxfaewOhLBLd3v6x0N-w@mail.gmail.com>

On Tue, Nov 28, 2017 at 9:50 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> 1296     public void XXXXtestCancelCancelRace() throws
> InterruptedException {
>
> Suggest ?DISABLED_? prefix rather than ?XXXX?
>

done.

From naoto.sato at oracle.com  Tue Nov 28 23:27:23 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 28 Nov 2017 15:27:23 -0800
Subject: <i18n dev> [10] RFR 8176841: Additional Unicode Language-Tag
 Extensions
In-Reply-To: <CACzrW9AiYD9whXokNvCqyXf_+F+PyNpEXWGSLOqLzv3-NfjW4A@mail.gmail.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <03d177e8-ae43-6692-80f5-34dcc402ae51@oracle.com>
 <CACzrW9A6GAWv=UUAsJ-xHivGp-RkjJvv2riXjYhyaoC-u4TeuQ@mail.gmail.com>
 <f32d69be-effa-d08e-6745-c3beb5b86504@oracle.com>
 <CACzrW9AiYD9whXokNvCqyXf_+F+PyNpEXWGSLOqLzv3-NfjW4A@mail.gmail.com>
Message-ID: <64fbb071-cb5a-5961-e4d6-68db2c4b255b@oracle.com>

I've got some internal comments (two editorial fixes and java time test 
location move) and reflected them to the existing fix. Updated webrevs 
are located at:

http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.07/
http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.06-07/ 
(from v.06)

Naoto

On 11/27/17 1:26 PM, Stephen Colebourne wrote:
> This fixes my previous points, so fine by me. But I am not an OpenJDK reviewer.
> Stephen
> 
> On 27 November 2017 at 20:54, Naoto Sato <naoto.sato at oracle.com> wrote:
>> Thanks, Stephen. Here is the updated webrev:
>>
>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.06/
>>
>> Naoto
>>
>>
>> On 11/23/17 8:13 AM, Stephen Colebourne wrote:
>>>
>>> In DateTimeFormatter line 1508, this would be preferred:
>>>
>>>     return  new DateTimeFormatter(printerParser, locale, ds,
>>> resolverStyle, resolverFields, c, z);
>>>
>>> In DateTimeFormatterBuilder.getLocalizedDateTimePattern() there is no
>>> spec change wrt using "rg".
>>>
>>> Should findRegionOverride() just return a Locale instead of am
>>> Optional<Locale>? It always seems to have an orElse(locale).
>>>
>>> Java-Time tests look good.
>>>
>>> thanks
>>> Stephen
>>>
>>>
>>> On 22 November 2017 at 19:04, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>>
>>>> I revised the proposed changes, including java.time changes suggested by
>>>> Stephen (CSR is still in progress):
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8191349
>>>>
>>>> The entire webrev is located at:
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.05/
>>>>
>>>> And the diff webrev from the last one is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8191349/webrev.04-05/
>>>>
>>>> I'd appreciate your reviews.
>>>>
>>>> Naoto
>>>>
>>>>
>>>>
>>>> On 11/9/17 3:34 PM, Naoto Sato wrote:
>>>>>
>>>>>
>>>>> Kindly requesting reviews. I incorporated a fix to the following issue
>>>>> raised by the test team:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8190918
>>>>>
>>>>> Here is the updated webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/
>>>>>
>>>>> And the webrev since the one below (to address 8190918):
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8190918/
>>>>>
>>>>> Naoto
>>>>>
>>>>>
>>>>>
>>>>> On 11/2/17 2:42 PM, Naoto Sato wrote:
>>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Please review the proposed changes for the following issues:
>>>>>>
>>>>>> 8176841: Additional Unicode Language-Tag Extensions
>>>>>> 8189134: New system properties for the default Locale extensions
>>>>>>
>>>>>> The proposed changeset is located at:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
>>>>>>
>>>>>> This serves as the implementation of JEP 314.
>>>>>>
>>>>>> Naoto
>>>>>>
>>>>>>
>>>>>>
>>>>
>>

From vladimir.kozlov at oracle.com  Tue Nov 28 23:51:46 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 28 Nov 2017 15:51:46 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules
 if -Djvmci.Compiler=graal is in the command line
Message-ID: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>

http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8191788

This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to tests which have 
--limit-modules option. Unfortunately tests start failing on SPARC where Graal 
(jdk.internal.vm.compiler) is not available. JDK-8191653 [2] reversed 8190975 changes to fix that 
problem.

This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM only when Graal is used: when 
it is explicitly specified with -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler 
is true.

I tested the fix with failed tests from JDK-8190975 which are mostly AppCDS tests in 
test/runtime/appcds/jigsaw and also test/jdk/java/lang/String/concat/WithSecurityManager.java

I think this fix may break upgradeable status of Graal (for Oracle Labs version of Graal).
But it should be fine since it is only used with --limit-modules which is not used by Labs.

Thanks,
Vladimir

[1] http://hg.openjdk.java.net/jdk/hs/rev/8deb7919d118
[2] http://hg.openjdk.java.net/jdk/hs/rev/b38d8aadcada

From lance.andersen at oracle.com  Wed Nov 29 00:00:20 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 28 Nov 2017 19:00:20 -0500
Subject: <i18n dev> [10] RFR 8176841: Additional Unicode Language-Tag
 Extensions
In-Reply-To: <64fbb071-cb5a-5961-e4d6-68db2c4b255b@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <03d177e8-ae43-6692-80f5-34dcc402ae51@oracle.com>
 <CACzrW9A6GAWv=UUAsJ-xHivGp-RkjJvv2riXjYhyaoC-u4TeuQ@mail.gmail.com>
 <f32d69be-effa-d08e-6745-c3beb5b86504@oracle.com>
 <CACzrW9AiYD9whXokNvCqyXf_+F+PyNpEXWGSLOqLzv3-NfjW4A@mail.gmail.com>
 <64fbb071-cb5a-5961-e4d6-68db2c4b255b@oracle.com>
Message-ID: <A705C1D1-8C9B-42C9-B9ED-6870559D73D3@oracle.com>

Updates look good :-)
> On Nov 28, 2017, at 6:27 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> I've got some internal comments (two editorial fixes and java time test location move) and reflected them to the existing fix. Updated webrevs are located at:
> 
> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.07/
> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.06-07/ (from v.06)
> 
> Naoto
> 
> On 11/27/17 1:26 PM, Stephen Colebourne wrote:
>> This fixes my previous points, so fine by me. But I am not an OpenJDK reviewer.
>> Stephen
>> On 27 November 2017 at 20:54, Naoto Sato <naoto.sato at oracle.com> wrote:
>>> Thanks, Stephen. Here is the updated webrev:
>>> 
>>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.06/
>>> 
>>> Naoto
>>> 
>>> 
>>> On 11/23/17 8:13 AM, Stephen Colebourne wrote:
>>>> 
>>>> In DateTimeFormatter line 1508, this would be preferred:
>>>> 
>>>>    return  new DateTimeFormatter(printerParser, locale, ds,
>>>> resolverStyle, resolverFields, c, z);
>>>> 
>>>> In DateTimeFormatterBuilder.getLocalizedDateTimePattern() there is no
>>>> spec change wrt using "rg".
>>>> 
>>>> Should findRegionOverride() just return a Locale instead of am
>>>> Optional<Locale>? It always seems to have an orElse(locale).
>>>> 
>>>> Java-Time tests look good.
>>>> 
>>>> thanks
>>>> Stephen
>>>> 
>>>> 
>>>> On 22 November 2017 at 19:04, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>>> 
>>>>> I revised the proposed changes, including java.time changes suggested by
>>>>> Stephen (CSR is still in progress):
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8191349
>>>>> 
>>>>> The entire webrev is located at:
>>>>> 
>>>>> 
>>>>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.05/
>>>>> 
>>>>> And the diff webrev from the last one is located at:
>>>>> 
>>>>> http://cr.openjdk.java.net/~naoto/8191349/webrev.04-05/
>>>>> 
>>>>> I'd appreciate your reviews.
>>>>> 
>>>>> Naoto
>>>>> 
>>>>> 
>>>>> 
>>>>> On 11/9/17 3:34 PM, Naoto Sato wrote:
>>>>>> 
>>>>>> 
>>>>>> Kindly requesting reviews. I incorporated a fix to the following issue
>>>>>> raised by the test team:
>>>>>> 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190918
>>>>>> 
>>>>>> Here is the updated webrev:
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/
>>>>>> 
>>>>>> And the webrev since the one below (to address 8190918):
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~naoto/8190918/
>>>>>> 
>>>>>> Naoto
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 11/2/17 2:42 PM, Naoto Sato wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> Please review the proposed changes for the following issues:
>>>>>>> 
>>>>>>> 8176841: Additional Unicode Language-Tag Extensions
>>>>>>> 8189134: New system properties for the default Locale extensions
>>>>>>> 
>>>>>>> The proposed changeset is located at:
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
>>>>>>> 
>>>>>>> This serves as the implementation of JEP 314.
>>>>>>> 
>>>>>>> Naoto
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From paul.sandoz at oracle.com  Wed Nov 29 00:31:24 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 28 Nov 2017 16:31:24 -0800
Subject: RFR: JDK-8186087: jar tool fails to create a multi-release jar
 when validating nested classes
In-Reply-To: <5A1CD08B.9060906@oracle.com>
References: <5A1CD08B.9060906@oracle.com>
Message-ID: <251A3D7A-7286-4672-A0BC-CE65F6E684CB@oracle.com>

+1

Validator
--
 365     public static void main(String[] args) throws IOException {
 366         System.out.println("validating: " +
 367             new Validator(new Main(System.out, System.err, "validator"),
 368                           new ZipFile(args[0]))
 369                 .validate());
 370     }

Left over from debugging?

Paul.

> On 27 Nov 2017, at 18:57, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi
> 
> Please help review the change for #8186087
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8186087
> webrev: http://cr.openjdk.java.net/~sherman/8186087/webrev
> 
> The proposed change is to handle the "outer class" of a  nested class correctly, instead of simply
> relying on "top level" class. Other than that, a "minor" change is to also stop trying to "validate"
> the non-class/resource entries, for example, if you have a resource "foo" both in the base and
> versioned directory, and with different "content", currently implementation throws a warning
> message, which does not appear to be desired and appropriate.
> 
> There is a "known/open" issue during discussion regarding how to handle the entry that its class
> name does not match its entry name (for example, class p.foo.class is located at bar/p/foo.class,
> currently jar.validator fails the validation with error msg). It appears to be a separate issue, so
> I'm leaving that one of this one for now.
> 
> Thanks,
> Sherman


From stuart.marks at oracle.com  Wed Nov 29 01:37:28 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 28 Nov 2017 17:37:28 -0800
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <4273A1A8-F160-42DB-B13C-7EE041429829@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>
 <CAPkkuSctDbApfZDxi-CcJLYAU0KuvNCg28BYA-rj_9yUeTSd9A@mail.gmail.com>
 <3eeefa3a-fffa-138d-fecb-29e22a00d4c0@oracle.com>
 <4273A1A8-F160-42DB-B13C-7EE041429829@oracle.com>
Message-ID: <1c51d0cb-c714-5880-154b-acba5ff9e7bc@oracle.com>

On 11/17/17 9:43 PM, John Rose wrote:
> Late to the party, but these lines rub me the wrong way:
> 
> @return the new {@code List}
> @return the new {@code Set}
> @return the new {@code Map}
> 
> The word "new" is a loaded term, which usually means
> (or can be easily mistaken to mean) that a new object
> identity is guaranteed.  Thus, "new" shouldn't be used
> to specify the behavior of value-based classes.
> 
> Given that that the underlying objects are of VBCs,
> and that we are encouraging programmers to rely on
> the efficiency of chained copies, it should say something
> like this instead:
> 
> @return a {@code List} containing the same elements as the given collection
> @return a {@code Set} containing the same elements as the given collection
> @return a {@code Map} containing the same mappings as the given map
> 
> (Or even s/return a/return an unmodifiable/.)

OK, per your other message, we'll stick with 
Collectors.toUnmodifiableList/Set/Map, in the hope that in the future we can 
work on improving various incarnations of toList() to have more desirable 
properties.

Meanwhile, I agree that "@return the new {@code List}" is wrong and I'll adjust 
it (respectively, Set and Map).

Another point from our discussions is that the copyOf() methods should get an 
@implNote that says they'll try not to make unnecessary copies.

Also included are some markup changes and a small Set.copyOf implementation 
change suggested upthread.

Final(?) webrev:

     http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.3/

Specdiff:

 
http://cr.openjdk.java.net/~smarks/reviews/8177290/specdiff.3/overview-summary.html

s'marks

From david.holmes at oracle.com  Wed Nov 29 04:57:41 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 29 Nov 2017 14:57:41 +1000
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
Message-ID: <9ca3556e-e8d2-a444-a3ce-5bb4557b5802@oracle.com>

Hi Vladimir,

On 29/11/2017 9:51 AM, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8191788
> 
> This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler 
> to tests which have --limit-modules option. Unfortunately tests start 
> failing on SPARC where Graal (jdk.internal.vm.compiler) is not 
> available. JDK-8191653 [2] reversed 8190975 changes to fix that problem.
> 
> This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM 
> only when Graal is used: when it is explicitly specified with 
> -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is 
> true.

This seems a reasonable way to handle this - at least for now.

Typo:

3379     // and --limit-modules are spcified.

spcified -> specified

Thanks,
David
-----

> I tested the fix with failed tests from JDK-8190975 which are mostly 
> AppCDS tests in test/runtime/appcds/jigsaw and also 
> test/jdk/java/lang/String/concat/WithSecurityManager.java
> 
> I think this fix may break upgradeable status of Graal (for Oracle Labs 
> version of Graal).
> But it should be fine since it is only used with --limit-modules which 
> is not used by Labs.
> 
> Thanks,
> Vladimir
> 
> [1] http://hg.openjdk.java.net/jdk/hs/rev/8deb7919d118
> [2] http://hg.openjdk.java.net/jdk/hs/rev/b38d8aadcada

From stuart.marks at oracle.com  Wed Nov 29 05:21:41 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 28 Nov 2017 21:21:41 -0800
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <31772934.1447977.1511369115414.JavaMail.zimbra@u-pem.fr>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <E3598621-C8A0-4ECA-9EFB-8D8F6381AF18@oracle.com>
 <CACzrW9DibVN=ajMJBSQhZzNdZDWM1LPsXPH6M=ryt28kgZS3ag@mail.gmail.com>
 <31772934.1447977.1511369115414.JavaMail.zimbra@u-pem.fr>
Message-ID: <a42bfadb-d8b6-eaa0-0ca8-995a46eb7c6b@oracle.com>

On 11/22/17 8:45 AM, Remi Forax wrote:
> I think i prefer toImmutableList() than toUnmodifiableList() because the List
> is truly immutable and not an unmodifiable proxy in front of a mutable List
> (like Collections.unmodifiableList() does).

Immutability is like wine.

If you put a spoonful of wine in a barrel full of sewage, you get sewage. If you 
put a spoonful of sewage in a barrel full of wine, you get sewage. 
(Schopenhauer's Law of Entropy)

Similarly, if you add a little immutability to something mutable, you get 
mutability. And if you add a little mutability to something immutable, you get 
mutability.

To get the desired properties of immutability (e.g., thread-safety, or the 
ability to hand around references safely without making defensive copies), it's 
insufficient for a collection to be "immutable"; you also have to make some 
statements about the contents. It's thus more precise to say that a collection 
is unmodifiable, and to provide a clear definition of an unmodifiable collection.

Although unmodifiable collections have been around since the collections 
framework was introduced, oddly enough the concept has never had a good 
definition. The current proposal includes definitions for unmodifiability, 
unmodifiable collections, and unmodifiable views, and it clearly specifies which 
APIs return unmodifiable views and which return unmodifiable collections.

s'marks



From calvin.cheung at oracle.com  Wed Nov 29 06:15:39 2017
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Tue, 28 Nov 2017 22:15:39 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
Message-ID: <5A1E508B.8090709@oracle.com>

Hi Vladimir,

Fix looks good to me.

Could you break up lines #3386 (104 chars) and #3391 (146 chars)?
No need to send another webrev for the above change.

thanks,
Calvin

On 11/28/17, 3:51 PM, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8191788
>
> This is redo of JDK-8190975 [1] fix which added 
> jdk.internal.vm.compiler to tests which have --limit-modules option. 
> Unfortunately tests start failing on SPARC where Graal 
> (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] reversed 
> 8190975 changes to fix that problem.
>
> This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM 
> only when Graal is used: when it is explicitly specified with 
> -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is 
> true.
>
> I tested the fix with failed tests from JDK-8190975 which are mostly 
> AppCDS tests in test/runtime/appcds/jigsaw and also 
> test/jdk/java/lang/String/concat/WithSecurityManager.java
>
> I think this fix may break upgradeable status of Graal (for Oracle 
> Labs version of Graal).
> But it should be fine since it is only used with --limit-modules which 
> is not used by Labs.
>
> Thanks,
> Vladimir
>
> [1] http://hg.openjdk.java.net/jdk/hs/rev/8deb7919d118
> [2] http://hg.openjdk.java.net/jdk/hs/rev/b38d8aadcada

From vladimir.kozlov at oracle.com  Wed Nov 29 07:45:54 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 28 Nov 2017 23:45:54 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <9ca3556e-e8d2-a444-a3ce-5bb4557b5802@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <9ca3556e-e8d2-a444-a3ce-5bb4557b5802@oracle.com>
Message-ID: <3987545f-87ff-5970-c946-381fe03a5a5b@oracle.com>

Thank you, David

On 11/28/17 8:57 PM, David Holmes wrote:
> Hi Vladimir,
> 
> On 29/11/2017 9:51 AM, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8191788
>>
>> This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to tests which have --limit-modules option. 
>> Unfortunately tests start failing on SPARC where Graal (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] 
>> reversed 8190975 changes to fix that problem.
>>
>> This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM only when Graal is used: when it is explicitly 
>> specified with -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is true.
> 
> This seems a reasonable way to handle this - at least for now.
> 
> Typo:
> 
> 3379???? // and --limit-modules are spcified.
> 
> spcified -> specified

Will fix.

Vladimir

> 
> Thanks,
> David
> -----
> 
>> I tested the fix with failed tests from JDK-8190975 which are mostly AppCDS tests in test/runtime/appcds/jigsaw and 
>> also test/jdk/java/lang/String/concat/WithSecurityManager.java
>>
>> I think this fix may break upgradeable status of Graal (for Oracle Labs version of Graal).
>> But it should be fine since it is only used with --limit-modules which is not used by Labs.
>>
>> Thanks,
>> Vladimir
>>
>> [1] http://hg.openjdk.java.net/jdk/hs/rev/8deb7919d118
>> [2] http://hg.openjdk.java.net/jdk/hs/rev/b38d8aadcada

From vladimir.kozlov at oracle.com  Wed Nov 29 07:49:32 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 28 Nov 2017 23:49:32 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <5A1E508B.8090709@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <5A1E508B.8090709@oracle.com>
Message-ID: <6f82dc58-9d91-bba8-16ad-3582036f1f6d@oracle.com>

Thank you, Calvin

On 11/28/17 10:15 PM, Calvin Cheung wrote:
> Hi Vladimir,
> 
> Fix looks good to me.
> 
> Could you break up lines #3386 (104 chars) and #3391 (146 chars)?

I will do that.

Vladimir

> No need to send another webrev for the above change.
> 
> thanks,
> Calvin
> 
> On 11/28/17, 3:51 PM, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8191788
>>
>> This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to tests which have --limit-modules option. 
>> Unfortunately tests start failing on SPARC where Graal (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] 
>> reversed 8190975 changes to fix that problem.
>>
>> This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM only when Graal is used: when it is explicitly 
>> specified with -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is true.
>>
>> I tested the fix with failed tests from JDK-8190975 which are mostly AppCDS tests in test/runtime/appcds/jigsaw and 
>> also test/jdk/java/lang/String/concat/WithSecurityManager.java
>>
>> I think this fix may break upgradeable status of Graal (for Oracle Labs version of Graal).
>> But it should be fine since it is only used with --limit-modules which is not used by Labs.
>>
>> Thanks,
>> Vladimir
>>
>> [1] http://hg.openjdk.java.net/jdk/hs/rev/8deb7919d118
>> [2] http://hg.openjdk.java.net/jdk/hs/rev/b38d8aadcada

From Alan.Bateman at oracle.com  Wed Nov 29 09:05:30 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Nov 2017 09:05:30 +0000
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
Message-ID: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>

On 28/11/2017 23:51, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8191788
>
> This is redo of JDK-8190975 [1] fix which added 
> jdk.internal.vm.compiler to tests which have --limit-modules option. 
> Unfortunately tests start failing on SPARC where Graal 
> (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] reversed 
> 8190975 changes to fix that problem.
>
> This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM 
> only when Graal is used: when it is explicitly specified with 
> -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is 
> true.
>
> I tested the fix with failed tests from JDK-8190975 which are mostly 
> AppCDS tests in test/runtime/appcds/jigsaw and also 
> test/jdk/java/lang/String/concat/WithSecurityManager.java
>
> I think this fix may break upgradeable status of Graal (for Oracle 
> Labs version of Graal).
> But it should be fine since it is only used with --limit-modules which 
> is not used by Labs.
If jdk.internal.vm.compiler is not observable on SPARC then shouldn't 
the tests have `@requires jdk.internal.vm.compiler` and jtreg will skip 
the test on that platform?

Just asking as augmenting the value passed to --limit-modules is very 
strange. It's normal for XX options to augment the set of modules that 
resolved (+EnableJVMCI implies `--add-modules jdk.internal.vm.ci` for 
example) but doing this for --limit-modules suggests the VM is doing 
something to mask an issue with the way that the tests are run.

-Alan

From doug.simon at oracle.com  Wed Nov 29 10:56:44 2017
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 29 Nov 2017 11:56:44 +0100
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
Message-ID: <3BD68E18-134C-4EA8-8861-8BD57C35FA57@oracle.com>



> On 29 Nov 2017, at 10:05, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 28/11/2017 23:51, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8191788
>> 
>> This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to tests which have --limit-modules option. Unfortunately tests start failing on SPARC where Graal (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] reversed 8190975 changes to fix that problem.
>> 
>> This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM only when Graal is used: when it is explicitly specified with -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is true.
>> 
>> I tested the fix with failed tests from JDK-8190975 which are mostly AppCDS tests in test/runtime/appcds/jigsaw and also test/jdk/java/lang/String/concat/WithSecurityManager.java
>> 
>> I think this fix may break upgradeable status of Graal (for Oracle Labs version of Graal).
>> But it should be fine since it is only used with --limit-modules which is not used by Labs.
> If jdk.internal.vm.compiler is not observable on SPARC then shouldn't the tests have `@requires jdk.internal.vm.compiler` and jtreg will skip the test on that platform?
> 
> Just asking as augmenting the value passed to --limit-modules is very strange. It's normal for XX options to augment the set of modules that resolved (+EnableJVMCI implies `--add-modules jdk.internal.vm.ci` for example) but doing this for --limit-modules suggests the VM is doing something to mask an issue with the way that the tests are run.

As much as I understand the issue, I agree. This seems like something that should be addressed in the test(s) instead of in the VM.

-Doug

From david.holmes at oracle.com  Wed Nov 29 11:26:11 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 29 Nov 2017 21:26:11 +1000
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
Message-ID: <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com>

On 29/11/2017 7:05 PM, Alan Bateman wrote:
> On 28/11/2017 23:51, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8191788
>>
>> This is redo of JDK-8190975 [1] fix which added 
>> jdk.internal.vm.compiler to tests which have --limit-modules option. 
>> Unfortunately tests start failing on SPARC where Graal 
>> (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] reversed 
>> 8190975 changes to fix that problem.
>>
>> This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM 
>> only when Graal is used: when it is explicitly specified with 
>> -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is 
>> true.
>>
>> I tested the fix with failed tests from JDK-8190975 which are mostly 
>> AppCDS tests in test/runtime/appcds/jigsaw and also 
>> test/jdk/java/lang/String/concat/WithSecurityManager.java
>>
>> I think this fix may break upgradeable status of Graal (for Oracle 
>> Labs version of Graal).
>> But it should be fine since it is only used with --limit-modules which 
>> is not used by Labs.
> If jdk.internal.vm.compiler is not observable on SPARC then shouldn't 
> the tests have `@requires jdk.internal.vm.compiler` and jtreg will skip 
> the test on that platform?

I didn't know @requires supported modules that way! Even so we'd also 
have to reapply the original fix for JDK-8190975 to update --limit-modules.

> Just asking as augmenting the value passed to --limit-modules is very 
> strange. It's normal for XX options to augment the set of modules that 
> resolved (+EnableJVMCI implies `--add-modules jdk.internal.vm.ci` for 
> example) but doing this for --limit-modules suggests the VM is doing 
> something to mask an issue with the way that the tests are run.

The current approach basically prevents anyone using JVMCI from shooting 
themselves in the foot by setting --limit-modules in a way that excludes 
the jdk.internal.vm.compiler module. In essence we want to ensure that 
if using JVMCI then all the requisite pieces will be available. But 
perhaps we are doing this the wrong way: how do --limit-modules and 
--add-modules combine? We could add jdk.internal.vm.compiler rather than 
expanding the limit-set. But the end result would seem the same.

Thanks,
David

> 
> -Alan

From Alan.Bateman at oracle.com  Wed Nov 29 12:37:50 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Nov 2017 12:37:50 +0000
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
 <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com>
Message-ID: <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com>

On 29/11/2017 11:26, David Holmes wrote:
>
> The current approach basically prevents anyone using JVMCI from 
> shooting themselves in the foot by setting --limit-modules in a way 
> that excludes the jdk.internal.vm.compiler module. In essence we want 
> to ensure that if using JVMCI then all the requisite pieces will be 
> available. But perhaps we are doing this the wrong way: how do 
> --limit-modules and --add-modules combine? We could add 
> jdk.internal.vm.compiler rather than expanding the limit-set. But the 
> end result would seem the same.
The VM shouldn't augment the value specified to --limit-modules so I 
think we need to do back to the original issue and find a better 
solution. Is JDK-8190975 the real issue that we should be looking at? Is 
it just the two tests listed? In the case of BootAppendTests then it can 
check if the module is observable before specifying it to 
--limit-modules when creating the child VM. WithSecurityManager might 
need additional work or maybe it can drop the use of --limit-modules.

As regards using --limit-modules and --add-modules together then it is 
possible, the details are in JEP 261.

-Alan.

From Roger.Riggs at Oracle.com  Wed Nov 29 15:05:53 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 29 Nov 2017 10:05:53 -0500
Subject: <i18n dev> [10] RFR 6354947: [Fmt-*] DecimalFormat ignores
 FieldPosition settings on input, contrary to Javadocs
In-Reply-To: <91cfcd2f-97ba-dda8-eb2d-9c4bd0f05f29@oracle.com>
References: <156741f0-36df-03cb-e30f-e2c41d0fc3ef@oracle.com>
 <91cfcd2f-97ba-dda8-eb2d-9c4bd0f05f29@oracle.com>
Message-ID: <d7bc5240-369f-88f6-8e46-d3e38152c2db@Oracle.com>

Hi Nishit,

The webrev and updates to the javadoc look fine.

However, the summary of the issue does not reflect the issue and implies 
the implementation is wrong;
but it is the javadoc that need clarification.

Please change the issue summary (on both the CSR and the issue) to 
reflect the true cause, something like:

[Fmt-*] Clarify DecimalFormat description of FieldPosition use

Thanks, Roger


On 11/17/2017 7:21 PM, Naoto Sato wrote:
> +1
>
> Naoto
>
> On 11/16/17 10:52 PM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-6354947
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-6354947
>> Webrev: http://cr.openjdk.java.net/~nishjain/6354947/webrev.02/
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191014
>>
>> Fix: Clarified handling of the FieldPosition settings in the 
>> java.text.Format APIs specification.
>>
>> Regards,
>> Nishit Jain


From Roger.Riggs at Oracle.com  Wed Nov 29 15:09:07 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 29 Nov 2017 10:09:07 -0500
Subject: <i18n dev> [10] RFR 8176841: Additional Unicode Language-Tag
 Extensions
In-Reply-To: <A705C1D1-8C9B-42C9-B9ED-6870559D73D3@oracle.com>
References: <5caff010-ef03-b62f-2041-3f57f126ae97@oracle.com>
 <d17ec439-110a-36e5-9575-d79f74592d51@oracle.com>
 <03d177e8-ae43-6692-80f5-34dcc402ae51@oracle.com>
 <CACzrW9A6GAWv=UUAsJ-xHivGp-RkjJvv2riXjYhyaoC-u4TeuQ@mail.gmail.com>
 <f32d69be-effa-d08e-6745-c3beb5b86504@oracle.com>
 <CACzrW9AiYD9whXokNvCqyXf_+F+PyNpEXWGSLOqLzv3-NfjW4A@mail.gmail.com>
 <64fbb071-cb5a-5961-e4d6-68db2c4b255b@oracle.com>
 <A705C1D1-8C9B-42C9-B9ED-6870559D73D3@oracle.com>
Message-ID: <c9008e81-de82-468e-e50f-48f4373221f1@Oracle.com>

+1

Thanks, Roger

On 11/28/2017 7:00 PM, Lance Andersen wrote:
> Updates look good :-)
>> On Nov 28, 2017, at 6:27 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>
>> I've got some internal comments (two editorial fixes and java time test location move) and reflected them to the existing fix. Updated webrevs are located at:
>>
>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.07/
>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.06-07/ (from v.06)
>>
>> Naoto
>>
>> On 11/27/17 1:26 PM, Stephen Colebourne wrote:
>>> This fixes my previous points, so fine by me. But I am not an OpenJDK reviewer.
>>> Stephen
>>> On 27 November 2017 at 20:54, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>> Thanks, Stephen. Here is the updated webrev:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.06/
>>>>
>>>> Naoto
>>>>
>>>>
>>>> On 11/23/17 8:13 AM, Stephen Colebourne wrote:
>>>>> In DateTimeFormatter line 1508, this would be preferred:
>>>>>
>>>>>     return  new DateTimeFormatter(printerParser, locale, ds,
>>>>> resolverStyle, resolverFields, c, z);
>>>>>
>>>>> In DateTimeFormatterBuilder.getLocalizedDateTimePattern() there is no
>>>>> spec change wrt using "rg".
>>>>>
>>>>> Should findRegionOverride() just return a Locale instead of am
>>>>> Optional<Locale>? It always seems to have an orElse(locale).
>>>>>
>>>>> Java-Time tests look good.
>>>>>
>>>>> thanks
>>>>> Stephen
>>>>>
>>>>>
>>>>> On 22 November 2017 at 19:04, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>>>> I revised the proposed changes, including java.time changes suggested by
>>>>>> Stephen (CSR is still in progress):
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8191349
>>>>>>
>>>>>> The entire webrev is located at:
>>>>>>
>>>>>>
>>>>>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.05/
>>>>>>
>>>>>> And the diff webrev from the last one is located at:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~naoto/8191349/webrev.04-05/
>>>>>>
>>>>>> I'd appreciate your reviews.
>>>>>>
>>>>>> Naoto
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/9/17 3:34 PM, Naoto Sato wrote:
>>>>>>>
>>>>>>> Kindly requesting reviews. I incorporated a fix to the following issue
>>>>>>> raised by the test team:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190918
>>>>>>>
>>>>>>> Here is the updated webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918/webrev.04/
>>>>>>>
>>>>>>> And the webrev since the one below (to address 8190918):
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~naoto/8190918/
>>>>>>>
>>>>>>> Naoto
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 11/2/17 2:42 PM, Naoto Sato wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review the proposed changes for the following issues:
>>>>>>>>
>>>>>>>> 8176841: Additional Unicode Language-Tag Extensions
>>>>>>>> 8189134: New system properties for the default Locale extensions
>>>>>>>>
>>>>>>>> The proposed changeset is located at:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~naoto/8176841/webrev.03/
>>>>>>>>
>>>>>>>> This serves as the implementation of JEP 314.
>>>>>>>>
>>>>>>>> Naoto
>>>>>>>>
>>>>>>>>
>>>>>>>>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>


From mandy.chung at oracle.com  Wed Nov 29 16:15:18 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 29 Nov 2017 08:15:18 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
 <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com>
 <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com>
Message-ID: <5b1d87ec-5386-59fe-3547-3d741297db69@oracle.com>



On 11/29/17 4:37 AM, Alan Bateman wrote:
> On 29/11/2017 11:26, David Holmes wrote:
>>
>> The current approach basically prevents anyone using JVMCI from 
>> shooting themselves in the foot by setting --limit-modules in a way 
>> that excludes the jdk.internal.vm.compiler module. In essence we want 
>> to ensure that if using JVMCI then all the requisite pieces will be 
>> available. But perhaps we are doing this the wrong way: how do 
>> --limit-modules and --add-modules combine? We could add 
>> jdk.internal.vm.compiler rather than expanding the limit-set. But the 
>> end result would seem the same.
> The VM shouldn't augment the value specified to --limit-modules so I 
> think we need to do back to the original issue and find a better 
> solution. Is JDK-8190975 the real issue that we should be looking at? 
> Is it just the two tests listed? In the case of BootAppendTests then 
> it can check if the module is observable before specifying it to 
> --limit-modules when creating the child VM. WithSecurityManager might 
> need additional work or maybe it can drop the use of --limit-modules.
>
I agree that augmenting --limit-modules doesn't seem the right solution 
here.

Would @modules jdk.internal.vm.compiler be a temporary workaround so 
that this test will not run on SPARC where the module is not present?

Mandy



From vladimir.kozlov at oracle.com  Wed Nov 29 17:02:05 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 29 Nov 2017 09:02:05 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
Message-ID: <009a8c21-f0e6-9986-82b3-ec77454a6baf@oracle.com>

Hi Alan,

On 11/29/17 1:05 AM, Alan Bateman wrote:
> On 28/11/2017 23:51, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8191788
>>
>> This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to tests which have --limit-modules option. 
>> Unfortunately tests start failing on SPARC where Graal (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] 
>> reversed 8190975 changes to fix that problem.
>>
>> This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM only when Graal is used: when it is explicitly 
>> specified with -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is true.
>>
>> I tested the fix with failed tests from JDK-8190975 which are mostly AppCDS tests in test/runtime/appcds/jigsaw and 
>> also test/jdk/java/lang/String/concat/WithSecurityManager.java
>>
>> I think this fix may break upgradeable status of Graal (for Oracle Labs version of Graal).
>> But it should be fine since it is only used with --limit-modules which is not used by Labs.
> If jdk.internal.vm.compiler is not observable on SPARC then shouldn't the tests have `@requires 
> jdk.internal.vm.compiler` and jtreg will skip the test on that platform?

No, these testes (listed above) has nothing to do with Graal. So we can't guard them based on presence of Graal.
That was the problem and that is why original 8190975 fix had to be reversed.

> 
> Just asking as augmenting the value passed to --limit-modules is very strange. It's normal for XX options to augment the 
> set of modules that resolved (+EnableJVMCI implies `--add-modules jdk.internal.vm.ci` for example) but doing this for 
> --limit-modules suggests the VM is doing something to mask an issue with the way that the tests are run.

Just reminder - Graal is upgradeable module [1]. We can't do for it what we do for JVMCI as you pointed.

[1] https://bugs.openjdk.java.net/browse/JDK-8177845

Thanks,
Vladimir

> 
> -Alan

From vladimir.kozlov at oracle.com  Wed Nov 29 17:27:29 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 29 Nov 2017 09:27:29 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
 <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com>
 <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com>
Message-ID: <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com>

On 11/29/17 4:37 AM, Alan Bateman wrote:
> On 29/11/2017 11:26, David Holmes wrote:
>>
>> The current approach basically prevents anyone using JVMCI from shooting themselves in the foot by setting 
>> --limit-modules in a way that excludes the jdk.internal.vm.compiler module. In essence we want to ensure that if using 
>> JVMCI then all the requisite pieces will be available. But perhaps we are doing this the wrong way: how do 
>> --limit-modules and --add-modules combine? We could add jdk.internal.vm.compiler rather than expanding the limit-set. 
>> But the end result would seem the same.
> The VM shouldn't augment the value specified to --limit-modules so I think we need to do back to the original issue and 
> find a better solution. Is JDK-8190975 the real issue that we should be looking at? Is it just the two tests listed? In 
> the case of BootAppendTests then it can check if the module is observable before specifying it to --limit-modules when 
> creating the child VM. WithSecurityManager might need additional work or maybe it can drop the use of --limit-modules.

There are more AppCDS tests which failed too. Originally they we in closed repo and not listed. But now they are in open:

http://hg.openjdk.java.net/jdk/hs/file/461e9c898e80/test/hotspot/jtreg/runtime/appcds/jigsaw

16 tests.

> 
> As regards using --limit-modules and --add-modules together then it is possible, the details are in JEP 261.

I tried to add jdk.internal.vm.compiler to --add-modules instead of --limit-modules. But it fails because it will 
require to add all Graal's "required" modules too:

http://hg.openjdk.java.net/jdk/hs/file/461e9c898e80/src/jdk.internal.vm.compiler/share/classes/module-info.java#l26

If it acceptable I can do that instead.

But I insist that we should do that in JVM. I don't want to skip tests on SPARC which have nothing to do with Graal.

Thanks,
Vladimir

> 
> -Alan.

From xueming.shen at oracle.com  Wed Nov 29 18:01:27 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 29 Nov 2017 10:01:27 -0800
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
In-Reply-To: <f9aa9a4b-d399-14e1-d38e-81eec3e0ab9d@oracle.com>
References: <5A0E4703.3040409@oracle.com>
 <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>
 <5A0F13FF.8090406@oracle.com>
 <1c71e540-88a2-4f6f-5f2b-06b62b955df7@oracle.com>
 <5A131E90.6090509@oracle.com>
 <BE9EE092-1BDD-4A34-A8CF-C9F93094D3DE@oracle.com>
 <5A139662.2030105@oracle.com>
 <f9aa9a4b-d399-14e1-d38e-81eec3e0ab9d@oracle.com>
Message-ID: <5A1EF5F7.1030303@oracle.com>

On 11/27/17, 5:43 PM, mandy chung wrote:
>
>
> On 11/20/17 6:58 PM, Xueming Shen wrote:
>>
>> http://cr.openjdk.java.net/~sherman/8189611/webrev
>>
> Just passing comments.
> 140      * that {@link getName()} returns.
>
> should be #getName().  There are a couple other @link missing #.
> src/java.base/share/classes/module-info.java
>     line 214: the semi-colon is missing.   It didn't fail the 
> compilation because gensrc/java.base/module-info.java is generated to 
> append the OS-specific module declaration and the build tool appends 
> the semi-colon.  The build tool should catch this.
>
Thanks Mandy!

webrev has been updated accordingly as suggested. now wait for the csr.

-Sherman

From martinrb at google.com  Wed Nov 29 18:09:49 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 29 Nov 2017 10:09:49 -0800
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <a42bfadb-d8b6-eaa0-0ca8-995a46eb7c6b@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <E3598621-C8A0-4ECA-9EFB-8D8F6381AF18@oracle.com>
 <CACzrW9DibVN=ajMJBSQhZzNdZDWM1LPsXPH6M=ryt28kgZS3ag@mail.gmail.com>
 <31772934.1447977.1511369115414.JavaMail.zimbra@u-pem.fr>
 <a42bfadb-d8b6-eaa0-0ca8-995a46eb7c6b@oracle.com>
Message-ID: <CA+kOe08YikYjj08ifh_03pQXstvP6MW=CKruPmckG_EgeTUdCw@mail.gmail.com>

Guava's "immutable collections" are very popular
https://github.com/google/guava/wiki/ImmutableCollectionsExplained
and it's not a good idea to fight their advertised notion of "immutable".

No generic container class can promise s'marks-style immutability (until
valhalla perhaps?) so it's not that useful a concept in this domain.
We like to think of Optional as an immutable value based class but you
can't stop anyone who really wants to mutate the contained element from
creating an Optional<AtomicReference<Object>>

We could do a better job of clarifying consequences of element mutation.
E.g. do we ever say that hash based collections/maps are broken if elements
are ever mutated in such a way that their hash code changes while they are
in the collection/map?

From robert.field at oracle.com  Wed Nov 29 18:31:16 2017
From: robert.field at oracle.com (Robert Field)
Date: Wed, 29 Nov 2017 10:31:16 -0800
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <badb6f618f5b489ca634adb6b545b152@sap.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <5A1C4081.2090107@oracle.com> <badb6f618f5b489ca634adb6b545b152@sap.com>
Message-ID: <9F5BAA92-7186-4046-B67C-61FBFF540497@oracle.com>

Thumbs up for JShell changes.

-Robert

> On Nov 28, 2017, at 3:16 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi,
> 
> I uploaded a new webrev:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.04/
> 
> This includes the changes 
>  - to jshell requested by Robert
>  - to the test as requested by Kumar.
> 
> See also incremental patch and the test output including all the
> help messages referenced in the webrev.
> 
> Best regards,
>  Goetz.
> 
>> -----Original Message-----
>> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com]
>> Sent: Montag, 27. November 2017 17:43
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Cc: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net'
>> <compiler-dev at openjdk.java.net>; serviceability-dev (serviceability-
>> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
>> 
>> Hi,
>> 
>> I looked at some of the components I maintain, and they look good.
>> 
>> Wrt. the test:
>> 
>> 1. The local variables/fields don't comply with the coding conventions,
>> we have been
>>      following in the JDK.
>> 
>> 2.  Hmm, someone parked a .ini file in bin directory, later removed,
>>      perhaps on windows simply check for .exe ? Should a check exist
>>      to verify if file has executable permissions ?"File.canExecute".
>> 
>>  171     // Returns true if the file is not a tool.
>>  172     static boolean notATool(String file) {
>>  173         file = file.toLowerCase();
>>  174         if (file.endsWith(".dll") ||
>>  175             file.endsWith(".map") ||
>>  176             file.endsWith(".pdb") ||
>>  177             file.equals("server")) {  // server subdir on windows.
>>  178             return true;
>>  179         }
>>  180         return false;
>>  181     }
>> 
>> 
>> 3.  Typo in comment
>> 
>> 201     // Check whether 'flag' appears in 'line' as a word of itself. I must not
>> 
>> s/I must/It must/
>> 
>> 
>> 4. There is a method to check for isEnglishLocale in TestHelper, perhaps
>> use it
>> to have the test bale out in non english locales as early as possible ?
>> 
>> 5.  Has this been tested on all platforms ? do you need help testing it ?
>> 
>> Kumar
>> 
>> 
>> On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>> 
>>> please review this change. I also filed a CSR for this:
>>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
>> helpMessage/webrev.02/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
>>> 
>>> See the webrev for a detailed description of the changes.
>>> 
>>> If required, I'll make break-out changes to be reviewed separately.
>>> 
>>> I had posted a RFR before, but improved the change to
>>> give a more complete overview of currently supported flags
>>> for the CSR:
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
>> October/028615.html
>>> 
>>> Best regards,
>>>   Goetz.
>>> 
> 


From paul.sandoz at oracle.com  Wed Nov 29 18:43:29 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 29 Nov 2017 10:43:29 -0800
Subject: RFR: jsr166 jdk10 integration wave 6
In-Reply-To: <CA+kOe0-yJ+9EX+U32zHAvMjo9LSJ9rKeKTmsrTskqk5uSBue4w@mail.gmail.com>
References: <CA+kOe0-yJ+9EX+U32zHAvMjo9LSJ9rKeKTmsrTskqk5uSBue4w@mail.gmail.com>
Message-ID: <DCFB498A-F7A2-4744-8728-61B80C1433AB@oracle.com>



> On 27 Nov 2017, at 20:19, Martin Buchholz <martinrb at google.com> wrote:
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/overview.html <http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/overview.html>
> 
> Thanks to D?vid Karnok and Pavel Rappo for help with SubmissionPublisher.
> 
> 8191937: Lost interrupt in AbstractQueuedSynchronizer when tryAcquire methods throw
> 8187947: A race condition in SubmissionPublisher

Hard to review by eyeballing code but it looks good to me.


SubmissionPublisher
--

1004         // Order-sensitive field declarations
Is this still relevant with the use of @Contended on the demand/waiting fields of BufferedSubscription and periodic updates?


  81  * <p>A single SubmissionPublisher may be shared among multiple
  82  * sources. Actions in a source thread prior to publishing an item or
  83  * issuing a signal <a href="package-summary.html#MemoryVisibility">
  84  * <i>happen-before</i></a> actions subsequent to the corresponding
  85  * access by each subscriber. But reported estimates of lag and demand
  86  * are designed for use in monitoring, not for synchronization
  87  * control, and may reflect stale or inaccurate views of progress.
We probably need a CSR for this.

Is ?corresponding access by each subscriber? referring to access of the published item by each subscriber?

Paul.

> 8191069: Miscellaneous changes imported from jsr166 CVS 2017-12


From huizhe.wang at oracle.com  Wed Nov 29 18:58:35 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 29 Nov 2017 10:58:35 -0800
Subject: RFR (JDK10/JAXP) 8191938: Fix lint warnings in JAXP repo: a few
 Deprecation warrnings and enable -Xlint:all
In-Reply-To: <eb39d13b-561b-f8ac-48ec-6813ef9684b3@oracle.com>
References: <5A1DA6EC.6080702@oracle.com>
 <eb39d13b-561b-f8ac-48ec-6813ef9684b3@oracle.com>
Message-ID: <5A1F035B.7060900@oracle.com>

Hi Joe,

I moved the LastModified to the bottom of the class comment block. 
Please let me know what you think:
http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/index.html

Thanks,
Joe

On 11/28/17, 10:19 AM, joe darcy wrote:
> Hi Joe,
>
> The code changes look fine, but the copyright blocks should *not* be 
> updated to include a "@LastModified: Nov 2017" comment.
>
> Cheers,
>
> -Joe
>
>
> On 11/28/2017 10:11 AM, Joe Wang wrote:
>> Hi,
>>
>> Please review a fix for a few more deprecation warnings. Compiling 
>> with -Xlint:all showed that these were the last few warnings. We can 
>> then enable -Xlint:all for the java.xml module.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8191938
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/
>>
>> Thanks,
>> Joe
>

From joe.darcy at oracle.com  Wed Nov 29 19:45:03 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 29 Nov 2017 11:45:03 -0800
Subject: RFR (JDK10/JAXP) 8191938: Fix lint warnings in JAXP repo: a few
 Deprecation warrnings and enable -Xlint:all
In-Reply-To: <5A1F035B.7060900@oracle.com>
References: <5A1DA6EC.6080702@oracle.com>
 <eb39d13b-561b-f8ac-48ec-6813ef9684b3@oracle.com>
 <5A1F035B.7060900@oracle.com>
Message-ID: <37af36a2-253f-344b-972f-3f34c96b9625@oracle.com>

Hi Joe,

The new version looks fine to me; thanks,

-Joe


On 11/29/2017 10:58 AM, Joe Wang wrote:
> Hi Joe,
>
> I moved the LastModified to the bottom of the class comment block. 
> Please let me know what you think:
> http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/index.html
>
> Thanks,
> Joe
>
> On 11/28/17, 10:19 AM, joe darcy wrote:
>> Hi Joe,
>>
>> The code changes look fine, but the copyright blocks should *not* be 
>> updated to include a "@LastModified: Nov 2017" comment.
>>
>> Cheers,
>>
>> -Joe
>>
>>
>> On 11/28/2017 10:11 AM, Joe Wang wrote:
>>> Hi,
>>>
>>> Please review a fix for a few more deprecation warnings. Compiling 
>>> with -Xlint:all showed that these were the last few warnings. We can 
>>> then enable -Xlint:all for the java.xml module.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8191938
>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/
>>>
>>> Thanks,
>>> Joe
>>


From jiangli.zhou at oracle.com  Wed Nov 29 19:46:55 2017
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Wed, 29 Nov 2017 11:46:55 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
 <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com>
 <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com>
 <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com>
Message-ID: <9053DF41-2560-437B-B374-1DC8587AB2F5@oracle.com>


> On Nov 29, 2017, at 9:27 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> On 11/29/17 4:37 AM, Alan Bateman wrote:
>> On 29/11/2017 11:26, David Holmes wrote:
>>> 
>>> The current approach basically prevents anyone using JVMCI from shooting themselves in the foot by setting --limit-modules in a way that excludes the jdk.internal.vm.compiler module. In essence we want to ensure that if using JVMCI then all the requisite pieces will be available. But perhaps we are doing this the wrong way: how do --limit-modules and --add-modules combine? We could add jdk.internal.vm.compiler rather than expanding the limit-set. But the end result would seem the same.
>> The VM shouldn't augment the value specified to --limit-modules so I think we need to do back to the original issue and find a better solution. Is JDK-8190975 the real issue that we should be looking at? Is it just the two tests listed? In the case of BootAppendTests then it can check if the module is observable before specifying it to --limit-modules when creating the child VM. WithSecurityManager might need additional work or maybe it can drop the use of --limit-modules.
> 
> There are more AppCDS tests which failed too. Originally they we in closed repo and not listed. But now they are in open:
> 
> http://hg.openjdk.java.net/jdk/hs/file/461e9c898e80/test/hotspot/jtreg/runtime/appcds/jigsaw
> 
> 16 tests.
> 
>> As regards using --limit-modules and --add-modules together then it is possible, the details are in JEP 261.
> 
> I tried to add jdk.internal.vm.compiler to --add-modules instead of --limit-modules. But it fails because it will require to add all Graal's "required" modules too:
> 
> http://hg.openjdk.java.net/jdk/hs/file/461e9c898e80/src/jdk.internal.vm.compiler/share/classes/module-info.java#l26
> 
> If it acceptable I can do that instead.
> 
> But I insist that we should do that in JVM. I don't want to skip tests on SPARC which have nothing to do with Graal.

I agree with Vladimir. Skipping these tests on SPARC is not applaudable in this case as they are not Graal specific tests.

Thanks,
Jiangli

> 
> Thanks,
> Vladimir
> 
>> -Alan.


From jiangli.zhou at oracle.com  Wed Nov 29 19:46:55 2017
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Wed, 29 Nov 2017 11:46:55 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
 <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com>
 <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com>
 <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com>
Message-ID: <28EEE53F-D02D-432C-B2AC-D88EE45D8FE4@oracle.com>


> On Nov 29, 2017, at 9:27 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> On 11/29/17 4:37 AM, Alan Bateman wrote:
>> On 29/11/2017 11:26, David Holmes wrote:
>>> 
>>> The current approach basically prevents anyone using JVMCI from shooting themselves in the foot by setting --limit-modules in a way that excludes the jdk.internal.vm.compiler module. In essence we want to ensure that if using JVMCI then all the requisite pieces will be available. But perhaps we are doing this the wrong way: how do --limit-modules and --add-modules combine? We could add jdk.internal.vm.compiler rather than expanding the limit-set. But the end result would seem the same.
>> The VM shouldn't augment the value specified to --limit-modules so I think we need to do back to the original issue and find a better solution. Is JDK-8190975 the real issue that we should be looking at? Is it just the two tests listed? In the case of BootAppendTests then it can check if the module is observable before specifying it to --limit-modules when creating the child VM. WithSecurityManager might need additional work or maybe it can drop the use of --limit-modules.
> 
> There are more AppCDS tests which failed too. Originally they we in closed repo and not listed. But now they are in open:
> 
> http://hg.openjdk.java.net/jdk/hs/file/461e9c898e80/test/hotspot/jtreg/runtime/appcds/jigsaw
> 
> 16 tests.
> 
>> As regards using --limit-modules and --add-modules together then it is possible, the details are in JEP 261.
> 
> I tried to add jdk.internal.vm.compiler to --add-modules instead of --limit-modules. But it fails because it will require to add all Graal's "required" modules too:
> 
> http://hg.openjdk.java.net/jdk/hs/file/461e9c898e80/src/jdk.internal.vm.compiler/share/classes/module-info.java#l26
> 
> If it acceptable I can do that instead.
> 
> But I insist that we should do that in JVM. I don't want to skip tests on SPARC which have nothing to do with Graal.

I agree with Vladimir. Skipping these tests on SPARC is not applaudable in this case as they are not Graal specific tests.

Thanks,
Jiangli

> 
> Thanks,
> Vladimir
> 
>> -Alan.


From aleksej.efimov at oracle.com  Wed Nov 29 19:48:49 2017
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Wed, 29 Nov 2017 19:48:49 +0000
Subject: [10] RFR: 8186441: Change of behavior in the getMessage () method of
 the SOAPMessageContextImpl class
Message-ID: <860f18bc-fafa-eaf1-e263-0f6d27a9d776@oracle.com>

Hi,

Can I, please, ask for assistance with reviewing the JDK-8186441 fix [1]?

Problem description:
In JDK9 we've fixed SAAJ bug in JDK:
 ??? https://bugs.openjdk.java.net/browse/JDK-8159058
And this fix caused JDK-8186441 regression that resulted in breaking the 
namespace definitions in SOAP elements, i.e. the namespace definitions 
were added to SOAP body or to the parent elements.

I'm aware that we're going to remove JAXWS and other EE modules in 
JDK10, but I still would like to fix this bug since it is a regression 
in existing code and JDK8 backport is also required for this issue.

Will submit the same source fix to saaj-ri project [2] too.

Solution:
Fix the implementation of SaajStaxWriter::DeferredElement to add 
namespaces declaration to current element instead of parent.

Webrev:
http://cr.openjdk.java.net/~aefimov/8186441/10/00/index.html

Testing:
Modified regression test and? XML/JAXWS? JCK tests show no failures with 
the fix


With Best Regards,
Aleksei

[1] https://bugs.openjdk.java.net/browse/JDK-8186441
[2] https://github.com/javaee/metro-saaj


From Roger.Riggs at Oracle.com  Wed Nov 29 19:49:56 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 29 Nov 2017 14:49:56 -0500
Subject: RFR (JDK10/JAXP) 8191938: Fix lint warnings in JAXP repo: a few
 Deprecation warrnings and enable -Xlint:all
In-Reply-To: <37af36a2-253f-344b-972f-3f34c96b9625@oracle.com>
References: <5A1DA6EC.6080702@oracle.com>
 <eb39d13b-561b-f8ac-48ec-6813ef9684b3@oracle.com>
 <5A1F035B.7060900@oracle.com>
 <37af36a2-253f-344b-972f-3f34c96b9625@oracle.com>
Message-ID: <9c95e215-b32f-b8fb-6081-3449da53cd25@Oracle.com>

+1

On 11/29/2017 2:45 PM, joe darcy wrote:
> Hi Joe,
>
> The new version looks fine to me; thanks,
>
> -Joe
>
>
> On 11/29/2017 10:58 AM, Joe Wang wrote:
>> Hi Joe,
>>
>> I moved the LastModified to the bottom of the class comment block. 
>> Please let me know what you think:
>> http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/index.html
>>
>> Thanks,
>> Joe
>>
>> On 11/28/17, 10:19 AM, joe darcy wrote:
>>> Hi Joe,
>>>
>>> The code changes look fine, but the copyright blocks should *not* be 
>>> updated to include a "@LastModified: Nov 2017" comment.
>>>
>>> Cheers,
>>>
>>> -Joe
>>>
>>>
>>> On 11/28/2017 10:11 AM, Joe Wang wrote:
>>>> Hi,
>>>>
>>>> Please review a fix for a few more deprecation warnings. Compiling 
>>>> with -Xlint:all showed that these were the last few warnings. We 
>>>> can then enable -Xlint:all for the java.xml module.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8191938
>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/
>>>>
>>>> Thanks,
>>>> Joe
>>>
>


From huizhe.wang at oracle.com  Wed Nov 29 19:53:35 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 29 Nov 2017 11:53:35 -0800
Subject: RFR (JDK10/JAXP) 8191938: Fix lint warnings in JAXP repo: a few
 Deprecation warrnings and enable -Xlint:all
In-Reply-To: <9c95e215-b32f-b8fb-6081-3449da53cd25@Oracle.com>
References: <5A1DA6EC.6080702@oracle.com>
 <eb39d13b-561b-f8ac-48ec-6813ef9684b3@oracle.com>
 <5A1F035B.7060900@oracle.com>
 <37af36a2-253f-344b-972f-3f34c96b9625@oracle.com>
 <9c95e215-b32f-b8fb-6081-3449da53cd25@Oracle.com>
Message-ID: <5A1F103F.7080602@oracle.com>

Thanks Joe, Roger!

On 11/29/17, 11:49 AM, Roger Riggs wrote:
> +1
>
> On 11/29/2017 2:45 PM, joe darcy wrote:
>> Hi Joe,
>>
>> The new version looks fine to me; thanks,
>>
>> -Joe
>>
>>
>> On 11/29/2017 10:58 AM, Joe Wang wrote:
>>> Hi Joe,
>>>
>>> I moved the LastModified to the bottom of the class comment block. 
>>> Please let me know what you think:
>>> http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/index.html
>>>
>>> Thanks,
>>> Joe
>>>
>>> On 11/28/17, 10:19 AM, joe darcy wrote:
>>>> Hi Joe,
>>>>
>>>> The code changes look fine, but the copyright blocks should *not* 
>>>> be updated to include a "@LastModified: Nov 2017" comment.
>>>>
>>>> Cheers,
>>>>
>>>> -Joe
>>>>
>>>>
>>>> On 11/28/2017 10:11 AM, Joe Wang wrote:
>>>>> Hi,
>>>>>
>>>>> Please review a fix for a few more deprecation warnings. Compiling 
>>>>> with -Xlint:all showed that these were the last few warnings. We 
>>>>> can then enable -Xlint:all for the java.xml module.
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8191938
>>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>
>>
>

From lance.andersen at oracle.com  Wed Nov 29 20:12:47 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 29 Nov 2017 15:12:47 -0500
Subject: [10] RFR: 8186441: Change of behavior in the getMessage () method
 of the SOAPMessageContextImpl class
In-Reply-To: <860f18bc-fafa-eaf1-e263-0f6d27a9d776@oracle.com>
References: <860f18bc-fafa-eaf1-e263-0f6d27a9d776@oracle.com>
Message-ID: <CD936AEC-642B-42DA-9BD5-B7EEE135273C@oracle.com>

Hi Aleks,

The changes look reasonable

Best
Lance
> On Nov 29, 2017, at 2:48 PM, Aleks Efimov <aleksej.efimov at oracle.com> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8159058 <https://bugs.openjdk.java.net/browse/JDK-8159058>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From aleksej.efimov at oracle.com  Wed Nov 29 20:13:43 2017
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Wed, 29 Nov 2017 20:13:43 +0000
Subject: [10] RFR: 8186441: Change of behavior in the getMessage () method
 of the SOAPMessageContextImpl class
In-Reply-To: <CD936AEC-642B-42DA-9BD5-B7EEE135273C@oracle.com>
References: <860f18bc-fafa-eaf1-e263-0f6d27a9d776@oracle.com>
 <CD936AEC-642B-42DA-9BD5-B7EEE135273C@oracle.com>
Message-ID: <0c7217d1-f664-ca3e-6dab-04fcc9fcaf04@oracle.com>

Thank you Lance!

Best,
Aleksei

On 11/29/2017 08:12 PM, Lance Andersen wrote:
> Hi Aleks,
>
> The changes look reasonable
>
> Best
> Lance
>> On Nov 29, 2017, at 2:48 PM, Aleks Efimov <aleksej.efimov at oracle.com 
>> <mailto:aleksej.efimov at oracle.com>> wrote:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8159058
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>


From paul.sandoz at oracle.com  Wed Nov 29 20:15:44 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 29 Nov 2017 12:15:44 -0800
Subject: RFR 8186961 Class.getFields() does not return fields of previously
 visited super interfaces/classes.
Message-ID: <929496D6-A4B3-4EF2-BDCB-D2504C1BECE3@oracle.com>

Hi,

Please review:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186961-iface-static-fields-get/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186961-iface-static-fields-get/webrev/>

There is a bug lurking, perhaps for a while, where diamond patterns for interface hierarchies can result in the incorrect reporting of fields when using reflection, see the test case.

Since reflection data is cached i don?t see an advantage to retaining a set of of traversed interfaces, which is the root cause of the issue.

The code is optimized for common cases and will for less common cases collect fields of interfaces into a temporary linked hash set (to preserve the order, perhaps not strictly necessary but i did not want to change that behaviour).

Thanks,
Paul.

From dl at cs.oswego.edu  Wed Nov 29 21:39:38 2017
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 29 Nov 2017 16:39:38 -0500
Subject: RFR: jsr166 jdk10 integration wave 6
In-Reply-To: <DCFB498A-F7A2-4744-8728-61B80C1433AB@oracle.com>
References: <CA+kOe0-yJ+9EX+U32zHAvMjo9LSJ9rKeKTmsrTskqk5uSBue4w@mail.gmail.com>
 <DCFB498A-F7A2-4744-8728-61B80C1433AB@oracle.com>
Message-ID: <b0412aa9-e4cc-d8cf-cff4-d30985de9fe6@cs.oswego.edu>

On 11/29/2017 01:43 PM, Paul Sandoz wrote:

> SubmissionPublisher
> --
> 
> 1004         // Order-sensitive field declarations
> 
> Is this still relevant

Not really; layout is now discussed in class-level doc.
Removed. Thanks.

> 
> 81 * <p>A single SubmissionPublisher may be shared among multiple
> 82 * sources. Actions in a source thread prior to publishing an item or
> 83 * issuing a signal <a href="package-summary.html#MemoryVisibility">
> 84 * <i>happen-before</i></a> actions subsequent to the corresponding
> 85 * access by each subscriber. But reported estimates of lag and demand
> 86 * are designed for use in monitoring, not for synchronization
> 87 * control, and may reflect stale or inaccurate views of progress.
> 
> We probably need a CSR for this.

Yeah, I guess so, even though it is just a clarification.

> 
> Is ?corresponding access by each subscriber? referring to access of the
> published item by each subscriber?
> 

Yes. And also for signals like closeExceptionally exceptions.
This seems to cover both cases, but maybe could be improved.

-Doug



From jonathan.gibbons at oracle.com  Wed Nov 29 22:11:07 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 29 Nov 2017 14:11:07 -0800
Subject: RFR (JDK10/JAXP) 8191938: Fix lint warnings in JAXP repo: a few
 Deprecation warrnings and enable -Xlint:all
In-Reply-To: <5A1F035B.7060900@oracle.com>
References: <5A1DA6EC.6080702@oracle.com>
 <eb39d13b-561b-f8ac-48ec-6813ef9684b3@oracle.com>
 <5A1F035B.7060900@oracle.com>
Message-ID: <5A1F307B.6080601@oracle.com>

Joe,

I presume javadoc is OK with this not-quite-a-doc-comment-tag, when you 
do "make docs" ...

-- Jon


On 11/29/2017 10:58 AM, Joe Wang wrote:
> Hi Joe,
>
> I moved the LastModified to the bottom of the class comment block. 
> Please let me know what you think:
> http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/index.html
>
> Thanks,
> Joe
>
> On 11/28/17, 10:19 AM, joe darcy wrote:
>> Hi Joe,
>>
>> The code changes look fine, but the copyright blocks should *not* be 
>> updated to include a "@LastModified: Nov 2017" comment.
>>
>> Cheers,
>>
>> -Joe
>>
>>
>> On 11/28/2017 10:11 AM, Joe Wang wrote:
>>> Hi,
>>>
>>> Please review a fix for a few more deprecation warnings. Compiling 
>>> with -Xlint:all showed that these were the last few warnings. We can 
>>> then enable -Xlint:all for the java.xml module.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8191938
>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/
>>>
>>> Thanks,
>>> Joe
>>


From mandy.chung at oracle.com  Wed Nov 29 22:44:07 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 29 Nov 2017 14:44:07 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
 <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com>
 <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com>
 <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com>
Message-ID: <c3cca6dc-14f2-855a-e2be-fa60c0ad9ac8@oracle.com>

Vladimir and I discussed this offline. java --limit-modules should have 
the same set of observable modules as running on an image that is 
created with jlink.? When running with -XX:+UseJVMCICompiler on a 
runtime image with just java.base, it will fail in the same way as 
running with java --limit-modules java.base -XX:+UseJVMCICompiler. These 
tests are written to run on a runtime image with java.base only should 
be updated to get it run with -XX:+UseJVMCICompiler.? I will take a look 
and see how we can refactor the tests to support such testing 
configuration.?? In the meantime, Vladimir suggests to exclude these 
tests when running with -XX:+UseJVMCICompiler (specifying @requires).

Mandy

From vladimir.kozlov at oracle.com  Wed Nov 29 23:19:06 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 29 Nov 2017 15:19:06 -0800
Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to
 --limit-modules if -Djvmci.Compiler=graal is in the command line
In-Reply-To: <c3cca6dc-14f2-855a-e2be-fa60c0ad9ac8@oracle.com>
References: <de00d754-bcf2-d64c-bc41-1f297661a0f6@oracle.com>
 <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com>
 <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com>
 <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com>
 <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com>
 <c3cca6dc-14f2-855a-e2be-fa60c0ad9ac8@oracle.com>
Message-ID: <85ed009a-5c31-80fb-b8ae-1f889843e6e7@oracle.com>

Yes, it was my limited understanding what --limit-modules is. We should not add modules "under 
cover" when --limit-modules is used. User should known all required modules *explicitly* to create 
correct image with jlink based on result of runs with --limit-modules flag.

Since it is limited set of tests which use --limit-modules (11 in hotspot, 23 in jdk and few in 
closed) I will exclude these tests from running with Graal as JIT by adding @require to them:

  @requires !vm.graal.enabled

We may revisit this later in a future when Graal become default JIT compiler (it should be supported 
on platforms at that time).

Thanks,
Vladimir

On 11/29/17 2:44 PM, mandy chung wrote:
> Vladimir and I discussed this offline. java --limit-modules should have the same set of observable 
> modules as running on an image that is created with jlink.? When running with -XX:+UseJVMCICompiler 
> on a runtime image with just java.base, it will fail in the same way as running with java 
> --limit-modules java.base -XX:+UseJVMCICompiler. These tests are written to run on a runtime image 
> with java.base only should be updated to get it run with -XX:+UseJVMCICompiler.? I will take a look 
> and see how we can refactor the tests to support such testing configuration.?? In the meantime, 
> Vladimir suggests to exclude these tests when running with -XX:+UseJVMCICompiler (specifying 
> @requires).
> 
> Mandy

From stuart.marks at oracle.com  Wed Nov 29 23:49:41 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 29 Nov 2017 15:49:41 -0800
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <CA+kOe08YikYjj08ifh_03pQXstvP6MW=CKruPmckG_EgeTUdCw@mail.gmail.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <E3598621-C8A0-4ECA-9EFB-8D8F6381AF18@oracle.com>
 <CACzrW9DibVN=ajMJBSQhZzNdZDWM1LPsXPH6M=ryt28kgZS3ag@mail.gmail.com>
 <31772934.1447977.1511369115414.JavaMail.zimbra@u-pem.fr>
 <a42bfadb-d8b6-eaa0-0ca8-995a46eb7c6b@oracle.com>
 <CA+kOe08YikYjj08ifh_03pQXstvP6MW=CKruPmckG_EgeTUdCw@mail.gmail.com>
Message-ID: <d341892a-33f9-2c05-cc3a-1d2ff5840dc7@oracle.com>



On 11/29/17 10:09 AM, Martin Buchholz wrote:
> Guava's "immutable collections" are very popular 
> https://github.com/google/guava/wiki/ImmutableCollectionsExplained and it's
> not a good idea to fight their advertised notion of "immutable".
> 
> No generic container class can promise s'marks-style immutability (until 
> valhalla perhaps?) so it's not that useful a concept in this domain. We like
> to think of Optional as an immutable value based class but you can't stop
> anyone who really wants to mutate the contained element from creating an 
> Optional<AtomicReference<Object>>

Sure, you can't prevent anybody from doing something like this.

The big problem with "immutable" is that to many people it seems to imply what 
I'd call "persistent". That is, modification operations will modify and return a 
new data structure, preserving the old one (unmodified), often with structural 
sharing. A web search for "immutable data structure" matches this. Java is the 
outlier in trying to define "immutable" as meaning "throws 
UnsupportedOperationException" on modification.

I really think "unmodifiable" is the better word here.

> We could do a better job of clarifying consequences of element mutation.
> E.g. do we ever say that hash based collections/maps are broken if elements
> are ever mutated in such a way that their hash code changes while they are in
> the collection/map?

Not exactly, but Set has the following in the class doc:

> Note: Great care must be exercised if mutable objects are used as set
> elements. The behavior of a set is not specified if the value of an object is
> changed in a manner that affects equals comparisons while the object is an
> element in the set. A special case of this prohibition is that it is not
> permissible for a set to contain itself as an element.

(Map has something similar.) There isn't anything in SortedSet/SortedMap that 
talks about mutation vs. its effect on the Comparator-imposed total ordering. 
Perhaps there should be.

s'marks

From claes.redestad at oracle.com  Thu Nov 30 00:00:19 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 30 Nov 2017 01:00:19 +0100
Subject: RFR 8186961 Class.getFields() does not return fields of
 previously visited super interfaces/classes.
In-Reply-To: <929496D6-A4B3-4EF2-BDCB-D2504C1BECE3@oracle.com>
References: <929496D6-A4B3-4EF2-BDCB-D2504C1BECE3@oracle.com>
Message-ID: <c3086c30-5974-365d-8958-3944d3bfcc64@oracle.com>

Hi Paul,

it seems you'll effectively skip processing of the last interface of c in the new code - is this intentional?

3049         Field[] iFields = null;
3050         for (Class<?> c : getInterfaces()) {
3051             if (iFields != null && iFields.length > 0) {
...
3060             }
3061             iFields = c.privateGetPublicFields();
3062         }

ifaces is unused:

3047         Class<?>[] ifaces = getInterfaces();

Nit: You could probably simplify code by replacing List<Field> fields with the LinkedHashSet directly, removing the need to create it conditionally.

/Claes


On 2017-11-29 21:15, Paul Sandoz wrote:
> Hi,
>
> Please review:
>
>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186961-iface-static-fields-get/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186961-iface-static-fields-get/webrev/>
>
> There is a bug lurking, perhaps for a while, where diamond patterns for interface hierarchies can result in the incorrect reporting of fields when using reflection, see the test case.
>
> Since reflection data is cached i don?t see an advantage to retaining a set of of traversed interfaces, which is the root cause of the issue.
>
> The code is optimized for common cases and will for less common cases collect fields of interfaces into a temporary linked hash set (to preserve the order, perhaps not strictly necessary but i did not want to change that behaviour).
>
> Thanks,
> Paul.


From martinrb at google.com  Thu Nov 30 00:03:39 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 29 Nov 2017 16:03:39 -0800
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
In-Reply-To: <5A1EF5F7.1030303@oracle.com>
References: <5A0E4703.3040409@oracle.com>
 <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>
 <5A0F13FF.8090406@oracle.com>
 <1c71e540-88a2-4f6f-5f2b-06b62b955df7@oracle.com>
 <5A131E90.6090509@oracle.com>
 <BE9EE092-1BDD-4A34-A8CF-C9F93094D3DE@oracle.com>
 <5A139662.2030105@oracle.com>
 <f9aa9a4b-d399-14e1-d38e-81eec3e0ab9d@oracle.com>
 <5A1EF5F7.1030303@oracle.com>
Message-ID: <CA+kOe08-8=P9sMbkzr4_HxBiqZ0dkO-X3D09YYtC3+qy_fYzhw@mail.gmail.com>

+    private static boolean isASCII(byte[] ba, int off, int len) {+
    for (int i = off; i < off + len; i++) {+            if (ba[i] <
0)+                return false;+        }+        return true;+    }

I see that StringCoding has

    @HotSpotIntrinsicCandidate
    public static boolean hasNegatives(byte[] ba, int off, int len) {
        for (int i = off; i < off + len; i++) {
            if (ba[i] < 0) {
                return true;
            }
        }
        return false;
    }

and in hotspot-land I see that MacroAssembler::has_negatives has 200 lines
of hairy assemblerese.  Let's reuse that enormous effort!  And not just in
ZipCoder.java - needing to check a byte sequence for Ascii-ness is a bit
goofy but important enough to be a public API  (I've used optimized
versions of this in other languages).  I don't know where it belongs (could
add a method to CharsetDecoder, intrinsified for US_ASCII), but we can find
one.  Even without that, surely today we should be able to reuse this
intrinsic from somewhere else within the java.base module.

(Keeping high-performance intrinsics hidden is a top reason why java
developers use jdk internals)

(Not directed at Xueming in particular)

From martinrb at google.com  Thu Nov 30 00:05:26 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 29 Nov 2017 16:05:26 -0800
Subject: RFR: JDK-8189611: JarFile versioned stream and real name support
In-Reply-To: <CA+kOe08-8=P9sMbkzr4_HxBiqZ0dkO-X3D09YYtC3+qy_fYzhw@mail.gmail.com>
References: <5A0E4703.3040409@oracle.com>
 <36ffda9d-2615-cfe3-c325-b863a7490a41@oracle.com>
 <5A0F13FF.8090406@oracle.com>
 <1c71e540-88a2-4f6f-5f2b-06b62b955df7@oracle.com>
 <5A131E90.6090509@oracle.com>
 <BE9EE092-1BDD-4A34-A8CF-C9F93094D3DE@oracle.com>
 <5A139662.2030105@oracle.com>
 <f9aa9a4b-d399-14e1-d38e-81eec3e0ab9d@oracle.com>
 <5A1EF5F7.1030303@oracle.com>
 <CA+kOe08-8=P9sMbkzr4_HxBiqZ0dkO-X3D09YYtC3+qy_fYzhw@mail.gmail.com>
Message-ID: <CA+kOe09yUBCyeZj=1vx3J0JpfW=VSOFibSZDJ0=T3ydvbsokCA@mail.gmail.com>

(How hard is it to rename that hotspot intrinsic to isAscii?)

On Wed, Nov 29, 2017 at 4:03 PM, Martin Buchholz <martinrb at google.com>
wrote:

> +    private static boolean isASCII(byte[] ba, int off, int len) {+        for (int i = off; i < off + len; i++) {+            if (ba[i] < 0)+                return false;+        }+        return true;+    }
>
> I see that StringCoding has
>
>     @HotSpotIntrinsicCandidate
>     public static boolean hasNegatives(byte[] ba, int off, int len) {
>         for (int i = off; i < off + len; i++) {
>             if (ba[i] < 0) {
>                 return true;
>             }
>         }
>         return false;
>     }
>
> and in hotspot-land I see that MacroAssembler::has_negatives has 200 lines
> of hairy assemblerese.  Let's reuse that enormous effort!  And not just in
> ZipCoder.java - needing to check a byte sequence for Ascii-ness is a bit
> goofy but important enough to be a public API  (I've used optimized
> versions of this in other languages).  I don't know where it belongs (could
> add a method to CharsetDecoder, intrinsified for US_ASCII), but we can find
> one.  Even without that, surely today we should be able to reuse this
> intrinsic from somewhere else within the java.base module.
>
> (Keeping high-performance intrinsics hidden is a top reason why java
> developers use jdk internals)
>
> (Not directed at Xueming in particular)
>

From stuart.marks at oracle.com  Thu Nov 30 00:18:56 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 29 Nov 2017 16:18:56 -0800
Subject: RFR(s): 8160406: Collection.toArray() spec should be explicit about
 returning precisely an Object[]
Message-ID: <f4de2d2c-5e21-f073-9262-7fdb35c5ae00@oracle.com>

Hi all,

Please review this small spec change / clarification regarding 
Collection.toArray(). The runtime type of the array returned has always been 
intended to be exactly Object[] and not an array of some subtype. This 
requirement is actually implied by the spec already, but in the wrong place; the 
spec for

     <T> T[] toArray?(T[] a)

says

> Note that toArray(new Object[0]) is identical in function to toArray().

Clearly, this should also be specified on toArray() itself.

Patch is below.

Thanks,

s'marks



diff -r 9bb771005928 -r c3d5e370e06f 
src/java.base/share/classes/java/util/Collection.java
--- a/src/java.base/share/classes/java/util/Collection.java	Tue Nov 28 17:14:30 
2017 -0800
+++ b/src/java.base/share/classes/java/util/Collection.java	Wed Nov 29 14:29:14 
2017 -0800
@@ -268,7 +268,7 @@
       * Returns an array containing all of the elements in this collection.
       * If this collection makes any guarantees as to what order its elements
       * are returned by its iterator, this method must return the elements in
-     * the same order.
+     * the same order. The returned array's component type is {@code Object}.
       *
       * <p>The returned array will be "safe" in that no references to it are
       * maintained by this collection.  (In other words, this method must
@@ -278,7 +278,8 @@
       * <p>This method acts as bridge between array-based and collection-based
       * APIs.
       *
-     * @return an array containing all of the elements in this collection
+     * @return an array, whose component type is {@code Object}, containing all
+     * of the elements in this collection
       */
      Object[] toArray();


From paul.sandoz at oracle.com  Thu Nov 30 01:18:36 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 29 Nov 2017 17:18:36 -0800
Subject: RFR(s): 8160406: Collection.toArray() spec should be explicit
 about returning precisely an Object[]
In-Reply-To: <f4de2d2c-5e21-f073-9262-7fdb35c5ae00@oracle.com>
References: <f4de2d2c-5e21-f073-9262-7fdb35c5ae00@oracle.com>
Message-ID: <21DB21D0-B94E-4082-81AB-9974BBF01AB4@oracle.com>

+1

Paul.

> On 29 Nov 2017, at 16:18, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Hi all,
> 
> Please review this small spec change / clarification regarding Collection.toArray(). The runtime type of the array returned has always been intended to be exactly Object[] and not an array of some subtype. This requirement is actually implied by the spec already, but in the wrong place; the spec for
> 
>    <T> T[] toArray?(T[] a)
> 
> says
> 
>> Note that toArray(new Object[0]) is identical in function to toArray().
> 
> Clearly, this should also be specified on toArray() itself.
> 
> Patch is below.
> 
> Thanks,
> 
> s'marks
> 
> 
> 
> diff -r 9bb771005928 -r c3d5e370e06f src/java.base/share/classes/java/util/Collection.java
> --- a/src/java.base/share/classes/java/util/Collection.java	Tue Nov 28 17:14:30 2017 -0800
> +++ b/src/java.base/share/classes/java/util/Collection.java	Wed Nov 29 14:29:14 2017 -0800
> @@ -268,7 +268,7 @@
>      * Returns an array containing all of the elements in this collection.
>      * If this collection makes any guarantees as to what order its elements
>      * are returned by its iterator, this method must return the elements in
> -     * the same order.
> +     * the same order. The returned array's component type is {@code Object}.
>      *
>      * <p>The returned array will be "safe" in that no references to it are
>      * maintained by this collection.  (In other words, this method must
> @@ -278,7 +278,8 @@
>      * <p>This method acts as bridge between array-based and collection-based
>      * APIs.
>      *
> -     * @return an array containing all of the elements in this collection
> +     * @return an array, whose component type is {@code Object}, containing all
> +     * of the elements in this collection
>      */
>     Object[] toArray();
> 


From martinrb at google.com  Thu Nov 30 01:20:43 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 29 Nov 2017 17:20:43 -0800
Subject: RFR(s): 8160406: Collection.toArray() spec should be explicit
 about returning precisely an Object[]
In-Reply-To: <f4de2d2c-5e21-f073-9262-7fdb35c5ae00@oracle.com>
References: <f4de2d2c-5e21-f073-9262-7fdb35c5ae00@oracle.com>
Message-ID: <CA+kOe0-rAhM96scPxzYYL7Aw-_1-qOYP+Y17an44oO2WEJLsZg@mail.gmail.com>

Thanks.  This looks good, and finishes the effort started 12 years ago.
Apologies for not having made this spec change myself years ago.

I tried to find a less JLSese way to wordsmith it.  Nearby spec talks about
the "runtime type" of the array.  Maybe s/component/runtime component/ but
I'm not sure that's actually better.

On Wed, Nov 29, 2017 at 4:18 PM, Stuart Marks <stuart.marks at oracle.com>
wrote:

> Hi all,
>
> Please review this small spec change / clarification regarding
> Collection.toArray(). The runtime type of the array returned has always
> been intended to be exactly Object[] and not an array of some subtype. This
> requirement is actually implied by the spec already, but in the wrong
> place; the spec for
>
>     <T> T[] toArray?(T[] a)
>
> says
>
> Note that toArray(new Object[0]) is identical in function to toArray().
>>
>
> Clearly, this should also be specified on toArray() itself.
>
> Patch is below.
>
> Thanks,
>
> s'marks
>
>
>
> diff -r 9bb771005928 -r c3d5e370e06f src/java.base/share/classes/ja
> va/util/Collection.java
> --- a/src/java.base/share/classes/java/util/Collection.java     Tue Nov
> 28 17:14:30 2017 -0800
> +++ b/src/java.base/share/classes/java/util/Collection.java     Wed Nov
> 29 14:29:14 2017 -0800
> @@ -268,7 +268,7 @@
>       * Returns an array containing all of the elements in this collection.
>       * If this collection makes any guarantees as to what order its
> elements
>       * are returned by its iterator, this method must return the elements
> in
> -     * the same order.
> +     * the same order. The returned array's component type is {@code
> Object}.
>       *
>       * <p>The returned array will be "safe" in that no references to it
> are
>       * maintained by this collection.  (In other words, this method must
> @@ -278,7 +278,8 @@
>       * <p>This method acts as bridge between array-based and
> collection-based
>       * APIs.
>       *
> -     * @return an array containing all of the elements in this collection
> +     * @return an array, whose component type is {@code Object},
> containing all
> +     * of the elements in this collection
>       */
>      Object[] toArray();
>
>

From stuart.marks at oracle.com  Thu Nov 30 02:54:20 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 29 Nov 2017 18:54:20 -0800
Subject: RFR(s): 8160406: Collection.toArray() spec should be explicit
 about returning precisely an Object[]
In-Reply-To: <CA+kOe0-rAhM96scPxzYYL7Aw-_1-qOYP+Y17an44oO2WEJLsZg@mail.gmail.com>
References: <f4de2d2c-5e21-f073-9262-7fdb35c5ae00@oracle.com>
 <CA+kOe0-rAhM96scPxzYYL7Aw-_1-qOYP+Y17an44oO2WEJLsZg@mail.gmail.com>
Message-ID: <444c273e-a457-edef-2354-5991a831cf49@oracle.com>



On 11/29/17 5:20 PM, Martin Buchholz wrote:
> Thanks.? This looks good, and finishes the effort started 12 years ago.  
> Apologies for not having made this spec change myself years ago.
> 
> I tried to find a less JLSese way to wordsmith it.? Nearby spec talks about the 
> "runtime type" of the array. Maybe s/component/runtime component/ but I'm not 
> sure that's actually better.

Good point. I looked through the specs of both toArray() methods to see if 
anything needed to be fixed up. Indeed, there is.

Off-list, Claes Redestad pointed out that in the T[] method, there is the following:

      * @param <T> the runtime type of the array to contain the collection

This is in fact completely wrong. The array type is T[] and so T is not the type 
of the array, it's the component type. Furthermore, it's not the runtime 
component type, it's the static component type. This is pretty easy to 
illustrate. Suppose we have:

     var list = List.of("a")
     CharSequence[] csa = list.toArray((CharSequence[])new String[0])

In the second line, the type variable T is CharSequence, but the runtime 
component type of the returned array is String. (Alternatively, the runtime type 
of the array is String[].)

The specs here need to distinguish between the array's type and the array's 
component type, and also between the static component type and the runtime 
component type. It just goes to show that nothing is ever as simple as it seems!

Here's what I did:

* In a couple places, I substituted "runtime component type" and also made this 
be a link to the Class.getComponentType() method to make sure it's absolutely 
clear what's being talked about. The JLS describes the "element type" of an 
array and sometimes the "component" of an array; I chose "component type" 
because it's consistent with Class.getComponentType().

* I fixed up the @param <T> doc to be "static component type".

* I fixed up ArrayStoreException in the T[] method because it confused the 
array's type with the Collection elements' runtime types. I mirrored the wording 
from JLS 10.5 ArrayStoreException, which is framed around assignment compatibility.

I left some statements that mentioned the "runtime type of the array" because I 
think they're correct as they stand. For example, "...a new array is allocated 
with the runtime type of the specified array...."

Revised patch appended below. Overall it's not much bigger than the previous 
patch, but it did require a lot of close reading.

Thanks,

s'marks





diff -r 9bb771005928 -r fb5434478123 
src/java.base/share/classes/java/util/Collection.java
--- a/src/java.base/share/classes/java/util/Collection.java	Tue Nov 28 17:14:30 
2017 -0800
+++ b/src/java.base/share/classes/java/util/Collection.java	Wed Nov 29 18:30:35 
2017 -0800
@@ -268,7 +268,8 @@
       * Returns an array containing all of the elements in this collection.
       * If this collection makes any guarantees as to what order its elements
       * are returned by its iterator, this method must return the elements in
-     * the same order.
+     * the same order. The returned array's {@linkplain Class#getComponentType
+     * runtime component type} is {@code Object}.
       *
       * <p>The returned array will be "safe" in that no references to it are
       * maintained by this collection.  (In other words, this method must
@@ -278,7 +279,8 @@
       * <p>This method acts as bridge between array-based and collection-based
       * APIs.
       *
-     * @return an array containing all of the elements in this collection
+     * @return an array, whose {@linkplain Class#getComponentType runtime component
+     * type} is {@code Object}, containing all of the elements in this collection
       */
      Object[] toArray();

@@ -315,14 +317,14 @@
       * Note that {@code toArray(new Object[0])} is identical in function to
       * {@code toArray()}.
       *
-     * @param <T> the runtime type of the array to contain the collection
+     * @param <T> the static component type of the array to contain the collection
       * @param a the array into which the elements of this collection are to be
       *        stored, if it is big enough; otherwise, a new array of the same
       *        runtime type is allocated for this purpose.
       * @return an array containing all of the elements in this collection
-     * @throws ArrayStoreException if the runtime type of the specified array
-     *         is not a supertype of the runtime type of every element in
-     *         this collection
+     * @throws ArrayStoreException if the runtime type of any element in this
+     *         collection is not assignable to the {@linkplain 
Class#getComponentType
+     *         runtime component type} of the specified array
       * @throws NullPointerException if the specified array is null
       */
      <T> T[] toArray(T[] a);

From martinrb at google.com  Thu Nov 30 03:28:06 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 29 Nov 2017 19:28:06 -0800
Subject: RFR(s): 8160406: Collection.toArray() spec should be explicit
 about returning precisely an Object[]
In-Reply-To: <444c273e-a457-edef-2354-5991a831cf49@oracle.com>
References: <f4de2d2c-5e21-f073-9262-7fdb35c5ae00@oracle.com>
 <CA+kOe0-rAhM96scPxzYYL7Aw-_1-qOYP+Y17an44oO2WEJLsZg@mail.gmail.com>
 <444c273e-a457-edef-2354-5991a831cf49@oracle.com>
Message-ID: <CA+kOe09=MTw76ygjh0anh58_LFsUmjVzmJJY4xX2Bo+4CjSVzQ@mail.gmail.com>

Wordsmithing is hard.  Which may be why I never tried to improve these
specs decades ago.

I would make one change.

+     * @param <T> the static component type of the array to contain the
collection

Just drop runtime/static

    * @param <T> the component type of the array to contain the collection

the "static" is "obvious" and the caller could in theory provide the T to
use.


On Wed, Nov 29, 2017 at 6:54 PM, Stuart Marks <stuart.marks at oracle.com>
wrote:

>
>
> On 11/29/17 5:20 PM, Martin Buchholz wrote:
>
>> Thanks.  This looks good, and finishes the effort started 12 years ago.
>> Apologies for not having made this spec change myself years ago.
>>
>> I tried to find a less JLSese way to wordsmith it.  Nearby spec talks
>> about the "runtime type" of the array. Maybe s/component/runtime component/
>> but I'm not sure that's actually better.
>>
>
> Good point. I looked through the specs of both toArray() methods to see if
> anything needed to be fixed up. Indeed, there is.
>
> Off-list, Claes Redestad pointed out that in the T[] method, there is the
> following:
>
>      * @param <T> the runtime type of the array to contain the collection
>
> This is in fact completely wrong. The array type is T[] and so T is not
> the type of the array, it's the component type. Furthermore, it's not the
> runtime component type, it's the static component type. This is pretty easy
> to illustrate. Suppose we have:
>
>     var list = List.of("a")
>     CharSequence[] csa = list.toArray((CharSequence[])new String[0])
>
> In the second line, the type variable T is CharSequence, but the runtime
> component type of the returned array is String. (Alternatively, the runtime
> type of the array is String[].)
>
> The specs here need to distinguish between the array's type and the
> array's component type, and also between the static component type and the
> runtime component type. It just goes to show that nothing is ever as simple
> as it seems!
>
> Here's what I did:
>
> * In a couple places, I substituted "runtime component type" and also made
> this be a link to the Class.getComponentType() method to make sure it's
> absolutely clear what's being talked about. The JLS describes the "element
> type" of an array and sometimes the "component" of an array; I chose
> "component type" because it's consistent with Class.getComponentType().
>
> * I fixed up the @param <T> doc to be "static component type".
>
> * I fixed up ArrayStoreException in the T[] method because it confused the
> array's type with the Collection elements' runtime types. I mirrored the
> wording from JLS 10.5 ArrayStoreException, which is framed around
> assignment compatibility.
>
> I left some statements that mentioned the "runtime type of the array"
> because I think they're correct as they stand. For example, "...a new array
> is allocated with the runtime type of the specified array...."
>
> Revised patch appended below. Overall it's not much bigger than the
> previous patch, but it did require a lot of close reading.
>
> Thanks,
>
> s'marks
>
>
>
>
>
> diff -r 9bb771005928 -r fb5434478123 src/java.base/share/classes/ja
> va/util/Collection.java
> --- a/src/java.base/share/classes/java/util/Collection.java     Tue Nov
> 28 17:14:30 2017 -0800
> +++ b/src/java.base/share/classes/java/util/Collection.java     Wed Nov
> 29 18:30:35 2017 -0800
> @@ -268,7 +268,8 @@
>       * Returns an array containing all of the elements in this collection.
>       * If this collection makes any guarantees as to what order its
> elements
>       * are returned by its iterator, this method must return the elements
> in
> -     * the same order.
> +     * the same order. The returned array's {@linkplain
> Class#getComponentType
> +     * runtime component type} is {@code Object}.
>       *
>       * <p>The returned array will be "safe" in that no references to it
> are
>       * maintained by this collection.  (In other words, this method must
> @@ -278,7 +279,8 @@
>       * <p>This method acts as bridge between array-based and
> collection-based
>       * APIs.
>       *
> -     * @return an array containing all of the elements in this collection
> +     * @return an array, whose {@linkplain Class#getComponentType runtime
> component
> +     * type} is {@code Object}, containing all of the elements in this
> collection
>       */
>      Object[] toArray();
>
> @@ -315,14 +317,14 @@
>       * Note that {@code toArray(new Object[0])} is identical in function
> to
>       * {@code toArray()}.
>       *
> -     * @param <T> the runtime type of the array to contain the collection
> +     * @param <T> the static component type of the array to contain the
> collection
>       * @param a the array into which the elements of this collection are
> to be
>       *        stored, if it is big enough; otherwise, a new array of the
> same
>       *        runtime type is allocated for this purpose.
>       * @return an array containing all of the elements in this collection
> -     * @throws ArrayStoreException if the runtime type of the specified
> array
> -     *         is not a supertype of the runtime type of every element in
> -     *         this collection
> +     * @throws ArrayStoreException if the runtime type of any element in
> this
> +     *         collection is not assignable to the {@linkplain
> Class#getComponentType
> +     *         runtime component type} of the specified array
>       * @throws NullPointerException if the specified array is null
>       */
>      <T> T[] toArray(T[] a);
>

From nishit.jain at oracle.com  Thu Nov 30 06:00:31 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Thu, 30 Nov 2017 11:30:31 +0530
Subject: <i18n dev> [10] RFR 6354947: [Fmt-*] DecimalFormat ignores
 FieldPosition settings on input, contrary to Javadocs
In-Reply-To: <d7bc5240-369f-88f6-8e46-d3e38152c2db@Oracle.com>
References: <156741f0-36df-03cb-e30f-e2c41d0fc3ef@oracle.com>
 <91cfcd2f-97ba-dda8-eb2d-9c4bd0f05f29@oracle.com>
 <d7bc5240-369f-88f6-8e46-d3e38152c2db@Oracle.com>
Message-ID: <105a30a7-fc82-3080-42af-269f00903f62@oracle.com>

Thanks Naoto, Roger for the review.

 > the summary of the issue does not reflect the issue and implies the 
implementation is wrong; but it is the javadoc that need clarification.
It is probably because when this bug was filed, it was not clear whether 
implementation will be changed as per javadoc or the javadoc will be 
changed.

 > Please change the issue summary (on both the CSR and the issue) to 
reflect the true cause.
Done

Regards,
Nishit Jain
On 29-11-2017 20:35, Roger Riggs wrote:
> Hi Nishit,
>
> The webrev and updates to the javadoc look fine.
>
> However, the summary of the issue does not reflect the issue and 
> implies the implementation is wrong;
> but it is the javadoc that need clarification.
>
> Please change the issue summary (on both the CSR and the issue) to 
> reflect the true cause, something like:
>
> [Fmt-*] Clarify DecimalFormat description of FieldPosition use
>
> Thanks, Roger
>
>
> On 11/17/2017 7:21 PM, Naoto Sato wrote:
>> +1
>>
>> Naoto
>>
>> On 11/16/17 10:52 PM, Nishit Jain wrote:
>>> Hi,
>>>
>>> Please review the fix for JDK-6354947
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6354947
>>> Webrev: http://cr.openjdk.java.net/~nishjain/6354947/webrev.02/
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191014
>>>
>>> Fix: Clarified handling of the FieldPosition settings in the 
>>> java.text.Format APIs specification.
>>>
>>> Regards,
>>> Nishit Jain
>


From xueming.shen at oracle.com  Thu Nov 30 07:12:45 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 29 Nov 2017 23:12:45 -0800
Subject: RFR JDK-8187910: Charset MS950_HKSCS not supported in JDK 9
Message-ID: <5A1FAF6D.3010003@oracle.com>

Hi

Please help review the change for JDK-8187910.

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

The change is to add charset MS950_HKSCS into sun.nio.cs/"standard 
charset provider"
on Windows platform. It appears it is being used for Windows7's 
Traditional, Hong Kong
S.A.R. locale, as reported.

Thanks,
Sherman

From goetz.lindenmaier at sap.com  Thu Nov 30 09:18:54 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 30 Nov 2017 09:18:54 +0000
Subject: RFR: 8189102: All tools should support -?, -h and --help
In-Reply-To: <9F5BAA92-7186-4046-B67C-61FBFF540497@oracle.com>
References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com>
 <5A1C4081.2090107@oracle.com> <badb6f618f5b489ca634adb6b545b152@sap.com>
 <9F5BAA92-7186-4046-B67C-61FBFF540497@oracle.com>
Message-ID: <f0767add3acc4cbc960ffa6603abe020@sap.com>

Thanks, Robert!

Best regards,
  Goetz.

> -----Original Message-----
> From: Robert Field [mailto:robert.field at oracle.com]
> Sent: Mittwoch, 29. November 2017 19:31
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: Kumar Srinivasan <kumar.x.srinivasan at oracle.com>; serviceability-dev
> (serviceability-dev at openjdk.java.net) <serviceability-
> dev at openjdk.java.net>; compiler-dev at openjdk.java.net; core-libs-
> dev at openjdk.java.net
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Thumbs up for JShell changes.
> 
> -Robert
> 
> > On Nov 28, 2017, at 3:16 AM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi,
> >
> > I uploaded a new webrev:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.04/
> >
> > This includes the changes
> >  - to jshell requested by Robert
> >  - to the test as requested by Kumar.
> >
> > See also incremental patch and the test output including all the
> > help messages referenced in the webrev.
> >
> > Best regards,
> >  Goetz.
> >
> >> -----Original Message-----
> >> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com]
> >> Sent: Montag, 27. November 2017 17:43
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >> Cc: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net'
> >> <compiler-dev at openjdk.java.net>; serviceability-dev (serviceability-
> >> dev at openjdk.java.net) <serviceability-dev at openjdk.java.net>
> >> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> >>
> >> Hi,
> >>
> >> I looked at some of the components I maintain, and they look good.
> >>
> >> Wrt. the test:
> >>
> >> 1. The local variables/fields don't comply with the coding conventions,
> >> we have been
> >>      following in the JDK.
> >>
> >> 2.  Hmm, someone parked a .ini file in bin directory, later removed,
> >>      perhaps on windows simply check for .exe ? Should a check exist
> >>      to verify if file has executable permissions ?"File.canExecute".
> >>
> >>  171     // Returns true if the file is not a tool.
> >>  172     static boolean notATool(String file) {
> >>  173         file = file.toLowerCase();
> >>  174         if (file.endsWith(".dll") ||
> >>  175             file.endsWith(".map") ||
> >>  176             file.endsWith(".pdb") ||
> >>  177             file.equals("server")) {  // server subdir on windows.
> >>  178             return true;
> >>  179         }
> >>  180         return false;
> >>  181     }
> >>
> >>
> >> 3.  Typo in comment
> >>
> >> 201     // Check whether 'flag' appears in 'line' as a word of itself. I must not
> >>
> >> s/I must/It must/
> >>
> >>
> >> 4. There is a method to check for isEnglishLocale in TestHelper, perhaps
> >> use it
> >> to have the test bale out in non english locales as early as possible ?
> >>
> >> 5.  Has this been tested on all platforms ? do you need help testing it ?
> >>
> >> Kumar
> >>
> >>
> >> On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> please review this change. I also filed a CSR for this:
> >>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
> >> helpMessage/webrev.02/
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >>>
> >>> See the webrev for a detailed description of the changes.
> >>>
> >>> If required, I'll make break-out changes to be reviewed separately.
> >>>
> >>> I had posted a RFR before, but improved the change to
> >>> give a more complete overview of currently supported flags
> >>> for the CSR:
> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> >> October/028615.html
> >>>
> >>> Best regards,
> >>>   Goetz.
> >>>
> >


From Alan.Bateman at oracle.com  Thu Nov 30 11:01:55 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 Nov 2017 11:01:55 +0000
Subject: RFR JDK-8187910: Charset MS950_HKSCS not supported in JDK 9
In-Reply-To: <5A1FAF6D.3010003@oracle.com>
References: <5A1FAF6D.3010003@oracle.com>
Message-ID: <e8fb2a81-1007-c227-0407-9aecbaeb9bb9@oracle.com>

On 30/11/2017 07:12, Xueming Shen wrote:
> Hi
>
> Please help review the change for JDK-8187910.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8187910
> webrev: http://cr.openjdk.java.net/~sherman/8187910/webrev
>
> The change is to add charset MS950_HKSCS into sun.nio.cs/"standard 
> charset provider"
> on Windows platform. It appears it is being used for Windows7's 
> Traditional, Hong Kong
> S.A.R. locale, as reported.
Hopefully the configured list for each platform is right now. In any 
case, the changes in this webrev look okay as the increase in size of 
java.base on Windows shouldn't be a big deal.

-Alan

From Roger.Riggs at Oracle.com  Thu Nov 30 15:20:23 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 30 Nov 2017 10:20:23 -0500
Subject: RFR: 8189331 [testbug]
 java/io/Serializable/maskSyntheticModifier/MaskSyntheticModifierTest.java
 failed incorrect serialVersionUID
Message-ID: <5005f00f-a302-fe43-24fd-987e58406182@Oracle.com>

Please review a test fix to copy the golden Foo.class into the classpath 
instead of the current directory.

webrev:
 ?http://cr.openjdk.java.net/~rriggs/webrev-synthetic-8189331/

issue:
 ?? https://bugs.openjdk.java.net/browse/JDK-8189331

Thanks, Roger


From lance.andersen at oracle.com  Thu Nov 30 16:08:36 2017
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Thu, 30 Nov 2017 11:08:36 -0500
Subject: RFR: 8189331 [testbug]
 java/io/Serializable/maskSyntheticModifier/MaskSyntheticModifierTest.java
 failed incorrect serialVersionUID
In-Reply-To: <5005f00f-a302-fe43-24fd-987e58406182@Oracle.com>
References: <5005f00f-a302-fe43-24fd-987e58406182@Oracle.com>
Message-ID: <74DDC9E8-4633-4B50-82BF-8F8D38CD27EA@oracle.com>

+1


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com
Sent from my iPad

> On Nov 30, 2017, at 10:20 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Please review a test fix to copy the golden Foo.class into the classpath instead of the current directory.
> 
> webrev:
>  http://cr.openjdk.java.net/~rriggs/webrev-synthetic-8189331/
> 
> issue:
>    https://bugs.openjdk.java.net/browse/JDK-8189331
> 
> Thanks, Roger
> 

From paul.sandoz at oracle.com  Thu Nov 30 16:41:59 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 30 Nov 2017 08:41:59 -0800
Subject: RFR 8186961 Class.getFields() does not return fields of
 previously visited super interfaces/classes.
In-Reply-To: <c3086c30-5974-365d-8958-3944d3bfcc64@oracle.com>
References: <929496D6-A4B3-4EF2-BDCB-D2504C1BECE3@oracle.com>
 <c3086c30-5974-365d-8958-3944d3bfcc64@oracle.com>
Message-ID: <FBEBD1D0-6EB6-4C1C-BCDD-8C4776896ACB@oracle.com>

Hi Caes,

As we discussed off list the post loop logic is easily missed.

However, i found another obvious issue i missed with two classes (super/sub) extending from the same interface that declares a field. See updated test case in the webrev.

I have an idea to retain Field[] arrays and then process ?em all at the end of the method to produce the final array. That should hopefully make the logic clearer too.

Paul.


> On 29 Nov 2017, at 16:00, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi Paul,
> 
> it seems you'll effectively skip processing of the last interface of c in the new code - is this intentional?
> 
> 3049         Field[] iFields = null;
> 3050         for (Class<?> c : getInterfaces()) {
> 3051             if (iFields != null && iFields.length > 0) {
> ...
> 3060             }
> 3061             iFields = c.privateGetPublicFields();
> 3062         }
> 
> ifaces is unused:
> 
> 3047         Class<?>[] ifaces = getInterfaces();
> 
> Nit: You could probably simplify code by replacing List<Field> fields with the LinkedHashSet directly, removing the need to create it conditionally.
> 
> /Claes
> 
> 
> On 2017-11-29 21:15, Paul Sandoz wrote:
>> Hi,
>> 
>> Please review:
>> 
>>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186961-iface-static-fields-get/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186961-iface-static-fields-get/webrev/>
>> 
>> There is a bug lurking, perhaps for a while, where diamond patterns for interface hierarchies can result in the incorrect reporting of fields when using reflection, see the test case.
>> 
>> Since reflection data is cached i don?t see an advantage to retaining a set of of traversed interfaces, which is the root cause of the issue.
>> 
>> The code is optimized for common cases and will for less common cases collect fields of interfaces into a temporary linked hash set (to preserve the order, perhaps not strictly necessary but i did not want to change that behaviour).
>> 
>> Thanks,
>> Paul.
> 


From stuart.marks at oracle.com  Thu Nov 30 19:17:09 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 30 Nov 2017 11:17:09 -0800
Subject: RFR(s): 8160406: Collection.toArray() spec should be explicit
 about returning precisely an Object[]
In-Reply-To: <CA+kOe09=MTw76ygjh0anh58_LFsUmjVzmJJY4xX2Bo+4CjSVzQ@mail.gmail.com>
References: <f4de2d2c-5e21-f073-9262-7fdb35c5ae00@oracle.com>
 <CA+kOe0-rAhM96scPxzYYL7Aw-_1-qOYP+Y17an44oO2WEJLsZg@mail.gmail.com>
 <444c273e-a457-edef-2354-5991a831cf49@oracle.com>
 <CA+kOe09=MTw76ygjh0anh58_LFsUmjVzmJJY4xX2Bo+4CjSVzQ@mail.gmail.com>
Message-ID: <56b86174-21ce-bd7e-56ce-294e3d6b8dac@oracle.com>



On 11/29/17 7:28 PM, Martin Buchholz wrote:
> I would make one change.
> 
> +? ? ?* @param <T> the static component type of the array to contain the collection
> 
> Just drop runtime/static
> 
>  ?? ?* @param <T> the component type of the array to contain the collection
> 
> the "static" is "obvious" and the caller could in theory provide the T to use.

OK. This makes it read a bit better. We emphasize the runtime type in the other 
places where it's important, which is probably provides a sufficient distinction.

Thanks,

s'marks


From huizhe.wang at oracle.com  Thu Nov 30 19:25:02 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 30 Nov 2017 11:25:02 -0800
Subject: RFR (JDK10/JAXP) 8191938: Fix lint warnings in JAXP repo: a few
 Deprecation warrnings and enable -Xlint:all
In-Reply-To: <5A1F307B.6080601@oracle.com>
References: <5A1DA6EC.6080702@oracle.com>
 <eb39d13b-561b-f8ac-48ec-6813ef9684b3@oracle.com>
 <5A1F035B.7060900@oracle.com> <5A1F307B.6080601@oracle.com>
Message-ID: <5A205B0E.80409@oracle.com>

Hi Jon, all,

For the LastModified tag, yes, "make docs" was fine. Note that it will 
appear only in impl classes.

For the webrev, I also updated the javac flag from doclint:none to a set 
of java.xml public packages that we care about.

http://cr.openjdk.java.net/%7Ejoehw/jdk10/8191938/webrev/

Thanks,
Joe

On 11/29/17, 2:11 PM, Jonathan Gibbons wrote:
> Joe,
>
> I presume javadoc is OK with this not-quite-a-doc-comment-tag, when 
> you do "make docs" ...
>
> -- Jon
>
>
> On 11/29/2017 10:58 AM, Joe Wang wrote:
>> Hi Joe,
>>
>> I moved the LastModified to the bottom of the class comment block. 
>> Please let me know what you think:
>> http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/index.html
>>
>> Thanks,
>> Joe
>>
>> On 11/28/17, 10:19 AM, joe darcy wrote:
>>> Hi Joe,
>>>
>>> The code changes look fine, but the copyright blocks should *not* be 
>>> updated to include a "@LastModified: Nov 2017" comment.
>>>
>>> Cheers,
>>>
>>> -Joe
>>>
>>>
>>> On 11/28/2017 10:11 AM, Joe Wang wrote:
>>>> Hi,
>>>>
>>>> Please review a fix for a few more deprecation warnings. Compiling 
>>>> with -Xlint:all showed that these were the last few warnings. We 
>>>> can then enable -Xlint:all for the java.xml module.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8191938
>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8191938/webrev/
>>>>
>>>> Thanks,
>>>> Joe
>>>
>

From paul.sandoz at oracle.com  Thu Nov 30 20:17:52 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 30 Nov 2017 12:17:52 -0800
Subject: RFR 8186961 Class.getFields() does not return fields of
 previously visited super interfaces/classes.
In-Reply-To: <FBEBD1D0-6EB6-4C1C-BCDD-8C4776896ACB@oracle.com>
References: <929496D6-A4B3-4EF2-BDCB-D2504C1BECE3@oracle.com>
 <c3086c30-5974-365d-8958-3944d3bfcc64@oracle.com>
 <FBEBD1D0-6EB6-4C1C-BCDD-8C4776896ACB@oracle.com>
Message-ID: <BC884ADD-32FF-4F04-A145-4A23F576CA97@oracle.com>

Here is the updated webrev:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186961-iface-static-fields-get/webrev/

I opted for the simple solution using a LinkedHashSet.

It?s possible to heavily optimize (avoiding the production of a linked hash set until required [*]) but the resulting code is harder to understand.

Paul.

[*] when there are two or more super interface with fields, or one or more super interfaces and a super classes with fields.


> On 30 Nov 2017, at 08:41, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
> Hi Caes,
> 
> As we discussed off list the post loop logic is easily missed.
> 
> However, i found another obvious issue i missed with two classes (super/sub) extending from the same interface that declares a field. See updated test case in the webrev.
> 
> I have an idea to retain Field[] arrays and then process ?em all at the end of the method to produce the final array. That should hopefully make the logic clearer too.
> 
> Paul.
> 
> 
>> On 29 Nov 2017, at 16:00, Claes Redestad <claes.redestad at oracle.com> wrote:
>> 
>> Hi Paul,
>> 
>> it seems you'll effectively skip processing of the last interface of c in the new code - is this intentional?
>> 
>> 3049         Field[] iFields = null;
>> 3050         for (Class<?> c : getInterfaces()) {
>> 3051             if (iFields != null && iFields.length > 0) {
>> ...
>> 3060             }
>> 3061             iFields = c.privateGetPublicFields();
>> 3062         }
>> 
>> ifaces is unused:
>> 
>> 3047         Class<?>[] ifaces = getInterfaces();
>> 
>> Nit: You could probably simplify code by replacing List<Field> fields with the LinkedHashSet directly, removing the need to create it conditionally.
>> 
>> /Claes
>> 
>> 
>> On 2017-11-29 21:15, Paul Sandoz wrote:
>>> Hi,
>>> 
>>> Please review:
>>> 
>>>  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186961-iface-static-fields-get/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186961-iface-static-fields-get/webrev/>
>>> 
>>> There is a bug lurking, perhaps for a while, where diamond patterns for interface hierarchies can result in the incorrect reporting of fields when using reflection, see the test case.
>>> 
>>> Since reflection data is cached i don?t see an advantage to retaining a set of of traversed interfaces, which is the root cause of the issue.
>>> 
>>> The code is optimized for common cases and will for less common cases collect fields of interfaces into a temporary linked hash set (to preserve the order, perhaps not strictly necessary but i did not want to change that behaviour).
>>> 
>>> Thanks,
>>> Paul.
>> 
> 


From forax at univ-mlv.fr  Thu Nov 30 20:25:29 2017
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 30 Nov 2017 21:25:29 +0100 (CET)
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <a42bfadb-d8b6-eaa0-0ca8-995a46eb7c6b@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <E3598621-C8A0-4ECA-9EFB-8D8F6381AF18@oracle.com>
 <CACzrW9DibVN=ajMJBSQhZzNdZDWM1LPsXPH6M=ryt28kgZS3ag@mail.gmail.com>
 <31772934.1447977.1511369115414.JavaMail.zimbra@u-pem.fr>
 <a42bfadb-d8b6-eaa0-0ca8-995a46eb7c6b@oracle.com>
Message-ID: <1268169963.2362223.1512073529601.JavaMail.zimbra@u-pem.fr>

OK !
you convince me.

R?mi

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mercredi 29 Novembre 2017 06:21:41
> Objet: Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

> On 11/22/17 8:45 AM, Remi Forax wrote:
>> I think i prefer toImmutableList() than toUnmodifiableList() because the List
>> is truly immutable and not an unmodifiable proxy in front of a mutable List
>> (like Collections.unmodifiableList() does).
> 
> Immutability is like wine.
> 
> If you put a spoonful of wine in a barrel full of sewage, you get sewage. If you
> put a spoonful of sewage in a barrel full of wine, you get sewage.
> (Schopenhauer's Law of Entropy)
> 
> Similarly, if you add a little immutability to something mutable, you get
> mutability. And if you add a little mutability to something immutable, you get
> mutability.
> 
> To get the desired properties of immutability (e.g., thread-safety, or the
> ability to hand around references safely without making defensive copies), it's
> insufficient for a collection to be "immutable"; you also have to make some
> statements about the contents. It's thus more precise to say that a collection
> is unmodifiable, and to provide a clear definition of an unmodifiable
> collection.
> 
> Although unmodifiable collections have been around since the collections
> framework was introduced, oddly enough the concept has never had a good
> definition. The current proposal includes definitions for unmodifiability,
> unmodifiable collections, and unmodifiable views, and it clearly specifies which
> APIs return unmodifiable views and which return unmodifiable collections.
> 
> s'marks

From claes.redestad at oracle.com  Thu Nov 30 21:00:29 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 30 Nov 2017 22:00:29 +0100
Subject: RFR 8186961 Class.getFields() does not return fields of
 previously visited super interfaces/classes.
In-Reply-To: <BC884ADD-32FF-4F04-A145-4A23F576CA97@oracle.com>
References: <929496D6-A4B3-4EF2-BDCB-D2504C1BECE3@oracle.com>
 <c3086c30-5974-365d-8958-3944d3bfcc64@oracle.com>
 <FBEBD1D0-6EB6-4C1C-BCDD-8C4776896ACB@oracle.com>
 <BC884ADD-32FF-4F04-A145-4A23F576CA97@oracle.com>
Message-ID: <3ad01601-35a7-80f2-b0d0-b4342043e6d2@oracle.com>

Hi,

as expected this is quite a bit easier to follow. Thanks!

As any heavy use of reflection is likely to hit cached data, then 
heavily optimizing might be ill-advised here.

A simpler optimization might be to check if the class has any superclass 
or interfaces whatsoever first, since if not then publicFields == 
privateGetDeclaredField(true). This might reduce number of 
LinkedHashSets created for many trivial class hierarchies significantly 
for only a nominal increase in code complexity, and actually reduce the 
retained set a bit.

/Claes


On 2017-11-30 21:17, Paul Sandoz wrote:
> Here is the updated webrev:
>
>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186961-iface-static-fields-get/webrev/
>
> I opted for the simple solution using a LinkedHashSet.
>
> It?s possible to heavily optimize (avoiding the production of a linked hash set until required [*]) but the resulting code is harder to understand.
>
> Paul.
>
> [*] when there are two or more super interface with fields, or one or more super interfaces and a super classes with fields.
>
>
>> On 30 Nov 2017, at 08:41, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
>>
>> Hi Caes,
>>
>> As we discussed off list the post loop logic is easily missed.
>>
>> However, i found another obvious issue i missed with two classes (super/sub) extending from the same interface that declares a field. See updated test case in the webrev.
>>
>> I have an idea to retain Field[] arrays and then process ?em all at the end of the method to produce the final array. That should hopefully make the logic clearer too.
>>
>> Paul.
>>
>>
>>> On 29 Nov 2017, at 16:00, Claes Redestad <claes.redestad at oracle.com> wrote:
>>>
>>> Hi Paul,
>>>
>>> it seems you'll effectively skip processing of the last interface of c in the new code - is this intentional?
>>>
>>> 3049         Field[] iFields = null;
>>> 3050         for (Class<?> c : getInterfaces()) {
>>> 3051             if (iFields != null && iFields.length > 0) {
>>> ...
>>> 3060             }
>>> 3061             iFields = c.privateGetPublicFields();
>>> 3062         }
>>>
>>> ifaces is unused:
>>>
>>> 3047         Class<?>[] ifaces = getInterfaces();
>>>
>>> Nit: You could probably simplify code by replacing List<Field> fields with the LinkedHashSet directly, removing the need to create it conditionally.
>>>
>>> /Claes
>>>
>>>
>>> On 2017-11-29 21:15, Paul Sandoz wrote:
>>>> Hi,
>>>>
>>>> Please review:
>>>>
>>>>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186961-iface-static-fields-get/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186961-iface-static-fields-get/webrev/>
>>>>
>>>> There is a bug lurking, perhaps for a while, where diamond patterns for interface hierarchies can result in the incorrect reporting of fields when using reflection, see the test case.
>>>>
>>>> Since reflection data is cached i don?t see an advantage to retaining a set of of traversed interfaces, which is the root cause of the issue.
>>>>
>>>> The code is optimized for common cases and will for less common cases collect fields of interfaces into a temporary linked hash set (to preserve the order, perhaps not strictly necessary but i did not want to change that behaviour).
>>>>
>>>> Thanks,
>>>> Paul.


From brent.christian at oracle.com  Thu Nov 30 21:35:39 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 30 Nov 2017 13:35:39 -0800
Subject: RFR 8187222 : ClassLoader.getSystemClassLoader not clear if recursive
 initialization leads to ISE or unspecified error
Message-ID: <6d4e7e94-9e83-f215-0a2a-10f0dd3b69f4@oracle.com>

Hi,

Please review the following change:

Bug: https://bugs.openjdk.java.net/browse/JDK-8187222
Webrev: http://cr.openjdk.java.net/~bchristi/8187222/webrev.00/

The method description of ClassLoader.getSystemClassLoader() states (in 
regards to setting a custom system classloader):

"If circular initialization of the system class loader is detected then 
an unspecified error or exception is thrown."

This ambiguity in the method description can and should be removed.

The method also has a @throws tag:

* @throws  IllegalStateException
*          If invoked recursively during the construction of the class
*          loader specified by the "{@code java.system.class.loader}"
*          property.

JDK 8 threw an IllegalStateException.  This changed to an  InternalError 
in 9b111[1].

Throwing an IllegalStateException conforms to the @throws tag, and 
returns to the previous behavior of JDK 8 and (earlier on in) 9.  Also, 
as Alan points out in the bug, an InternalError looks like a bug in the 
JDK itself, whereas IllegalStateException better reflects that the issue 
likely lies in the custom classloader.

Automated build & test job passes cleanly.

Thanks,
-Brent

1. https://bugs.openjdk.java.net/browse/JDK-8142968


From paul.sandoz at oracle.com  Thu Nov 30 22:25:29 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 30 Nov 2017 14:25:29 -0800
Subject: RFR 8186961 Class.getFields() does not return fields of
 previously visited super interfaces/classes.
In-Reply-To: <3ad01601-35a7-80f2-b0d0-b4342043e6d2@oracle.com>
References: <929496D6-A4B3-4EF2-BDCB-D2504C1BECE3@oracle.com>
 <c3086c30-5974-365d-8958-3944d3bfcc64@oracle.com>
 <FBEBD1D0-6EB6-4C1C-BCDD-8C4776896ACB@oracle.com>
 <BC884ADD-32FF-4F04-A145-4A23F576CA97@oracle.com>
 <3ad01601-35a7-80f2-b0d0-b4342043e6d2@oracle.com>
Message-ID: <48D190E9-52B7-461E-BB3D-81F116ECAACC@oracle.com>



> On 30 Nov 2017, at 13:00, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> as expected this is quite a bit easier to follow. Thanks!
> 
> As any heavy use of reflection is likely to hit cached data, then heavily optimizing might be ill-advised here.
> 
> A simpler optimization might be to check if the class has any superclass or interfaces whatsoever first, since if not then publicFields == privateGetDeclaredField(true). This might reduce number of LinkedHashSets created for many trivial class hierarchies significantly for only a nominal increase in code complexity, and actually reduce the retained set a bit.
> 

I am resisting the temptation to do that right now, i threw away a highly optimal implementation, i liked it, but you might not :-) An intermediate solution is to create a pre-sized Field[][] and not be as smart about that allocation.

Mandy is gonna take a careful look next week.

Paul.

From claes.redestad at oracle.com  Thu Nov 30 22:41:40 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 30 Nov 2017 23:41:40 +0100
Subject: RFR 8186961 Class.getFields() does not return fields of
 previously visited super interfaces/classes.
In-Reply-To: <48D190E9-52B7-461E-BB3D-81F116ECAACC@oracle.com>
References: <929496D6-A4B3-4EF2-BDCB-D2504C1BECE3@oracle.com>
 <c3086c30-5974-365d-8958-3944d3bfcc64@oracle.com>
 <FBEBD1D0-6EB6-4C1C-BCDD-8C4776896ACB@oracle.com>
 <BC884ADD-32FF-4F04-A145-4A23F576CA97@oracle.com>
 <3ad01601-35a7-80f2-b0d0-b4342043e6d2@oracle.com>
 <48D190E9-52B7-461E-BB3D-81F116ECAACC@oracle.com>
Message-ID: <5a72e3ee-f5ed-2b1c-b2ea-367c84710116@oracle.com>



On 2017-11-30 23:25, Paul Sandoz wrote:
>
>> On 30 Nov 2017, at 13:00, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> Hi,
>>
>> as expected this is quite a bit easier to follow. Thanks!
>>
>> As any heavy use of reflection is likely to hit cached data, then heavily optimizing might be ill-advised here.
>>
>> A simpler optimization might be to check if the class has any superclass or interfaces whatsoever first, since if not then publicFields == privateGetDeclaredField(true). This might reduce number of LinkedHashSets created for many trivial class hierarchies significantly for only a nominal increase in code complexity, and actually reduce the retained set a bit.
>>
> I am resisting the temptation to do that right now, i threw away a highly optimal implementation, i liked it, but you might not :-) An intermediate solution is to create a pre-sized Field[][] and not be as smart about that allocation.

Joel points out the obvious fact that the only class that doesn't have a 
superclass is Object, so my optimization idea wouldn't be very effective 
without also checking that the super class isn't Object, making it less 
sweet as a middle-ground option.

Any optimization should probably be done as a follow-up, anyhow. The 
current patch looks fine as-is to me.

>
> Mandy is gonna take a careful look next week.

Yes, I'd not count my review as a capital-R review in this area. Too 
much history. :-)

/Claes

From xueming.shen at oracle.com  Thu Nov 30 22:46:15 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 30 Nov 2017 14:46:15 -0800
Subject: RFR JDK-8191918: tomcat gzip-compressed response bodies appear to
 be broken in update 151
Message-ID: <5A208A37.3030109@oracle.com>

Hi,

Please help review the change for  JDK-8191918:

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

This is the backport/identical change we have already putback into 
earlier update
releases for JDK-8189789. It includes two changes

(1) to replace the change we put into jdk9 for #8184306 with the "official"
change currently in zlib github repo 
(https://github.com/madler/zlib/issues/275)

http://cr.openjdk.java.net/~sherman/8184306
https://bugs.openjdk.java.net/browse/JDK-8184306

(2) to change the way we handle the returned result Z_BUF_ERROR. Now the
implementation expects that there might be bytes read from the input and 
bytes
written to the output buffer when the deflateParams()/deflate() returns
Z_BUF_ERROR. It is "interpreted as there is no enough buffer space for 
all output,
but the deflater has decoded input bytes and write out output bytes as 
many as
possible, come back with more available output space".

See related github/zlib discussions at #275 [1] and #305[2]

Thanks,
Sherman

[1] https://github.com/madler/zlib/issues/275
[2] https://github.com/madler/zlib/issues/305

From mandy.chung at oracle.com  Thu Nov 30 22:57:31 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 30 Nov 2017 14:57:31 -0800
Subject: RFR 8187222 : ClassLoader.getSystemClassLoader not clear if
 recursive initialization leads to ISE or unspecified error
In-Reply-To: <6d4e7e94-9e83-f215-0a2a-10f0dd3b69f4@oracle.com>
References: <6d4e7e94-9e83-f215-0a2a-10f0dd3b69f4@oracle.com>
Message-ID: <93aa28c5-3d83-7536-e574-60517342e481@oracle.com>



On 11/30/17 1:35 PM, Brent Christian wrote:
> Hi,
>
> Please review the following change:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8187222
> Webrev: http://cr.openjdk.java.net/~bchristi/8187222/webrev.00/
>

Thanks for fixing it.

This is indeed a bug that should throw ISE when 
ClassLoader.getSystemClassLoader is called during the initialization of 
the system class loader, as the spec states.

line 1921: I suggest to revise the message to make it clearer:
 ? ?? "getSystemClassLoader cannot be called during the system class 
loader instantiation"

In ClassLoader::initSystemClassLoader (line 1971), when the exception is 
thrown via Constructor::newInstance, it would be good to the cause of an 
InvocationTargetException like:

+??????????????? Throwable t = e;
+??????????????? if (e instanceof InvocationTargetException) {
+??????????????????? t = e.getCause();
+??????????????? }
+??????????????? throw new Error(t.getMessage(), t);

InitSystemLoaderTest.java verifies a working custom system class 
loader.? This recursive custom system loader test fits better as a new 
test rather a test case in InitSystemLoaderTest.java.

I suggest to rename ThrowingCustomLoader as RecursiveSystemLoader and 
make it as jtreg test with a static void main (maybe it should validate 
what getSystemClassLoader returns). ?? It can be made simpler e.g. line 
30-31, 45-47 and 54 are not needed.

Mandy