Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

[Kim Barrett]

> On Mar 3, 2020, at 4:49 PM, Alexey Semenyuk  
> wrote:
> 
> How about C++11? I have a pending patch for jpackage that depends on C++11 
> features that I hesitate to pull in jdk15.

The reasons for HotSpot (at least) not already being on C++14 (cost of
switching over the Solaris Studio based platform) also apply to C++11.
A big part of the work involves dealing with changes to the compilation
model, the runtime libraries, and the ABI, all of which are part of
Solaris Studio's transition from C++98 to C++11.

Re: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity

[Stephen Colebourne]

I fear more changes are needed here.

1) The code is isFixedOffset() is indeed wrong, but the fix is
insufficient. The zone is fixed if baseStandardOffset=baseWallOffset
and all three other lists are empty. A fixed offset rule is the
equivalent of a ZoneOffset. See ZoneId.normalized() for the code that
assumes that.

2) The code in getOffset(Instant) is wrong, but so is the proposed
fix. The purpose of the if statement is to optimise the following few
lines which refer to savingsInstantTransitions and wallOffsets. The
code does have a bug as it should return the first wall offset.
Corrected code:
  public ZoneOffset getOffset(Instant instant) {
if (savingsInstantTransitions.length == 0) {
  return wallOffsets[0];
}
With the correct definition of isFixedOffset() it becomes apparent
that this if statement is in fact not related to the fixed offset.

Currently this test case fails (a zone in DST for all eternity):
ZoneRules rules = ZoneRules.of(
ZoneOffset.ofHours(1),
ZoneOffset.ofHours(2),
Collections.emptyList(),
Collections.emptyList(),
Collections.emptyList());
assertEquals(rules.getStandardOffset(Instant.EPOCH),
ZoneOffset.ofHours(1));
assertEquals(rules.getOffset(Instant.EPOCH),  ZoneOffset.ofHours(2));

3) The code in getStandardOffset(Instant) also has an error as it
checks the wrong array. It should check standardTransitions as that is
what is used in the following few lines. Corrected code:
  public ZoneOffset getStandardOffset(Instant instant) {
if (standardTransitions.length == 0) {
  return standardOffsets[0];
}

4) The code in getOffsetInfo(LocalDateTime dt) has a similar fault.
Since it protects savingsLocalTransitions, it should return
wallOffsets[0].

5) The code in getDaylightSavings(Instant instant) has an optimising
if statement that should refer to isFixedOffset().

6) Also, in the test.
 assertTrue(!rules.isFixedOffset());
should be
 assertFalse(rules.isFixedOffset());

The class has worked so far as every normal case has
baseStandardOffset = baseWallOffset, even though it is conceptually
valid for this not to be true.

Stephen




On Thu, 27 Feb 2020 at 20:42,  wrote:
>
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8239836
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8239836/webrev.00/
>
> It turned out that 'transitionList' is not necessarily a superset of
> 'standardOffsetTransitionList', as in some occasions where a standard
> offset change and a savings change happen at the same time (canceling
> each other), resulting in no wall time transition. This means that the
> "rules" in the sample code is a valid ZoneRules instance.
>
> However, there is an assumption in ZoneRules where no (wall time)
> transition means the fixed offset zone. With that assumption, the
> example rule is considered a fixed offset zone which is not correct. So
> the fix proposed here is not to throw an IAE but to recognize the rule
> as a valid, non-fixed offset ZoneRules instance.
>
> Naoto
>
>

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

[Alexey Semenyuk]

How about C++11? I have a pending patch for jpackage that depends on 
C++11 features that I hesitate to pull in jdk15.


- Alexey

On 3/3/2020 5:22 AM, Volker Simonis wrote:

On Tue, Mar 3, 2020 at 10:26 AM Andrew Haley  wrote:

On 3/2/20 10:46 PM, Volker Simonis wrote:


As lead of the 8 and 11 update projects you probably know best, if this fix
will eventually be considered for backporting and choose your means wisely
:)

Yeah, I know. Srsly. :-)

But one of the few things of which I am certain is that we must not
allow the needs of backporting to determine the future of Java. That's
the way of staying in the past.

As Patrick Head put it, “Some people tell me that Formula 1 would be
better if the drivers still used stick shifts, but that’s a bit like
saying, 'isn’t it a pity we don’t still walk around in clogs!'”


Totally agree.


--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing

[Alan Bateman]

On 03/03/2020 18:01, Volker Simonis wrote:

:
Thanks. Shortened the comments as suggested:

http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333.01/

OK, now?


Thanks, looks good to me.

-Alan

Re: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity

[Joe Wang]

Looks good to me.

Thanks,
Joe

On 3/3/20 10:15 AM, naoto.s...@oracle.com wrote:

Thanks, Joe. Updated:

http://cr.openjdk.java.net/~naoto/8239836/webrev.02/

Naoto

On 3/3/20 8:59 AM, Joe Wang wrote:


On 3/3/20 8:27 AM, naoto.s...@oracle.com wrote:

Hi Joe, thanks for the review.

Are you suggesting something like

isFixedOffset() {
    return isFixedOffset;
}


Yes, something like that. It could be initiated while the rules is 
constructed. I feel it might be semantically clearer as transitions 
indirectly reflect that the offset is fixed. Your call.


Best,
Joe



Naoto

On 3/2/20 11:20 PM, Joe Wang wrote:

Hi Naoto,

The fix would be fine if you want to keep it as is since it does work.

I noticed though that for standard zones (the ones loaded from tz 
database), savingsInstantTransitions and standardTransitions are 
consistent in that they are both empty for the standard zones, e.g. 
Etc/GMT, and not empty for zones with a country/city id, including 
countries that don't actually observe DST. This means a check for 
one of them is enough for standard zones, which was done in the 
current implementation (that is, isFixedOffset() returns 
savingsInstantTransitions.length == 0). For custom ZoneRules 
created with the "of" method, it would depend on whether they are 
set through the relevant parameters (in the test case, the later 
was set but the former was empty, that was why isFixedOffset was 
true). It would therefore be possible to add and use a transient 
boolean field to represent isFixedOffset.


Just my two cents.

-Joe

On 3/2/20 10:37 AM, Roger Riggs wrote:

Looks good.

Give it a day to see if anyone else has comments.

Thanks, Roger

On 3/2/20 1:35 PM, naoto.s...@oracle.com wrote:

Hi Roger, thanks for the review.

On 3/2/20 8:44 AM, Roger Riggs wrote:

Hi Naoto,

look ok.

ZoneRules.java: 488, 644, 761, 791
I'd suggest calling isFixedOffset() instead of repeating the code:
standardTransitions.length == 0 && 
savingsInstantTransitions.length == 0


Modified as suggested:

http://cr.openjdk.java.net/~naoto/8239836/webrev.01/



It should be inlined in cases where the performance matters.


None of those locations is invoked during ZoneRules object 
instantiation. So I believe it is OK to replace them with 
isFixedOffset().


Naoto



Thanks, Roger


On 2/27/20 3:41 PM, naoto.s...@oracle.com wrote:

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8239836/webrev.00/

It turned out that 'transitionList' is not necessarily a 
superset of
'standardOffsetTransitionList', as in some occasions where a 
standard offset change and a savings change happen at the same 
time (canceling each other), resulting in no wall time 
transition. This means that the "rules" in the sample code is a 
valid ZoneRules instance.


However, there is an assumption in ZoneRules where no (wall 
time) transition means the fixed offset zone. With that 
assumption, the example rule is considered a fixed offset zone 
which is not correct. So the fix proposed here is not to throw 
an IAE but to recognize the rule as a valid, non-fixed offset 
ZoneRules instance.


Naoto

Re: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity

[naoto . sato]

Thanks, Joe. Updated:

http://cr.openjdk.java.net/~naoto/8239836/webrev.02/

Naoto

On 3/3/20 8:59 AM, Joe Wang wrote:


On 3/3/20 8:27 AM, naoto.s...@oracle.com wrote:

Hi Joe, thanks for the review.

Are you suggesting something like

isFixedOffset() {
    return isFixedOffset;
}


Yes, something like that. It could be initiated while the rules is 
constructed. I feel it might be semantically clearer as transitions 
indirectly reflect that the offset is fixed. Your call.


Best,
Joe



Naoto

On 3/2/20 11:20 PM, Joe Wang wrote:

Hi Naoto,

The fix would be fine if you want to keep it as is since it does work.

I noticed though that for standard zones (the ones loaded from tz 
database), savingsInstantTransitions and standardTransitions are 
consistent in that they are both empty for the standard zones, e.g. 
Etc/GMT, and not empty for zones with a country/city id, including 
countries that don't actually observe DST. This means a check for one 
of them is enough for standard zones, which was done in the current 
implementation (that is, isFixedOffset() returns 
savingsInstantTransitions.length == 0). For custom ZoneRules created 
with the "of" method, it would depend on whether they are set through 
the relevant parameters (in the test case, the later was set but the 
former was empty, that was why isFixedOffset was true). It would 
therefore be possible to add and use a transient boolean field to 
represent isFixedOffset.


Just my two cents.

-Joe

On 3/2/20 10:37 AM, Roger Riggs wrote:

Looks good.

Give it a day to see if anyone else has comments.

Thanks, Roger

On 3/2/20 1:35 PM, naoto.s...@oracle.com wrote:

Hi Roger, thanks for the review.

On 3/2/20 8:44 AM, Roger Riggs wrote:

Hi Naoto,

look ok.

ZoneRules.java: 488, 644, 761, 791
I'd suggest calling isFixedOffset() instead of repeating the code:
standardTransitions.length == 0 && 
savingsInstantTransitions.length == 0


Modified as suggested:

http://cr.openjdk.java.net/~naoto/8239836/webrev.01/



It should be inlined in cases where the performance matters.


None of those locations is invoked during ZoneRules object 
instantiation. So I believe it is OK to replace them with 
isFixedOffset().


Naoto



Thanks, Roger


On 2/27/20 3:41 PM, naoto.s...@oracle.com wrote:

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8239836/webrev.00/

It turned out that 'transitionList' is not necessarily a superset of
'standardOffsetTransitionList', as in some occasions where a 
standard offset change and a savings change happen at the same 
time (canceling each other), resulting in no wall time 
transition. This means that the "rules" in the sample code is a 
valid ZoneRules instance.


However, there is an assumption in ZoneRules where no (wall time) 
transition means the fixed offset zone. With that assumption, the 
example rule is considered a fixed offset zone which is not 
correct. So the fix proposed here is not to throw an IAE but to 
recognize the rule as a valid, non-fixed offset ZoneRules instance.


Naoto

Re: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing

[Lance Andersen]

Looks good to me Thank you Volker

> On Mar 3, 2020, at 1:03 PM, Volker Simonis  wrote:
> 
> Thanks Lance.
> 
> I've just sent out an updated webrev with the shortened comments:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333.01/ 
> 
> 
> 
> On Tue, Mar 3, 2020 at 7:00 PM Lance Andersen  > wrote:
>> 
>> I think this all looks OK.  I would consider the same comment clean-up in 
>> JmodTask.java as well
>> 
>> Best
>> Lance
>> 
>> On Mar 3, 2020, at 11:27 AM, Alan Bateman  wrote:
>> 
>> On 03/03/2020 11:01, Volker Simonis wrote:
>> 
>> Hi,
>> 
>> can I please get a review for the following small fix:
>> 
>> http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/
>> https://bugs.openjdk.java.net/browse/JDK-8240333
>> 
>> 
>> The code changes okay but I think the comment needs a bit of clean-up. Maybe 
>> drop L96-97 so that it just says that it preserves the attributes that don't 
>> change.
>> 
>> -Alan.
>> 
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> lance.ander...@oracle.com 
 
  

 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: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing

[Volker Simonis]

Thanks Lance.

I've just sent out an updated webrev with the shortened comments:

http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333.01/


On Tue, Mar 3, 2020 at 7:00 PM Lance Andersen  wrote:
>
> I think this all looks OK.  I would consider the same comment clean-up in 
> JmodTask.java as well
>
> Best
> Lance
>
> On Mar 3, 2020, at 11:27 AM, Alan Bateman  wrote:
>
> On 03/03/2020 11:01, Volker Simonis wrote:
>
> Hi,
>
> can I please get a review for the following small fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/
> https://bugs.openjdk.java.net/browse/JDK-8240333
>
>
> The code changes okay but I think the comment needs a bit of clean-up. Maybe 
> drop L96-97 so that it just says that it preserves the attributes that don't 
> change.
>
> -Alan.
>
>
>
> 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: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing

[Volker Simonis]

On Tue, Mar 3, 2020 at 5:27 PM Alan Bateman  wrote:
>
> On 03/03/2020 11:01, Volker Simonis wrote:
> > Hi,
> >
> > can I please get a review for the following small fix:
> >
> > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/
> > https://bugs.openjdk.java.net/browse/JDK-8240333
> >
> >
> The code changes okay but I think the comment needs a bit of clean-up.
> Maybe drop L96-97 so that it just says that it preserves the attributes
> that don't change.
>

Thanks. Shortened the comments as suggested:

http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333.01/

OK, now?

> -Alan.

Re: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing

[Volker Simonis]

On Tue, Mar 3, 2020 at 5:20 PM Martin Buchholz  wrote:
>
> Looks Good To Me ... except you should fix that "delfated" typo.
>

Thanks. Corrected the typo along with some comment shortening suggested by Alan:

http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333.01/

> Those looking for a zip implementation career path

:-))

> can try to fix up all the compressedSize in the local headers so that they 
> are correctly filled in.  Which is hard because you don't know the 
> compressedSize when you are writing the local entry header with putNextEntry.
>

You can't know it be fore you are doing it :)

> On Tue, Mar 3, 2020 at 3:02 AM Volker Simonis  
> wrote:
>>
>> Hi,
>>
>> can I please get a review for the following small fix:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/
>> https://bugs.openjdk.java.net/browse/JDK-8240333
>>
>> The "jmod" tool needs to update .jar files as well as .jmod files when
>> adding hashes to the module-info file. This is handled in the method
>> jdk.tools.jmod.JmodTask.updateModularJar() for modular jar files and
>> in the methods jdk.tools.jmod.JmodTask.updateJmodFile() and
>> jdk.tools.jmod.JmodOutputStream.writeEntry() for .jmod files.
>>
>> Unfortunately, both implementations are incorrect because they are
>> writing the JarEntry/ZipEntry entries which they reading from the
>> ZipInputStream verbatim to the ZipOutputStream. This approach is not
>> correct, because Zip/Entry/JarEntry contains both, the compressed and
>> uncompressed size of the corresponding entry. But the original
>> Deflater which initially compressed that entry can be either different
>> from the current one or it might have used a different compression
>> level compared to the current Deflater which re-deflates the entry
>> data.
>>
>> When the newly created entry is closed, the new compressed size will
>> be checked against the original compressed size if that was recorded
>> in the ZipEntry/JarEntry entry and an exception will be thrown, when
>> they differ. For modular jar files it looks as follows:
>>
>> $ jmod hash --module-path . --hash-modules .*
>> Error: java.util.zip.ZipException: invalid entry compressed size
>> (expected 58 but got 57 bytes)
>> java.io.UncheckedIOException: java.util.zip.ZipException: invalid
>> entry compressed size (expected 58 but got 57 bytes)
>> at 
>> jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateModularJar$3(JmodTask.java:995)
>> at 
>> java.base/java.util.zip.ZipFile$EntrySpliterator.tryAdvance(ZipFile.java:571)
>> at java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:326)
>> at 
>> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
>> at 
>> jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModularJar(JmodTask.java:980)
>> at 
>> jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModuleInfo(JmodTask.java:957)
>> at jdk.jlink/jdk.tools.jmod.JmodTask.lambda$hashModules$3(JmodTask.java:300)
>> at java.base/java.util.HashMap.forEach(HashMap.java:1425)
>> at jdk.jlink/jdk.tools.jmod.JmodTask.hashModules(JmodTask.java:291)
>> at jdk.jlink/jdk.tools.jmod.JmodTask.run(JmodTask.java:220)
>> at jdk.jlink/jdk.tools.jmod.Main.main(Main.java:34)
>> Suppressed: java.util.zip.ZipException: invalid entry compressed size
>> (expected 58 but got 57 bytes)
>> at 
>> java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267)
>> at java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360)
>> at 
>> java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:237)
>> at java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377)
>> at 
>> jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModularJar(JmodTask.java:976)
>> ... 6 more
>> Caused by: java.util.zip.ZipException: invalid entry compressed size
>> (expected 58 but got 57 bytes)
>> at 
>> java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267)
>> at 
>> jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateModularJar$3(JmodTask.java:992)
>> ... 10 more
>>
>> For jmod files it looks like this:
>>
>> $ jmod hash --module-path . --hash-modules .*
>> Error: java.util.zip.ZipException: invalid entry compressed size
>> (expected 383 but got 377 bytes)
>> java.io.UncheckedIOException: java.util.zip.ZipException: invalid
>> entry compressed size (expected 383 but got 377 bytes)
>> at 
>> jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateJmodFile$4(JmodTask.java:1021)
>> at 
>> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>> at 
>> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>> at 
>> java.base/java.util.zip.ZipFile$EntrySpliterator.tryAdvance(ZipFile.java:571)
>> at java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:326)
>> at 
>> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>> at 
>> 

Re: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing

[Lance Andersen]

I think this all looks OK.  I would consider the same comment clean-up in 
JmodTask.java as well

Best
Lance

> On Mar 3, 2020, at 11:27 AM, Alan Bateman  wrote:
> 
> On 03/03/2020 11:01, Volker Simonis wrote:
>> Hi,
>> 
>> can I please get a review for the following small fix:
>> 
>> http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/
>> https://bugs.openjdk.java.net/browse/JDK-8240333
>> 
>> 
> The code changes okay but I think the comment needs a bit of clean-up. Maybe 
> drop L96-97 so that it just says that it preserves the attributes that don't 
> change.
> 
> -Alan.

 
  

 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: RFR: JDK-8237966,: Creating runtime pkg requires --mac-package-identifier

[Alexander Zuev]

Looks fine to me.

/Alex

On 2/26/20 20:48, Andy Herrick wrote:

Please review the fix to issue [1] at [2].

The initial concern with defaulting to the application or installer 
name was that is might not be a valid mac package identifier (use only 
alphanumeric, '.' , and '-' chars)  but this can be true when the id 
is derived from main class (as in application case) or explicitly 
specified (using --mac-package-identifier).  So this change now tests 
it in any case.


[1] https://bugs.openjdk.java.net/browse/JDK-8237966

[2] http://cr.openjdk.java.net/~herrick/8237966/webrev.01/

/Andy

Re: RFR: JDK-8238692: MacOS runtime Installer issue

[Alexander Zuev]

Last version looks fine to me.

/Alex

On 2/21/20 20:10, Andy Herrick wrote:
After internal discussion of default values for mac-package-identifier 
I have removed the fix for [3] from this main fix to issue [2].


please review the revised webrev at [1]

/Andy

On 2/18/2020 2:46 PM, Andy Herrick wrote:


Please review the jpackage fix at [1] for the related issues [2], 
[3], and [4].


This will basically make pkg type runtime installers work on macosx, 
while we wait for JDK-8237971 to either fix or disable dmg type 
runtime installers.


/Andy

[1] http://cr.openjdk.java.net/~herrick/8238692/webrev.02/

[2] https://bugs.openjdk.java.net/browse/JDK-8238692

[3] https://bugs.openjdk.java.net/browse/JDK-8237966

[4] https://bugs.openjdk.java.net/browse/JDK-8237970

Re: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity

[Joe Wang]

On 3/3/20 8:27 AM, naoto.s...@oracle.com wrote:

Hi Joe, thanks for the review.

Are you suggesting something like

isFixedOffset() {
    return isFixedOffset;
}


Yes, something like that. It could be initiated while the rules is 
constructed. I feel it might be semantically clearer as transitions 
indirectly reflect that the offset is fixed. Your call.


Best,
Joe



Naoto

On 3/2/20 11:20 PM, Joe Wang wrote:

Hi Naoto,

The fix would be fine if you want to keep it as is since it does work.

I noticed though that for standard zones (the ones loaded from tz 
database), savingsInstantTransitions and standardTransitions are 
consistent in that they are both empty for the standard zones, e.g. 
Etc/GMT, and not empty for zones with a country/city id, including 
countries that don't actually observe DST. This means a check for one 
of them is enough for standard zones, which was done in the current 
implementation (that is, isFixedOffset() returns 
savingsInstantTransitions.length == 0). For custom ZoneRules created 
with the "of" method, it would depend on whether they are set through 
the relevant parameters (in the test case, the later was set but the 
former was empty, that was why isFixedOffset was true). It would 
therefore be possible to add and use a transient boolean field to 
represent isFixedOffset.


Just my two cents.

-Joe

On 3/2/20 10:37 AM, Roger Riggs wrote:

Looks good.

Give it a day to see if anyone else has comments.

Thanks, Roger

On 3/2/20 1:35 PM, naoto.s...@oracle.com wrote:

Hi Roger, thanks for the review.

On 3/2/20 8:44 AM, Roger Riggs wrote:

Hi Naoto,

look ok.

ZoneRules.java: 488, 644, 761, 791
I'd suggest calling isFixedOffset() instead of repeating the code:
standardTransitions.length == 0 && 
savingsInstantTransitions.length == 0


Modified as suggested:

http://cr.openjdk.java.net/~naoto/8239836/webrev.01/



It should be inlined in cases where the performance matters.


None of those locations is invoked during ZoneRules object 
instantiation. So I believe it is OK to replace them with 
isFixedOffset().


Naoto



Thanks, Roger


On 2/27/20 3:41 PM, naoto.s...@oracle.com wrote:

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8239836/webrev.00/

It turned out that 'transitionList' is not necessarily a superset of
'standardOffsetTransitionList', as in some occasions where a 
standard offset change and a savings change happen at the same 
time (canceling each other), resulting in no wall time 
transition. This means that the "rules" in the sample code is a 
valid ZoneRules instance.


However, there is an assumption in ZoneRules where no (wall time) 
transition means the fixed offset zone. With that assumption, the 
example rule is considered a fixed offset zone which is not 
correct. So the fix proposed here is not to throw an IAE but to 
recognize the rule as a valid, non-fixed offset ZoneRules instance.


Naoto

Re: [11u] RFR: 8232854: URLClassLoader.close() doesn't close cached JAR file on Windows when load() fails

[Alan Bateman]

On 02/03/2020 20:44, Alex Kashchenko wrote:


Yes, I can work on this issue for jdk/jdk. I found this part of code 
complicated and would appreciate the guidance.


JDK-8132359 is the main issue (yes, JDK-8232854 is a bit confusing). I 
think Michael is looking into whether it needs to touch or the 
URLClassPath code or whether it can be fixed in the jar protocol handler.


-Alan

Re: [15] RFR: 8239836: ZoneRules.of() doesn't check transitionList/standardOffsetTL arguments validity

[naoto . sato]

Hi Joe, thanks for the review.

Are you suggesting something like

isFixedOffset() {
return isFixedOffset;
}

Naoto

On 3/2/20 11:20 PM, Joe Wang wrote:

Hi Naoto,

The fix would be fine if you want to keep it as is since it does work.

I noticed though that for standard zones (the ones loaded from tz 
database), savingsInstantTransitions and standardTransitions are 
consistent in that they are both empty for the standard zones, e.g. 
Etc/GMT, and not empty for zones with a country/city id, including 
countries that don't actually observe DST. This means a check for one of 
them is enough for standard zones, which was done in the current 
implementation (that is, isFixedOffset() returns 
savingsInstantTransitions.length == 0). For custom ZoneRules created 
with the "of" method, it would depend on whether they are set through 
the relevant parameters (in the test case, the later was set but the 
former was empty, that was why isFixedOffset was true). It would 
therefore be possible to add and use a transient boolean field to 
represent isFixedOffset.


Just my two cents.

-Joe

On 3/2/20 10:37 AM, Roger Riggs wrote:

Looks good.

Give it a day to see if anyone else has comments.

Thanks, Roger

On 3/2/20 1:35 PM, naoto.s...@oracle.com wrote:

Hi Roger, thanks for the review.

On 3/2/20 8:44 AM, Roger Riggs wrote:

Hi Naoto,

look ok.

ZoneRules.java: 488, 644, 761, 791
I'd suggest calling isFixedOffset() instead of repeating the code:
standardTransitions.length == 0 && savingsInstantTransitions.length 
== 0


Modified as suggested:

http://cr.openjdk.java.net/~naoto/8239836/webrev.01/



It should be inlined in cases where the performance matters.


None of those locations is invoked during ZoneRules object 
instantiation. So I believe it is OK to replace them with 
isFixedOffset().


Naoto



Thanks, Roger


On 2/27/20 3:41 PM, naoto.s...@oracle.com wrote:

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8239836/webrev.00/

It turned out that 'transitionList' is not necessarily a superset of
'standardOffsetTransitionList', as in some occasions where a 
standard offset change and a savings change happen at the same time 
(canceling each other), resulting in no wall time transition. This 
means that the "rules" in the sample code is a valid ZoneRules 
instance.


However, there is an assumption in ZoneRules where no (wall time) 
transition means the fixed offset zone. With that assumption, the 
example rule is considered a fixed offset zone which is not 
correct. So the fix proposed here is not to throw an IAE but to 
recognize the rule as a valid, non-fixed offset ZoneRules instance.


Naoto

Re: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing

[Alan Bateman]

On 03/03/2020 11:01, Volker Simonis wrote:

Hi,

can I please get a review for the following small fix:

http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/
https://bugs.openjdk.java.net/browse/JDK-8240333


The code changes okay but I think the comment needs a bit of clean-up. 
Maybe drop L96-97 so that it just says that it preserves the attributes 
that don't change.


-Alan.

Re: RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing

[Martin Buchholz]

Looks Good To Me ... except you should fix that "delfated" typo.

Those looking for a zip implementation career path can try to fix up all
the compressedSize in the local headers so that they are correctly filled
in.  Which is hard because you don't know the compressedSize when you are
writing the local entry header with putNextEntry.

On Tue, Mar 3, 2020 at 3:02 AM Volker Simonis 
wrote:

> Hi,
>
> can I please get a review for the following small fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/
> https://bugs.openjdk.java.net/browse/JDK-8240333
>
> The "jmod" tool needs to update .jar files as well as .jmod files when
> adding hashes to the module-info file. This is handled in the method
> jdk.tools.jmod.JmodTask.updateModularJar() for modular jar files and
> in the methods jdk.tools.jmod.JmodTask.updateJmodFile() and
> jdk.tools.jmod.JmodOutputStream.writeEntry() for .jmod files.
>
> Unfortunately, both implementations are incorrect because they are
> writing the JarEntry/ZipEntry entries which they reading from the
> ZipInputStream verbatim to the ZipOutputStream. This approach is not
> correct, because Zip/Entry/JarEntry contains both, the compressed and
> uncompressed size of the corresponding entry. But the original
> Deflater which initially compressed that entry can be either different
> from the current one or it might have used a different compression
> level compared to the current Deflater which re-deflates the entry
> data.
>
> When the newly created entry is closed, the new compressed size will
> be checked against the original compressed size if that was recorded
> in the ZipEntry/JarEntry entry and an exception will be thrown, when
> they differ. For modular jar files it looks as follows:
>
> $ jmod hash --module-path . --hash-modules .*
> Error: java.util.zip.ZipException: invalid entry compressed size
> (expected 58 but got 57 bytes)
> java.io.UncheckedIOException: java.util.zip.ZipException: invalid
> entry compressed size (expected 58 but got 57 bytes)
> at
> jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateModularJar$3(JmodTask.java:995)
> at
> java.base/java.util.zip.ZipFile$EntrySpliterator.tryAdvance(ZipFile.java:571)
> at java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:326)
> at
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
> at
> jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModularJar(JmodTask.java:980)
> at
> jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModuleInfo(JmodTask.java:957)
> at
> jdk.jlink/jdk.tools.jmod.JmodTask.lambda$hashModules$3(JmodTask.java:300)
> at java.base/java.util.HashMap.forEach(HashMap.java:1425)
> at jdk.jlink/jdk.tools.jmod.JmodTask.hashModules(JmodTask.java:291)
> at jdk.jlink/jdk.tools.jmod.JmodTask.run(JmodTask.java:220)
> at jdk.jlink/jdk.tools.jmod.Main.main(Main.java:34)
> Suppressed: java.util.zip.ZipException: invalid entry compressed size
> (expected 58 but got 57 bytes)
> at
> java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267)
> at java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360)
> at
> java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:237)
> at java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377)
> at
> jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModularJar(JmodTask.java:976)
> ... 6 more
> Caused by: java.util.zip.ZipException: invalid entry compressed size
> (expected 58 but got 57 bytes)
> at
> java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267)
> at
> jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateModularJar$3(JmodTask.java:992)
> ... 10 more
>
> For jmod files it looks like this:
>
> $ jmod hash --module-path . --hash-modules .*
> Error: java.util.zip.ZipException: invalid entry compressed size
> (expected 383 but got 377 bytes)
> java.io.UncheckedIOException: java.util.zip.ZipException: invalid
> entry compressed size (expected 383 but got 377 bytes)
> at
> jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateJmodFile$4(JmodTask.java:1021)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at
> java.base/java.util.zip.ZipFile$EntrySpliterator.tryAdvance(ZipFile.java:571)
> at java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:326)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at

Re: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly

[Martin Buchholz]

For the truly desperate in search of a spam folder, recent emails from
google.com can be viewed here:
https://openjdk.markmail.org/search/?q=from%3Agoogle.com%20date%3A2020-

On Mon, Mar 2, 2020 at 11:15 PM Langer, Christoph 
wrote:

> Hi Volker,
>
> sure, looks good. Unfortunately I don't get the mails from Martin ☹
>
> Cheers
> Christoph
>
> > -Original Message-
> > From: Volker Simonis 
> > Sent: Montag, 2. März 2020 16:17
> > To: Langer, Christoph 
> > Cc: Java Core Libs 
> > Subject: Re: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar
> files
> > incorrectly
> >
> > Hi Christoph,
> >
> > thanks for looking at my change. I've slightly improved the
> > implementation as suggested by Martin to preserve all the zip
> > attributes which can be preserved. Still fine for you?
> >
> > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235.01
> >
> > On Sun, Mar 1, 2020 at 9:21 PM Langer, Christoph
> >  wrote:
> > >
> > > Hi Volker,
> > >
> > > this looks good to me.
> > >
> > > Best regards
> > > Christoph
> > >
> > > > -Original Message-
> > > > From: core-libs-dev  On
> > Behalf
> > > > Of Volker Simonis
> > > > Sent: Freitag, 28. Februar 2020 19:48
> > > > To: Java Core Libs 
> > > > Subject: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar
> files
> > incorrectly
> > > >
> > > > Hi,
> > > >
> > > > can I please have a review for this small test fix:
> > > >
> > > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8240235/
> > > > https://bugs.openjdk.java.net/browse/JDK-8240235
> > > >
> > > > JarUtils.updateJar() and JarUtils.updateJarFile() update jar files by
> > > > reading JarEntry-s from a source jar file and writing these exact
> > > > JarEntry-s to the destination jar file followed be the inflated and
> > > > re-deflated data belonging to this entry.
> > > >
> > > > This approach is not correct, because JarEntry contains both, the
> > > > compressed and uncompressed size of the corresponding entry. But the
> > > > original Defalter which initially compressed that entry can be either
> > > > different from the current one or it might have used a different
> > > > compression level compared to the current Deflater which re-deflates
> > > > the entry data.
> > > >
> > > > When the newly created entry is closed, the new compressed size will
> > > > be checked against the original compressed size if that was recorded
> > > > in the JarEntry and an exception will be thrown, when they differ:
> > > >
> > > > java.util.zip.ZipException: invalid entry compressed size (expected
> > > > 237 but got 238 bytes)
> > > > at
> > > >
> >
> java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:26
> > > > 7)
> > > > at
> > > >
> > java.base/java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java
> > > > :192)
> > > > at
> > > >
> > java.base/java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java
> > > > :108)
> > > > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:294)
> > > > at jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:252)
> > > > at HasUnsignedEntryTest.start(HasUnsignedEntryTest.java:77)
> > > > at HasUnsignedEntryTest.main(HasUnsignedEntryTest.java:44)
> > > > at
> > > >
> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> > > > Method)
> > > > at
> > > >
> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet
> > > > hodAccessorImpl.java:62)
> > > > at
> > > >
> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega
> > > > tingMethodAccessorImpl.java:43)
> > > > at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> > > > at
> > > >
> > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp
> > > > er.java:127)
> > > > at java.base/java.lang.Thread.run(Thread.java:832)
> > > > Suppressed: java.util.zip.ZipException: invalid entry
> > > > compressed size (expected 237 but got 238 bytes)
> > > > at
> > > >
> >
> java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:26
> > > > 7)
> > > > at
> > > >
> > java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360)
> > > > at
> > > >
> >
> java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.ja
> > > > va:237)
> > > > at
> > > >
> java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377)
> > > > at
> jdk.test.lib.util.JarUtils.updateJar(JarUtils.java:280)
> > > >
> > > > The fix is trivial. Instead of copying the JarEntry-s verbatim to the
> > > > output stream, simply write newly created JarEntry-s to the output
> > > > stream which only contain the entry name. This is also the way how
> > > > this is handled by the jar tool, when it updates jar files.
> > > >
> > > > Thank you and best regards,
> > > > Volker
>

Re: RFR: 8239365: ProcessBuilder/Basic.java test modifications for AIX execution

[Roger Riggs]

Hi Adam,

It doesn't look like you saw my comments from 2/21.
Please take another look.

http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-February/064878.html

Roger


On 3/3/20 5:43 AM, Adam Farley8 wrote:

Hi All,

Reviews and sponsor requested for a small test change.

Short version: When an AIX machine has the file set "bos.msg.en_US.rte",
the error messages are not in a form that the test expects, causing
failure.

The simplest option appears to be adding the second potential form of the
message into the regex (see webrev).

http://cr.openjdk.java.net/~afarley/8239365.1/webrev/

Bug: https://bugs.openjdk.java.net/browse/JDK-8239365

Best Regards

Adam Farley
IBM Runtimes
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

RFR(S): 8240333: jmod incorrectly updates .jar and .jmod files during hashing

[Volker Simonis]

Hi,

can I please get a review for the following small fix:

http://cr.openjdk.java.net/~simonis/webrevs/2020/8240333/
https://bugs.openjdk.java.net/browse/JDK-8240333

The "jmod" tool needs to update .jar files as well as .jmod files when
adding hashes to the module-info file. This is handled in the method
jdk.tools.jmod.JmodTask.updateModularJar() for modular jar files and
in the methods jdk.tools.jmod.JmodTask.updateJmodFile() and
jdk.tools.jmod.JmodOutputStream.writeEntry() for .jmod files.

Unfortunately, both implementations are incorrect because they are
writing the JarEntry/ZipEntry entries which they reading from the
ZipInputStream verbatim to the ZipOutputStream. This approach is not
correct, because Zip/Entry/JarEntry contains both, the compressed and
uncompressed size of the corresponding entry. But the original
Deflater which initially compressed that entry can be either different
from the current one or it might have used a different compression
level compared to the current Deflater which re-deflates the entry
data.

When the newly created entry is closed, the new compressed size will
be checked against the original compressed size if that was recorded
in the ZipEntry/JarEntry entry and an exception will be thrown, when
they differ. For modular jar files it looks as follows:

$ jmod hash --module-path . --hash-modules .*
Error: java.util.zip.ZipException: invalid entry compressed size
(expected 58 but got 57 bytes)
java.io.UncheckedIOException: java.util.zip.ZipException: invalid
entry compressed size (expected 58 but got 57 bytes)
at 
jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateModularJar$3(JmodTask.java:995)
at java.base/java.util.zip.ZipFile$EntrySpliterator.tryAdvance(ZipFile.java:571)
at java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:326)
at 
java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModularJar(JmodTask.java:980)
at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModuleInfo(JmodTask.java:957)
at jdk.jlink/jdk.tools.jmod.JmodTask.lambda$hashModules$3(JmodTask.java:300)
at java.base/java.util.HashMap.forEach(HashMap.java:1425)
at jdk.jlink/jdk.tools.jmod.JmodTask.hashModules(JmodTask.java:291)
at jdk.jlink/jdk.tools.jmod.JmodTask.run(JmodTask.java:220)
at jdk.jlink/jdk.tools.jmod.Main.main(Main.java:34)
Suppressed: java.util.zip.ZipException: invalid entry compressed size
(expected 58 but got 57 bytes)
at java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267)
at java.base/java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360)
at 
java.base/java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:237)
at java.base/java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377)
at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModularJar(JmodTask.java:976)
... 6 more
Caused by: java.util.zip.ZipException: invalid entry compressed size
(expected 58 but got 57 bytes)
at java.base/java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267)
at 
jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateModularJar$3(JmodTask.java:992)
... 10 more

For jmod files it looks like this:

$ jmod hash --module-path . --hash-modules .*
Error: java.util.zip.ZipException: invalid entry compressed size
(expected 383 but got 377 bytes)
java.io.UncheckedIOException: java.util.zip.ZipException: invalid
entry compressed size (expected 383 but got 377 bytes)
at 
jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.lambda$updateJmodFile$4(JmodTask.java:1021)
at 
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at 
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at java.base/java.util.zip.ZipFile$EntrySpliterator.tryAdvance(ZipFile.java:571)
at java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:326)
at 
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at 
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at 
java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at 
java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at 
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at 
java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateJmodFile(JmodTask.java:1009)
at jdk.jlink/jdk.tools.jmod.JmodTask$Hasher.updateModuleInfo(JmodTask.java:955)
at jdk.jlink/jdk.tools.jmod.JmodTask.lambda$hashModules$3(JmodTask.java:300)
at java.base/java.util.HashMap.forEach(HashMap.java:1425)
at jdk.jlink/jdk.tools.jmod.JmodTask.hashModules(JmodTask.java:291)
at jdk.jlink/jdk.tools.jmod.JmodTask.run(JmodTask.java:220)
at jdk.jlink/jdk.tools.jmod.Main.main(Main.java:34)
Suppressed: java.util.zip.ZipException: invalid entry compressed size
(expected 383 but got 377 

RFR 8129841 Update comment for Java_java_net_Inet6AddressImpl_getHostByAddr

[Vipin Mv1]

Hi All,

Please find the below changes for the issue 
https://bugs.openjdk.java.net/browse/JDK-8129841. Apart from the requested 
changes, I have made additional changes to the Signature where ever I found it 
incorrect.


Thanks 
Vipin M V


diff -r 387369ff21a4 src/java.base/unix/native/libnet/Inet4AddressImpl.c
--- a/src/java.base/unix/native/libnet/Inet4AddressImpl.c   Wed Feb 05 
12:20:36 2020 -0300
+++ b/src/java.base/unix/native/libnet/Inet4AddressImpl.c   Tue Mar 03 
15:32:21 2020 +0530
@@ -218,7 +218,7 @@
 /*
  * Class: java_net_Inet4AddressImpl
  * Method:getHostByAddr
- * Signature: (I)Ljava/lang/String;
+ * Signature: ([B)Ljava/lang/String;
  *
  * Theoretically the UnknownHostException could be enriched with gai error
  * information. But as it is silently ignored anyway, there's no need for this.
diff -r 387369ff21a4 src/java.base/unix/native/libnet/Inet6AddressImpl.c
--- a/src/java.base/unix/native/libnet/Inet6AddressImpl.c   Wed Feb 05 
12:20:36 2020 -0300
+++ b/src/java.base/unix/native/libnet/Inet6AddressImpl.c   Tue Mar 03 
15:32:21 2020 +0530
@@ -413,7 +413,7 @@
 /*
  * Class: java_net_Inet6AddressImpl
  * Method:getHostByAddr
- * Signature: (I)Ljava/lang/String;
+ * Signature: ([B)Ljava/lang/String;
  *
  * Theoretically the UnknownHostException could be enriched with gai error
  * information. But as it is silently ignored anyway, there's no need for this.
@@ -668,7 +668,7 @@
 /*
  * Class: java_net_Inet6AddressImpl
  * Method:isReachable0
- * Signature: ([bII[bI)Z
+ * Signature: ([BII[BII)Z
  */
 JNIEXPORT jboolean JNICALL
 Java_java_net_Inet6AddressImpl_isReachable0(JNIEnv *env, jobject this,
diff -r 387369ff21a4 src/java.base/windows/native/libnet/Inet4AddressImpl.c
--- a/src/java.base/windows/native/libnet/Inet4AddressImpl.cWed Feb 05 
12:20:36 2020 -0300
+++ b/src/java.base/windows/native/libnet/Inet4AddressImpl.cTue Mar 03 
15:32:21 2020 +0530
@@ -171,7 +171,7 @@
 /*
  * Class: java_net_Inet4AddressImpl
  * Method:getHostByAddr
- * Signature: (I)Ljava/lang/String;
+ * Signature: ([B)Ljava/lang/String;
  *
  * Theoretically the UnknownHostException could be enriched with gai error
  * information. But as it is silently ignored anyway, there's no need for this.
diff -r 387369ff21a4 src/java.base/windows/native/libnet/Inet6AddressImpl.c
--- a/src/java.base/windows/native/libnet/Inet6AddressImpl.cWed Feb 05 
12:20:36 2020 -0300
+++ b/src/java.base/windows/native/libnet/Inet6AddressImpl.cTue Mar 03 
15:32:21 2020 +0530
@@ -240,7 +240,7 @@
 /*
  * Class: java_net_Inet6AddressImpl
  * Method:getHostByAddr
- * Signature: (I)Ljava/lang/String;
+ * Signature: ([B)Ljava/lang/String;
  *
  * Theoretically the UnknownHostException could be enriched with gai error
  * information. But as it is silently ignored anyway, there's no need for this.
@@ -435,7 +435,7 @@
 /*
  * Class: java_net_Inet6AddressImpl
  * Method:isReachable0
- * Signature: ([bII[bI)Z
+ * Signature: ([BII[BII)Z
  */
 JNIEXPORT jboolean JNICALL
 Java_java_net_Inet6AddressImpl_isReachable0(JNIEnv *env, jobject this,

Re: RFR: 8239365: ProcessBuilder/Basic.java test modifications for AIX execution

[Thomas Stüfe]

This is why I always was against handing up the result of strerror to the
user :) The same problem we would have when running with different locales.
We should have a platform agnostic string table in the java lib for that
purpose...

As for the test, looks good, but I personally would shorten the AIX
patterns a bit or maybe try to find a short form fitting all platforms
(e.g. "[Pp]ermission").

But thats just idle bikeshedding, lets see what others think.

Cheers Thomas

On Tue, Mar 3, 2020 at 11:43 AM Adam Farley8  wrote:

> Hi All,
>
> Reviews and sponsor requested for a small test change.
>
> Short version: When an AIX machine has the file set "bos.msg.en_US.rte",
> the error messages are not in a form that the test expects, causing
> failure.
>
> The simplest option appears to be adding the second potential form of the
> message into the regex (see webrev).
>
> http://cr.openjdk.java.net/~afarley/8239365.1/webrev/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8239365
>
> Best Regards
>
> Adam Farley
> IBM Runtimes
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>

RFR: 8239365: ProcessBuilder/Basic.java test modifications for AIX execution

[Adam Farley8]

Hi All,

Reviews and sponsor requested for a small test change.

Short version: When an AIX machine has the file set "bos.msg.en_US.rte", 
the error messages are not in a form that the test expects, causing 
failure.

The simplest option appears to be adding the second potential form of the 
message into the regex (see webrev).

http://cr.openjdk.java.net/~afarley/8239365.1/webrev/

Bug: https://bugs.openjdk.java.net/browse/JDK-8239365 

Best Regards

Adam Farley 
IBM Runtimes
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

[Volker Simonis]

On Tue, Mar 3, 2020 at 10:26 AM Andrew Haley  wrote:
>
> On 3/2/20 10:46 PM, Volker Simonis wrote:
>
> > As lead of the 8 and 11 update projects you probably know best, if this fix
> > will eventually be considered for backporting and choose your means wisely
> > :)
>
> Yeah, I know. Srsly. :-)
>
> But one of the few things of which I am certain is that we must not
> allow the needs of backporting to determine the future of Java. That's
> the way of staying in the past.
>
> As Patrick Head put it, “Some people tell me that Formula 1 would be
> better if the drivers still used stick shifts, but that’s a bit like
> saying, 'isn’t it a pity we don’t still walk around in clogs!'”
>

Totally agree.

> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. 
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

[Andrew Haley]

On 3/2/20 10:46 PM, Volker Simonis wrote:

> As lead of the 8 and 11 update projects you probably know best, if this fix
> will eventually be considered for backporting and choose your means wisely
> :)

Yeah, I know. Srsly. :-)

But one of the few things of which I am certain is that we must not
allow the needs of backporting to determine the future of Java. That's
the way of staying in the past.

As Patrick Head put it, “Some people tell me that Formula 1 would be
better if the drivers still used stick shifts, but that’s a bit like
saying, 'isn’t it a pity we don’t still walk around in clogs!'”

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

[Andrew Haley]

On 3/2/20 9:51 PM, Kim Barrett wrote:
>> On Mar 2, 2020, at 7:00 AM, Andrew Haley  wrote:
>>
>> On 11/19/18 8:39 PM, Kim Barrett wrote:
>>> I don't see any benefit to making the first C++ code change that uses
>>> a new feature also incorporate the needed build system changes.
>>> Indeed, how does one develop that feature usage unless one has the
>>> build system changes already in hand?
>>>
>>> It seems to me that if the documentation says one can use some new
>>> language feature but the build system hasn't been updated to actually
>>> support doing so, then the documentation is wrong. And recall that
>>> this JEP includes making some new features available immediately.
>>> (That initial list might be modified as part of this JEP discussion.)
>>
>> What is the status of this? I thought we'd decide, but I still see
>>
>>   $1_CXXSTD_CXXFLAG="-std=gnu++98"
>>
>> in flags-cflags.m4
>>
>> I need std::make_unsigned in order to fix some undefined behaviour in
>> HotSpot. I could implement it myself in share/metaprogramming but if
>> we've agreed to allow C++14, can we please get it done now? Thx.
> 
> In light of JEP 362 "Deprecate the Solaris and SPARC Ports"
> https://bugs.openjdk.java.net/browse/JDK-8231554
> with the intended removal of Oracle Developer Studio (aka Solaris
> Studio) as a supported compiler sometime soon, we don't want to spend
> effort getting HotSpot to production quality on that platform with
> C++11/14 features enabled and in use.

OK. So, I guess this means that we're stuck with C++98 (!) for a while.

It's not too hard for me to write the support for make_unsigned and add
it to share/metaprogramming. I'll do that and see what people say.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

RE: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly

[Langer, Christoph]

> On 03/03/20 12:45 pm, Langer, Christoph wrote:
> > Unfortunately I don't get the mails from Martin ☹
> 
> Same for me. They always end up in spam folder which I usually check
> once a month. I see that there's already
> https://bugs.openjdk.java.net/browse/JDK-8213225 which seems to be the
> same issue.
> 

You are lucky, that you at least get it delivered to the spam folder... 

/Christoph

Re: RFR(s): 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly

[Jaikiran Pai]

On 03/03/20 12:45 pm, Langer, Christoph wrote:
> Unfortunately I don't get the mails from Martin ☹

Same for me. They always end up in spam folder which I usually check
once a month. I see that there's already
https://bugs.openjdk.java.net/browse/JDK-8213225 which seems to be the
same issue.

-Jaikiran