Re: RFR[12] JDK-8211107: LDAPS communication failure with jdk 1.8.0_181

[vyom tewari]

Hi Prasad,

Change looks good to me, can you please put some comment why we are not 
performing "ssl handshake" if connectTime <= 0. This will help future 
maintainer of this code.


Thanks,

Vyom

On Tuesday 02 October 2018 06:39 AM, Prasadrao Koppula wrote:

Hi,

  


Could you please review this patch. This patch fixes the regression caused by 
LDAP fixes in JDK11, JDK8u181, JDK7u191

  


Webrev: http://cr.openjdk.java.net/~pkoppula/8211107/webrev.01/

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

  

  


Thanks,

Prasad.K

  

Re: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike

[joe darcy]

Changes look fine; thanks,

-Joe


On 10/1/2018 4:43 PM, Lance Andersen wrote:

The changes look reasonable Ivan


On Oct 1, 2018, at 7:37 PM, Ivan Gerasimov  wrote:

Hello!

A handful of a few similar typos across core-libs/security-libs areas.

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381
WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/

Would you please help review the fix?

--
With kind regards,
Ivan Gerasimov


  
   

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

RFR[12] JDK-8211107: LDAPS communication failure with jdk 1.8.0_181

[Prasadrao Koppula]

Hi,

 

Could you please review this patch. This patch fixes the regression caused by 
LDAP fixes in JDK11, JDK8u181, JDK7u191

 

Webrev: http://cr.openjdk.java.net/~pkoppula/8211107/webrev.01/ 

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

 

 

Thanks,

Prasad.K

 

Re: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike

[Bradford Wetmore]

I checked the last 6 only (SSLEngine+).  Looks good.

Brad


On 10/1/2018 4:37 PM, Ivan Gerasimov wrote:

Hello!

A handful of a few similar typos across core-libs/security-libs areas.

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381
WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/

Would you please help review the fix?

Re: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike

[Lance Andersen]

The changes look reasonable Ivan

> On Oct 1, 2018, at 7:37 PM, Ivan Gerasimov  wrote:
> 
> Hello!
> 
> A handful of a few similar typos across core-libs/security-libs areas.
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381
> WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/
> 
> Would you please help review the fix?
> 
> -- 
> With kind regards,
> Ivan Gerasimov
> 

 
  

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

RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike

[Ivan Gerasimov]

Hello!

A handful of a few similar typos across core-libs/security-libs areas.

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381
WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/

Would you please help review the fix?

--
With kind regards,
Ivan Gerasimov

Re: RFR(M) : 8211171 : move JarUtils to top-level testlibrary

[Igor Ignatyev]

Hi Alan,

thanks for your review!

-- Igor

> On Sep 30, 2018, at 8:00 AM, Alan Bateman  wrote:
> 
> On 27/09/2018 00:38, Igor Ignatyev wrote:
>> here is the webrevs w/ JarUtils from default package inserted into 
>> jdk.test.lib.util.JarUtils:
>> whole patch: 
>> http://cr.openjdk.java.net/~iignatyev//8211171/webrev.01/index.html 
>> 
>>> 655 lines changed: 239 ins; 355 del; 61 mod;
>> incremental: 
>> http://cr.openjdk.java.net/~iignatyev//8211171/webrev.0-1/index.html 
>> 
>>> 476 lines changed: 239 ins; 203 del; 34 mod;
>> 
>> doing that, I noticed that both updateJarFile and createJarFile don't close 
>> Stream from Files::find, the current patch fixes that.
>> 
> I see you've also deprecated the String methods in the old class - good! I'd 
> probably carry over test/jdk/lib/testlibrary/JarUtils.java without changing 
> the format but your IDE must be setup differently and it will get changed 
> again by whoever next changes it so I think it's okay.
> 
> The update to tests using this look fine.
> 
> -Alan

Re: 8152910: Get performance improvement with Stable annotation

[Brian Burkhalter]

Hi Rémi,

You’re right: that was stupid, especially given the work currently being done 
for https://bugs.openjdk.java.net/browse/JDK-8211300.

Will change.

Thanks,

Brian

On Oct 1, 2018, at 2:46 PM, Remi Forax  wrote:

> can you move the [] to the right place at the same time, to use the java 
> syntax not the C one.
> i.e.
>   @Stable
>   private static final BigInteger[] posConst = new BigInteger[MAX_CONSTANT+1];
> instead of
>   @Stable
>   private static final BigInteger posConst[] = new BigInteger[MAX_CONSTANT+1];

Re: 8152910: Get performance improvement with Stable annotation

[Remi Forax]

Hi Brian,
can you move the [] to the right place at the same time, to use the java syntax 
not the C one.
i.e.
   @Stable
   private static final BigInteger[] posConst = new BigInteger[MAX_CONSTANT+1];
instead of
   @Stable
   private static final BigInteger posConst[] = new BigInteger[MAX_CONSTANT+1];

cheers,
Rémi

- Mail original -
> De: "Brian Burkhalter" 
> À: "core-libs-dev" 
> Envoyé: Lundi 1 Octobre 2018 23:31:22
> Objet: 8152910: Get performance improvement with Stable annotation

> Please review at your convenience:
> 
> https://bugs.openjdk.java.net/browse/JDK-8152910
> 
> JMH benchmarks do show a slight but measurable performance improvement with 
> the
> below patch applied.
> 
> Thanks,
> 
> Brian
> 
> --- a/src/java.base/share/classes/java/math/BigInteger.java
> +++ b/src/java.base/share/classes/java/math/BigInteger.java
> @@ -41,6 +41,7 @@
> import jdk.internal.math.DoubleConsts;
> import jdk.internal.math.FloatConsts;
> import jdk.internal.HotSpotIntrinsicCandidate;
> +import jdk.internal.vm.annotation.Stable;
> 
> /**
>  * Immutable arbitrary-precision integers.  All operations behave as if
> @@ -1219,8 +1220,10 @@
>  * Initialize static constant array when class is loaded.
>  */
> private static final int MAX_CONSTANT = 16;
> -private static BigInteger posConst[] = new BigInteger[MAX_CONSTANT+1];
> -private static BigInteger negConst[] = new BigInteger[MAX_CONSTANT+1];
> +@Stable
> +private static final BigInteger posConst[] = new
> BigInteger[MAX_CONSTANT+1];
> +@Stable
> +private static final BigInteger negConst[] = new
> BigInteger[MAX_CONSTANT+1];

6516099: InputStream.skipFully(int k) to skip exactly k bytes

[Brian Burkhalter]

https://bugs.openjdk.java.net/browse/JDK-6516099
http://cr.openjdk.java.net/~bpb/6516099/webrev.00/

This patch implements a method InputStream.skipNBytes() instead of skipFully() 
based on the supposition that this name is less likely to conflict with 
existing subclasses, e.g., [1]. There is some inconsistency however with 
respect to the description of the method readNBytes() [2], which may return 
fewer than N bytes if end of stream is reached first.

If we converge on a solution in this thread I’ll file a CSR.

Thanks,

Brian

[1] 
https://developer.ibm.com/static/site-id/155/maximodev/7609/maximocore/businessobjects/psdi/iface/webservices/action/bytecode/ClassReader.html
[2] 
https://download.java.net/java/early_access/jdk12/docs/api/java.base/java/io/InputStream.html#readNBytes(byte[],int,int)

8152910: Get performance improvement with Stable annotation

[Brian Burkhalter]

Please review at your convenience:

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

JMH benchmarks do show a slight but measurable performance improvement with the 
below patch applied.

Thanks,

Brian

--- a/src/java.base/share/classes/java/math/BigInteger.java
+++ b/src/java.base/share/classes/java/math/BigInteger.java
@@ -41,6 +41,7 @@
 import jdk.internal.math.DoubleConsts;
 import jdk.internal.math.FloatConsts;
 import jdk.internal.HotSpotIntrinsicCandidate;
+import jdk.internal.vm.annotation.Stable;
 
 /**
  * Immutable arbitrary-precision integers.  All operations behave as if
@@ -1219,8 +1220,10 @@
  * Initialize static constant array when class is loaded.
  */
 private static final int MAX_CONSTANT = 16;
-private static BigInteger posConst[] = new BigInteger[MAX_CONSTANT+1];
-private static BigInteger negConst[] = new BigInteger[MAX_CONSTANT+1];
+@Stable
+private static final BigInteger posConst[] = new 
BigInteger[MAX_CONSTANT+1];
+@Stable
+private static final BigInteger negConst[] = new 
BigInteger[MAX_CONSTANT+1];

Re: RFR 8211295: DriverManager.getConnection fails when called from com.sun.rowset.JdbcRowSetImpl

[Lance Andersen]

> On Oct 1, 2018, at 1:09 PM, Mandy Chung  wrote:
> 
> 
> 
> On 9/29/18 1:59 PM, Lance Andersen wrote:
>> Attached is the webrev for the JDBC RowSet/DriverManager issue, 
>> https://bugs.openjdk.java.net/browse/JDK-8211295 
>> ,  that was raised on the 
>> thread: 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055755.html
>>  
>> 
>> 
>> I have run the JDBC TestSuite against the Derby Embedded and Derby Network 
>> server;  Mach 5 jdk tier1, tier2, and tier3 tests as well as the JCK 
>> java.sql and javax.sql tests.  All pass with the fix
>> 
>> The webrev can be found at 
>> http://cr.openjdk.java.net/~lancea/8211295/webrev.00/ 
>> 
> 
> The change looks okay.DriverManager::drivers and a few other methods are 
> caller-sensitive.  If they were called from java.sql.rowset, it won't work 
> properly.   I believe no such code path and so it's okay.

That is correct, only DriverManager::getConnection is called

> 
> We should try again to investigate removing @CallerSensitive from 
> DriverManager in the future:
>https://bugs.openjdk.java.net/browse/JDK-8154346 
> 

OK, let the fun times begin ;-) 
> 
> Mandy

 
  

 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: Convert old-style array declarations (was: Re: ByteArrayOutputStream should not have a new writeBytes method in Java)

[Martin Buchholz]

Thank you very much for working on these cleanups.  I've occasionally done
similar in the past.

I've made big changesets with only one automated change at a time.
So e.g. I would do only
"C-style array declaration"
in one changeset.  This is one example of a change that should leave zero
impact on the generated bytecode, and that should be testable, if only by
comparing the .class files for identical size.

One difficulty is that the copy of the source code in openjdk may not be
the "master" copy - it may be imported from some other project, and in
general it's hard to tell.

On Sun, Sep 30, 2018 at 8:40 PM, Tagir Valeev  wrote:

> Hello!
>
> Ok, let's start with smaller thing which is java.desktop. Created a
> JBS issue and posted a patch here:
> http://mail.openjdk.java.net/pipermail/2d-dev/2018-October/009486.html
>
> Jonathan,
>
> > Although cleanup like this is nice, I'll give a word of warning that
> pervasive
> > changes like that can sometimes cause difficulties when there are lots of
> > changes in code which is undergoing different lines of development in
> different
> > branches or repos. If nothing else, I'd consider doing it on a
> per-component
> > or per-module basis.
>
> I'm not sure I have enough time to post 70+ reviews for every module
> and track all of them. My volunteering abilities are quite limited :-)
> I think I can manage up to 3-4 separate changesets including already
> posted java.desktop change. If you have suggestions on how to split
> this to several big parts, you are welcome (I don't know how
> "components" are mapped to modules, probably components are big
> enough?). Or probably we can cover only part of modules for now and
> wait for the next volunteer to pick up this.
>
> With best regards,
> Tagir Valeev.
>
>
> On Sat, Sep 29, 2018 at 5:41 AM Sergey Bylokhov
>  wrote:
> >
> > I can review the changes in java.desktop, please use these email alias
> > awt-dev/2d-dev/swing-dev.
> >
> > On 28/09/2018 04:13, Alan Bateman wrote:
> > > As regards doing the entire source base then I think that would be
> good.
> > > Due to the complexity of testing, changes to the java.desktop module
> are
> > > pushed to jdk/client repo rather than jdk/jdk so if it's not too
> awkward
> > > then it might be helper if the patch for java.desktop were a separate
> > > change that gets pushed to jdk/client rather than jdk/jdk.
> >
> >
> > --
> > Best regards, Sergey.
>

Re: Optimized HashSet.toArray()

[Martin Buchholz]

Thanks, Tagir.

I agree these optimizations are worth doing.  I have worked on similar
toArray methods in other Collection implementations.

I have a benchmark that is also a correctness test
Collection/IteratorMicroBenchmark.java
but I never added any Set implementations since I intentionally want to
test duplicates and we'd have to special-case Sets somehow.

We probably want to check in the jmh benchmark, but not sure where - there
have been recent discussions ... """Reviving JEP 230: Microbenchmark
Suite"""

On Sun, Sep 30, 2018 at 10:03 PM, Tagir Valeev  wrote:

> Hello!
>
> I think that HashSet.toArray(), HashMap.keySet().toArray() and
> HashMap.values().toArray() methods are used often enough to deserve a
> dedicated optimized implementation. Here's the patch I propose which
> is based on KeySet#forEach and AbstractCollection#toArray
> implementations:
> http://cr.openjdk.java.net/~tvaleev/patches/hashset_toarray/patch.txt
>
> I performed quick JMH test for HashSet.toArray(). The source code is here:
> http://cr.openjdk.java.net/~tvaleev/patches/hashset_
> toarray/jmh/ToArray.java
>
> Result on JDK 11+28 is here:
> http://cr.openjdk.java.net/~tvaleev/patches/hashset_
> toarray/jmh/jmh_toArray_11.txt
>
> Result on JDK 11+28 with patch applied is here
> http://cr.openjdk.java.net/~tvaleev/patches/hashset_
> toarray/jmh/jmh_toArray_11_patched.txt
>
> Summary (non-patched):
> Benchmark  (size)  Score  Error  Units
> ToArray.toArray 0  6,327 ±0,094  ns/op
> ToArray.toArray 1 55,040 ±0,389  ns/op
> ToArray.toArray10112,903 ±3,571  ns/op
> ToArray.toArray  1000  11281,875 ±   74,423  ns/op
> ToArray.toArray102795345,640 ±57164,196  ns/op
> ToArray.toArray  1000  443763064,267 ± 82551994,563  ns/op
> ToArray.toArrayPresized 0  8,244 ±0,054  ns/op
> ToArray.toArrayPresized 1 57,094 ±0,431  ns/op
> ToArray.toArrayPresized10105,456 ±3,831  ns/op
> ToArray.toArrayPresized  1000  11935,895 ±  251,150  ns/op
> ToArray.toArrayPresized102771938,363 ±42917,423  ns/op
> ToArray.toArrayPresized  1000  421335484,317 ± 66222482,723  ns/op
> ToArray.toObjectArray   0  8,288 ±0,060  ns/op
> ToArray.toObjectArray   1 49,415 ±2,454  ns/op
> ToArray.toObjectArray  10 94,243 ±2,346  ns/op
> ToArray.toObjectArray1000  10061,125 ±   77,197  ns/op
> ToArray.toObjectArray  102455011,037 ±86539,734  ns/op
> ToArray.toObjectArray1000  416595706,650 ± 84619961,188  ns/op
>
> Summary (patched):
> Benchmark  (size)   Score  Error  Units
> ToArray.toArray 0   5,319 ±0,050  ns/op
> ToArray.toArray 1  22,235 ±0,365  ns/op
> ToArray.toArray10  57,515 ±0,687  ns/op
> ToArray.toArray  10006586,112 ±   71,258  ns/op
> ToArray.toArray10 1700754,903 ±41289,676  ns/op
> ToArray.toArray  1000   299815797,250 ± 37778823,759  ns/op
> ToArray.toArrayPresized 0   6,689 ±0,042  ns/op
> ToArray.toArrayPresized 1  44,852 ±0,813  ns/op
> ToArray.toArrayPresized10  66,904 ±0,748  ns/op
> ToArray.toArrayPresized  10007839,880 ±   75,954  ns/op
> ToArray.toArrayPresized10 1605381,429 ±55070,143  ns/op
> ToArray.toArrayPresized  1000   292954965,933 ± 45912224,761  ns/op
> ToArray.toObjectArray   0   6,608 ±0,049  ns/op
> ToArray.toObjectArray   1  28,085 ±0,326  ns/op
> ToArray.toObjectArray  10  58,170 ±2,716  ns/op
> ToArray.toObjectArray10005979,407 ±   55,930  ns/op
> ToArray.toObjectArray  10 1420318,139 ±27226,724  ns/op
> ToArray.toObjectArray1000   255417541,372 ± 33366555,142  ns/op
>
> As you can see, the patched version is always faster, sometimes 2x and
> even more. Also it doesn't allocate anything except the target array
> when necessary (current version allocates an iterator).
>
> If anybody is interested to sponsor this change, I can log a JBS issue
> and provide proper webrev for review. Do we need to add new unit-tests
> or these methods are covered enough by existing tests?
>
> With best regards,
> Tagir Valeev.
>

Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

[Naoto Sato]

+1. Added myself as a reviewer of the CSR. Thanks for working on this.

Naoto

On 10/1/18 9:38 AM, Pallavi Sonal wrote:

Thanks Roger, made the suggested changes.

Thanks,

Pallavi Sonal

*From:*Roger Riggs
*Sent:* Monday, October 01, 2018 9:29 PM
*To:* Pallavi Sonal ; Naoto Sato 
; core-libs-dev 
*Subject:* Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should 
handle offsets


Hi,

The checkbox for compatibility Kind Behavioral should be checked. (You 
may need to hit Edit to see it).

A simple description of the compatibility risk may help clarify minimal.
Something to the effect, that there is no change in formatting behavior
and that parsing will now accept a numeric offset.

Otherwise, looks fine.

Thanks, Roger

On 10/01/2018 09:24 AM, Pallavi Sonal wrote:

Hi Naoto,

Here is the CSR for review :

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


Thanks,

Pallavi Sonal

-Original Message-

From: Naoto Sato

Sent: Friday, September 28, 2018 9:38 PM

To: Pallavi Sonal ; Roger 
Riggs ; 
core-libs-dev 

Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle 
offsets

Hi Pallavi,

Please file a CSR for this, as this will change the behavior.

Naoto

On 9/28/18 8:53 AM, Pallavi Sonal wrote:

Thanks Roger. I will update it before the commit.

-Original Message-

From: Roger Riggs

Sent: Friday, September 28, 2018 6:15 PM

To: Pallavi Sonal 
; core-libs-dev




Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should

handle offsets

Hi Pallavi,

Looks fine,

But can you re-wrap the lines with the new links, they got longer than

100 chars with the link.

No new webrev is needed.

Thanks, Roger

On 9/28/18 8:35 AM, Pallavi Sonal wrote:

Thanks Roger and Stephen. Here is the updated webrev with the 
suggested changes:

http://cr.openjdk.java.net/~rpatil/8166138/webrev.04/


Thanks,

Pallavi Sonal

-Original Message-

From: Roger Riggs

Sent: Friday, September 28, 2018 12:51 AM

To: core-libs-dev


Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should

handle offsets

Hi Pallavi,

I'd suggest using @link for the reference (in both files).

It will be easier for the reader to traverse and understand the 
pattern.

DateTimeFormatterBuilder.java: line 836.

The trailing "" should be omitted so the readability of the 
source is maintained.

Otherwise, looks good,

Thanks, Roger

On 09/27/2018 03:39 AM, Stephen Colebourne wrote:

In DateTimeFormatter you need to qualify the @code part to 
refer to

DateTimeFormatterBuilder.

Otherwise good.

thanks

Stephen

On Thu, 27 Sep 2018 at 05:35, Pallavi Sonal 
  wrote:

Thanks for the clarification. Here is the updated webrev 
for review :

http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/ 


Thanks,

Pallavi Sonal

-Original Message-

From: Stephen Colebourne 


Sent: Tuesday, September 25, 2018 4:39 PM

To: core-libs-dev


Subject: Re: RFR: JDK-8166138 - 
DateTimeFormatter.ISO_INSTANT

should handle offsets

I think it makes sense for both, although I was only 
considering

appendInstant() when I wrote it.

Stephen

On Tue, 25 Sep 2018 at 09:27, Pallavi 
Sonal
  wrote:

Hi Stephen,

Is the addition to the documentation in your mail below 
meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT  as 
well ?

-Original Message-

From: Stephen Colebourne 


Sent: Sunday, September 23, 2018 12:36 PM

To: core-libs-dev


Subj

Re: RFR 8211295: DriverManager.getConnection fails when called from com.sun.rowset.JdbcRowSetImpl

[Mandy Chung]

On 9/29/18 1:59 PM, Lance Andersen wrote:

Attached is the webrev for the JDBC RowSet/DriverManager issue, 
https://bugs.openjdk.java.net/browse/JDK-8211295,  that was raised on the 
thread: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055755.html

I have run the JDBC TestSuite against the Derby Embedded and Derby Network 
server;  Mach 5 jdk tier1, tier2, and tier3 tests as well as the JCK java.sql 
and javax.sql tests.  All pass with the fix

The webrev can be found at http://cr.openjdk.java.net/~lancea/8211295/webrev.00/


The change looks okay.    DriverManager::drivers and a few other methods 
are caller-sensitive.  If they were called from java.sql.rowset, it 
won't work properly.   I believe no such code path and so it's okay.


We should try again to investigate removing @CallerSensitive from 
DriverManager in the future:

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

Mandy

RE: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

[Pallavi Sonal]

Thanks Roger, made the suggested changes.

 

Thanks,

Pallavi Sonal

 

From: Roger Riggs 
Sent: Monday, October 01, 2018 9:29 PM
To: Pallavi Sonal ; Naoto Sato 
; core-libs-dev 
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle 
offsets

 

Hi,

The checkbox for compatibility Kind Behavioral should be checked. (You may need 
to hit Edit to see it).
A simple description of the compatibility risk may help clarify minimal.
Something to the effect, that there is no change in formatting behavior
and that parsing will now accept a numeric offset.

Otherwise, looks fine.

Thanks, Roger

On 10/01/2018 09:24 AM, Pallavi Sonal wrote:

Hi Naoto,
Here is the CSR for review :
https://bugs.openjdk.java.net/browse/JDK-8211316 
 
Thanks,
Pallavi Sonal
 
-Original Message-
From: Naoto Sato 
Sent: Friday, September 28, 2018 9:38 PM
To: Pallavi Sonal HYPERLINK 
"mailto:pallavi.so...@oracle.com";; Roger Riggs 
HYPERLINK "mailto:roger.ri...@oracle.com";; 
core-libs-dev HYPERLINK 
"mailto:core-libs-dev@openjdk.java.net";
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle 
offsets
 
Hi Pallavi,
 
Please file a CSR for this, as this will change the behavior.
 
Naoto
 
On 9/28/18 8:53 AM, Pallavi Sonal wrote:

Thanks Roger. I will update it before the commit.
 
-Original Message-
From: Roger Riggs
Sent: Friday, September 28, 2018 6:15 PM
To: Pallavi Sonal HYPERLINK 
"mailto:pallavi.so...@oracle.com";; core-libs-dev 
HYPERLINK 
"mailto:core-libs-dev@openjdk.java.net";
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should 
handle offsets
 
Hi Pallavi,
 
Looks fine,
 
But can you re-wrap the lines with the new links, they got longer than
100 chars with the link.
 
No new webrev is needed.
 
Thanks, Roger
 
 
On 9/28/18 8:35 AM, Pallavi Sonal wrote:

Thanks Roger and Stephen. Here is the updated webrev with the suggested changes:
http://cr.openjdk.java.net/~rpatil/8166138/webrev.04/
 
Thanks,
Pallavi Sonal
 
-Original Message-
From: Roger Riggs
Sent: Friday, September 28, 2018 12:51 AM
To: core-libs-dev HYPERLINK 
"mailto:core-libs-dev@openjdk.java.net";
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should 
handle offsets
 
Hi Pallavi,
 
I'd suggest using @link for the reference (in both files).
It will be easier for the reader to traverse and understand the pattern.
 
DateTimeFormatterBuilder.java: line 836.
The trailing "" should be omitted so the readability of the source is 
maintained.
 
Otherwise, looks good,
 
Thanks, Roger
 
 
 
On 09/27/2018 03:39 AM, Stephen Colebourne wrote:

In DateTimeFormatter you need to qualify the @code part to refer to 
DateTimeFormatterBuilder.
Otherwise good.
thanks
Stephen
 
 
On Thu, 27 Sep 2018 at 05:35, Pallavi Sonal HYPERLINK 
"mailto:pallavi.so...@oracle.com"; wrote:

Thanks for the clarification. Here is the updated webrev for review :
http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/
 
Thanks,
Pallavi Sonal
 
-Original Message-
From: Stephen Colebourne HYPERLINK 
"mailto:scolebou...@joda.org";
Sent: Tuesday, September 25, 2018 4:39 PM
To: core-libs-dev HYPERLINK 
"mailto:core-libs-dev@openjdk.java.net";
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT 
should handle offsets
 
I think it makes sense for both, although I was only considering
appendInstant() when I wrote it.
Stephen
 
 
On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal HYPERLINK 
"mailto:pallavi.so...@oracle.com"; wrote:

Hi Stephen,
Is the addition to the documentation in your mail below meant for only 
appendInstant() method or for DateTimeFormatter.ISO_INSTANT  as well ?
 
-Original Message-
From: Stephen Colebourne HYPERLINK 
"mailto:scolebou...@joda.org";
Sent: Sunday, September 23, 2018 12:36 PM
To: core-libs-dev HYPERLINK 
"mailto:core-libs-dev@openjdk.java.net";
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT 
should handle offsets
 
Thanks
 
Can we change the docs to:
 

When formatting, the instant will always be suffixed by 'Z' to indicate UTC.
When parsing, the behaviour of {@code appendOffsetId()} will be used to parse 
the offset, converting the instant to UTC as necessary.
 
thanks
Stephen
 
 
On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal HYPERLINK 
"mailto:pallavi.so...@oracle.com"; wrote:

Thank you Stephen for your inputs. Based on that, here is the updated webrev 
for review :
 http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/
 
Thanks,
Pallavi Sonal.
 
-Original Message-
From: Stephen Colebourne HYPERLINK 
"mailto:scolebou...@joda.org";
Sent: Thursday, September 20, 2018 6:38 PM
To: core-libs-dev HYPERLINK 
"mailto:core-libs-dev@openjdk.java.net";
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT 
should handle offsets
 
Thanks for the update.
 
The test case does not cover the situation of MAX/MIN instant and an offset 
other than zero, where the offset makes the instant invalid.
eg. a negative offset at MAX or a positive offset at MI

Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

[Roger Riggs]

Hi,

The checkbox for compatibility Kind Behavioral should be checked. (You 
may need to hit Edit to see it).

A simple description of the compatibility risk may help clarify minimal.
Something to the effect, that there is no change in formatting behavior
and that parsing will now accept a numeric offset.

Otherwise, looks fine.

Thanks, Roger

On 10/01/2018 09:24 AM, Pallavi Sonal wrote:

Hi Naoto,
Here is the CSR for review :
https://bugs.openjdk.java.net/browse/JDK-8211316

Thanks,
Pallavi Sonal

-Original Message-
From: Naoto Sato
Sent: Friday, September 28, 2018 9:38 PM
To: Pallavi Sonal ; Roger Riggs ; 
core-libs-dev 
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle 
offsets

Hi Pallavi,

Please file a CSR for this, as this will change the behavior.

Naoto

On 9/28/18 8:53 AM, Pallavi Sonal wrote:

Thanks Roger. I will update it before the commit.

-Original Message-
From: Roger Riggs
Sent: Friday, September 28, 2018 6:15 PM
To: Pallavi Sonal ; core-libs-dev

Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should
handle offsets

Hi Pallavi,

Looks fine,

But can you re-wrap the lines with the new links, they got longer than
100 chars with the link.

No new webrev is needed.

Thanks, Roger


On 9/28/18 8:35 AM, Pallavi Sonal wrote:

Thanks Roger and Stephen. Here is the updated webrev with the suggested changes:
http://cr.openjdk.java.net/~rpatil/8166138/webrev.04/

Thanks,
Pallavi Sonal

-Original Message-
From: Roger Riggs
Sent: Friday, September 28, 2018 12:51 AM
To: core-libs-dev 
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should
handle offsets

Hi Pallavi,

I'd suggest using @link for the reference (in both files).
It will be easier for the reader to traverse and understand the pattern.

DateTimeFormatterBuilder.java: line 836.
The trailing "" should be omitted so the readability of the source is 
maintained.

Otherwise, looks good,

Thanks, Roger



On 09/27/2018 03:39 AM, Stephen Colebourne wrote:

In DateTimeFormatter you need to qualify the @code part to refer to
DateTimeFormatterBuilder.
Otherwise good.
thanks
Stephen


On Thu, 27 Sep 2018 at 05:35, Pallavi Sonal  wrote:

Thanks for the clarification. Here is the updated webrev for review :
http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/

Thanks,
Pallavi Sonal

-Original Message-
From: Stephen Colebourne 
Sent: Tuesday, September 25, 2018 4:39 PM
To: core-libs-dev 
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT
should handle offsets

I think it makes sense for both, although I was only considering
appendInstant() when I wrote it.
Stephen


On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal  wrote:

Hi Stephen,
Is the addition to the documentation in your mail below meant for only 
appendInstant() method or for DateTimeFormatter.ISO_INSTANT  as well ?

-Original Message-
From: Stephen Colebourne 
Sent: Sunday, September 23, 2018 12:36 PM
To: core-libs-dev 
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT
should handle offsets

Thanks

Can we change the docs to:


When formatting, the instant will always be suffixed by 'Z' to indicate UTC.
When parsing, the behaviour of {@code appendOffsetId()} will be used to parse 
the offset, converting the instant to UTC as necessary.

thanks
Stephen


On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal  wrote:

Thank you Stephen for your inputs. Based on that, here is the updated webrev 
for review :
  http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/

Thanks,
Pallavi Sonal.

-Original Message-
From: Stephen Colebourne 
Sent: Thursday, September 20, 2018 6:38 PM
To: core-libs-dev 
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT
should handle offsets

Thanks for the update.

The test case does not cover the situation of MAX/MIN instant and an offset 
other than zero, where the offset makes the instant invalid.
eg. a negative offset at MAX or a positive offset at MIN.

The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to 
cover the fact that any OffsetId is parsed.

thanks
Stephen


On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal  wrote:

Thanks Roger , Naoto and Stephen for the review and valuable inputs.
Here is the updated webrev for review :
http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/

Thanks,
Pallavi Sonal

-Original Message-
From: Stephen Colebourne 
Sent: Thursday, September 20, 2018 2:50 AM
To: core-libs-dev 
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT
should handle offsets

Thanks for looking at this.

The proposed fix does not tackle the bug fully. The bug is that
the spec says

"The format consists of: The ISO_OFFSET_DATE_TIME where ..."

As such, the format must parse *any* offset, not just "Z" / "+00:00" etc.

In addition, the fix doesn't work properly. Parsers work off a CharSequence 
which may be much longer than the instant. For example, the instant might be 
followed by a literal space a

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

[Francesco Nigro]

Hi guys!

I'm one of the mentioned devs (like many others) that are using external
(and unsafe) APIs to concurrent access ByteBuffer's content and a developer
of a messaging broker's journal
that would benefit by this JEP :)
Re concurrent access API, how it looks
https://github.com/real-logic/agrona/blob/master/agrona/src/main/java/org/agrona/concurrent/AtomicBuffer.java
?

note:
I don't know how's considered to appear in these discussions without
presenting myself and I hope to not be OT, but both this JEP and the
comments around are so interesting
that I couldn't resist: I apologize if I'm not respecting some rule on it

Thanks for the hard work,
Francesco

Il giorno ven 28 set 2018 alle ore 09:21 Peter Levart <
peter.lev...@gmail.com> ha scritto:

> Hi Stuart,
>
> I mostly agree with your assessment about the suitability of the
> ByteBuffer API for nice multithreaded use. What would such API look like? I
> think pretty much like ByteBuffer but without things that mutate
> mark/position/limit/ByteOrder. A stripped-down ByteBuffer API therefore.
> That would be in my opinion the most low-level API possible. If you add
> things to such API that coordinate multithreaded access to the underlying
> memory, you are already creating a concurrent data structure for a
> particular set of use cases, which might not cover all possible use cases
> or be sub-optimal at some of them. So I think this is better layered on top
> of such API not built into it. Low-level multithreaded access to memory is,
> in my opinion, always going to be "unsafe" from the standpoint of
> coordination. It's not only the mark/position/limit/ByteOrder that is not
> multithreaded-friendly about ByteBuffer API, but the underlying memory too.
> It would be nice if mark/position/limit/ByteOrder weren't in the way though.
>
> Regards, Peter
>
>
> On 09/28/2018 07:51 AM, Stuart Marks wrote:
>
> Hi Andrew,
>
> Let me first stay that this issue of "ByteBuffer might not be the right
> answer" is something of a digression from the JEP discussion. I think the
> JEP should proceed forward using MBB with the API that you and Alan had
> discussed previously. At most, the discussion of the "right thing" issue
> might affect a side note in the JEP text about possible limitations and
> future directions of this effort. However, it's not a blocker to the JEP
> making progress as far as I'm concerned.
>
> With that in mind, I'll discuss the issue of multithreaded access to
> ByteBuffers and how this bears on whether buffers are or aren't the "right
> answer." There are actually several issues that figure into the "right
> answer" analysis. In this message, though, I'll just focus on the issue of
> multithreaded access.
>
> To recap (possibly for the benefit of other readers) the Buffer class doc
> has the following statement:
>
> Buffers are not safe for use by multiple concurrent threads. If a
> buffer
> is to be used by more than one thread then access to the buffer should
> be
> controlled by appropriate synchronization.
>
> Buffers are primarily designed for sequential operations such as I/O or
> codeset conversion. Typical buffer operations set the mark, position, and
> limit before initiating the operation. If the operation completes partially
> -- not uncommon with I/O or codeset conversion -- the position is updated
> so that the operation can be resumed easily from where it left off.
>
> The fact that buffers not only contain the data being operated upon but
> also mutable state information such as mark/position/limit makes it
> difficult to have multiple threads operate on different parts of the same
> buffer. Each thread would have to lock around setting the position and
> limit and performing the operation, preventing any parallelism. The typical
> way to deal with this is to create multiple buffer slices, one per thread.
> Each slice has its own mark/position/limit values but shares the same
> backing data.
>
> We can avoid the need for this by adding absolute bulk operations, right?
>
> Let's suppose we were to add something like this (considering ByteBuffer
> only, setting the buffer views aside):
>
> get(int srcOff, byte[] dst, int dstOff, int length)
> put(int dstOff, byte[] src, int srcOff, int length)
>
> Each thread can perform its operations on a different part of the buffer,
> in parallel, without interference from the others. Presumably these
> operations don't read or write the mark and position. Oh, wait. The
> existing absolute put and get overloads *do* respect the buffer's limit, so
> the absolute bulk operations ought to as well. This means they do depend on
> shared state. (I guess we could make the absolute bulk ops not respect the
> limit, but that seems inconsistent.)
>
> OK, let's adopt an approach similar to what was described by Peter Levart
> a couple messages upthread, where a) there is an initialization step where
> various things including the limit are set properly; b) the buffer is
> published to 

RE: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

[Pallavi Sonal]

Hi Naoto,
Here is the CSR for review :
https://bugs.openjdk.java.net/browse/JDK-8211316 

Thanks,
Pallavi Sonal

-Original Message-
From: Naoto Sato 
Sent: Friday, September 28, 2018 9:38 PM
To: Pallavi Sonal ; Roger Riggs 
; core-libs-dev 
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle 
offsets

Hi Pallavi,

Please file a CSR for this, as this will change the behavior.

Naoto

On 9/28/18 8:53 AM, Pallavi Sonal wrote:
> Thanks Roger. I will update it before the commit.
> 
> -Original Message-
> From: Roger Riggs
> Sent: Friday, September 28, 2018 6:15 PM
> To: Pallavi Sonal ; core-libs-dev 
> 
> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should 
> handle offsets
> 
> Hi Pallavi,
> 
> Looks fine,
> 
> But can you re-wrap the lines with the new links, they got longer than
> 100 chars with the link.
> 
> No new webrev is needed.
> 
> Thanks, Roger
> 
> 
> On 9/28/18 8:35 AM, Pallavi Sonal wrote:
>> Thanks Roger and Stephen. Here is the updated webrev with the suggested 
>> changes:
>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.04/
>>
>> Thanks,
>> Pallavi Sonal
>>
>> -Original Message-
>> From: Roger Riggs
>> Sent: Friday, September 28, 2018 12:51 AM
>> To: core-libs-dev 
>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should 
>> handle offsets
>>
>> Hi Pallavi,
>>
>> I'd suggest using @link for the reference (in both files).
>> It will be easier for the reader to traverse and understand the pattern.
>>
>> DateTimeFormatterBuilder.java: line 836.
>> The trailing "" should be omitted so the readability of the source is 
>> maintained.
>>
>> Otherwise, looks good,
>>
>> Thanks, Roger
>>
>>
>>
>> On 09/27/2018 03:39 AM, Stephen Colebourne wrote:
>>> In DateTimeFormatter you need to qualify the @code part to refer to 
>>> DateTimeFormatterBuilder.
>>> Otherwise good.
>>> thanks
>>> Stephen
>>>
>>>
>>> On Thu, 27 Sep 2018 at 05:35, Pallavi Sonal  
>>> wrote:
 Thanks for the clarification. Here is the updated webrev for review :
 http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/

 Thanks,
 Pallavi Sonal

 -Original Message-
 From: Stephen Colebourne 
 Sent: Tuesday, September 25, 2018 4:39 PM
 To: core-libs-dev 
 Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT 
 should handle offsets

 I think it makes sense for both, although I was only considering
 appendInstant() when I wrote it.
 Stephen


 On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal  
 wrote:
> Hi Stephen,
> Is the addition to the documentation in your mail below meant for only 
> appendInstant() method or for DateTimeFormatter.ISO_INSTANT  as well ?
>
> -Original Message-
> From: Stephen Colebourne 
> Sent: Sunday, September 23, 2018 12:36 PM
> To: core-libs-dev 
> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT 
> should handle offsets
>
> Thanks
>
> Can we change the docs to:
>
> 
> When formatting, the instant will always be suffixed by 'Z' to indicate 
> UTC.
> When parsing, the behaviour of {@code appendOffsetId()} will be used to 
> parse the offset, converting the instant to UTC as necessary.
>
> thanks
> Stephen
>
>
> On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal  
> wrote:
>> Thank you Stephen for your inputs. Based on that, here is the updated 
>> webrev for review :
>>  http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/
>>
>> Thanks,
>> Pallavi Sonal.
>>
>> -Original Message-
>> From: Stephen Colebourne 
>> Sent: Thursday, September 20, 2018 6:38 PM
>> To: core-libs-dev 
>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT 
>> should handle offsets
>>
>> Thanks for the update.
>>
>> The test case does not cover the situation of MAX/MIN instant and an 
>> offset other than zero, where the offset makes the instant invalid.
>> eg. a negative offset at MAX or a positive offset at MIN.
>>
>> The doc of appendInstant() in DateTimeFormatterBuilder should be 
>> clarified to cover the fact that any OffsetId is parsed.
>>
>> thanks
>> Stephen
>>
>>
>> On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal  
>> wrote:
>>> Thanks Roger , Naoto and Stephen for the review and valuable inputs.
>>> Here is the updated webrev for review :
>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/
>>>
>>> Thanks,
>>> Pallavi Sonal
>>>
>>> -Original Message-
>>> From: Stephen Colebourne 
>>> Sent: Thursday, September 20, 2018 2:50 AM
>>> To: core-libs-dev 
>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT 
>>> should handle offsets
>>>
>>> Thanks for looking at this.
>>>
>>> The proposed fix does not tackle the bug fully. T

Re: How can I solve Modularity related issue ?

[Lance Andersen]

I will be pushing the fix back later today

Best
Lance
> On Oct 1, 2018, at 3:56 AM, Ichiroh Takiguchi  
> wrote:
> 
> Hello Alan and Mandy.
> 
> I appreciate your explanation and action.
> 
> Also I read Lance's mail.
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055780.html
> 
> I verified Lance's patch, it worked...
> 
> Many thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> On 2018-09-29 09:35, Mandy Chung wrote:
>> On 9/28/18 1:59 AM, Alan Bateman wrote:
>>> On 28/09/2018 08:28, Ichiroh Takiguchi wrote:
 Hello.
 One of JDBC application with JavaDB did not work on JDK12.
 Following exception happened:
   java.sql.SQLException: No suitable driver found for jdbc:derby:xx
 I assume, this issue related Modularity feature...
 I could not solve this issue by myself.
>>> I suspect this is related to the de-privileging of the java.sql.rowset 
>>> module in JDK 9. The java.sql.rowset module is mapped to the platform class 
>>> loader whereas historically the types in this module were defined by the 
>>> boot class loader. This is relevant because java.sql.rowset is making use 
>>> of the java.sql.DriverManager (in the java.sql module) and DriverManager is 
>>> caller sensitive so it sees the caller coming from java.sql.rowset. This is 
>>> problematic because the JDBC driver is on the class path and is not visible 
>>> to the caller's class loader. The visibility check has always been in JDBC 
>>> and I suspect this usage in the JDBC Rowset implementation only worked by 
>>> accident in the past because DriverManager used the TCCL when called from 
>>> code defined to the bootstrap class loader. I'm sure Lance will jump in but 
>>> all previous investigations into changing behavior going back 20+ has come 
>>> to nothing due to compatibility concerns.
>> It does look like related to the de-privileging of java.sql.rowset
>> module.  JDBC rowset implementation just happened to work in the past
>> as it was defined to the bootstrap class loader.
>> I have created JBS issue for this:
>>https://bugs.openjdk.java.net/browse/JDK-8211295
>> Mandy
> 

 
  

 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: How can I solve Modularity related issue ?

[Ichiroh Takiguchi]

Hello Alan and Mandy.

I appreciate your explanation and action.

Also I read Lance's mail.
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055780.html

I verified Lance's patch, it worked...

Many thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2018-09-29 09:35, Mandy Chung wrote:

On 9/28/18 1:59 AM, Alan Bateman wrote:

On 28/09/2018 08:28, Ichiroh Takiguchi wrote:

Hello.

One of JDBC application with JavaDB did not work on JDK12.
Following exception happened:
  java.sql.SQLException: No suitable driver found for 
jdbc:derby:xx


I assume, this issue related Modularity feature...
I could not solve this issue by myself.
I suspect this is related to the de-privileging of the java.sql.rowset 
module in JDK 9. The java.sql.rowset module is mapped to the platform 
class loader whereas historically the types in this module were 
defined by the boot class loader. This is relevant because 
java.sql.rowset is making use of the java.sql.DriverManager (in the 
java.sql module) and DriverManager is caller sensitive so it sees the 
caller coming from java.sql.rowset. This is problematic because the 
JDBC driver is on the class path and is not visible to the caller's 
class loader. The visibility check has always been in JDBC and I 
suspect this usage in the JDBC Rowset implementation only worked by 
accident in the past because DriverManager used the TCCL when called 
from code defined to the bootstrap class loader. I'm sure Lance will 
jump in but all previous investigations into changing behavior going 
back 20+ has come to nothing due to compatibility concerns.




It does look like related to the de-privileging of java.sql.rowset
module.  JDBC rowset implementation just happened to work in the past
as it was defined to the bootstrap class loader.

I have created JBS issue for this:
   https://bugs.openjdk.java.net/browse/JDK-8211295

Mandy