Re: java.util.Pair

2017-07-13 Thread kedar mhaswade 
On Thu, Jul 13, 2017 at 4:24 PM, Dave Brosius 
wrote:

> I would avoid Pair and Entry like the plague. They are devoid of meaning
> and are just there to save your fingers.


The only difference is that the latter is already available in java.util.
And perhaps it is (should be?) more attractive to a typical Java developer
to use Entry than depend upon JavaFX (is that available in headless
environment?)

If that is your main impetus, i'd just turn to using lombok and have true
> bean classes, that are finger-cost free.
>
>
>
> On 07/13/2017 05:41 PM, fo...@univ-mlv.fr wrote:
>
>> De: "John Rose" 
>>> À: "Rémi Forax" 
>>> Cc: "joe darcy" , "core-libs-dev"
>>> 
>>> Envoyé: Jeudi 13 Juillet 2017 23:05:14
>>> Objet: Re: java.util.Pair
>>> On Jul 13, 2017, at 1:39 PM, Remi Forax < [ mailto:fo...@univ-mlv.fr |
>>> fo...@univ-mlv.fr ] > wrote:
>>>
 Tuples are like an array of value types parameterized by a constant
 integer

>>> The homogeneous case is pretty simple; most of what you need is
>>> to allow a generic type to be parameterized by an integer. C++ templates
>>> have had that for a long time.
>>> What's harder is to have a two-step process for type instantiation:
>>> First, tell me the arity N, and second, for each position under that
>>> arity,
>>> tell me the type T[i], i>> the most Java-like way to handle it might be type-functions that overload
>>> alongside generic types. But there are many, many ways to slice it.
>>>
>> or use a recursive definition like in Ceylon
>> https://modules.ceylon-lang.org/repo/1/ceylon/language/1.0.
>> 0/module-doc/Tuple.type.html
>> and the fact that value types are flatten to specify the rest, i.e a
>> Tuple contains a T first and a Tuple rest.
>>
>> C++ templates can express heterogeneous tuples:
>>> [ http://en.cppreference.com/w/cpp/utility/tuple |
>>> http://en.cppreference.com/w/cpp/utility/tuple ]
>>> Typically there is a small limit to C++ tuple size, because the
>>> underlying
>>> template implementation has its size set to the arity limit.
>>> — John
>>>
>> Rémi
>>
>>
>

Re: [9] JDK-8184306: zlib 1.2.11 upgrade triggers j.u.zip.Deflater regression

2017-07-13 Thread Brian Burkhalter 
On Jul 12, 2017, at 11:52 PM, Alan Bateman  wrote:

> On 13/07/2017 00:06, Xueming Shen wrote:
>> :
>> 
>> My reading of the 1.2.11 changes suggests the root cause is that the internal
>> state "deflate_state.high_water" is not being reset correctly/appropriately 
>> (to 0?)
>> in deflateReset/deflateResetKeep/lm_init().
>> 
>> AND the change of one of the conditions in deflate.c/deflateParams(), from
>> "strm->total_in!=0" to "s->high_water" (in the "Flush last buffer" branch) 
>> as showed
>> below, obvious triggers the regression from 1.2.8 to 1.2.11, in the scenario 
>> that
>> the "strategy/levle is changed" AND a followup "reset()" is called (with the
>> assumption that everything should be reset back to initial state and we 
>> start a
>> new compression circle, with the new level and strategy. This is how it works
>> in 1.2.8 and early releases).
> This is good sleuthing and I think you have identified the regression. The 
> fix looks right although it would be good to get confirmation from the zlib 
> maintainers (no comments on zlib/issues/275 so far).
> 
> As this is a P1 showstopper issue then additional eyes are welcome, esp. if 
> we patch zlib rather than go back to an older version.

I concur with Alan: good detective work figuring this one out. It looks good to 
me. As a sanity check, on Windows I ran the new version of the DeInflate test 
without and with the deflate.c change applied and it failed and passed, 
respectively, as expected.

Brian

Re: java.util.Pair

2017-07-13 Thread Dave Brosius 
I would avoid Pair and Entry like the plague. They are devoid of meaning 
and are just there to save your fingers. If that is your main impetus, 
i'd just turn to using lombok and have true bean classes, that are 
finger-cost free.



On 07/13/2017 05:41 PM, fo...@univ-mlv.fr wrote:

De: "John Rose" 
À: "Rémi Forax" 
Cc: "joe darcy" , "core-libs-dev"

Envoyé: Jeudi 13 Juillet 2017 23:05:14
Objet: Re: java.util.Pair
On Jul 13, 2017, at 1:39 PM, Remi Forax < [ mailto:fo...@univ-mlv.fr |
fo...@univ-mlv.fr ] > wrote:

Tuples are like an array of value types parameterized by a constant integer

The homogeneous case is pretty simple; most of what you need is
to allow a generic type to be parameterized by an integer. C++ templates
have had that for a long time.
What's harder is to have a two-step process for type instantiation:
First, tell me the arity N, and second, for each position under that arity,
tell me the type T[i], i
or use a recursive definition like in Ceylon
https://modules.ceylon-lang.org/repo/1/ceylon/language/1.0.0/module-doc/Tuple.type.html
and the fact that value types are flatten to specify the rest, i.e a Tuple 
contains a T first and a Tuple rest.


C++ templates can express heterogeneous tuples:
[ http://en.cppreference.com/w/cpp/utility/tuple |
http://en.cppreference.com/w/cpp/utility/tuple ]
Typically there is a small limit to C++ tuple size, because the underlying
template implementation has its size set to the arity limit.
— John

Rémi

Re: java.util.Pair

2017-07-13 Thread forax 
> De: "John Rose" 
> À: "Rémi Forax" 
> Cc: "joe darcy" , "core-libs-dev"
> 
> Envoyé: Jeudi 13 Juillet 2017 23:05:14
> Objet: Re: java.util.Pair

> On Jul 13, 2017, at 1:39 PM, Remi Forax < [ mailto:fo...@univ-mlv.fr |
> fo...@univ-mlv.fr ] > wrote:

>> Tuples are like an array of value types parameterized by a constant integer

> The homogeneous case is pretty simple; most of what you need is
> to allow a generic type to be parameterized by an integer. C++ templates
> have had that for a long time.

> What's harder is to have a two-step process for type instantiation:
> First, tell me the arity N, and second, for each position under that arity,
> tell me the type T[i], i the most Java-like way to handle it might be type-functions that overload
> alongside generic types. But there are many, many ways to slice it.

or use a recursive definition like in Ceylon 
https://modules.ceylon-lang.org/repo/1/ceylon/language/1.0.0/module-doc/Tuple.type.html
 
and the fact that value types are flatten to specify the rest, i.e a Tuple 
contains a T first and a Tuple rest. 

> C++ templates can express heterogeneous tuples:

> [ http://en.cppreference.com/w/cpp/utility/tuple |
> http://en.cppreference.com/w/cpp/utility/tuple ]

> Typically there is a small limit to C++ tuple size, because the underlying
> template implementation has its size set to the arity limit.

> — John

Rémi

Re: java.util.Pair

2017-07-13 Thread John Rose 
On Jul 13, 2017, at 1:39 PM, Remi Forax  wrote:
> 
> Tuples are like an array of value types parameterized by a constant integer

The homogeneous case is pretty simple; most of what you need is
to allow a generic type to be parameterized by an integer.  C++ templates
have had that for a long time.

What's harder is to have a two-step process for type instantiation:
First, tell me the arity N, and second, for each position under that arity,
tell me the type T[i], ihttp://en.cppreference.com/w/cpp/utility/tuple

Typically there is a small limit to C++ tuple size, because the underlying
template implementation has its size set to the arity limit.

— John

Re: java.util.Pair

2017-07-13 Thread Remi Forax 
Tuples are like an array of value types parameterized by a constant integer so 
it will be interesting to revisit this issue when we will have a clear idea 
about what value types are and how to parameterized a class.

cheers,
Rémi

- Mail original -
> De: "joe darcy" 
> À: "Hohensee, Paul" , core-libs-dev@openjdk.java.net
> Envoyé: Jeudi 13 Juillet 2017 19:22:19
> Objet: Re: java.util.Pair

> Hi Paul,
> 
> See the discussion in thread:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html
> 
> In short, no current plans to add java.util.Pair.
> 
> -Joe
> 
> 
> On 7/13/2017 10:07 AM, Hohensee, Paul wrote:
>> See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273.
>>
>> At Amazon, many projects depend on JavaFX to get only a single class, namely
>> javafx.util.Pair. That means that we must distribute OpenJFX along with our
>> internal OpenJDK distribution, or split javafx.util.Pair out into a separate
>> package, both of which we’d like to avoid in the future. So, are there any
>> plans to add java.util.Pair to JDK10?
>>
>> Thanks,
>>
>> Paul

Re: java.util.Pair

2017-07-13 Thread John Rose 
On Jul 13, 2017, at 10:29 AM, Maurizio Cimadamore 
 wrote:
> 
> Maybe automatic refactoring to Map.Entry ? With the new static method added 
> in 9, creating one is also very fluent (but I
> know that Entry doesn't convey same meaning as Pair in method 
> signatures/fields)

The JavaFX Pair Paul is asking for has key and value components, just like an 
Entry.
Sounds like "Map.entry" should be in the running as a good-enough replacement 
for
"new Pair".

One problem with "just give me (x,y)" is that there are too many ways to 
express a
pair of values in an O-O language, and even more after adding primitives and 
mutability.
(Pure functional languages with complete polymorphism have an easier time.)
The bug report JDK-4947273 very frankly offers five alternative versions, 
thereby
undermining the reporter's case for "a standard Pair class" (where a=1).

It *may* be that the Amber project, after introduces some sort of simplified
class for simple data structures, could help us gravitate toward a (yes, a=1)
standard Pair class, that would be one of those simplified things.  Maybe.

It is much more likely that the Valhalla project, when that grows mature,
will give us enough polymorphism and functional data structures to put
us in the same place as languages like Haskell, where it will be economical
to define a single Pair type.  (I'm hoping for an arity-polymorphic Tuple type,
but that would be a stretch goal.)

— John

Re: java.util.Pair

2017-07-13 Thread Vitaly Davidovich 
Similarly, I've used
https://docs.oracle.com/javase/8/docs/api/java/util/AbstractMap.SimpleEntry.html
and
https://docs.oracle.com/javase/8/docs/api/java/util/AbstractMap.SimpleImmutableEntry.html
in these circumstances.

On Thu, Jul 13, 2017 at 1:29 PM Maurizio Cimadamore <
maurizio.cimadam...@oracle.com> wrote:

> Maybe automatic refactoring to Map.Entry ? With the new static method
> added in 9, creating one is also very fluent (but I know that Entry
> doesn't convey same meaning as Pair in method signatures/fields)
>
> http://download.java.net/java/jdk9/docs/api/java/util/Map.html#entry-K-V-
>
> Cheers
> Maurizio
>
>
> On 13/07/17 18:22, joe darcy wrote:
> > Hi Paul,
> >
> > See the discussion in thread:
> >
> >
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html
> >
> >
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html
> >
> >
> > In short, no current plans to add java.util.Pair.
> >
> > -Joe
> >
> >
> > On 7/13/2017 10:07 AM, Hohensee, Paul wrote:
> >> See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273.
> >>
> >> At Amazon, many projects depend on JavaFX to get only a single class,
> >> namely javafx.util.Pair. That means that we must distribute OpenJFX
> >> along with our internal OpenJDK distribution, or split
> >> javafx.util.Pair out into a separate package, both of which we’d like
> >> to avoid in the future. So, are there any plans to add java.util.Pair
> >> to JDK10?
> >>
> >> Thanks,
> >>
> >> Paul
> >>
> >
>
> --
Sent from my phone

Re: java.util.Pair

2017-07-13 Thread Gary Gregory 
Hi All,

FYI: We added a couple of classes in Apache Commons Lang to deal with pairs
and triples. This is definitely for the pragmatic programmer...

https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/tuple/Pair.html
https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/tuple/ImmutablePair.html
https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/tuple/MutablePair.html
https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/tuple/Triple.html
https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/tuple/ImmutableTriple.html
https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/tuple/MutableTriple.html

Gary


On Thu, Jul 13, 2017 at 11:24 AM, Hohensee, Paul 
wrote:

> Thanks for the immediate response.
>
> Having read the thread, I understand the argument against including Pair
> in the JDK and personally agree with the sw engineering argument. But, it
> got into javafx.util somehow and is now effectively part of the JDK anyway,
> so that ship has sailed. Thus, it seemed reasonable me to just copy it from
> there into java.util, though there would be a maintenance headache if it
> were desired to keep them sync’ed.
>
> I suppose also that there’s a pov that having it in javafx.util indirectly
> encourages JavaFX adoption. (
>
> Anyhow, thanks for the explanation.
>
> Paul
>
> On 7/13/17, 10:22 AM, "joe darcy"  wrote:
>
> Hi Paul,
>
> See the discussion in thread:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-
> March/003973.html
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-
> April/thread.html
>
> In short, no current plans to add java.util.Pair.
>
> -Joe
>
>
> On 7/13/2017 10:07 AM, Hohensee, Paul wrote:
> > See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273.
> >
> > At Amazon, many projects depend on JavaFX to get only a single
> class, namely javafx.util.Pair. That means that we must distribute OpenJFX
> along with our internal OpenJDK distribution, or split javafx.util.Pair out
> into a separate package, both of which we’d like to avoid in the future.
> So, are there any plans to add java.util.Pair to JDK10?
> >
> > Thanks,
> >
> > Paul
> >
>
>
>
>

Re: java.util.Pair

2017-07-13 Thread Hohensee, Paul 
Thanks for the immediate response.

Having read the thread, I understand the argument against including Pair in the 
JDK and personally agree with the sw engineering argument. But, it got into 
javafx.util somehow and is now effectively part of the JDK anyway, so that ship 
has sailed. Thus, it seemed reasonable me to just copy it from there into 
java.util, though there would be a maintenance headache if it were desired to 
keep them sync’ed.

I suppose also that there’s a pov that having it in javafx.util indirectly 
encourages JavaFX adoption. (

Anyhow, thanks for the explanation.

Paul

On 7/13/17, 10:22 AM, "joe darcy"  wrote:

Hi Paul,

See the discussion in thread:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html

In short, no current plans to add java.util.Pair.

-Joe


On 7/13/2017 10:07 AM, Hohensee, Paul wrote:
> See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273.
>
> At Amazon, many projects depend on JavaFX to get only a single class, 
namely javafx.util.Pair. That means that we must distribute OpenJFX along with 
our internal OpenJDK distribution, or split javafx.util.Pair out into a 
separate package, both of which we’d like to avoid in the future. So, are there 
any plans to add java.util.Pair to JDK10?
>
> Thanks,
>
> Paul
>

Re: java.util.Pair

2017-07-13 Thread Hohensee, Paul 
That’s a possibility. We could recommend that as an alternative.

Thanks,

Paul

On 7/13/17, 10:29 AM, "Maurizio Cimadamore"  
wrote:

Maybe automatic refactoring to Map.Entry ? With the new static method 
added in 9, creating one is also very fluent (but I know that Entry 
doesn't convey same meaning as Pair in method signatures/fields)

http://download.java.net/java/jdk9/docs/api/java/util/Map.html#entry-K-V-

Cheers
Maurizio


On 13/07/17 18:22, joe darcy wrote:
> Hi Paul,
>
> See the discussion in thread:
>
> 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html 
>
> 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html 
>
>
> In short, no current plans to add java.util.Pair.
>
> -Joe
>
>
> On 7/13/2017 10:07 AM, Hohensee, Paul wrote:
>> See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273.
>>
>> At Amazon, many projects depend on JavaFX to get only a single class, 
>> namely javafx.util.Pair. That means that we must distribute OpenJFX 
>> along with our internal OpenJDK distribution, or split 
>> javafx.util.Pair out into a separate package, both of which we’d like 
>> to avoid in the future. So, are there any plans to add java.util.Pair 
>> to JDK10?
>>
>> Thanks,
>>
>> Paul
>>
>

Re: java.util.Pair

2017-07-13 Thread Maurizio Cimadamore 
Maybe automatic refactoring to Map.Entry ? With the new static method 
added in 9, creating one is also very fluent (but I know that Entry 
doesn't convey same meaning as Pair in method signatures/fields)


http://download.java.net/java/jdk9/docs/api/java/util/Map.html#entry-K-V-

Cheers
Maurizio


On 13/07/17 18:22, joe darcy wrote:

Hi Paul,

See the discussion in thread:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html 

http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html 



In short, no current plans to add java.util.Pair.

-Joe


On 7/13/2017 10:07 AM, Hohensee, Paul wrote:

See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273.

At Amazon, many projects depend on JavaFX to get only a single class, 
namely javafx.util.Pair. That means that we must distribute OpenJFX 
along with our internal OpenJDK distribution, or split 
javafx.util.Pair out into a separate package, both of which we’d like 
to avoid in the future. So, are there any plans to add java.util.Pair 
to JDK10?


Thanks,

Paul

Re: java.util.Pair

2017-07-13 Thread joe darcy 

Hi Paul,

See the discussion in thread:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html

In short, no current plans to add java.util.Pair.

-Joe


On 7/13/2017 10:07 AM, Hohensee, Paul wrote:

See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273.

At Amazon, many projects depend on JavaFX to get only a single class, namely 
javafx.util.Pair. That means that we must distribute OpenJFX along with our 
internal OpenJDK distribution, or split javafx.util.Pair out into a separate 
package, both of which we’d like to avoid in the future. So, are there any 
plans to add java.util.Pair to JDK10?

Thanks,

Paul

Re: [9] JDK-8184306: zlib 1.2.11 upgrade triggers j.u.zip.Deflater regression

2017-07-13 Thread Martin Buchholz 
Random drive-by comments.

- consider adding a link to the JDK bug to the zlib bug.

- configure on linux reports:
  --with-zlib use zlib from build system or OpenJDK source
  (system, bundled) [bundled]
Does this need updating to "system" ?

java.util.Pair

2017-07-13 Thread Hohensee, Paul 
See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273.

At Amazon, many projects depend on JavaFX to get only a single class, namely 
javafx.util.Pair. That means that we must distribute OpenJFX along with our 
internal OpenJDK distribution, or split javafx.util.Pair out into a separate 
package, both of which we’d like to avoid in the future. So, are there any 
plans to add java.util.Pair to JDK10?

Thanks,

Paul

Re: RFR: 8184311: Update java.sql and java.sql.rowset API docs for accessibility

2017-07-13 Thread Jonathan Gibbons 

Thanks, Lance

-- Jon


On 7/13/17 3:20 AM, Lance Andersen wrote:

looks fine Jon

On Jul 12, 2017, at 10:06 PM, Jonathan Gibbons 
mailto:jonathan.gibb...@oracle.com>> wrote:


Please review ...

More noreg-doc API cleanup for accessibility, etc.  This time for 
java.sql and java.sql.rowset.
One of the tables ought to be restructured a bit, because there is no 
single unique column
to use for a rowheader, but that is a bigger change than I want to do 
in this round of updates.


JBS: https://bugs.openjdk.java.net/browse/JDK-8184311
Webrev: http://cr.openjdk.java.net/~jjg/8184311/webrev.00/ 

API: http://cr.openjdk.java.net/~jjg/8184311/api.00/ 



-- Jon






Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com

RE: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel()

2017-07-13 Thread Kazunori Ogata 
Hi Christoph,

Thank you for your help!


Regards,
Ogata

"Langer, Christoph"  wrote on 2017/07/13 
19:32:32:

> From: "Langer, Christoph" 
> To: Kazunori Ogata 
> Cc: core-libs-dev , "nio-
> d...@openjdk.java.net" 
> Date: 2017/07/13 19:32
> Subject: RE: 8182743: Ineffective use of volatile hurts performance of 
> Charset.atBugLevel()
> 
> Hi Ogata,
> 
> I'll take care of backporting a fix to remove the "volatile" qualifier 
for
> both, JDK-8182743 and JDK-8184330.
> 
> Best regards
> Christoph
> 
> > -Original Message-
> > From: Kazunori Ogata [mailto:oga...@jp.ibm.com]
> > Sent: Freitag, 7. Juli 2017 18:59
> > To: core-libs-dev ; nio-
> > d...@openjdk.java.net
> > Cc: Langer, Christoph 
> > Subject: RE: 8182743: Ineffective use of volatile hurts performance of
> > Charset.atBugLevel()
> > 
> > Hi all,
> > 
> > Any comment on downporting a fix to JDK9u and JDK8u, which simply
> > removes
> > volatile?
> > 
> > 
> > Regards,
> > Ogata
> > 
> > Kazunori Ogata/Japan/IBM wrote on 2017/07/03 17:28:54:
> > 
> > > From: Kazunori Ogata/Japan/IBM
> > > To: "Langer, Christoph" 
> > > Cc: core-libs-dev , "nio-
> > > d...@openjdk.java.net" 
> > > Date: 2017/07/03 17:28
> > > Subject: RE: 8182743: Ineffective use of volatile hurts performance 
of
> > > Charset.atBugLevel()
> > >
> > > Hi Christoph,
> > >
> > > Thank you very much for your help!
> > >
> > > For JDK9 updates and JDK8 updates, it is desirable if we can back 
port
> > the
> > > removal of volatile.  What should I do for it?
> > >
> > > Regards,
> > > Ogata
> > >
> > > From: "Langer, Christoph" 
> > > To: Kazunori Ogata , "nio-...@openjdk.java.net"
> >  > > d...@openjdk.java.net>
> > > Cc: core-libs-dev 
> > > Date: 2017/07/03 17:17
> > > Subject: RE: 8182743: Ineffective use of volatile hurts performance 
of
> > > Charset.atBugLevel()
> > >
> > > Hi,
> > >
> > > I've pushed to JDK10 now:
> > http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/
> > > 7a2bc0a80087
> > >
> > > What do you think, shall we try to downport a fix to JDK9 updates 
and
> > JDK8
> > > updates, which simply removes the volatile as we can't bring this
> > behavior
> > > changing fix down?
> > >
> > > Thanks
> > > Christoph
> > >
> > > > -Original Message-
> > > > From: Kazunori Ogata [mailto:oga...@jp.ibm.com]
> > > > Sent: Freitag, 30. Juni 2017 20:31
> > > > To: Seán Coffey 
> > > > Cc: Langer, Christoph ; core-libs-dev
> >  > > > d...@openjdk.java.net>; nio-...@openjdk.java.net; ppc-aix-port-
> > > > d...@openjdk.java.net
> > > > Subject: Re: 8182743: Ineffective use of volatile hurts 
performance of
> > > > Charset.atBugLevel()
> > > >
> > > > Hi Sean,
> > > >
> > > > Thank you for your comments.
> > > >
> > > > I fixed the copyright and updated webrev:
> > > >
> > > > http://cr.openjdk.java.net/~horii/8182743/webrev.03/
> > > >
> > > >
> > > > > * The bug ID referenced in mail/webrev links is wrong. It should 
be
> > > > > 8182743 ?
> > > >
> > > > Yes, they should be 8182743.  I fixed both.
> > > >
> > > >
> > > > Regards,
> > > > Ogata
> > > >
> > > >
> > > > Seán Coffey  wrote on 2017/06/30 23:57:25:
> > > >
> > > > > From: Seán Coffey 
> > > > > To: Kazunori Ogata , "Langer, Christoph"
> > > > > 
> > > > > Cc: "ppc-aix-port-...@openjdk.java.net"  > > > > d...@openjdk.java.net>, core-libs-dev
> > ,
> > > > > "nio-...@openjdk.java.net" 
> > > > > Date: 2017/06/30 23:57
> > > > > Subject: Re: 8179527:(8182743?) Ineffective use of volatile 
hurts
> > > > > performance of Charset.atBugLevel()
> > > > >
> > > > > Ogata,
> > > > >
> > > > > minor comments from me.
> > > > >
> > > > > * The bug ID referenced in mail/webrev links is wrong. It should 
be
> > > > > 8182743 ?
> > > > > * The copyright change in Charset-X-Coder.java.template is the 
wrong
> > > > > format. You can simply replace 2013 with 2017.
> > > > >
> > > > > Regards,
> > > > > Sean.
> > > > >
> > > > > On 29/06/17 19:49, Kazunori Ogata wrote:
> > > > > > Hi Christoph,
> > > > > >
> > > > > > I updated webrev:
> > > > http://cr.openjdk.java.net/~horii/8179527/webrev.02/
> > > > > >
> > > > > > This one includes changes in tests.  I removed all @run and 
@build
> > > > > > directives in the tests because those after removing "@run
> > > > main/othervm
> > > > > > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as 
the
> > > > default
> > > > > > ones.  I checked the modified tests passed.
> > > > > >
> > > > > > I also fixed the copyright lines.
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Ogata
> > > > > >
> > > > > >
> > > > > > "Langer, Christoph"  wrote on
> > 2017/06/28
> > > > > > 21:04:36:
> > > > > >
> > > > > >> From: "Langer, Christoph" 
> > > > > >> To: Kazunori Ogata 
> > > > > >> Cc: Alan Bateman , Claes Redestad
> > > > > >> , core-libs-dev  > > > > >> d...@openjdk.java.net>, "nio-...@openjdk.java.net"  > > > > >> d...@openjdk.java.net>, "ppc-aix-port-...@openjdk.java.net"
> > > > > >  > > > > >> d...@openjdk.java.net>
> > > > > >> Date: 2017/06/28 21:04
> > > > > >> Sub

RE: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel()

2017-07-13 Thread Langer, Christoph 
Hi Ogata,

I'll take care of backporting a fix to remove the "volatile" qualifier for 
both, JDK-8182743 and JDK-8184330.

Best regards
Christoph

> -Original Message-
> From: Kazunori Ogata [mailto:oga...@jp.ibm.com]
> Sent: Freitag, 7. Juli 2017 18:59
> To: core-libs-dev ; nio-
> d...@openjdk.java.net
> Cc: Langer, Christoph 
> Subject: RE: 8182743: Ineffective use of volatile hurts performance of
> Charset.atBugLevel()
> 
> Hi all,
> 
> Any comment on downporting a fix to JDK9u and JDK8u, which simply
> removes
> volatile?
> 
> 
> Regards,
> Ogata
> 
> Kazunori Ogata/Japan/IBM wrote on 2017/07/03 17:28:54:
> 
> > From: Kazunori Ogata/Japan/IBM
> > To: "Langer, Christoph" 
> > Cc: core-libs-dev , "nio-
> > d...@openjdk.java.net" 
> > Date: 2017/07/03 17:28
> > Subject: RE: 8182743: Ineffective use of volatile hurts performance of
> > Charset.atBugLevel()
> >
> > Hi Christoph,
> >
> > Thank you very much for your help!
> >
> > For JDK9 updates and JDK8 updates, it is desirable if we can back port
> the
> > removal of volatile.  What should I do for it?
> >
> > Regards,
> > Ogata
> >
> > From: "Langer, Christoph" 
> > To: Kazunori Ogata , "nio-...@openjdk.java.net"
>  > d...@openjdk.java.net>
> > Cc: core-libs-dev 
> > Date: 2017/07/03 17:17
> > Subject: RE: 8182743: Ineffective use of volatile hurts performance of
> > Charset.atBugLevel()
> >
> > Hi,
> >
> > I've pushed to JDK10 now:
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/
> > 7a2bc0a80087
> >
> > What do you think, shall we try to downport a fix to JDK9 updates and
> JDK8
> > updates, which simply removes the volatile as we can't bring this
> behavior
> > changing fix down?
> >
> > Thanks
> > Christoph
> >
> > > -Original Message-
> > > From: Kazunori Ogata [mailto:oga...@jp.ibm.com]
> > > Sent: Freitag, 30. Juni 2017 20:31
> > > To: Seán Coffey 
> > > Cc: Langer, Christoph ; core-libs-dev
>  > > d...@openjdk.java.net>; nio-...@openjdk.java.net; ppc-aix-port-
> > > d...@openjdk.java.net
> > > Subject: Re: 8182743: Ineffective use of volatile hurts performance of
> > > Charset.atBugLevel()
> > >
> > > Hi Sean,
> > >
> > > Thank you for your comments.
> > >
> > > I fixed the copyright and updated webrev:
> > >
> > > http://cr.openjdk.java.net/~horii/8182743/webrev.03/
> > >
> > >
> > > > * The bug ID referenced in mail/webrev links is wrong. It should be
> > > > 8182743 ?
> > >
> > > Yes, they should be 8182743.  I fixed both.
> > >
> > >
> > > Regards,
> > > Ogata
> > >
> > >
> > > Seán Coffey  wrote on 2017/06/30 23:57:25:
> > >
> > > > From: Seán Coffey 
> > > > To: Kazunori Ogata , "Langer, Christoph"
> > > > 
> > > > Cc: "ppc-aix-port-...@openjdk.java.net"  > > > d...@openjdk.java.net>, core-libs-dev
> ,
> > > > "nio-...@openjdk.java.net" 
> > > > Date: 2017/06/30 23:57
> > > > Subject: Re: 8179527:(8182743?) Ineffective use of volatile hurts
> > > > performance of Charset.atBugLevel()
> > > >
> > > > Ogata,
> > > >
> > > > minor comments from me.
> > > >
> > > > * The bug ID referenced in mail/webrev links is wrong. It should be
> > > > 8182743 ?
> > > > * The copyright change in Charset-X-Coder.java.template is the wrong
> > > > format. You can simply replace 2013 with 2017.
> > > >
> > > > Regards,
> > > > Sean.
> > > >
> > > > On 29/06/17 19:49, Kazunori Ogata wrote:
> > > > > Hi Christoph,
> > > > >
> > > > > I updated webrev:
> > > http://cr.openjdk.java.net/~horii/8179527/webrev.02/
> > > > >
> > > > > This one includes changes in tests.  I removed all @run and @build
> > > > > directives in the tests because those after removing "@run
> > > main/othervm
> > > > > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the
> > > default
> > > > > ones.  I checked the modified tests passed.
> > > > >
> > > > > I also fixed the copyright lines.
> > > > >
> > > > >
> > > > > Regards,
> > > > > Ogata
> > > > >
> > > > >
> > > > > "Langer, Christoph"  wrote on
> 2017/06/28
> > > > > 21:04:36:
> > > > >
> > > > >> From: "Langer, Christoph" 
> > > > >> To: Kazunori Ogata 
> > > > >> Cc: Alan Bateman , Claes Redestad
> > > > >> , core-libs-dev  > > > >> d...@openjdk.java.net>, "nio-...@openjdk.java.net"  > > > >> d...@openjdk.java.net>, "ppc-aix-port-...@openjdk.java.net"
> > > > >  > > > >> d...@openjdk.java.net>
> > > > >> Date: 2017/06/28 21:04
> > > > >> Subject: RE: 8179527: Ineffective use of volatile hurts
> performance
> > > of
> > > > >> Charset.atBugLevel()
> > > > >>
> > > > >> Hi Ogata,
> > > > >>
> > > >  remove the second run with -Dsun.nio.cs.bugLevel=1.4
> > > > >>> How can I do this?  Is it sufficient to remove the following
> line at
> > > > > the
> > > > >>> beginning of the file?: "@run main/othervm
> -Dsun.nio.cs.bugLevel=1.4
> > > > >>> EmptyCharsetName"
> > > > >> Yes, this line should be removed. Currently there are two @run
> > > > > directives
> > > > >> which cause running the testcase twice. Once in normal mode and
> once
> > > > > with
> > > > >> bugLevel set to 1.4. So, if "sun.nio.cs.bugL

Re: RFR: 8184311: Update java.sql and java.sql.rowset API docs for accessibility

2017-07-13 Thread Lance Andersen 
looks fine Jon

> On Jul 12, 2017, at 10:06 PM, Jonathan Gibbons  
> wrote:
> 
> Please review ...
> 
> More noreg-doc API cleanup for accessibility, etc.  This time for java.sql 
> and java.sql.rowset.
> One of the tables ought to be restructured a bit, because there is no single 
> unique column
> to use for a rowheader, but that is a bigger change than I want to do in this 
> round of updates.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8184311
> Webrev: http://cr.openjdk.java.net/~jjg/8184311/webrev.00/
> API: http://cr.openjdk.java.net/~jjg/8184311/api.00/
> 
> -- Jon
> 
> 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

JDK 10 RFR of JDK-8183377: Refactor java/lang/ClassLoader/deadlock shell tests to java

2017-07-13 Thread Amy Lu 

java/lang/ClassLoader/deadlock/TestCrossDelegate.sh
java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh

Please review this patch to refactor the shell tests to java.

bug: https://bugs.openjdk.java.net/browse/JDK-8183377
http://cr.openjdk.java.net/~amlu/8183377/webrev.00/

Thanks,
Amy