Re: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

[Scott Palmer]

> On May 12, 2022, at 8:10 AM, Michael Hall  wrote:
> 
> 
> 
>> 
>> My primary suggestion would to be to use an UUID for the unique ID. They are 
>> of fixed length, are for all intents and purposes unique and you can conjure 
>> them up from your hat. (An alternative is that the user needs to specify a 
>> unique ID, but that is probably a less ideal solution.) Presumably, we can 
>> have some kind of prefix like "org.openjdk.jpackage." before the UUID to 
>> make them a bit understandable, if someone where to inspect the package 
>> metadata.e 
> 
> I was thinking jpackage would change the XXX to app name but a fixed size 
> unique field would probably be better.
>> 
>> This seems like a fully workable solution to me. However, I'd really like to 
>> understand option #1 better, which was: "Package the `java` executable in a 
>> standard bundle, replacing `runtime/Contents/Home/bin/java` with a symlink 
>> to that."
>> 
>> I don't know what a "standard bundle" is, or how you would go around to 
>> package the java executable in one. But on the surface, it sounds much nicer 
>> than binary editing.
>> 
>> I also don't understand if that means that the standard bundle needs to be 
>> created at jpackage time, so it gives us the chance to set a proper ID, or 
>> if the standard bundle can be created at build time, and then the existence 
>> of this bundle just makes Apple avoid the bundle ID collision checks. Or if 
>> I'm just misunderstanding it all...
>> 
>> /Magnus
> 
> I may again not understanding but I was thinking they were talking about 
> something like symlinks to a machine installed JDK and this seemed to me to 
> defeat some of the purpose of embedding the jdk. But he could be thinking 
> else. Something external to the application anyhow it seemed.
> 

I thought they meant something like the embedded JDK would be like a framework 
bundle. Since the framework is expected to be the same in multiple apps it 
would be excluded from the duplicate id check. (I think that is related to the 
older bug that the Apple guy thought might have come back.)

Scott

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

[Scott Palmer]

> 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 io/m3si/utils/ClassLoaderUtils$Agent.class
  4613 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/ClassLoaderUtils.class

I extracted MANIFEST.MF just to be sure …

Manifest-Version: 1.0
Implementation-Title: Kayak Plugins Bootstrap
Premain-Class: io.m3si.utils.ClassLoaderUtils$Agent
Implementation-Version: 1.0.1
Agent-Class: io.m3si.utils.ClassLoaderUtils$Agent
Main-Clas

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

[Scott Palmer]

Sorry That last build with the Oracle OpenJDK needed the build file changed to 
have

   vendor = JvmVendorSpec.ORACLE

as well as the command line property pointing to the path to the jdk,

Scott 


> On Sep 22, 2021, at 10:24 AM, Scott Palmer  wrote:
> 
> I reproduced it with the AZUL's distribution of OpenJDK (with JavaFX modules 
> bundled) and I just changed:
> 
>   vendor = JvmVendorSpec.ADOPTOPENJDK
> 
> And get the same error with that build of OpenJDK as well.  “OpenJDK Runtime 
> Environment Temurin-17+35 (build 17+35)”
> You can try that, as Gradle should download the JDK for you.
> 
> I then downloaded the Oracle build of OpenJDK from https://jdk.java.net/17/   
>  (build 17+35-2724)
> unzipped it to C:\Tools
> building with:
> 
> gradlew -Porg.gradle.java.installations.paths=C:\Tools\jdk-17 clean build
> 
> I still reproduce the error.
> 
> Though the assertion in native JVM code that you are getting looks like yet 
> another bug!  So perhaps it is good that it is discovered as well.
> 
> 
> Scott
> 
>> On Sep 22, 2021, at 9:54 AM, Andy Herrick  wrote:
>> 
>> I can't seem to get your testcase to work with the Oracle JDK configured.
>> 
>> I can build, but then when I run
>> 
>> $ ./build/application/FetchURL/FetchURL.exe
>> 
>> I get:
>> 
>>> *** 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
>> same behavior if I restore "runtime" directory and fix FetchURL.cfg to 
>> remove app.runtime entry.
>> 
>> anyway I used your two source files to build the test app without gradle, 
>> and the test can download 
>> https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8 
>> without any problems.
>> 
>> I then moved runtime to jre and added line "app.runtime=$APPDIR/../jre" to 
>> cfg file and app still ran fine (downloaded the above)
>> 
>> So I still don't have any way to reproduce this problemwith the Oracle jdk.
>> 
>> /Andy
>> 
>> 
>> PS:
>> 
>> Although something somewhere else may have changed to counter the problem, 
>> it's clear from your description, that since the only place in the code the 
>> default runtime path is used (instead of the actual runtime path, which may 
>> be different) is the line in WinLauncher.cpp to call SetDllDirectory().
>> 
>> This should be fixed - but would like a way to reproduce the problem it 
>> causes first.
>> 
>> /Andy
>> 
>> On 9/21/2021 12:12 PM, Andy Herrick wrote:
>>> I thought I could create a reproduction scenario by using an app with 
>>> "-splash:" arg then moving the jre as you did, but I have not 
>>> yet been able make it fail.
>>> 
>>> /Andy
>>> 
>>> On 9/21/2021 11:43 AM, Scott Palmer wrote:
>>>>> On Sep 21, 2021, at 11:40 AM, Alan Bateman  
>>>>> wrote:
>>>>> 
>>>>> On 21/09/2021 15:54, Andy Herrick wrote:
>>>>>> I found the problem in 
>>>>>> open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp
>>>>>> 
>>>>>> we call SetDllDirectory() with the path to the bin dir in the default 
>>>>>> runtime directory, not the actual runtime directory.
>>>>>> 
>>>>>> since on Windows we never use other than the default runtime location - 
>>>>>> we had not seen a problem, but is bug I will file and fix.
>>>>>> 
>>>>> Good to see that you found it quickly. However I'm puzzled as why 
>>>>> initializingEncoding wasn't called, I would have expected the VM to blow 
>>>>> up during early startup. Would you have cycles to dig into that a bit 
>>>>> more in case something has been masked, like for example an exception 
>>>>> being swallowed.  Running with -Xlog:exceptions might reveal something.
>>>> 
>>>> Do you have a case that reproduces the issue?
>>>> 
>>>> Scott
> 

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

[Scott Palmer]

I reproduced it with the AZUL's distribution of OpenJDK (with JavaFX modules 
bundled) and I just changed:

vendor = JvmVendorSpec.ADOPTOPENJDK

And get the same error with that build of OpenJDK as well.  “OpenJDK Runtime 
Environment Temurin-17+35 (build 17+35)”
You can try that, as Gradle should download the JDK for you.

I then downloaded the Oracle build of OpenJDK from https://jdk.java.net/17/
(build 17+35-2724)
unzipped it to C:\Tools
building with:

gradlew -Porg.gradle.java.installations.paths=C:\Tools\jdk-17 clean build

I still reproduce the error.

Though the assertion in native JVM code that you are getting looks like yet 
another bug!  So perhaps it is good that it is discovered as well.


Scott

> On Sep 22, 2021, at 9:54 AM, Andy Herrick  wrote:
> 
> I can't seem to get your testcase to work with the Oracle JDK configured.
> 
> I can build, but then when I run
> 
> $ ./build/application/FetchURL/FetchURL.exe
> 
> I get:
> 
>> *** 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
> same behavior if I restore "runtime" directory and fix FetchURL.cfg to remove 
> app.runtime entry.
> 
> anyway I used your two source files to build the test app without gradle, and 
> the test can download 
> https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8 
> without any problems.
> 
> I then moved runtime to jre and added line "app.runtime=$APPDIR/../jre" to 
> cfg file and app still ran fine (downloaded the above)
> 
> So I still don't have any way to reproduce this problemwith the Oracle jdk.
> 
> /Andy
> 
> 
> PS:
> 
> Although something somewhere else may have changed to counter the problem, 
> it's clear from your description, that since the only place in the code the 
> default runtime path is used (instead of the actual runtime path, which may 
> be different) is the line in WinLauncher.cpp to call SetDllDirectory().
> 
> This should be fixed - but would like a way to reproduce the problem it 
> causes first.
> 
> /Andy
> 
> On 9/21/2021 12:12 PM, Andy Herrick wrote:
>> I thought I could create a reproduction scenario by using an app with 
>> "-splash:" arg then moving the jre as you did, but I have not 
>> yet been able make it fail.
>> 
>> /Andy
>> 
>> On 9/21/2021 11:43 AM, Scott Palmer wrote:
>>>> On Sep 21, 2021, at 11:40 AM, Alan Bateman  wrote:
>>>> 
>>>> On 21/09/2021 15:54, Andy Herrick wrote:
>>>>> I found the problem in 
>>>>> open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp
>>>>> 
>>>>> we call SetDllDirectory() with the path to the bin dir in the default 
>>>>> runtime directory, not the actual runtime directory.
>>>>> 
>>>>> since on Windows we never use other than the default runtime location - 
>>>>> we had not seen a problem, but is bug I will file and fix.
>>>>> 
>>>> Good to see that you found it quickly. However I'm puzzled as why 
>>>> initializingEncoding wasn't called, I would have expected the VM to blow 
>>>> up during early startup. Would you have cycles to dig into that a bit more 
>>>> in case something has been masked, like for example an exception being 
>>>> swallowed.  Running with -Xlog:exceptions might reveal something.
>>> 
>>> Do you have a case that reproduces the issue?
>>> 
>>> Scott

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

[Scott Palmer]

I’ve uploaded a project that reproduces the problem to JDK-8274087 
<https://bugs.openjdk.java.net/browse/JDK-8274087>

Regards,

Scott 

> On Sep 21, 2021, at 3:49 PM, Scott Palmer  wrote:
> 
> I have discovered that I have to have my Java Agent configured  in the .cfg 
> file for it to happen:
> 
> [JavaOptions]
> java-option=-javaagent:$APPDIR\libs\MyAgent.jar
> 
> 
> The agent is needed in my real app only to get an instance of the 
> Instrumentation interface. In my test code, where I have reproduced this, it 
> is never used.  My test app just takes a URL and fetches it via a 
> HttpURLConnection with setInstanceFollowRedirects(false) so I can capture the 
> new location.  If you are still having trouble reproducing I will have the 
> code cleaned up for the bug report soon...
> 
> 
> Regards,
> 
> Scott
> 
> 
> 
>> On Sep 21, 2021, at 12:12 PM, Andy Herrick  wrote:
>> 
>> I thought I could create a reproduction scenario by using an app with 
>> "-splash:" arg then moving the jre as you did, but I have not 
>> yet been able make it fail.
>> 
>> /Andy
>> 
>> On 9/21/2021 11:43 AM, Scott Palmer wrote:
>>>> On Sep 21, 2021, at 11:40 AM, Alan Bateman  wrote:
>>>> 
>>>> On 21/09/2021 15:54, Andy Herrick wrote:
>>>>> I found the problem in 
>>>>> open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp
>>>>> 
>>>>> we call SetDllDirectory() with the path to the bin dir in the default 
>>>>> runtime directory, not the actual runtime directory.
>>>>> 
>>>>> since on Windows we never use other than the default runtime location - 
>>>>> we had not seen a problem, but is bug I will file and fix.
>>>>> 
>>>> Good to see that you found it quickly. However I'm puzzled as why 
>>>> initializingEncoding wasn't called, I would have expected the VM to blow 
>>>> up during early startup. Would you have cycles to dig into that a bit more 
>>>> in case something has been masked, like for example an exception being 
>>>> swallowed.  Running with -Xlog:exceptions might reveal something.
>>> 
>>> Do you have a case that reproduces the issue?
>>> 
>>> Scott
> 

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

[Scott Palmer]

I have discovered that I have to have my Java Agent configured  in the .cfg 
file for it to happen:

[JavaOptions]
java-option=-javaagent:$APPDIR\libs\MyAgent.jar


The agent is needed in my real app only to get an instance of the 
Instrumentation interface. In my test code, where I have reproduced this, it is 
never used.  My test app just takes a URL and fetches it via a 
HttpURLConnection with setInstanceFollowRedirects(false) so I can capture the 
new location.  If you are still having trouble reproducing I will have the code 
cleaned up for the bug report soon...


Regards,

Scott



> On Sep 21, 2021, at 12:12 PM, Andy Herrick  wrote:
> 
> I thought I could create a reproduction scenario by using an app with 
> "-splash:" arg then moving the jre as you did, but I have not yet 
> been able make it fail.
> 
> /Andy
> 
> On 9/21/2021 11:43 AM, Scott Palmer wrote:
>>> On Sep 21, 2021, at 11:40 AM, Alan Bateman  wrote:
>>> 
>>> On 21/09/2021 15:54, Andy Herrick wrote:
>>>> I found the problem in 
>>>> open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp
>>>> 
>>>> we call SetDllDirectory() with the path to the bin dir in the default 
>>>> runtime directory, not the actual runtime directory.
>>>> 
>>>> since on Windows we never use other than the default runtime location - we 
>>>> had not seen a problem, but is bug I will file and fix.
>>>> 
>>> Good to see that you found it quickly. However I'm puzzled as why 
>>> initializingEncoding wasn't called, I would have expected the VM to blow up 
>>> during early startup. Would you have cycles to dig into that a bit more in 
>>> case something has been masked, like for example an exception being 
>>> swallowed.  Running with -Xlog:exceptions might reveal something.
>> 
>> Do you have a case that reproduces the issue?
>> 
>> Scott

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

[Scott Palmer]

> On Sep 21, 2021, at 11:40 AM, Alan Bateman  wrote:
> 
> On 21/09/2021 15:54, Andy Herrick wrote:
>> 
>> I found the problem in 
>> open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp
>> 
>> we call SetDllDirectory() with the path to the bin dir in the default 
>> runtime directory, not the actual runtime directory.
>> 
>> since on Windows we never use other than the default runtime location - we 
>> had not seen a problem, but is bug I will file and fix.
>> 
> Good to see that you found it quickly. However I'm puzzled as why 
> initializingEncoding wasn't called, I would have expected the VM to blow up 
> during early startup. Would you have cycles to dig into that a bit more in 
> case something has been masked, like for example an exception being 
> swallowed.  Running with -Xlog:exceptions might reveal something.


Do you have a case that reproduces the issue?

Scott

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

[Scott Palmer]

This is on Windows 10 Pro.  using JDK 17 for jpackage and I'm pretty sure
for jimage  (though the image was made shortly after 17 GA and is being
reused)..

There are no libraries directly in $APPDIR, though there are plenty in
other sibling folders to the 'app' folder (in addition to those in app\libs)

I changed app.runtime to point to the (relative) path without the
$APPDIR\.. - same problem. Tried a absolute path, same problem.

The exact same runtime folder that was failing for me was simply copied to
the default location to make it work.  It works if I leave app.runtime out
of the .cfg file, or if I point to $APPDIR\..\runtime

I did some more experiments and found that if I just rename the 'runtime'
folder to 'jre', but leave it at the same depth then the problem appears.

I suspected there must be some hardcoded reference to the 'runtime' folder
in the app launcher.  However, if I have two copies of the runtime, one at
the default location, and use app.runtime to point to the other copy it
still fails. (i.e. if it is referencing some library from the default
location it doesn't help.. I thought it might, being that it is all in the
same process.)

The application is complex.  It has a plugin mechanism that uses an Agent
and the Instrument class to augment the classpath at runtime.

(Older versions of the plugin mechanism used to hack the System classloader
on JDK 8 and switching to an Agent was the fastest way to make it work on
later versions in a supported manner. It likely should be using custom
classloaders, but classloading issues got messy when I looked into that way
back when we started.)

I will try to find time later this week to isolate a test case that can
reproduce it.  For now I can work around the issue by putting the runtime
back to the default location for this case.  This is a special case of an
application that actually includes the JRE itself as one of the plugins so
we can upgrade the JRE after the initial deployment or run different jobs
with different JREs.  I was trying to make a smaller tool/demo that used
the JRE from where it would be in our "plugin" folder.

Regards,

Scott

On Tue, Sep 21, 2021 at 9:22 AM Andy Herrick 
wrote:

> I don't see anything wrong with this offhand. the runtime should be able
> to be anywhere if the cfg files "app.runtime" line points to it.
>
> Is this on windows ? Is the the released JDK17 used both for the jlinked
> runtime and the jpackage tool ?
>
> Are there any libraries in $APPDIR (which is added to the $PATH env
> variable on windows) which could be interfering with encoding
> initialization ?
>
> Can you try the following experiment:
>
> manually edit the cfg file line:
>
> app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre
>
> to contain the canonical path to
> ...\my_own_folder\where_the_jre_is_deeper\jre
>
> and try again ?
>
>
> /Andy
>
> On 9/20/2021 5:37 PM, Scott Palmer wrote:
> > This is likely not the right place to ask this (sorry).. but I'm trying
> to
> > get info to write a bug report and want to make sure I'm not doing
> > something stupid first.
> >
> > I've created a JRE image from JDK 17 with jlink.  I've made an
> > application image with jpackage.  I've moved the default location of the
> > runtime in the application image and modified the launcher .cfg file
> > accordingly by adding a line to the [Application] section
> >
> > app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre
> >
> > My application launches.  It shows a JavaFX GUI.  It does a bunch of
> stuff
> > that "works", but then one thread fails with this exception:
> >
> > Exception in thread "Reader-BG-1" java.lang.InternalError: platform
> > encoding not initialized
> >  at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native
> > Method)
> >  at
> > java.base/java.net
> .InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933)
> >  at
> > java.base/java.net
> .InetAddress.getAddressesFromNameService(InetAddress.java:1519)
> >  at
> > java.base/java.net
> .InetAddress$NameServiceAddresses.get(InetAddress.java:852)
> >  at
> > java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509)
> >  at
> > java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367)
> >  at
> > java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301)
> >  at java.base/java.net
> .InetAddress.getByName(InetAddress.java:1251)
> >  at
> > java.base/java.net.InetSocketAddress.(InetSocketAddress.java:229)
> >  at java.base/sun.net
> .NetworkClient.doConnect(NetworkClient.java:178)
> >

What causes java.lang.InternalError: platform encoding not initialized ?

[Scott Palmer]

This is likely not the right place to ask this (sorry).. but I'm trying to
get info to write a bug report and want to make sure I'm not doing
something stupid first.

I've created a JRE image from JDK 17 with jlink.  I've made an
application image with jpackage.  I've moved the default location of the
runtime in the application image and modified the launcher .cfg file
accordingly by adding a line to the [Application] section

app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre

My application launches.  It shows a JavaFX GUI.  It does a bunch of stuff
that "works", but then one thread fails with this exception:

Exception in thread "Reader-BG-1" java.lang.InternalError: platform
encoding not initialized
at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native
Method)
at
java.base/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933)
at
java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1519)
at
java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:852)
at
java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509)
at
java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367)
at
java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301)
at java.base/java.net.InetAddress.getByName(InetAddress.java:1251)
at
java.base/java.net.InetSocketAddress.(InetSocketAddress.java:229)
at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:178)
at
java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:498)
at
java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:603)
at
java.base/sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:266)
at
java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:380)
at
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:189)
at
java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1242)
at
java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1128)
at
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:175)
at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1665)
at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589)
at
java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:529)
at
java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:308)

If I keep the runtime in $APPDIR\runtime, things don't fail in this way.

Smells like a bug in the app launcher to me.. but maybe it's in the runtime?

Any assistance would be appreciated (including telling me where I should go
to ask this, if this list isn't appropriate).

Thanks,

Scott

Re: Proposal to add JavaScript platform to jpackage

[Scott Palmer]

This doesn’t seem like something that should be the job of jpackage.  The 
jpackage tool is currently used for producing platform-specific packages or 
installers targeted at end-users that include native launchers and a JRE.  
Web-based applications are an entirely different beast. This seems like more of 
a job for a Maven or Gradle plugin.

Regards,

Scott


> On Apr 24, 2021, at 5:59 PM, Andrew Oliver <93q...@gmail.com> wrote:
> 
> Below is a Java Enhancement Proposal for your consideration to add
> JavaScript to jpackage as a new target platform.  I would appreciate
> feedback on the proposal contents.  I am also interested in learning about
> the process, specifically what approvals are required prior to start of
> implementation, should sufficient consensus be reached.
> 
> ( To view this proposal as a web page, please visit:
> https://frequal.com/TeaVM/openjdk/jdk-list-draft1.html )
> 
> Thank you!
> 
>  -Andrew Oliver
> 
> Title: Add JavaScript platform to jpackage
> Author: Andrew Oliver
> Created: 2021/04/24
> Type: Feature
> State: Draft
> Exposure: Open
> Component: tools/jpackage
> Scope: JDK
> Discussion: core-libs-dev@openjdk.java.net
> Template: 1.0
> 
> Summary
> ---
> 
> jpackage already allows packaging Java applications for several platforms.
> This proposal adds a new platform: JavaScript.
> 
> This effort will enable jpackage to convert bytecode from the provided
> classes into JavaScript, and generate the required HTML to invoke the
> specified main method when opened in a web browser. These files will be
> bundled into a WAR file for easy deployment.
> 
> Goals
> -
> 
> *   Enabling JVM languages to build client-side web applications
> *   Allow easy generation of JavaScript from JVM bytecode
> *   Allow easy deployment and execution of generated JavaScript in web
> browsers
> *   Allow easy deployment of the generated JavaScript in all web server
> environments
>*   Java web application container (like Tomcat)
>*   Static file web servers
>*   Static file web hosting services
> 
> Non-Goals
> -
> 
> *   Allowing execution of JavaScript server-side. (Java already has
> numerous options for executing bytecode server-side.)
> 
> Motivation
> --
> 
> Java was once used to create client-side web applications via applets that
> could be launched by visiting a web page. Applets could draw on an area of
> the screen (like HTML5 Canvas) or manipulate the page DOM to create dynamic
> front-end applications (like JS single-page apps).
> 
> However, as evident in JEP 398 ([
> https://openjdk.java.net/jeps/398](https://openjdk.java.net/jeps/398)),
> applets are no longer feasible due to the actions of browser vendors. While
> browsers have lost the ability to execute Java bytecode or invoke methods
> from the Java class libraries, they do have mature engines for executing a
> different sort of code (JavaScript) and an extensive list of useful APIs.
> By converting class files to JavaScript, and providing mechanisms to invoke
> browser APIs, Java can again be used to create in-browser applications.
> [TeaVM](https://teavm.org) has demonstrated that this is feasible and has
> numerous benefits:
> 
> *   Provides a strongly-typed language for client-side web development
> *   Provides a wealth of IDEs, build tools, and testing tools for
> client-side web development
> *   Allows teams with Java experience to produce apps with familiar
> technology
> *   Allows sharing of POJO and business logic classes, simplifying
> development
> *   Allows options for porting applet- and JNLP-based systems to
> present-day browsers
> 
> Details
> ---
> 
> An additional jpackage option for type will be added: `js`
> 
> jpackage will use a JavaScript AOT compiler (TeaVM) to convert the Java
> code to JavaScript, with the main class compiled to a JavaScript method
> called 'main()'.
> 
> jpackage bundles application code, runtime, and resources into a
> platform-specific format. For this new JavaScript type, the layout will be
> either a ZIP file or a standard WAR file. The ZIP format will contain the
> files ready to be extracted to a static file webserver or HTML hosting
> service. Generated WARs will have the required structure to be deployable
> in a Java web application container.
> 
> ### WAR layout
> 
> *   HelloApp.war
>*   index.html (Main application page, loads classes.js and invokes
> main())
>*   teavm
>*   classes.js (Class files, templates, and resources compiled to
> JavaScript)
>*   css
>*   (CSS files from application)
>*   META-INF
>*   MANIFEST.MF
>*   WEB-INF
>*   web.xml
> 
> ### ZIP Layout
> 
> *   HelloApp.zip
>*   index.html (Main application page, loads classes.js and invokes
> main())
>*   teavm
>*   classes.js (Class files, templates, and resources compiled to
> JavaScript)
>*   css
>*   (CSS files from application)
> 
> Basic usage: Non-modular applications
> 

Re: jpackage: support for environment variables in --java-options

[Scott Palmer]

> On Sep 3, 2020, at 8:55 AM, Michael Hall  wrote:
> 
> 
> 
>> On Sep 3, 2020, at 7:12 AM, Scott Palmer > <mailto:swpal...@gmail.com>> wrote:
>> 
>> 
>> 
>>> On Sep 3, 2020, at 4:26 AM, Michael Hall >> <mailto:mik3h...@gmail.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Sep 2, 2020, at 10:07 PM, Scott Palmer >>> <mailto:swpal...@gmail.com>> wrote:
>>>> 
>>>> There is already a way to supply a custom Info.plist.  
>>>> That can have the LSEnvironment entries you want.
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8233175 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8233175>
>>>> 
>>>> I was under the impression that we were after something that would allow 
>>>> different values to get to the application based on environment variables. 
>>>>  The env var values can’t be hard-coded in the Info.plist to do that, we 
>>>> want values that are expanded based on set environment variables on the 
>>>> user’s machine.  Isn’t that what this is about?
>>>> 
>>>> Scott
>>> 
>>> Yes for Serban’s thread. Which was already shown not to work OS X on the 
>>> users machine because user environment variables aren’t passed to 
>>> applications. 
>> 
>> As I mentioned earlier, launchctl must be used to set environment variables 
>> that you want passed to GUI applications.
> 
> This is not how I’ve done it before. I did a little googling and it seemed to 
> indicate launchctl could somehow be used for ‘global’ environment variables. 
> It didn’t sound application specific.

Right it isn’t application specific.  If you need a separate environment for 
your application, that wouldn’t work.  But if you are passing parameters that 
are specific to the application launcher, why use environment variables at all?


> The incident mentioned earlier showed a resolution of having the user provide 
> their own custom Info.plist.

Just use a config file that can be platform independent.  Modifying the 
Info.plist for each specific install smells wrong.

Scott

> While plain old edit would probably be fine for this some sort of code to 
> provide it without manual intervention might also be nice. I believe I have 
> some old code lying around that might just provide a beginning for such a 
> thing.

Re: jpackage: support for environment variables in --java-options

[Scott Palmer]

> On Sep 3, 2020, at 4:26 AM, Michael Hall  wrote:
> 
> 
> 
>> On Sep 2, 2020, at 10:07 PM, Scott Palmer > <mailto:swpal...@gmail.com>> wrote:
>> 
>> There is already a way to supply a custom Info.plist.  
>> That can have the LSEnvironment entries you want.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8233175 
>> <https://bugs.openjdk.java.net/browse/JDK-8233175>
>> 
>> I was under the impression that we were after something that would allow 
>> different values to get to the application based on environment variables.  
>> The env var values can’t be hard-coded in the Info.plist to do that, we want 
>> values that are expanded based on set environment variables on the user’s 
>> machine.  Isn’t that what this is about?
>> 
>> Scott
> 
> Yes for Serban’s thread. Which was already shown not to work OS X on the 
> users machine because user environment variables aren’t passed to 
> applications.

As I mentioned earlier, launchctl must be used to set environment variables 
that you want passed to GUI applications.

Scott

Re: jpackage: support for environment variables in --java-options

[Scott Palmer]

There is already a way to supply a custom Info.plist.  
That can have the LSEnvironment entries you want.

https://bugs.openjdk.java.net/browse/JDK-8233175 
<https://bugs.openjdk.java.net/browse/JDK-8233175>

I was under the impression that we were after something that would allow 
different values to get to the application based on environment variables.  The 
env var values can’t be hard-coded in the Info.plist to do that, we want values 
that are expanded based on set environment variables on the user’s machine.  
Isn’t that what this is about?

Scott


> On Sep 2, 2020, at 1:20 PM, Michael Hall  wrote:
> 
> 
> 
>> On Sep 2, 2020, at 12:14 PM, Scott Palmer  wrote:
>> 
>> If your app need to use environment variables to configure something for 
>> runtime it is probably best to have your own stub launcher and launch a 
>> sub-process.  
> 
> They need to be available at runtime for external native that expects them to 
> be present. 
> 
>> 
>> It can be tricky to have a smooth user experience with that though. You 
>> would want to avoid an extra icon in the dock/start bar. You don’t want the 
>> other process to show up as “java.exe”, etc.  That’s the benefit of trying 
>> to solve this in the launcher created by jpackage. 
>> 
> 
> What I am suggesting would be handled by jpackage within the application 
> bundle. It would modify the Info.plist to include the LSEnvironment entries.

Re: jpackage: support for environment variables in --java-options

[Scott Palmer]

If your app need to use environment variables to configure something for 
runtime it is probably best to have your own stub launcher and launch a 
sub-process.  

It can be tricky to have a smooth user experience with that though. You would 
want to avoid an extra icon in the dock/start bar. You don’t want the other 
process to show up as “java.exe”, etc.  That’s the benefit of trying to solve 
this in the launcher created by jpackage. 

Scott

> On Sep 2, 2020, at 11:59 AM, Michael Hall  wrote:
> 
> 
> 
>> On Sep 2, 2020, at 9:04 AM, Andy Herrick  wrote:
>> 
>> Yes - environment variables are not a good answer for this, not just mac, 
>> but even on windows the env variables at run time are different if launched 
>> from a shell (the env variables of that shell) vs. when run from a shortcut 
>> (the system-wide or user env variables set in Control Panel or Settings 
>> dialog).
>> 
>> JEP-343 says jpackage should be "a tool for packaging self-contained Java 
>> applications.", so an app packaged with jpackage should run on a machine 
>> without requiring any other files to be installed .  That should not 
>> prohibit optional configuration from being discovered on a machine and used 
>> to tune the application or it's use of Java.
>> 
>> Normally, any such discovery can be done by the application itself, except 
>> where it is the the java options that tune the java vm itself, and that is 
>> why we are considering mechanisms (such as expanding environment variables 
>> at runtime, or reading an installed configuration file of some kind)
>> 
> It’s difficult and was difficult with java applications on OS X from the 
> start to have an application support anything like command line invoking with 
> parameters.
> 
> Maybe add standalone options for the command that update an existing 
> application bundle? Of course then there would probably be signing and other 
> issues.
> 
> Again, for LSEnvironment on OS X I think it wouldn’t be terribly difficult to 
> implement. You could handle it something like it appears file associations 
> work. Although, I haven’t done anything with those yet. Then just modify the 
> Info.plist. I have had code that does that in the past. XML right?
> 
> In the past I have had need to add environment variables to my application to 
> interface it with the R language. Also  debugging AppleScript related at one 
> point required environment variables. It was very much an OS X only java app 
> at one point in time.
> Recently I had problems interfacing to Anaconda python that it seemed like 
> being able to set the PATH variable might resolve. Although my own attempts 
> to set the variables to get it to work failed. What did work was command line 
> shell invoking the application. Like myApp.app/Contents/MacOS/myApp from 
> Terminal. That was for someone else’s application.
> I decided just to set a alias for that in .bash_profile for my own use and 
> not try to figure what exactly the Finder launched application needed to make 
> it work.
> So these are some use cases where environment variables were involved. A 
> feature to support them could occasionally be nice. 
> 
> 
> 
> 
> 
> 
> 

Re: jpackage: support for environment variables in --java-options

[Scott Palmer]

> On Sep 1, 2020, at 5:22 PM, Michael Hall  wrote:
> 
> 
>> 
>> 
>>> Is there a way to pass values from environment variables when using
>>> --java-options?
>>> 
>>> It would be nice to be able to write something like this:
>>> --java-options "-DmyAppData=$HOME/.myData"
>>> 
>>> (Instead of using the $ sign, another notation may be more appropriate, in
>>> order to not conflict with macros such as $APPDIR or $ROOTDIR.)
>> Although I don't think there is a problem conflicting with the existing 
>> macros for $ROOTDIR, $APPDIR, or $BINDIR, we may need something more 
>> exclusive that "$" since dollar sign may be a legitimate character in an 
>> existing argument or vm option ("-DPRICE=$10.50") or ("-DCURRENCY_TAG=$")
>> 
>> anyway, wouldn't this go a long way to alleviating the concerns of 
>> JDK-8250950  ?
>> 
>> 
> If I follow the referenced issue, after a quick browse, it wants to satisfy 
> the need for different user memory specifications. It proposes doing this 
> with a standalone configuration file that could override the one jpackage 
> uses. So could be used for more general overrides.
> You are now thinking environment variables could provide the override without 
> the need for a second user/developer configuration file? 
> I am not sure that works. Actually, I don’t think the environment variable 
> settings would be very useful on OS X at all after considering this issue. 
> On OS X applications get a default set of environment variables not dependent 
> on user ones. 
> Looking like this from an application of mine…
> 
> exec env
> TMPDIR=/var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp4gn/T/
> __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0y for 
> HOME=/Users/mjh
> SHELL=/bin/bash
> Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.sZlyFCZcWZ/Render
> SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.f11OdXASJN/Listeners
> PATH=/usr/bin:/bin:/usr/sbin:/sbin
> LOGNAME=mjh
> DISPLAY=/private/tmp/com.apple.launchd.rN2uW3mk7s/org.macosforge.xquartz:0
> XPC_SERVICE_NAME=us.hall.FastRGraalHP.35068
> USER=mjh
> XPC_FLAGS=0x0
> 
> My own settings from Terminal (.bash_profile) are more involved say for the 
> PATH variable…
> 
> env | grep PATH
> PATH=/Users/mjh/anaconda3/bin:/Users/mjh/anaconda3/condabin:/opt/ooRexx/bin:/usr/local/Cellar/watchman/4.9.0_3/bin:/Users/mjh/management/spark-2.4.3-bin-hadoop2.7/bin:/Users/mjh/management/apache-maven-3.6.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
> ...
> 
> So I’m not sure passing things to the application at launch time by 
> environment variable would work? At least OS X. If as I think the issue 
> indicated you wanted a cross-platform solution.

On macOS you need to set the variables differently, but I think it can still 
work. The variables known to your shell are not the same as those known to 
LaunchServices. For those use the launchctl command to set them. 


Scott

Re: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302

[Scott Palmer]

I think that sorry if things is usually handled in an “Application Manifest” on 
Windows

https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests

Scott

> On May 12, 2020, at 8:33 AM, Kevin Rushforth  
> wrote:
> 
> Is there a way you can link the launcher (e.g., something similar to RPATH 
> on Unix systems) to look in the right place relative to the launcher? 
> Otherwise, the solution with adding to the PATH seems OK to me.
> 
> -- Kevin
> 
> 
>> On 5/12/2020 5:22 AM, Andy Herrick wrote:
>> Is the problem that by removing the copy of the microsoft dlls from the 
>> applications bin directory, then on machines that do not have all of these 
>> dll's already in the PATH (usually in C:\windows\system32) they can no 
>> longer be found ?
>> 
>> I don't like manually manipulating the PATH env variable either, but if so I 
>> don't see what else can be done short of putting the app exe in the bin dir 
>> of the runtime.
>> 
>> /Andy
>> 
>> 
>>> On 5/11/2020 9:37 PM, Alexander Matveev wrote:
>>> Hi Alexey,
>>> 
>>> Updating PATH does not look like good solution to me. Did you try to load 
>>> jli.dll by specifying full path to jli.dll when calling LoadLibary? If it 
>>> does not work, then for AddDllDirectory() did you used LoadLibrary() or 
>>> LoadLibraryEx() with LOAD_LIBRARY_SEARCH_USER_DIRS? According to doc you 
>>> need to use LoadLibraryEx() with flag when using AddDllDirectory().
>>> 
>>> Thanks,
>>> Alexander
>>> 
>>> On 5/11/2020 4:36 PM, Alexey Semenyuk wrote:
 Please review fix [2] for jpackage bug [1].
 
 Fix failure to load jli.dll from app launcher. The fix is to append path 
 to directory with jli.dll to PATH env variable and load jli.dll with 
 altered value of PATH if the first attempt to load jli.dll without 
 altering PATH fails.
 
 - Alexey
 
 [1] https://bugs.openjdk.java.net/browse/JDK-8244634
 
 [2] http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.00
 
>>> 
> 

Re: RFR(S): 8242848: Improve performance of InflaterOutputStream.write()

[Scott Palmer]

Typo in the benchmark javadoc: “avarage” instead of “average"

> On Apr 22, 2020, at 4:47 PM, Claes Redestad  wrote:
> 
> 
> 
> On 2020-04-22 22:08, Volker Simonis wrote:
>> http://cr.openjdk.java.net/~simonis/webrevs/2020/8242848.02/
>> Notice that this new version only changes the microbenchmark, all the
>> other files are untouched.
>> As everybody seemed to be happy with the change itself and the
>> regression test, I'm now waiting for your and Clae's final review of
>> the microbenchmark before pushing. Please let me know hat you think?
> 
> 
> I think the microbenchmark looks reasonable. Simple and to the point.
> Hard-coded Random seed avoids a big source of variance.
> 
> Thanks!
> 
> /Claes

Re: jpackage current status

[Scott Palmer]

It's included as a preview feature, so it's still incubating.

On Fri, Feb 21, 2020 at 10:24 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 runtime binaries

[Scott Palmer]

I’m using jlink to build my own runtime for exactly this reason.  My app needs 
to launch Java sub-processes, so it needs to be able to find the java 
executable.

Scott

> On Feb 18, 2020, at 1:10 PM, Michael Hall  wrote:
> 
> I was wondering if there is any way to include java executable binaries like 
> bin/java.
> 
> They do not appear to be default included. Looking at help I am not seeing a 
> specific parameter for that purpose.
> 
> I do see…
> 
> --runtime-image 
>  Path of the predefined runtime image that will be copied into
>  the application image
>  (absolute path or relative to the current directory)
>  If --runtime-image is not specified, jpackage will run jlink to
>  create the runtime image using options:
>  --strip-debug, --no-header-files, --no-man-pages, and
>  --strip-native-commands.
> 
> Is —strip-native-commands what causes these to be omitted? So the workaround 
> would be to jlink your own runtime. Or would a parameter to control that 
> specific setting be possible?
> 
> Thanks

Re: New issues in notarization of jpackage-created Mac applications

[Scott Palmer]

See https://bugs.openjdk.java.net/browse/JDK-8235687

I noticed this was recently discussed on the OpenJDK email list. 

Scott

> On Feb 8, 2020, at 11:06 PM, James Elliott  wrote:
> 
> As I noted earlier on this mailing list, until this past week I had been 
> successfully notarizing Mac disk images containing an application by ignoring 
> the code-signing features of jpackage (which are missing elements required 
> for notarization; one of those is already recorded in bug JDK-8238184, 
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8238184 
>  but since that 
> was filed, Apple has further tightened the requirements and it is also 
> necessary to enable the hardened runtime via `—options runtime` and to supply 
> an entitlements file with several important entitlements).
> 
> So, what I had been doing was creating my disk image using the early access 
> jpackage, and a runtime created via jlink from an Amazon Corretto 11 LTS 
> OpenJDK, with no signing, and then running `codesign —force —deep` with the 
> necessary timestamp, runtime, and entitlements arguments and file.
> 
> That stopped working at the end of the week, because Apple started to 
> complain that the individual binaries and native libraries of the runtime 
> itself were not signed. Since there were many dozens of them, I despaired 
> about what to do, and opened a support ticket with Apple (as yet no response 
> has been forthcoming).
> 
> But in further experimentation today, I tried downloading this weeks’s 
> release candidate of OpenJDK 14, and noticed that the binaries and native 
> libraries within that are all properly signed and notarized by Oracle. 
> Excellent! So I changed approaches.
> 
> I used the release candidate of OpenJDK 14 for both the jlink step to produce 
> my tailored runtime, and then used that with jpackage to create an 
> application image. I then code signed the application image (without 
> attempting to use —deep) to add the necessary timestamp, hardened runtime, 
> and entitlements. I then put that into a disk image and submitted it to Apple 
> for notarization.
> 
> It *almost* worked, but I received the following error report from Apple:
> 
> {
>  "logFormatVersion": 1,
>  "jobId": "c8195a4f-3e5b-492b-be27-dc22f20efb42",
>  "status": "Invalid",
>  "statusSummary": "Archive contains critical validation errors",
>  "statusCode": 4000,
>  "archiveFilename": "Beat_Link_Trigger.dmg",
>  "uploadDate": "2020-02-08T23:04:13Z",
>  "sha256": "3d0c25a6e6563f2c69201c74ea48c182b1df590838436bc84a57f4e9b25ea934",
>  "ticketContents": null,
>  "issues": [
>{
>  "severity": "error",
>  "code": null,
>  "path": "Beat_Link_Trigger.dmg/Beat Link 
> Trigger.app/Contents/runtime/Contents/MacOS/libjli.dylib",
>  "message": "The signature of the binary is invalid.",
>  "docUrl": null,
>  "architecture": "x86_64"
>}
>  ]
> }
> Looking into the application image package contents, I discovered that for 
> some reason, there were two copies of libjli.dylib present. In addition to 
> the expected one in:
>  My.app/Contents/runtime/Contents/Home/lib/libjli.dylib
> there was an additional copy (and nothing else) in:
>  My.app/Contents/runtime/Contents/MacOS/libjli.dylib
> 
> That second one was the one that was causing the notarization to fail.
> 
> I updated my build script to remove that extra folder, 
> Contents/runtime/Contents/MacOS/, from the application image before code 
> signing, building the disk image, and submitting it for notarization, and I 
> was back in business creating successfully notarized Java applications. Note 
> that the application appears to work just fine without the redundant, 
> problematic copy of libjli.dylib inside it.
> 
> You can find the build script that does all this here:
> https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_dmg.zsh
>  
> 
> 
> It is driven by this GitHub Actions workflow:
> https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml
>  
> 
> 
> Please let me know if there is any more information I could provide, or if 
> you think I should open this as a bug in itself.
> 
> Thanks,
> 
>  -James

Re: jpackager

[Scott Palmer]

Welcome to Windows.

The .exe is a Windows app not a Console app.  This is a distinction that only 
Microsoft seemed to think was needed.  All other platforms are sane.
There is command line option to make a console app.

--win-console


Scott 



> On Dec 14, 2019, at 12:22 PM, Thomas Vatter  wrote:
> 
> Hi,
> 
> I've created a modular jar and jre image by jlink.
> 
> I tested it with this command:
> 
> PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp
> Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main
> INFO: SimpleApp says hello
> 
> It says "SimpleApp says hello" in the powershell window.
> 
> 
> Then I packaged it by
> 
> jpackager.exe create-image --input dist --output jp_out --name test01
> --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar
> 
> This creates in the output folder a file structure with an exe file in it.
> 
> When I execute the exe file fron the powershell there is no error
> message, but it doesn't say "SimpleApp says hello" any more.
> 
> Is something wrong?
> 
> regards
> 
> Thomas
> 
> 
> 
> 
> 
> 

Re: Class-Path (in jar file) semantics different between Java 11 and 13 (on Windows)?

[Scott Palmer]

/C:/blah... is “root relative”. The (old) spec says the URL must be
"relative to the code base".  What does "code base" mean when not referring
to Applets or RMI?

This seems like a bad idea (security hole) that worked by accident.

Scott

On Wed, Nov 20, 2019 at 10:00 AM Alan Bateman 
wrote:

> On 20/11/2019 13:50, David Lloyd wrote:
> > :
> > OK, but this decision violates both the old and updated spec (and
> > makes it difficult to write code that works in both cases: in
> > situations that reject absolute URLs (javac) and in situations that
> > reject drive letters (this code)), so I would request that this be
> > revisited.
> >
> This cannot be rushed as it require detailed security analysis. Is there
> any reason why you need to encode absolute file paths as relative URLs?
> I assume the use-case discussed here will work if File::toURI or toURL
> is used to create the file URL as it will have the "file:" scheme.
>
> -Alan
>

Re: jpackage on MacOs: app from pkg cannot write files and create directories inside itself

[Scott Palmer]

You should never write inside an application bundle.  (Thank the malware 
writers for these restrictions.)

On macOS your writable files should go somewhere under /Library/Application 
Support/ or  ~/Library/Application Support/

On Windows you should write to somewhere under %ProgramData%, %APPDATA%, or 
%LOCALAPPDATA%

Scott


> On Sep 6, 2019, at 8:49 AM, Andrey Volkov  wrote:
> 
> Hello.
> 
> I use jpackage (Build 14-jpackage+1-35) to bundle my Swing-based app for
> MacOS. Whereas DMG format works pretty well, PGK bundle has a serious
> issue. When I install the app from PKG, it cannot write files or create
> directories inside itself.
> I have /resource directory for my app that has a few settings and temp
> directory for file processing. For the app from PKG I get "File not Found
> (Permission Denied)" when the app tries to create a directory like
> "/Application/MyApp.app/Contents/Java/resources/temp" or any write/create
> any file inside  "/Application/MyApp.app/Contents/Java/resources/"
> Do you have any clue how to fix it for PKG bundle? I would prefer to use it
> because it has a more user-friendly installation.
> 
> BTW, Windows has a similar issue when per-user installation works fine, but
> a system-wide installation in "Program Files" lack permissions to write
> files inside "Program File/MyApp".
> 
> -- 
> Best regards,
> Andrey Volkov

Re: Comments on jpackage (JEP 343)

[Scott Palmer]

I use a very similar workflow, but I’m building for all platforms. I want the 
image to produce a simple zipped version of the app, and I want all the 
installer/bundles/packages as well. 

I also agree with all of the “would be nice to haves” - Particularly 
service/daemon support. 
I also agree with the recent comments here about getting back the user options 
support and having a way for args in the configure file to stay and be 
augmented by arguments added on the command line by the user. 

Scott

> On Sep 5, 2019, at 8:51 AM, Rachel Greenham  wrote:
> 
> (Sorry for non-threading, i read the digest)
> 
> As you've been lacking feedback from people using the jpackage EA builds, 
> here's mine FWIW.
> 
> I've been quiet because it's been working well enough for us. That said, our 
> needs and process probably simplify matters in that:
> 
> 1. We're only producing Windows installers
> 2. We've been lucky in having patient clients during this post-webstart, 
> post-javapackager disruption.
> 3. We were happy to modify our versioning to match Windows standards
> 4. Our application is non-modular
> 5. We do it in three steps: jlink to make a JRE, then jpackage to make an app 
> image, then jpackage again to make both an exe and msi installer based on 
> that image. (client slow to reply which one they'd actually prefer!) Not 
> trying to do everything in one step.
> 
> Since the fix that made new versions of our app correctly replace older ones 
> I've mostly just been testing new EA builds to make sure they don't break it! 
> They do sometimes, usually because of changes in the parameter names, and of 
> course we lost our Inno Setup customisations. I haven't yet made any attempt 
> to customise the EXE setup installer since then.
> 
> Would be nice:
> 
> 1. For it to use the supplied app icon for the installer, or be able to 
> supply another specifically for the installer. For it to be shown in the 
> installer in some fashion. Other exe customisations of straightforward 
> branding and/or flags to control what questions they're asked would be very 
> nice.
> 2. For it to be able to sign the installer in the fashion of, or actually 
> using, signtool. (Ideally internalised as installing signtool itself is a 
> pain.) Currently that's an extra step after the installers are built
> 
> But I can wait for them, I want it in a release so I can use it via 
> ToolProvider rather than execing an external JDK. All the while it's the way 
> it is it massively complicates the build.
> 
> Later would-be-nices, not for this desktop app, but ability to use it to 
> package background service-type apps, as a service for windows, using launchd 
> for osx, and systemd for linux.
> 
> -- 
> Rachel

Re: jdk-14-jpackage+1-33 on jdk.java.net

[Scott Palmer]

Unless you added the --win-console option, I think this is expected.  Windows 
has a rather silly concept of console vs. window applications.  To avoid a 
console window popping up when you don’t expected it, the default launcher is 
in ‘window’ mode, not ‘console’ mode.

You need to know which kind of windows application you are building. Command 
line tools like javac would need to be packaged with the --win-console option.

Scott

> On Aug 27, 2019, at 4:06 AM, Schnoor Jonas 
>  wrote:
> 
> First of all: Thank you very much for JPackage. This looks very promising.
> 
> To give some feedback: I just tried JPackage on Windows 10 and I believe I 
> ran into this bug: https://bugs.openjdk.java.net/browse/JDK-8211299
> It says the bug is fixed but I do not see anything written to either 
> System.out or System.err.
> To make sure it was not something I am doing inside my application I tested 
> it with a simple "Hello World" example and got the same result.
> When executing the JAR file directly using java -jar  I get the 
> expected output in the CMD window.
> 
> Can someone confirm this? Is this expected behaviour?
> 
> BTW: When running the application inside the Git Bash (with MinGW) the output 
> is displayed. But inside a Powershell/CMD window the output is _not_ 
> displayed.
> If the application is started from a batch file no output is displayed either.
> 
> -- Jonas

Re: Mechanism to maintain backwards compatibility when moving classes to different packages

[Scott Palmer]

Not worth it. How will package level access be affected? How can this be 
exploited? How will it affect security and signing when things from the same 
package aren’t *really* from the same package?

Now that the recommendation is to bundle a JRE with your application, that kind 
of backwards compatibility is becoming less critical.  If necessary, deprecate 
java.util.Random. Make an interface for RNGs to implement and go with factories 
and a service provider pattern. Sometime down the line retire java.util.Random. 

Scott

> On Jul 2, 2019, at 7:55 PM, Jacob Glickman  wrote:
> 
> Friendly reminder :)
> -- Forwarded message -
> From: Jacob Glickman 
> Date: Sat, Jun 22, 2019 at 4:42 PM
> Subject: Mechanism to maintain backwards compatibility when moving classes
> to different packages
> To: 
> 
> 
> Yesterday, Mark Reinhold introduced the idea of a java.util.random
> subpackage[1]. Obviously, moving java.util.Random into that subpackage is
> not currently an option, as that would break backwards compatibility.
> Assuming the subpackage is created, it would make sense to ultimately move
> java.util.Random into it. For that reason, I propose a new language feature
> that could make this possible:
> 
> package java.util.random previously java.util;
> 
> The syntax isn't important at the moment, but this mechanism should allow
> for users to run previously-compiled code with newer versions of Java, even
> if their code points to a class that has since been moved to a different
> package.
> 
> To eliminate potential bugs, users compiling new code shouldn't be allowed
> to reference java.util.Random, even if java.util.random.Random states that
> it previously resided in java.util.
> 
> I'm curious what you all would think of this, as it is not just applicable
> to this single example. There have been plenty of times that I've realized
> that my packages were named badly, but I'm forced to stick with that naming
> (unless I want my users to have to modify their code).
> 
> Thanks,
> 
> Jacob Glickman
> 
> [1]:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-June/060995.html

Re: JPackage application image file system layout

[Scott Palmer]

> On Jul 1, 2019, at 2:47 AM, Robert Lichtenberger  
> wrote:
> 
> While trying to update our application to the (ea-version of) jpackager I
> noticed that the executable files are now in a bin/ subdirectory, which
> will make the application update from javapackager a real pain.
> 
> For Linux this can be argumented with the Filesystem Hierarchy Standard but
> under Windows it is not common or standard to do so. The .exe file for an
> application is expected to live in the base installation directory.

It can also be argued that on Windows it is more common to launch the 
application from a shortcut in the Start menu, on the Desktop, or in the launch 
bar.
I get that this is a change from the previous behaviour so some adjustments 
need to be made, but how bad is it really? 
The JDK has always had a bin directory and many other applications follow this 
pattern on Windows as well. 

> Is there any chance this can still be changed or made configurable?

Making it configurable makes the most sense. But it may get complicated as the 
launcher exe needs to find the .cfg file without any additional info. Maybe the 
relative path to the .cfg file can be injected into the exe at build time, much 
like customizing the exe’s icon?

Regards,

Scott

Re: JPackage EA build 8 ( jdk-14-jpackage+1-8 )

[Scott Palmer]

> On Jun 27, 2019, at 4:29 PM, Andy Herrick  wrote:
> 
> 
> 
> On 6/27/2019 4:07 PM, Scott Palmer wrote:
>> I also just noticed that "--icon" is not allowed with "--package-type msi"  
>> when creating the msi using --app-image.  It should be, unless there is some 
>> other way to set the icon to show in "Add or Remove programs"?
> The --icon option needs to be used when creating the app image (the icon is 
> then put in the app-image), so it is not valid when --package-type and 
> --app-image arg are both there.
> 
> /Andy


I use the --icon option when creating the app image, but that is the icon for 
the application launcher.  There could be multiple icons in the image on 
Windows, one for each launcher. (I haven’t checked yet if that works.. trying 
multiple launchers is something that I will need to do soon.)

There are other needs for an icon when making the package.  For Windows the 
"Add or remove programs" has an icon (ARP_ICON property in the MSI).  For macOS 
the DMG has an icon - currently this is showing up as the Java coffee cup logo. 
 I want an image that identifies my company or application.

Regards,

Scott

Re: JPackage EA build 8 ( jdk-14-jpackage+1-8 )

[Scott Palmer]

On Wed, Jun 26, 2019 at 2:39 PM Andy Herrick 
wrote:

>
>
> On 6/25/2019 1:44 PM, Scott Palmer wrote:
> > I just tried this out. One thing that has changed since my last testing
> was the “create-installer” vs “--package-type” parameter.
> >
> > “--package-type all” isn’t allowed.   If I want to create .rpm and .deb,
> or .exe. and .msi, do I need to run twice now?
> Yes - the new model is that only one artifact generated by each
> invocation of the jpackage command.  To build both artifacts now
> requires running the tool twice. This avoids a problem in the previous
> implementation when one package type succeeded and another failed.
>

I'm doing things in up to three steps now... first run jpackage to create
the application image, then run once to create each of the package types I
want from the application image, e.g. deb and rpm, or msi and exe.
I assume that is the right way to do it to reduce redundant operations...
though I suspect if making a msi and an exe there may still be
optimizations possible.


> > The --help output on macOS ends with the line “Platform dependent
> options for creating the application package:” with no options listed after
> that.  Are there options for setting the background graphic image of the
> installer package and different images for each flavour of .dmg?  The .dmg
> with the Application Bundle should be able to have a different background
> image than the .dmg with a .pkg installer.  The most common contents of the
> Application Bundle .dmg are a alias to the Applications folder and an arrow
> graphic on the background to suggest dragging the app bundle to the
> Applications folder.  For a installer package no such arrow image would be
> needed, though you may have a graphic with some instructions, or just
> branding imagery.
> Currently there are no “Platform dependent options for creating the
> application package:”, but this seems like a good suggestion to add one.
> Would "mac-dmg-image" or "mac-dmg-background" be an appropriate option
> name for such an option ?
>

 I don't like "image" because we are already dealing with that term
referring to something else when using the "--app-image" parameter, so I
would go with background.

I also just noticed that "--icon" is not allowed with "--package-type msi"
when creating the msi using --app-image.  It should be, unless there is
some other way to set the icon to show in "Add or Remove programs"?

Regards,

Scott

Re: JPackage EA build 8 ( jdk-14-jpackage+1-8 )

[Scott Palmer]

I just tried this out. One thing that has changed since my last testing was the 
“create-installer” vs “--package-type” parameter.

“--package-type all” isn’t allowed.   If I want to create .rpm and .deb, or 
.exe. and .msi, do I need to run twice now?

Maybe this could be a comma separated list or the --package-type parameter 
could be specified multiple times?

This also doesn’t address the issue on macOS where the the typical distribution 
of a .pkg file is in a .dmg image.  On macOS you typically have either an 
Application Bundle (the raw macOS app image) in a .dmg, or an installer package 
(.pkg) in a .dmg.I’ve never seen a .pkg distributed on it’s own, though I 
guess there is no reason it couldn’t be.  Unlike the Application Bundle, an 
installer package really is a single file.

The --help output on macOS ends with the line “Platform dependent options for 
creating the application package:” with no options listed after that.  Are 
there options for setting the background graphic image of the installer package 
and different images for each flavour of .dmg?  The .dmg with the Application 
Bundle should be able to have a different background image than the .dmg with a 
.pkg installer.  The most common contents of the Application Bundle .dmg are a 
alias to the Applications folder and an arrow graphic on the background to 
suggest dragging the app bundle to the Applications folder.  For a installer 
package no such arrow image would be needed, though you may have a graphic with 
some instructions, or just branding imagery.

Regards,

Scott


> On Jun 24, 2019, at 2:31 PM, Andy Herrick  wrote:
> 
> The next EA build of JPackage is available at https://jdk.java.net/jpackage/
> 
> This build ( jdk-14-jpackage+1-8 ) is the first early access release based on 
> JDK-14
> 
> This release contains fixes to the following issues:
> 
> JDK-8225428: CLI change to remove "mode", rename to "package", and build only 
> one target
> JDK-8226191: jpackager --license-file option broken on windows for jdk 
> installers.
> JDK-8225569: jpackage app-image layout
> JDK-8224132: Investigate feasibility of doing SQE code coverage runs for 
> jpackage
> JDK-8225092: Several jpackage tests failes when run with jcov enabled
> JDK-8221333: Replace Inno Setup with custom MSI wrapper for .exe bundler
> JDK-8226193: BundleNameTest and BundleIdentifierTest fails if run without 
> network connection
> JDK-8223643: Provide better defined context for custom installer steps on 
> Windows
> JDK-8223402: Create tests for some Mac installer specific options
> JDK-8225023: JPackageCreateAppImageBundleNameTest fails
> JDK-8223038: JPackage code signing fails on Mac.
> JDK-8223318: jpackage --mac-bundle-name option doesn't work
> JDK-8223080: Build team code review requests.
> JDK-8223212: Code cleanup found during jpackage review
> JDK-8223586: remove jpackage dead code and other cleanup
> JDK-8223953: Fix CLASSPATH parsing for sub-directorys containing spaces
> JDK-8224748: --add-launcher option --add-modules
> JDK-8222901: different behavior when --name option not used
> JDK-8223241: jpackage cleanup from code review
> JDK-822: Use try-with-resources where feasible
> JDK-8224130: create additional automated tests for create-app-image
> JDK-8223334: Additional cleanup in jpackage tool
> JDK-8224116: populate jpackage manual tests for Linux
> JDK-8223700: Create markdown file for jpackage man pages
> JDK-8223189: Fix trailing whitespace and whitespace only file modification.
> JDK-8223321: jpackage ToolProvider is not thread-safe
> JDK-8226532: cleanup is not called when jpackage command fails.
> JDK-8224597: create automated tests for platform create-app-image options
> 
> please send feedback to core-libs-dev@openjdk.java.net
> 
> /Andy Herrick
> 

Re: jpackage DMG creation trouble

[Scott Palmer]

DMG isn’t an installer type.  The common thing would be for the Application 
Bundle to be wrapped in a DMG for distribution, or if a Package is needed, that 
would be wrapped in the DMG instead.
Creating the DMG wrapper is independent of the kind of “installer” .  On Mac 
this means no installer - the preferred drag-and-drop Application Bundle, or a 
.pkg installer because the application is not entirely encapsulated into an 
Application Bundle.

Typically on Mac the only reason to produce a .pkg is because you are 
installing a service, so there is post-install stuff to run to get the service 
configured to run automatically, etc..  Some non-daemon Application Bundles may 
need this extra setup, but it isn’t common. Since there is usually no reason to 
produce a .pkg if all you have is a stand-alone Application Bundle, seeing a 
.pkg in that context would only make me distrust it.

I typically want to create both .deb and .rpm packages on Linux, because 
customers may use a distribution based on either format, but I would rarely 
have the need to produce both a .pkg in a .dmg and a separate Application 
Bundle in a .dmg.   If I need a .pkg, the Application Bundle on it’s own would 
usually be useless because the extra post-install config would be needed for it 
to operate properly.  (Though it may be useful to me as a developer, because my 
dev system is different - I may want to run my service as an Application while 
debugging.) Usually this means I produced a service daemon.  I haven’t been 
tracking jpackage close enough, but I think the ability to create a service was 
dropped for the initial release.  I think the jpackage release has also been 
pushed out to JDK 14 now, so hopefully we can get that badly needed 
functionality back?

Scott  



> On Jun 12, 2019, at 9:28 AM, Andy Herrick  wrote:
> 
> I think the question here was what is in the dmg image.
> 
> The dmg could be an image of the pkg, or an image of the application.
> 
> Jeff says "I get both the app image *and *a pkg installer inside said dmg."
> 
> We need to look into that.
> 
> /Andy
> 
> 
> 
> On 6/12/2019 9:04 AM, Kevin Rushforth wrote:
>> Or if you only want the app in the dmg:
>> 
>> jpackage create-installer --installer-type dmg
>> 
>> -- Kevin
>> 
>> 
>> On 6/12/2019 6:02 AM, Kevin Rushforth wrote:
>>> This will likely change so that only a single package is created by 
>>> jpackage. The current EA version creates all possible package types for a 
>>> given platform by default, even when that doesn't make sense (as on a 
>>> typical Linux machine which either has Debian or RPM tools, but typically 
>>> not both).
>>> 
>>> To answer your question, you can do the following today:
>>> 
>>> jpackage create-installer --installer-type pkg
>>> 
>>> -- Kevin
>>> 
>>> 
>>> On 6/11/2019 6:04 PM, Jeff Carpenter wrote:
 Hi everyone,
 
 I'm working (for jClarity) on building some installers with jpackage. Now 
 whenever I build a dmg image, I get both the app image *and *a pkg 
 installer inside said dmg. Is there a way I can get just the app image in 
 the dmg?
 
 Thanks,
 Jeff
 
 
>>> 
>> 
> 

Re: JEP 343: Packaging Tool

[Scott Palmer]

A couple comments inline...

> On Jun 5, 2019, at 5:16 PM, mark.reinh...@oracle.com wrote:
> 
> I saw that you moved JEP 343 to “Proposed to Target,” so I spent a
> couple of hours looking at it.  You’ve made good progress but I don’t
> think this is in the “nearly finished” state that we ask of features
> in the six-month cadence.  I suggest that you move this JEP back to
> Candidate for now and continue refining it.  The next feature release,
> JDK 14, is just six months away.
> 
> Some specific observations and suggestions:
> 
>  - At the moment there are 75 open issues in JBS [1], 69 of which are
>P3 or higher.  JDK 13 will enter RDP 1 next week, so there’s not
>much time to make progress on all those issues.

I get where you are coming from, but I feel I should point out how it looks 
like the JDK is moving backwards from my perspective. When JavaFX was bundled 
with Java 8, like it or not the distribution of Java from Oracke co rained a 
packager and there was no appearance that it was JavaFX-specific (because it 
wasn’t). The. That useful tool that devs came to rely on was removed and it 
won’t be replaced for how many major versions in a row now? Because it isn’t 
ready, even though you already had been shipping a packager tool that already 
had more features than the replacement. (E.g. creating a service)

> 
>  - The use of the term “installer” in the JEP and in the command-line
>options is confusing.  The tool only creates installers on Windows
>and macOS (pkg); the other formats that it supports (macOS dmg,
>Linux deb/rpm) are OS-specific packages rather than interactive
>installers.  Consider replacing the term “installer” with “package”
>throughout.  This would also align better with the name of the tool
>itself.
> 
>  - It’s not clear why there are distinct subcommands to create an image
>vs. to create an OS-specific package.  Given the name of the tool,
>I’d expect creating a package to be the primary behavior.  An option
>to preserve the image, which is just a temporary result, could make
>sense, as well as another option to skip the creation of the
>package, but I don’t understand the need for subcommands.

I disagree with this. The primary reason to produce the image is because you 
will be incorporating it into your own installer with other things (part of a 
larger product, installer needs more custom options, etc.), or providing a 
simplified .zip distribution. 
Running the tool all the way to produce an installer/package that you are just 
going to throw away is a waste. On Windows MSI installers take forever to 
build.  So it would be a big waste if you had to wait for it. Two extra flags, 
one to say to preserve the “intermediate result” that was all you wanted, and 
another to disable creating the installer/package that you had to ask for in 
the first place to get the image. It’s awkward. Just have multiple target 
package types, including “image”. 

It is also very useful to be able to customize the image prior to generating 
the final package. (E.g. adding files in arbitrary subfolders, tweaking a 
generated file because of missing features in the packager tool, etc.). So 
building a package/installer from an image is important, and a naturally 
distinct step in the process already. 

Scott 
(Like most, I’m stuck on Java 8 until the dust settles.)

> 
>  - On a Debian machine I tried to create a package from a trivial,
>two-module application using the command
> 
>  $ jpackage create-installer -o /tmp -p lib -m org.openjdk.hello -n hello
> 
>This terminated with exit code 255 and an error message.  In Linux,
>and Unix/POSIX generally, an exit code of 255 means that the exit
>status was out of range.  I suggest you exit with the value 1 on
>errors, at least on Linux.
> 
>  - The error message from the above command was:
> 
>  Bundler RPM Bundle skipped because of a configuration problem: Can not 
> find rpmbuild 4 or newer..
>  Advice to fix: Install packages needed to build RPM, version 4 or newer.
> 
>I’m on a Debian machine, trying to create an OS-specific (i.e.,
>Debian) image, so this was a confusing message.  (Yes, I know it’s
>possible to create rpms under Debian if you have the right tools
>installed, but that’s not what I was trying to do here.)
> 
>  - What’s more, even though the tool exited on error it still produced
>a Debian package in the output directory, but I found it only by
>accident.
> 
>  - Looking at the content of the generated Debian package, the control
>file has many fields that don’t have corresponding jpackage options.
>That could be a problem for some developers.
> 
>  - The data in the Debian package would place the application into a
>directory named `/usr/bin/hello`, which is completely wrong.  Please
>see the Filesystem Hierarchy Standard [2] and the Debian Policy
>Manual [3] for details.
> 
>  - I tried to create a 

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

[Scott Palmer]

Ideally the wix code should be generated by running the heat.exe tool on the 
application image.

Scott

> On May 2, 2019, at 5:08 PM, Andy Herrick  wrote:
> 
> Alexey:
> 
> Please file Bugs for these two issues.
> 
> /Andy
> 
> 
>> On 5/2/2019 1:49 PM, Alexey Semenyuk wrote:
>> Some findings:
>> 
>> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/raw_files/new/make/launcher/Launcher-jdk.jpackage.gmk:
>>  
>> I think definitions of BUILD_JPACKAGE_APPLAUNCHEREXE and 
>> BUILD_JPACKAGE_APPLAUNCHERWEXE targets should be moved to 
>> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/make/lib/Lib-jdk.jpackage.gmk.html.
>>  Reason: these targets don't output executables into images/jdk/bin 
>> directory. They produce artifacts that stored as resources in jpackage just 
>> like other targets defined in Lib-jdk.jpackage.gmk.
>> 
>> Wix source code produced by 
>> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html
>>  doesn't comply to recommendations of how files should be packed in 
>> component. The recommendation is to use one file per a component - 
>> http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_a_file.html.
>>  However jpackage produces way less components than files:
>> ---
>> $ less config/bundle.wxi | grep '> 634
>> 
>> $ less config/bundle.wxi | grep '> 1650
>> ---
>> Data picked from my local test project.
>> 
>> http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java.html:745
>>  
>>  + " Guid=\"" + UUID.randomUUID().toString() + "\""
>> Use of random GUIDs for components is not recommended and potentially can 
>> result in issues with application updates. The recommended approach is to 
>> generate stable GUIDs - 
>> http://wixtoolset.org/documentation/manual/v3/howtos/general/generate_guids.html,
>>  
>> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-does-heat-maintain-consistent-GUIDs-td7599757.html.
>>  
>> Algorithm to create stable GUIDs is explained at 
>> https://tools.ietf.org/html/rfc4122#page-13. However we can avoid the hassle 
>> of generating stable GUIDs if we would put only one file in every component. 
>> In this case WiX is able to generate stable GUIDs for us.
>> 
>> - Alexey
>> 
>>> On 4/27/2019 8:46 PM, Philip Race wrote:
>>> Adding build-dev for the build changes. I don't know if these were 
>>> previously reviewed there,
>>> but I am not sure what the changes in NativeCompilation.gmk have to do with 
>>> jpackage.
>>> 
>>> -phil.
>>> 
 On 4/24/19, 5:47 PM, Andy Herrick wrote:
 
> On 4/24/2019 8:44 PM, Andy Herrick wrote:
> Please review  changes for [1] which is the implementation bug for 
> JEP-343.
> 
> The webrev at [2] is the total cumulative webrev of changes for the 
> jpackage tool, currently in the JDK-8200758-branch branch of the open 
> sandbox repository.
> 
> The webrev at [3] shows the changes from EA-05 to EA-06.
 sorry - the links are reversed from what is stated above. [2] is the 
 incremental webrev since EA 05, [3] is the cumulativewebrev
 /Andy
> 
> The latest EA-6 (build 49) is posted at [4].
> 
> Please send feedback to core-libs-dev@openjdk.java.net
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
> 
> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/
> 
> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/
> 
> [4] http://jdk.java.net/jpackage/
> 
> 
> /Andy
> 
> 
 
>> 
> 

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

[Scott Palmer]

I don’t mean any offence, but I have to say, I strongly disagree with nearly 
everything you’ve written below. To me, the idea of making a stream of integers 
for a simple loop counter is hackish, confusing, verbose, and basically abusing 
the stream concept.  The only part I agree with is that it is an obvious 
performance drawback as well.  A counter and a stream of integers are 
completely different concepts and should not be confused in this manner.

Scott

> On Mar 6, 2019, at 5:10 AM, Tagir Valeev  wrote:
> 
> Hello!
> 
> By the way one of the painful code patterns in modern Java is `for(int
> i = 0; i newbies and prone to errors as the variable need to be repeated three
> times. Also the variable is not effectively final, despite it never
> changes within the loop body, so could have been considered as
> redeclared on every loop iteration (like in for-each). With the new
> proposal it's possible to write `for(int i : range(0, bound).boxed())`
> (assuming import static j.u.s.IntStream.range), which looks much
> better, though it has obvious performance drawback. Moving
> IterableOnce to BaseStream would enable to use `for(int i : range(0,
> bound))` which looks even better, though again we have plenty of
> garbage (but considerably less than in previous case!). I wonder
> whether Java could evolve to the point where such kind of code would
> be a recommended way to iterate over subsequent integer values without
> any performance handicap.
> 
> With best regards,
> Tagir Valeev.
> 
> On Fri, Mar 1, 2019 at 9:47 AM Stuart Marks  wrote:
>> 
>> Hi all,
>> 
>> Please review and comment on this proposal to allow Stream instances to be 
>> used
>> in enhanced-for ("for-each") loops.
>> 
>> Abstract
>> 
>> Occasionally it's useful to iterate a Stream using a conventional loop. 
>> However,
>> the Stream interface doesn't implement Iterable, and therefore streams 
>> cannot be
>> used with the enhanced-for statement. This is a proposal to remedy that
>> situation by introducing a new interface IterableOnce that is a subtype of
>> Iterable, and then retrofitting the Stream interface to implement it. Other 
>> JDK
>> classes will also be retrofitted to implement IterableOnce.
>> 
>> Full Proposal:
>> 
>> http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html
>> 
>> Bug report:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8148917
>> 
>> Webrev:
>> 
>> http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/
>> 
>> Note, this changeset isn't ready to push yet. In particular, it has no tests
>> yet. However, the implementation is so simple that I figured I should include
>> it. Comments on the specification wording are also welcome.
>> 
>> Thanks,
>> 
>> s'marks

Re: jpackage OS X Classes directory

[Scott Palmer]

I don’t see the need. Can’t you just include whatever files you want in the 
application image?

Scott

> On Jan 19, 2019, at 9:41 AM, Michael Hall  wrote:
> 
> Going back to old legacy application building code on OS X the original OS X 
> port project came up with AppBundler. That had included a feature where a 
> Classes directory was included in /Contents/Java/Classes. This directory 
> was also automatically added into classpath. I found it convenient for adding 
> application specific resources like property files. I’m not sure I ever saw 
> anyone else mention using it. 
> 
> I am currently not finding those files in testing my jpackage app so I assume 
> that is no longer supported? It was copied when I pointed my jpackage input 
> directory to my old application’s Java directory but I am guessing it is no 
> longer in class path. I suppose just jar’ing the resources into a file in the 
> Java directory would be an easy enough fix, although to me maybe slightly 
> less convenient.
> 
> Is this, in fact, no longer supported? Is there any chance some similar 
> feature might be added?

Re: Jpackage Windows shortcuts

[Scott Palmer]

For there record, a reboot fixed my uninstall issues.

Scott

> On Jan 18, 2019, at 1:18 PM, Scott Palmer  wrote:
> 
> Add/Remove programs is called  Apps & Features now, I guess.  So we are in 
> the same place.  I’m going to reboot, as I have a Windows update to install 
> anyway.. I think maybe the msi database is very confused.
> 
> Scott
> 
>> On Jan 18, 2019, at 3:59 AM, Rachel Greenham  
>> wrote:
>> 
>> FWIW uninstall working for me from Windows 10's "Apps & features" panel. 
>> Could it be doing something different when done from "Add/Remove Programs"? 
>> And (wild guessing) might that be related to the known bug about old 
>> versions not being uninstalled properly during upgrade? 
>> <https://bugs.openjdk.java.net/browse/JDK-8214564>
>> 
>> (You might already be able to tell Windows isn't my main platform, only 
>> having to use it for this! ;-) )
>> 
>> -- 
>> Rachel
>> 
>> On 17/01/2019 16:21, Scott Palmer wrote:
>>> Note that the uninstall is still failing after I removed the spaces from
>>> the app name. I didn't mean to imply these issues were related.
>>> 
>>> On Thu, Jan 17, 2019 at 11:00 AM Andy Herrick 
>>> wrote:
>>> 
>>>> yes - seeing several problems when space in app name - filed JDK-8217331
>>>> <https://bugs.openjdk.java.net/browse/JDK-8217331> and will address.
>>>> 
>>>> /Andy
>>>> 
>>>> On 1/17/2019 10:37 AM, Scott Palmer wrote:
>>>> 
>>>> I'm creating a MSI installer. My application name did have spaces in it. I
>>>> can confirm that changing the --name parameter to something without spaces
>>>> avoids the issue, though this is still clearly a bug that needs to be 
>>>> fixed.
>>>> 
>>>> It also seems that uninstall does not work.  When I attempt it I get this
>>>> error message from Add/Remove Programs:
>>>> 
>>>> [Window Title]
>>>> C:\WINDOWS\system32\msiexec.exe
>>>> 
>>>> [Content]
>>>> Windows cannot access the specified device, path, or file. You may not
>>>> have the appropriate permissions to access the item.
>>>> 
>>>> [OK]
>>>> 
>>>> I can run C:\WINDOWS\System32\msiexec.exe, so I'm not clear on what the
>>>> real issue is. Maybe a bad message from Windows and the path that can't be
>>>> accessed is a parameter to msiexec??
>>>> 
>>>> I'm using Microsoft Windows [Version 10.0.17134.471]
>>>> 
>>>> Regards,
>>>> 
>>>> Scott
>>>> 
>>>> 
>>>> On Thu, Jan 17, 2019 at 8:20 AM Andy Herrick 
>>>> wrote:
>>>> 
>>>>> Simple tests of --win-menu and --win-shortcut options on Windows 7 are
>>>>> working for me.  Shortcuts are created as expected when running either
>>>>> the exe or msi installer generated.
>>>>> 
>>>>> Can you share the full OS version and full command you use , perhaps
>>>>> some combination of options is not working.
>>>>> 
>>>>> /Andy
>>>>> 
>>>>> 
>>>>> On 1/16/2019 7:47 PM, Scott Palmer wrote:
>>>>>> Are the flags to create shortcuts in the start menu and on the desktop
>>>>> supposed to be working at this point? I tried them and they had no effect.
>>>>>> Scott
>>>>> 
>> 
> 

Re: Jpackage Windows shortcuts

[Scott Palmer]

Add/Remove programs is called  Apps & Features now, I guess.  So we are in the 
same place.  I’m going to reboot, as I have a Windows update to install 
anyway.. I think maybe the msi database is very confused.

Scott

> On Jan 18, 2019, at 3:59 AM, Rachel Greenham  wrote:
> 
> FWIW uninstall working for me from Windows 10's "Apps & features" panel. 
> Could it be doing something different when done from "Add/Remove Programs"? 
> And (wild guessing) might that be related to the known bug about old versions 
> not being uninstalled properly during upgrade? 
> <https://bugs.openjdk.java.net/browse/JDK-8214564>
> 
> (You might already be able to tell Windows isn't my main platform, only 
> having to use it for this! ;-) )
> 
> -- 
> Rachel
> 
> On 17/01/2019 16:21, Scott Palmer wrote:
>> Note that the uninstall is still failing after I removed the spaces from
>> the app name. I didn't mean to imply these issues were related.
>> 
>> On Thu, Jan 17, 2019 at 11:00 AM Andy Herrick 
>> wrote:
>> 
>>> yes - seeing several problems when space in app name - filed JDK-8217331
>>> <https://bugs.openjdk.java.net/browse/JDK-8217331> and will address.
>>> 
>>> /Andy
>>> 
>>> On 1/17/2019 10:37 AM, Scott Palmer wrote:
>>> 
>>> I'm creating a MSI installer. My application name did have spaces in it. I
>>> can confirm that changing the --name parameter to something without spaces
>>> avoids the issue, though this is still clearly a bug that needs to be fixed.
>>> 
>>> It also seems that uninstall does not work.  When I attempt it I get this
>>> error message from Add/Remove Programs:
>>> 
>>> [Window Title]
>>> C:\WINDOWS\system32\msiexec.exe
>>> 
>>> [Content]
>>> Windows cannot access the specified device, path, or file. You may not
>>> have the appropriate permissions to access the item.
>>> 
>>> [OK]
>>> 
>>> I can run C:\WINDOWS\System32\msiexec.exe, so I'm not clear on what the
>>> real issue is. Maybe a bad message from Windows and the path that can't be
>>> accessed is a parameter to msiexec??
>>> 
>>> I'm using Microsoft Windows [Version 10.0.17134.471]
>>> 
>>> Regards,
>>> 
>>> Scott
>>> 
>>> 
>>> On Thu, Jan 17, 2019 at 8:20 AM Andy Herrick 
>>> wrote:
>>> 
>>>> Simple tests of --win-menu and --win-shortcut options on Windows 7 are
>>>> working for me.  Shortcuts are created as expected when running either
>>>> the exe or msi installer generated.
>>>> 
>>>> Can you share the full OS version and full command you use , perhaps
>>>> some combination of options is not working.
>>>> 
>>>> /Andy
>>>> 
>>>> 
>>>> On 1/16/2019 7:47 PM, Scott Palmer wrote:
>>>>> Are the flags to create shortcuts in the start menu and on the desktop
>>>> supposed to be working at this point? I tried them and they had no effect.
>>>>> Scott
>>>> 
> 

Re: Compact Number Formatting and Fraction Digits

[Scott Palmer]

On Jan 17, 2019, at 2:22 PM, Gunnar Morling  wrote:

>> since you don’t actually want a minimum.
> 
> I'd like to have 1 fractional digit unless it's 0:
> 
> 1,000 -> 1K (*not* 1.0K)
> 1,500 -> 1.5K
> 
> --Gunnar

That’s exactly what setting the maximum fraction digits to 1 does. 

Scott


> 
>> Am Do., 17. Jan. 2019 um 19:15 Uhr schrieb Scott Palmer :
>> 
>> 
>> On Jan 17, 2019, at 12:42 PM, Gunnar Morling  wrote:
>> 
>>>> this could be a good value add to introduce an API [...]
>>> 
>>> Should I file a JDK issue then (not sure I can even)?
>>> 
>>>> Wouldn’t this be accomplished with setMaximumFractionDigits(1) ?
>>> 
>>> That wouldn't achieve that there's no fraction digit(s) in case of
>>> trailing 0s.
>> 
>> Yes it does. I just tried. Don’t set a minimum fraction digits, since you 
>> don’t actually want a minimum.
>> 
>> Scott
>> 
>>> 
>>>> Am Do., 17. Jan. 2019 um 15:50 Uhr schrieb Scott Palmer 
>>>> :
>>>> 
>>>> Wouldn’t this be accomplished with setMaximumFractionDigits(1) ?
>>>> 
>>>>> On Jan 17, 2019, at 5:13 AM, Nishit Jain  wrote:
>>>>> 
>>>>> Hi Gunnar,
>>>>> 
>>>>> Currently there is no way to obtain the below expected behavior (to get 
>>>>> 1K) when min fraction digit is set to non-zero value. I think that is not 
>>>>> even expected when min fraction digits is set, but considering the 
>>>>> objective of compact number formatting this could be a good value add to 
>>>>> introduce an API which if set, truncates trailing fractional zeros while 
>>>>> formatting output. This may need some thought process on its feasibility.
>>>>> 
>>>>> Regards,
>>>>> Nishit Jain
>>>>>> On 17-01-2019 14:37, Gunnar Morling wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> I took a look at the compact number formatting recently added in JDK 12.
>>>>>> 
>>>>>> There's setMinimumFractionDigits() to control the number of fractional
>>>>>> digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but
>>>>>> it also will format 1,000 as 1.0K. Is there a way to have fractional
>>>>>> digits but remove trailing zeros, so that 1,500 and 1,000 would be
>>>>>> formatted as 1.5K and 1K, respectively?

Re: Compact Number Formatting and Fraction Digits

[Scott Palmer]

On Jan 17, 2019, at 12:42 PM, Gunnar Morling  wrote:

>> this could be a good value add to introduce an API [...]
> 
> Should I file a JDK issue then (not sure I can even)?
> 
>> Wouldn’t this be accomplished with setMaximumFractionDigits(1) ?
> 
> That wouldn't achieve that there's no fraction digit(s) in case of
> trailing 0s.

Yes it does. I just tried. Don’t set a minimum fraction digits, since you don’t 
actually want a minimum. 

Scott

> 
>> Am Do., 17. Jan. 2019 um 15:50 Uhr schrieb Scott Palmer :
>> 
>> Wouldn’t this be accomplished with setMaximumFractionDigits(1) ?
>> 
>>> On Jan 17, 2019, at 5:13 AM, Nishit Jain  wrote:
>>> 
>>> Hi Gunnar,
>>> 
>>> Currently there is no way to obtain the below expected behavior (to get 1K) 
>>> when min fraction digit is set to non-zero value. I think that is not even 
>>> expected when min fraction digits is set, but considering the objective of 
>>> compact number formatting this could be a good value add to introduce an 
>>> API which if set, truncates trailing fractional zeros while formatting 
>>> output. This may need some thought process on its feasibility.
>>> 
>>> Regards,
>>> Nishit Jain
>>>> On 17-01-2019 14:37, Gunnar Morling wrote:
>>>> Hi,
>>>> 
>>>> I took a look at the compact number formatting recently added in JDK 12.
>>>> 
>>>> There's setMinimumFractionDigits() to control the number of fractional
>>>> digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but
>>>> it also will format 1,000 as 1.0K. Is there a way to have fractional
>>>> digits but remove trailing zeros, so that 1,500 and 1,000 would be
>>>> formatted as 1.5K and 1K, respectively?

Re: Jpackage Windows shortcuts

[Scott Palmer]

Note that the uninstall is still failing after I removed the spaces from
the app name. I didn't mean to imply these issues were related.

On Thu, Jan 17, 2019 at 11:00 AM Andy Herrick 
wrote:

> yes - seeing several problems when space in app name - filed JDK-8217331
> <https://bugs.openjdk.java.net/browse/JDK-8217331> and will address.
>
> /Andy
>
> On 1/17/2019 10:37 AM, Scott Palmer wrote:
>
> I'm creating a MSI installer. My application name did have spaces in it. I
> can confirm that changing the --name parameter to something without spaces
> avoids the issue, though this is still clearly a bug that needs to be fixed.
>
> It also seems that uninstall does not work.  When I attempt it I get this
> error message from Add/Remove Programs:
>
> [Window Title]
> C:\WINDOWS\system32\msiexec.exe
>
> [Content]
> Windows cannot access the specified device, path, or file. You may not
> have the appropriate permissions to access the item.
>
> [OK]
>
> I can run C:\WINDOWS\System32\msiexec.exe, so I'm not clear on what the
> real issue is. Maybe a bad message from Windows and the path that can't be
> accessed is a parameter to msiexec??
>
> I'm using Microsoft Windows [Version 10.0.17134.471]
>
> Regards,
>
> Scott
>
>
> On Thu, Jan 17, 2019 at 8:20 AM Andy Herrick 
> wrote:
>
>> Simple tests of --win-menu and --win-shortcut options on Windows 7 are
>> working for me.  Shortcuts are created as expected when running either
>> the exe or msi installer generated.
>>
>> Can you share the full OS version and full command you use , perhaps
>> some combination of options is not working.
>>
>> /Andy
>>
>>
>> On 1/16/2019 7:47 PM, Scott Palmer wrote:
>> > Are the flags to create shortcuts in the start menu and on the desktop
>> supposed to be working at this point? I tried them and they had no effect.
>> >
>> > Scott
>>
>>
>

Re: Jpackage Windows shortcuts

[Scott Palmer]

I'm creating a MSI installer. My application name did have spaces in it. I
can confirm that changing the --name parameter to something without spaces
avoids the issue, though this is still clearly a bug that needs to be fixed.

It also seems that uninstall does not work.  When I attempt it I get this
error message from Add/Remove Programs:

[Window Title]
C:\WINDOWS\system32\msiexec.exe

[Content]
Windows cannot access the specified device, path, or file. You may not have
the appropriate permissions to access the item.

[OK]

I can run C:\WINDOWS\System32\msiexec.exe, so I'm not clear on what the
real issue is. Maybe a bad message from Windows and the path that can't be
accessed is a parameter to msiexec??

I'm using Microsoft Windows [Version 10.0.17134.471]

Regards,

Scott


On Thu, Jan 17, 2019 at 8:20 AM Andy Herrick 
wrote:

> Simple tests of --win-menu and --win-shortcut options on Windows 7 are
> working for me.  Shortcuts are created as expected when running either
> the exe or msi installer generated.
>
> Can you share the full OS version and full command you use , perhaps
> some combination of options is not working.
>
> /Andy
>
>
> On 1/16/2019 7:47 PM, Scott Palmer wrote:
> > Are the flags to create shortcuts in the start menu and on the desktop
> supposed to be working at this point? I tried them and they had no effect.
> >
> > Scott
>
>

Re: Compact Number Formatting and Fraction Digits

[Scott Palmer]

Wouldn’t this be accomplished with setMaximumFractionDigits(1) ?

> On Jan 17, 2019, at 5:13 AM, Nishit Jain  wrote:
> 
> Hi Gunnar,
> 
> Currently there is no way to obtain the below expected behavior (to get 1K) 
> when min fraction digit is set to non-zero value. I think that is not even 
> expected when min fraction digits is set, but considering the objective of 
> compact number formatting this could be a good value add to introduce an API 
> which if set, truncates trailing fractional zeros while formatting output. 
> This may need some thought process on its feasibility.
> 
> Regards,
> Nishit Jain
> On 17-01-2019 14:37, Gunnar Morling wrote:
>> Hi,
>> 
>> I took a look at the compact number formatting recently added in JDK 12.
>> 
>> There's setMinimumFractionDigits() to control the number of fractional
>> digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but
>> it also will format 1,000 as 1.0K. Is there a way to have fractional
>> digits but remove trailing zeros, so that 1,500 and 1,000 would be
>> formatted as 1.5K and 1K, respectively?

Jpackage Windows shortcuts

[Scott Palmer]

Are the flags to create shortcuts in the start menu and on the desktop supposed 
to be working at this point? I tried them and they had no effect. 

Scott

Re: jpackage custom resources not found

[Scott Palmer]

> On Jan 15, 2019, at 11:43 AM, Michael Hall  wrote:
>> On Jan 15, 2019, at 10:35 AM, Andy Herrick  wrote:
>> On 1/15/2019 11:25 AM, Michael Hall wrote:
 On Jan 15, 2019, at 10:19 AM, Andy Herrick  wrote:
 
 On 1/15/2019 11:04 AM, Michael Hall wrote:
> java -version
> openjdk version "12-internal" 2019-03-19
> OpenJDK Runtime Environment (build 12-internal+0-jdk12-jpackage.7)
> OpenJDK 64-Bit Server VM (build 12-internal+0-jdk12-jpackage.7, mixed 
> mode, sharing)
 This is the first jpackage EA build that was based on JDK12.
 The second jpackage EA build is based on JDK13. (as will be any subsequent 
 jpackage EA builds).
 
 Real JDK12 builds will not have jpackage.  Even normal JDK13 builds will 
 not have jpackage till the JEP is targeted and the sandbox code is then 
 integrated into the mainline JDK.
>>> Yes, I had installed that version as well. The first EA.
>>> So removing the jdk-13 fell back to that one.
>>> 
>>> ~/Documents/jdk-13.jdk/Contents/home/bin/jpackage --version
>>> jpackage version 13-internal
>>> 
>>> Shows the second EA jpackage can be explicitly invoked against a current 
>>> jdk-12. But I understand it isn’t supported that way so why normally do it?
>> 
>> Actually, once jpackage is invoked the path is not used. jpackage itself 
>> will run with the jre it comes with. Without -- runtime-image specified, 
>> jpackage will package the app with runtime image it comes with.  If 
>> --runtime-image is specified, it will package the app with the specified 
>> runtime.
>> 
> Thats interesting too. How does it manage to do that, to run with the JRE 
> it’s packaged with if the command is invoked command line by absolute path?

I believe that is how all the commands in the bin folder of the JDK work - 
intentionally.  

> If nothing has been done to make the wrapping JDK an available JRE/JDK? Not 
> in JavaVirtualMachines, no JAVA_HOME set, no JRE set up at all. 

You are explicitly invoking commands of that JDK.  What would you expect if you 
ran ‘~/Documents/jdk-13.jdk/Contents/home/bin/java’  ?


Regards,

Scott

Re: Modular Applications - Regression

[Scott Palmer]

Aren’t you just saying that jlink works when you don’t use the stuff that broke?

Can you use jlink with JAXB or JAX-WS that does not rely on the .jmod files 
from JDK 9 or 10?

Is there a way to use JAXB or JAX-WS on the module path like there was with JDK 
9 & 10?

From what I can tell, if one of the modules you need is JAXB or JAX-WS and you 
already had this working with Java 9 or 10, you have to make a lot of changes.  
You can’t build a JRE image with jlink that contains the new replacements for 
JAXB or JAX-WS.  You can include JAXB or JAX-WS on the classpath, but you can’t 
go back to how it worked with JDK 9 & 10.  

Applications based on a JRE image that includes the java.xml.bind, java.xml.ws, 
or java.activation modules can’t be made to work anymore without resorting to 
hacks like running jlink to pull the .jmod files for those modules from JDK 10 
and the rest of the  runtime from JDK 11.

Scott


> On Jan 14, 2019, at 2:37 PM, Bernd Eckenfels  wrote:
> 
> JLink works fine with applications on the classpath, all you have to do is to 
> list the modules needed manually (and JDeps helps with that).
> 
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> 
> Von: core-libs-dev  im Auftrag von 
> Scott Palmer 
> Gesendet: Montag, Januar 14, 2019 8:16 PM
> An: Alan Bateman
> Cc: core-libs-dev
> Betreff: Re: Modular Applications - Regression
> 
> 
> 
>> On Jan 14, 2019, at 10:33 AM, Alan Bateman  wrote:
>> 
>> On 14/01/2019 15:03, Scott Palmer wrote:
>>> :
>>> 
>>> Does this not require ALL dependencies - down the entire dependency chain, 
>>> including every transitive dependency, to be 100% modular?
>> Look for "automatic modules", this is how the module system facilitates 
>> top-down migration where you can migrate to modules without waiting 
>> everything you depend on to migrate first. Automatic modules also support 
>> bridging to the class path so you can migrate without moving everything from 
>> the class path to module name.
> 
> Sorry, I’m asking this in the context of building a modular app that I can 
> then run jlink or jpackage on. (I *think* I understand automatic modules.) 
> However, a workflow that will run perfectly fine with JDK 9 & 10 can’t easily 
> be ported to JDK 11 because jlink can't work with automatic modules and 
> java.activation is no-longer available as an explicit module (until the issue 
> you cited is fixed, but note that the module name has changed, thus requiring 
> a stub module for modules that are expecting a module named java.activation).
> 
>> 
>>> 
>>> I don’t know of many applications outside of those included in the JDK 
>>> (where dependencies are not an option) that this restriction actually 
>>> applies to. In fact since Java 11 there is a regression where applications 
>>> that could be built as modular with JDK 9 & 10 no longer can be, because 
>>> the java.activation module was removed and no modular replacement is 
>>> available. Many dependency chains lead to java.activation.
>> The JavaBeans Activation Framework (JAF) was always maintained as a project 
>> in Java EE, never here. In any case, you can download JAF from Maven and 
>> deploy it on the module path, it should just work. The only issue with link 
>> time where it needs to be migrated to an explicit module before it can be 
>> linked into a run-time image. There is an issue in its Eclipse project to 
>> migrate it to an explicit module [1].
> 
> This issue breaks many cases where jlink used to work. This is why I refer to 
> the current state of things as a regression. It’s more than a simple matter 
> of obtaining the replacement module for the modules that were removed from 
> the JDK - because no such modules currently exist.
> 
> Even if you modularize your library or application - you can’t run jlink on 
> it if the dependency chain ever leads to an automatic module. Therefore 
> jpackage and jlink tools can’t work on projects that they previously could 
> work on due to the changes in the JDK being made without a suitable 
> replacement ready for java.activation. Somehow java.activation became 
> un-modularized in the process of removing it from the JDK.
> 
> So more to the point - very few application modules are suitable for jlink 
> input. The only practical case seems to be to run jlink by explicitly 
> including only modules that have no automatic module transitive dependencies 
> (e.g. JavaFX). Even that can’t be done to include JAXB or JAX-WS into a Java 
> 11 JRE image, to make a JRE compatible with Java 9 & 10, because of 
> java.activation
> 
> Is that correct?
> 
> Scott
> 
>> 
>> -Alan
>> 
>> [1] https://github.com/eclipse-ee4j/jaf/issues/13
> 

Re: Modular Applications - Regression

[Scott Palmer]

> On Jan 14, 2019, at 10:33 AM, Alan Bateman  wrote:
> 
> On 14/01/2019 15:03, Scott Palmer wrote:
>> :
>> 
>> Does this not require ALL dependencies - down the entire dependency chain, 
>> including every transitive dependency, to be 100% modular?
> Look for "automatic modules", this is how the module system facilitates 
> top-down migration where you can migrate to modules without waiting 
> everything you depend on to migrate first. Automatic modules also support 
> bridging to the class path so you can migrate without moving everything from 
> the class path to module name.

Sorry, I’m asking this in the context of building a modular app that I can then 
run jlink or jpackage on. (I *think* I understand automatic modules.)  However, 
a workflow that will run perfectly fine with JDK 9 & 10 can’t easily be ported 
to JDK 11 because jlink can't work with automatic modules and java.activation 
is no-longer available as an explicit module (until the issue you cited is 
fixed, but note that the module name has changed, thus requiring a stub module 
for modules that are expecting a module named java.activation).  

> 
>> 
>> I don’t know of many applications outside of those included in the JDK 
>> (where dependencies are not an option) that this restriction actually 
>> applies to.  In fact since Java 11 there is a regression where applications 
>> that could be built as modular with JDK 9 & 10 no longer can be, because the 
>> java.activation module was removed and no modular replacement is available.  
>> Many dependency chains lead to java.activation.
> The JavaBeans Activation Framework (JAF) was always maintained as a project 
> in Java EE, never here. In any case, you can download JAF from Maven and 
> deploy it on the module path, it should just work. The only issue with link 
> time where it needs to be migrated to an explicit module before it can be 
> linked into a run-time image. There is an issue in its Eclipse project to 
> migrate it to an explicit module [1].

This issue breaks many cases where jlink used to work.  This is why I refer to 
the current state of things as a regression.  It’s more than a simple matter of 
obtaining the replacement module for the modules that were removed from the JDK 
- because no such modules currently exist.

Even if you modularize your library or application - you can’t run jlink on it 
if the dependency chain ever leads to an automatic module.  Therefore jpackage 
and jlink tools can’t work on projects that they previously could work on due 
to the changes in the JDK being made without a suitable replacement ready for 
java.activation.  Somehow java.activation became un-modularized in the process 
of removing it from the JDK.

So more to the point - very few application modules are suitable for jlink 
input.  The only practical case seems to be to run jlink by explicitly 
including only modules that have no automatic module transitive dependencies 
(e.g. JavaFX).  Even that can’t be done to include JAXB or JAX-WS into a Java 
11 JRE image, to make a JRE compatible with Java 9 & 10, because of 
java.activation 

Is that correct?

Scott

> 
> -Alan
> 
> [1] https://github.com/eclipse-ee4j/jaf/issues/13

Modular Applications - Regression

[Scott Palmer]

Hi, 

I’ld like to confirm something, because I see suggestions to “build X as a 
modular app” or “build as a modular jar” and I’m wondering if I’m missing 
something.  These options don’t seem to be practical for most applications.

Does this not require ALL dependencies - down the entire dependency chain, 
including every transitive dependency, to be 100% modular?

I don’t know of many applications outside of those included in the JDK (where 
dependencies are not an option) that this restriction actually applies to.  In 
fact since Java 11 there is a regression where applications that could be built 
as modular with JDK 9 & 10 no longer can be, because the java.activation module 
was removed and no modular replacement is available.  Many dependency chains 
lead to java.activation.

Am I correct that this is the current state of things when trying to create a 
Java module?  I feel I must be missing something because I’m not seeing the 
expected complaints over the app-breaking regression of the removed modules no 
longer being available as modules.  Is it just that nobody is making modular 
apps yet?

Regards,

Scott


> On Jan 14, 2019, at 9:34 AM, Andy Herrick  wrote:
> …

> you can avoid that by running jlink first, and creating a minimal jdk-11.0.1 
> runtime image for your app, or by building EazyCNC.jar as a modular app (or 
> as a modular jar which you may have already done for all I know)

Re: latest changes in java.lang.Class

[Scott Palmer]

The string concatenation nested in the append argument is also strange. Won’t 
javac make an new StringBuilder to handle that? And single character appends 
should be done with chars ‘.’ not strings “.”

Scott

> On Dec 30, 2018, at 7:16 AM, Andrew Luo  
> wrote:
> 
> Stream.of should not be used with null.
> 
> https://docs.oracle.com/javase/9/docs/api/java/util/stream/Stream.html#of-T-
> 
> I think you'd be right if it were Stream.ofNullable, and there does appear to 
> be a bug in that code (never appended to sb) - thanks for pointing that out...
> 
> Thanks,
> 
> -Andrew
> 
> -Original Message-
> From: core-libs-dev  On Behalf Of 
> ?? ???
> Sent: Saturday, December 29, 2018 11:23 PM
> To: core-libs-dev 
> Subject: latest changes in java.lang.Class
> 
> Hi,
> 
> looking into Class::methodToString I've found some changes done into it 
> recently in JDK 11 repository.
> 
> Currently the method looks like this:
> 
> private String methodToString(String name, Class[] argTypes) {
> StringBuilder sb = new StringBuilder();
> sb.append(getName() + "." + name + "(");
> if (argTypes != null) {
> Stream.of(argTypes).map(c -> {return (c == null) ? "null" : 
> c.getName();}).
> collect(Collectors.joining(","));
> }
> sb.append(")");
> return sb.toString();
> }
> 
> Here result of Stream.collect() is ignored, i. e. even when condition 
> argTypes != null is true nothing is appended to sb.
> It seems in this case we either don’t need this `if` branch or need to append 
> to sb.
> 
> Am I missing something?
> 
> Kind regards,
> Sergey Tsypanov

Re: jpackage EA Build 0

[Scott Palmer]

If the main jar is in a subfolder the .cfg file is written incorrectly leading 
to: 
  
  Error: Could not find or load main class 
  Caused by: java.lang.ClassNotFoundException: 

Which I only found by manually running:

./MyApp.app/Contents/MacOS/MyApp

as double clicking doesn’t seem to show that output anywhere (I tried to find 
it in the Console.app output, but didn’t).

In my case the main jar is in a ‘libs’ subfolder.  The image is built 
correctly, with the subfolder under the ‘Java’ folder in the Mac application 
bundle.  However, the cfg file had:

  app.mainjar=MyMainJar-1.0.0.jar

instead of:

app.mainjar=libs/MyMainJar-1.0.0.jar


When I manually made that edit, it started to work.


Scott


> On Dec 14, 2018, at 7:46 AM, Andy Herrick  wrote:
> 
> I am pleased to announce that the first EA build of jpackage is now available 
> at : https://jdk.java.net/jpackage/
> 
> This is an early access build of JEP 343: Packaging Tool 
> , aimed at testing a prototype 
> implementation of jpackage,
> 
> This build is intended for developers interested in jpackage, and is provided 
> as a convenience so that they don't need to build from the source code 
>  (branch="JDK-8200758-branch").
> 
> Warning: This build is based on an incomplete version of JDK 12 
> .
> 
> Please send feedback via e-mail to core-libs-dev@openjdk.java.net
> 
> /Andy
> 

Re: Proposal: ArrayList constructor perforrmance improvement

[Scott Palmer]

> On Dec 18, 2018, at 12:58 PM, Jason Mehrens  wrote:
> 
> Hi Steve,
> 
>> ArrayList has a constructor which takes an arbitrary Collection as a 
>> parameter. This constructor will create an iterator over the collection 
>> ;and it will add each entry returned to the ArrayList. 
> 
>> We have found that quite a lot of the time the object passed as a 
>> parameter is in fact an instance of ArrayList. 
> 
>> In the case of an ArrayList it is possible to significantly increase the 
>> performance of the method since there is no need for an iterator - the 
>> backing array can be directly copied.
> 
> Maybe I'm looking at a different version of the ArrayList source code but it 
> seems that the ArrayList constructor calls c.toArray().  If the given 
> Collection is an ArrayList then that will call the overridden 
> ArrayList.toArray which directly copies the backing array once and doesn't 
> create an iterator.  I would assume that most collections provide an 
> optimized toArray().
> 
> Jason

That makes sense, but the benchmarks show a notable improvement. It is worth 
taking a closer look to see what is going on to account for that.

toArray uses:
  Arrays.copyOf(elementData, size);
which *should* be faster than:
  elementData = new Object[((ArrayList)c).elementData.length];
  System.arraycopy(((ArrayList)c).elementData, 0, elementData, 0, 
((ArrayList)c).elementData.length);

I say should be faster, because, unlike ‘new’, internally it think it is an 
intrinsic that is able to get away with not zeroing the destination array prior 
to copying.  Otherwise it is basically the same implementation, with a test to 
choose between new or Array.newInstance for creating the array.  I wouldn’t 
think that test could account for the performance difference, but that’s why it 
needs a closer look IMO.


Scott

Re: jpackage EA Build 0

[Scott Palmer]

I finally got to the point where I can play with this…

I’m just using trial and error, trying to figure out what to do based on the 
output of package --help and responding to error messages to guide me.

I’ve already used jlink to create a runtime (including JavaFX) that I want to 
use with my non-modular application.  I’ve put a bunch of files that my 
application requires in an ‘app’ folder

/Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home/bin/jpackage 
create-installer --input /Users/scott/dev/AdminApp/build/image/app, 
--runtime-image /Users/scott/dev/AdminApp/build/image/runtime --output 
/Users/scott/dev/AdminApp/build/installer --build-root 
/Users/scott/dev/AdminApp/build/tmpInst --name "Server Admin" --main-jar 
/Users/scott/dev/AdminApp/build/libs/AdminApp-1.0.4.jar —class 
my.company.serveradmin.ServerAdminApp


Bundler Mac App Store Ready Bundler skipped because of a configuration problem: 
java.lang.RuntimeException: File 
/Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home/jmods does not 
belong to /Users/scott/dev/AdminApp/build/image/app
Bundler DMG Installer skipped because of a configuration problem: 
java.lang.RuntimeException: File 
/Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home/jmods does not 
belong to /Users/scott/dev/AdminApp/build/image/app
Bundler PKG Installer skipped because of a configuration problem: 
java.lang.RuntimeException: File 
/Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home/jmods does not 
belong to /Users/scott/dev/AdminApp/build/image/app


I don’t understand the error message.  What is it complaining about?

I figured out that I was using the wrong value for the --main-jar .. I needed 
the name relative to my input folder, so I changed that and it produced output, 
but the error message I got above was not at all helpful.

Then I looked at the directory structure of the application bundle.  My input 
directory looked like

app/
   libs/
 

But the ‘libs’ subfolder was missing from the produced bundle. All the jars 
that were in it were placed directly in the ‘Java’ folder of the app bundle.

So then I added a README.txt file under /app as a sibling of the libs folder.  
That caused the bundled structure to match what I had, with a README.txt and 
‘libs’ folder containing all my jars, all located in the ‘Java’ folder of the 
application bundle.
I think that inconsistent layout should be corrected.

It would be good to document what is expected in the input directory,  how 
those files are used, and where they end up in the output directory.  --icon 
says it takes the icon file name (not a path), but I don’t want to install the 
icon file as a separate discrete file in my application, so where is it looking 
for it? 
I complete example for each of the sample usages shown by "package --help" 
would go a long way.


Scott


> On Dec 14, 2018, at 7:46 AM, Andy Herrick  wrote:
> 
> I am pleased to announce that the first EA build of jpackage is now available 
> at : https://jdk.java.net/jpackage/
> 
> This is an early access build of JEP 343: Packaging Tool 
> , aimed at testing a prototype 
> implementation of jpackage,
> 
> This build is intended for developers interested in jpackage, and is provided 
> as a convenience so that they don't need to build from the source code 
>  (branch="JDK-8200758-branch").
> 
> Warning: This build is based on an incomplete version of JDK 12 
> .
> 
> Please send feedback via e-mail to core-libs-dev@openjdk.java.net
> 
> /Andy
> 

Re: jpackage EA Build 0

[Scott Palmer]

Building a non-modular app on macOS:

In the output folder I find a .dmg file and a .pkg file. However, the .dmg 
produced contains both the application bundle AND the .pkg installer.  It 
should not contain the .pkg

Scott


> On Dec 14, 2018, at 7:46 AM, Andy Herrick  wrote:
> 
> I am pleased to announce that the first EA build of jpackage is now available 
> at : https://jdk.java.net/jpackage/
> 
> This is an early access build of JEP 343: Packaging Tool 
> , aimed at testing a prototype 
> implementation of jpackage,
> 
> This build is intended for developers interested in jpackage, and is provided 
> as a convenience so that they don't need to build from the source code 
>  (branch="JDK-8200758-branch").
> 
> Warning: This build is based on an incomplete version of JDK 12 
> .
> 
> Please send feedback via e-mail to core-libs-dev@openjdk.java.net
> 
> /Andy
> 

Re: -jar option and the modulepath

[Scott Palmer]

I’m curious how this relates to the -m or —module option.
I had though it looked like the module equivalent of the -jar option.

Cheers,

Scott

> On Nov 23, 2018, at 12:41 PM, Richard Hillegas  wrote:
> 
> Thanks, Alan.
> 
> On 11/23/18 12:06 AM, Alan Bateman wrote:
>> On 22/11/2018 19:27, Richard Hillegas wrote:
>>> Can I scribble something in a jar file manifest which will cause "java 
>>> -jar" to boot with a modulepath rather than a classpath? I do not see any 
>>> support for a modulepath attribute in the Java 9 jar file documentation at 
>>> https://docs.oracle.com/javase/9/docs/specs/jar/jar.html. My sense is that 
>>> the -jar option commits the JVM to using a classpath.
>> There is no support for executable modular JARs at this time. It's part of a 
>> bigger topic that is tracked as #MultiModuleExecutableJARs. Some prototypes 
>> during JDK 9 but the decision at the time was to defer it to some future 
>> effort. So when you run with `java -jar` then it puts the JAR file on the 
>> class path (exactly as it did in all previous releases).
>> 
>> -Alan
>> 
> 

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

[Scott Palmer]

On Oct 30, 2018, at 1:10 PM, Andy Herrick  wrote:
> 
> On 10/30/2018 12:09 PM, Alan Bateman wrote:
>>> ...
>> Alex has suggested jdk.jpackager to avoid giving the impression that it's 
>> the "JDK packager". Also several existing tool modules have the tool name in 
>> the module name (jdk.jdeps, jdk.jlink, jdk.jshell, ...).
> This seems reasonable, jdk.packager -> jdk.jpackager
> still leaves the question of jdk.packager.services -> jdk.jpackager.services 
> (or jdk.jpackager.runtime) or something else ?


I prefer jdk.jpackager.runtime.  I think  it makes more sense given the likely 
future functions that will be implemented there.  User JVM args support and 
single instance support don’t seem to fit the ’services’ name.  

I’m also hoping that the service daemon support will make it into the JDK 12 
deliverable.  Is that out of the question at this point?

Regards,

Scott

Re: Draft JEP proposal: JDK-8200758: Packaging Tool

[Scott Palmer]

Right, I explicitly want to make the distinction between this and the “Multiple 
launchers” stretch goal.  I want to use the "multiple launchers” as well. 

One way that I have used multiple launchers (on Linux, I don’t think I could 
get it to work on Windows) is to have one launcher be a service/daemon and a 
second launcher be a configuration utility for the service.

I have some cases where multiple services are installed, each can be 
independent, but normally they are part of several different product suites.  
The total product itself can share a JRE, that’s where I want the option to 
specify a private, shared JRE.  

The JRE often makes up the majority of the application’s size.  This can come 
down with jlink of course, but because of the nature of our product - with many 
plugins that are installed after the fact, we need a full JRE as we can’t 
anticipate what modules the plugins will need.

Scott

> On Jul 27, 2018, at 10:14 AM, Andy Herrick  wrote:
> 
> I don't see why this isn't feasible, and will file such an enhancement 
> request, but should be possible to deliver a suite of apps in one bundle.  
> This is the third 'stretch goal' : "Multiple launchers (enables a suite of 
> applications to be bundled in a single self-contained application package)"
> 
> /Andy
> 
> 
> On 7/27/2018 9:13 AM, Kevin Rushforth wrote:
>> > Will it be possible to NOT include the JRE, but specify instead a 
>> > pre-existing location for the JRE?
>> 
>> This does seem like an interesting use case. As you say, it is similar in 
>> many ways to both the Multiple Launchers and system JRE, but not quite the 
>> same as either. The mechanism to manage and locate these shared-but-private 
>> JREs seems like the most challenging part. We can add it to the "if there is 
>> time" list of features, but I don't know how feasible it is for the first 
>> version. Andy or Alexey can comment as to whether the current prototype has 
>> done anything that would make this difficult.
>> 
>> -- Kevin
>> 
>> 
>> On 7/26/2018 7:38 AM, Scott Palmer wrote:
>>> "The input to jpackager includes: a Java runtime image, and a Java 
>>> application in one of several formats..."
>>> 
>>> Will it be possible to NOT include the JRE, but specify instead a 
>>> pre-existing location for the JRE?
>>> 
>>> As an example use-case consider an office productivity suite where there 
>>> are separate installers for a word processor and a spreadsheet application. 
>>>  These applications are independent and can be installed in any combination 
>>> (word processor only, both, spreadsheet only).  However they are part of 
>>> the same versioned application suite and have been developed and tested 
>>> with a particular JRE.  Only a single JRE needs to be installed.  The 
>>> applications can share it.  This is not the same as using a system-wide JRE 
>>> (is that even supported for Java 11 and beyond?).  But a shared private JRE 
>>> controlled by the application developer.
>>> 
>>> This is similar but not the same as the proposed "Multiple launchers" 
>>> feature (if time allows), as the shared JRE could be used by different 
>>> software packages.
>>> 
>>> In many cases the JRE is a very large part of the software installation, 
>>> both in terms of the size of the distributed installer package and the 
>>> storage requirements of the installed application.  JRE sharing can help 
>>> with this.
>>> 
>>> I'm thinking that eventually we could get to the point where developers 
>>> could treat the JRE as a versioned dependency, also covering the case of 
>>> customized JRE images.  I don't propose that this jpackager tool be 
>>> involved in creating or distributing such JRE images, only that it supports 
>>> running applications using a pre-installed JRE where the location can be 
>>> determined at installer build time or perhaps install time.
>>> 
>>> This was possible with the javapackager tool.
>>> 
>>> Scott
>>> 
>>>> On Jul 25, 2018, at 7:12 PM, Kevin Rushforth  
>>>> wrote:
>>>> 
>>>> Thank you to all who provided feedback. I have updated the draft JEP [1], 
>>>> and I think I have incorporated most of the feedback I received. 
>>>> Specifically, I have reorganized and reworded a few things for clarity, 
>>>> added '.exe' and '.app in a .dmg' native package format to the list of 
>>>> features, and added the service bundler (daemon) feature to the &qu

Re: Draft JEP proposal: JDK-8200758: Packaging Tool

[Scott Palmer]

With the existing javapackager there are some limitations.  

On Windows I only use it to go as far as creating the application image.  I 
then run the WiX commands in my Gradle build script to finish creating an 
installer that has an added custom component used to tweak the .cfg file. 
(Creating just the application image is something that should still be possible 
with the new tool.)  On Linux the full install package can be built directly 
with javapackager.

The idea is to set the packager to use the system JRE.  This creates an 
application image with the .cfg file configured with no JRE path 
("app.runtime=“) and no JRE files bundled.

For Linux builds, I customize the .spec file used by the packager (in verbose 
mode the packager tells you where it put the generated file .spec file so you 
can customize it).  I add a simple command to modify the application’s .cfg 
file with a simple search/replace of the app.runtime= line.

E.g. for MyApplication which installs in /opt:

# Tweak .cfg to point to JRE if it is not already specified.  E.g.: change 
“app.runtime=" to "app.runtime=/usr/java/latest"
sed -e 's/^app\.runtime=$/app\.runtime=\/usr\/java\/latest/' 
%{_sourcedir}/MyApplication/app/MyApplication.cfg > 
%{buildroot}/opt/MyApplication/app/MyApplication.cfg


On Windows, I take advantage of the fact that the .cfg file follows the 
convention of a Windows .ini file and MSI/WiX has a mechanism to add or modify 
.ini file entries.

This WiX code added to some component, where the jre64FolderId is refers to the 
install location of the private JRE, and appDirId refers the the ‘app’ 
sub-folder of the application image.  My Gradle build script sets some of these 
variables:



In both cases I use a separate module for the private JRE that can be shared 
among other applications.  The JRE installs to a common company folder in a 
versioned sub-folder so we can have multiple private JREs as we migrate 
products to newer JREs, but only ever one copy of any given version of the JRE.

My concern with the new tool is that removal of support for a “system JRE” 
would make it impossible to build a package that doesn't contain a JRE, 
bloating the sizes of both the installer and installed image footprint (since 
applications can’t share a common JRE easily).

Having the applications run on the same JRE may also have benefits related to 
class data sharing.

Scott

> On Jul 27, 2018, at 7:59 AM, Buchberger, Joerg 
>  wrote:
> 
> Thanks for the info - I was not aware of these possibilities in javapackager.
> 
> @Kevin: just fyi, this would be also a very useful feature for the company I 
> work for and for our projects
> 
> @Scott: please, let me know, how to achieve this with javapackager
> 
> Cheers
> Jörg
> 
> 
> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net 
> <mailto:core-libs-dev-boun...@openjdk.java.net>] On Behalf Of Scott Palmer
> Sent: Donnerstag, 26. Juli 2018 16:39
> To: Kevin Rushforth  <mailto:kevin.rushfo...@oracle.com>>
> Cc: core-libs-dev@openjdk.java.net <mailto:core-libs-dev@openjdk.java.net>
> Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
> 
> "The input to jpackager includes: a Java runtime image, and a Java 
> application in one of several formats..."
> 
> Will it be possible to NOT include the JRE, but specify instead a 
> pre-existing location for the JRE?
> 
> 

> This was possible with the javapackager tool.
> 
> Scott

Re: Draft JEP proposal: JDK-8200758: Packaging Tool

[Scott Palmer]

"The input to jpackager includes: a Java runtime image, and a Java application 
in one of several formats..."

Will it be possible to NOT include the JRE, but specify instead a pre-existing 
location for the JRE?

As an example use-case consider an office productivity suite where there are 
separate installers for a word processor and a spreadsheet application.  These 
applications are independent and can be installed in any combination (word 
processor only, both, spreadsheet only).  However they are part of the same 
versioned application suite and have been developed and tested with a 
particular JRE.  Only a single JRE needs to be installed.  The applications can 
share it.  This is not the same as using a system-wide JRE (is that even 
supported for Java 11 and beyond?).  But a shared private JRE controlled by the 
application developer.

This is similar but not the same as the proposed "Multiple launchers" feature 
(if time allows), as the shared JRE could be used by different software 
packages.

In many cases the JRE is a very large part of the software installation, both 
in terms of the size of the distributed installer package and the storage 
requirements of the installed application.  JRE sharing can help with this.

I'm thinking that eventually we could get to the point where developers could 
treat the JRE as a versioned dependency, also covering the case of customized 
JRE images.  I don't propose that this jpackager tool be involved in creating 
or distributing such JRE images, only that it supports running applications 
using a pre-installed JRE where the location can be determined at installer 
build time or perhaps install time.

This was possible with the javapackager tool.

Scott

> On Jul 25, 2018, at 7:12 PM, Kevin Rushforth  
> wrote:
> 
> Thank you to all who provided feedback. I have updated the draft JEP [1], and 
> I think I have incorporated most of the feedback I received. Specifically, I 
> have reorganized and reworded a few things for clarity, added '.exe' and 
> '.app in a .dmg' native package format to the list of features, and added the 
> service bundler (daemon) feature to the "if we have time" list (at the top of 
> that list).
> 
> Please let me know if I missed an important point. I hope to submit this JEP 
> in the next week or two.
> 
> -- Kevin
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
> 
> 
> On 5/30/2018 5:10 PM, Kevin Rushforth wrote:
>> I would like to propose the following Draft JEP [1] for discussion.
>> 
>> JDK-8200758: Packaging Tool
>> 
>> This is intended as a JDK-scope replacement for the existing javapackager 
>> tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and 
>> was delivered as part of the JavaFX build. The javapackager tool has been 
>> removed from Oracle JDK 11 along with the removal of JavaFX.
>> 
>> Comments on this JEP are welcome. It is currently not targeted for a 
>> specific release, but we are aiming for JDK 12.
>> 
>> -- Kevin
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
>> 
> 

Re: RFR : 8207395: jar has issues with UNC-path arguments for the jar -C parameter [windows]

[Scott Palmer]

That gives a different result.

Original:
"///" -> “/"

replaceAll:
"///" -> “//"


> On Jul 18, 2018, at 7:18 AM, Baesken, Matthias  
> wrote:
> 
> Hi Götz, thanks for the input !
> Should we maybe use  
> 
> dir.replaceAll
> 
> and not the while loop  ?
> 
>> while (dir.indexOf("//") > -1) {
>> dir = dir.replace("//", "/");
>> }
> 
> Best regards, Matthias
> 
> 
>> -Original Message-
>> From: Lindenmaier, Goetz
>> Sent: Mittwoch, 18. Juli 2018 11:32
>> To: Baesken, Matthias ; core-libs-
>> d...@openjdk.java.net
>> Subject: RE: RFR : 8207395: jar has issues with UNC-path arguments for the
>> jar -C parameter [windows]
>> 
>> Hi Matthias,
>> 
>> thanks for doing this fix.
>> 
>> I think this can be noted down a bit better, avoiding duplicating the loop.
>> Also, please remove the redundant dir.replace(File.separatorChar, '/').
>> 
>> dir = dir.replace(File.separatorChar, '/');
>> +String unc = (dir.startsWith("//") && 
>> (File.separatorChar == '\\'))
>> ? "/" : "";
>> while (dir.indexOf("//") > -1) {
>> dir = dir.replace("//", "/");
>> }
>> -
>> pathsMap.get(version).add(dir.replace(File.separatorChar, '/'));
>> +// Restore the second leading '/' needed for the 
>> Windows UNC
>> path.
>> +dir = unc + dir;
>> +pathsMap.get(version).add(dir);
>> nameBuf[k++] = dir + args[++i];
>> 
>> Best regards,
>>  Goetz.
>> 
>>> -Original Message-
>>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
>>> Behalf Of Baesken, Matthias
>>> Sent: Dienstag, 17. Juli 2018 13:15
>>> To: core-libs-dev@openjdk.java.net
>>> Subject: [CAUTION] RFR : 8207395: jar has issues with UNC-path arguments
>>> for the jar -C parameter [windows]
>>> 
>>> Please review   this small fix for allowing  windows UNC paths  in the  jar 
>>> -C
>>> parameter.
>>> Currently  passing a UNC path to a directory   with -Cfails  :
>>> 
>>> c:\testdir>c:\tools\jdk10\bin\jar.exe test.jar -C \\MYMACHINE\subdir
>>> README.txt
>>> Illegal option: s
>>> Try `jar --help' for more information.
>>> 
>>> With  the patch  it works .
>>> 
>>> webrev
>>> 
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8207395/
>>> 
>>> bug
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8207395
>>> 
>>> 
>>> 
>>> 
>>> Thanks, Matthias
> 

Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]

[Scott Palmer]

Since support for services/daemons was already in javapackager, why does this 
have to be a stretch goal? Isn’t it mostly already done?

I would like to see this in the initial implementation. It is something I’m 
currently using via javapackager.

I’m still trying to figure out the best strategy from bridging the gap in Java 
11 where suddenly no packager is available. My company has already decided to 
skip Java 9 and 10 altogether. Modules were too disruptive when they came in 
Java 9, which didn’t last long until Java 10. Given that Java 11 unbundled 
JavaFX, we decided not to bother trying to go to 10 just to have to re-jig 
everything for 11.  Now 11 is missing key tools (javapackager) that we began to 
rely on, so we keep falling behind, unable to adopt the newer JDK/JRE because 
the cost is so high. The first time ever in the history of Java where we 
couldn’t just adapt the new JDK and tweak for minor issues if any.

Migrating projects beyond Java 8 is a big pain. It would suck if Java 12 lacks 
what was available in Java 8.

(Please excuse the rant.)

Scott

> On Jul 11, 2018, at 7:08 PM, Kevin Rushforth  
> wrote:
> 
> We will likely be able to deliver the .exe installer (with its dependency on 
> Inno Setup).
> 
> As for the service bundler, this will be a "nice to have" (a stretch goal) 
> for this version, but isn't on the list of committed features. Alexsei might 
> be able to comment further on how much work it would be to provide it, 
> including documenting and testing it. This might give you, and other 
> interested developers, a sense of how likely this is to make it for this 
> version.
> 
> -- Kevin
> 
> 
>> On 7/10/2018 4:35 AM, Buchberger, Joerg wrote:
>> Hi
>> 
>> thanks for the update/info. I had a quick look at the changes. So, here some 
>> thoughts...
>> 
>> As described in JDK-8200758, and therefore expected, WinExeBundler has been 
>> removed in favor of putting focus on WinMsiBundler.
>> (Although, I regret that decision - since my personal experience has been 
>> that InnoSetup based WinExeBundler has worked much better than wix based 
>> WinMsiBundler for our use cases - I can live with that.)
>> 
>> What is much more disturbing: WinServiceBundler has also been actively 
>> removed, although that was working fine together with both wix/msi and 
>> exe/iss. Why has service wrapping been removed as well, while the command 
>> line option for it is kept in place?
>> 
>> Is there any chance of service bundler coming back into scope of JDK-8200758 
>> or coming back in at all?
>> 
>> Cheers
>> Jörg
>> 
>> 
>> -Original Message-
>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On 
>> Behalf Of Kevin Rushforth
>> Sent: Freitag, 6. Juli 2018 22:14
>> To: core-libs-dev@openjdk.java.net
>> Cc: Alexey Semenyuk ; Andy Herrick 
>> 
>> Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: 
>> JDK-8200758: Packaging Tool]
>> 
>> An initial prototype of the jpackager tool has been pushed to a new 
>> 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested 
>> in taking a look, you can clone it as follows:
>> 
>>  hg clone 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=jWWENz_KIkmyh-9-kQQvoZ0BwBymwQ-BKx8hG3F5Iy0=
>>  cd ./sandbox
>>  hg update JDK-8200758-branch
>> 
>> I plan to reply to the feedback already provided, and update the JEP [2] 
>> next week some time, but in the mean time if you have additional questions 
>> or comments, feel free to reply.
>> 
>> -- Kevin
>> 
>> [1] 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_sandbox_shortlog_JDK-2D8200758-2Dbranch=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=F-CqPAWlz-Cfb0kae2FBEj4Ncd3ZBVu7BeOVY1AM-cA=
>> [2] 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8200758=DwIFaQ=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrEdQ22wI9I=
>> 
>> 
>>> On 6/27/2018 3:30 PM, Kevin Rushforth wrote:
>>> We're aiming to get this into JDK 12 early enough so that an EA build
>>> would be available around the time JDK 11 ships. That will allow you
>>> to take a jlinked image with JDK 11 and package it up using (the EA)
>>> jpackager.
>>> 
>>> We will create a development branch in the JDK sandbox [1] some time
>>> in the next week or so so you can follow the development.
>>> 
>>> Also, thank you to those who have provided feedback. I'll reply to
>>> feedback soon and then incorporate it into an updated JEP.
>>> 
>>> -- Kevin
> 

Re: Useless null check in HashMap.merge()

[Scott Palmer]

On Jul 4, 2018, at 5:42 AM, Zheka Kozlov  wrote:
> 
> I noticed dead code in java.util.HashMap.merge():
> 
> public V merge(K key, V value,
>   BiFunction
> remappingFunction) {
>if (value == null)
>throw new NullPointerException();
> 
>...
> 
>if (value != null) { *// Condition ' value != null' is always true*
>if (t != null)
>t.putTreeVal(this, tab, hash, key, value);
>else {
>tab[i] = newNode(hash, key, value, first);
>if (binCount >= TREEIFY_THRESHOLD - 1)
>treeifyBin(tab, hash);
>}
>++modCount;
>++size;
>afterNodeInsertion(true);
>}
>return value;
> }
> 
> The code in the if branch will never be executed because `value` was
> previously checked at the beginning of the method.
> 
> Is this a mistake?

You mean it will ALWAYS be executed.  Yes, it looks to me like the ‘if’ is 
useless.

Re: Draft JEP proposal: JDK-8200758: Packaging Tool

[Scott Palmer]

Doesn’t jlink require a *fully* modularized application?  I.e. no non-module 
dependencies.
The packaging tool should work with all runnable Java applications, not just 
fully modularized ones.

Modularization seems to be a bit of an effort and is one of the main reasons my 
application(s) are still stuck on Java 8.

Scott



> On Jun 27, 2018, at 6:30 PM, Kevin Rushforth  
> wrote:
> 
> We're aiming to get this into JDK 12 early enough so that an EA build would 
> be available around the time JDK 11 ships. That will allow you to take a 
> jlinked image with JDK 11 and package it up using (the EA) jpackager.
> 
> We will create a development branch in the JDK sandbox [1] some time in the 
> next week or so so you can follow the development.
> 
> Also, thank you to those who have provided feedback. I'll reply to feedback 
> soon and then incorporate it into an updated JEP.
> 
> -- Kevin
> 
> 
> On 6/27/2018 3:09 AM, Buchberger, Joerg wrote:
>> Thanks for the info! And thanks for the efforts.  [no irony, no sarcasm - I 
>> really mean it]
>> 
>> But, to sum up my comprehension...
>> 
>> anyone who placed their bets on javapackager, starting with last LTS Java 8
>> will be left in the rain with followup LTS Java 11, because their ain't 
>> neither javapackager (anymore), nor jpackager (yet).
>> 
>> Is this correct?
>> 
>> So, strategic choice boils down to either throw away all work done based on 
>> javapackager so far and the associated distribution concepts (reworking 
>> everything from scratch)
>> or neglect Java 11 completely, thus placing all bets on jpackager really 
>> coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter.
>> 
>> Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in 
>> ...
>> 
>> Cheers
>> Jörg
>> 
>> 
>> On 5/31/2018 0:10 AM, Rushforth, Kevin wrote:
>>> I would like to propose the following Draft JEP [1] for discussion.
>>> 
>>> JDK-8200758: Packaging Tool
>>> 
>>> This is intended as a JDK-scope replacement for the existing
>>> javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK
>>> releases), and was delivered as part of the JavaFX build. The
>>> javapackager tool has been removed from Oracle JDK 11 along with the
>>> removal of JavaFX.
>>> 
>>> Comments on this JEP are welcome. It is currently not targeted for a
>>> specific release, but we are aiming for JDK 12.
>>> 
>>> -- Kevin
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
>>> 
> 

Re: Reducing Garbage Generated by URLClassLoader

[Scott Palmer]

> On Dec 5, 2016, at 1:31 AM, Max Kanat-Alexander  wrote:
> 
> Yeah, I have implemented a fast-path byte-only ZipCoder in a customized JDK
> and it makes a big difference for allocations in long classpaths.

I expected to see an improvement, but haven’t made any attempt at solving the 
problem yet.  I was just gauging how much interest there was in such a change.  
It is nice to see that some work has already been done.  Do you have numbers?

Regards,

Scott


> The basic
> code to do just that isn't very complex. I could possibly dig that up and
> upstream it if there's interest. My recollection is that my solution isn't
> the cleanest, but it doesn't regress the "needs encoding" path.
> 
> It also is possible to optimize URLClassLoader itself to do a better job of
> caching zip entries, which significantly reduces the String allocation load
> if you're doing a lot of lookups on the classpath. I have also implemented
> something like this, but it's hard to get right and my changes aren't in a
> state where they could be easily upstreamed.
> 
> -Max

Reducing Garbage Generated by URLClassLoader

[Scott Palmer]

Excuse me if this is the wrong list for this discussion.  Please direct me to 
the right place if this isn’t it.

When doing an analysis of garbage generation in our application we discovered a 
significant number of redundant strings generated by the class loader.  In my 
case there are hundreds of jars on the classpath - everything in the 
application is a plugin.  I figured on average 10kB of useless garbage char[]s 
were generated per findResource call for plugin resources.

This is caused mostly by the ZipFile implementation.  What is the purpose of 
java.util.zip.ZipCoder’s byte[] getBytes(String s) method?  It seems to simply 
be a custom implementation of string.getBytes(CharSet cs) and as such needs to 
first make a copy of the char[] to work on.  This combined with the need to 
operate on byte[] path names internally in the ZipFile implementation means 
that URLClassLoader generates a lot of unnecessary garbage in a findResource 
call - proportional to the number of jars on the classpath.

Since JarFile forces the ZipFile to be open with UTF-8 always, if there was 
some API exposed that took a byte[] for the resource name, all of that extra 
string copying and encoding could be hoisted out of the loop in 
sun.misc.URLClassPath. Would this be worth it creating an internal class for 
something like a ‘ClasspathJarFile’ to and tweaking ZipFile so the byte[] based 
method is protected instead of private?

I also noticed that sun.net.www.ParseUtil.encodePath(String, boolean) usually 
had nothing useful to do but still made three copies of the string passed in 
anyway (two char arrays to work on, and the String returned).



Cheers,

Scott

Re: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X

[Scott Palmer]

Then shouldn't you be complaining to Apple that the value returned by
nl_langinfo needs to be changed?
David's point seems to be that second guessing the character set reported
by the OS is likely to cause a different set of problems.

Scott


On Tue, Jul 30, 2013 at 10:14 AM, Johannes Schindelin 
johannes.schinde...@gmx.de wrote:

 Hi,

 On Tue, 30 Jul 2013, David Holmes wrote:

  On 30/07/2013 5:54 AM, Brent Christian wrote:
   On 7/28/13 10:13 PM, David Holmes wrote:
On 27/07/2013 3:53 AM, Brent Christian wrote:
 Please review my fix for 8011194 : Apps launched via
 double-clicked
 .jars have file.encoding value of US-ASCII on Mac OS X

 http://bugs.sun.com/view_bug.do?bug_id=8011194

 In most cases of launching a Java app on Mac (from the cmdline, or
 from a native .app bundle), reading and displaying UTF-8
 characters beyond the standard ASCII range works fine.

 A notable exception is the launching of an app by double-clicking
 a .jar file.  In this case, file.encoding defaults to US-ASCII,
 and characters outside of the ASCII range show up as garbage.
   
Why does this occur? What sets the encoding to US-ASCII?
  
   US-ASCII is the answer we get from nl_langinfo(CODESET) because no
   values for LANG/LC* are set in the environment when double-clicking a
   .jar.
  
   We get UTF-8 when launching from the command line because the
   default Terminal.app setup on Mac will setup LANG for you (to
   en_US.UTF-8 in the US).
 
  Sounds like a user environment error to me. This isn't my area but I'm
  not convinced we should be second guessing what we think the encoding
  should be.

 Except that that is not the case here, of course. The user did *not* set
 any environment variable in this case.

 So we are not talking about second guessing or user environment error
 but about a sensible default.

 As to US-ASCII, sorry to say: the seventies called and want their
 character set back.

 There can be no question that UTF-8 is the best default character
 encoding, or are you even going to question *that*?

  What if someone intends for it to be US-ASCII?

 Then LANG would not be unset, would it.

 Hth,
 Johannes