Re: javapackager feedback and questions

[Scott Palmer]

I’m using javapackager to generate native installers for several services and 
GUI applications. I would be using it for some command line tools as well, but 
it doesn’t yet support “console” applications on Windows. I.e. you can’t make 
javapackager with javapackager. I’ve filed an issue for that already (it was 
closed as won’t fix, but thankfully it was reopened)

Javapackager is one of the most useful tools in the JDK, but it is mostly 
undocumented and has many usability issues.
IMO, it tried to do way too much. The only thing it ever needed to do was the 
-deploy option.

I run javapackager two ways, always from Gradle scripts, either via the javaFX 
Gradle plugin, or as an Exec task.

The ability to have secondary launchers is great.

The customization options for installers needs some work. I’ve filed several 
issues (and I could file more). E.g. background images for macOS .dmg must be 
different from background images used in macOS .pkg as they are serving 
entirely different purposes. Including custom resources in subdirectories is 
difficult and/or broken depending on the version of javapackager used (v9 is 
broken).
On Windows .msi component rules are not followed making upgrades problematic. 
Install folders should be customizable by supplying custom wix files, etc.

On Linux services should be handled with systemd or sysctl. (I can’t remember 
which is preferred at the moment, but I know it didn’t use what I needed.)

I really like that we have javapackager and feel it is a very important 
addition to the JDK.  

I too would love if it could build for multiple platforms from a single 
platform, but I honestly don’t see that happening. It isn’t worth the trouble 
or effort - things like making a HFS+ .dmg for macOS from Windows isn’t 
realistic. We do NOT want some custom non-native installer (Though a .zip of an 
app bundle might work.)  You would also need the native bits of the JRE for 
each platform anyway. It would be possible to have those files available on any 
platform, but the tools to build .deb, .rpm, .dmg, .msi, etc. are just never 
going to be available everywhere.

Scott

> On Nov 30, 2017, at 7:16 PM, Kevin Rushforth  
> wrote:
> 
> Hi Michael,
> 
> We realized that the javapackger CLI JEP wasn't quite ready, and was out of 
> scope for JDK 10 anyway, so we withdrew it in order to file a new JEP later.
> 
> Related to this, we are soliciting input as to how people are using the 
> javapackager (see Victor's question below).
> 
> So we'd love to hear how you and others are using it, and for what kind of 
> applications.
> 
> -- Kevin
> 
> 
> Michael Hall wrote:
>>> On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:
>>> 
>>> Hi, Mani.
>>> 
>>> Thanks for providing the feedback!
>>> We will consider adding more examples and more details in the docs as you 
>>> proposed(there is an arg named jvmOptions but that's not mentioned in the 
>>> table).
>>> Looks like there is a bug when you specify systemWide=true on the MacOSX in 
>>> non-gui mode. Can you provide more details about that (like full cmd line)?
>>> Actually, if you want you can clone the repo:
>>> http://hg.openjdk.java.net/openjfx/10-dev/rt/
>>> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
>>> and help to improve javapackager. Or you can just create Enhancements for 
>>> deploy/packager, as it's not always clear what users expect.
>>> 
>>>
>> 
>> Why was JEP 311 [1] Closed/Withdrawn?
>> 
>> [1] http://openjdk.java.net/jeps/311
>> 
>>  

[10] Review request: 8192867: Update version of Lucene in license file to 7.1.0

[Kevin Rushforth]

Phil,

Please review the following follow-up fix to the Lucene 7.1.0 upgrade. I 
forgot to change the version in the license file:


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

The one line diff is in JBS, and repeated here:

diff --git a/apps/samples/Ensemble8/legal/lucene.md 
b/apps/samples/Ensemble8/legal/lucene.md

--- a/apps/samples/Ensemble8/legal/lucene.md
+++ b/apps/samples/Ensemble8/legal/lucene.md
@@ -1,4 +1,4 @@
-## Apache Lucene v3.2.0
+## Apache Lucene v7.1.0

### Apache 2.0 License



-- Kevin

Re: javapackager feedback and questions

[Mani Sarkar]

Hi Victor,

To answer your query about how javapackager can be made better, packr (
https://github.com/libgdx/packr) and FPM (
https://github.com/jordansissel/fpm) are two great examples in this space.
If we can pool together some of the features from both, it would certainly
draw attention of  developers building installers and distributable
packages. javapackager does already have many of them already. Packr does
allow compressing jre packed into the app although jlink already helps in
this area. Another example would be to be able to --dry-run your
executions, bundle respective apps as a service (systemd, etc...), see
usage of FPM at https://github.com/jordansissel/fpm/wiki#usage.

Your queries about how people use it or like to use it, one thing FPM and
packr do very well, is to allow creation of packages/installer on a single
platform, their cross-platform functionality is a boon, although building
on native environments have their own merits. Just now one would need to
run javapackager in the specific environments to get a working
installer/package created for that environment. Many would like to run
Jenkins (Linux env) and build all three types of packages/installers on one
box rather than spin off the individual slave variants of different
platforms (Linux, MacOSX and Windows.

I can help draw some enhancement points off this list and share it with you
to avoid noise here, and you can choose to bring them to this list - the
ones you would make part of the packager.

Others might differ in the above and want something else.

I hope this helps.

Cheers,
Mani

On Thu, 30 Nov 2017 at 18:57 Martijn Verburg 
wrote:

> Hi Victor,
>
> I can answer the last Q.  It's for two products, one is Censum our GC Log
> analyser (Java swing desktop app, yes they still exist! ;p) and the second
> is a stand alone Java 'daemon' for our APM SaaS tool (illuminate).
>
> jlink and javapackager is a powerful combination for us, so thanks for
> these tools!
>
> Cheers,
> Martijn
>
> On 29 November 2017 at 23:18,  wrote:
>
>> Hi, Mani.
>>
>> Thanks for providing the feedback!
>> We will consider adding more examples and more details in the docs as you
>> proposed(there is an arg named jvmOptions but that's not mentioned in the
>> table).
>> Looks like there is a bug when you specify systemWide=true on the MacOSX
>> in non-gui mode. Can you provide more details about that (like full cmd
>> line)?
>> Actually, if you want you can clone the repo:
>> http://hg.openjdk.java.net/openjfx/10-dev/rt/
>> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
>> and help to improve javapackager. Or you can just create Enhancements for
>> deploy/packager, as it's not always clear what users expect.
>>
>> By the way, what kind of apps you distribute using javapackager? Is that
>> a UI app or services?
>>
>> --Victor
>>
>>
>>
>> On 11/29/17 3:48 AM, Mani Sarkar wrote:
>>
>>> Hi all,
>>>
>>> First I hope I'm writing to the correct mailing list, if not please
>>> suggest
>>> where to write instead. Also if it is worth writing back as separate
>>> messages per issue or item, please do let me know.
>>>
>>> Some of my observations and feedback when using *javapackager*:
>>>
>>> *Positives*
>>> - .dmg and .msi packaging work very well out of the box, easy to put
>>> together configuration settings
>>> - .rpm packages build very quickly
>>> - a number of features from FPM (docs
>>>  | GitHub
>>> ) available but some more for the
>>> individual types of packages would certainly help (for e.g. exposing some
>>> more of the CLI flags for DEB and RPM packaging)
>>>
>>> *Improvements*
>>> - [doc and example required]: Additional documentation and examples
>>> around
>>> how to add a license when building a package would be helpful. After a
>>> bit
>>> of searching on google and experimenting with couple of combinations of
>>> CLI
>>> options I was able to figure it out.
>>> - [doc correction]: jvmUserArg is referred to in the documentation with
>>> examples, while in the usage documentation jvmOptions is used
>>> (discrepancy
>>> between the names of flags), see
>>>
>>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javapackager.html
>>>   and
>>>
>>> https://docs.oracle.com/javase/9/deploy/self-contained-application-packaging.htm#JSDPG585
>>> - [doc correction]: same goes for mac.signing-key-user-name while there
>>> is
>>> no mention of it in the javapackager usage documentation, it takes the
>>> full
>>> name of the user i.e. *Jane Doe*
>>> *- *[doc and example required]: just adding
>>> mac.signing-key-developer-id-app=x isn't enough, needs the other
>>> code-sign related flags as well, possibly key should be in the Mac
>>> KeyStore
>>> when building it (check if id provided is the correct one, additional
>>> examples would definitely help to reduce or eliminate experimentation and
>>> assumptions)
>>> 

Re: javapackager feedback and questions

[Michael Hall]

> On Nov 30, 2017, at 6:16 PM, Kevin Rushforth  
> wrote:
> 
> Hi Michael,
> 
> We realized that the javapackger CLI JEP wasn't quite ready, and was out of 
> scope for JDK 10 anyway, so we withdrew it in order to file a new JEP later.
> 
> Related to this, we are soliciting input as to how people are using the 
> javapackager (see Victor's question below).
> 
> So we'd love to hear how you and others are using it, and for what kind of 
> applications.
> 
> — Kevin

I was sort of waiting to see what came out of the JEP. 
It had some issues on OS X the last time I tried it. I might have used it for a 
starter application that I’ve been manually updating since. 
Now I use jlink, copy in the results… That sort of thing. 
I may look at it some more as-is if it doesn’t have a significant update 
currently in the works.

Thanks.

Re: javapackager feedback and questions

[Kevin Rushforth]

Hi Michael,

We realized that the javapackger CLI JEP wasn't quite ready, and was out 
of scope for JDK 10 anyway, so we withdrew it in order to file a new JEP 
later.


Related to this, we are soliciting input as to how people are using the 
javapackager (see Victor's question below).


So we'd love to hear how you and others are using it, and for what kind 
of applications.


-- Kevin


Michael Hall wrote:

On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:

Hi, Mani.

Thanks for providing the feedback!
We will consider adding more examples and more details in the docs as you 
proposed(there is an arg named jvmOptions but that's not mentioned in the 
table).
Looks like there is a bug when you specify systemWide=true on the MacOSX in 
non-gui mode. Can you provide more details about that (like full cmd line)?
Actually, if you want you can clone the repo:
http://hg.openjdk.java.net/openjfx/10-dev/rt/
(hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
and help to improve javapackager. Or you can just create Enhancements for 
deploy/packager, as it's not always clear what users expect.




Why was JEP 311 [1] Closed/Withdrawn?

[1] http://openjdk.java.net/jeps/311

  

Re: javapackager feedback and questions

[Martijn Verburg]

Hi Victor,

I can answer the last Q.  It's for two products, one is Censum our GC Log
analyser (Java swing desktop app, yes they still exist! ;p) and the second
is a stand alone Java 'daemon' for our APM SaaS tool (illuminate).

jlink and javapackager is a powerful combination for us, so thanks for
these tools!

Cheers,
Martijn

On 29 November 2017 at 23:18,  wrote:

> Hi, Mani.
>
> Thanks for providing the feedback!
> We will consider adding more examples and more details in the docs as you
> proposed(there is an arg named jvmOptions but that's not mentioned in the
> table).
> Looks like there is a bug when you specify systemWide=true on the MacOSX
> in non-gui mode. Can you provide more details about that (like full cmd
> line)?
> Actually, if you want you can clone the repo:
> http://hg.openjdk.java.net/openjfx/10-dev/rt/
> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> and help to improve javapackager. Or you can just create Enhancements for
> deploy/packager, as it's not always clear what users expect.
>
> By the way, what kind of apps you distribute using javapackager? Is that a
> UI app or services?
>
> --Victor
>
>
>
> On 11/29/17 3:48 AM, Mani Sarkar wrote:
>
>> Hi all,
>>
>> First I hope I'm writing to the correct mailing list, if not please
>> suggest
>> where to write instead. Also if it is worth writing back as separate
>> messages per issue or item, please do let me know.
>>
>> Some of my observations and feedback when using *javapackager*:
>>
>> *Positives*
>> - .dmg and .msi packaging work very well out of the box, easy to put
>> together configuration settings
>> - .rpm packages build very quickly
>> - a number of features from FPM (docs
>>  | GitHub
>> ) available but some more for the
>> individual types of packages would certainly help (for e.g. exposing some
>> more of the CLI flags for DEB and RPM packaging)
>>
>> *Improvements*
>> - [doc and example required]: Additional documentation and examples around
>> how to add a license when building a package would be helpful. After a bit
>> of searching on google and experimenting with couple of combinations of
>> CLI
>> options I was able to figure it out.
>> - [doc correction]: jvmUserArg is referred to in the documentation with
>> examples, while in the usage documentation jvmOptions is used (discrepancy
>> between the names of flags), see
>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/
>> javapackager.html
>>   and
>> https://docs.oracle.com/javase/9/deploy/self-contained-
>> application-packaging.htm#JSDPG585
>> - [doc correction]: same goes for mac.signing-key-user-name while there is
>> no mention of it in the javapackager usage documentation, it takes the
>> full
>> name of the user i.e. *Jane Doe*
>> *- *[doc and example required]: just adding
>> mac.signing-key-developer-id-app=x isn't enough, needs the other
>> code-sign related flags as well, possibly key should be in the Mac
>> KeyStore
>> when building it (check if id provided is the correct one, additional
>> examples would definitely help to reduce or eliminate experimentation and
>> assumptions)
>> - [potential bug]: Using *-B*systemWide=true flag causes error -10810 when
>> building on the MacOSX in non-gui mode, can be overridden by using the
>> -Bmac.dmg.simple=true but we loose the backdrop and automatic shortcut
>> creation, etc... Swappin gthe order to: -Bmac.dmg.simple=true and *-B*
>> systemWide=true does not help, still ends up building a .dmg package with
>> just the app in it (no icon, no background)
>> - code signing examples for Windows and MacOSX will certainly help quite a
>> bit
>> - [doc and example required] .deb packages take a long time to build, some
>> additional flags that can help. Some findings along the lines on how to
>> speed up dpkg-build:
>>
>> export CCACHE_DIR=/home/$USER/.ccache
>>
>> export CCACHE_HASHDIR=$CCACHE_DIR
>>
>> export DEB_BUILD_OPTIONS="${DEB_BUILD_OPTIONS}
>> --preserve-envvar=CCACHE_DIR
>> --prepend-path=/usr/lib/ccache parallel=jobs"
>>
>> echo "Debian build options: ${DEB_BUILD_OPTIONS}"
>>
>> ---
>>
>> A response with answers for the above will be highly appreciated.
>>
>> Thanks.
>>
>> Cheers,
>> Mani
>>
>
>

Re: [10] Review request: 8185923: Bump minimum gradle version to 4.3 for JDK10

[Johan Vos]

FWIW, I'm +1 on this. We're using 4.3.1 for building JavaFX on mobile.

- Johan

On Thu, Nov 30, 2017 at 6:36 PM Kevin Rushforth 
wrote:

> Hi Phil,
>
> Please review the following fix to make gradle 4.3 the minimum version:
>
> https://bugs.openjdk.java.net/browse/JDK-8185923
> http://cr.openjdk.java.net/~kcr/8185923/webrev.00/
>
> We've already been using 4.3 for a few weeks, so it is time to enforce
> it as the minimum in preparation for enabling JDK 10 as our boot JDK.
>
> -- Kevin
>
>

[10] Review request: 8185923: Bump minimum gradle version to 4.3 for JDK10

[Kevin Rushforth]

Hi Phil,

Please review the following fix to make gradle 4.3 the minimum version:

https://bugs.openjdk.java.net/browse/JDK-8185923
http://cr.openjdk.java.net/~kcr/8185923/webrev.00/

We've already been using 4.3 for a few weeks, so it is time to enforce 
it as the minimum in preparation for enabling JDK 10 as our boot JDK.


-- Kevin

Re: javah deprecated?

[Kevin Rushforth]

Yes, something along those lines is what I was thinking. Preferably it 
would be added in an existing class in the javafx.web module rather than 
a new class if a suitable one can be found. In either case, it will need 
to be done in a way that does not expose these constants as part of the 
public API (e.g., either they need to go into a non-public class, or a 
public class in a non-exported package, or the new constants need to be 
package scope).


Thanks.

-- Kevin


Johan Vos wrote:

Hi Kevin,

Just to make sure I understand this approach: you want a (new or 
existing) Foo.Java file in the modules/javafx.web space that contains 
e.g. this:


public static int DIRECTIONALITY_LEFT_TO_RIGHT = 
Character.DIRECTIONALITY_LEFT_TO_RIGHT;


Applying javac -h (which the build already does) will generate Foo.h 

In modules/javafx.web/src/main/native/Source/WTF/wtf/unicode/java/UnicodeJava.h  
we replace the


#include java_lang_Character.h

with

#include Foo.h


Is this correct?


- Johan


On Thu, Nov 30, 2017 at 2:13 PM Kevin Rushforth 
> wrote:


Hi Johan,

Thanks for filing the bug.

If we really do need Character and IDN, then the cleanest approach
might be to define new fields in a  suitable JavaFX class and
assign the appropriate values to them.


-- Kevin



Johan Vos wrote:

I filed a bug (https://bugs.openjdk.java.net/browse/JDK-8192806)
and I am looking into it.

It seems a bit weird to me that the java.lang.Character and
java.net.IDN header files are needed. I'll remove them and see
where it fails.
But if they are needed (and they probably are), it won't be easy
to generate them with javac -h as that requires the source code
instead of the classfiles. That would require access to the
java.lang.Character and java.net.IDN java source code in OpenJDK,
from within OpenJFX.

- Johan

On Wed, Nov 29, 2017 at 8:02 PM Kevin Rushforth
>
wrote:

Hi Johan,

Thanks for pointing this out. I had missed that this was
targeted to JDK 10.

We eliminated all but one use of javah, in favor of javac -h,
in JDK 9
[1]. The only one remaining is in the web module. I can't
remember why
that wasn't switched at the same time (I have a fuzzy
recollection that
it might have had something to do with incremental
compilation), but
yes, it seems like this will need to be fixed.

If you would like to file a bug then this would be a great
thing for the
community to work on. This will block us from moving to JDK
10 as a boot
JDK, so if we end up doing that for JDK 10 then this would
need to be
done soon.

Let me know if you would like to work on this.

Thanks.

-- Kevin

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


Johan Vos wrote:
> Hi,
>
> I learned javah might be removed in Java 10 (
> http://openjdk.java.net/jeps/313) but as far as I know, it
is still used in
> OpenJFX:
>
> defineProperty("JAVAH",
cygpath("$JDK_HOME/bin/javah${IS_WINDOWS ? '.exe' :
> ''}"))
>
> Are there already plans to move to javac -h instead?
> It seems a relative easy task that might be done by someone
from the wider
> community?
>
> Thanks,
>
> - Johan
>

Re: javah deprecated?

[Johan Vos]

Hi Kevin,

Just to make sure I understand this approach: you want a (new or existing)
Foo.Java file in the modules/javafx.web space that contains e.g. this:

public static int DIRECTIONALITY_LEFT_TO_RIGHT = Character.
DIRECTIONALITY_LEFT_TO_RIGHT;

Applying javac -h (which the build already does) will generate Foo.h

In modules/javafx.web/src/main/native/Source/WTF/wtf/unicode/java/UnicodeJava.h
we replace the

#include java_lang_Character.h

with

#include Foo.h


Is this correct?


- Johan

On Thu, Nov 30, 2017 at 2:13 PM Kevin Rushforth 
wrote:

> Hi Johan,
>
> Thanks for filing the bug.
>
> If we really do need Character and IDN, then the cleanest approach might
> be to define new fields in a  suitable JavaFX class and assign the
> appropriate values to them.
>
>
> -- Kevin
>
>
>
> Johan Vos wrote:
>
> I filed a bug (https://bugs.openjdk.java.net/browse/JDK-8192806) and I am
> looking into it.
>
> It seems a bit weird to me that the java.lang.Character and java.net.IDN
> header files are needed. I'll remove them and see where it fails.
> But if they are needed (and they probably are), it won't be easy to
> generate them with javac -h as that requires the source code instead of the
> classfiles. That would require access to the java.lang.Character and
> java.net.IDN java source code in OpenJDK, from within OpenJFX.
>
> - Johan
>
> On Wed, Nov 29, 2017 at 8:02 PM Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Hi Johan,
>>
>> Thanks for pointing this out. I had missed that this was targeted to JDK
>> 10.
>>
>> We eliminated all but one use of javah, in favor of javac -h, in JDK 9
>> [1]. The only one remaining is in the web module. I can't remember why
>> that wasn't switched at the same time (I have a fuzzy recollection that
>> it might have had something to do with incremental compilation), but
>> yes, it seems like this will need to be fixed.
>>
>> If you would like to file a bug then this would be a great thing for the
>> community to work on. This will block us from moving to JDK 10 as a boot
>> JDK, so if we end up doing that for JDK 10 then this would need to be
>> done soon.
>>
>> Let me know if you would like to work on this.
>>
>> Thanks.
>>
>> -- Kevin
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8161704
>>
>>
>> Johan Vos wrote:
>> > Hi,
>> >
>> > I learned javah might be removed in Java 10 (
>> > http://openjdk.java.net/jeps/313) but as far as I know, it is still
>> used in
>> > OpenJFX:
>> >
>> > defineProperty("JAVAH", cygpath("$JDK_HOME/bin/javah${IS_WINDOWS ?
>> '.exe' :
>> > ''}"))
>> >
>> > Are there already plans to move to javac -h instead?
>> > It seems a relative easy task that might be done by someone from the
>> wider
>> > community?
>> >
>> > Thanks,
>> >
>> > - Johan
>> >
>>
>

Java Packager fails to create macOS or Windows Bundle

[Dmitry Beloborodov]

(Two months later)

Please fix bug
https://bugs.openjdk.java.net/browse/JDK-8179033

See patch below (or previous letter
http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-October/020878.html)

See example on GitHub to check
https://github.com/dbelob/multiplatform-distribution

How to build for Windows and macOS:
mvn clean package -P native-deploy
(there is no error on Linux)

With best regards,
Dmitry Beloborodov

On Mon, Oct 9, 2017 at 6:52 PM, Dmitry Beloborodov  wrote:

> There is JDK-8179033
> https://bugs.openjdk.java.net/browse/JDK-8179033
> ("javapackager fails to create Mac Application Bundle")
>
> Error is reproduced on macOS and Windows
> (there is no error on Linux)
>
> Cause is the absence of a destination resource subdirectory.
>
> I suppose that to fix the error it is enough to create subdirectories
> before copying of destination resources
> (see correct methods
> com.oracle.tools.packager.windows.WinAppBundler::copyApplication in Java 8
> com.oracle.tools.packager.mac.MacAppBundler::copyClassPathEntries in Java
> 8
> com.oracle.tools.packager.linux.LinuxAppBundler::copyApplication in Java 8
> or
> jdk.packager.builders.linux.LinuxAppImageBuilder::copyApplication in Java
> 9
> )
>
> To fix it (in Java 9) you need to
> 1. Change in 
> jdk.packager.builders.windows.WindowsAppImageBuilder::copyApplication
> method
> from
>for (String fname : appResources.getIncludedFiles()) {
>   Files.copy(new File(srcdir, fname).toPath(), new
> File(appDir.toFile(), fname).toPath());
>}
> to
>for (String fname : appResources.getIncludedFiles()) {
>   File destFile = new File(appDir.toFile(), fname);
>
>   destFile.getParentFile().mkdirs();
>   Files.copy(new File(srcdir, fname).toPath(), destFile.toPath());
>}
>
> 2. Change in jdk.packager.builders.mac.MacAppImageBuilder::copyApplication
> method
> from
>for (String fname : classPath.getIncludedFiles()) {
>   // use new File since fname can have file separators
>   Files.copy(new File(srcdir, fname).toPath(), new
> File(javaDirectory.toFile(), fname).toPath());
>}
> to
>for (String fname : classPath.getIncludedFiles()) {
>   // use new File since fname can have file separators
>   File destFile = new File(javaDirectory.toFile(), fname);
>
>   destFile.getParentFile().mkdirs();
>   Files.copy(new File(srcdir, fname).toPath(), destFile.toPath());
>}
>
> Please fix error. Many thanks!
>
> With best regards,
> Dmitry Beloborodov
>

Re: javah deprecated?

[Kevin Rushforth]

Hi Johan,

Thanks for filing the bug.

If we really do need Character and IDN, then the cleanest approach might 
be to define new fields in a  suitable JavaFX class and assign the 
appropriate values to them.


-- Kevin


Johan Vos wrote:
I filed a bug (https://bugs.openjdk.java.net/browse/JDK-8192806) and I 
am looking into it.


It seems a bit weird to me that the java.lang.Character and 
java.net.IDN header files are needed. I'll remove them and see where 
it fails.
But if they are needed (and they probably are), it won't be easy to 
generate them with javac -h as that requires the source code instead 
of the classfiles. That would require access to the 
java.lang.Character and java.net.IDN java source code in OpenJDK, from 
within OpenJFX.


- Johan

On Wed, Nov 29, 2017 at 8:02 PM Kevin Rushforth 
> wrote:


Hi Johan,

Thanks for pointing this out. I had missed that this was targeted
to JDK 10.

We eliminated all but one use of javah, in favor of javac -h, in JDK 9
[1]. The only one remaining is in the web module. I can't remember why
that wasn't switched at the same time (I have a fuzzy recollection
that
it might have had something to do with incremental compilation), but
yes, it seems like this will need to be fixed.

If you would like to file a bug then this would be a great thing
for the
community to work on. This will block us from moving to JDK 10 as
a boot
JDK, so if we end up doing that for JDK 10 then this would need to be
done soon.

Let me know if you would like to work on this.

Thanks.

-- Kevin

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


Johan Vos wrote:
> Hi,
>
> I learned javah might be removed in Java 10 (
> http://openjdk.java.net/jeps/313) but as far as I know, it is
still used in
> OpenJFX:
>
> defineProperty("JAVAH", cygpath("$JDK_HOME/bin/javah${IS_WINDOWS
? '.exe' :
> ''}"))
>
> Are there already plans to move to javac -h instead?
> It seems a relative easy task that might be done by someone from
the wider
> community?
>
> Thanks,
>
> - Johan
>

Re: javah deprecated?

[Johan Vos]

The headers are required indeed.
modules/javafx.web/src/main/native/Source/WTF/wtf/unicode/java/UnicodeJava.h
includes java_lang_Character.h in order to access the static final fields
in Character.java

- Johan

On Thu, Nov 30, 2017 at 12:07 PM Johan Vos  wrote:

> There was a related issue at
> https://bugs.openjdk.java.net/browse/JDK-8170591 about going back to
> javah instead of javac -h but that doesn't talk about why the headers for
> Character and IDN are needed.
>
> I'm building without those headers (takes almost 1 hour though to build
> webkit on linux) so I'll find out if they are needed on linux.
>
> - Johan
>
> On Thu, Nov 30, 2017 at 11:42 AM Johan Vos  wrote:
>
>> I filed a bug (https://bugs.openjdk.java.net/browse/JDK-8192806) and I
>> am looking into it.
>>
>> It seems a bit weird to me that the java.lang.Character and java.net.IDN
>> header files are needed. I'll remove them and see where it fails.
>> But if they are needed (and they probably are), it won't be easy to
>> generate them with javac -h as that requires the source code instead of the
>> classfiles. That would require access to the java.lang.Character and
>> java.net.IDN java source code in OpenJDK, from within OpenJFX.
>>
>> - Johan
>>
>> On Wed, Nov 29, 2017 at 8:02 PM Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>> Hi Johan,
>>>
>>> Thanks for pointing this out. I had missed that this was targeted to JDK
>>> 10.
>>>
>>> We eliminated all but one use of javah, in favor of javac -h, in JDK 9
>>> [1]. The only one remaining is in the web module. I can't remember why
>>> that wasn't switched at the same time (I have a fuzzy recollection that
>>> it might have had something to do with incremental compilation), but
>>> yes, it seems like this will need to be fixed.
>>>
>>> If you would like to file a bug then this would be a great thing for the
>>> community to work on. This will block us from moving to JDK 10 as a boot
>>> JDK, so if we end up doing that for JDK 10 then this would need to be
>>> done soon.
>>>
>>> Let me know if you would like to work on this.
>>>
>>> Thanks.
>>>
>>> -- Kevin
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8161704
>>>
>>>
>>> Johan Vos wrote:
>>> > Hi,
>>> >
>>> > I learned javah might be removed in Java 10 (
>>> > http://openjdk.java.net/jeps/313) but as far as I know, it is still
>>> used in
>>> > OpenJFX:
>>> >
>>> > defineProperty("JAVAH", cygpath("$JDK_HOME/bin/javah${IS_WINDOWS ?
>>> '.exe' :
>>> > ''}"))
>>> >
>>> > Are there already plans to move to javac -h instead?
>>> > It seems a relative easy task that might be done by someone from the
>>> wider
>>> > community?
>>> >
>>> > Thanks,
>>> >
>>> > - Johan
>>> >
>>>
>>

Re: javah deprecated?

[Johan Vos]

There was a related issue at
https://bugs.openjdk.java.net/browse/JDK-8170591 about going back to javah
instead of javac -h but that doesn't talk about why the headers for
Character and IDN are needed.

I'm building without those headers (takes almost 1 hour though to build
webkit on linux) so I'll find out if they are needed on linux.

- Johan

On Thu, Nov 30, 2017 at 11:42 AM Johan Vos  wrote:

> I filed a bug (https://bugs.openjdk.java.net/browse/JDK-8192806) and I am
> looking into it.
>
> It seems a bit weird to me that the java.lang.Character and java.net.IDN
> header files are needed. I'll remove them and see where it fails.
> But if they are needed (and they probably are), it won't be easy to
> generate them with javac -h as that requires the source code instead of the
> classfiles. That would require access to the java.lang.Character and
> java.net.IDN java source code in OpenJDK, from within OpenJFX.
>
> - Johan
>
> On Wed, Nov 29, 2017 at 8:02 PM Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Hi Johan,
>>
>> Thanks for pointing this out. I had missed that this was targeted to JDK
>> 10.
>>
>> We eliminated all but one use of javah, in favor of javac -h, in JDK 9
>> [1]. The only one remaining is in the web module. I can't remember why
>> that wasn't switched at the same time (I have a fuzzy recollection that
>> it might have had something to do with incremental compilation), but
>> yes, it seems like this will need to be fixed.
>>
>> If you would like to file a bug then this would be a great thing for the
>> community to work on. This will block us from moving to JDK 10 as a boot
>> JDK, so if we end up doing that for JDK 10 then this would need to be
>> done soon.
>>
>> Let me know if you would like to work on this.
>>
>> Thanks.
>>
>> -- Kevin
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8161704
>>
>>
>> Johan Vos wrote:
>> > Hi,
>> >
>> > I learned javah might be removed in Java 10 (
>> > http://openjdk.java.net/jeps/313) but as far as I know, it is still
>> used in
>> > OpenJFX:
>> >
>> > defineProperty("JAVAH", cygpath("$JDK_HOME/bin/javah${IS_WINDOWS ?
>> '.exe' :
>> > ''}"))
>> >
>> > Are there already plans to move to javac -h instead?
>> > It seems a relative easy task that might be done by someone from the
>> wider
>> > community?
>> >
>> > Thanks,
>> >
>> > - Johan
>> >
>>
>

Re: javapackager feedback and questions

[Mani Sarkar]

Thanks Victor for you response and invite. I'll get back with details for
your query.

Just for your info, I was referring to javapackager in the context of Java
9 built artifacts.

On Thu, 30 Nov 2017 09:28 Michael Hall,  wrote:

>
> > On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:
> >
> > Hi, Mani.
> >
> > Thanks for providing the feedback!
> > We will consider adding more examples and more details in the docs as
> you proposed(there is an arg named jvmOptions but that's not mentioned in
> the table).
> > Looks like there is a bug when you specify systemWide=true on the MacOSX
> in non-gui mode. Can you provide more details about that (like full cmd
> line)?
> > Actually, if you want you can clone the repo:
> > http://hg.openjdk.java.net/openjfx/10-dev/rt/
> > (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> > and help to improve javapackager. Or you can just create Enhancements
> for deploy/packager, as it's not always clear what users expect.
> >
>
> Why was JEP 311 [1] Closed/Withdrawn?
>
> [1] http://openjdk.java.net/jeps/311
>
> --

@theNeomatrix369   |  Blog
  |  @adoptopenjdk | Dev communities

Meet-a-Project - MutabilityDetector 
 |  Github   | Slideshare
  | LinkedIn


Come to Devoxx UK 2018: http://www.devoxx.co.uk/

Don't chase success, rather aim for "Excellence", and success will come
chasing after you!

Re: javah deprecated?

[Johan Vos]

I filed a bug (https://bugs.openjdk.java.net/browse/JDK-8192806) and I am
looking into it.

It seems a bit weird to me that the java.lang.Character and java.net.IDN
header files are needed. I'll remove them and see where it fails.
But if they are needed (and they probably are), it won't be easy to
generate them with javac -h as that requires the source code instead of the
classfiles. That would require access to the java.lang.Character and
java.net.IDN java source code in OpenJDK, from within OpenJFX.

- Johan

On Wed, Nov 29, 2017 at 8:02 PM Kevin Rushforth 
wrote:

> Hi Johan,
>
> Thanks for pointing this out. I had missed that this was targeted to JDK
> 10.
>
> We eliminated all but one use of javah, in favor of javac -h, in JDK 9
> [1]. The only one remaining is in the web module. I can't remember why
> that wasn't switched at the same time (I have a fuzzy recollection that
> it might have had something to do with incremental compilation), but
> yes, it seems like this will need to be fixed.
>
> If you would like to file a bug then this would be a great thing for the
> community to work on. This will block us from moving to JDK 10 as a boot
> JDK, so if we end up doing that for JDK 10 then this would need to be
> done soon.
>
> Let me know if you would like to work on this.
>
> Thanks.
>
> -- Kevin
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8161704
>
>
> Johan Vos wrote:
> > Hi,
> >
> > I learned javah might be removed in Java 10 (
> > http://openjdk.java.net/jeps/313) but as far as I know, it is still
> used in
> > OpenJFX:
> >
> > defineProperty("JAVAH", cygpath("$JDK_HOME/bin/javah${IS_WINDOWS ?
> '.exe' :
> > ''}"))
> >
> > Are there already plans to move to javac -h instead?
> > It seems a relative easy task that might be done by someone from the
> wider
> > community?
> >
> > Thanks,
> >
> > - Johan
> >
>

Re: javapackager feedback and questions

[Michael Hall]

> On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:
> 
> Hi, Mani.
> 
> Thanks for providing the feedback!
> We will consider adding more examples and more details in the docs as you 
> proposed(there is an arg named jvmOptions but that's not mentioned in the 
> table).
> Looks like there is a bug when you specify systemWide=true on the MacOSX in 
> non-gui mode. Can you provide more details about that (like full cmd line)?
> Actually, if you want you can clone the repo:
> http://hg.openjdk.java.net/openjfx/10-dev/rt/
> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> and help to improve javapackager. Or you can just create Enhancements for 
> deploy/packager, as it's not always clear what users expect.
> 

Why was JEP 311 [1] Closed/Withdrawn?

[1] http://openjdk.java.net/jeps/311

Re: javapackager feedback and questions

[Michael Paus]

Hi,
I am wondering why you can say that ".dmg and .msi packaging work very well"
because there is this still open bug 
https://bugs.openjdk.java.net/browse/JDK-8179033
which keeps me from building DMG files on Java 9. Are you still using 
Java 8?

Michael

Am 29.11.17 um 12:48 schrieb Mani Sarkar:

Hi all,

First I hope I'm writing to the correct mailing list, if not please suggest
where to write instead. Also if it is worth writing back as separate
messages per issue or item, please do let me know.

Some of my observations and feedback when using *javapackager*:

*Positives*
- .dmg and .msi packaging work very well out of the box, easy to put
together configuration settings
- .rpm packages build very quickly
- a number of features from FPM (docs
 | GitHub
) available but some more for the
individual types of packages would certainly help (for e.g. exposing some
more of the CLI flags for DEB and RPM packaging)

*Improvements*
- [doc and example required]: Additional documentation and examples around
how to add a license when building a package would be helpful. After a bit
of searching on google and experimenting with couple of combinations of CLI
options I was able to figure it out.
- [doc correction]: jvmUserArg is referred to in the documentation with
examples, while in the usage documentation jvmOptions is used (discrepancy
between the names of flags), see
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javapackager.html
  and
https://docs.oracle.com/javase/9/deploy/self-contained-application-packaging.htm#JSDPG585
- [doc correction]: same goes for mac.signing-key-user-name while there is
no mention of it in the javapackager usage documentation, it takes the full
name of the user i.e. *Jane Doe*
*- *[doc and example required]: just adding
mac.signing-key-developer-id-app=x isn't enough, needs the other
code-sign related flags as well, possibly key should be in the Mac KeyStore
when building it (check if id provided is the correct one, additional
examples would definitely help to reduce or eliminate experimentation and
assumptions)
- [potential bug]: Using *-B*systemWide=true flag causes error -10810 when
building on the MacOSX in non-gui mode, can be overridden by using the
-Bmac.dmg.simple=true but we loose the backdrop and automatic shortcut
creation, etc... Swappin gthe order to: -Bmac.dmg.simple=true and *-B*
systemWide=true does not help, still ends up building a .dmg package with
just the app in it (no icon, no background)
- code signing examples for Windows and MacOSX will certainly help quite a
bit
- [doc and example required] .deb packages take a long time to build, some
additional flags that can help. Some findings along the lines on how to
speed up dpkg-build:

export CCACHE_DIR=/home/$USER/.ccache

export CCACHE_HASHDIR=$CCACHE_DIR

export DEB_BUILD_OPTIONS="${DEB_BUILD_OPTIONS} --preserve-envvar=CCACHE_DIR
--prepend-path=/usr/lib/ccache parallel=jobs"

echo "Debian build options: ${DEB_BUILD_OPTIONS}"

---

A response with answers for the above will be highly appreciated.

Thanks.

Cheers,
Mani