Re: Comments on jpackage (JEP 343)

[Alexey Semenyuk]

Sverre,

Thank you for your feedback. I've captured it in 
https://bugs.openjdk.java.net/browse/JDK-8230668.


- Alexey

On 9/25/2019 9:45 AM, Sverre Moe wrote:

I have some new comments regarding the Windows build of jpackage.

1)
Is there any way to build an trusted application installer using WiX?
I want to avoid "Unknown Publisher" when installing the application.
Also having problems with Windows Defender SmartScreen, depending on what
settings the user has (Block, Warn, Off).
If Block, the user cannot install the application. If Warn, the user can
click "More info", then "Run anyway".

2)
The EXE installer details has no information about the actual application
it will install.
File version: 14.0.0
Product Name OpenJDK Platform 14
Product version: 14
This is not quite right, since the application was built with Java 11, only
packaged with jpackage from Java 14.
Should it not use the name and app version supplied to jpackage on these
properties.

Original filename: msiwrapper.msi.
It should be the name supplied to jpackage used here at least >
applicationName.msi

Building an MSI has much better detail properties, but a couple of the
description properties says nothing about the actual application.
Title: Installation Database
Comments: This installer database contains the logic and data required to
install applicationName.
Any way to change the title and comments?

3)
The icon for the installer file is not using the one from the resource
directory. If supplied the --icon argument is not used.
Both Explorer and List of installed application shows a generic application
icon.

4)
MSI installer has a Category detail property. Perhaps jpackage should have
an --windows-category argument.

5)
Help text for --icon argument should mention that it needs to be an ICO
when packaging on Windows.

Currently there is no way to supply a custom WXS file to WiX in the
resource directory. Perhaps this could help further customization.

/Sverre



tor. 19. sep. 2019 kl. 20:29 skrev Kevin Rushforth <
kevin.rushfo...@oracle.com>:


OK, that makes sense. Andy has already implemented this change (pushed
it to the sandbox), so it will be in the next EA build.

-- Kevin

On 9/19/2019 10:25 AM, mark.reinh...@oracle.com wrote:

jlink’s -o/--output option names exactly the thing being output,
rather than a container for the thing being output.

The jpackage option we’re discussing here names a container for the
thing being output, much like the -d option of javac and javadoc.

Using -d/--dest for jpackage is consistent with the JDK’s other
command-line tools.

- Mark

Re: RFR: JDK-8231382: Use main class from main module if available

[Alexey Semenyuk]

Looks good.

- Alexey

On 9/25/2019 6:30 PM, Alexander Matveev 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).


- Main class from module will be used if main class is not specified 
in CLI. Main class from CLI will be preferred over main class 
specified in module attribute.


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

[2] http://cr.openjdk.java.net/~almatvee/8231382/webrev.00/

Thanks,
Alexander

Re: JEP proposed to target JDK 14: 358: Helpful NullPointerExceptions

[Jonathan Gibbons]

Typo "isnull" and/or font issue, in "The format of the null-detail message"

1.

   In a failed array access --|Cannot load from object array because
   'a[i][j]' is|null|.|-- the second part|'a[i][j]' is null.|suffices
   to pinpoint the|null|expression in source code,|a[i][j][k] = 99;|

-- Jon

On 9/25/19 3:22 PM, mark.reinh...@oracle.com wrote:

The following JEP is proposed to target JDK 14:

   358: Helpful NullPointerExceptions
https://openjdk.java.net/jeps/358

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:00 UTC on Wednesday, 2 October, or if they’re raised
and then satisfactorily answered, then per the JEP 2.0 process proposal
[2] I’ll target this JEP to JDK 14.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

RFR: JDK-8231382: Use main class from main module if available

[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).


- Main class from module will be used if main class is not specified in 
CLI. Main class from CLI will be preferred over main class specified in 
module attribute.


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

[2] http://cr.openjdk.java.net/~almatvee/8231382/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8230649 : Make jpackage tool an experimental feature

[Kevin Rushforth]

That seems fine then. Thanks.

-- Kevin


On 9/25/2019 8:29 AM, Andy Herrick wrote:

I can will remove the makefile change then.

The warning is going the same place as the help output (Log.info()) 
which is stdout unless a different stream is passed to ToolProvider.


So if we want a more detailed message in Help text we can either show 
the more detailed message in addition to the message shown in all 
cases, or specifically exclude the generic message in the Help case.


/Andy

On 9/25/19 11:18 AM, Kevin Rushforth wrote:



On 9/25/2019 7:44 AM, Alan Bateman wrote:

On 25/09/2019 15:33, 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).


These are the code changes to make jpackage an experimental feature.

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

[2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/
I assume the change to CreateJmods.gmk is not needed as the module 
will be resolved because it provides an implementation of ToolProvider.


I was going to point out the same thing as Alan. The rest looks good, 
although an explicit informational line in the --help message might 
be nice, in case log warnings are going somewhere else.


-- Kevin

Re: RFR: JDK-8230649 : Make jpackage tool an experimental feature

[Andy Herrick]

I can will remove the makefile change then.

The warning is going the same place as the help output (Log.info()) 
which is stdout unless a different stream is passed to ToolProvider.


So if we want a more detailed message in Help text we can either show 
the more detailed message in addition to the message shown in all cases, 
or specifically exclude the generic message in the Help case.


/Andy

On 9/25/19 11:18 AM, Kevin Rushforth wrote:



On 9/25/2019 7:44 AM, Alan Bateman wrote:

On 25/09/2019 15:33, 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).


These are the code changes to make jpackage an experimental feature.

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

[2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/
I assume the change to CreateJmods.gmk is not needed as the module 
will be resolved because it provides an implementation of ToolProvider.


I was going to point out the same thing as Alan. The rest looks good, 
although an explicit informational line in the --help message might be 
nice, in case log warnings are going somewhere else.


-- Kevin

Re: RFR: JDK-8230649 : Make jpackage tool an experimental feature

[Kevin Rushforth]

On 9/25/2019 7:44 AM, Alan Bateman wrote:

On 25/09/2019 15:33, 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).


These are the code changes to make jpackage an experimental feature.

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

[2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/
I assume the change to CreateJmods.gmk is not needed as the module 
will be resolved because it provides an implementation of ToolProvider.


I was going to point out the same thing as Alan. The rest looks good, 
although an explicit informational line in the --help message might be 
nice, in case log warnings are going somewhere else.


-- Kevin

Re: RFR: JDK-8230649 : Make jpackage tool an experimental feature

[Alan Bateman]

On 25/09/2019 15:33, 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).


These are the code changes to make jpackage an experimental feature.

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

[2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/
I assume the change to CreateJmods.gmk is not needed as the module will 
be resolved because it provides an implementation of ToolProvider.


-Alan

RFR: JDK-8230649 : Make jpackage tool an experimental feature

[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).


These are the code changes to make jpackage an experimental feature.

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

[2] http://cr.openjdk.java.net/~herrick/8230649/webrev.02/

/Andy

Re: Comments on jpackage (JEP 343)

[Sverre Moe]

I have some new comments regarding the Windows build of jpackage.

1)
Is there any way to build an trusted application installer using WiX?
I want to avoid "Unknown Publisher" when installing the application.
Also having problems with Windows Defender SmartScreen, depending on what
settings the user has (Block, Warn, Off).
If Block, the user cannot install the application. If Warn, the user can
click "More info", then "Run anyway".

2)
The EXE installer details has no information about the actual application
it will install.
File version: 14.0.0
Product Name OpenJDK Platform 14
Product version: 14
This is not quite right, since the application was built with Java 11, only
packaged with jpackage from Java 14.
Should it not use the name and app version supplied to jpackage on these
properties.

Original filename: msiwrapper.msi.
It should be the name supplied to jpackage used here at least >
applicationName.msi

Building an MSI has much better detail properties, but a couple of the
description properties says nothing about the actual application.
Title: Installation Database
Comments: This installer database contains the logic and data required to
install applicationName.
Any way to change the title and comments?

3)
The icon for the installer file is not using the one from the resource
directory. If supplied the --icon argument is not used.
Both Explorer and List of installed application shows a generic application
icon.

4)
MSI installer has a Category detail property. Perhaps jpackage should have
an --windows-category argument.

5)
Help text for --icon argument should mention that it needs to be an ICO
when packaging on Windows.

Currently there is no way to supply a custom WXS file to WiX in the
resource directory. Perhaps this could help further customization.

/Sverre



tor. 19. sep. 2019 kl. 20:29 skrev Kevin Rushforth <
kevin.rushfo...@oracle.com>:

> OK, that makes sense. Andy has already implemented this change (pushed
> it to the sandbox), so it will be in the next EA build.
>
> -- Kevin
>
> On 9/19/2019 10:25 AM, mark.reinh...@oracle.com wrote:
> > jlink’s -o/--output option names exactly the thing being output,
> > rather than a container for the thing being output.
> >
> > The jpackage option we’re discussing here names a container for the
> > thing being output, much like the -d option of javac and javadoc.
> >
> > Using -d/--dest for jpackage is consistent with the JDK’s other
> > command-line tools.
> >
> > - Mark
>
>

Re: JDK 14 RFR of JDK-8231442 : Suppress warnings on non-serializable instance fields in java.sql.* modules

[Lance Andersen]

Hi Joe,

Looks OK

SyncProviderException.java, SQLClientInfoException.java, StatementEvent.java 
should probably have the copyright notice updated to 2019 prior to pushing

Best
Lance

> On Sep 25, 2019, at 12:34 AM, Joe Darcy  wrote:
> 
> Hello,
> 
> Next step in the serialization warnings pre-cleanup is java.sql.* modules. 
> Please review the proposed changes:
> 
> JDK-8231442 : Suppress warnings on non-serializable instance fields in 
> java.sql.* modules
> http://cr.openjdk.java.net/~darcy/8231442.0/
> 
> Several of the writeObject methods do runtime checks on whether on not 
> objects pointed to by the fields in question are serializable. The fields 
> with this runtime check get a explanatory comment noting that different from 
> the usual comment.
> 
> Thanks,
> 
> -Joe
> 

 
  

 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: RandomAccess Interface and List Heirarchy

[Remi Forax]

Hi Cyrus,
as the javadoc says RandomAccess is a marker interface,
an interface used at runtime to indicate if the implementation provides a fast 
random access operation or not.

"marker interface" is the precursor of a runtime visible annotation.
RandomAccess was introduce in 1.4 while annotations were introduced later in 
1.5.

implementing RandomAccess is equivalent of adding a bit on all implementations 
of List,
so casting an instance to RandomAccess is not how you should using it.

More generally, the idea of the collection API is that instead of having a 
RandomAccessList, a MutableList, an ImmutableList, a RandomImmutableList, etc 
you have only one type java.util.List and if you want to know more either you 
do a instanceof check, or call a method that throws 
UnsuportedOperationException or use a method of the API that does the runtime 
checks for you, like by example List.copyOf().

that said, i believe we should deprecate LinkedList (and any other List 
implementation that doesn't implement RandomAccess) because there are too much 
code out there that suppose that list.get() is O(1).

Rémi

- Mail original -
> De: "Cyrus Vafadari" 
> À: "core-libs-dev" 
> Envoyé: Mercredi 25 Septembre 2019 05:19:49
> Objet: RandomAccess Interface and List Heirarchy

> Hello all,
> 
> *TLDR: Why doesn't RandomAccess interface extend List?*
> 
> I'm maintaining a framework that lets developers build plugins, and
> developers implement a `put(List thingList)` in their plugins.
> However, I want to guarantee to the implementer that their List will
> support RandomAccess. I see Java does support a syntax for declaring that
> the argument should implement both List and RandomAccess using the "&"
> operator, and I could declare my own interface that extends both, but I am
> surprised that RandomAccess itself does not extend List and appear in the
> List hierarchy. According to the docs, it only applies to List
> implementations anyway, and we use `instanceof` extensively in the code to
> bifurcate how we handle both cases. It seems more natural to me for
> RandomAccess to extend List, so that I can let my implementer know
> explicitly they can rely on RandomAccess.
> 
> I am happy to give more details on my scenario, and very excited to learn
> more why this decision was made, and if there is an aspect I am missing or
> if improvements could be made!
> 
> Best wishes,
> 
> Cyrus