Re: How can I trigger a @Serial warning?

2021-09-23 Thread Tagir Valeev 
Hello, Cay!

By the way, in IntelliJ IDEA we have the inspection that warns you about
wrong use of Serial:

[image: image.png]
It also suggests adding this annotation where it's appropriate:

[image: image.png]
Both inspections are turned on by default.

With best regards,
Tagir Valeev.


On Thu, Sep 9, 2021 at 2:47 PM Cay Horstmann 
wrote:

> I am trying to give an example of the utility of the @Serial annotation.
> But the JDK 17 javac doesn't seem to do anything with it. I tried:
>
> @Serial private void readObject(java.io.ObjectInputStream stream, int
> shouldNotHaveThisParam) throws IOException, ClassNotFoundException
> @Serial private static final String serialVersionUID = "Fred";
> @Serial public String getName() { ... }
>
> Is there some flag that I need to use? I tried -Xlint:serial, but it
> didn't make a difference.
>
> Thanks,
>
> Cay
>
> --
>
> Cay S. Horstmann | http://horstmann.com | mailto:c...@horstmann.com
>

Re: RFR: 8273401: Disable JarIndex support in URLClassPath [v2]

2021-09-23 Thread wxiang 
On Thu, 16 Sep 2021 01:29:41 GMT, wxiang 
 wrote:

>> wxiang has updated the pull request incrementally with one additional commit 
>> since the last revision:
>> 
>>   add isEmpty check
>
> I have changed 
> 
> ENABLE_JAR_INDEX = p != null ? p.equals("true") : false;
> 
> to
> 
> ENABLE_JAR_INDEX = p != null ? p.equals("true") || p.isEmpty() : false;
> 
> 
> Furthemore,  in order to maintain consistency in URLClassPath, the property 
> name is "jdk.net.URLClassPath.enableJarIndex" .

> @shiyuexw Just a reminder that you need to finalize the CSR.

Thanks a lot. We have finalized the CSR.

-

PR: https://git.openjdk.java.net/jdk/pull/5524

Re: RFR: 8266936: Add a finalization JFR event [v11]

2021-09-23 Thread Coleen Phillimore 
On Mon, 13 Sep 2021 17:12:49 GMT, Markus Grönlund  wrote:

>> Greetings,
>> 
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to 
>> replace and mitigate Object.finalize() uses in the JDK libraries; please see 
>> https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
>> 
>> We also like to assist users in replacing and mitigating uses in non-JDK 
>> code.
>> 
>> Hence, this changeset adds a periodic JFR event to help identify which 
>> classes are overriding Object.finalize().
>> 
>> Thanks
>> Markus
>
> Markus Grönlund has updated the pull request incrementally with two 
> additional commits since the last revision:
> 
>  - remove rehashing and rely on default grow_hint for table resize
>  - mtStatistics

src/hotspot/share/jfr/periodic/jfrFinalizerStatisticsEvent.cpp line 26:

> 24: 
> 25: #include "precompiled.hpp"
> 26: #if INCLUDE_MANAGEMENT

With precompiled headers turned off, this gets a compilation error:
error: "INCLUDE_MANAGEMENT" is not
 defined, evaluates to 0 [-Werror=undef]

-

PR: https://git.openjdk.java.net/jdk/pull/4731

Re: RFR: JDK-8274087: Windows DLL path not set correctly.

2021-09-23 Thread Alexey Semenyuk 
On Thu, 23 Sep 2021 20:03:29 GMT, Andy Herrick  wrote:

> JDK-8274087: Windows DLL path not set correctly.

Marked as reviewed by asemenyuk (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5663

Re: RFR: 8274234: Remove unnecessary boxing via primitive wrapper valueOf(String) methods in java.sql.rowset

2021-09-23 Thread Brian Burkhalter 
On Thu, 23 Sep 2021 19:47:51 GMT, Andrey Turbanov 
 wrote:

> Usages of methods Integer.valueOf, Byte.valueOf, Short.valueOf, 
> Float.valueOf, Double.valueOf, Long.valueOf often can be simplified by using 
> their pair methods parseInt/parseLong/parseShort/parseByte/parseFloat.

Marked as reviewed by bpb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5662

Re: RFR: 8274234: Remove unnecessary boxing via primitive wrapper valueOf(String) methods in java.sql.rowset

2021-09-23 Thread Lance Andersen 
On Thu, 23 Sep 2021 19:47:51 GMT, Andrey Turbanov 
 wrote:

> Usages of methods Integer.valueOf, Byte.valueOf, Short.valueOf, 
> Float.valueOf, Double.valueOf, Long.valueOf often can be simplified by using 
> their pair methods parseInt/parseLong/parseShort/parseByte/parseFloat.

Marked as reviewed by lancea (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5662

Re: RFR: JDK-8274087: Windows DLL path not set correctly.

2021-09-23 Thread Alexander Matveev 
On Thu, 23 Sep 2021 20:03:29 GMT, Andy Herrick  wrote:

> JDK-8274087: Windows DLL path not set correctly.

Marked as reviewed by almatvee (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5663

RFR: JDK-8274087: Windows DLL path not set correctly.

2021-09-23 Thread Andy Herrick 
JDK-8274087: Windows DLL path not set correctly.

-

Commit messages:
 - JDK-8274087: Windows DLL path not set correctly.

Changes: https://git.openjdk.java.net/jdk/pull/5663/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5663=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274087
  Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5663/head:pull/5663

PR: https://git.openjdk.java.net/jdk/pull/5663

Integrated: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base

2021-09-23 Thread Andrey Turbanov 
On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov 
 wrote:

> There are few places in code where manual while loop is used with Iterator to 
> iterate over Collection.
> Instead of manual while cycles it's preferred to use enhanced-for cycle 
> instead: it's less verbose, makes code easier to read and it's less 
> error-prone.
> It doesn't have any performance impact: java compiler generates similar code 
> when compiling enhanced-for cycle.
> 
> Similar cleanups:
> * https://bugs.openjdk.java.net/browse/JDK-8258006
> * https://bugs.openjdk.java.net/browse/JDK-8257912

This pull request has now been integrated.

Changeset: 56b8b352
Author:Andrey Turbanov 
Committer: Roger Riggs 
URL:   
https://git.openjdk.java.net/jdk/commit/56b8b35286634f2d2224ca445bc9f32ff284ae74
Stats: 93 lines in 11 files changed: 1 ins; 50 del; 42 mod

8273261: Replace 'while' cycles with iterator with enhanced-for in java.base

Reviewed-by: dfuchs, rriggs, iris, mullan

-

PR: https://git.openjdk.java.net/jdk/pull/5328

Re: RFR: 8273261: Replace 'while' cycles with iterator with enhanced-for in java.base

2021-09-23 Thread Andrey Turbanov 
On Wed, 1 Sep 2021 07:37:53 GMT, Andrey Turbanov 
 wrote:

> There are few places in code where manual while loop is used with Iterator to 
> iterate over Collection.
> Instead of manual while cycles it's preferred to use enhanced-for cycle 
> instead: it's less verbose, makes code easier to read and it's less 
> error-prone.
> It doesn't have any performance impact: java compiler generates similar code 
> when compiling enhanced-for cycle.
> 
> Similar cleanups:
> * https://bugs.openjdk.java.net/browse/JDK-8258006
> * https://bugs.openjdk.java.net/browse/JDK-8257912

Can someone sponsor changes, please? I believe we have enough approvals.

-

PR: https://git.openjdk.java.net/jdk/pull/5328

RFR: 8274234: Remove unnecessary boxing via primitive wrapper valueOf(String) methods in java.sql.rowset

2021-09-23 Thread Andrey Turbanov 
Usages of methods Integer.valueOf, Byte.valueOf, Short.valueOf, Float.valueOf, 
Double.valueOf, Long.valueOf often can be simplified by using their pair 
methods parseInt/parseLong/parseShort/parseByte/parseFloat.

-

Commit messages:
 - [PATCH] Remove unnecessary boxing via primitive wrapper valueOf(String) 
methods in java.sql.rowset

Changes: https://git.openjdk.java.net/jdk/pull/5662/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5662=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274234
  Stats: 7 lines in 2 files changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5662.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5662/head:pull/5662

PR: https://git.openjdk.java.net/jdk/pull/5662

Re: RFR: 8177814: jdk/editpad is not in jdk TEST.groups

2021-09-23 Thread Sergey Bylokhov 
On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev  wrote:

> @prrace notices this here: 
> https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think 
> it is the already open issue that this patch is fixing. While the original 
> patch added the test in `jdk_other`, Phil suggests it to be added to 
> `jdk_desktop`.
> 
> Additional testing:
>  - [x] `jdk_editpad` is passing

There is also one such test in the test/hotspot.
@prrace Not sure what is the best fix for this. Probably the test automation 
should run the headful tests from t1/2/3/etc instead of just jdk_desktop?

-

PR: https://git.openjdk.java.net/jdk/pull/5648

Re: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file [v3]

2021-09-23 Thread Alan Bateman 
On Thu, 23 Sep 2021 14:53:42 GMT, Christian Stein  wrote:

>> This commit appends the name of the JAR file to the exception message for 
>> when automatic module lists a non-existing provider class.
>
> Christian Stein has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Add JBS issue `8262944` to the `@bug` list and update copyright year

Marked as reviewed by alanb (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5543

Re: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file [v3]

2021-09-23 Thread Mandy Chung 
On Thu, 23 Sep 2021 14:53:42 GMT, Christian Stein  wrote:

>> This commit appends the name of the JAR file to the exception message for 
>> when automatic module lists a non-existing provider class.
>
> Christian Stein has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Add JBS issue `8262944` to the `@bug` list and update copyright year

Looks good to me.

-

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5543

RFR: 8273682: Upgrade Jline to 3.20.0

2021-09-23 Thread Jan Lahoda 
I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt terminal 
(see JDK-8270943), and to generally use a newer version of the library. This 
patch is basically a application of relevant parts of the diff between JLine 
3.14.0 and 3.20.0, with merge fixes as needed.

Thanks!

-

Commit messages:
 - Removing trailing whitespace.
 - Fixing tests.
 - Fixing Windows build.
 - Upgrading JLine to 3.20.0

Changes: https://git.openjdk.java.net/jdk/pull/5655/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5655=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273682
  Stats: 2667 lines in 47 files changed: 1830 ins; 473 del; 364 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5655.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5655/head:pull/5655

PR: https://git.openjdk.java.net/jdk/pull/5655

Re: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file [v3]

2021-09-23 Thread Lance Andersen 
On Thu, 23 Sep 2021 14:53:42 GMT, Christian Stein  wrote:

>> This commit appends the name of the JAR file to the exception message for 
>> when automatic module lists a non-existing provider class.
>
> Christian Stein has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Add JBS issue `8262944` to the `@bug` list and update copyright year

Marked as reviewed by lancea (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5543

Integrated: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0

2021-09-23 Thread Roger Riggs 
On Wed, 22 Sep 2021 15:00:59 GMT, Roger Riggs  wrote:

> The Mac OS specific code to determine the os.version property in 
> java_props_macosx.c is updated
> to replace the code extracting the version from the SystemVersion.plist by 
> reading the version using t\
> he hidden link:

This pull request has now been integrated.

Changeset: 3b1b8fc6
Author:Roger Riggs 
URL:   
https://git.openjdk.java.net/jdk/commit/3b1b8fc646493eae5f4df828afe29abb75fa5e60
Stats: 25 lines in 1 file changed: 7 ins; 13 del; 5 mod

8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0

Reviewed-by: naoto, clanger

-

PR: https://git.openjdk.java.net/jdk/pull/5633

Re: RFR: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 [v2]

2021-09-23 Thread Roger Riggs 
On Wed, 22 Sep 2021 17:41:18 GMT, Roger Riggs  wrote:

>> The Mac OS specific code to determine the os.version property in 
>> java_props_macosx.c is updated
>> to replace the code extracting the version from the SystemVersion.plist by 
>> reading the version using t\
>> he hidden link:
>
> Roger Riggs has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Check for missing version from SystemVersion plist.
>   Refactor avoid repetition of conversion of NSString to char *.

Thanks for testing with Xcode 11.7. and MacOS 11.6.

-

PR: https://git.openjdk.java.net/jdk/pull/5633

Re: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file [v3]

2021-09-23 Thread Christian Stein 
> This commit appends the name of the JAR file to the exception message for 
> when automatic module lists a non-existing provider class.

Christian Stein has updated the pull request incrementally with one additional 
commit since the last revision:

  Add JBS issue `8262944` to the `@bug` list and update copyright year

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5543/files
  - new: https://git.openjdk.java.net/jdk/pull/5543/files/5afba0bd..f8b15c13

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=5543=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5543=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5543.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5543/head:pull/5543

PR: https://git.openjdk.java.net/jdk/pull/5543

Re: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file [v2]

2021-09-23 Thread Alan Bateman 
On Thu, 23 Sep 2021 13:40:30 GMT, Christian Stein  wrote:

>> This commit appends the name of the JAR file to the exception message for 
>> when automatic module lists a non-existing provider class.
>
> Christian Stein has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Assert that only the name of the JAR file (without its path) is appended

Thanks for the update. For completeness, you may want to add to the list of JBS 
issues listed at the top of AutomatcModulesTest and you probably should update 
its copyright year too.

-

PR: https://git.openjdk.java.net/jdk/pull/5543

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

2021-09-23 Thread Andy Herrick 

I also had a JDK16 bin dir on my path ...

I can get the error you show below (Error occurred during initialization 
of VM) if I clear my PATH, which is different from the error I get when 
running without moved runtime, so I can reproduce problem and test the fix.


I am using a script like:



./gradlew.bat clean build

cp -r build/application build/app2
mv build/app2/FetchURL/jre build/app2/FetchURL/runtime
cp FetchURLcfg.save build/app2/FetchURL/app/FetchURL.cfg

export PATH=

echo ""
echo "RUN as built:"
echo ""
build/application/FetchURL/FetchURL

echo ""
echo "RUN with default runtime:"
echo ""
build/app2/FetchURL/FetchURL

after fix both runs should have the same behavior and there should be no 
error like:



Error occurred during initialization of VM
Could not find agent library instrument on the library path, with 
error: Can't find dependent libraries

Module java.instrument may be missing from runtime image.


/Andy

On 9/22/2021 11:44 AM, Scott Palmer wrote:



On Sep 22, 2021, at 11:22 AM, Andy Herrick > wrote:


I still don't get the error your report.  Is there something else 
that needs to be set up for using instrumentation ?


Nothing that I’m aware of.  Maybe there is something to do with Visual 
C/C++ runtime libraries that I have installed globally? -just a wild 
guess.


Ohhh… here’s something…

I had JDK 17 ‘bin’ folder on my PATH (along with many other things)
If I clear the PATH env var with:
 set PATH=

Then I get an different error:

Error occurred during initialization of VM
Could not find agent library instrument on the library path, with 
error: Can’t find dependent libraries

Module java.instrument may be missing from runtime image.

All I have to do to et back to the original error is

set PATH=C:\Tools\jdk-17\bin

So this is definitely related to the DLL search path, and it was just 
lucky that some libraries were found via PATH in my environment.




I do get a different error when I have both runtime and jre 
directories after "cp -r jre runtime" (in 
FetchURL/build/application/FetchURL dir)


As built (before copy):


$ ./FetchURL
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" 
with message c

an't find transform methodID at JPLISAgent.c line: 552
*** java.lang.instrument ASSERTION FAILED ***: "result" at 
JPLISAgent.c line: 400


FATAL ERROR in native method: processing of -javaagent failed


after copy:


$ ./FetchURL
Exception in thread "main" java.lang.ClassNotFoundException: 
io.m3si.utils.ClassL

oaderUtils$Agent
    at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClas

sLoader.java:636)
    at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Cl

assLoaders.java:182)
    at 
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAg

ent(InstrumentationImpl.java:433)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPre

main(InstrumentationImpl.java:527)
*** java.lang.instrument ASSERTION FAILED ***: "result" with message 
agent load/p
remain call failed at 
t:\workspace\open\src\java.instrument\share\native\libinstr

ument\JPLISAgent.c line: 422
FATAL ERROR in native method: processing of -javaagent failed, 
processJavaStart f

ailed


but then with jre removed and line in cfg removed I get the same error:


$ ./FetchURL
Exception in thread "main" java.lang.ClassNotFoundException: 
io.m3si.utils.ClassLoaderUt

ils$Agent
    at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader

.java:636)
    at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoad

ers.java:182)
    at 
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(Ins

trumentationImpl.java:433)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(In

strumentationImpl.java:527)
*** java.lang.instrument ASSERTION FAILED ***: "result" with message 
agent load/premain
call failed at 
t:\workspace\open\src\java.instrument\share\native\libinstrument\JPLISAge

nt.c line: 422
FATAL ERROR in native method: processing of -javaagent failed, 
processJavaStart failed


note the "t:\workspace" ?  I don't have a t: drive, where is that 
coming from ?


Must be from how the JDK was built.  I don’t have a T: drive either.

jar -tvf build\application\FetchURL\app\libs\FetchURL-0.0.01.jar
     0 Wed Sep 22 11:16:40 EDT 2021 META-INF/
   248 Wed Sep 22 11:16:40 EDT 2021 META-INF/MANIFEST.MF
     0 Wed Sep 22 11:10:30 EDT 2021 io/
     0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/
     0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/
     0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/fetchurl/
  3988 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/fetchurl/Main.class
  1000 Wed Sep 22 11:10:30 EDT 2021

Re: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file [v2]

2021-09-23 Thread Christian Stein 
> This commit appends the name of the JAR file to the exception message for 
> when automatic module lists a non-existing provider class.

Christian Stein has updated the pull request incrementally with one additional 
commit since the last revision:

  Assert that only the name of the JAR file (without its path) is appended

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5543/files
  - new: https://git.openjdk.java.net/jdk/pull/5543/files/bb9762b8..5afba0bd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=5543=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5543=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5543.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5543/head:pull/5543

PR: https://git.openjdk.java.net/jdk/pull/5543

Re: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file

2021-09-23 Thread Christian Stein 
On Thu, 23 Sep 2021 11:26:26 GMT, Alan Bateman  wrote:

>> This commit appends the name of the JAR file to the exception message for 
>> when automatic module lists a non-existing provider class.
>
> src/java.base/share/classes/jdk/internal/module/ModulePath.java line 554:
> 
>> 552: String pn = packageName(cn);
>> 553: if (!packages.contains(pn)) {
>> 554: String msg = "Provider class " + cn + " not 
>> in module created for " + fn;
> 
> "not in module created" isn't quite right as the module cannot be created.  
> Maybe you could change it to "not in JAR file"

Will do so.

-

PR: https://git.openjdk.java.net/jdk/pull/5543

Re: RFR: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0 [v2]

2021-09-23 Thread Christoph Langer 
On Wed, 22 Sep 2021 17:41:18 GMT, Roger Riggs  wrote:

>> The Mac OS specific code to determine the os.version property in 
>> java_props_macosx.c is updated
>> to replace the code extracting the version from the SystemVersion.plist by 
>> reading the version using t\
>> he hidden link:
>
> Roger Riggs has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Check for missing version from SystemVersion plist.
>   Refactor avoid repetition of conversion of NSString to char *.

Looks good to me. I tested with an Xcode 11.7 build on a MacOS 11.6 and there 
OsVersionTest fails without the fix and passes with it.

-

Marked as reviewed by clanger (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5633

Integrated: 8273546: DecimalFormat documentation contains literal HTML character references

2021-09-23 Thread Naoto Sato 
On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato  wrote:

> Simple doc fix.

This pull request has now been integrated.

Changeset: c4345285
Author:Naoto Sato 
URL:   
https://git.openjdk.java.net/jdk/commit/c43452859d7211f0d6537d71bd0df89412d4ff6f
Stats: 14 lines in 3 files changed: 0 ins; 0 del; 14 mod

8273546: DecimalFormat documentation contains literal HTML character references

Reviewed-by: joehw, bpb, iris, lancea

-

PR: https://git.openjdk.java.net/jdk/pull/5620

Re: RFR: 8273401: Disable JarIndex support in URLClassPath [v2]

2021-09-23 Thread Alan Bateman 
On Thu, 16 Sep 2021 01:29:41 GMT, wxiang 
 wrote:

>> wxiang has updated the pull request incrementally with one additional commit 
>> since the last revision:
>> 
>>   add isEmpty check
>
> I have changed 
> 
> ENABLE_JAR_INDEX = p != null ? p.equals("true") : false;
> 
> to
> 
> ENABLE_JAR_INDEX = p != null ? p.equals("true") || p.isEmpty() : false;
> 
> 
> Furthemore,  in order to maintain consistency in URLClassPath, the property 
> name is "jdk.net.URLClassPath.enableJarIndex" .

@shiyuexw Just a reminder that you need to finalize the CSR.

-

PR: https://git.openjdk.java.net/jdk/pull/5524

Re: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file

2021-09-23 Thread Alan Bateman 
On Thu, 16 Sep 2021 09:06:20 GMT, Christian Stein  wrote:

> This commit appends the name of the JAR file to the exception message for 
> when automatic module lists a non-existing provider class.

src/java.base/share/classes/jdk/internal/module/ModulePath.java line 554:

> 552: String pn = packageName(cn);
> 553: if (!packages.contains(pn)) {
> 554: String msg = "Provider class " + cn + " not 
> in module created for " + fn;

"not in module created" isn't quite right as the module cannot be created.  
Maybe you could change it to "not in JAR file"

-

PR: https://git.openjdk.java.net/jdk/pull/5543

Re: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file

2021-09-23 Thread Jorn Vernee 
On Thu, 16 Sep 2021 09:06:20 GMT, Christian Stein  wrote:

> This commit appends the name of the JAR file to the exception message for 
> when automatic module lists a non-existing provider class.

Marked as reviewed by jvernee (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5543

Re: RFR: JDK-8262944: Improve exception message when automatic module lists provider class not in JAR file

2021-09-23 Thread Daniel Fuchs 
On Thu, 16 Sep 2021 09:06:20 GMT, Christian Stein  wrote:

> This commit appends the name of the JAR file to the exception message for 
> when automatic module lists a non-existing provider class.

The proposed change looks reasonable to me.

-

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5543

Re: RFR: 8231640: (prop) Canonical property storage [v22]

2021-09-23 Thread Magnus Ihse Bursie 
On Wed, 22 Sep 2021 10:27:45 GMT, Jaikiran Pai  wrote:

>> The commit in this PR implements the proposal for enhancement that was 
>> discussed in the core-libs-dev mailing list recently[1], for 
>> https://bugs.openjdk.java.net/browse/JDK-8231640
>> 
>> At a high level - the `store()` APIs in `Properties` have been modified to 
>> now look for the `SOURCE_DATE_EPOCH` environment variable[2]. If that env 
>> variable is set, then instead of writing out the current date time as a date 
>> comment, the `store()` APIs instead will use the value set for this env 
>> variable to parse it to a `Date` and write out the string form of such a 
>> date. The implementation here uses the `d MMM  HH:mm:ss 'GMT'` date 
>> format and `Locale.ROOT` to format and write out such a date. This should 
>> provide reproducibility whenever the `SOURCE_DATE_EPOCH` is set. 
>> Furthermore, intentionally, no changes in the date format of the "current 
>> date" have been done.
>> 
>> These  modified `store()` APIs work in the presence of the `SecurityManager` 
>> too. The caller is expected to have a read permission on the 
>> `SOURCE_DATE_EPOCH` environment variable. If the caller doesn't have that 
>> permission, then the implementation of these `store()` APIs will write out 
>> the "current date" and will ignore any value that has been set for the 
>> `SOURCE_DATE_EPOCH` env variable. This should allow for backward 
>> compatibility of existing applications, where, when they run under a 
>> `SecurityManager` and perhaps with an existing restrictive policy file, the 
>> presence of `SOURCE_DATE_EPOCH` shouldn't impact their calls to the 
>> `store()` APIs.
>> 
>> The modified `store()` APIs will also ignore any value for 
>> `SOURCE_DATE_EPOCH` that  cannot be parsed to an `long` value. In such 
>> cases, the `store()` APIs will write out the "current date" and ignore the 
>> value set for this environment variable. No exceptions will be thrown for 
>> such invalid values. This is an additional backward compatibility precaution 
>> to prevent any rogue value for `SOURCE_DATE_EPOCH` from breaking 
>> applications.
>> 
>> An additional change in the implementation of these `store()` APIs and 
>> unrelated to the date comment, is that these APIs will now write out the 
>> property keys in a deterministic order. The keys will be written out in the 
>> natural ordering as specified by `java.lang.String#compareTo()` API.
>> 
>> The combination of the ordering of the property keys when written out and 
>> the usage of `SOURCE_DATE_EPOCH` environment value to determine the date 
>> comment should together allow for reproducibility of the output generated by 
>> these `store()` APIs.
>> 
>> New jtreg test classes have been introduced to verify these changes. The 
>> primary focus of `PropertiesStoreTest` is the ordering aspects of the 
>> property keys that are written out. On the other hand 
>> `StoreReproducibilityTest` focuses on the reproducibility of the output 
>> generated by these APIs.  The `StoreReproducibilityTest` runs these tests 
>> both in the presence and absence of `SecurityManager`. Plus, in the presence 
>> of SecurityManager, it tests both the scenarios where the caller is granted 
>> the requisite permission and in other case not granted that permission.
>> 
>> These new tests and existing tests under `test/jdk/java/util/Properties/` 
>> pass with these changes.
>> 
>> [1] 
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html
>> [2] https://reproducible-builds.org/specs/source-date-epoch/
>
> Jaikiran Pai has updated the pull request incrementally with two additional 
> commits since the last revision:
> 
>  - Revert "Implement Mark's suggestion in CSR to include the 
> java.properties.date in the list of system properties listed in 
> System::getProperties()"
>
>Additional inputs since this specific commit was introduced have leaned 
> towards not listing this property in System::getProperties()
>
>This reverts commit 458c1fd37cf1e8e8bd0a60a171d173ce5da12b7c.
>  - reduce the line length of code comment

Marked as reviewed by ihse (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5372

RFR: 8177814: jdk/editpad is not in jdk TEST.groups

2021-09-23 Thread Aleksey Shipilev 
@prrace notices this here: 
https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think it 
is the already open issue that this patch is fixing. While the original patch 
added the test in `jdk_other`, Phil suggests it to be added to `jdk_desktop`.

Additional testing:
 - [x] `jdk_editpad` is passing

-

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/5648/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5648=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8177814
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5648.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5648/head:pull/5648

PR: https://git.openjdk.java.net/jdk/pull/5648

Re: RFR: 8236505: Mark jdk/editpad/EditPadTest.java as @headful

2021-09-23 Thread Aleksey Shipilev 
On Wed, 22 Sep 2021 23:19:50 GMT, Phil Race  wrote:

> You'd need to add it to the desktop test group.

Right. See #5648.

-

PR: https://git.openjdk.java.net/jdk/pull/5544

Integrated: 8274075: Fix miscellaneous typos in java.base

2021-09-23 Thread Pavel Rappo 
On Tue, 21 Sep 2021 12:26:25 GMT, Pavel Rappo  wrote:

> 8274075: Fix miscellaneous typos in java.base

This pull request has now been integrated.

Changeset: 87998565
Author:Pavel Rappo 
URL:   
https://git.openjdk.java.net/jdk/commit/8799856528f5804b616b734caed3fc4ba9811bfa
Stats: 26 lines in 9 files changed: 0 ins; 1 del; 25 mod

8274075: Fix miscellaneous typos in java.base

Reviewed-by: dfuchs, darcy, iris, lancea, bpb

-

PR: https://git.openjdk.java.net/jdk/pull/5610

Re: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time [v2]

2021-09-23 Thread Jaikiran Pai 
On Fri, 17 Sep 2021 12:54:07 GMT, Jaikiran Pai  wrote:

>> The commit here is a potential fix for the issue noted in 
>> https://bugs.openjdk.java.net/browse/JDK-8258117.
>> 
>> The change here repurposes an existing internal interface `ModuleInfoEntry` 
>> to keep track of the last modified timestamp of a `module-info.class` 
>> descriptor.
>> 
>> This commit uses the timestamp of the `module-info.class` on the filesystem 
>> to set the time on the `JarEntry`. There are a couple of cases to consider 
>> here:
>> 
>> 1. When creating a jar  (using `--create`), we use the source 
>> `module-info.class` from the filesystem and then add extended info to it 
>> (attributes like packages, module version etc...). In such cases, this patch 
>> will use the lastmodified timestamp from the filesystem of 
>> `module-info.class` even though we might end up updating/extending/modifying 
>> (for example by adding a module version) its content while storing it as a 
>> `JarEntry`. 
>> 
>> 2. When updating a jar (using `--update`), this patch will use the 
>> lastmodified timestamp of `module-info.class` either from the filesystem or 
>> from the source jar's entry (depending on whether a new `module-info.class` 
>> is being passed to the command). Here too, it's possible that we might end 
>> up changing/modifying/extending the `module-info.class` (for example, 
>> changing the module version to a new version) that gets written into the 
>> updated jar file, but this patch _won't_ use `System.currentTimeMillis()` 
>> even in such cases.
>> 
>> If we do have to track actual changes that might happen to 
>> `module-info.class` while extending its info (in `extendedInfoBytes()`) and 
>> then decide whether to use current system time as last modified time, then 
>> this will require a bigger change and also a discussion on what kind of 
>> extending of module-info.class content will require a change to the 
>> lastmodifiedtime of that entry.
>
> Jaikiran Pai has updated the pull request with a new target base due to a 
> merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains two additional 
> commits since the last revision:
> 
>  - Merge latest from master branch
>  - 8258117: jar tool sets the time stamp of module-info.class entries to the 
> current time

Any reviews for this one, please?

-

PR: https://git.openjdk.java.net/jdk/pull/5486