k

... 
Short
... 
Short
... 
Short
... 
Short
... 
Short


{@code
  376      *    public CompletableFuture onExit() {
  377      *       return delegate.onExit();
  378      *    }
  379      * }
{@code
>  376      *    public CompletableFuture onExit() {
>  377      *       return delegate.onExit();
>  378      *    }
>  379      * }









len
 tags as they are not supported in HTML5).

Thanks,
Alexander


From paul.sandoz at oracle.com  Tue Apr 28 12:30:04 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 28 Apr 2015 14:30:04 +0200
Subject: flatMap performance  Re: Additional method on Stream
In-Reply-To: <532350DE-510A-439C-B3A3-292151C5D1AE@oracle.com>
References: 		
	<10F26F8C-3F79-45B9-9D06-C2F0CDCF59D7@oracle.com>
	<553E8846.90202@gmail.com>
	<532350DE-510A-439C-B3A3-292151C5D1AE@oracle.com>
Message-ID: <8333D181-1735-4A15-A505-549F3DB093C6@oracle.com>


On Apr 28, 2015, at 12:57 PM, Paul Sandoz  wrote:

> Hi Peter,
> 
> You are correct in stating that flatMap has some overhead. 
> 
> There are optimizations in place for operating on one element and on the head of the stream that reduce the overhead.

I believe at least in the micro-benchmark cases i can reduce the flatMap time by about 60% with special stream impls for none and one element, rather than levering the stream builder directly. They are not that difficult if one uses a pattern like the following: 

static final class StreamOfOne implements Stream {
    boolean consumed;
    final T t;

    public StreamOfOne(T t) {
        this.t = t;
    }

    void consumed() {
        if (consumed) throw new IllegalStateException();
        consumed = true;
    }

    Stream fork() {
        consumed();
        return StreamSupport.stream(new Streams.StreamBuilderImpl<>(t), false);
    }

...

    @Override
    public Stream filter(Predicate predicate) {
        return fork().filter(predicate);
    }

...

    @Override
    public void forEach(Consumer action) {
        consumed();
        action.accept(t);
    }

...
}

There is a cost if intermediate operations and certain terminal operations (like collect) are invoked (that cost can be reduced by merging in a Spliterator implementation). For the common cases of simpler terminal operations, with flatMap, it's a win. So I am pondering adding such implementations. 

Also, FWIW, returning null rather than Stream.empty() is slightly faster. The latter results in more profiling effects.

Looking at generated code there is still a lot of "ceremony" that one would think hotspot would just able to do away with given the temporary Stream objects (me of course not understanding the intricate details of the C2 compiler).
 
Paul.


From paul.sandoz at oracle.com  Tue Apr 28 13:05:44 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 28 Apr 2015 15:05:44 +0200
Subject: Additional method on Stream
In-Reply-To: 
References: 
	
	
	<10F26F8C-3F79-45B9-9D06-C2F0CDCF59D7@oracle.com>
	
Message-ID: <019DEEBC-592A-4571-9B1B-DC8278E21A19@oracle.com>

On Apr 28, 2015, at 11:18 AM, Stephen Colebourne  wrote:
> On 27 April 2015 at 16:23, Paul Sandoz  wrote:
>> One issue is there are zillions of possible more specific convenience operations we could add. Everyone has their own favourite. Some static methods were recently added to Stream and Optional in preference to such operations.
>> 
>> There has to be a really good reason to add new operations. I realize this use-case might be more common than others but i am still yet to be convinced that it has sufficient weight given flatMap + lambda + static method.
>> 
>>> BTW, I wait months before making this request to see if it really was
>>> common enough a pattern, but I'm confident that it is now.
>> 
>> Were you aware of the pattern using flatMap during those months?
> 
> No, but if I had, I would not have used it. Its a rubbish workaround.
> It creates extra objects for no value. It involves statically
> importing another random utility. and it is less expressive - the
> desire is to filter by type, so I want the filter method.
> 

It's not just a filter method it's a specific, fused filter and map method.


> I do understand the desire to control methods, but API design isn't
> just about minimalism, it is also about meeting common use cases in a
> natural way. The parallel is of course a standard if (obj instanceof
> Foo) statement in Java, where developers often curse that they have to
> additionally cast obj after the check.

I believe Ceylon might also do contextual type narrowing. I dunno how easy it would to modify the Java language and javac to do similar things. A separate discussion to be had...

A library analogue could be:

  Optional Class.castIf(Object obj).

At the risk of increasing your wrath about flatMap, you could then do:

   s.flatMap(e -> Foo.castIf(e).stream())

Paul.


> Why can't the compiler just do
> it? (Kotlin does for example). While changing the Java language to do
> this is hard, changing the Stream API would be easy, and good value
> given a year's coding with streams.
> 
> Stephen



From paul.sandoz at oracle.com  Tue Apr 28 13:09:00 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 28 Apr 2015 15:09:00 +0200
Subject: Optional.orElseChain ?
In-Reply-To: <55350CD9.6040002@univ-mlv.fr>
References: <55317D2D.2040900@univ-mlv.fr>
	<19ADDB4E-2F30-4926-ACF3-2A775CE525CA@oracle.com>
	<55350CD9.6040002@univ-mlv.fr>
Message-ID: 

Hi Remi,

Chasing this up. I have not joined the dark-side just yet... but can you log an issue for this?

Thanks,
Paul.

On Apr 20, 2015, at 4:27 PM, Remi Forax  wrote:

> 
> On 04/20/2015 01:39 PM, Paul Sandoz wrote:
>> Hi Remi,
>> 
>> I was gonna propose the same trick you mentioned in your last email :-)
> 
> yes, it's the same as
>  optional.map(Stream::of).orElseGet(() -> Stream.empty())
> (I use orElseGet() because Stream.empty() is not a constant !).
> 
>> 
>> Similar tricks are possible for other cases like an equivalent of the recently added ifPresentOrElse, but that was considered a little obtuse.
>> 
>> 
>> On Apr 17, 2015, at 11:37 PM, Remi Forax  wrote:
>>> Hi guys,
>>> I was trying to write a code that uses Optional and I think one method is missing.
>>> 
>> There is always one more (or four more including the primitive variants) :-)
> 
> Yes, yet another one.
> 
> Note that technically, the only thing you need is to be able to do pattern matching on the two states,
> so if you have a way to do a flatMap() for the case with a value and a flatMap() for the case with no value,
> you're done.
> 
> Doing a flatMap for the case with no value is exactly what you have called 'or'.
> So it's yet another method to add but it's the last one :)
> 
>> 
>> We avoided supporting both the present and absent axes in the intermediate operations (e.g. additional methods with a supplier on absence).
>> 
>> This seems like a special intermediate operation, injecting an alternative optional on absence, rather than associated with the orElse terminal operations that return T:
>> 
>>   public Optional or(Supplier> mapper) {
>>       Objects.requireNonNull(mapper);
>>       if (isPresent()) {
>>           return this;
>>       } else {
>>           return Objects.requireNonNull(mapper.get());
>>       }
>>   }
> 
> yes,
> 
>> 
>> But it has some terminal like qualities to it. It really only makes sense once, or once after each flatMap. I am concerned that a bunch of these sprinkled within a sequence of fluent calls might make it hard to reason about.
>> 
>> As such a static method might be more appropriate, but then it's easy for someone to add one in their own code:
>> 
>> static  Optional or(Optional a, Supplier> b) {
>>     Objects.requireNonNull(a);
>>     Objects.requireNonNull(b);
>>     return a.isPresent() ? a : Objects.requireNonNull(b.get());
>> }
>> 
>> static  Optional or(Optional a, Optional b) {
>>     Objects.requireNonNull(a);
>>     Objects.requireNonNull(b);
>>     return a.isPresent() ? a : b;
>> }
>> 
>> Perhaps the non-obvious thing about these is a null return should not be allowed.
> 
> But mixing static methods and instance methods is not readable too,
> instance methods goes left to right and static methods goes right to left.
> 
>> 
>> I am somewhat on the fence here...
> 
> If you only knew the power of the Dark Side :)
> 
>> 
>> Paul.
> 
> R?mi
> 


From Roger.Riggs at Oracle.com  Tue Apr 28 13:32:42 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 28 Apr 2015 09:32:42 -0400
Subject: RFR 9: 8078826: Add diagnostic info for
	java/lang/Runtime/exec/LotsOfOutput.java fails intermittently
In-Reply-To: <8C853804-52E3-46C7-BB8C-E9B958DFE11D@oracle.com>
References: <553EA212.3030403@Oracle.com>
	<8C853804-52E3-46C7-BB8C-E9B958DFE11D@oracle.com>
Message-ID: <553F8BFA.2080306@Oracle.com>

Hi Joe, Chris,

Thanks for the review and suggestions.

I created a new issue for the diagnostic additions,
so the original bugid [1] can be used to accumulate additional information.

Issue:
8078826 : Add 
diagnostic info for java/lang/Runtime/exec/LotsOfOutput.java fails 
intermittently

Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-lots-8078826/

Roger
[1] JDK-8078582  
java/lang/Runtime/exec/LotsOfOutput.java fails intermittently with 
Process consumes memory

On 4/28/2015 3:56 AM, Chris Hegarty wrote:
> On 27 Apr 2015, at 21:54, Roger Riggs  wrote:
>
>> Please review adding diagnostic output to identify an intermittent failure.
> I agree with the adding additional diagnostic output. Maybe the bug description should be updated to indicate that?
>
>> Webrev:
>>   http://cr.openjdk.java.net/~rriggs/webrev-lots-8078582/
> I typically do not add the bug number to the @bug tag for non-product changes. I think this is right, since the test is not testing the product for that bug.
>
> -Chris.
>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8078582
>>
>> Thanks, Roger
>>



From chris.hegarty at oracle.com  Tue Apr 28 13:34:13 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 28 Apr 2015 14:34:13 +0100
Subject: RFR 9: 8078826: Add diagnostic info for
	java/lang/Runtime/exec/LotsOfOutput.java fails intermittently
In-Reply-To: <553F8BFA.2080306@Oracle.com>
References: <553EA212.3030403@Oracle.com>
	<8C853804-52E3-46C7-BB8C-E9B958DFE11D@oracle.com>
	<553F8BFA.2080306@Oracle.com>
Message-ID: 

Looks fine to me Roger.

-Chris.

On 28 Apr 2015, at 14:32, Roger Riggs  wrote:

> Hi Joe, Chris,
> 
> Thanks for the review and suggestions.
> 
> I created a new issue for the diagnostic additions,
> so the original bugid [1] can be used to accumulate additional information.
> 
> Issue:
> 8078826 : Add diagnostic info for java/lang/Runtime/exec/LotsOfOutput.java fails intermittently
> 
> Webrev:
>  http://cr.openjdk.java.net/~rriggs/webrev-lots-8078826/
> 
> Roger
> [1] JDK-8078582  java/lang/Runtime/exec/LotsOfOutput.java fails intermittently with Process consumes memory
> 
> On 4/28/2015 3:56 AM, Chris Hegarty wrote:
>> On 27 Apr 2015, at 21:54, Roger Riggs  wrote:
>> 
>>> Please review adding diagnostic output to identify an intermittent failure.
>> I agree with the adding additional diagnostic output. Maybe the bug description should be updated to indicate that?
>> 
>>> Webrev:
>>>  http://cr.openjdk.java.net/~rriggs/webrev-lots-8078582/
>> I typically do not add the bug number to the @bug tag for non-product changes. I think this is right, since the test is not testing the product for that bug.
>> 
>> -Chris.
>> 
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8078582
>>> 
>>> Thanks, Roger
>>> 
> 



From Roger.Riggs at Oracle.com  Tue Apr 28 14:06:38 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 28 Apr 2015 10:06:38 -0400
Subject: RFR [9] 8076224: some tidy warning from core libs
In-Reply-To: <553F7B90.5020601@oracle.com>
References: <553F7B90.5020601@oracle.com>
Message-ID: <553F93EE.60507@Oracle.com>

Hi Alexander,

Thanks for doing this cleanup.

Generally, avoiding line breaks of {@link xxxxx} across lines makes the 
source easier to read.
Its is ok to re-wrap lines to make the source more readable.

Otherwise, it looks fine to me.

Thanks, Roger


On 4/28/2015 8:22 AM, alexander stepanov wrote:
> Hello,
>
> Could you please review the following fix
> http://cr.openjdk.java.net/~avstepan/8076224/webrev.00/
>
> for
> https://bugs.openjdk.java.net/browse/JDK-8076224
>
> Just some HTML cleanup for docs (remove tidy warnings; remove some 
> unnecessary  tags as they are not supported in HTML5).
>
> Thanks,
> Alexander



From peter.levart at gmail.com  Tue Apr 28 14:07:08 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 28 Apr 2015 16:07:08 +0200
Subject: RFR: 8077846: improve locking strategy for readConfiguration(),
	reset(), and initializeGlobalHandlers()
In-Reply-To: <553F4136.5010500@oracle.com>
References: <553A7835.80209@oracle.com>	<553D8F0B.4070102@oracle.com>	<553DE503.2060608@oracle.com>	<553E29C7.8030800@oracle.com>
	<553E9685.1030809@oracle.com> <553F3DC4.4010104@gmail.com>
	<553F4136.5010500@oracle.com>
Message-ID: <553F940C.4050105@gmail.com>



On 04/28/2015 10:13 AM, Daniel Fuchs wrote:
> On 28/04/15 09:59, Peter Levart wrote:
>> On 04/27/2015 10:05 PM, David Holmes wrote:
>>>>>>> The patch proposes to use a Reantrant lock to deal with
>>>>>>> configurations changes in reset() and readConfiguration(),
>>>>>>> and avoids lock contention in initializeGlobalHandlers()
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8077846/webrev.00/
>>>>>>
>>>>>> How early in VM startup can logging be initialized and used? I just
>>>>>> wonder whether the use of ReentrantLock changes that at all?
>>>>>
>>>>> The initialization will not happen before the first class calls
>>>>> Logger.getLogger() or LogManager.getLogManager().
>>>>> In particular, it does not happen when the LogManager.class is loaded
>>>>> (that is: it no longer happens as  part of the class static
>>>>> initialization).
>>>>>
>>>>> I see Alan replied to that question as well...
>>>>
>>>> I'm just wondering what anyone might be running with a customized core
>>>> class that uses logging, and which may now fail due to the different
>>>> requirements.
>>>
>>> But then I just recalled that we used to use ReentrantLock via
>>> ConcurrentHashMap in Class, so introducing it early is not likely to
>>> cause any issue.
>>>
>>> Cheers,
>>> David
>>
>> Hi David, Daniel,
>>
>> CHM in JDK8 is not using ReentrantLock. But in JDK7, it is used, yes.
>>
>> But anyway, is there a special reason to use ReentrantLock here in
>> LogManager instead of Java built-in monitor lock? It is reentrant too.
>
> Hi Peter,
>
> That's one of the possibility I was envisaging - but I didn't feel very
> comfortable with synchronizing the whole method bodies.

Hi Daniel,

There is a synchronized (lock) { ... } syntax too.

>
> Using a reentrant lock also offers more possibility for evolutions
> like try locking or timeout locking - which you can't do with a
> monitor (unless you reinvent ReentrantLock)...

Ok, fair enough.

Now that I studied the synchronization in more detail, I must say, huh, 
it's very tricky. The state is composed of 3 boolean flags (that's 
theoretically 8 states) that are sometimes modified in pairs under lock 
and sometimes individually under lock and sometimes (shutdown hook) not 
under lock. So one has to pay attention to all possible interleavings.

Anyway, I think I found a bug (not synchronization related, but 
re-entrancy related). In initializeGlobalHandlers() In line 1629 you 
check if initializeGlobalHandlersCalled is true and return (a recursive 
call), but you do this inside the try block and therefore finally block 
is executed which sets initializeGlobalHandlersDone to true. This is 
prematurely, as loadLoggerHandlers might not be finished yet.

I think all possible states can be compressed into just 4 and this can 
be an int so that it is always updated atomically (easier to reason 
about). This way you can also get initial state to be default value (0).

Here's my attempt at simplifying this:

http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.01/

So what do you think?

Regards, Peter



>
> best regards,
>
> -- daniel
>>
>> Regards, Peter
>>
>



From daniel.fuchs at oracle.com  Tue Apr 28 14:57:11 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 28 Apr 2015 16:57:11 +0200
Subject: RFR: 8077846: improve locking strategy for readConfiguration(),
	reset(), and initializeGlobalHandlers()
In-Reply-To: <553F940C.4050105@gmail.com>
References: <553A7835.80209@oracle.com>	<553D8F0B.4070102@oracle.com>	<553DE503.2060608@oracle.com>	<553E29C7.8030800@oracle.com>
	<553E9685.1030809@oracle.com> <553F3DC4.4010104@gmail.com>
	<553F4136.5010500@oracle.com> <553F940C.4050105@gmail.com>
Message-ID: <553F9FC7.4020806@oracle.com>

Hi Peter,

On 28/04/15 16:07, Peter Levart wrote:

> Hi Daniel,
>
> There is a synchronized (lock) { ... } syntax too.
>
>>
>> Using a reentrant lock also offers more possibility for evolutions
>> like try locking or timeout locking - which you can't do with a
>> monitor (unless you reinvent ReentrantLock)...
>
> Ok, fair enough.
>
> Now that I studied the synchronization in more detail, I must say, huh,
> it's very tricky. The state is composed of 3 boolean flags (that's
> theoretically 8 states) that are sometimes modified in pairs under lock
> and sometimes individually under lock and sometimes (shutdown hook) not
> under lock. So one has to pay attention to all possible interleavings.

And I believed I did pay attention ;-)

> Anyway, I think I found a bug (not synchronization related, but
> re-entrancy related). In initializeGlobalHandlers() In line 1629 you
> check if initializeGlobalHandlersCalled is true and return (a recursive
> call), but you do this inside the try block and therefore finally block
> is executed which sets initializeGlobalHandlersDone to true. This is
> prematurely, as loadLoggerHandlers might not be finished yet.

Hey - very good catch! Argh.
I believe you're right. I should have used two nested
try finally block.

> I think all possible states can be compressed into just 4 and this can
> be an int so that it is always updated atomically (easier to reason
> about). This way you can also get initial state to be default value (0).

hmmm... I'm not sure it really simplifies things. Though I have to admit
that an initial state value 0 is appealing.
I was hopping to avoid a multi state int value - I still have
a preference for the 2 booleans...

>
> Here's my attempt at simplifying this:
>
> http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.01/

LogManager can be subclassed, and subclasses may override reset() for
different purposes.
So I'm afraid the Cleaner thread still needs to call te public
reset() method. The same unfortunately applies to
readConfiguration().

best regards,

-- daniel

> So what do you think?
>
> Regards, Peter
>
>
>
>>
>> best regards,
>>
>> -- daniel
>>>
>>> Regards, Peter
>>>
>>
>



From brian.burkhalter at oracle.com  Tue Apr 28 15:04:01 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 28 Apr 2015 08:04:01 -0700
Subject: [9] RFR of 8078672: Print and allow setting by Java property
	seeds used to initialize Random instances in java.lang numerics tests
In-Reply-To: <2EDA6421-2B3C-406C-83C9-B9FBFC75FDC5@oracle.com>
References: <3BF44A04-8B17-4C5B-8EC6-70BA948C0841@oracle.com>
	<553ED521.3020208@oracle.com>
	<9711F5D5-20DD-49AC-A237-FB054D7E342D@oracle.com>
	<2EDA6421-2B3C-406C-83C9-B9FBFC75FDC5@oracle.com>
Message-ID: <85512CBD-11DA-4EDB-96A1-7D222E941E5F@oracle.com>


On Apr 28, 2015, at 12:57 AM, Chris Hegarty  wrote:

>>> Perhaps the random number handling should be moved up to somewhere under jdk/test/lib? That would more easily let other type who want to handling random numbers in a uniform way use the library (at the cost of slightly more complicated jtreg tagging).
>> 
>> I?ll investigate tomorrow whether perhaps this functionality can be moved to a higher level with removal of duplication of code. The java/math/RandomSeed class changeset was the first in which I used @library so I should look over the jtreg tag list again.
> 
> I think having support for this in the jdk/test/lib/testlibrary/jdk/testlibrary would be good. I was going to suggest that too when the first changeset was pushed.
> 
> -Chris.

Hi Chris,

Yes I concur and will look into consolidating this code in a centralized location.

Thanks,

Brian

From peter.levart at gmail.com  Tue Apr 28 15:46:35 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 28 Apr 2015 17:46:35 +0200
Subject: RFR: 8077846: improve locking strategy for readConfiguration(),
	reset(), and initializeGlobalHandlers()
In-Reply-To: <553F9FC7.4020806@oracle.com>
References: <553A7835.80209@oracle.com>	<553D8F0B.4070102@oracle.com>	<553DE503.2060608@oracle.com>	<553E29C7.8030800@oracle.com>
	<553E9685.1030809@oracle.com> <553F3DC4.4010104@gmail.com>
	<553F4136.5010500@oracle.com> <553F940C.4050105@gmail.com>
	<553F9FC7.4020806@oracle.com>
Message-ID: <553FAB5B.3060605@gmail.com>



On 04/28/2015 04:57 PM, Daniel Fuchs wrote:
>> Here's my attempt at simplifying this:
>>
>> http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.01/ 
>>
>
> LogManager can be subclassed, and subclasses may override reset() for
> different purposes.
> So I'm afraid the Cleaner thread still needs to call te public
> reset() method. The same unfortunately applies to
> readConfiguration().
>
> best regards,
>
> -- daniel 

Um, yes of course. This can be fixed:

http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.02/

Regards, Peter



From alexander.v.stepanov at oracle.com  Tue Apr 28 16:09:28 2015
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Tue, 28 Apr 2015 19:09:28 +0300
Subject: RFR [9] 8076224: some tidy warning from core libs
In-Reply-To: <553F93EE.60507@Oracle.com>
References: <553F7B90.5020601@oracle.com> <553F93EE.60507@Oracle.com>
Message-ID: <553FB0B8.3050307@oracle.com>

Hello Roger,

Thanks!

 > Generally, avoiding line breaks of {@link xxxxx} across lines makes 
the source easier to read.

Please see the updated version (no line breaks inside of {@link} tags):
http://cr.openjdk.java.net/~avstepan/8076224/webrev.01/
(is that what expected?)

Regards,
Alexander

On 28.04.2015 17:06, Roger Riggs wrote:
> Hi Alexander,
>
> Thanks for doing this cleanup.
>
> Generally, avoiding line breaks of {@link xxxxx} across lines makes 
> the source easier to read.
> Its is ok to re-wrap lines to make the source more readable.
>
> Otherwise, it looks fine to me.
>
> Thanks, Roger
>
>
> On 4/28/2015 8:22 AM, alexander stepanov wrote:
>> Hello,
>>
>> Could you please review the following fix
>> http://cr.openjdk.java.net/~avstepan/8076224/webrev.00/
>>
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8076224
>>
>> Just some HTML cleanup for docs (remove tidy warnings; remove some 
>> unnecessary  tags as they are not supported in HTML5).
>>
>> Thanks,
>> Alexander
>



From huizhe.wang at oracle.com  Tue Apr 28 16:10:58 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 28 Apr 2015 09:10:58 -0700
Subject: RFR 9: 8078826: Add diagnostic info for
	java/lang/Runtime/exec/LotsOfOutput.java fails intermittently
In-Reply-To: 
References: <553EA212.3030403@Oracle.com>
	<8C853804-52E3-46C7-BB8C-E9B958DFE11D@oracle.com>
	<553F8BFA.2080306@Oracle.com>
	
Message-ID: <553FB112.2010900@oracle.com>

+1.

-Joe

On 4/28/2015 6:34 AM, Chris Hegarty wrote:
> Looks fine to me Roger.
>
> -Chris.
>
> On 28 Apr 2015, at 14:32, Roger Riggs  wrote:
>
>> Hi Joe, Chris,
>>
>> Thanks for the review and suggestions.
>>
>> I created a new issue for the diagnostic additions,
>> so the original bugid [1] can be used to accumulate additional information.
>>
>> Issue:
>> 8078826 : Add diagnostic info for java/lang/Runtime/exec/LotsOfOutput.java fails intermittently
>>
>> Webrev:
>>   http://cr.openjdk.java.net/~rriggs/webrev-lots-8078826/
>>
>> Roger
>> [1] JDK-8078582  java/lang/Runtime/exec/LotsOfOutput.java fails intermittently with Process consumes memory
>>
>> On 4/28/2015 3:56 AM, Chris Hegarty wrote:
>>> On 27 Apr 2015, at 21:54, Roger Riggs  wrote:
>>>
>>>> Please review adding diagnostic output to identify an intermittent failure.
>>> I agree with the adding additional diagnostic output. Maybe the bug description should be updated to indicate that?
>>>
>>>> Webrev:
>>>>   http://cr.openjdk.java.net/~rriggs/webrev-lots-8078582/
>>> I typically do not add the bug number to the @bug tag for non-product changes. I think this is right, since the test is not testing the product for that bug.
>>>
>>> -Chris.
>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8078582
>>>>
>>>> Thanks, Roger
>>>>



From lance.andersen at oracle.com  Tue Apr 28 16:25:14 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 28 Apr 2015 12:25:14 -0400
Subject: RFR [9] 8076224: some tidy warning from core libs
In-Reply-To: <553FB0B8.3050307@oracle.com>
References: <553F7B90.5020601@oracle.com> <553F93EE.60507@Oracle.com>
	<553FB0B8.3050307@oracle.com>
Message-ID: <70E99AB8-E9CF-4892-A324-529EAF4E6AE1@oracle.com>

This seems better now :-)

On Apr 28, 2015, at 12:09 PM, alexander stepanov  wrote:

> Hello Roger,
> 
> Thanks!
> 
> > Generally, avoiding line breaks of {@link xxxxx} across lines makes the source easier to read.
> 
> Please see the updated version (no line breaks inside of {@link} tags):
> http://cr.openjdk.java.net/~avstepan/8076224/webrev.01/
> (is that what expected?)
> 
> Regards,
> Alexander
> 
> On 28.04.2015 17:06, Roger Riggs wrote:
>> Hi Alexander,
>> 
>> Thanks for doing this cleanup.
>> 
>> Generally, avoiding line breaks of {@link xxxxx} across lines makes the source easier to read.
>> Its is ok to re-wrap lines to make the source more readable.
>> 
>> Otherwise, it looks fine to me.
>> 
>> Thanks, Roger
>> 
>> 
>> On 4/28/2015 8:22 AM, alexander stepanov wrote:
>>> Hello,
>>> 
>>> Could you please review the following fix
>>> http://cr.openjdk.java.net/~avstepan/8076224/webrev.00/
>>> 
>>> for
>>> https://bugs.openjdk.java.net/browse/JDK-8076224
>>> 
>>> Just some HTML cleanup for docs (remove tidy warnings; remove some unnecessary  tags as they are not supported in HTML5).
>>> 
>>> Thanks,
>>> Alexander
>> 
> 



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 Roger.Riggs at Oracle.com  Tue Apr 28 16:46:01 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 28 Apr 2015 12:46:01 -0400
Subject: [9] RFR of 8078672: Print and allow setting by Java property
	seeds used to initialize Random instances in java.lang numerics tests
In-Reply-To: <2EDA6421-2B3C-406C-83C9-B9FBFC75FDC5@oracle.com>
References: <3BF44A04-8B17-4C5B-8EC6-70BA948C0841@oracle.com>	<553ED521.3020208@oracle.com>	<9711F5D5-20DD-49AC-A237-FB054D7E342D@oracle.com>
	<2EDA6421-2B3C-406C-83C9-B9FBFC75FDC5@oracle.com>
Message-ID: <553FB949.3040605@Oracle.com>

Hi,

Note that there is some existing support for Random (and predetermined)
seeds in the Hotspot test library.
See hotspot/test/testlibrary/.../Utils.java

Soon(ish) to be coming to a testlibrary near you.

Roger


On 4/28/2015 3:57 AM, Chris Hegarty wrote:
> On 28 Apr 2015, at 01:44, Brian Burkhalter  wrote:
>
>> Hi Joe,
>>
>> On Apr 27, 2015, at 5:32 PM, joe darcy  wrote:
>>
>>> The patch looks pretty good. A few questions / comments:
>>>
>>> The test ParseHexFloatingPoint.java didn't get the "(use -Dseed=X to set PRNG seed)" addition; was that intentional?
>> No, it was an oversight. Thanks for catching it. I thought it had been there. Possibly something happened in moving the path to a different issue.
>>
>>> To save some space on the @summary line
>>>
>>>    Numerical tests for hexadecimal inputs to parseDouble, parseFloat
>>>
>>> could be replaced with
>>>
>>>    Numerical tests for hexadecimal inputs to parse{Double, Float}
>> Will change.
>>
>>> Could the java/math/RandomSeed class you added for java.math be used for this changeset instead of another another class with a large subset of the functionality?
>>>
>>> Perhaps the random number handling should be moved up to somewhere under jdk/test/lib? That would more easily let other type who want to handling random numbers in a uniform way use the library (at the cost of slightly more complicated jtreg tagging).
> I think having support for this in the jdk/test/lib/testlibrary/jdk/testlibrary would be good. I was going to suggest that too when the first changeset was pushed.
>
> -Chris.
>
>> I?ll investigate tomorrow whether perhaps this functionality can be moved to a higher level with removal of duplication of code. The java/math/RandomSeed class changeset was the first in which I used @library so I should look over the jtreg tag list again.
>>
>> Thanks,
>>
>> Brian



From Roger.Riggs at Oracle.com  Tue Apr 28 16:55:31 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 28 Apr 2015 12:55:31 -0400
Subject: RFR [9] 8076224: some tidy warning from core libs
In-Reply-To: <553FB0B8.3050307@oracle.com>
References: <553F7B90.5020601@oracle.com> <553F93EE.60507@Oracle.com>
	<553FB0B8.3050307@oracle.com>
Message-ID: <553FBB83.2090302@Oracle.com>

Yes, looks good to me,

Thanks, Roger


On 4/28/2015 12:09 PM, alexander stepanov wrote:
> Hello Roger,
>
> Thanks!
>
> > Generally, avoiding line breaks of {@link xxxxx} across lines makes 
> the source easier to read.
>
> Please see the updated version (no line breaks inside of {@link} tags):
> http://cr.openjdk.java.net/~avstepan/8076224/webrev.01/
> (is that what expected?)
>
> Regards,
> Alexander
>
> On 28.04.2015 17:06, Roger Riggs wrote:
>> Hi Alexander,
>>
>> Thanks for doing this cleanup.
>>
>> Generally, avoiding line breaks of {@link xxxxx} across lines makes 
>> the source easier to read.
>> Its is ok to re-wrap lines to make the source more readable.
>>
>> Otherwise, it looks fine to me.
>>
>> Thanks, Roger
>>
>>
>> On 4/28/2015 8:22 AM, alexander stepanov wrote:
>>> Hello,
>>>
>>> Could you please review the following fix
>>> http://cr.openjdk.java.net/~avstepan/8076224/webrev.00/
>>>
>>> for
>>> https://bugs.openjdk.java.net/browse/JDK-8076224
>>>
>>> Just some HTML cleanup for docs (remove tidy warnings; remove some 
>>> unnecessary  tags as they are not supported in HTML5).
>>>
>>> Thanks,
>>> Alexander
>>
>



From brian.burkhalter at oracle.com  Tue Apr 28 16:57:41 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 28 Apr 2015 09:57:41 -0700
Subject: [9] RFR of 8078672: Print and allow setting by Java property
	seeds used to initialize Random instances in java.lang numerics tests
In-Reply-To: <553FB949.3040605@Oracle.com>
References: <3BF44A04-8B17-4C5B-8EC6-70BA948C0841@oracle.com>	<553ED521.3020208@oracle.com>	<9711F5D5-20DD-49AC-A237-FB054D7E342D@oracle.com>
	<2EDA6421-2B3C-406C-83C9-B9FBFC75FDC5@oracle.com>
	<553FB949.3040605@Oracle.com>
Message-ID: 

Thanks, Roger, I?ll take a look. Perhaps it might be better to defer this present effort until this happens.

Brian

On Apr 28, 2015, at 9:46 AM, Roger Riggs  wrote:

> Note that there is some existing support for Random (and predetermined)
> seeds in the Hotspot test library.
> See hotspot/test/testlibrary/.../Utils.java
> 
> Soon(ish) to be coming to a testlibrary near you.



From alexander.v.stepanov at oracle.com  Tue Apr 28 17:18:32 2015
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Tue, 28 Apr 2015 20:18:32 +0300
Subject: RFR [9] 8076224: some tidy warning from core libs
In-Reply-To: <70E99AB8-E9CF-4892-A324-529EAF4E6AE1@oracle.com>
References: <553F7B90.5020601@oracle.com> <553F93EE.60507@Oracle.com>
	<553FB0B8.3050307@oracle.com>
	<70E99AB8-E9CF-4892-A324-529EAF4E6AE1@oracle.com>
Message-ID: <553FC0E8.4060607@oracle.com>

thanks!

On 28.04.2015 19:25, Lance Andersen wrote:
> This seems better now :-)
>
> On Apr 28, 2015, at 12:09 PM, alexander stepanov 
>  > wrote:
>
>> Hello Roger,
>>
>> Thanks!
>>
>> > Generally, avoiding line breaks of {@link xxxxx} across lines makes 
>> the source easier to read.
>>
>> Please see the updated version (no line breaks inside of {@link} tags):
>> http://cr.openjdk.java.net/~avstepan/8076224/webrev.01/ 
>> 
>> (is that what expected?)
>>
>> Regards,
>> Alexander
>>
>> On 28.04.2015 17:06, Roger Riggs wrote:
>>> Hi Alexander,
>>>
>>> Thanks for doing this cleanup.
>>>
>>> Generally, avoiding line breaks of {@link xxxxx} across lines makes 
>>> the source easier to read.
>>> Its is ok to re-wrap lines to make the source more readable.
>>>
>>> Otherwise, it looks fine to me.
>>>
>>> Thanks, Roger
>>>
>>>
>>> On 4/28/2015 8:22 AM, alexander stepanov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the following fix
>>>> http://cr.openjdk.java.net/~avstepan/8076224/webrev.00/
>>>>
>>>> for
>>>> https://bugs.openjdk.java.net/browse/JDK-8076224
>>>>
>>>> Just some HTML cleanup for docs (remove tidy warnings; remove some 
>>>> unnecessary  tags as they are not supported in HTML5).
>>>>
>>>> Thanks,
>>>> Alexander
>>>
>>
>
> 
> 
> 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 mikhail.cherkasov at oracle.com  Tue Apr 28 19:35:24 2015
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Tue, 28 Apr 2015 22:35:24 +0300
Subject: sync in share native code
Message-ID: <553FE0FC.6050101@oracle.com>

Hi there,

I need to add synchronization in shared native code, it can't be moved 
to java side.
But for now it's not clear how to make it cross platform.

Maybe someone already has similar experience? Furthermore maybe jdk 
already has a cross platform implementation of mutex
in native code?

Thanks,
Mikhail.


From Roger.Riggs at Oracle.com  Tue Apr 28 21:22:20 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 28 Apr 2015 17:22:20 -0400
Subject: RFR JDK-8029804: (spec) BufferedWriter.write(String, int, int)
	IndexOutOfBoundsException
In-Reply-To: 
References: 
Message-ID: <553FFA0C.4060204@Oracle.com>

Hi Pavel,

That looks ok.

It would be a bit more comfortable to read and compare with the parent 
contract
if it could use the len < 0 phrase.
But as written it clearly matches the implementation and is logically 
equivalent.

Roger


On 4/27/2015 12:48 PM, Pavel Rappo wrote:
> Hi everyone,
>
> Could you please review my change for JDK-8029804
>
> http://cr.openjdk.java.net/~prappo/8029804/webrev.00/
>
> -------------------------------------------------------------------------------
> There is an issue where java.io.BufferedWriter.write(String s, int off, int len)
> doesn't check required preconditions for `off` and `len` and goes straight to
> the algorithm procedures. As a result an acceptable region for (off, len) is
> wider than the one declared by parent. For example, following calls should throw
> IndexOutOfBoundsException, but they don't:
>
>      bw.write("abc", 10,   0)
>      bw.write("abc",  5,  -1)
>      bw.write("abc", -7,   0)
>      bw.write("abc", -2,  -3)
>      bw.write("abc",  3, Integer.MAX_VALUE)
>
> The problem though is not in the bug itself (it's been there for a long time),
> but rather than the amendment to the javadoc which supposed to describe this
> divergence is not comprehensive:
>
>       *  If the value of the len parameter is negative then no
>       * characters are written.  This is contrary to the specification of this
>       * method in the {@linkplain java.io.Writer#write(java.lang.String,int,int)
>       * superclass}, which requires that an {@link IndexOutOfBoundsException} be
>       * thrown.
>
> Suggested solution is to update the javadoc and provide a test that gives a
> certain amount of confidence that the javadoc captures the actual contract.
>
>   -Pavel
>



From joe.darcy at oracle.com  Tue Apr 28 23:53:41 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 28 Apr 2015 16:53:41 -0700
Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness
In-Reply-To: <553A85A8.7080207@oracle.com>
References: <553703BC.1070504@oracle.com>
	<5539A249.7050105@oracle.com>	<5539DB71.2070605@oracle.com>
	<553A85A8.7080207@oracle.com>
Message-ID: <55401D85.1090306@oracle.com>

Hello,

I'd like to get this changeset, or something close to it, pushed soon so 
we can start taking advantage of better failure triaging.

Any further concerns?

Thanks,

-Joe

On 4/24/2015 11:04 AM, joe darcy wrote:
> On 4/23/2015 10:58 PM, Alan Bateman wrote:
>> On 24/04/2015 02:54, Joseph D. Darcy wrote:
>>> Hello,
>>>
>>> Any additional comments on marking with tests in question with a 
>>> "randomness" keyword?
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>> I don't object to this keyword although I should say that most of the 
>> (apparent) randomness that I've seen hasn't been because of tests 
>> using Random but rather because of non-deterministic sequence of 
>> tests running in the same VM. The switch from othervm to agentvm a 
>> few years ago took a long time to weed out issues, same thing (even 
>> more) with -concurrency. Another source of apparent randomness is 
>> just having a large pool of machines and where machines are randomly 
>> selected to execute the tests.
>>
>> I agree with your comments that tests using Random should have report 
>> the seed and a have a way to re-run with the same value. It could 
>> help with some cases.
>>
>> One thing that isn't clear to me is how this keyword will be 
>> maintained. If I modify a test and replace the use of Random then I 
>> guess I need to remember to also remove this label. When I add a test 
>> that uses Random ...   Just wondering if there is a tool to do the 
>> tests analysis, identify the use of specific APIs ,and help identify 
>> where the keyword might be missing or not needed.
>>
>
> The goal of the keyword is to enable better analysis of bug failures. 
> We (still) have some intermittent test failures in the platform, some 
> probably remaining from -concurrency issues and some due to 
> inconsistent machine config issues on the test farms. However, there 
> is reason to believe some of the tests also fail because of the use of 
> randomness in the generation of test cases. For example, the test
>
>     java/lang/invoke/MethodHandles/CatchExceptionTest.java
>
> fails about once every three hundred runs when the random cases it 
> generates trigger an error condition. Setting the seed to known-bad 
> value causes the test to fail consistently (JDK-8055269). I have 
> suspicions some of our other intermittently failing tests are in a 
> similar but undiagnosed situation.
>
> If a test uses randomness, I think the default assumed cause for a 
> test failure should switch from environmental causes (bad machine 
> config, etc.) to the random behavior. Therefore, when a random-using 
> test fails, I think the failure analysis needs to include recording of 
> the bad seed to see if the failure is reproducible / deterministic 
> with a fixed seed value.
>
> I was very surprised by the large number of random-using tests in the 
> JDK regression tests. Nearly all of these have been stably passing for 
> many years. After the one-time cost of this large update to add the 
> keywords, there would be a small amount of incremental test 
> maintenance as new random-using tests were added or the randomness 
> value of a test changed. However, I would expect whether or not a test 
> used randomness to be a property of a test that very rarely changed.
>
> Thanks,
>
> -Joe



From Alan.Bateman at oracle.com  Wed Apr 29 06:51:18 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Apr 2015 07:51:18 +0100
Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness
In-Reply-To: <55401D85.1090306@oracle.com>
References: <553703BC.1070504@oracle.com>
	<5539A249.7050105@oracle.com>	<5539DB71.2070605@oracle.com>
	<553A85A8.7080207@oracle.com> <55401D85.1090306@oracle.com>
Message-ID: <55407F66.1030905@oracle.com>



On 29/04/2015 00:53, Joseph D. Darcy wrote:
> Hello,
>
> I'd like to get this changeset, or something close to it, pushed soon 
> so we can start taking advantage of better failure triaging.
>
> Any further concerns?
I should have been clearer, I don't have any issues with the proposed 
patch. I was mostly probing to see how the keyword would be used as it 
looks to be more for triage rather than test selection.

-Alan


From peter.levart at gmail.com  Wed Apr 29 09:33:38 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 29 Apr 2015 11:33:38 +0200
Subject: RFR: JDK-8074003
	java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized
In-Reply-To: 
References: <553E62D6.9030102@gmail.com>
	
Message-ID: <5540A572.5@gmail.com>


On 04/27/2015 06:51 PM, Stephen Colebourne wrote:
> One additional change is needed. The compareTo() method can rely on
> the new epochSecond field as well.
> Otherwise good!
> Stephen

Hi Stephen,

LocalDateTime (transition) has nanosecond precision. It may be that 
transitions loaded from file in ZoneRules only have second precisions, 
but ZoneOffsetTransition is a public class with public factory method 
that takes a LocalDateTime transition parameter, so I think compareTo() 
can't rely on epochSecond alone. But epochSecond can be used as 
optimization in compareTo() as well as equals():

http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.03/

An alternative to keeping epochSecond field in ZoneOffsetTransition 
would be to keep a reference to Instant instead. Instant contains an 
epochSecond field (as well as nanos) and could be used for both 
toEpochSecond() and getInstant() methods.

What do you think?

It also occurred to me that serialization format of ZoneOffsetTransition 
is not adequate currently as it looses nanosecond precision.

Regards, Peter

>
> On 27 April 2015 at 17:24, Peter Levart  wrote:
>> Hi again,
>>
>> Here's another optimization to be reviewed that has been discussed a while
>> ago (just rebased from webrev.01) and approved by Stephen:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.02/
>>
>>
>> The discussion about it is intermingled with the ZoneId.systemDefault()
>> discussion and starts about here:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031873.html
>>
>>
>> The rationale for the optimization is speeding-up the conversion from epoch
>> time to LocalDateTime. This conversion uses ZoneRules.getOffset(Instant)
>> where there is a loop over ZoneOffsetTransition[] array that searches for
>> 1st transition that has its toEpochSecond value less than the Instant's
>> epochSecond. This calls ZoneOffsetTransition.toEpochSecond repeatedly,
>> converting ZoneOffsetTransition.transition which is a LocalDateTime to
>> epochSecond. This repeated conversion is unnecessary, as
>> ZoneOffsetTransition[] array is part of ZoneRules which is cached.
>> Optimizing the ZoneOffsetTransition implementation (keeping both
>> LocalDateTime variant and eposhSecond variant of transition time as the
>> object's state) speeds up this conversion.
>>
>>
>> Regards, Peter
>>



From scolebourne at joda.org  Wed Apr 29 09:43:00 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 29 Apr 2015 10:43:00 +0100
Subject: RFR: JDK-8074003
	java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized
In-Reply-To: <5540A572.5@gmail.com>
References: <553E62D6.9030102@gmail.com>
	
	<5540A572.5@gmail.com>
Message-ID: 

On the LocalDateTime being passed in with nanoseconds, that was an
unconsidered use case. The whole offset system relies on second based
offsets, so it should really be validated/truncated to remove nanos.
That way the equals/compareTo could be simplified again. Seems like a
separate issue, but perhaps could be tackled here. You need an Oracle
sponsor to tell you ;-)

Stephen


On 29 April 2015 at 10:33, Peter Levart  wrote:
>
> On 04/27/2015 06:51 PM, Stephen Colebourne wrote:
>>
>> One additional change is needed. The compareTo() method can rely on
>> the new epochSecond field as well.
>> Otherwise good!
>> Stephen
>
>
> Hi Stephen,
>
> LocalDateTime (transition) has nanosecond precision. It may be that
> transitions loaded from file in ZoneRules only have second precisions, but
> ZoneOffsetTransition is a public class with public factory method that takes
> a LocalDateTime transition parameter, so I think compareTo() can't rely on
> epochSecond alone. But epochSecond can be used as optimization in
> compareTo() as well as equals():
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.03/
>
> An alternative to keeping epochSecond field in ZoneOffsetTransition would be
> to keep a reference to Instant instead. Instant contains an epochSecond
> field (as well as nanos) and could be used for both toEpochSecond() and
> getInstant() methods.
>
> What do you think?
>
> It also occurred to me that serialization format of ZoneOffsetTransition is
> not adequate currently as it looses nanosecond precision.
>
> Regards, Peter
>
>
>>
>> On 27 April 2015 at 17:24, Peter Levart  wrote:
>>>
>>> Hi again,
>>>
>>> Here's another optimization to be reviewed that has been discussed a
>>> while
>>> ago (just rebased from webrev.01) and approved by Stephen:
>>>
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.02/
>>>
>>>
>>> The discussion about it is intermingled with the ZoneId.systemDefault()
>>> discussion and starts about here:
>>>
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031873.html
>>>
>>>
>>> The rationale for the optimization is speeding-up the conversion from
>>> epoch
>>> time to LocalDateTime. This conversion uses ZoneRules.getOffset(Instant)
>>> where there is a loop over ZoneOffsetTransition[] array that searches for
>>> 1st transition that has its toEpochSecond value less than the Instant's
>>> epochSecond. This calls ZoneOffsetTransition.toEpochSecond repeatedly,
>>> converting ZoneOffsetTransition.transition which is a LocalDateTime to
>>> epochSecond. This repeated conversion is unnecessary, as
>>> ZoneOffsetTransition[] array is part of ZoneRules which is cached.
>>> Optimizing the ZoneOffsetTransition implementation (keeping both
>>> LocalDateTime variant and eposhSecond variant of transition time as the
>>> object's state) speeds up this conversion.
>>>
>>>
>>> Regards, Peter
>>>
>


From Roger.Riggs at Oracle.com  Wed Apr 29 13:23:54 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 29 Apr 2015 09:23:54 -0400
Subject: RFR: JDK-8074003
	java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized
In-Reply-To: 
References: <553E62D6.9030102@gmail.com>		<5540A572.5@gmail.com>
	
Message-ID: <5540DB6A.1020005@Oracle.com>

Hi Stephen, Peter,

I think we should clarify the constructor to indicate that nanoseconds 
are truncated/ignored.
That should be done as a separate request since it is a spec change and 
needs additional review.

Roger


On 4/29/2015 5:43 AM, Stephen Colebourne wrote:
> On the LocalDateTime being passed in with nanoseconds, that was an
> unconsidered use case. The whole offset system relies on second based
> offsets, so it should really be validated/truncated to remove nanos.
> That way the equals/compareTo could be simplified again. Seems like a
> separate issue, but perhaps could be tackled here. You need an Oracle
> sponsor to tell you ;-)
>
> Stephen
>
>
> On 29 April 2015 at 10:33, Peter Levart  wrote:
>> On 04/27/2015 06:51 PM, Stephen Colebourne wrote:
>>> One additional change is needed. The compareTo() method can rely on
>>> the new epochSecond field as well.
>>> Otherwise good!
>>> Stephen
>>
>> Hi Stephen,
>>
>> LocalDateTime (transition) has nanosecond precision. It may be that
>> transitions loaded from file in ZoneRules only have second precisions, but
>> ZoneOffsetTransition is a public class with public factory method that takes
>> a LocalDateTime transition parameter, so I think compareTo() can't rely on
>> epochSecond alone. But epochSecond can be used as optimization in
>> compareTo() as well as equals():
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.03/
>>
>> An alternative to keeping epochSecond field in ZoneOffsetTransition would be
>> to keep a reference to Instant instead. Instant contains an epochSecond
>> field (as well as nanos) and could be used for both toEpochSecond() and
>> getInstant() methods.
>>
>> What do you think?
>>
>> It also occurred to me that serialization format of ZoneOffsetTransition is
>> not adequate currently as it looses nanosecond precision.
>>
>> Regards, Peter
>>
>>
>>> On 27 April 2015 at 17:24, Peter Levart  wrote:
>>>> Hi again,
>>>>
>>>> Here's another optimization to be reviewed that has been discussed a
>>>> while
>>>> ago (just rebased from webrev.01) and approved by Stephen:
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.02/
>>>>
>>>>
>>>> The discussion about it is intermingled with the ZoneId.systemDefault()
>>>> discussion and starts about here:
>>>>
>>>>
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031873.html
>>>>
>>>>
>>>> The rationale for the optimization is speeding-up the conversion from
>>>> epoch
>>>> time to LocalDateTime. This conversion uses ZoneRules.getOffset(Instant)
>>>> where there is a loop over ZoneOffsetTransition[] array that searches for
>>>> 1st transition that has its toEpochSecond value less than the Instant's
>>>> epochSecond. This calls ZoneOffsetTransition.toEpochSecond repeatedly,
>>>> converting ZoneOffsetTransition.transition which is a LocalDateTime to
>>>> epochSecond. This repeated conversion is unnecessary, as
>>>> ZoneOffsetTransition[] array is part of ZoneRules which is cached.
>>>> Optimizing the ZoneOffsetTransition implementation (keeping both
>>>> LocalDateTime variant and eposhSecond variant of transition time as the
>>>> object's state) speeds up this conversion.
>>>>
>>>>
>>>> Regards, Peter
>>>>



From Roger.Riggs at Oracle.com  Wed Apr 29 13:31:14 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 29 Apr 2015 09:31:14 -0400
Subject: RFR: JDK-8074003
	java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized
In-Reply-To: <5540A572.5@gmail.com>
References: <553E62D6.9030102@gmail.com>	
	<5540A572.5@gmail.com>
Message-ID: <5540DD22.1000503@Oracle.com>

Hi Peter,

Point taken about the constructor and that should have a spec 
clarification to ignore the nanoseconds.
The issue is tracked with:
JDK-8079063  
ZoneOffsetTransition constructor should ignore nanoseconds

With that, the compareTo method can be simpler.  The rest looks fine.

Roger


On 4/29/2015 5:33 AM, Peter Levart wrote:
>
> On 04/27/2015 06:51 PM, Stephen Colebourne wrote:
>> One additional change is needed. The compareTo() method can rely on
>> the new epochSecond field as well.
>> Otherwise good!
>> Stephen
>
> Hi Stephen,
>
> LocalDateTime (transition) has nanosecond precision. It may be that 
> transitions loaded from file in ZoneRules only have second precisions, 
> but ZoneOffsetTransition is a public class with public factory method 
> that takes a LocalDateTime transition parameter, so I think 
> compareTo() can't rely on epochSecond alone. But epochSecond can be 
> used as optimization in compareTo() as well as equals():
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.03/ 
>
>
> An alternative to keeping epochSecond field in ZoneOffsetTransition 
> would be to keep a reference to Instant instead. Instant contains an 
> epochSecond field (as well as nanos) and could be used for both 
> toEpochSecond() and getInstant() methods.
>
> What do you think?
>
> It also occurred to me that serialization format of 
> ZoneOffsetTransition is not adequate currently as it looses nanosecond 
> precision.
>
> Regards, Peter
>
>>
>> On 27 April 2015 at 17:24, Peter Levart  wrote:
>>> Hi again,
>>>
>>> Here's another optimization to be reviewed that has been discussed a 
>>> while
>>> ago (just rebased from webrev.01) and approved by Stephen:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.02/ 
>>>
>>>
>>>
>>> The discussion about it is intermingled with the ZoneId.systemDefault()
>>> discussion and starts about here:
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031873.html 
>>>
>>>
>>>
>>> The rationale for the optimization is speeding-up the conversion 
>>> from epoch
>>> time to LocalDateTime. This conversion uses 
>>> ZoneRules.getOffset(Instant)
>>> where there is a loop over ZoneOffsetTransition[] array that 
>>> searches for
>>> 1st transition that has its toEpochSecond value less than the Instant's
>>> epochSecond. This calls ZoneOffsetTransition.toEpochSecond repeatedly,
>>> converting ZoneOffsetTransition.transition which is a LocalDateTime to
>>> epochSecond. This repeated conversion is unnecessary, as
>>> ZoneOffsetTransition[] array is part of ZoneRules which is cached.
>>> Optimizing the ZoneOffsetTransition implementation (keeping both
>>> LocalDateTime variant and eposhSecond variant of transition time as the
>>> object's state) speeds up this conversion.
>>>
>>>
>>> Regards, Peter
>>>
>



From aleksej.efimov at oracle.com  Wed Apr 29 14:37:29 2015
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 29 Apr 2015 17:37:29 +0300
Subject: RFR: 8077685: (tz) Support tzdata2015d
Message-ID: <5540ECA9.5040504@oracle.com>

Hi,

Please, review the fix for adding the latest tzdata2015d to JDK9.
The JTREG and JPRT tests were executed.
No failures were observed.

Thank you,
Aleksej

[1] JBS: https://bugs.openjdk.java.net/browse/JDK-8077685
[2] Webrev: http://cr.openjdk.java.net/~aefimov/tzdata/2015d/9/00


From peter.levart at gmail.com  Wed Apr 29 15:26:52 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 29 Apr 2015 17:26:52 +0200
Subject: RFR: JDK-8074003
	java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized
In-Reply-To: <5540DD22.1000503@Oracle.com>
References: <553E62D6.9030102@gmail.com>		<5540A572.5@gmail.com>
	<5540DD22.1000503@Oracle.com>
Message-ID: <5540F83C.2080100@gmail.com>



On 04/29/2015 03:31 PM, Roger Riggs wrote:
> Hi Peter,
>
> Point taken about the constructor and that should have a spec 
> clarification to ignore the nanoseconds.
> The issue is tracked with:
> JDK-8079063  
> ZoneOffsetTransition constructor should ignore nanoseconds
>
> With that, the compareTo method can be simpler.  The rest looks fine.
>
> Roger

Hi Roger,

Should I prepare a patch for both issues in one changeset as the correct 
compareTo/equals depends on the truncation or should I just pretend that 
truncation has been performed and make this change accordingly or should 
I 1st do the JDK-8079063 and then this one on top?

Also, getInstant() can be much simpler if the truncation is performed: 
return Instant.of(epochSecond);

Regards, Peter

>
>
> On 4/29/2015 5:33 AM, Peter Levart wrote:
>>
>> On 04/27/2015 06:51 PM, Stephen Colebourne wrote:
>>> One additional change is needed. The compareTo() method can rely on
>>> the new epochSecond field as well.
>>> Otherwise good!
>>> Stephen
>>
>> Hi Stephen,
>>
>> LocalDateTime (transition) has nanosecond precision. It may be that 
>> transitions loaded from file in ZoneRules only have second 
>> precisions, but ZoneOffsetTransition is a public class with public 
>> factory method that takes a LocalDateTime transition parameter, so I 
>> think compareTo() can't rely on epochSecond alone. But epochSecond 
>> can be used as optimization in compareTo() as well as equals():
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.03/ 
>>
>>
>> An alternative to keeping epochSecond field in ZoneOffsetTransition 
>> would be to keep a reference to Instant instead. Instant contains an 
>> epochSecond field (as well as nanos) and could be used for both 
>> toEpochSecond() and getInstant() methods.
>>
>> What do you think?
>>
>> It also occurred to me that serialization format of 
>> ZoneOffsetTransition is not adequate currently as it looses 
>> nanosecond precision.
>>
>> Regards, Peter
>>
>>>
>>> On 27 April 2015 at 17:24, Peter Levart  wrote:
>>>> Hi again,
>>>>
>>>> Here's another optimization to be reviewed that has been discussed 
>>>> a while
>>>> ago (just rebased from webrev.01) and approved by Stephen:
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.02/ 
>>>>
>>>>
>>>>
>>>> The discussion about it is intermingled with the 
>>>> ZoneId.systemDefault()
>>>> discussion and starts about here:
>>>>
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031873.html 
>>>>
>>>>
>>>>
>>>> The rationale for the optimization is speeding-up the conversion 
>>>> from epoch
>>>> time to LocalDateTime. This conversion uses 
>>>> ZoneRules.getOffset(Instant)
>>>> where there is a loop over ZoneOffsetTransition[] array that 
>>>> searches for
>>>> 1st transition that has its toEpochSecond value less than the 
>>>> Instant's
>>>> epochSecond. This calls ZoneOffsetTransition.toEpochSecond repeatedly,
>>>> converting ZoneOffsetTransition.transition which is a LocalDateTime to
>>>> epochSecond. This repeated conversion is unnecessary, as
>>>> ZoneOffsetTransition[] array is part of ZoneRules which is cached.
>>>> Optimizing the ZoneOffsetTransition implementation (keeping both
>>>> LocalDateTime variant and eposhSecond variant of transition time as 
>>>> the
>>>> object's state) speeds up this conversion.
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>
>



From Roger.Riggs at Oracle.com  Wed Apr 29 15:35:15 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 29 Apr 2015 11:35:15 -0400
Subject: RFR: JDK-8074003
	java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized
In-Reply-To: <5540F83C.2080100@gmail.com>
References: <553E62D6.9030102@gmail.com>		<5540A572.5@gmail.com>
	<5540DD22.1000503@Oracle.com> <5540F83C.2080100@gmail.com>
Message-ID: <5540FA33.60009@Oracle.com>

Hi Peter,

There should be two changesets; so pretend the truncation has been 
performed for this change.
It maybe useful to backport the performance improvement to jdk 8 but the 
spec change
will have to be in 9 (or wait for a maintenance release).

The simplification of toInstant can happen with the changeset for 8079063.

Thanks, Roger


On 4/29/2015 11:26 AM, Peter Levart wrote:
>
>
> On 04/29/2015 03:31 PM, Roger Riggs wrote:
>> Hi Peter,
>>
>> Point taken about the constructor and that should have a spec 
>> clarification to ignore the nanoseconds.
>> The issue is tracked with:
>> JDK-8079063  
>> ZoneOffsetTransition constructor should ignore nanoseconds
>>
>> With that, the compareTo method can be simpler.  The rest looks fine.
>>
>> Roger
>
> Hi Roger,
>
> Should I prepare a patch for both issues in one changeset as the 
> correct compareTo/equals depends on the truncation or should I just 
> pretend that truncation has been performed and make this change 
> accordingly or should I 1st do the JDK-8079063 and then this one on top?
>
> Also, getInstant() can be much simpler if the truncation is performed: 
> return Instant.of(epochSecond);
>
> Regards, Peter
>
>>
>>
>> On 4/29/2015 5:33 AM, Peter Levart wrote:
>>>
>>> On 04/27/2015 06:51 PM, Stephen Colebourne wrote:
>>>> One additional change is needed. The compareTo() method can rely on
>>>> the new epochSecond field as well.
>>>> Otherwise good!
>>>> Stephen
>>>
>>> Hi Stephen,
>>>
>>> LocalDateTime (transition) has nanosecond precision. It may be that 
>>> transitions loaded from file in ZoneRules only have second 
>>> precisions, but ZoneOffsetTransition is a public class with public 
>>> factory method that takes a LocalDateTime transition parameter, so I 
>>> think compareTo() can't rely on epochSecond alone. But epochSecond 
>>> can be used as optimization in compareTo() as well as equals():
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.03/ 
>>>
>>>
>>> An alternative to keeping epochSecond field in ZoneOffsetTransition 
>>> would be to keep a reference to Instant instead. Instant contains an 
>>> epochSecond field (as well as nanos) and could be used for both 
>>> toEpochSecond() and getInstant() methods.
>>>
>>> What do you think?
>>>
>>> It also occurred to me that serialization format of 
>>> ZoneOffsetTransition is not adequate currently as it looses 
>>> nanosecond precision.
>>>
>>> Regards, Peter
>>>
>>>>
>>>> On 27 April 2015 at 17:24, Peter Levart  
>>>> wrote:
>>>>> Hi again,
>>>>>
>>>>> Here's another optimization to be reviewed that has been discussed 
>>>>> a while
>>>>> ago (just rebased from webrev.01) and approved by Stephen:
>>>>>
>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.02/ 
>>>>>
>>>>>
>>>>>
>>>>> The discussion about it is intermingled with the 
>>>>> ZoneId.systemDefault()
>>>>> discussion and starts about here:
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031873.html 
>>>>>
>>>>>
>>>>>
>>>>> The rationale for the optimization is speeding-up the conversion 
>>>>> from epoch
>>>>> time to LocalDateTime. This conversion uses 
>>>>> ZoneRules.getOffset(Instant)
>>>>> where there is a loop over ZoneOffsetTransition[] array that 
>>>>> searches for
>>>>> 1st transition that has its toEpochSecond value less than the 
>>>>> Instant's
>>>>> epochSecond. This calls ZoneOffsetTransition.toEpochSecond 
>>>>> repeatedly,
>>>>> converting ZoneOffsetTransition.transition which is a 
>>>>> LocalDateTime to
>>>>> epochSecond. This repeated conversion is unnecessary, as
>>>>> ZoneOffsetTransition[] array is part of ZoneRules which is cached.
>>>>> Optimizing the ZoneOffsetTransition implementation (keeping both
>>>>> LocalDateTime variant and eposhSecond variant of transition time 
>>>>> as the
>>>>> object's state) speeds up this conversion.
>>>>>
>>>>>
>>>>> Regards, Peter
>>>>>
>>>
>>
>



From brian.burkhalter at oracle.com  Wed Apr 29 22:55:57 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 29 Apr 2015 15:55:57 -0700
Subject: [9] RFR of 8078672: Print and allow setting by Java property
	seeds used to initialize Random instances in java.lang numerics tests
In-Reply-To: <85512CBD-11DA-4EDB-96A1-7D222E941E5F@oracle.com>
References: <3BF44A04-8B17-4C5B-8EC6-70BA948C0841@oracle.com>
	<553ED521.3020208@oracle.com>
	<9711F5D5-20DD-49AC-A237-FB054D7E342D@oracle.com>
	<2EDA6421-2B3C-406C-83C9-B9FBFC75FDC5@oracle.com>
	<85512CBD-11DA-4EDB-96A1-7D222E941E5F@oracle.com>
Message-ID: <3BC685C9-5D43-4F29-8D1D-A73087EA9E7D@oracle.com>

Continuing the conversation about:

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

with an updated patch:

http://cr.openjdk.java.net/~bpb/8078672/webrev.01/.

Please review at your convenience.

Summary:

1) test/java/lang/RandomFactory.java is moved to test/lib/testlibrary/jdk/testlibrary/ (with respect to the previous patch but not visible in the webrev) and getSplittableRandom() is added.

2) the java/lang/{Double,Integer,Long,Math} tests modified in the previous patch are updated to use RandomFactory in its new, generic location.

3) the java/math/Big{Decimal,Integer} tests which used test/java/math/RandomSeed are modified to use RandomFactory.

4) test/java/math/RandomSeed.java is removed.

All tests pass locally on OS X and a job testing jdk_lang and jdk_math has been submitted to the usual set of platforms.

Thanks,

Brian

On Apr 28, 2015, at 8:04 AM, Brian Burkhalter  wrote:

> On Apr 28, 2015, at 12:57 AM, Chris Hegarty  wrote:
> 
>>>> Perhaps the random number handling should be moved up to somewhere under jdk/test/lib? That would more easily let other type who want to handling random numbers in a uniform way use the library (at the cost of slightly more complicated jtreg tagging).
>>> 
>>> I?ll investigate tomorrow whether perhaps this functionality can be moved to a higher level with removal of duplication of code. The java/math/RandomSeed class changeset was the first in which I used @library so I should look over the jtreg tag list again.
>> 
>> I think having support for this in the jdk/test/lib/testlibrary/jdk/testlibrary would be good. I was going to suggest that too when the first changeset was pushed.
>> 
>> -Chris.
> 
> Hi Chris,
> 
> Yes I concur and will look into consolidating this code in a centralized location.
> 
> Thanks,
> 
> Brian



From joe.darcy at oracle.com  Wed Apr 29 23:03:47 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 29 Apr 2015 16:03:47 -0700
Subject: [9] RFR of 8078672: Print and allow setting by Java property
	seeds used to initialize Random instances in java.lang numerics tests
In-Reply-To: <3BC685C9-5D43-4F29-8D1D-A73087EA9E7D@oracle.com>
References: <3BF44A04-8B17-4C5B-8EC6-70BA948C0841@oracle.com>	<553ED521.3020208@oracle.com>	<9711F5D5-20DD-49AC-A237-FB054D7E342D@oracle.com>	<2EDA6421-2B3C-406C-83C9-B9FBFC75FDC5@oracle.com>	<85512CBD-11DA-4EDB-96A1-7D222E941E5F@oracle.com>
	<3BC685C9-5D43-4F29-8D1D-A73087EA9E7D@oracle.com>
Message-ID: <55416353.7050602@oracle.com>

Hi Brian,

Looks good. If the new RandomFactory.java came from the old RandomSeed, 
it would be preferable if the old file was hg mv'ed to the new one.

Thanks,

-Joe

On 4/29/2015 3:55 PM, Brian Burkhalter wrote:
> Continuing the conversation about:
>
> https://bugs.openjdk.java.net/browse/JDK-8078672
>
> with an updated patch:
>
> http://cr.openjdk.java.net/~bpb/8078672/webrev.01/.
>
> Please review at your convenience.
>
> Summary:
>
> 1) test/java/lang/RandomFactory.java is moved to test/lib/testlibrary/jdk/testlibrary/ (with respect to the previous patch but not visible in the webrev) and getSplittableRandom() is added.
>
> 2) the java/lang/{Double,Integer,Long,Math} tests modified in the previous patch are updated to use RandomFactory in its new, generic location.
>
> 3) the java/math/Big{Decimal,Integer} tests which used test/java/math/RandomSeed are modified to use RandomFactory.
>
> 4) test/java/math/RandomSeed.java is removed.
>
> All tests pass locally on OS X and a job testing jdk_lang and jdk_math has been submitted to the usual set of platforms.
>
> Thanks,
>
> Brian
>
> On Apr 28, 2015, at 8:04 AM, Brian Burkhalter  wrote:
>
>> On Apr 28, 2015, at 12:57 AM, Chris Hegarty  wrote:
>>
>>>>> Perhaps the random number handling should be moved up to somewhere under jdk/test/lib? That would more easily let other type who want to handling random numbers in a uniform way use the library (at the cost of slightly more complicated jtreg tagging).
>>>> I?ll investigate tomorrow whether perhaps this functionality can be moved to a higher level with removal of duplication of code. The java/math/RandomSeed class changeset was the first in which I used @library so I should look over the jtreg tag list again.
>>> I think having support for this in the jdk/test/lib/testlibrary/jdk/testlibrary would be good. I was going to suggest that too when the first changeset was pushed.
>>>
>>> -Chris.
>> Hi Chris,
>>
>> Yes I concur and will look into consolidating this code in a centralized location.
>>
>> Thanks,
>>
>> Brian



From brian.burkhalter at oracle.com  Wed Apr 29 23:25:17 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 29 Apr 2015 16:25:17 -0700
Subject: [9] RFR of 8078672: Print and allow setting by Java property
	seeds used to initialize Random instances in java.lang numerics tests
In-Reply-To: <55416353.7050602@oracle.com>
References: <3BF44A04-8B17-4C5B-8EC6-70BA948C0841@oracle.com>	<553ED521.3020208@oracle.com>	<9711F5D5-20DD-49AC-A237-FB054D7E342D@oracle.com>	<2EDA6421-2B3C-406C-83C9-B9FBFC75FDC5@oracle.com>	<85512CBD-11DA-4EDB-96A1-7D222E941E5F@oracle.com>
	<3BC685C9-5D43-4F29-8D1D-A73087EA9E7D@oracle.com>
	<55416353.7050602@oracle.com>
Message-ID: <4D3543AB-058D-4CDE-8231-B2DB5322A29D@oracle.com>

Hi Joe,

No, RandomFactory would have been added by the previous webrev.00 version of the patch, i.e., RandomFactory did not come from RandomSeed.

Is this reasonable?

Thanks,

Brian

On Apr 29, 2015, at 4:03 PM, joe darcy  wrote:

> Looks good. If the new RandomFactory.java came from the old RandomSeed, it would be preferable if the old file was hg mv'ed to the new one.



From joe.darcy at oracle.com  Wed Apr 29 23:26:42 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 29 Apr 2015 16:26:42 -0700
Subject: [9] RFR of 8078672: Print and allow setting by Java property
	seeds used to initialize Random instances in java.lang numerics tests
In-Reply-To: <4D3543AB-058D-4CDE-8231-B2DB5322A29D@oracle.com>
References: <3BF44A04-8B17-4C5B-8EC6-70BA948C0841@oracle.com>	<553ED521.3020208@oracle.com>	<9711F5D5-20DD-49AC-A237-FB054D7E342D@oracle.com>	<2EDA6421-2B3C-406C-83C9-B9FBFC75FDC5@oracle.com>	<85512CBD-11DA-4EDB-96A1-7D222E941E5F@oracle.com>
	<3BC685C9-5D43-4F29-8D1D-A73087EA9E7D@oracle.com>
	<55416353.7050602@oracle.com>
	<4D3543AB-058D-4CDE-8231-B2DB5322A29D@oracle.com>
Message-ID: <554168B2.7020604@oracle.com>

Hi Brian,

On 4/29/2015 4:25 PM, Brian Burkhalter wrote:
> Hi Joe,
>
> No, RandomFactory would have been added by the previous webrev.00 
> version of the patch, i.e., RandomFactory did not come from RandomSeed.
>
> Is this reasonable?
>
> Thanks,
>

Sounds reasonable (they two files didn't necessarily look related, but I 
thought it was worth checking).

Thanks,

-Joe


From brian.burkhalter at oracle.com  Wed Apr 29 23:27:38 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 29 Apr 2015 16:27:38 -0700
Subject: [9] RFR of 8078672: Print and allow setting by Java property
	seeds used to initialize Random instances in java.lang numerics tests
In-Reply-To: <554168B2.7020604@oracle.com>
References: <3BF44A04-8B17-4C5B-8EC6-70BA948C0841@oracle.com>	<553ED521.3020208@oracle.com>	<9711F5D5-20DD-49AC-A237-FB054D7E342D@oracle.com>	<2EDA6421-2B3C-406C-83C9-B9FBFC75FDC5@oracle.com>	<85512CBD-11DA-4EDB-96A1-7D222E941E5F@oracle.com>
	<3BC685C9-5D43-4F29-8D1D-A73087EA9E7D@oracle.com>
	<55416353.7050602@oracle.com>
	<4D3543AB-058D-4CDE-8231-B2DB5322A29D@oracle.com>
	<554168B2.7020604@oracle.com>
Message-ID: <8001A431-F7FD-426F-A79D-91FBB97960DF@oracle.com>

Hi Joe,

On Apr 29, 2015, at 4:26 PM, Joseph D. Darcy  wrote:

> Sounds reasonable (they two files didn't necessarily look related, but I thought it was worth checking).

I understand: that?s just being thorough!

Thanks,

Brian

From masayoshi.okutsu at oracle.com  Thu Apr 30 06:50:06 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 30 Apr 2015 15:50:06 +0900
Subject:  RFR: 8077685: (tz) Support tzdata2015d
In-Reply-To: <5540ECA9.5040504@oracle.com>
References: <5540ECA9.5040504@oracle.com>
Message-ID: <5541D09E.4050904@oracle.com>

Looks good to me.

Masayoshi

On 4/29/2015 11:37 PM, Aleksej Efimov wrote:
> Hi,
>
> Please, review the fix for adding the latest tzdata2015d to JDK9.
> The JTREG and JPRT tests were executed.
> No failures were observed.
>
> Thank you,
> Aleksej
>
> [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8077685
> [2] Webrev: http://cr.openjdk.java.net/~aefimov/tzdata/2015d/9/00



From peter.levart at gmail.com  Thu Apr 30 10:24:23 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 30 Apr 2015 12:24:23 +0200
Subject: RFR: JDK-8074003
	java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized
In-Reply-To: <5540FA33.60009@Oracle.com>
References: <553E62D6.9030102@gmail.com>		<5540A572.5@gmail.com>
	<5540DD22.1000503@Oracle.com> <5540F83C.2080100@gmail.com>
	<5540FA33.60009@Oracle.com>
Message-ID: <554202D7.5030407@gmail.com>


On 04/29/2015 05:35 PM, Roger Riggs wrote:
> Hi Peter,
>
> There should be two changesets; so pretend the truncation has been 
> performed for this change.
> It maybe useful to backport the performance improvement to jdk 8 but 
> the spec change
> will have to be in 9 (or wait for a maintenance release).
>

Hi Roger,

So perhaps it would be best to push what we have in webrev.03 now, so 
that it can be backported to 8u directly without modifications and 
simplify equals/compareTo/getInstant as part of the changeset for 
8079063. I think this is more consistent. And I can prepare the change 
for 8079063 right away so the spec change process can be started.

Do I have a go for webrev.03 for jdk9 ?

http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.03/ 


Regards, Peter

> The simplification of toInstant can happen with the changeset for 
> 8079063.
>
> Thanks, Roger
>
>
> On 4/29/2015 11:26 AM, Peter Levart wrote:
>>
>>
>> On 04/29/2015 03:31 PM, Roger Riggs wrote:
>>> Hi Peter,
>>>
>>> Point taken about the constructor and that should have a spec 
>>> clarification to ignore the nanoseconds.
>>> The issue is tracked with:
>>> JDK-8079063  
>>> ZoneOffsetTransition constructor should ignore nanoseconds
>>>
>>> With that, the compareTo method can be simpler.  The rest looks fine.
>>>
>>> Roger
>>
>> Hi Roger,
>>
>> Should I prepare a patch for both issues in one changeset as the 
>> correct compareTo/equals depends on the truncation or should I just 
>> pretend that truncation has been performed and make this change 
>> accordingly or should I 1st do the JDK-8079063 and then this one on top?
>>
>> Also, getInstant() can be much simpler if the truncation is 
>> performed: return Instant.of(epochSecond);
>>
>> Regards, Peter
>>
>>>
>>>
>>> On 4/29/2015 5:33 AM, Peter Levart wrote:
>>>>
>>>> On 04/27/2015 06:51 PM, Stephen Colebourne wrote:
>>>>> One additional change is needed. The compareTo() method can rely on
>>>>> the new epochSecond field as well.
>>>>> Otherwise good!
>>>>> Stephen
>>>>
>>>> Hi Stephen,
>>>>
>>>> LocalDateTime (transition) has nanosecond precision. It may be that 
>>>> transitions loaded from file in ZoneRules only have second 
>>>> precisions, but ZoneOffsetTransition is a public class with public 
>>>> factory method that takes a LocalDateTime transition parameter, so 
>>>> I think compareTo() can't rely on epochSecond alone. But 
>>>> epochSecond can be used as optimization in compareTo() as well as 
>>>> equals():
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.03/ 
>>>>
>>>>
>>>> An alternative to keeping epochSecond field in ZoneOffsetTransition 
>>>> would be to keep a reference to Instant instead. Instant contains 
>>>> an epochSecond field (as well as nanos) and could be used for both 
>>>> toEpochSecond() and getInstant() methods.
>>>>
>>>> What do you think?
>>>>
>>>> It also occurred to me that serialization format of 
>>>> ZoneOffsetTransition is not adequate currently as it looses 
>>>> nanosecond precision.
>>>>
>>>> Regards, Peter
>>>>
>>>>>
>>>>> On 27 April 2015 at 17:24, Peter Levart  
>>>>> wrote:
>>>>>> Hi again,
>>>>>>
>>>>>> Here's another optimization to be reviewed that has been 
>>>>>> discussed a while
>>>>>> ago (just rebased from webrev.01) and approved by Stephen:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.02/ 
>>>>>>
>>>>>>
>>>>>>
>>>>>> The discussion about it is intermingled with the 
>>>>>> ZoneId.systemDefault()
>>>>>> discussion and starts about here:
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031873.html 
>>>>>>
>>>>>>
>>>>>>
>>>>>> The rationale for the optimization is speeding-up the conversion 
>>>>>> from epoch
>>>>>> time to LocalDateTime. This conversion uses 
>>>>>> ZoneRules.getOffset(Instant)
>>>>>> where there is a loop over ZoneOffsetTransition[] array that 
>>>>>> searches for
>>>>>> 1st transition that has its toEpochSecond value less than the 
>>>>>> Instant's
>>>>>> epochSecond. This calls ZoneOffsetTransition.toEpochSecond 
>>>>>> repeatedly,
>>>>>> converting ZoneOffsetTransition.transition which is a 
>>>>>> LocalDateTime to
>>>>>> epochSecond. This repeated conversion is unnecessary, as
>>>>>> ZoneOffsetTransition[] array is part of ZoneRules which is cached.
>>>>>> Optimizing the ZoneOffsetTransition implementation (keeping both
>>>>>> LocalDateTime variant and eposhSecond variant of transition time 
>>>>>> as the
>>>>>> object's state) speeds up this conversion.
>>>>>>
>>>>>>
>>>>>> Regards, Peter
>>>>>>
>>>>
>>>
>>
>



From peter.levart at gmail.com  Thu Apr 30 11:08:00 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 30 Apr 2015 13:08:00 +0200
Subject: RFR: 8077846: improve locking strategy for readConfiguration(),
	reset(), and initializeGlobalHandlers()
In-Reply-To: <553FAB5B.3060605@gmail.com>
References: <553A7835.80209@oracle.com>	<553D8F0B.4070102@oracle.com>	<553DE503.2060608@oracle.com>	<553E29C7.8030800@oracle.com>
	<553E9685.1030809@oracle.com> <553F3DC4.4010104@gmail.com>
	<553F4136.5010500@oracle.com> <553F940C.4050105@gmail.com>
	<553F9FC7.4020806@oracle.com> <553FAB5B.3060605@gmail.com>
Message-ID: <55420D10.2060001@gmail.com>



On 04/28/2015 05:46 PM, Peter Levart wrote:
>
>
> On 04/28/2015 04:57 PM, Daniel Fuchs wrote:
>>> Here's my attempt at simplifying this:
>>>
>>> http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.01/ 
>>>
>>
>> LogManager can be subclassed, and subclasses may override reset() for
>> different purposes.
>> So I'm afraid the Cleaner thread still needs to call te public
>> reset() method. The same unfortunately applies to
>> readConfiguration().
>>
>> best regards,
>>
>> -- daniel 
>
> Um, yes of course. This can be fixed:
>
> http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.02/ 
>
>
> Regards, Peter
>

Hi Daniel,

Just some observations...

I noticed you changed LogManager.Cleaner superclass from 
ManagedLocalsThread -> Thread. Is that intentional? The Cleaner is an 
unstarted Thread that gets registered as a shutdown hook in LogManager 
constructor. So at LogManager construction time it gets hold on 
inheritable thread locals and keeps them for the entire JVM lifetime. Do 
we have control on what thread performs LogManager construction and that 
no inheritable thread-local leaks are possible?

The other thing to note is that Cleaner class is not static, so it has 
an implicit reference to LogManager instance. So each LogManager 
instance constructed during lifetime of JVM is actually retained for the 
entire JVM lifetime.

The use of shutdown hook to call reset() directly is questionable. Why? 
Because other shutdown hooks might want to log their shutdown processing 
and they will race with LogManager shutdown hook executing reset(), 
shutting down all log handlers and effectively preventing shutdown 
process form being logged. Why is it so important to reset() 
LogManager(s) before exiting VM?

Regards, Peter



From scolebourne at joda.org  Thu Apr 30 11:28:14 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 30 Apr 2015 12:28:14 +0100
Subject: RFR: JDK-8074003
	java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized
In-Reply-To: <554202D7.5030407@gmail.com>
References: <553E62D6.9030102@gmail.com>
	
	<5540A572.5@gmail.com> <5540DD22.1000503@Oracle.com>
	<5540F83C.2080100@gmail.com>
	<5540FA33.60009@Oracle.com> <554202D7.5030407@gmail.com>
Message-ID: 

The approach works for me, and the patch is valid as is.
Stephen


On 30 April 2015 at 11:24, Peter Levart  wrote:
>
> On 04/29/2015 05:35 PM, Roger Riggs wrote:
>>
>> Hi Peter,
>>
>> There should be two changesets; so pretend the truncation has been
>> performed for this change.
>> It maybe useful to backport the performance improvement to jdk 8 but the
>> spec change
>> will have to be in 9 (or wait for a maintenance release).
>>
>
> Hi Roger,
>
> So perhaps it would be best to push what we have in webrev.03 now, so that
> it can be backported to 8u directly without modifications and simplify
> equals/compareTo/getInstant as part of the changeset for 8079063. I think
> this is more consistent. And I can prepare the change for 8079063 right away
> so the spec change process can be started.
>
> Do I have a go for webrev.03 for jdk9 ?
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.03/
>
> Regards, Peter
>
>
>> The simplification of toInstant can happen with the changeset for 8079063.
>>
>> Thanks, Roger
>>
>>
>> On 4/29/2015 11:26 AM, Peter Levart wrote:
>>>
>>>
>>>
>>> On 04/29/2015 03:31 PM, Roger Riggs wrote:
>>>>
>>>> Hi Peter,
>>>>
>>>> Point taken about the constructor and that should have a spec
>>>> clarification to ignore the nanoseconds.
>>>> The issue is tracked with:
>>>> JDK-8079063 
>>>> ZoneOffsetTransition constructor should ignore nanoseconds
>>>>
>>>> With that, the compareTo method can be simpler.  The rest looks fine.
>>>>
>>>> Roger
>>>
>>>
>>> Hi Roger,
>>>
>>> Should I prepare a patch for both issues in one changeset as the correct
>>> compareTo/equals depends on the truncation or should I just pretend that
>>> truncation has been performed and make this change accordingly or should I
>>> 1st do the JDK-8079063 and then this one on top?
>>>
>>> Also, getInstant() can be much simpler if the truncation is performed:
>>> return Instant.of(epochSecond);
>>>
>>> Regards, Peter
>>>
>>>>
>>>>
>>>> On 4/29/2015 5:33 AM, Peter Levart wrote:
>>>>>
>>>>>
>>>>> On 04/27/2015 06:51 PM, Stephen Colebourne wrote:
>>>>>>
>>>>>> One additional change is needed. The compareTo() method can rely on
>>>>>> the new epochSecond field as well.
>>>>>> Otherwise good!
>>>>>> Stephen
>>>>>
>>>>>
>>>>> Hi Stephen,
>>>>>
>>>>> LocalDateTime (transition) has nanosecond precision. It may be that
>>>>> transitions loaded from file in ZoneRules only have second precisions, but
>>>>> ZoneOffsetTransition is a public class with public factory method that takes
>>>>> a LocalDateTime transition parameter, so I think compareTo() can't rely on
>>>>> epochSecond alone. But epochSecond can be used as optimization in
>>>>> compareTo() as well as equals():
>>>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.03/
>>>>>
>>>>> An alternative to keeping epochSecond field in ZoneOffsetTransition
>>>>> would be to keep a reference to Instant instead. Instant contains an
>>>>> epochSecond field (as well as nanos) and could be used for both
>>>>> toEpochSecond() and getInstant() methods.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> It also occurred to me that serialization format of
>>>>> ZoneOffsetTransition is not adequate currently as it looses nanosecond
>>>>> precision.
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>>>
>>>>>> On 27 April 2015 at 17:24, Peter Levart 
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi again,
>>>>>>>
>>>>>>> Here's another optimization to be reviewed that has been discussed a
>>>>>>> while
>>>>>>> ago (just rebased from webrev.01) and approved by Stephen:
>>>>>>>
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.02/
>>>>>>>
>>>>>>>
>>>>>>> The discussion about it is intermingled with the
>>>>>>> ZoneId.systemDefault()
>>>>>>> discussion and starts about here:
>>>>>>>
>>>>>>>
>>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031873.html
>>>>>>>
>>>>>>>
>>>>>>> The rationale for the optimization is speeding-up the conversion from
>>>>>>> epoch
>>>>>>> time to LocalDateTime. This conversion uses
>>>>>>> ZoneRules.getOffset(Instant)
>>>>>>> where there is a loop over ZoneOffsetTransition[] array that searches
>>>>>>> for
>>>>>>> 1st transition that has its toEpochSecond value less than the
>>>>>>> Instant's
>>>>>>> epochSecond. This calls ZoneOffsetTransition.toEpochSecond
>>>>>>> repeatedly,
>>>>>>> converting ZoneOffsetTransition.transition which is a LocalDateTime
>>>>>>> to
>>>>>>> epochSecond. This repeated conversion is unnecessary, as
>>>>>>> ZoneOffsetTransition[] array is part of ZoneRules which is cached.
>>>>>>> Optimizing the ZoneOffsetTransition implementation (keeping both
>>>>>>> LocalDateTime variant and eposhSecond variant of transition time as
>>>>>>> the
>>>>>>> object's state) speeds up this conversion.
>>>>>>>
>>>>>>>
>>>>>>> Regards, Peter
>>>>>>>
>>>>>
>>>>
>>>
>>
>


From alexander.v.stepanov at oracle.com  Thu Apr 30 11:31:43 2015
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Thu, 30 Apr 2015 14:31:43 +0300
Subject: RFR [9] 8079075: some docs cleanup for CORBA - part 1
Message-ID: <5542129F.2060704@oracle.com>

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8079075/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8079075

Just some HTML markup fix for CORBA.

Thanks,
Alexander


From daniel.fuchs at oracle.com  Thu Apr 30 11:47:08 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 30 Apr 2015 13:47:08 +0200
Subject: RFR: 8077846: improve locking strategy for readConfiguration(),
	reset(), and initializeGlobalHandlers()
In-Reply-To: <55420D10.2060001@gmail.com>
References: <553A7835.80209@oracle.com>	<553D8F0B.4070102@oracle.com>	<553DE503.2060608@oracle.com>	<553E29C7.8030800@oracle.com>
	<553E9685.1030809@oracle.com> <553F3DC4.4010104@gmail.com>
	<553F4136.5010500@oracle.com> <553F940C.4050105@gmail.com>
	<553F9FC7.4020806@oracle.com> <553FAB5B.3060605@gmail.com>
	<55420D10.2060001@gmail.com>
Message-ID: <5542163C.7090608@oracle.com>

Hi Peter,

Sorry I didn't reply to your last mail.
I still intend to.

more on the current mail below...

On 30/04/15 13:08, Peter Levart wrote:
>
>
> On 04/28/2015 05:46 PM, Peter Levart wrote:
>>
>>
>> On 04/28/2015 04:57 PM, Daniel Fuchs wrote:
>>>> Here's my attempt at simplifying this:
>>>>
>>>> http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.01/
>>>>
>>>
>>> LogManager can be subclassed, and subclasses may override reset() for
>>> different purposes.
>>> So I'm afraid the Cleaner thread still needs to call te public
>>> reset() method. The same unfortunately applies to
>>> readConfiguration().
>>>
>>> best regards,
>>>
>>> -- daniel
>>
>> Um, yes of course. This can be fixed:
>>
>> http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.02/
>>
>>
>> Regards, Peter
>>
>
> Hi Daniel,
>
> Just some observations...
>
> I noticed you changed LogManager.Cleaner superclass from
> ManagedLocalsThread -> Thread. Is that intentional?

I didn't -

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

but you did :-)

http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.02

The repo on which I prepared the patch didn't have this change yet.
It's probably the result of a bad merge when you upgraded/applied
my patch.


> The Cleaner is an
> unstarted Thread that gets registered as a shutdown hook in LogManager
> constructor. So at LogManager construction time it gets hold on
> inheritable thread locals and keeps them for the entire JVM lifetime. Do
> we have control on what thread performs LogManager construction and that
> no inheritable thread-local leaks are possible?
>
> The other thing to note is that Cleaner class is not static, so it has
> an implicit reference to LogManager instance. So each LogManager
> instance constructed during lifetime of JVM is actually retained for the
> entire JVM lifetime.

Yes. I would say that's not an issue because the LogManager is supposed
to be a singleton class. There should be only one instance.
This is sadly not enforced and there are applications out there
that have taken that opportunity to create several LogManagers - but
that is not actually supported (we just try to not cause regressions).

> The use of shutdown hook to call reset() directly is questionable. Why?
> Because other shutdown hooks might want to log their shutdown processing
> and they will race with LogManager shutdown hook executing reset(),
> shutting down all log handlers and effectively preventing shutdown
> process form being logged. Why is it so important to reset()
> LogManager(s) before exiting VM?

It is questionable, agreed.
And there are applications which subclass
LogManager just for the purpose of preventing reset() from doing
anything - so that they can use loggers in other shutdown hook.
There's even an issue in JBS.

The problem here is to cleanly close the handlers when the VM exits
(there are locks to be released and XML tails to be written).

Using a mechanism similar to sun.misc.Cleaner in order to
close handlers when they are no longer referenced is
unfortunately not trivial, because you precisely need a
reference to the Handler in order to call close() on it.
And because of compatibility issues we're more or less stuck
with the current Cleaner thread anyway.

best regards

-- daniel

>
> Regards, Peter
>



From alexander.v.stepanov at oracle.com  Thu Apr 30 11:56:43 2015
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Thu, 30 Apr 2015 14:56:43 +0300
Subject: RFR [9] 8079075: some docs cleanup for CORBA - part 1
In-Reply-To: <5542129F.2060704@oracle.com>
References: <5542129F.2060704@oracle.com>
Message-ID: <5542187B.90003@oracle.com>

P.S. Sorry, not sure if changes like "" -> "{@literal }" 
(see, e.g., ValueBoxGen24.java) are what expected; please correct me if 
I'm wrong.

But something should be done; otherwise "" is interpreted as an 
unknown HTML tag causing the errors.

Thanks,
Alexander

On 30.04.2015 14:31, alexander stepanov wrote:
> Hello,
>
> Could you please review the following fix
> http://cr.openjdk.java.net/~avstepan/8079075/webrev.00/
> for
> https://bugs.openjdk.java.net/browse/JDK-8079075
>
> Just some HTML markup fix for CORBA.
>
> Thanks,
> Alexander



From Roger.Riggs at Oracle.com  Thu Apr 30 12:47:20 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 30 Apr 2015 08:47:20 -0400
Subject: RFR: JDK-8074003
	java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized
In-Reply-To: <554202D7.5030407@gmail.com>
References: <553E62D6.9030102@gmail.com>		<5540A572.5@gmail.com>
	<5540DD22.1000503@Oracle.com> <5540F83C.2080100@gmail.com>
	<5540FA33.60009@Oracle.com> <554202D7.5030407@gmail.com>
Message-ID: <55422458.1040202@Oracle.com>

Hi Peter,

Yes, go ahead with the patch as is.

Thanks, Roger


On 4/30/2015 6:24 AM, Peter Levart wrote:
>
> On 04/29/2015 05:35 PM, Roger Riggs wrote:
>> Hi Peter,
>>
>> There should be two changesets; so pretend the truncation has been 
>> performed for this change.
>> It maybe useful to backport the performance improvement to jdk 8 but 
>> the spec change
>> will have to be in 9 (or wait for a maintenance release).
>>
>
> Hi Roger,
>
> So perhaps it would be best to push what we have in webrev.03 now, so 
> that it can be backported to 8u directly without modifications and 
> simplify equals/compareTo/getInstant as part of the changeset for 
> 8079063. I think this is more consistent. And I can prepare the change 
> for 8079063 right away so the spec change process can be started.
>
> Do I have a go for webrev.03 for jdk9 ?
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.03/ 
>
>
> Regards, Peter
>
>> The simplification of toInstant can happen with the changeset for 
>> 8079063.
>>
>> Thanks, Roger
>>
>>
>> On 4/29/2015 11:26 AM, Peter Levart wrote:
>>>
>>>
>>> On 04/29/2015 03:31 PM, Roger Riggs wrote:
>>>> Hi Peter,
>>>>
>>>> Point taken about the constructor and that should have a spec 
>>>> clarification to ignore the nanoseconds.
>>>> The issue is tracked with:
>>>> JDK-8079063  
>>>> ZoneOffsetTransition constructor should ignore nanoseconds
>>>>
>>>> With that, the compareTo method can be simpler.  The rest looks fine.
>>>>
>>>> Roger
>>>
>>> Hi Roger,
>>>
>>> Should I prepare a patch for both issues in one changeset as the 
>>> correct compareTo/equals depends on the truncation or should I just 
>>> pretend that truncation has been performed and make this change 
>>> accordingly or should I 1st do the JDK-8079063 and then this one on 
>>> top?
>>>
>>> Also, getInstant() can be much simpler if the truncation is 
>>> performed: return Instant.of(epochSecond);
>>>
>>> Regards, Peter
>>>
>>>>
>>>>
>>>> On 4/29/2015 5:33 AM, Peter Levart wrote:
>>>>>
>>>>> On 04/27/2015 06:51 PM, Stephen Colebourne wrote:
>>>>>> One additional change is needed. The compareTo() method can rely on
>>>>>> the new epochSecond field as well.
>>>>>> Otherwise good!
>>>>>> Stephen
>>>>>
>>>>> Hi Stephen,
>>>>>
>>>>> LocalDateTime (transition) has nanosecond precision. It may be 
>>>>> that transitions loaded from file in ZoneRules only have second 
>>>>> precisions, but ZoneOffsetTransition is a public class with public 
>>>>> factory method that takes a LocalDateTime transition parameter, so 
>>>>> I think compareTo() can't rely on epochSecond alone. But 
>>>>> epochSecond can be used as optimization in compareTo() as well as 
>>>>> equals():
>>>>>
>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.03/ 
>>>>>
>>>>>
>>>>> An alternative to keeping epochSecond field in 
>>>>> ZoneOffsetTransition would be to keep a reference to Instant 
>>>>> instead. Instant contains an epochSecond field (as well as nanos) 
>>>>> and could be used for both toEpochSecond() and getInstant() methods.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> It also occurred to me that serialization format of 
>>>>> ZoneOffsetTransition is not adequate currently as it looses 
>>>>> nanosecond precision.
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>>>
>>>>>> On 27 April 2015 at 17:24, Peter Levart  
>>>>>> wrote:
>>>>>>> Hi again,
>>>>>>>
>>>>>>> Here's another optimization to be reviewed that has been 
>>>>>>> discussed a while
>>>>>>> ago (just rebased from webrev.01) and approved by Stephen:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.02/ 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The discussion about it is intermingled with the 
>>>>>>> ZoneId.systemDefault()
>>>>>>> discussion and starts about here:
>>>>>>>
>>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031873.html 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The rationale for the optimization is speeding-up the conversion 
>>>>>>> from epoch
>>>>>>> time to LocalDateTime. This conversion uses 
>>>>>>> ZoneRules.getOffset(Instant)
>>>>>>> where there is a loop over ZoneOffsetTransition[] array that 
>>>>>>> searches for
>>>>>>> 1st transition that has its toEpochSecond value less than the 
>>>>>>> Instant's
>>>>>>> epochSecond. This calls ZoneOffsetTransition.toEpochSecond 
>>>>>>> repeatedly,
>>>>>>> converting ZoneOffsetTransition.transition which is a 
>>>>>>> LocalDateTime to
>>>>>>> epochSecond. This repeated conversion is unnecessary, as
>>>>>>> ZoneOffsetTransition[] array is part of ZoneRules which is cached.
>>>>>>> Optimizing the ZoneOffsetTransition implementation (keeping both
>>>>>>> LocalDateTime variant and eposhSecond variant of transition time 
>>>>>>> as the
>>>>>>> object's state) speeds up this conversion.
>>>>>>>
>>>>>>>
>>>>>>> Regards, Peter
>>>>>>>
>>>>>
>>>>
>>>
>>
>



From Roger.Riggs at Oracle.com  Thu Apr 30 13:47:42 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 30 Apr 2015 09:47:42 -0400
Subject: RFR [9] 8079075: some docs cleanup for CORBA - part 1
In-Reply-To: <5542187B.90003@oracle.com>
References: <5542129F.2060704@oracle.com> <5542187B.90003@oracle.com>
Message-ID: <5542327E.6060403@Oracle.com>

Hi Alexander,

Thanks for working through all these changes.

0) Is there an upstream version of any of this code?  Making even 
cosmetic changes
    would make future versions harder to merge.

1) For files that we don't typically generate javadoc for, it is simpler 
to avoid adding unnecessary markup.
For example:

old/src/java.corba/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java:222+
+     * @return  the {@code TypeCode} for the element in the Any

There is not much value in the addition of {@code }.

For these kind of files, the javadoc should be well formed and any 
warnings/errors should be fixed.

2) a number of changes do not maintain the indentation, for example,
-     * @result          the InputStream to marshal value of Any out of.
+     * @return  the {@code InputStream} to marshal value of Any out of.

Unless all of the indentation is going to be fixed in a file; it is 
better to remain consistent with the per file style.

3) Removing degenerate @author tags is great.  But adding an extra blank 
line is not desirable.
    For example, 
old/src/java.corba/share/classes/com/sun/corba/se/impl/ior/GenericTaggedProfile.java:39

-/**
- * @author
- */
+

4) For snippets of code, use {@code} instead of a plain or {@literal ...}
These files don't that pattern extensively and its not important to fix 
it everywhere since it is in the impl code.
But for example, it would make sense here:
old/src/java.corba/share/classes/com/sun/corba/se/impl/ior/ObjectAdapterIdNumber.java:31+

- * internally as arrays of the form { "OldRootPOA", "" },
+ * internally as arrays of the form { "OldRootPOA", "{@literal 
}" },

Might be better as:
+ * internally as arrays of the form {@code { "OldRootPOA", "" }},

5) The continuation of @param should be indented.

src/java.corba/share/classes/com/sun/corba/se/impl/naming/pcosnaming/NamingContextImpl.java
@@ -1204,14 +1202,13 @@
      * This operation creates a URL based "iiopname://" format name
      * from the Stringified Name of the object.
      * @param addr internet based address of the host machine where
-    * Name Service is running 

-    * @param sn Stringified Name of the object 

*+    * Name Service is running*
+    * @param sn Stringified Name of the object


6) correct the punctuation since the line is being modified.
src/java.corba/share/classes/com/sun/corba/se/pept/transport/Acceptor.java

-     * @return trueAcceptor has been
+     * @return true. if the Acceptor has been

Would read better as:
+     * @return true if the Acceptor has been


7)  I don't recognize the strings of the format dNNNNN but they seem to 
be referring
     to past bug reports and the authors who fixed them.  I doubt they 
have any value in
     the code anymore. It would probably be fine to just drop the extra 
'<>' symbols.
     And around the author initials.    -->  klr

Regards, Roger



On 4/30/2015 7:56 AM, alexander stepanov wrote:
> P.S. Sorry, not sure if changes like "" -> "{@literal 
> }" (see, e.g., ValueBoxGen24.java) are what expected; please 
> correct me if I'm wrong.
>
> But something should be done; otherwise "" is interpreted as 
> an unknown HTML tag causing the errors.
>
> Thanks,
> Alexander
>
> On 30.04.2015 14:31, alexander stepanov wrote:
>> Hello,
>>
>> Could you please review the following fix
>> http://cr.openjdk.java.net/~avstepan/8079075/webrev.00/
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8079075
>>
>> Just some HTML markup fix for CORBA.
>>
>> Thanks,
>> Alexander
>



From Alan.Bateman at oracle.com  Thu Apr 30 13:51:14 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 Apr 2015 14:51:14 +0100
Subject: RFR [9] 8079075: some docs cleanup for CORBA - part 1
In-Reply-To: <5542327E.6060403@Oracle.com>
References: <5542129F.2060704@oracle.com> <5542187B.90003@oracle.com>
	<5542327E.6060403@Oracle.com>
Message-ID: <55423352.5080003@oracle.com>

On 30/04/2015 14:47, Roger Riggs wrote:
> Hi Alexander,
>
> Thanks for working through all these changes.
>
> 0) Is there an upstream version of any of this code?  Making even 
> cosmetic changes
>    would make future versions harder to merge.
>
No. This was the case a long time ago but for many releases then the 
master is in the JDK corba repo.

-Alan.



From daniel.fuchs at oracle.com  Thu Apr 30 14:42:01 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 30 Apr 2015 16:42:01 +0200
Subject: RFR: 8077846: improve locking strategy for readConfiguration(),
	reset(), and initializeGlobalHandlers()
In-Reply-To: <553FAB5B.3060605@gmail.com>
References: <553A7835.80209@oracle.com>	<553D8F0B.4070102@oracle.com>	<553DE503.2060608@oracle.com>	<553E29C7.8030800@oracle.com>
	<553E9685.1030809@oracle.com> <553F3DC4.4010104@gmail.com>
	<553F4136.5010500@oracle.com> <553F940C.4050105@gmail.com>
	<553F9FC7.4020806@oracle.com> <553FAB5B.3060605@gmail.com>
Message-ID: <55423F39.6060304@oracle.com>

On 28/04/15 17:46, Peter Levart wrote:
>
>
> On 04/28/2015 04:57 PM, Daniel Fuchs wrote:
>>> Here's my attempt at simplifying this:
>>>
>>> http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.01/
>>>
>>
>> LogManager can be subclassed, and subclasses may override reset() for
>> different purposes.
>> So I'm afraid the Cleaner thread still needs to call te public
>> reset() method. The same unfortunately applies to
>> readConfiguration().
>>
>> best regards,
>>
>> -- daniel
>
> Um, yes of course. This can be fixed:
>
> http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.02/

Hi Peter,

Sorry for the late reply.

My gut feeling is that I dislike multi-state ints.
But I guess that's a matter of taste - so I could probably
overcome it ;-)

What makes me less happy is that I had managed to
remove the explicit synchronized() { } block in the
Cleaner thread - and I now see it's back.

Could we maybe keep the imminentDeath boolean and remove
the explicit locking in the Cleaner thread?

I mean... imminentDeath should be checked from within
the lock - before doing anything. But it does not need
to be set from within a locked section.

best regards,

-- daniel

>
>
> Regards, Peter
>



From alexander.v.stepanov at oracle.com  Thu Apr 30 16:35:18 2015
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Thu, 30 Apr 2015 19:35:18 +0300
Subject: RFR [9] 8079075: some docs cleanup for CORBA - part 1
In-Reply-To: <5542327E.6060403@Oracle.com>
References: <5542129F.2060704@oracle.com> <5542187B.90003@oracle.com>
	<5542327E.6060403@Oracle.com>
Message-ID: <554259C6.9090303@oracle.com>

Hello Roger,

Thank you for the notes; please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8079075/webrev.01/

Regards,
Alexander

On 30.04.2015 16:47, Roger Riggs wrote:
> Hi Alexander,
>
> Thanks for working through all these changes.
>
> 0) Is there an upstream version of any of this code?  Making even 
> cosmetic changes
>    would make future versions harder to merge.
>
> 1) For files that we don't typically generate javadoc for, it is 
> simpler to avoid adding unnecessary markup.
> For example:
>
> old/src/java.corba/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java:222+ 
>
> +     * @return  the {@code TypeCode} for the element in the Any
>
> There is not much value in the addition of {@code }.
>
> For these kind of files, the javadoc should be well formed and any 
> warnings/errors should be fixed.
>
> 2) a number of changes do not maintain the indentation, for example,
> -     * @result          the InputStream to marshal value of Any out of.
> +     * @return  the {@code InputStream} to marshal value of Any out of.
>
> Unless all of the indentation is going to be fixed in a file; it is 
> better to remain consistent with the per file style.
>
> 3) Removing degenerate @author tags is great.  But adding an extra 
> blank line is not desirable.
>    For example, 
> old/src/java.corba/share/classes/com/sun/corba/se/impl/ior/GenericTaggedProfile.java:39
>
> -/**
> - * @author
> - */
> +
>
> 4) For snippets of code, use {@code} instead of a plain or {@literal ...}
> These files don't that pattern extensively and its not important to 
> fix it everywhere since it is in the impl code.
> But for example, it would make sense here:
> old/src/java.corba/share/classes/com/sun/corba/se/impl/ior/ObjectAdapterIdNumber.java:31+ 
>
>
> - * internally as arrays of the form { "OldRootPOA", "" },
> + * internally as arrays of the form { "OldRootPOA", "{@literal 
> }" },
>
> Might be better as:
> + * internally as arrays of the form {@code { "OldRootPOA", "" 
> }},
>
> 5) The continuation of @param should be indented.
>
> src/java.corba/share/classes/com/sun/corba/se/impl/naming/pcosnaming/NamingContextImpl.java 
>
> @@ -1204,14 +1202,13 @@
>      * This operation creates a URL based "iiopname://" format name
>      * from the Stringified Name of the object.
>      * @param addr internet based address of the host machine where
> -    * Name Service is running 

> -    * @param sn Stringified Name of the object 

> *+    * Name Service is running*
> +    * @param sn Stringified Name of the object
>
>
> 6) correct the punctuation since the line is being modified.
> src/java.corba/share/classes/com/sun/corba/se/pept/transport/Acceptor.java 
>
>
> -     * @return trueAcceptor has been
> +     * @return true. if the Acceptor has been
>
> Would read better as:
> +     * @return true if the Acceptor has been
>
>
> 7)  I don't recognize the strings of the format dNNNNN but they seem 
> to be referring
>     to past bug reports and the authors who fixed them.  I doubt they 
> have any value in
>     the code anymore. It would probably be fine to just drop the extra 
> '<>' symbols.
>     And around the author initials.    -->  klr
>
> Regards, Roger
>
>
>
> On 4/30/2015 7:56 AM, alexander stepanov wrote:
>> P.S. Sorry, not sure if changes like "" -> "{@literal 
>> }" (see, e.g., ValueBoxGen24.java) are what expected; please 
>> correct me if I'm wrong.
>>
>> But something should be done; otherwise "" is interpreted as 
>> an unknown HTML tag causing the errors.
>>
>> Thanks,
>> Alexander
>>
>> On 30.04.2015 14:31, alexander stepanov wrote:
>>> Hello,
>>>
>>> Could you please review the following fix
>>> http://cr.openjdk.java.net/~avstepan/8079075/webrev.00/
>>> for
>>> https://bugs.openjdk.java.net/browse/JDK-8079075
>>>
>>> Just some HTML markup fix for CORBA.
>>>
>>> Thanks,
>>> Alexander
>>
>



From alexander.v.stepanov at oracle.com  Thu Apr 30 17:21:41 2015
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Thu, 30 Apr 2015 20:21:41 +0300
Subject: RFR [9] 8040147: tidy warnings cleanup for javax.transaction
Message-ID: <554264A5.1010700@oracle.com>

Hello,

Could you please review the fix
http://cr.openjdk.java.net/~avstepan/8040147/webrev.01/
for
https://bugs.openjdk.java.net/browse/JDK-8040147

Just a very minor fix of docs markup.

Thanks,
Alexander



From Roger.Riggs at Oracle.com  Thu Apr 30 17:40:57 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 30 Apr 2015 13:40:57 -0400
Subject: RFR [9] 8079075: some docs cleanup for CORBA - part 1
In-Reply-To: <554259C6.9090303@oracle.com>
References: <5542129F.2060704@oracle.com> <5542187B.90003@oracle.com>
	<5542327E.6060403@Oracle.com> <554259C6.9090303@oracle.com>
Message-ID: <55426929.4090309@Oracle.com>

Hi Alexander,

The improvements look good to me.

Thank you,  Roger


On 4/30/2015 12:35 PM, alexander stepanov wrote:
> Hello Roger,
>
> Thank you for the notes; please see the updated webrev:
> http://cr.openjdk.java.net/~avstepan/8079075/webrev.01/
>
> Regards,
> Alexander
>
> On 30.04.2015 16:47, Roger Riggs wrote:
>> Hi Alexander,
>>
>> Thanks for working through all these changes.
>>
>> 0) Is there an upstream version of any of this code?  Making even 
>> cosmetic changes
>>    would make future versions harder to merge.
>>
>> 1) For files that we don't typically generate javadoc for, it is 
>> simpler to avoid adding unnecessary markup.
>> For example:
>>
>> old/src/java.corba/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java:222+ 
>>
>> +     * @return  the {@code TypeCode} for the element in the Any
>>
>> There is not much value in the addition of {@code }.
>>
>> For these kind of files, the javadoc should be well formed and any 
>> warnings/errors should be fixed.
>>
>> 2) a number of changes do not maintain the indentation, for example,
>> -     * @result          the InputStream to marshal value of Any out of.
>> +     * @return  the {@code InputStream} to marshal value of Any out of.
>>
>> Unless all of the indentation is going to be fixed in a file; it is 
>> better to remain consistent with the per file style.
>>
>> 3) Removing degenerate @author tags is great.  But adding an extra 
>> blank line is not desirable.
>>    For example, 
>> old/src/java.corba/share/classes/com/sun/corba/se/impl/ior/GenericTaggedProfile.java:39
>>
>> -/**
>> - * @author
>> - */
>> +
>>
>> 4) For snippets of code, use {@code} instead of a plain or {@literal 
>> ...}
>> These files don't that pattern extensively and its not important to 
>> fix it everywhere since it is in the impl code.
>> But for example, it would make sense here:
>> old/src/java.corba/share/classes/com/sun/corba/se/impl/ior/ObjectAdapterIdNumber.java:31+ 
>>
>>
>> - * internally as arrays of the form { "OldRootPOA", "" },
>> + * internally as arrays of the form { "OldRootPOA", "{@literal 
>> }" },
>>
>> Might be better as:
>> + * internally as arrays of the form {@code { "OldRootPOA", 
>> "" }},
>>
>> 5) The continuation of @param should be indented.
>>
>> src/java.corba/share/classes/com/sun/corba/se/impl/naming/pcosnaming/NamingContextImpl.java 
>>
>> @@ -1204,14 +1202,13 @@
>>      * This operation creates a URL based "iiopname://" format name
>>      * from the Stringified Name of the object.
>>      * @param addr internet based address of the host machine where
>> -    * Name Service is running 

>> -    * @param sn Stringified Name of the object 

>> *+    * Name Service is running*
>> +    * @param sn Stringified Name of the object
>>
>>
>> 6) correct the punctuation since the line is being modified.
>> src/java.corba/share/classes/com/sun/corba/se/pept/transport/Acceptor.java 
>>
>>
>> -     * @return trueAcceptor has been
>> +     * @return true. if the Acceptor has been
>>
>> Would read better as:
>> +     * @return true if the Acceptor has been
>>
>>
>> 7)  I don't recognize the strings of the format dNNNNN but they seem 
>> to be referring
>>     to past bug reports and the authors who fixed them.  I doubt they 
>> have any value in
>>     the code anymore. It would probably be fine to just drop the 
>> extra '<>' symbols.
>>     And around the author initials.    -->  klr
>>
>> Regards, Roger
>>
>>
>>
>> On 4/30/2015 7:56 AM, alexander stepanov wrote:
>>> P.S. Sorry, not sure if changes like "" -> "{@literal 
>>> }" (see, e.g., ValueBoxGen24.java) are what expected; please 
>>> correct me if I'm wrong.
>>>
>>> But something should be done; otherwise "" is interpreted as 
>>> an unknown HTML tag causing the errors.
>>>
>>> Thanks,
>>> Alexander
>>>
>>> On 30.04.2015 14:31, alexander stepanov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the following fix
>>>> http://cr.openjdk.java.net/~avstepan/8079075/webrev.00/
>>>> for
>>>> https://bugs.openjdk.java.net/browse/JDK-8079075
>>>>
>>>> Just some HTML markup fix for CORBA.
>>>>
>>>> Thanks,
>>>> Alexander
>>>
>>
>



From alexander.v.stepanov at oracle.com  Thu Apr 30 19:41:01 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Thu, 30 Apr 2015 12:41:01 -0700 (PDT)
Subject: RFR [9] 8079075: some docs cleanup for CORBA - part 1
Message-ID: <515b5dec-80ea-4840-9fd7-3841d0d9e10d@default>

Thanks!

----- ???????? ????????? -----
??: Roger.Riggs at Oracle.com
????: alexander.v.stepanov at oracle.com
?????: core-libs-dev at openjdk.java.net
????????????: ???????, 30 ?????? 2015 ? 21:41:05 GMT +03:00 ??????, ?????-?????????, ?????????
????: Re: RFR [9] 8079075: some docs cleanup for CORBA - part 1

Hi Alexander,

The improvements look good to me.

Thank you,  Roger


On 4/30/2015 12:35 PM, alexander stepanov wrote:
> Hello Roger,
>
> Thank you for the notes; please see the updated webrev:
> http://cr.openjdk.java.net/~avstepan/8079075/webrev.01/
>
> Regards,
> Alexander
>
> On 30.04.2015 16:47, Roger Riggs wrote:
>> Hi Alexander,
>>
>> Thanks for working through all these changes.
>>
>> 0) Is there an upstream version of any of this code?  Making even 
>> cosmetic changes
>>    would make future versions harder to merge.
>>
>> 1) For files that we don't typically generate javadoc for, it is 
>> simpler to avoid adding unnecessary markup.
>> For example:
>>
>> old/src/java.corba/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java:222+ 
>>
>> +     * @return  the {@code TypeCode} for the element in the Any
>>
>> There is not much value in the addition of {@code }.
>>
>> For these kind of files, the javadoc should be well formed and any 
>> warnings/errors should be fixed.
>>
>> 2) a number of changes do not maintain the indentation, for example,
>> -     * @result          the InputStream to marshal value of Any out of.
>> +     * @return  the {@code InputStream} to marshal value of Any out of.
>>
>> Unless all of the indentation is going to be fixed in a file; it is 
>> better to remain consistent with the per file style.
>>
>> 3) Removing degenerate @author tags is great.  But adding an extra 
>> blank line is not desirable.
>>    For example, 
>> old/src/java.corba/share/classes/com/sun/corba/se/impl/ior/GenericTaggedProfile.java:39
>>
>> -/**
>> - * @author
>> - */
>> +
>>
>> 4) For snippets of code, use {@code} instead of a plain or {@literal 
>> ...}
>> These files don't that pattern extensively and its not important to 
>> fix it everywhere since it is in the impl code.
>> But for example, it would make sense here:
>> old/src/java.corba/share/classes/com/sun/corba/se/impl/ior/ObjectAdapterIdNumber.java:31+ 
>>
>>
>> - * internally as arrays of the form { "OldRootPOA", "" },
>> + * internally as arrays of the form { "OldRootPOA", "{@literal 
>> }" },
>>
>> Might be better as:
>> + * internally as arrays of the form {@code { "OldRootPOA", 
>> "" }},
>>
>> 5) The continuation of @param should be indented.
>>
>> src/java.corba/share/classes/com/sun/corba/se/impl/naming/pcosnaming/NamingContextImpl.java 
>>
>> @@ -1204,14 +1202,13 @@
>>      * This operation creates a URL based "iiopname://" format name
>>      * from the Stringified Name of the object.
>>      * @param addr internet based address of the host machine where
>> -    * Name Service is running 

>> -    * @param sn Stringified Name of the object 

>> *+    * Name Service is running*
>> +    * @param sn Stringified Name of the object
>>
>>
>> 6) correct the punctuation since the line is being modified.
>> src/java.corba/share/classes/com/sun/corba/se/pept/transport/Acceptor.java 
>>
>>
>> -     * @return trueAcceptor has been
>> +     * @return true. if the Acceptor has been
>>
>> Would read better as:
>> +     * @return true if the Acceptor has been
>>
>>
>> 7)  I don't recognize the strings of the format dNNNNN but they seem 
>> to be referring
>>     to past bug reports and the authors who fixed them.  I doubt they 
>> have any value in
>>     the code anymore. It would probably be fine to just drop the 
>> extra '<>' symbols.
>>     And around the author initials.    -->  klr
>>
>> Regards, Roger
>>
>>
>>
>> On 4/30/2015 7:56 AM, alexander stepanov wrote:
>>> P.S. Sorry, not sure if changes like "" -> "{@literal 
>>> }" (see, e.g., ValueBoxGen24.java) are what expected; please 
>>> correct me if I'm wrong.
>>>
>>> But something should be done; otherwise "" is interpreted as 
>>> an unknown HTML tag causing the errors.
>>>
>>> Thanks,
>>> Alexander
>>>
>>> On 30.04.2015 14:31, alexander stepanov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the following fix
>>>> http://cr.openjdk.java.net/~avstepan/8079075/webrev.00/
>>>> for
>>>> https://bugs.openjdk.java.net/browse/JDK-8079075
>>>>
>>>> Just some HTML markup fix for CORBA.
>>>>
>>>> Thanks,
>>>> Alexander
>>>
>>
>



From mandy.chung at oracle.com  Thu Apr 30 22:31:25 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 30 Apr 2015 15:31:25 -0700
Subject: RFR: 8077846: improve locking strategy for readConfiguration(),
	reset(), and initializeGlobalHandlers()
In-Reply-To: <55423F39.6060304@oracle.com>
References: <553A7835.80209@oracle.com>	<553D8F0B.4070102@oracle.com>	<553DE503.2060608@oracle.com>	<553E29C7.8030800@oracle.com>	<553E9685.1030809@oracle.com>
	<553F3DC4.4010104@gmail.com>	<553F4136.5010500@oracle.com>
	<553F940C.4050105@gmail.com>	<553F9FC7.4020806@oracle.com>
	<553FAB5B.3060605@gmail.com> <55423F39.6060304@oracle.com>
Message-ID: <5542AD3D.5070004@oracle.com>

On 04/30/2015 07:42 AM, Daniel Fuchs wrote:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8077846/webrev.00/ 

>> http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.02/ 
>>

I reviewed both of the above webrevs.

TestConfigurationLock.java
    Copyright year should be 2015

TestConfigurationLock.properties
    It would be good to delete all commented lines except the lines
    relevant to the setting to make it obvious what the configuration is.

LogManager.java

I actually like having one state variable to describe the global handler 
(re-)initialization that to me is a simplification.  I couldn't 
immediately match the constant names in following the code right away.  
I read these states as:
     STATE_UNINITIALIZED - request reinitialization or invalidate the 
RootLogger
             (called from readConfiguration and after reset)
     STATE_INITIALIZED - reinitialization complete or error during 
readConfiguration
     STATE_INITIALIZING - global handlers are being initialized

Perhaps renaming the constant names to GLOBAL_HANDLERS_INVALIDATED etc 
might help.

I'm less sure about shutdown and the global handlers can skip 
reinitialization during shutdown and keeping it as separate variable 
makes it more explicit.  It may eliminate the configurationLock.lock() 
in the Cleaner.run() method.

A minor point - I wonder if a private reset method taking a boolean 
argument to indicate if the state change to STATE_INITIALIZED is 
required would make it little easier to follow.

Mandy


