subject:"Re\: jpackage current status"



> 
> now you can build runtime that has the tools like I do here:
> 
>> $JDK_HOME/bin/jlink --bind-services --output mods.runtime --add-modules 
>> me.mymodule --module-path '../input-mods/mods'
> (../input-mods/mods has my app in me.mymodule)
> 
> then in app you can find any of the tools by using 
> System.getProperty("java.home") and looking in "bin" subdir.
> 
> So in the app you can refer to any of the tools by their full path.
> 
> My proposed addition of --jlink-options jpackage option would only make the 
> first step unnecessary.
> 

Seems like this would work if users were aware they needed to build the path. I 
could of sworn though that there were occasions where I successfully just 
created and copied in commands. I was wondering if there were some way in the 
native launcher to have the bin directory included in the paths searched by the 
launched java task. Maybe not. I just thought this used to work.

Re: jpackage current status

2020-02-24 Thread Andy Herrick




On 2/24/2020 4:32 PM, Michael Hall wrote:



On Feb 24, 2020, at 2:59 PM, Kevin Rushforth  wrote:



On 2/24/2020 12:31 PM, Michael Hall wrote:

On Feb 24, 2020, at 1:48 PM, Michael Hall  wrote:




On Feb 24, 2020, at 1:15 PM, Kevin Rushforth  wrote:

Since your ToolProvider-based program doesn't explicitly require 
jdk.incubator.jpackage, it won't be in the module graph. It should work fine if 
you run with:

$ java --add-modules jdk.incubator.jpackage ...


I’m not understanding the module subtleties yet but yes that does work command 
line. Other than -add-modules into the runtime are there any special 
considerations for using it from an application?

Ah, the obvious. Same solution for application also works. I can 
programmatically invoke jpackage with this.

Good.


I am still wondering for the application embedded runtime exec not finding 
linked native commands if this is expected not to work or is considered an 
issue?


This remains a question for me. Should Runtime exec find the native commands 
included with an application embedded JRE? It currently doesn’t seem to on OS X.

Unless that JRE's bin directory is in your PATH, I wouldn't expect it to find 
it.


OK, ToolProvider seems like it would be a preferred api. But unless someone 
figures out how to get the bin directory searched I wouldn’t see any point in 
having native commands included ever.
Maybe the enhancement Andy mentioned for this a while back might address this?
A thought. I now have no need to.


now you can build runtime that has the tools like I do here:

$JDK_HOME/bin/jlink --bind-services --output mods.runtime 
--add-modules me.mymodule --module-path '../input-mods/mods'

(../input-mods/mods has my app in me.mymodule)

then in app you can find any of the tools by using 
System.getProperty("java.home") and looking in "bin" subdir.


So in the app you can refer to any of the tools by their full path.

My proposed addition of --jlink-options jpackage option would only make 
the first step unnecessary.


/Andy

Re: jpackage current status




> On Feb 24, 2020, at 2:59 PM, Kevin Rushforth  
> wrote:
> 
> 
> 
> On 2/24/2020 12:31 PM, Michael Hall wrote:
>> 
>>> On Feb 24, 2020, at 1:48 PM, Michael Hall  wrote:
>>> 
>>> 
>>> 
 On Feb 24, 2020, at 1:15 PM, Kevin Rushforth  
 wrote:
 
 Since your ToolProvider-based program doesn't explicitly require 
 jdk.incubator.jpackage, it won't be in the module graph. It should work 
 fine if you run with:
 
 $ java --add-modules jdk.incubator.jpackage ...
 
>>> I’m not understanding the module subtleties yet but yes that does work 
>>> command line. Other than -add-modules into the runtime are there any 
>>> special considerations for using it from an application?
>> Ah, the obvious. Same solution for application also works. I can 
>> programmatically invoke jpackage with this.
> 
> Good.
> 
>>> I am still wondering for the application embedded runtime exec not finding 
>>> linked native commands if this is expected not to work or is considered an 
>>> issue?
>>> 
>> This remains a question for me. Should Runtime exec find the native commands 
>> included with an application embedded JRE? It currently doesn’t seem to on 
>> OS X.
> 
> Unless that JRE's bin directory is in your PATH, I wouldn't expect it to find 
> it.
> 
OK, ToolProvider seems like it would be a preferred api. But unless someone 
figures out how to get the bin directory searched I wouldn’t see any point in 
having native commands included ever. 
Maybe the enhancement Andy mentioned for this a while back might address this?
A thought. I now have no need to.

Re: jpackage current status

2020-02-24 Thread Bernd Eckenfels

Hello Michael,

Currently the native binaries (java launcher) are not included. If you want to 
do that, you need to generate the jlink image first (what you need to do anyway 
if you want a specific version).

This is kind of by design, but it looks like if this can be configured in 
future versions.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von 
Michael Hall 
Gesendet: Montag, Februar 24, 2020 9:33 PM
An: Kevin Rushforth
Cc: core-libs-dev
Betreff: Re: jpackage current status

> On Feb 24, 2020, at 1:48 PM, Michael Hall  wrote:
>
>
>
>> On Feb 24, 2020, at 1:15 PM, Kevin Rushforth  
>> wrote:
>>
>> Since your ToolProvider-based program doesn't explicitly require 
>> jdk.incubator.jpackage, it won't be in the module graph. It should work fine 
>> if you run with:
>>
>> $ java --add-modules jdk.incubator.jpackage ...
>>
>
> I’m not understanding the module subtleties yet but yes that does work 
> command line. Other than -add-modules into the runtime are there any special 
> considerations for using it from an application?

Ah, the obvious. Same solution for application also works. I can 
programmatically invoke jpackage with this.

>
> I am still wondering for the application embedded runtime exec not finding 
> linked native commands if this is expected not to work or is considered an 
> issue?
>

This remains a question for me. Should Runtime exec find the native commands 
included with an application embedded JRE? It currently doesn’t seem to on OS X.

Re: jpackage current status

2020-02-24 Thread Kevin Rushforth





On 2/24/2020 12:31 PM, Michael Hall wrote:



On Feb 24, 2020, at 1:48 PM, Michael Hall  wrote:




On Feb 24, 2020, at 1:15 PM, Kevin Rushforth  wrote:

Since your ToolProvider-based program doesn't explicitly require 
jdk.incubator.jpackage, it won't be in the module graph. It should work fine if 
you run with:

$ java --add-modules jdk.incubator.jpackage ...


I’m not understanding the module subtleties yet but yes that does work command 
line. Other than -add-modules into the runtime are there any special 
considerations for using it from an application?

Ah, the obvious. Same solution for application also works. I can 
programmatically invoke jpackage with this.


Good.


I am still wondering for the application embedded runtime exec not finding 
linked native commands if this is expected not to work or is considered an 
issue?


This remains a question for me. Should Runtime exec find the native commands 
included with an application embedded JRE? It currently doesn’t seem to on OS X.


Unless that JRE's bin directory is in your PATH, I wouldn't expect it to 
find it.


-- Kevin

Re: jpackage current status




> On Feb 24, 2020, at 1:48 PM, Michael Hall  wrote:
> 
> 
> 
>> On Feb 24, 2020, at 1:15 PM, Kevin Rushforth  
>> wrote:
>> 
>> Since your ToolProvider-based program doesn't explicitly require 
>> jdk.incubator.jpackage, it won't be in the module graph. It should work fine 
>> if you run with:
>> 
>> $ java --add-modules jdk.incubator.jpackage ...
>> 
> 
> I’m not understanding the module subtleties yet but yes that does work 
> command line. Other than -add-modules into the runtime are there any special 
> considerations for using it from an application?

Ah, the obvious. Same solution for application also works. I can 
programmatically invoke jpackage with this. 

> 
> I am still wondering for the application embedded runtime exec not finding 
> linked native commands if this is expected not to work or is considered an 
> issue?
> 

This remains a question for me. Should Runtime exec find the native commands 
included with an application embedded JRE? It currently doesn’t seem to on OS X.

Re: jpackage current status

> On Feb 24, 2020, at 1:15 PM, Kevin Rushforth  
> wrote:
> 
> Since your ToolProvider-based program doesn't explicitly require 
> jdk.incubator.jpackage, it won't be in the module graph. It should work fine 
> if you run with:
> 
> $ java --add-modules jdk.incubator.jpackage ...
> 

I’m not understanding the module subtleties yet but yes that does work command 
line. Other than -add-modules into the runtime are there any special 
considerations for using it from an application?

I am still wondering for the application embedded runtime exec not finding 
linked native commands if this is expected not to work or is considered an 
issue?

Thanks for the command line solution.

Re: jpackage current status

2020-02-24 Thread Kevin Rushforth

Since your ToolProvider-based program doesn't explicitly require 
jdk.incubator.jpackage, it won't be in the module graph. It should work 
fine if you run with:


$ java --add-modules jdk.incubator.jpackage ...

-- Kevin


On 2/24/2020 8:23 AM, Michael Hall wrote:



On Feb 22, 2020, at 7:02 PM, Michael Hall > wrote:


Currently, at least for Runtime exec including the commands with the 
application does no good.


Just to check would this be known expected behavior?
Or a known issue?
Or something that should have a bug report filed against it?

I additionally looked at using ToolProvider with jpackage as it is 
indicated to support that but it does not appear to work either at 
this time.
This can be verified independently of my application. I’m not real 
familiar but based on a googled example.


import java.util.spi.ToolProvider;


public class ToolProviderTest {

public static void main(String[] args) {
ToolProvider tool = ToolProvider.findFirst(args[0])
.orElseThrow(() -> new IllegalStateException("can not find tool " + 
args[0]));

System.out.println("tool " + tool);
}

}

(base) Michaels-MBP:~ mjh$ java -cp . ToolProviderTest jlink
tool jdk.tools.jlink.internal.Main$JlinkToolProvider@1f32e575
(base) Michaels-MBP:~ mjh$ java -cp . ToolProviderTest jar
tool sun.tools.jar.JarToolProvider@2a84aee7
(base) Michaels-MBP:~ mjh$ java -cp . ToolProviderTest jpackage
Exception in thread "main" java.lang.IllegalStateException: can not 
find tool jpackage

at ToolProviderTest.lambda$main$0(ToolProviderTest.java:8)
at java.base/java.util.Optional.orElseThrow(Optional.java:401)
at ToolProviderTest.main(ToolProviderTest.java:8)
(base) Michaels-MBP:~ mjh$ java --list-modules | grep jpackage
jdk.incubator.jpackage@14

Probably due to jpackage incubator status? But for now programmatic 
testing of jpackage does not seem possible.

Re: jpackage current status




> On Feb 24, 2020, at 11:16 AM, Michael Hall  wrote:
> 
> 
> 
>> On Feb 24, 2020, at 11:12 AM, Andy Herrick > > wrote:
>> 
>> We have no problem invoking jpackage through the tool provider interface in 
>> all of our test cases.
>> 
>> In previous emails you described using a hybrid jdk13/jdk14 jdk. Can you 
>> explain what exactly you are using ?
>> 
>> /Andy
> 
> I was wondering what you had for tests. 
> Currently I have the latest ea or release candidate installed. I temporarily 
> had a jdk13 installed due to issues with Eclipse when I switched to that. 
> 
> java -version
> openjdk version "14" 2020-03-17
> OpenJDK Runtime Environment (build 14+36-1461)
> OpenJDK 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)

Mac OS 10.14.6
On OS X you install the JDK by adding it to the JavaVirtualMachines directory. 

ls -l /Library/Java/JavaVirtualMachines
total 0
drwxr-xr-x  3 mjh  wheel   96 Dec 14  2018 jdk-11.0.1.jdk
drwxr-xr-x  4 mjh  wheel  128 Dec 15  2018 jdk-12.jdk
drwxr-xr-x@ 3 mjh  wheel   96 Apr 19  2019 jdk-13.jdk
drwxr-xr-x@ 3 mjh  staff   96 Feb  6 15:49 jdk-14.jdk
drwxr-xr-x  3 mjh  wheel   96 Sep 22  2017 jdk-9.jdk
drwxr-xr-x  3 mjh  wheel   96 May 16  2017 jdk1.8.0_131.jdk


Eclipse is now configured to use the jdk-13
Default should be the latest, now the jdk-14.

/usr/libexec/java_home
/Library/Java/JavaVirtualMachines/jdk-14.jdk/Contents/Home

Re: jpackage current status




> On Feb 24, 2020, at 11:12 AM, Andy Herrick  wrote:
> 
> We have no problem invoking jpackage through the tool provider interface in 
> all of our test cases.
> 
> In previous emails you described using a hybrid jdk13/jdk14 jdk. Can you 
> explain what exactly you are using ?
> 
> /Andy

I was wondering what you had for tests. 
Currently I have the latest ea or release candidate installed. I temporarily 
had a jdk13 installed due to issues with Eclipse when I switched to that. 

java -version
openjdk version "14" 2020-03-17
OpenJDK Runtime Environment (build 14+36-1461)
OpenJDK 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)

Re: jpackage current status




> On Feb 22, 2020, at 12:04 PM, Michael Hall  wrote:
> 
> 
> 
>> On Feb 22, 2020, at 11:10 AM, Michael Hall > > wrote:
>> 
>> 
>> 
>>> On Feb 22, 2020, at 10:14 AM, Tom Schindl >> > wrote:
>>> 
>>> At Eclipse it is tracked as 
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559482 
>>> 
>> Thanks.
>> Not quite sure what would of triggered it yesterday.
>> 
> 
> OK. So I think what the deal was is that the jpackage development branch, 
> that I’ve been using for some time, dodged the bullet on this bug. It picked 
> it up when it merged in with the main stream. And I picked it up when I 
> installed that. 
> 
> Unfortunately I didn’t save a prior jdk14 jpackage jre. So to launch Eclipse 
> I had to remove all JDK 14 JRE’s. Then Eclipse wanted a jdk14. So I renamed 
> an old jdk13 jpackage one to jdk14. Eclipse than launched. 
> To make this a little easier to work with I changed the default installed jre 
> to jdk-13, the eclipse.ini vm to jdk-13 and renamed the jpackage one back to 
> jdk-13.jdk. 
> I think now I should be able to re-install a jdk14 to test that and current 
> jpackage. Just for now eclipse will use a slightly older, jpackage specific, 
> one.
> 
My current understanding is this. Including native commands with an OS X 
application with an embedded JRE does not work at all for current 
applications/JRE’s.

I’m not sure what the application problem with jlink was last night but it is 
working tonight. From the earlier problems with Eclipse I still had jdk14 
removed from JavaVirtualMachines. The version command started indicating jdk13. 
I put 14 back in and built a current jpackage application with a jlink commands 
included runtime. 
I then again removed jdk14 from JavaVirtualMachines.

exec java -version
openjdk version "13-internal" 2019-09-17
OpenJDK Runtime Environment (build 13-internal+0-jdk13-jpackage.49)
OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-jpackage.49, mixed mode, 
sharing)
versions
System.in:3:java.version=14
System.in:5:java.version.date=2020-03-17
System.in:15:java.class.version=58.0
System.in:16:java.vm.specification.version=14
System.in:19:java.vm.version=14+36-1461
System.in:22:java.runtime.version=14+36-1461
System.in:25:java.specification.version=14

It only finds the command in the JavaVirtualMachines 13 runtime. Not the 
application included 14 one. 
It only works if the OS has a correct link in place

exec which java
/usr/bin/java
exec ls -l /usr/bin/java
lrwxr-xr-x  1 root  wheel  74 Mar 19  2019 /usr/bin/java -> 
/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java

It does not work for jlink or jpackage because no such link exists.

Currently, at least for Runtime exec including the commands with the 
application does no good.

Re: jpackage current status

> On Feb 22, 2020, at 11:10 AM, Michael Hall  wrote:
> 
> 
> 
>> On Feb 22, 2020, at 10:14 AM, Tom Schindl > > wrote:
>> 
>> At Eclipse it is tracked as 
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559482 
>> 
> Thanks.
> Not quite sure what would of triggered it yesterday.
> 

OK. So I think what the deal was is that the jpackage development branch, that 
I’ve been using for some time, dodged the bullet on this bug. It picked it up 
when it merged in with the main stream. And I picked it up when I installed 
that. 

Unfortunately I didn’t save a prior jdk14 jpackage jre. So to launch Eclipse I 
had to remove all JDK 14 JRE’s. Then Eclipse wanted a jdk14. So I renamed an 
old jdk13 jpackage one to jdk14. Eclipse than launched. 
To make this a little easier to work with I changed the default installed jre 
to jdk-13, the eclipse.ini vm to jdk-13 and renamed the jpackage one back to 
jdk-13.jdk. 
I think now I should be able to re-install a jdk14 to test that and current 
jpackage. Just for now eclipse will use a slightly older, jpackage specific, 
one.

Re: jpackage current status




> On Feb 22, 2020, at 10:14 AM, Tom Schindl  wrote:
> 
> At Eclipse it is tracked as 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559482 
> 
Thanks.
Not quite sure what would of triggered it yesterday.

Re: jpackage current status

2020-02-22 Thread Tom Schindl

At Eclipse it is tracked as https://bugs.eclipse.org/bugs/show_bug.cgi?id=559482

Tom

Von meinem iPhone gesendet

> Am 22.02.2020 um 16:39 schrieb Kevin Rushforth :
> 
> The Failure to GetJREPath is due to JDK-8238225 [1]. Eclipse was 
> specifically mentioned as being affected by this. It is already fixed in JDK 
> 15.
> 
> -- Kevin
> 
> https://bugs.openjdk.java.net/browse/JDK-8238225
> 
> 
>> On 2/22/2020 7:32 AM, Michael Hall wrote:
>> 
>> 
 On Feb 21, 2020, at 11:18 AM, Michael Hall >>> > wrote:
>>> 
>>> 
>>> 
 On Feb 21, 2020, at 11:12 AM, Kevin Rushforth >>> > wrote:
 
 I doubt this has anything to do with jpackage being in incubator or not. 
 Fundamentally, just copying binary launchers into another JDK image like 
 you are doing is only going to work by accident, if it works at all. If 
 you need jpackage (or javac or jar or ...) to be in a JDK image, then you 
 should jlink it yourself, include all of the modules you need, and don't 
 strip the executables.
 
 -- Kevin
 
>>> 
>>> I was doing that for applications going back to before jlink - application 
>>> build tools have not handled this real consistently and often just strip. 
>>> Possibly now you are correct. jpackage does use jlink though? So why would 
>>> my own be better than what the tool does? I believe I showed the module is 
>>> present in the runtime in use.
>>> But again doing jlink separately might in this instance be the best 
>>> practice. I will try it.
>> 
>> Well this went a little wrong and is sort of getting messed up.
>> I tried a jlink jre. The app froze (OS X) and had to be force quit.
>> Left it at that for the time being.
>> This morning Eclipse won’t start.
>> 
>> Double clicking the app executable shows…
>> 
>> /Users/mjh/java-2019-06/Eclipse.app/Contents/MacOS/eclipse ; exit;
>> Error: could not find libjava.dylib
>> Failed to GetJREPath()
>> 
>> I tried falling back to the previous ea.
>> java -version
>> openjdk version "14-ea" 2020-03-17
>> 
>> But same thing.
>> 
>> Some searching seems to be showing this as the problem here…
>> https://bugs.openjdk.java.net/browse/JDK-8213362
>> For both versions. Current and earlier ea libjli.dylib appears to be both in 
>> the lib and MacOS directories.
>> 
>> I will probably try reinstalling Eclipse with the earlier ea in 
>> JavaVirtualMachines. A setup that had been working.
>> 
>> Just to mention something else a little off that needs working around 
>> although I don’t think it should mess anything up. Some of these commands 
>> are still not default available on OS X. No jpackage of course, but no jlink 
>> either. jdeps is there but I don’t remember if I added a link myself or not 
>> there.
>> 
>> For jpackage and jlink I do this…
>> 
>> PACKAGER=`/usr/libexec/java_home`/bin/jpackage
>> 
>> ${PACKAGER} \
>> --input ../HalfPipe12.app/Contents/Java \
>> --icon GenericApp.icns \
>> 
>> The entire jlink is…
>> LINKER=`/usr/libexec/java_home`/bin/jlink
>> 
>> ${LINKER}  --strip-debug --no-header-files --no-man-pages \
>>  --bind-services \
>>  --add-modules 
>> java.compiler,java.desktop,java.logging,java.management,java.prefs,java.se 
>> ,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell,jdk.crypto.ec,jdk.incubator.jpackage
>>  \
>>  --output runtime
>> 
>> Trying to follow the defaults indicated for jpackage.
>> 
>> 
>

Re: jpackage current status

2020-02-22 Thread Kevin Rushforth

The Failure to GetJREPath is due to JDK-8238225 [1]. Eclipse was
specifically mentioned as being affected by this. It is already fixed in
JDK 15.

-- Kevin

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

On 2/22/2020 7:32 AM, Michael Hall wrote:

On Feb 21, 2020, at 11:18 AM, Michael Hall > wrote:

On Feb 21, 2020, at 11:12 AM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:

I doubt this has anything to do with jpackage being in incubator or
not. Fundamentally, just copying binary launchers into another JDK
image like you are doing is only going to work by accident, if it
works at all. If you need jpackage (or javac or jar or ...) to be in
a JDK image, then you should jlink it yourself, include all of the
modules you need, and don't strip the executables.

-- Kevin

I was doing that for applications going back to before jlink -
application build tools have not handled this real consistently and
often just strip. Possibly now you are correct. jpackage does use
jlink though? So why would my own be better than what the tool does?
I believe I showed the module is present in the runtime in use.
But again doing jlink separately might in this instance be the best
practice. I will try it.

Well this went a little wrong and is sort of getting messed up.
I tried a jlink jre. The app froze (OS X) and had to be force quit.
Left it at that for the time being.
This morning Eclipse won’t start.

Double clicking the app executable shows…

/Users/mjh/java-2019-06/Eclipse.app/Contents/MacOS/eclipse ; exit;
Error: could not find libjava.dylib
Failed to GetJREPath()

I tried falling back to the previous ea.
java -version
openjdk version "14-ea" 2020-03-17

But same thing.

Some searching seems to be showing this as the problem here…
https://bugs.openjdk.java.net/browse/JDK-8213362
For both versions. Current and earlier ea libjli.dylib appears to be
both in the lib and MacOS directories.

I will probably try reinstalling Eclipse with the earlier ea in
JavaVirtualMachines. A setup that had been working.

Just to mention something else a little off that needs working around
although I don’t think it should mess anything up. Some of these
commands are still not default available on OS X. No jpackage of
course, but no jlink either. jdeps is there but I don’t remember if I
added a link myself or not there.

For jpackage and jlink I do this…

PACKAGER=`/usr/libexec/java_home`/bin/jpackage

${PACKAGER} \
--input ../HalfPipe12.app/Contents/Java \
--icon GenericApp.icns \

The entire jlink is…
LINKER=`/usr/libexec/java_home`/bin/jlink

${LINKER} --strip-debug --no-header-files --no-man-pages \
--bind-services \
--add-modules java.compiler,java.desktop,java.logging,java.management,java.prefs,java.se
,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell,jdk.crypto.ec,jdk.incubator.jpackage
\

--output runtime

Trying to follow the defaults indicated for jpackage.

Re: jpackage current status

> On Feb 21, 2020, at 11:18 AM, Michael Hall  wrote:
> 
> 
> 
>> On Feb 21, 2020, at 11:12 AM, Kevin Rushforth  
>> wrote:
>> 
>> I doubt this has anything to do with jpackage being in incubator or not. 
>> Fundamentally, just copying binary launchers into another JDK image like you 
>> are doing is only going to work by accident, if it works at all. If you need 
>> jpackage (or javac or jar or ...) to be in a JDK image, then you should 
>> jlink it yourself, include all of the modules you need, and don't strip the 
>> executables.
>> 
>> -- Kevin
>> 
> 
> I was doing that for applications going back to before jlink - application 
> build tools have not handled this real consistently and often just strip. 
> Possibly now you are correct. jpackage does use jlink though? So why would my 
> own be better than what the tool does? I believe I showed the module is 
> present in the runtime in use. 
> But again doing jlink separately might in this instance be the best practice. 
> I will try it.

Well this went a little wrong and is sort of getting messed up.
I tried a jlink jre. The app froze (OS X) and had to be force quit.
Left it at that for the time being.
This morning Eclipse won’t start.

Double clicking the app executable shows…

/Users/mjh/java-2019-06/Eclipse.app/Contents/MacOS/eclipse ; exit;
Error: could not find libjava.dylib
Failed to GetJREPath()

I tried falling back to the previous ea. 
java -version
openjdk version "14-ea" 2020-03-17

But same thing.

Some searching seems to be showing this as the problem here…
https://bugs.openjdk.java.net/browse/JDK-8213362 

For both versions. Current and earlier ea libjli.dylib appears to be both in 
the lib and MacOS directories.

I will probably try reinstalling Eclipse with the earlier ea in 
JavaVirtualMachines. A setup that had been working.

Just to mention something else a little off that needs working around although 
I don’t think it should mess anything up. Some of these commands are still not 
default available on OS X. No jpackage of course, but no jlink either. jdeps is 
there but I don’t remember if I added a link myself or not there. 

For jpackage and jlink I do this…

PACKAGER=`/usr/libexec/java_home`/bin/jpackage

${PACKAGER} \
--input ../HalfPipe12.app/Contents/Java \
--icon GenericApp.icns \   

The entire jlink is…
LINKER=`/usr/libexec/java_home`/bin/jlink

${LINKER}  --strip-debug --no-header-files --no-man-pages \
   --bind-services \
   --add-modules 
java.compiler,java.desktop,java.logging,java.management,java.prefs,java.se,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell,jdk.crypto.ec,jdk.incubator.jpackage
 \
   --output runtime

Trying to follow the defaults indicated for jpackage.

Re: jpackage current status

> On Feb 21, 2020, at 11:12 AM, Kevin Rushforth  
> wrote:
> 
> I doubt this has anything to do with jpackage being in incubator or not. 
> Fundamentally, just copying binary launchers into another JDK image like you 
> are doing is only going to work by accident, if it works at all. If you need 
> jpackage (or javac or jar or ...) to be in a JDK image, then you should jlink 
> it yourself, include all of the modules you need, and don't strip the 
> executables.
> 
> -- Kevin
> 

I was doing that for applications going back to before jlink - application 
build tools have not handled this real consistently and often just strip. 
Possibly now you are correct. jpackage does use jlink though? So why would my 
own be better than what the tool does? I believe I showed the module is present 
in the runtime in use. 
But again doing jlink separately might in this instance be the best practice. I 
will try it.

Re: jpackage current status

2020-02-21 Thread Kevin Rushforth

I doubt this has anything to do with jpackage being in incubator or not. 
Fundamentally, just copying binary launchers into another JDK image like 
you are doing is only going to work by accident, if it works at all. If 
you need jpackage (or javac or jar or ...) to be in a JDK image, then 
you should jlink it yourself, include all of the modules you need, and 
don't strip the executables.


-- Kevin


On 2/21/2020 9:04 AM, Michael Hall wrote:



On Feb 21, 2020, at 9:39 AM, Michael Hall  wrote:


You can't copy launchers in this way as it requires the module to be in the 
run-time image.

If I add modules it into the build runtime I think I’m ok but haven’t tried it 
yet.

jpackage seems to need more than just the module in the run-time image.
I did the jpackage build again including it in the --add-modules

This now shows it there…

exec java --list-modules | grep jpackage
System.in:35:jdk.incubator.jpackage@14

However, I still get this…

exec jpackage --version
java.io.IOException: Cannot run program "jpackage": error=2, No such file or 
directory
at java.base/java.lang.ProcessBuilder.start(Unknown Source)
at java.base/java.lang.ProcessBuilder.start(Unknown Source)

Running it directly now works…

./jpackage --version
WARNING: Using incubator modules: jdk.incubator.jpackage
14

Which I think again shows the module is included in the run-time image.

Possibly there is some other dependency. I’ll have to figure that out or wait 
until jpackage is out of incubator.

Re: jpackage current status

> On Feb 21, 2020, at 9:39 AM, Michael Hall  wrote:
> 
>> You can't copy launchers in this way as it requires the module to be in the 
>> run-time image.
> 
> If I add modules it into the build runtime I think I’m ok but haven’t tried 
> it yet.

jpackage seems to need more than just the module in the run-time image. 
I did the jpackage build again including it in the --add-modules

This now shows it there…

exec java --list-modules | grep jpackage
System.in:35:jdk.incubator.jpackage@14

However, I still get this…

exec jpackage --version
java.io.IOException: Cannot run program "jpackage": error=2, No such file or 
directory
at java.base/java.lang.ProcessBuilder.start(Unknown Source)
at java.base/java.lang.ProcessBuilder.start(Unknown Source)

Running it directly now works…

./jpackage --version
WARNING: Using incubator modules: jdk.incubator.jpackage
14

Which I think again shows the module is included in the run-time image.

Possibly there is some other dependency. I’ll have to figure that out or wait 
until jpackage is out of incubator.

Re: jpackage current status




> On Feb 21, 2020, at 9:41 AM, Michael Hall  wrote:
> 
> 
> 
>> On Feb 21, 2020, at 9:39 AM, Philip Race  wrote:
>> 
>> Hi,
>> 
>> I don't understand what you are doing here.
>> It is like you are copying around an application
>> which has dependent libraries but not copying those libraries.
>> 
>> Copying bits out of the JDK to some other location isn't something you can 
>> expect to work.
> 
> It has worked for me in the past for the java command when applications need 
> that and the build has not included it.
> 
>> 
>> And why does your application need jpackage ?
>> It is a developer tool, not a run time tool ?
>> 
> 
> It runs commands. I am considering a jpackage wrapper command. Possibly 
> including some use of jlink.
> 

For example…

exec java -version
openjdk version "14" 2020-03-17
OpenJDK Runtime Environment (build 14+36-1461)
OpenJDK 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)

exec jshell -version
jshell 14


However,

exec jpackage --help
java.io.IOException: Cannot run program "jpackage": error=2, No such file or 
directory
at java.base/java.lang.ProcessBuilder.start(Unknown Source)
at java.base/java.lang.ProcessBuilder.start(Unknown Source)
at java.base/java.lang.Runtime.exec(Unknown Source)
...

Re: jpackage current status

> On Feb 21, 2020, at 9:39 AM, Philip Race  wrote:
> 
> Hi,
> 
> I don't understand what you are doing here.
> It is like you are copying around an application
> which has dependent libraries but not copying those libraries.
> 
> Copying bits out of the JDK to some other location isn't something you can 
> expect to work.

It has worked for me in the past for the java command when applications need 
that and the build has not included it.

> 
> And why does your application need jpackage ?
> It is a developer tool, not a run time tool ?
> 

It runs commands. I am considering a jpackage wrapper command. Possibly 
including some use of jlink.

Re: jpackage current status




> On Feb 21, 2020, at 9:36 AM, Alan Bateman  wrote:
> 
> 
> 
> On 21/02/2020 15:23, Michael Hall wrote:
>> If I look at the jpackage page…
>> 
>> The jpackage tool has been integrated into the JDK, and is now included in 
>> JDK 14 early access builds.
>> 
>> The normal early access page now indicates release candidate and the 
>> download no longer includes -ea
>> 
>> However, the included jpackage still shows…
>> 
>>  jpackage --help
>> WARNING: Using incubator modules: jdk.incubator.jpackage
>> ...
>> 
>> With an incubator warning.
> Yes, should be expected as its an incubating module in JDK 14.  The CLI 
> options and application layout are non-final. The "Deliverying jpackage" 
> section in JEP 343 has more this.

I’ll look at the JEP as well.

> 
>> 
>> If I copy the jpackage bin command into my application
>> 
>> ./jpackage --help
>> Error occurred during initialization of boot layer
>> java.lang.module.FindException: Module jdk.incubator.jpackage not found
>> 
>> I could add the indicated jdk.incubator.jpackage module but should it 
>> actually still be needed?
> You can't copy launchers in this way as it requires the module to be in the 
> run-time image.

If I add modules it into the build runtime I think I’m ok but haven’t tried it 
yet.

Re: jpackage current status

2020-02-21 Thread Philip Race


Hi,

I don't understand what you are doing here.
It is like you are copying around an application
which has dependent libraries but not copying those libraries.

Copying bits out of the JDK to some other location isn't something you 
can expect to work.


And why does your application need jpackage ?
It is a developer tool, not a run time tool ?

-phil.

On 2/21/20, 7:23 AM, Michael Hall wrote:

If I look at the jpackage page…

The jpackage tool has been integrated into the JDK, and is now included in JDK 
14 early access builds.

The normal early access page now indicates release candidate and the download 
no longer includes -ea

However, the included jpackage still shows…

  jpackage --help
WARNING: Using incubator modules: jdk.incubator.jpackage
...

With an incubator warning.

If I copy the jpackage bin command into my application

./jpackage --help
Error occurred during initialization of boot layer
java.lang.module.FindException: Module jdk.incubator.jpackage not found

I could add the indicated jdk.incubator.jpackage module but should it actually 
still be needed?

Re: jpackage current status

2020-02-21 Thread Alan Bateman





On 21/02/2020 15:23, Michael Hall wrote:

If I look at the jpackage page…

The jpackage tool has been integrated into the JDK, and is now included in JDK 
14 early access builds.

The normal early access page now indicates release candidate and the download 
no longer includes -ea

However, the included jpackage still shows…

  jpackage --help
WARNING: Using incubator modules: jdk.incubator.jpackage
...

With an incubator warning.
Yes, should be expected as its an incubating module in JDK 14.  The CLI 
options and application layout are non-final. The "Deliverying jpackage" 
section in JEP 343 has more this.




If I copy the jpackage bin command into my application

./jpackage --help
Error occurred during initialization of boot layer
java.lang.module.FindException: Module jdk.incubator.jpackage not found

I could add the indicated jdk.incubator.jpackage module but should it actually 
still be needed?
You can't copy launchers in this way as it requires the module to be in 
the run-time image.


-Alan

Re: jpackage current status