RFR: JDK-8230654: jpackage package-type dmg on macOS

[Michael Paus]

Hi,

why are there scrollbars in the image on JBS? When you normally

open a DMG you do not get scrollbars.

Michael



Message: 6
Date: Tue, 17 Sep 2019 19:42:01 -0700
From: Alexander Matveev 
To: core-libs-dev 
Subject: RFR: JDK-8230654: jpackage package-type dmg on macOS
Message-ID: <94fa6522-c5ca-c305-b257-71388e97b...@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).

- Added link to "/Application" folder to DMG for drag and drop app to
this folder.
- Added background image with arrow pointing from App icon to
Application folder.
- If adding link and image to DMG fails it will not be considered
critical error. In headless environment it might not work correctly.
- See JBS issue for screenshot on how DMG will looks like with this fix.

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

[2] http://cr.openjdk.java.net/~almatvee/8230654/webrev.01/

Thanks,
Alexander

RFR: JDK-8230654: jpackage package-type dmg on macOS

[Alexander Matveev]

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Added link to "/Application" folder to DMG for drag and drop app to 
this folder.
- Added background image with arrow pointing from App icon to 
Application folder.
- If adding link and image to DMG fails it will not be considered 
critical error. In headless environment it might not work correctly.

- See JBS issue for screenshot on how DMG will looks like with this fix.

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

[2] http://cr.openjdk.java.net/~almatvee/8230654/webrev.01/

Thanks,
Alexander

Re: Concurrent Hash Map javadoc question

[David Holmes]

Re-directing to core-libs-dev mailing list.

David

On 18/09/2019 5:45 am, Keith Turner wrote:

The javadoc for ConcurrentHashMap.computeIfAbsent() states the
remapping function is applied at most once.  The functions
computeIfPresent() and compute() do not explicitly state if the
remapping functions could possibly be run multiple times. Does anyone
know if computeIfPresent() and compute() are guaranteed to only run
the remapping functions at most once?  If so, should the javadoc be
updated?

Thanks,

Keith

Re: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null.

[Remi Forax]

Hi Goetz,
in bytecodeUtils.cpp, in print_local_var(),
i believe that the code
  if (!method->is_static() && (slot == 0)) {
  os->print("this");
  }
  ...
is only true if the bytecode is generated by javac and ecj, tools like proguard 
that tries to obfuscate the code will reuse the slot 0 once "this" is not 
needed anymore.
This is obviously also true for any other parameters, so in my opinion, you 
should not try to be too heroic here and always display "local%d". 

The other solution is to propagate "this" and "parameter%d" during the static 
analysis, so "this" will become "local0" once a store_0 is seen.

Rémi

- Mail original -
> De: "Goetz Lindenmaier" 
> À: "hotspot-runtime-dev" , 
> "core-libs-dev" 
> Envoyé: Mardi 17 Septembre 2019 16:18:03
> Objet: RE: RFR (L, final): 8218626: Add detailed message to 
> NullPointerException describing what is null.

> @core-libs experts, I would appreciate comments on the changes
> to NullPointerException.java, especially wrt. the Javadoc comment.
> The change there is S.
> 
> Best regards,
>  Goetz.
> 
>> -Original Message-
>> From: Lindenmaier, Goetz
>> Sent: Dienstag, 10. September 2019 11:48
>> To: 'Hotspot dev runtime' ; Java Core
>> Libs 
>> Subject: RFR (L, final): 8218626: Add detailed message to 
>> NullPointerException
>> describing what is null.
>> 
>> Hi,
>> 
>> 
>> 
>> this is the implementation of JEP 358: Helpful NullPointerExceptions.
>> 
>> 
>> 
>> The JEP is in status "Candidate". Coleen (many, many thanks!) ran
>> 
>> it through the Oracle-internal processes.  Now I please need final reviews
>> 
>> for this change so that I can propose it to target jdk 14.
>> 
>> 
>> 
>> JEP: https://bugs.openjdk.java.net/browse/JDK-8220715
>> 
>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628
>> 
>> webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/
>> 
>> 
>> 
>> The change ran through a lot of testing, all jtreg and jck tests to name
>> 
>> only some. The webrev points to patch
>> 
>> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-
>> NPE/16/enable_NPE_message.patch
>> 
>> that enables the change by default,  which was useful for testing to
>> 
>> assure the code is used in the tests.
>> 
>> I just pushed the change to jdk/submit once more.
>> 
>> 
>> 
>> Please review.
>> 
>> 
>> 
>> Thanks!
>> 
> >   Goetz.

Re: RFR: JDK-8230920: jpackage problems when -input dir contains any files with "cfg" extension.

[Andy Herrick]

On 9/17/2019 3:51 PM, Alexey Semenyuk wrote:



On 9/17/2019 3:17 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


On Windows  when building MSI, the original application name was 
determined by looking into the /app dir for a ".cfg" file.


The problem was that:

 - There may be application files with ".cfg" extension.

 - There may be multiple ".cfg" files due to --add-launcher option(s)

Instead we create an ".id" in the root of the 
app-image , to insure we can derive application name from app-image.
`.id` will be another well known file. Why it is 
better than `app/.cfg`? Because there can be 
multiple `app/.cfg` files and only a single 
`.id`? What will prevent people from creating their 
own .id files?

because any file created by user will be in app directory, not in root.
I don't like this solution, to be honest. Its only benefit is that it 
is simple. Can we instead put some data in `app/name>.cfg` file for the main launcher when building app image so that 
bundle packagers can read all .cfg files and find the one that 
corresponds to the main launcher and thus get application name?


I began implementing it this way, adding an app.isMain=true or 
app.isMain=false entry in each cfg file (at least those generated by 
us).  That made it far more complicated.  Just to determine the 
application name required reading and parsing all the cfg files. There 
is currently no other reason for the bundling code to ever read these 
files, so I reverted to this simpler solution.


/Andy



- Alexey


[1] https://bugs.openjdk.java.net/browse/JDK-8230920
[2] http://cr.openjdk.java.net/~herrick/8230920


Thanks

Andy,

Re: RFR: JDK-8230920: jpackage problems when -input dir contains any files with "cfg" extension.

[Alexey Semenyuk]

On 9/17/2019 3:17 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


On Windows  when building MSI, the original application name was 
determined by looking into the /app dir for a ".cfg" file.


The problem was that:

 - There may be application files with ".cfg" extension.

 - There may be multiple ".cfg" files due to --add-launcher option(s)

Instead we create an ".id" in the root of the 
app-image , to insure we can derive application name from app-image.
`.id` will be another well known file. Why it is 
better than `app/.cfg`? Because there can be multiple 
`app/.cfg` files and only a single `name>.id`? What will prevent people from creating their own .id files?
I don't like this solution, to be honest. Its only benefit is that it is 
simple. Can we instead put some data in `app/.cfg` 
file for the main launcher when building app image so that bundle 
packagers can read all .cfg files and find the one that corresponds to 
the main launcher and thus get application name?


- Alexey


[1] https://bugs.openjdk.java.net/browse/JDK-8230920
[2] http://cr.openjdk.java.net/~herrick/8230920


Thanks

Andy,

RFR: JDK-8230920: jpackage problems when -input dir contains any files with "cfg" extension.

[Andy Herrick]

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


On Windows  when building MSI, the original application name was 
determined by looking into the /app dir for a ".cfg" file.


The problem was that:

 - There may be application files with ".cfg" extension.

 - There may be multiple ".cfg" files due to --add-launcher option(s)

Instead we create an ".id" in the root of the 
app-image , to insure we can derive application name from app-image.


[1] https://bugs.openjdk.java.net/browse/JDK-8230920
[2] http://cr.openjdk.java.net/~herrick/8230920


Thanks

Andy,

Re: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c

[naoto . sato]

On 9/17/19 10:14 AM, Martin Buchholz wrote:



On Tue, Sep 17, 2019 at 9:45 AM > wrote:


+1

On 9/17/19 8:29 AM, Martin Buchholz wrote:
 > Looks good to me.
 > At Google we also integrated tzdata2019c, and it was uneventful
(good!).
 > But we're still using rearguard format.
 > The vanguard/rearguard distinction is a source of errors, so it
should be
 > made clear what format is being used to import the files.
 > If you have a script to update the jdk sources, perhaps it should be
 > checked in to openjdk?
 > If these files are in vanguard format, is there a trap for those
of us
 > doing backports to jdks that only support rearguard?

Can't think of any off the top of my head, Martin. The build tool


Which build tool? TzdbZoneRulesCompiler?


Yes.



internally converts vanguard data into rearguard compatible, by
adjusting the standard offsets, and build into tzdb.dat (which should
even be compatible to prior JDK runtimes).


So ... a change like this one is created by copying selected vanguard 
format files from the tzdata source distribution into openjdk, and 
then TzdbZoneRulesCompiler converts to rearguard format internally?  At 
Google, we chose to run tzdata's own tool to convert to rearguard format 
and then check in those data files into the jdk source tree.


The tool will not convert the file format to rearguard. Read the 
vanguard format file, then converts the data into tzdb.dat that can be 
recognized by prior runtimes.




I worry that when other engineers backport to older releases, if only 
the data files are copied, then conversion to rearguard format will not 
happen, with bad results.


If an engineer only backports the vanguard files into older releases 
(before the vanguard support), I don't think the JDK build will succeed. 
Build will fail on creating tzdb.dat file.


Naoto

Re: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c

[Martin Buchholz]

On Tue, Sep 17, 2019 at 9:45 AM  wrote:

> +1
>
> On 9/17/19 8:29 AM, Martin Buchholz wrote:
> > Looks good to me.
> > At Google we also integrated tzdata2019c, and it was uneventful (good!).
> > But we're still using rearguard format.
> > The vanguard/rearguard distinction is a source of errors, so it should be
> > made clear what format is being used to import the files.
> > If you have a script to update the jdk sources, perhaps it should be
> > checked in to openjdk?
> > If these files are in vanguard format, is there a trap for those of us
> > doing backports to jdks that only support rearguard?
>
> Can't think of any off the top of my head, Martin. The build tool
>

Which build tool? TzdbZoneRulesCompiler?


> internally converts vanguard data into rearguard compatible, by
> adjusting the standard offsets, and build into tzdb.dat (which should
> even be compatible to prior JDK runtimes).
>

So ... a change like this one is created by copying selected vanguard
format files from the tzdata source distribution into openjdk, and
then TzdbZoneRulesCompiler converts to rearguard format internally?  At
Google, we chose to run tzdata's own tool to convert to rearguard format
and then check in those data files into the jdk source tree.

I worry that when other engineers backport to older releases, if only the
data files are copied, then conversion to rearguard format will not
happen, with bad results.

Re: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c

[naoto . sato]

+1

On 9/17/19 8:29 AM, Martin Buchholz wrote:

Looks good to me.
At Google we also integrated tzdata2019c, and it was uneventful (good!).
But we're still using rearguard format.
The vanguard/rearguard distinction is a source of errors, so it should be
made clear what format is being used to import the files.
If you have a script to update the jdk sources, perhaps it should be
checked in to openjdk?
If these files are in vanguard format, is there a trap for those of us
doing backports to jdks that only support rearguard?


Can't think of any off the top of my head, Martin. The build tool 
internally converts vanguard data into rearguard compatible, by 
adjusting the standard offsets, and build into tzdb.dat (which should 
even be compatible to prior JDK runtimes).


Naoto



On Tue, Sep 17, 2019 at 1:19 AM Ramanand Patil 
wrote:


Hi all,
Please review the patch for tzdata2019c integration into jdk
project(jdk-14).
Webrev: http://cr.openjdk.java.net/~rpatil/8231098/14/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8231098

The patch has passed all the related testing including JCK.

Regards,
Ramanand.

Re: RFR: 8231124: Missing closedir call with JDK-8223490

[naoto . sato]

Looks good.

Naoto

On 9/17/19 9:27 AM, Seán Coffey wrote:
A minor issue that was introduced via my recent JDK-8223490 fix. One 
which I noticed while backporting the edits..


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

proposed patch:
diff --git a/src/java.base/unix/native/libjava/TimeZone_md.c 
b/src/java.base/unix/native/libjava/TimeZone_md.c

--- a/src/java.base/unix/native/libjava/TimeZone_md.c
+++ b/src/java.base/unix/native/libjava/TimeZone_md.c
@@ -130,11 +130,6 @@
  char *tz = NULL;
  int res;

-    dirp = opendir(dir);
-    if (dirp == NULL) {
-    return NULL;
-    }
-
  if (strcmp(dir, ZONEINFO_DIR) == 0) {
  /* fast path for 1st iteration */
  for (unsigned int i = 0; i < sizeof (popularZones) / sizeof 
(popularZones[0]); i++) {

@@ -151,6 +146,11 @@
  }
  }

+    dirp = opendir(dir);
+    if (dirp == NULL) {
+    return NULL;
+    }
+
  while ((dp = readdir(dirp)) != NULL) {
  /*
   * Skip '.' and '..' (and possibly other .* files)


==

regards,
Sean.

RFR: 8231124: Missing closedir call with JDK-8223490

[Seán Coffey]

A minor issue that was introduced via my recent JDK-8223490 fix. One 
which I noticed while backporting the edits..


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

proposed patch:
diff --git a/src/java.base/unix/native/libjava/TimeZone_md.c 
b/src/java.base/unix/native/libjava/TimeZone_md.c

--- a/src/java.base/unix/native/libjava/TimeZone_md.c
+++ b/src/java.base/unix/native/libjava/TimeZone_md.c
@@ -130,11 +130,6 @@
 char *tz = NULL;
 int res;

-    dirp = opendir(dir);
-    if (dirp == NULL) {
-    return NULL;
-    }
-
 if (strcmp(dir, ZONEINFO_DIR) == 0) {
 /* fast path for 1st iteration */
 for (unsigned int i = 0; i < sizeof (popularZones) / sizeof 
(popularZones[0]); i++) {

@@ -151,6 +146,11 @@
 }
 }

+    dirp = opendir(dir);
+    if (dirp == NULL) {
+    return NULL;
+    }
+
 while ((dp = readdir(dirp)) != NULL) {
 /*
  * Skip '.' and '..' (and possibly other .* files)


==

regards,
Sean.

Re: RFR [14/java.xml] 8230814: Enable SAX ContentHandler to handle XML Declaration

[Joe Wang]

On 9/17/19 3:00 AM, Alan Bateman wrote:

On 16/09/2019 19:25, Joe Wang wrote:

:

I deliberately left the javadoc in the SAX package as they are. But I 
agree it may be worth it to address this aspect of the document. I 
suggest we do so with a separate doc-only request[1] to clarify the 
relationship with the SAX project, likely adding a short note in the 
package description and removing all other references. If you are 
okay, I'll keep this changeset the way it is, limiting it to the new 
method.
A separate issue is fine but I think important to do it in the same 
release where the APIs diverge to avoid confusing the reader (by 
redirecting them to stale API docs).


Agree, will do it next while we all are here on the issue.

-Joe


-Alan

Re: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null.

[Thomas Stüfe]

Makes sense Goetz.

Cheers, Thomas

On Tue, Sep 17, 2019 at 11:23 AM Lindenmaier, Goetz <
goetz.lindenma...@sap.com> wrote:

> Hi Thomas,
>
> thanks for pointing this out.  I improved the placement
> of the ResourceMarks.
> Unfortunately, base() returns an immutable string, but
> for trim_well_known_class_names this does not work.
> So I'd propose this:
> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/17-incremental/
> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/17/
>
> Best regards,
>   Goetz.
>
> > -Original Message-
> > From: Thomas Stüfe 
> > Sent: Dienstag, 17. September 2019 09:06
> > To: Lindenmaier, Goetz 
> > Cc: Hotspot dev runtime ; Java
> Core
> > Libs 
> > Subject: Re: RFR (L, final): 8218626: Add detailed message to
> > NullPointerException describing what is null.
> >
> > Additionally, since 8224193, stringStream does not use RA anymore, so
> you do
> > not need ResourceMarks for the backing buffer. 8224193 has been
> backported
> > to 11, btw.
> >
> > On Mon, Sep 16, 2019 at 2:53 PM Thomas Stüfe  >  > wrote:
> >
> >
> >   Hi Goetz,
> >
> >   not a full review, just a small suggestion. In jvm.cpp you could
> just
> > access ss->base() instead of ss->as_string() since the internal buffer
> is already
> > NULL terminated and result_string does not outlive the stringStream
> object.
> > Also it misses including ostream.hpp.
> >
> >   Cheers, Thomas
> >
> >
> >   On Tue, Sep 10, 2019 at 4:46 PM Lindenmaier, Goetz
> > mailto:goetz.lindenma...@sap.com> > wrote:
> >
> >
> >   Hi,
> >
> >   the subject should mention 8218628. (Not 8218626).
> >   Sorry for this!
> >
> >   Best regards,
> > Goetz.
> >
> >   From: Lindenmaier, Goetz
> >   Sent: Dienstag, 10. September 2019 11:48
> >   To: 'Hotspot dev runtime'  > d...@openjdk.java.net  >;
> Java
> > Core Libs mailto:core-libs-
> > d...@openjdk.java.net> >
> >   Subject: RFR (L, final): 8218626: Add detailed message to
> > NullPointerException describing what is null.
> >
> >   Hi,
> >
> >   this is the implementation of JEP 358: Helpful
> > NullPointerExceptions.
> >
> >   The JEP is in status "Candidate". Coleen (many, many
> thanks!)
> > ran
> >   it through the Oracle-internal processes.  Now I please
> need
> > final reviews
> >   for this change so that I can propose it to target jdk 14.
> >
> >   JEP: https://bugs.openjdk.java.net/browse/JDK-8220715
> >   Enhancement: https://bugs.openjdk.java.net/browse/JDK-
> > 8218628
> >   webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-
> > exMsg-NPE/16/
> >
> >   The change ran through a lot of testing, all jtreg and jck
> tests to
> > name
> >   only some. The webrev points to patch
> >   http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-
> > NPE/16/enable_NPE_message.patch
> >   that enables the change by default,  which was useful for
> > testing to
> >   assure the code is used in the tests.
> >   I just pushed the change to jdk/submit once more.
> >
> >   Please review.
> >
> >   Thanks!
> > Goetz.
> >
>
>

Re: RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c

[Martin Buchholz]

Looks good to me.
At Google we also integrated tzdata2019c, and it was uneventful (good!).
But we're still using rearguard format.
The vanguard/rearguard distinction is a source of errors, so it should be
made clear what format is being used to import the files.
If you have a script to update the jdk sources, perhaps it should be
checked in to openjdk?
If these files are in vanguard format, is there a trap for those of us
doing backports to jdks that only support rearguard?

On Tue, Sep 17, 2019 at 1:19 AM Ramanand Patil 
wrote:

> Hi all,
> Please review the patch for tzdata2019c integration into jdk
> project(jdk-14).
> Webrev: http://cr.openjdk.java.net/~rpatil/8231098/14/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8231098
>
> The patch has passed all the related testing including JCK.
>
> Regards,
> Ramanand.
>

RE: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null.

[Lindenmaier, Goetz]

@core-libs experts, I would appreciate comments on the changes
to NullPointerException.java, especially wrt. the Javadoc comment.
The change there is S.

Best regards,
  Goetz.

> -Original Message-
> From: Lindenmaier, Goetz
> Sent: Dienstag, 10. September 2019 11:48
> To: 'Hotspot dev runtime' ; Java Core
> Libs 
> Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException
> describing what is null.
> 
> Hi,
> 
> 
> 
> this is the implementation of JEP 358: Helpful NullPointerExceptions.
> 
> 
> 
> The JEP is in status "Candidate". Coleen (many, many thanks!) ran
> 
> it through the Oracle-internal processes.  Now I please need final reviews
> 
> for this change so that I can propose it to target jdk 14.
> 
> 
> 
> JEP: https://bugs.openjdk.java.net/browse/JDK-8220715
> 
> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628
> 
> webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/
> 
> 
> 
> The change ran through a lot of testing, all jtreg and jck tests to name
> 
> only some. The webrev points to patch
> 
> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-
> NPE/16/enable_NPE_message.patch
> 
> that enables the change by default,  which was useful for testing to
> 
> assure the code is used in the tests.
> 
> I just pushed the change to jdk/submit once more.
> 
> 
> 
> Please review.
> 
> 
> 
> Thanks!
> 
>   Goetz.

Re: RFR(s): 8228580: DnsClient TCP socket timeout

[Pavel Rappo]

Milan,

While the CSR is being processed, could we maybe think of some additional 
testing for that change? Otherwise, that test seems kind of anemic. It makes 
sure that the query doesn't hang, but that's about it. It doesn't check that 
the timeout is respected. I was wondering if you could propose some way of 
testing that.

> On 17 Sep 2019, at 09:55, Pavel Rappo  wrote:
> 
> I have filed the CSR:
> 
>https://bugs.openjdk.java.net/browse/JDK-8230965
> 
>> On 13 Sep 2019, at 11:21, Pavel Rappo  wrote:
>> 
>> Here's the latest webrev accumulating all the changes we've discussed so far:
>> 
>>   http://cr.openjdk.java.net/~prappo/8228580/webrev.03/
>> 
>> If people are okay with that I will proceed to creating a CSR.

Re: Comments on jpackage (JEP 343)

[Kevin Rushforth]

Hi Phil,

In the app-image case it always creates a new directory with the name of 
the application underneath the dest/output directory for holding all of 
the files. So you either have:


   /appname.ext

or

   /appname/

So I think "." is a reasonable default if not specified.

As to whether to call it "--dest" or "--output", I don't have a strong 
opinion. There are precedents for both.


-- Kevin


On 9/16/2019 8:24 PM, Philip Race wrote:

> but I'd concede it to be "." as a default

On second thoughts I am not sure about that either.
I find it much cleaner to know what was generated by looking in a new 
directory rather than
hunting in my current directory, especially for the default app-image 
case which will dump

a bunch of unfamiliar files.

-phil.

On 9/16/19, 8:13 PM, Philip Race wrote:

I've been thinking about this.
output is nicely symmetrical with input and in the case of a default 
app-image it is more than a single item
and personally I'd much rather it not clutter my working directory 
and again you get symmetry with input
which you really want to specify  but I'd concede it to be "." as a 
default over changing the name to dest ...


There is also precedent :
jlink uses -output and these two tools are going to be frequently 
used together.


So I would like to see the status quo.

-phil.


On 9/3/19, 11:58 AM, mark.reinh...@oracle.com wrote:
   - The `--output`/`-o` option is confusing.  It doesn’t name the 
output
 itself, but rather a directory into which the single item of 
output
 will be placed.  Typing `-o .` all the time is just annoying.  
It’d
 be more logical to rename this option to `--dest`/`-d` and to 
make it

 optional, with a default value of `.`.

Re: RFR [14/java.xml] 8230814: Enable SAX ContentHandler to handle XML Declaration

[Alan Bateman]

On 16/09/2019 19:25, Joe Wang wrote:

:

I deliberately left the javadoc in the SAX package as they are. But I 
agree it may be worth it to address this aspect of the document. I 
suggest we do so with a separate doc-only request[1] to clarify the 
relationship with the SAX project, likely adding a short note in the 
package description and removing all other references. If you are 
okay, I'll keep this changeset the way it is, limiting it to the new 
method.
A separate issue is fine but I think important to do it in the same 
release where the APIs diverge to avoid confusing the reader (by 
redirecting them to stale API docs).


-Alan

RE: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null.

[Lindenmaier, Goetz]

Hi Thomas, 

thanks for pointing this out.  I improved the placement 
of the ResourceMarks. 
Unfortunately, base() returns an immutable string, but
for trim_well_known_class_names this does not work.
So I'd propose this: 
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/17-incremental/
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/17/

Best regards,
  Goetz.

> -Original Message-
> From: Thomas Stüfe 
> Sent: Dienstag, 17. September 2019 09:06
> To: Lindenmaier, Goetz 
> Cc: Hotspot dev runtime ; Java Core
> Libs 
> Subject: Re: RFR (L, final): 8218626: Add detailed message to
> NullPointerException describing what is null.
> 
> Additionally, since 8224193, stringStream does not use RA anymore, so you do
> not need ResourceMarks for the backing buffer. 8224193 has been backported
> to 11, btw.
> 
> On Mon, Sep 16, 2019 at 2:53 PM Thomas Stüfe   > wrote:
> 
> 
>   Hi Goetz,
> 
>   not a full review, just a small suggestion. In jvm.cpp you could just
> access ss->base() instead of ss->as_string() since the internal buffer is 
> already
> NULL terminated and result_string does not outlive the stringStream object.
> Also it misses including ostream.hpp.
> 
>   Cheers, Thomas
> 
> 
>   On Tue, Sep 10, 2019 at 4:46 PM Lindenmaier, Goetz
> mailto:goetz.lindenma...@sap.com> > wrote:
> 
> 
>   Hi,
> 
>   the subject should mention 8218628. (Not 8218626).
>   Sorry for this!
> 
>   Best regards,
> Goetz.
> 
>   From: Lindenmaier, Goetz
>   Sent: Dienstag, 10. September 2019 11:48
>   To: 'Hotspot dev runtime'  d...@openjdk.java.net  >; Java
> Core Libs mailto:core-libs-
> d...@openjdk.java.net> >
>   Subject: RFR (L, final): 8218626: Add detailed message to
> NullPointerException describing what is null.
> 
>   Hi,
> 
>   this is the implementation of JEP 358: Helpful
> NullPointerExceptions.
> 
>   The JEP is in status "Candidate". Coleen (many, many thanks!)
> ran
>   it through the Oracle-internal processes.  Now I please need
> final reviews
>   for this change so that I can propose it to target jdk 14.
> 
>   JEP: https://bugs.openjdk.java.net/browse/JDK-8220715
>   Enhancement: https://bugs.openjdk.java.net/browse/JDK-
> 8218628
>   webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-
> exMsg-NPE/16/
> 
>   The change ran through a lot of testing, all jtreg and jck 
> tests to
> name
>   only some. The webrev points to patch
>   http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-
> NPE/16/enable_NPE_message.patch
>   that enables the change by default,  which was useful for
> testing to
>   assure the code is used in the tests.
>   I just pushed the change to jdk/submit once more.
> 
>   Please review.
> 
>   Thanks!
> Goetz.
> 

Re: RFR(s): 8228580: DnsClient TCP socket timeout

[Pavel Rappo]

I have filed the CSR:

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

> On 13 Sep 2019, at 11:21, Pavel Rappo  wrote:
> 
> Here's the latest webrev accumulating all the changes we've discussed so far:
> 
>http://cr.openjdk.java.net/~prappo/8228580/webrev.03/
> 
> If people are okay with that I will proceed to creating a CSR.
> 
>> On 12 Sep 2019, at 20:06, Alan Bateman  wrote:
>> 
>> On 12/09/2019 12:41, Chris Hegarty wrote:
>>> Here is an initial attempt to document these timeout/retry properties. It’s 
>>> effectively the wording lifted from the tech notes [1], with “UDP” removed.
>> Thanks, this look and dropping the reference to "UDP" make sense.
>> 
>> One minor nit is that "are relevant to the DNS provider" might be better 
>> worded as "may be used when creating the initial context". This will fit 
>> nicely if/when someone adds a description to the @provides tag. At some 
>> point I hope the other properties can be used too but that is beyond the 
>> scope of JDK-8228580.
>> 
>> -Alan
> 

RE: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer types and string literal conversion warnings

[Langer, Christoph]

Hi Matthias,

this seems fine to me. The change in NetworkInterface.c is correct, too.

Best regards
Christoph

> -Original Message-
> From: core-libs-dev  On Behalf
> Of Baesken, Matthias
> Sent: Donnerstag, 25. Juli 2019 15:45
> To: Doerr, Martin ; 'hotspot-
> d...@openjdk.java.net' ; core-libs-
> d...@openjdk.java.net; net-...@openjdk.java.net
> Cc: 'ppc-aix-port-...@openjdk.java.net'  d...@openjdk.java.net>
> Subject: [CAUTION] RE: RFR: 8228482: fix xlc16/xlclang comparison of distinct
> pointer types and string literal conversion warnings
> 
> Thanks Martin .
> May I get a second review ?
> 
> Best regards, Matthias
> 
> 
> From: Doerr, Martin
> Sent: Mittwoch, 24. Juli 2019 12:14
> To: Baesken, Matthias ; 'hotspot-
> d...@openjdk.java.net' ; core-libs-
> d...@openjdk.java.net; net-...@openjdk.java.net
> Cc: 'ppc-aix-port-...@openjdk.java.net'  d...@openjdk.java.net>
> Subject: RE: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer
> types and string literal conversion warnings
> 
> Hi Matthias,
> 
> I wouldn’t say „looks good”, but I think it’s the right thing to do 😊
> The type casts look correct to fit to the AIX headers.
> 
> libodm_aix:
> Good. Maybe we should open a new issue for freeing what’s returned by
> odm_set_path and we could also remove the AIX 5 support.
> 
> NetworkInterface.c:
> Strange, but ok. Should be reviewed by somebody else in addition.
> 
> Other files:
> No comments.
> 
> Best regards,
> Martin
> 
> 
> From: ppc-aix-port-dev  boun...@openjdk.java.net boun...@openjdk.java.net>> On Behalf Of Baesken, Matthias
> Sent: Dienstag, 23. Juli 2019 17:15
> To: 'hotspot-...@openjdk.java.net'  d...@openjdk.java.net>; core-libs-
> d...@openjdk.java.net; net-
> d...@openjdk.java.net
> Cc: 'ppc-aix-port-...@openjdk.java.net'  d...@openjdk.java.net>
> Subject: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer types
> and string literal conversion warnings
> 
> Hello please review this patch .
> 
> It fixes a couple of  xlc16/xlclang warnings  , especially  comparison of 
> distinct
> pointer types and string literal conversion warnings  .
> 
> When building with xlc16/xlclang, we still have a couple of warnings that have
> to be fixed :
> warning: ISO C++11 does not allow conversion from string literal to 'char *' 
> [-
> Wwritable-strings]
> for example :
> /nightly/jdk/src/hotspot/os/aix/libodm_aix.cpp:81:18: warning: ISO C++11
> does not allow conversion from string literal to 'char *' [-Wwritable-strings]
>   odmWrapper odm("product", "/usr/lib/objrepos"); // could also use "lpp"
>  ^
> /nightly/jdk/src/hotspot/os/aix/libodm_aix.cpp:81:29: warning: ISO C++11
> does not allow conversion from string literal to 'char *' [-Wwritable-strings]
>   odmWrapper odm("product", "/usr/lib/objrepos"); // could also use "lpp"
> ^
> 
> warning: comparison of distinct pointer types, for example :
> 
> /nightly/jdk/src/java.desktop/aix/native/libawt/porting_aix.c:50:14:
> warning: comparison of distinct pointer types ('void *' and 'char *') [-
> Wcompare-distinct-pointer-types]
> addr < (((char*)p->ldinfo_textorg) + p->ldinfo_textsize)) {
>  ^ ~
> 
> 
> 
> Bug/webrev :
> 
> 
> https://bugs.openjdk.java.net/browse/JDK-8228482
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8228482.1/
> 
> 
> Thanks, Matthias
> 

Re: Comments on jpackage (JEP 343)

[Sverre Moe]

I have built many times with the new jpackage, but actually just now tried
to install the package built by it.

The new jpackage adds a lot of Requires to the built RPM package. We had
the same problem with the old javapackager. Its default RPM spec file had a
lot of Requires that made it difficult for us to install our package on
different Linux distributions. We circumvented this by packaging the
application image with the Gradle ospackage plugin for RPM and DEB packages.

Only the last one of these requires is actually in our RPM spec file
provided with --resource-dir.

I cannot even install the package on the system I built it, because it
cannot find libavcodec-ffmpeg.so.56
For OpenSUSE Leap 15.1, my Linux distribution there is no package that
provides the libavcodec-ffmpeg.

Are all these Requires actually necessary for running a JavaFX application
on Linux?
As mentioned we had packaged our JavaFX 8 application with Gradle ospackage
plugin without all these Requires, and it has worked fine on RPM Linux
distributions.

ld-linux-x86-64.so.2()(64bit)
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
libGL.so.1()(64bit)
libX11.so.6()(64bit)
libXext.so.6()(64bit)
libXi.so.6()(64bit)
libXrender.so.1()(64bit)
libXtst.so.6()(64bit)
libasound.so.2()(64bit)
libasound.so.2(ALSA_0.9)(64bit)
libasound.so.2(ALSA_0.9.0rc4)(64bit)
libavcodec-ffmpeg.so.56()(64bit)
libavcodec-ffmpeg.so.56(LIBAVCODEC_FFMPEG_56)(64bit)
libavcodec.so.54()(64bit)
libavcodec.so.54(LIBAVCODEC_54)(64bit)
libavcodec.so.56()(64bit)
libavcodec.so.56(LIBAVCODEC_56)(64bit)
libavcodec.so.57()(64bit)
libavcodec.so.57(LIBAVCODEC_57)(64bit)
libavformat-ffmpeg.so.56()(64bit)
libavformat-ffmpeg.so.56(LIBAVFORMAT_FFMPEG_56)(64bit)
libavformat.so.54()(64bit)
libavformat.so.54(LIBAVFORMAT_54)(64bit)
libavformat.so.56()(64bit)
libavformat.so.56(LIBAVFORMAT_56)(64bit)
libavformat.so.57()(64bit)
libavformat.so.57(LIBAVFORMAT_57)(64bit)
libawt.so()(64bit)
libawt_xawt.so()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.11)(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.15)(64bit)
libc.so.6(GLIBC_2.17)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.2)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.6)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libcairo.so.2()(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libfreetype.so()(64bit)
libfreetype.so.6()(64bit)
libgdk-3.so.0()(64bit)
libgdk-x11-2.0.so.0()(64bit)
libgdk_pixbuf-2.0.so.0()(64bit)
libgio-2.0.so.0()(64bit)
libglib-2.0.so.0()(64bit)
libgmodule-2.0.so.0()(64bit)
libgobject-2.0.so.0()(64bit)
libgstreamer-lite.so()(64bit)
libgthread-2.0.so.0()(64bit)
libgtk-3.so.0()(64bit)
libgtk-x11-2.0.so.0()(64bit)
libjava.so()(64bit)
libjli.so()(64bit)
libjvm.so()(64bit)
libjvm.so(SUNWprivate_1.1)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.15)(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libnet.so()(64bit)
libpango-1.0.so.0()(64bit)
libpangoft2-1.0.so.0()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libpthread.so.0(GLIBC_2.3.2)(64bit)
librt.so.1()(64bit)
librt.so.1(GLIBC_2.2.5)(64bit)
libverify.so()(64bit)
libz.so.1()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
rtld(GNU_HASH)
xdg-utils

RFR: 8231098: (tz) Upgrade time-zone data to tzdata2019c

[Ramanand Patil]

Hi all,
Please review the patch for tzdata2019c integration into jdk project(jdk-14).
Webrev: http://cr.openjdk.java.net/~rpatil/8231098/14/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8231098

The patch has passed all the related testing including JCK.

Regards,
Ramanand.

Re: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null.

[Thomas Stüfe]

Additionally, since 8224193, stringStream does not use RA anymore, so you
do not need ResourceMarks for the backing buffer. 8224193 has been
backported to 11, btw.

On Mon, Sep 16, 2019 at 2:53 PM Thomas Stüfe 
wrote:

> Hi Goetz,
>
> not a full review, just a small suggestion. In jvm.cpp you could just
> access ss->base() instead of ss->as_string() since the internal buffer is
> already NULL terminated and result_string does not outlive the stringStream
> object. Also it misses including ostream.hpp.
>
> Cheers, Thomas
>
> On Tue, Sep 10, 2019 at 4:46 PM Lindenmaier, Goetz <
> goetz.lindenma...@sap.com> wrote:
>
>> Hi,
>>
>> the subject should mention 8218628. (Not 8218626).
>> Sorry for this!
>>
>> Best regards,
>>   Goetz.
>>
>> From: Lindenmaier, Goetz
>> Sent: Dienstag, 10. September 2019 11:48
>> To: 'Hotspot dev runtime' ; Java
>> Core Libs 
>> Subject: RFR (L, final): 8218626: Add detailed message to
>> NullPointerException describing what is null.
>>
>> Hi,
>>
>> this is the implementation of JEP 358: Helpful NullPointerExceptions.
>>
>> The JEP is in status "Candidate". Coleen (many, many thanks!) ran
>> it through the Oracle-internal processes.  Now I please need final reviews
>> for this change so that I can propose it to target jdk 14.
>>
>> JEP: https://bugs.openjdk.java.net/browse/JDK-8220715
>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8218628
>> webrev: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/
>>
>> The change ran through a lot of testing, all jtreg and jck tests to name
>> only some. The webrev points to patch
>>
>> http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/16/enable_NPE_message.patch
>> that enables the change by default,  which was useful for testing to
>> assure the code is used in the tests.
>> I just pushed the change to jdk/submit once more.
>>
>> Please review.
>>
>> Thanks!
>>   Goetz.
>>
>