From swingler at apple.com  Sun Feb  1 00:49:04 2015
From: swingler at apple.com (Mike Swingler)
Date: Sat, 31 Jan 2015 16:49:04 -0800
Subject: JRELoadError
In-Reply-To: <CALitSbvYHxzxH4krWJeGaW9FZG=c1_ow0F0TrfmY1r37piis-A@mail.gmail.com>
References: <ED32FFE2-CEF7-4FA9-9E97-680F6E2F8B8A@eteks.com>
	<C033E3AA-06C4-4DB9-8308-DC315D18FF8F@gmail.com>
	<CALitSbvYHxzxH4krWJeGaW9FZG=c1_ow0F0TrfmY1r37piis-A@mail.gmail.com>
Message-ID: <52CA5C47-DBFC-4275-A688-2016B2EBFA6F@apple.com>

Please search for the Java 7, 8, 9 JVM symbols before trying to find the Java 6 symbols. We are actively discouraging developers from using Apples Java SE 6, since it has been deprecated for almost 5 years, and will be unavailable for some future version of OS X. We want developers and users using the best/newest Java available, even if Apple's old one is installed.

Thanks
Mike Swingler
Apple Inc.

> On Jan 31, 2015, at 8:45 AM, Peter J Slack <pslack at wavedna.com> wrote:
> 
> The Mac version JRE 1.6 uses different symbols than 1.7 and 1.8 for the 2
> key functions used by a launcher to load and run JVM
> 
> in order to remedy this I've searched both symbols in case one fails when
> launching a JVM in my own launcher
> 
> Launchers have to load the library into memory and then wrap 2 key
> functions.  Apple names these functions differently
> 
> here's a code snippet in C illustrating how I've adapted setting up to
> launch the JVM by loading in memory, if the Apple naming fails I revert to
> openjdk naming
> 
> //first see if the apple naming is active
> WRAPPED_JNI_CreateJavaVM my_JNI_CreateJavaVM = (WRAPPED_JNI_CreateJavaVM)
> dlsym(handle,"JNI_CreateJavaVM_Impl");
> 
> //we need to try the possibility that this is not Apple JVM where they
> mangle the names by appending _impl
>        if(my_JNI_CreateJavaVM == NULL){
> 
>               //this is the case for openjdk 1.7 + where they use the
> traditional symbols in jvm.dll
> my_JNI_CreateJavaVM = (WRAPPED_JNI_CreateJavaVM)
> dlsym(handle,"JNI_CreateJavaVM");
> 
> }
> 
> WRAPPED_JNI_GetCreatedJavaVMs my_JNI_GetCreatedJavaVMs =
> (WRAPPED_JNI_GetCreatedJavaVMs)dlsym(handle,"JNI_GetCreatedJavaVMs_Impl");
> 
> if(my_JNI_GetCreatedJavaVMs == NULL){
> my_JNI_GetCreatedJavaVMs =
> (WRAPPED_JNI_GetCreatedJavaVMs)dlsym(handle,"JNI_GetCreatedJavaVMs");
> }
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Fri, Jan 30, 2015 at 8:43 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> On Jan 30, 2015, at 4:00 PM, Emmanuel Puybaret <puybaret at eteks.com> wrote:
>> 
>>> Hi,
>>> 
>>> I developed a sandboxed version of Sweet Home 3D that comes with its own
>> copy of JRE 7.
>>> Miserably, a few users reported recently that they got a "JRELoadError"
>> when they launch the application.
>>> I tried to update from JRE 7u72 to JRE 7u76, tried to replace
>> JavaAppLauncher by the launcher generated by javafxpackager,  and also
>> tried to replace the JRE 7 copy by a JRE 8 copy, but these users reported
>> to me it didn't fix this issue.
>>> 
>>> Would have any of you encounter this problem and/or have an idea how to
>> fix it?
>> 
>> A number of apps seem to have had the issue if you search on the subject
>> error.
>> This post?.
>> 
>> 
>> http://jedit.9.x6.nabble.com/jEdit-users-JRELoadError-launching-jEdit-5-2pre1-after-mavericks-upgrade-but-no-java-version-or-JAVAe-td5005300.html
>> 
>> had a lot of mail list noise but ended up with some valid enough
>> suggestions as to what the possible conflicts might be.
>> Use of JAVA_HOME
>> conflicting with the browser installed JRE version
>> some sort of embedded symlink back to an apple JRE
>> the possibilities that I remember.
>> It suggested a work around of using a 3rd party package for running an app
>> configuration that would work with both Apple and Oracle JRE?s.
>> There might be some information of use to you in that one. There were a
>> number of apps that appeared to have the issue.
>> 
>> Michael Hall
>> 
>> trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz
>> 
>> HalfPipe Java 6/7 shell app
>> http://www195.pair.com/mik3hall/index.html#halfpipe
>> 
>> AppConverter convert Apple jvm to openjdk apps
>> http://www195.pair.com/mik3hall/index.html#appconverter
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Senior Software Developer / IT Administrator
> Work:  (416) 466-9283
> Fax  :  (866)  855-2605
> 
> <http://www.wavedna.com/>
>   <https://www.facebook.com/waveDNA>  <http://www.twitter.com/wavedna>
> <http://www.youtube.com/wavedna>  <http://www.soundcloud.com/wavedna>
> <https://plus.google.com/+Wavedna/posts>  <http://instagram.com/wavedna>
> <http://www.linkedin.com/company/wavedna>


From pslack at wavedna.com  Sun Feb  1 16:42:31 2015
From: pslack at wavedna.com (Peter J Slack)
Date: Sun, 1 Feb 2015 11:42:31 -0500
Subject: JRELoadError
In-Reply-To: <52CA5C47-DBFC-4275-A688-2016B2EBFA6F@apple.com>
References: <ED32FFE2-CEF7-4FA9-9E97-680F6E2F8B8A@eteks.com>
	<C033E3AA-06C4-4DB9-8308-DC315D18FF8F@gmail.com>
	<CALitSbvYHxzxH4krWJeGaW9FZG=c1_ow0F0TrfmY1r37piis-A@mail.gmail.com>
	<52CA5C47-DBFC-4275-A688-2016B2EBFA6F@apple.com>
Message-ID: <CALitSbsJuDQfZLLYzMMe=h3fEhYSbPdyCe9V4F_V6fM0Nx9J3Q@mail.gmail.com>

Just to clarify my post, I'm suggesting this is potentially the reason why
some canned java launchers may not be working with openjdk 1.7 + as opposed
to recommending using java 1.6.

As far as canned launchers go, I would recommend Oracle's FX Ant.  not only
does it embed java for you and create an application bundle , it creates a
package installer, also works for windows.

the FX:DEPLOY task constructs the launcher for your project

http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference.htm





On Sat, Jan 31, 2015 at 7:49 PM, Mike Swingler <swingler at apple.com> wrote:

> Please search for the Java 7, 8, 9 JVM symbols before trying to find the
> Java 6 symbols. We are actively discouraging developers from using Apples
> Java SE 6, since it has been deprecated for almost 5 years, and will be
> unavailable for some future version of OS X. We want developers and users
> using the best/newest Java available, even if Apple's old one is installed.
>
> Thanks
> Mike Swingler
> Apple Inc.
>
> > On Jan 31, 2015, at 8:45 AM, Peter J Slack <pslack at wavedna.com> wrote:
> >
> > The Mac version JRE 1.6 uses different symbols than 1.7 and 1.8 for the 2
> > key functions used by a launcher to load and run JVM
> >
> > in order to remedy this I've searched both symbols in case one fails when
> > launching a JVM in my own launcher
> >
> > Launchers have to load the library into memory and then wrap 2 key
> > functions.  Apple names these functions differently
> >
> > here's a code snippet in C illustrating how I've adapted setting up to
> > launch the JVM by loading in memory, if the Apple naming fails I revert
> to
> > openjdk naming
> >
> > //first see if the apple naming is active
> > WRAPPED_JNI_CreateJavaVM my_JNI_CreateJavaVM = (WRAPPED_JNI_CreateJavaVM)
> > dlsym(handle,"JNI_CreateJavaVM_Impl");
> >
> > //we need to try the possibility that this is not Apple JVM where they
> > mangle the names by appending _impl
> >        if(my_JNI_CreateJavaVM == NULL){
> >
> >               //this is the case for openjdk 1.7 + where they use the
> > traditional symbols in jvm.dll
> > my_JNI_CreateJavaVM = (WRAPPED_JNI_CreateJavaVM)
> > dlsym(handle,"JNI_CreateJavaVM");
> >
> > }
> >
> > WRAPPED_JNI_GetCreatedJavaVMs my_JNI_GetCreatedJavaVMs =
> >
> (WRAPPED_JNI_GetCreatedJavaVMs)dlsym(handle,"JNI_GetCreatedJavaVMs_Impl");
> >
> > if(my_JNI_GetCreatedJavaVMs == NULL){
> > my_JNI_GetCreatedJavaVMs =
> > (WRAPPED_JNI_GetCreatedJavaVMs)dlsym(handle,"JNI_GetCreatedJavaVMs");
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Jan 30, 2015 at 8:43 PM, Michael Hall <mik3hall at gmail.com>
> wrote:
> >
> >> On Jan 30, 2015, at 4:00 PM, Emmanuel Puybaret <puybaret at eteks.com>
> wrote:
> >>
> >>> Hi,
> >>>
> >>> I developed a sandboxed version of Sweet Home 3D that comes with its
> own
> >> copy of JRE 7.
> >>> Miserably, a few users reported recently that they got a "JRELoadError"
> >> when they launch the application.
> >>> I tried to update from JRE 7u72 to JRE 7u76, tried to replace
> >> JavaAppLauncher by the launcher generated by javafxpackager,  and also
> >> tried to replace the JRE 7 copy by a JRE 8 copy, but these users
> reported
> >> to me it didn't fix this issue.
> >>>
> >>> Would have any of you encounter this problem and/or have an idea how to
> >> fix it?
> >>
> >> A number of apps seem to have had the issue if you search on the subject
> >> error.
> >> This post?.
> >>
> >>
> >>
> http://jedit.9.x6.nabble.com/jEdit-users-JRELoadError-launching-jEdit-5-2pre1-after-mavericks-upgrade-but-no-java-version-or-JAVAe-td5005300.html
> >>
> >> had a lot of mail list noise but ended up with some valid enough
> >> suggestions as to what the possible conflicts might be.
> >> Use of JAVA_HOME
> >> conflicting with the browser installed JRE version
> >> some sort of embedded symlink back to an apple JRE
> >> the possibilities that I remember.
> >> It suggested a work around of using a 3rd party package for running an
> app
> >> configuration that would work with both Apple and Oracle JRE?s.
> >> There might be some information of use to you in that one. There were a
> >> number of apps that appeared to have the issue.
> >>
> >> Michael Hall
> >>
> >> trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz
> >>
> >> HalfPipe Java 6/7 shell app
> >> http://www195.pair.com/mik3hall/index.html#halfpipe
> >>
> >> AppConverter convert Apple jvm to openjdk apps
> >> http://www195.pair.com/mik3hall/index.html#appconverter
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Senior Software Developer / IT Administrator
> > Work:  (416) 466-9283
> > Fax  :  (866) 855-2605
> >
> > <http://www.wavedna.com/>
> >   <https://www.facebook.com/waveDNA>  <http://www.twitter.com/wavedna>
> > <http://www.youtube.com/wavedna>  <http://www.soundcloud.com/wavedna>
> > <https://plus.google.com/+Wavedna/posts>  <http://instagram.com/wavedna>
> > <http://www.linkedin.com/company/wavedna>
>
>


-- 
Senior Software Developer / IT Administrator
Work:  (416) 466-9283
Fax  :  (866)  855-2605

<http://www.wavedna.com/>
   <https://www.facebook.com/waveDNA>  <http://www.twitter.com/wavedna>
<http://www.youtube.com/wavedna>  <http://www.soundcloud.com/wavedna>
<https://plus.google.com/+Wavedna/posts>  <http://instagram.com/wavedna>
<http://www.linkedin.com/company/wavedna>

From puybaret at eteks.com  Sun Feb  1 20:17:47 2015
From: puybaret at eteks.com (Emmanuel Puybaret)
Date: Sun, 1 Feb 2015 21:17:47 +0100
Subject: JRELoadError
In-Reply-To: <CALitSbsJuDQfZLLYzMMe=h3fEhYSbPdyCe9V4F_V6fM0Nx9J3Q@mail.gmail.com>
References: <ED32FFE2-CEF7-4FA9-9E97-680F6E2F8B8A@eteks.com>
	<C033E3AA-06C4-4DB9-8308-DC315D18FF8F@gmail.com>
	<CALitSbvYHxzxH4krWJeGaW9FZG=c1_ow0F0TrfmY1r37piis-A@mail.gmail.com>
	<52CA5C47-DBFC-4275-A688-2016B2EBFA6F@apple.com>
	<CALitSbsJuDQfZLLYzMMe=h3fEhYSbPdyCe9V4F_V6fM0Nx9J3Q@mail.gmail.com>
Message-ID: <BCAD1A39-7936-4CA3-9E8E-E7BC669BB941@eteks.com>

Thank you all for your suggestions.
Just to be clear, this error happens for very few users in a sandboxed version of the program that embeds a copy of the JRE.
The error happens with JavaAppLauncher and with the launcher provided with javafxpacakager.
Nevertheless, I requested to a user who encountered this issue to reset JAVA_HOME and to remove all JVMs he could find
in folders "/Library/Internet Plug-Ins", "/Library/Java/JavaVirtualMachines" and "/System/Library/Java/JavaVirtualMachines".
From his report, this didn't help at all. :-(

Any other idea of a possible conflict?

Thans for your help :-)
--
Emmanuel PUYBARET
Email  : puybaret at eteks.com
Web    : http://www.eteks.com
         http://www.sweethome3d.com

> Le 1 f?vr. 2015 ? 17:42, Peter J Slack <pslack at wavedna.com> a ?crit :
> 
> Just to clarify my post, I'm suggesting this is potentially the reason why some canned java launchers may not be working with openjdk 1.7 + as opposed to recommending using java 1.6. 
> 
> As far as canned launchers go, I would recommend Oracle's FX Ant.  not only does it embed java for you and create an application bundle , it creates a package installer, also works for windows.
> 
> the FX:DEPLOY task constructs the launcher for your project
> 
> http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference.htm <http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference.htm>
> 
> 
> 
> 
> 
> On Sat, Jan 31, 2015 at 7:49 PM, Mike Swingler <swingler at apple.com <mailto:swingler at apple.com>> wrote:
> Please search for the Java 7, 8, 9 JVM symbols before trying to find the Java 6 symbols. We are actively discouraging developers from using Apples Java SE 6, since it has been deprecated for almost 5 years, and will be unavailable for some future version of OS X. We want developers and users using the best/newest Java available, even if Apple's old one is installed.
> 
> Thanks
> Mike Swingler
> Apple Inc.
> 
> > On Jan 31, 2015, at 8:45 AM, Peter J Slack <pslack at wavedna.com <mailto:pslack at wavedna.com>> wrote:
> >
> > The Mac version JRE 1.6 uses different symbols than 1.7 and 1.8 for the 2
> > key functions used by a launcher to load and run JVM
> >
> > in order to remedy this I've searched both symbols in case one fails when
> > launching a JVM in my own launcher
> >
> > Launchers have to load the library into memory and then wrap 2 key
> > functions.  Apple names these functions differently
> >
> > here's a code snippet in C illustrating how I've adapted setting up to
> > launch the JVM by loading in memory, if the Apple naming fails I revert to
> > openjdk naming
> >
> > //first see if the apple naming is active
> > WRAPPED_JNI_CreateJavaVM my_JNI_CreateJavaVM = (WRAPPED_JNI_CreateJavaVM)
> > dlsym(handle,"JNI_CreateJavaVM_Impl");
> >
> > //we need to try the possibility that this is not Apple JVM where they
> > mangle the names by appending _impl
> >        if(my_JNI_CreateJavaVM == NULL){
> >
> >               //this is the case for openjdk 1.7 + where they use the
> > traditional symbols in jvm.dll
> > my_JNI_CreateJavaVM = (WRAPPED_JNI_CreateJavaVM)
> > dlsym(handle,"JNI_CreateJavaVM");
> >
> > }
> >
> > WRAPPED_JNI_GetCreatedJavaVMs my_JNI_GetCreatedJavaVMs =
> > (WRAPPED_JNI_GetCreatedJavaVMs)dlsym(handle,"JNI_GetCreatedJavaVMs_Impl");
> >
> > if(my_JNI_GetCreatedJavaVMs == NULL){
> > my_JNI_GetCreatedJavaVMs =
> > (WRAPPED_JNI_GetCreatedJavaVMs)dlsym(handle,"JNI_GetCreatedJavaVMs");
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Jan 30, 2015 at 8:43 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
> >
> >> On Jan 30, 2015, at 4:00 PM, Emmanuel Puybaret <puybaret at eteks.com <mailto:puybaret at eteks.com>> wrote:
> >>
> >>> Hi,
> >>>
> >>> I developed a sandboxed version of Sweet Home 3D that comes with its own
> >> copy of JRE 7.
> >>> Miserably, a few users reported recently that they got a "JRELoadError"
> >> when they launch the application.
> >>> I tried to update from JRE 7u72 to JRE 7u76, tried to replace
> >> JavaAppLauncher by the launcher generated by javafxpackager,  and also
> >> tried to replace the JRE 7 copy by a JRE 8 copy, but these users reported
> >> to me it didn't fix this issue.
> >>>
> >>> Would have any of you encounter this problem and/or have an idea how to
> >> fix it?
> >>
> >> A number of apps seem to have had the issue if you search on the subject
> >> error.
> >> This post?.
> >>
> >>
> >> http://jedit.9.x6.nabble.com/jEdit-users-JRELoadError-launching-jEdit-5-2pre1-after-mavericks-upgrade-but-no-java-version-or-JAVAe-td5005300.html <http://jedit.9.x6.nabble.com/jEdit-users-JRELoadError-launching-jEdit-5-2pre1-after-mavericks-upgrade-but-no-java-version-or-JAVAe-td5005300.html>
> >>
> >> had a lot of mail list noise but ended up with some valid enough
> >> suggestions as to what the possible conflicts might be.
> >> Use of JAVA_HOME
> >> conflicting with the browser installed JRE version
> >> some sort of embedded symlink back to an apple JRE
> >> the possibilities that I remember.
> >> It suggested a work around of using a 3rd party package for running an app
> >> configuration that would work with both Apple and Oracle JRE?s.
> >> There might be some information of use to you in that one. There were a
> >> number of apps that appeared to have the issue.
> >>
> >> Michael Hall
> >>
> >> trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz <http://www195.pair.com/mik3hall/index.html#trz>
> >>
> >> HalfPipe Java 6/7 shell app
> >> http://www195.pair.com/mik3hall/index.html#halfpipe <http://www195.pair.com/mik3hall/index.html#halfpipe>
> >>
> >> AppConverter convert Apple jvm to openjdk apps
> >> http://www195.pair.com/mik3hall/index.html#appconverter <http://www195.pair.com/mik3hall/index.html#appconverter>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Senior Software Developer / IT Administrator
> > Work:  (416) 466-9283 <tel:%28416%29%20466-9283>
> > Fax  :  (866) 855-2605 <tel:%28866%29%20%20855-2605>
> >
> > <http://www.wavedna.com/ <http://www.wavedna.com/>>
> >   <https://www.facebook.com/waveDNA <https://www.facebook.com/waveDNA>>  <http://www.twitter.com/wavedna <http://www.twitter.com/wavedna>>
> > <http://www.youtube.com/wavedna <http://www.youtube.com/wavedna>>  <http://www.soundcloud.com/wavedna <http://www.soundcloud.com/wavedna>>
> > <https://plus.google.com/+Wavedna/posts <https://plus.google.com/+Wavedna/posts>>  <http://instagram.com/wavedna <http://instagram.com/wavedna>>
> > <http://www.linkedin.com/company/wavedna <http://www.linkedin.com/company/wavedna>>
> 
> 
> 
> 
> -- 
> Senior Software Developer / IT Administrator
> Work:  (416) 466-9283 <>
> Fax  :  (866) ?855-2605 <>


From swingler at apple.com  Sun Feb  1 23:01:51 2015
From: swingler at apple.com (Mike Swingler)
Date: Sun, 1 Feb 2015 15:01:51 -0800
Subject: JRELoadError
In-Reply-To: <BCAD1A39-7936-4CA3-9E8E-E7BC669BB941@eteks.com>
References: <ED32FFE2-CEF7-4FA9-9E97-680F6E2F8B8A@eteks.com>
	<C033E3AA-06C4-4DB9-8308-DC315D18FF8F@gmail.com>
	<CALitSbvYHxzxH4krWJeGaW9FZG=c1_ow0F0TrfmY1r37piis-A@mail.gmail.com>
	<52CA5C47-DBFC-4275-A688-2016B2EBFA6F@apple.com>
	<CALitSbsJuDQfZLLYzMMe=h3fEhYSbPdyCe9V4F_V6fM0Nx9J3Q@mail.gmail.com>
	<BCAD1A39-7936-4CA3-9E8E-E7BC669BB941@eteks.com>
Message-ID: <21A9E44D-7CB0-447E-903A-A9B1823261CE@apple.com>

A few things you might want to try (since you mentioned that the app was sandboxed):
- Check the app bundle's code signature validity with "codesign -vvvv"
- Try launching the app inside of a clean new user account.
- Ask the user if they have a different GateKeeper setting than you do.
- Ask the user which OS version they are on, and compare it to the one you are using to reproduce.

Good luck,
Mike Swingler
Apple Inc.

> On Feb 1, 2015, at 12:17 PM, Emmanuel Puybaret <puybaret at eteks.com> wrote:
> 
> Thank you all for your suggestions.
> Just to be clear, this error happens for very few users in a sandboxed version of the program that embeds a copy of the JRE.
> The error happens with JavaAppLauncher and with the launcher provided with javafxpacakager.
> Nevertheless, I requested to a user who encountered this issue to reset JAVA_HOME and to remove all JVMs he could find
> in folders "/Library/Internet Plug-Ins", "/Library/Java/JavaVirtualMachines" and "/System/Library/Java/JavaVirtualMachines".
> From his report, this didn't help at all. :-(
> 
> Any other idea of a possible conflict?
> 
> Thans for your help :-)
> --
> Emmanuel PUYBARET
> Email  : puybaret at eteks.com <mailto:puybaret at eteks.com>
> Web    : http://www.eteks.com <http://www.eteks.com/>
>          http://www.sweethome3d.com <http://www.sweethome3d.com/>
>> Le 1 f?vr. 2015 ? 17:42, Peter J Slack <pslack at wavedna.com <mailto:pslack at wavedna.com>> a ?crit :
>> 
>> Just to clarify my post, I'm suggesting this is potentially the reason why some canned java launchers may not be working with openjdk 1.7 + as opposed to recommending using java 1.6. 
>> 
>> As far as canned launchers go, I would recommend Oracle's FX Ant.  not only does it embed java for you and create an application bundle , it creates a package installer, also works for windows.
>> 
>> the FX:DEPLOY task constructs the launcher for your project
>> 
>> http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference.htm <http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference.htm>
>> 
>> 
>> 
>> 
>> 
>> On Sat, Jan 31, 2015 at 7:49 PM, Mike Swingler <swingler at apple.com <mailto:swingler at apple.com>> wrote:
>> Please search for the Java 7, 8, 9 JVM symbols before trying to find the Java 6 symbols. We are actively discouraging developers from using Apples Java SE 6, since it has been deprecated for almost 5 years, and will be unavailable for some future version of OS X. We want developers and users using the best/newest Java available, even if Apple's old one is installed.
>> 
>> Thanks
>> Mike Swingler
>> Apple Inc.
>> 
>> > On Jan 31, 2015, at 8:45 AM, Peter J Slack <pslack at wavedna.com <mailto:pslack at wavedna.com>> wrote:
>> >
>> > The Mac version JRE 1.6 uses different symbols than 1.7 and 1.8 for the 2
>> > key functions used by a launcher to load and run JVM
>> >
>> > in order to remedy this I've searched both symbols in case one fails when
>> > launching a JVM in my own launcher
>> >
>> > Launchers have to load the library into memory and then wrap 2 key
>> > functions.  Apple names these functions differently
>> >
>> > here's a code snippet in C illustrating how I've adapted setting up to
>> > launch the JVM by loading in memory, if the Apple naming fails I revert to
>> > openjdk naming
>> >
>> > //first see if the apple naming is active
>> > WRAPPED_JNI_CreateJavaVM my_JNI_CreateJavaVM = (WRAPPED_JNI_CreateJavaVM)
>> > dlsym(handle,"JNI_CreateJavaVM_Impl");
>> >
>> > //we need to try the possibility that this is not Apple JVM where they
>> > mangle the names by appending _impl
>> >        if(my_JNI_CreateJavaVM == NULL){
>> >
>> >               //this is the case for openjdk 1.7 + where they use the
>> > traditional symbols in jvm.dll
>> > my_JNI_CreateJavaVM = (WRAPPED_JNI_CreateJavaVM)
>> > dlsym(handle,"JNI_CreateJavaVM");
>> >
>> > }
>> >
>> > WRAPPED_JNI_GetCreatedJavaVMs my_JNI_GetCreatedJavaVMs =
>> > (WRAPPED_JNI_GetCreatedJavaVMs)dlsym(handle,"JNI_GetCreatedJavaVMs_Impl");
>> >
>> > if(my_JNI_GetCreatedJavaVMs == NULL){
>> > my_JNI_GetCreatedJavaVMs =
>> > (WRAPPED_JNI_GetCreatedJavaVMs)dlsym(handle,"JNI_GetCreatedJavaVMs");
>> > }
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Fri, Jan 30, 2015 at 8:43 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>> >
>> >> On Jan 30, 2015, at 4:00 PM, Emmanuel Puybaret <puybaret at eteks.com <mailto:puybaret at eteks.com>> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> I developed a sandboxed version of Sweet Home 3D that comes with its own
>> >> copy of JRE 7.
>> >>> Miserably, a few users reported recently that they got a "JRELoadError"
>> >> when they launch the application.
>> >>> I tried to update from JRE 7u72 to JRE 7u76, tried to replace
>> >> JavaAppLauncher by the launcher generated by javafxpackager,  and also
>> >> tried to replace the JRE 7 copy by a JRE 8 copy, but these users reported
>> >> to me it didn't fix this issue.
>> >>>
>> >>> Would have any of you encounter this problem and/or have an idea how to
>> >> fix it?
>> >>
>> >> A number of apps seem to have had the issue if you search on the subject
>> >> error.
>> >> This post?.
>> >>
>> >>
>> >> http://jedit.9.x6.nabble.com/jEdit-users-JRELoadError-launching-jEdit-5-2pre1-after-mavericks-upgrade-but-no-java-version-or-JAVAe-td5005300.html <http://jedit.9.x6.nabble.com/jEdit-users-JRELoadError-launching-jEdit-5-2pre1-after-mavericks-upgrade-but-no-java-version-or-JAVAe-td5005300.html>
>> >>
>> >> had a lot of mail list noise but ended up with some valid enough
>> >> suggestions as to what the possible conflicts might be.
>> >> Use of JAVA_HOME
>> >> conflicting with the browser installed JRE version
>> >> some sort of embedded symlink back to an apple JRE
>> >> the possibilities that I remember.
>> >> It suggested a work around of using a 3rd party package for running an app
>> >> configuration that would work with both Apple and Oracle JRE?s.
>> >> There might be some information of use to you in that one. There were a
>> >> number of apps that appeared to have the issue.
>> >>
>> >> Michael Hall
>> >>
>> >> trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz <http://www195.pair.com/mik3hall/index.html#trz>
>> >>
>> >> HalfPipe Java 6/7 shell app
>> >> http://www195.pair.com/mik3hall/index.html#halfpipe <http://www195.pair.com/mik3hall/index.html#halfpipe>
>> >>
>> >> AppConverter convert Apple jvm to openjdk apps
>> >> http://www195.pair.com/mik3hall/index.html#appconverter <http://www195.pair.com/mik3hall/index.html#appconverter>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > Senior Software Developer / IT Administrator
>> > Work:  (416) 466-9283 <tel:%28416%29%20466-9283>
>> > Fax  :  (866) 855-2605 <tel:%28866%29%20%20855-2605>
>> >
>> > <http://www.wavedna.com/ <http://www.wavedna.com/>>
>> >   <https://www.facebook.com/waveDNA <https://www.facebook.com/waveDNA>>  <http://www.twitter.com/wavedna <http://www.twitter.com/wavedna>>
>> > <http://www.youtube.com/wavedna <http://www.youtube.com/wavedna>>  <http://www.soundcloud.com/wavedna <http://www.soundcloud.com/wavedna>>
>> > <https://plus.google.com/+Wavedna/posts <https://plus.google.com/+Wavedna/posts>>  <http://instagram.com/wavedna <http://instagram.com/wavedna>>
>> > <http://www.linkedin.com/company/wavedna <http://www.linkedin.com/company/wavedna>>
>> 
>> 
>> 
>> 
>> -- 
>> Senior Software Developer / IT Administrator
>> Work:  (416) 466-9283 <>
>> Fax  :  (866) ?855-2605 <>
> 


From david.dehaven at oracle.com  Mon Feb  2 16:44:23 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 2 Feb 2015 08:44:23 -0800
Subject: JRELoadError
In-Reply-To: <BCAD1A39-7936-4CA3-9E8E-E7BC669BB941@eteks.com>
References: <ED32FFE2-CEF7-4FA9-9E97-680F6E2F8B8A@eteks.com>
	<C033E3AA-06C4-4DB9-8308-DC315D18FF8F@gmail.com>
	<CALitSbvYHxzxH4krWJeGaW9FZG=c1_ow0F0TrfmY1r37piis-A@mail.gmail.com>
	<52CA5C47-DBFC-4275-A688-2016B2EBFA6F@apple.com>
	<CALitSbsJuDQfZLLYzMMe=h3fEhYSbPdyCe9V4F_V6fM0Nx9J3Q@mail.gmail.com>
	<BCAD1A39-7936-4CA3-9E8E-E7BC669BB941@eteks.com>
Message-ID: <181F24FC-FCDF-43FE-970C-D609F72A6FFF@oracle.com>


What version of the javafxpackager? Try using the latest in the 8u40 EA builds if you haven't already. You should still be able to bundle Java 7 with it if your app doesn't run with 8.

-DrD-

> Thank you all for your suggestions.
> Just to be clear, this error happens for very few users in a sandboxed version of the program that embeds a copy of the JRE.
> The error happens with JavaAppLauncher and with the launcher provided with javafxpacakager.
> Nevertheless, I requested to a user who encountered this issue to reset JAVA_HOME and to remove all JVMs he could find
> in folders "/Library/Internet Plug-Ins", "/Library/Java/JavaVirtualMachines" and "/System/Library/Java/JavaVirtualMachines".
> From his report, this didn't help at all. :-(
> 
> Any other idea of a possible conflict?
> 
> Thans for your help :-)
> --
> Emmanuel PUYBARET
> Email  : puybaret at eteks.com
> Web    : http://www.eteks.com
>         http://www.sweethome3d.com
> 
>> Le 1 f?vr. 2015 ? 17:42, Peter J Slack <pslack at wavedna.com> a ?crit :
>> 
>> Just to clarify my post, I'm suggesting this is potentially the reason why some canned java launchers may not be working with openjdk 1.7 + as opposed to recommending using java 1.6. 
>> 
>> As far as canned launchers go, I would recommend Oracle's FX Ant.  not only does it embed java for you and create an application bundle , it creates a package installer, also works for windows.
>> 
>> the FX:DEPLOY task constructs the launcher for your project
>> 
>> http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference.htm <http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference.htm>
>> 
>> 
>> 
>> 
>> 
>> On Sat, Jan 31, 2015 at 7:49 PM, Mike Swingler <swingler at apple.com <mailto:swingler at apple.com>> wrote:
>> Please search for the Java 7, 8, 9 JVM symbols before trying to find the Java 6 symbols. We are actively discouraging developers from using Apples Java SE 6, since it has been deprecated for almost 5 years, and will be unavailable for some future version of OS X. We want developers and users using the best/newest Java available, even if Apple's old one is installed.
>> 
>> Thanks
>> Mike Swingler
>> Apple Inc.
>> 
>>> On Jan 31, 2015, at 8:45 AM, Peter J Slack <pslack at wavedna.com <mailto:pslack at wavedna.com>> wrote:
>>> 
>>> The Mac version JRE 1.6 uses different symbols than 1.7 and 1.8 for the 2
>>> key functions used by a launcher to load and run JVM
>>> 
>>> in order to remedy this I've searched both symbols in case one fails when
>>> launching a JVM in my own launcher
>>> 
>>> Launchers have to load the library into memory and then wrap 2 key
>>> functions.  Apple names these functions differently
>>> 
>>> here's a code snippet in C illustrating how I've adapted setting up to
>>> launch the JVM by loading in memory, if the Apple naming fails I revert to
>>> openjdk naming
>>> 
>>> //first see if the apple naming is active
>>> WRAPPED_JNI_CreateJavaVM my_JNI_CreateJavaVM = (WRAPPED_JNI_CreateJavaVM)
>>> dlsym(handle,"JNI_CreateJavaVM_Impl");
>>> 
>>> //we need to try the possibility that this is not Apple JVM where they
>>> mangle the names by appending _impl
>>>       if(my_JNI_CreateJavaVM == NULL){
>>> 
>>>              //this is the case for openjdk 1.7 + where they use the
>>> traditional symbols in jvm.dll
>>> my_JNI_CreateJavaVM = (WRAPPED_JNI_CreateJavaVM)
>>> dlsym(handle,"JNI_CreateJavaVM");
>>> 
>>> }
>>> 
>>> WRAPPED_JNI_GetCreatedJavaVMs my_JNI_GetCreatedJavaVMs =
>>> (WRAPPED_JNI_GetCreatedJavaVMs)dlsym(handle,"JNI_GetCreatedJavaVMs_Impl");
>>> 
>>> if(my_JNI_GetCreatedJavaVMs == NULL){
>>> my_JNI_GetCreatedJavaVMs =
>>> (WRAPPED_JNI_GetCreatedJavaVMs)dlsym(handle,"JNI_GetCreatedJavaVMs");
>>> }
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Fri, Jan 30, 2015 at 8:43 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>>> 
>>>> On Jan 30, 2015, at 4:00 PM, Emmanuel Puybaret <puybaret at eteks.com <mailto:puybaret at eteks.com>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I developed a sandboxed version of Sweet Home 3D that comes with its own
>>>> copy of JRE 7.
>>>>> Miserably, a few users reported recently that they got a "JRELoadError"
>>>> when they launch the application.
>>>>> I tried to update from JRE 7u72 to JRE 7u76, tried to replace
>>>> JavaAppLauncher by the launcher generated by javafxpackager,  and also
>>>> tried to replace the JRE 7 copy by a JRE 8 copy, but these users reported
>>>> to me it didn't fix this issue.
>>>>> 
>>>>> Would have any of you encounter this problem and/or have an idea how to
>>>> fix it?
>>>> 
>>>> A number of apps seem to have had the issue if you search on the subject
>>>> error.
>>>> This post?.
>>>> 
>>>> 
>>>> http://jedit.9.x6.nabble.com/jEdit-users-JRELoadError-launching-jEdit-5-2pre1-after-mavericks-upgrade-but-no-java-version-or-JAVAe-td5005300.html <http://jedit.9.x6.nabble.com/jEdit-users-JRELoadError-launching-jEdit-5-2pre1-after-mavericks-upgrade-but-no-java-version-or-JAVAe-td5005300.html>
>>>> 
>>>> had a lot of mail list noise but ended up with some valid enough
>>>> suggestions as to what the possible conflicts might be.
>>>> Use of JAVA_HOME
>>>> conflicting with the browser installed JRE version
>>>> some sort of embedded symlink back to an apple JRE
>>>> the possibilities that I remember.
>>>> It suggested a work around of using a 3rd party package for running an app
>>>> configuration that would work with both Apple and Oracle JRE?s.
>>>> There might be some information of use to you in that one. There were a
>>>> number of apps that appeared to have the issue.
>>>> 
>>>> Michael Hall
>>>> 
>>>> trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz <http://www195.pair.com/mik3hall/index.html#trz>
>>>> 
>>>> HalfPipe Java 6/7 shell app
>>>> http://www195.pair.com/mik3hall/index.html#halfpipe <http://www195.pair.com/mik3hall/index.html#halfpipe>
>>>> 
>>>> AppConverter convert Apple jvm to openjdk apps
>>>> http://www195.pair.com/mik3hall/index.html#appconverter <http://www195.pair.com/mik3hall/index.html#appconverter>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Senior Software Developer / IT Administrator
>>> Work:  (416) 466-9283 <tel:%28416%29%20466-9283>
>>> Fax  :  (866) 855-2605 <tel:%28866%29%20%20855-2605>
>>> 
>>> <http://www.wavedna.com/ <http://www.wavedna.com/>>
>>>  <https://www.facebook.com/waveDNA <https://www.facebook.com/waveDNA>>  <http://www.twitter.com/wavedna <http://www.twitter.com/wavedna>>
>>> <http://www.youtube.com/wavedna <http://www.youtube.com/wavedna>>  <http://www.soundcloud.com/wavedna <http://www.soundcloud.com/wavedna>>
>>> <https://plus.google.com/+Wavedna/posts <https://plus.google.com/+Wavedna/posts>>  <http://instagram.com/wavedna <http://instagram.com/wavedna>>
>>> <http://www.linkedin.com/company/wavedna <http://www.linkedin.com/company/wavedna>>
>> 
>> 
>> 
>> 
>> -- 
>> Senior Software Developer / IT Administrator
>> Work:  (416) 466-9283 <>
>> Fax  :  (866)  855-2605 <>
> 


From Sergey.Bylokhov at oracle.com  Mon Feb  9 16:32:08 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 09 Feb 2015 19:32:08 +0300
Subject: java2d performance java7 / java8
In-Reply-To: <54C98058.4070208@users.sourceforge.net>
References: <53DFA95C.6040507@3kraft.com>	<53E0DE0F.5070507@oracle.com>	<53F20819.2020300@3kraft.com>	<023FA89F-A112-49A8-B234-18F97785969F@tagtraum.com>	<479011BB-C625-4E65-99AB-9C065466B1BA@tagtraum.com>
	<54C98058.4070208@users.sourceforge.net>
Message-ID: <54D8E108.4030003@oracle.com>

Hello,
Yes you are right, in the opengl pipeline usage of ARGB_PRE is 
preferable, but other pipelines can use different formats. So it is 
better to use GraphicsConfiguration.createCompatibleImage()
http://docs.oracle.com/javase/8/docs/api/java/awt/GraphicsConfiguration.html#createCompatibleImage-int-int-int-

On 29.01.2015 3:35, DRC wrote:
> I discovered in my own testing that, at least for my application 
> (which is drawing large BufferedImages to the screen), using a 
> TYPE_INT_ARGB_PRE BufferedImage is in some cases 4-5x as fast as using 
> a TYPE_INT_RGB BufferedImage.  The reason is because, if the pixel 
> format isn't alpha-enabled, then OGLBlitSwToSurface() will call 
> glPixelTransferf() to set the alpha scale and bias.  This is basically 
> instructing glDrawPixels() to set the alpha components to a particular 
> value, which can be incredibly slow (probably not even 
> hardware-accelerated on a lot of platforms.)  It's much faster to set 
> the alpha components to opaque in my source image.

Note that you can rewrite this part of openjdk, sources are open, 
patches are welcome!

>
> On my 2009 Mac Mini, the difference this makes is about 4x (80 
> Mpixels/sec vs. 20.)  On my Linux machine with a high-end nVidia card, 
> using ARGB_PRE with -Dsun.java2d.opengl=true increases the performance 
> from 300 Mixels/sec to 400.  On my MacBook Pro, the performance 
> increase is also about 1/3.  So I think that, in general, using 
> ARGB_PRE BufferedImages is best when using OpenGL Java2d blitting.
>
> The Mac performance with Java 1.7 or 1.8 is still not as good as it 
> was under Apple Java 1.6 (which was about 120 Mpixels/sec on the Mac 
> Mini), but it's at least a lot better.
>
>
> On 10/7/14 12:01 PM, Hendrik Schreiber wrote:
>> On Aug 22, 2014, at 11:59, Hendrik Schreiber <hs at tagtraum.com> wrote:
>>
>>> On Aug 18, 2014, at 16:05, Florian Bruckner (3kraft) 
>>> <florian.bruckner at 3kraft.com> wrote:
>>>
>>> [...]
>>>
>>> Thanks for coming up with some sort of test.
>>>
>>> Hopefully the folks at Oracle find the time to look into this, 
>>> perhaps do their own performance testing, and find ways to improve 
>>> the 2D pipeline.
>>
>> Looks like we have something to look forward to:
>>
>> http://mail.openjdk.java.net/pipermail/2d-dev/2014-October/004870.html
>>
>> -hendrik


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Feb  9 16:37:21 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 09 Feb 2015 19:37:21 +0300
Subject: FileDialog on OS X 10.10 with Java 8u25
In-Reply-To: <9740043A-91AA-4CB3-8440-7CD202EA62AA@gmail.com>
References: <mailman.16970.1411060609.10816.macosx-port-dev@openjdk.java.net>
	<9740043A-91AA-4CB3-8440-7CD202EA62AA@gmail.com>
Message-ID: <54D8E241.9060303@oracle.com>

Hi, William.
Please file a new bug at http://bugreport.sun.com/bugreport , don't 
forget to add a steps to reproduce your issue.

On 19.11.2014 19:39, William Moore wrote:
> Hello
>
> I'm using a java.awt.FileDialog to select a file for opening. I get the following error when I make the FileDialog visible:
>
> <error>
>
> 2014-11-19 17:09:10.925 java[11592:4309058] Unable to simultaneously satisfy constraints:
> (
>      "<NSAutoresizingMaskLayoutConstraint:0x7f8993cc3df0 h=--& v=--& V:[FI_TBrowserBackgroundView:0x7f8993d17a50(0)]>",
>      "<NSAutoresizingMaskLayoutConstraint:0x7f8993cc3800 h=-&- v=-&- V:|-(0)-[FI_TListScrollView:0x7f8993d54790]   (Names: '|':FI_TBrowserBackgroundView:0x7f8993d17a50 )>",
>      "<NSAutoresizingMaskLayoutConstraint:0x7f8993cc37b0 h=-&- v=-&- V:[FI_TListScrollView:0x7f8993d54790]-(0)-|   (Names: '|':FI_TBrowserBackgroundView:0x7f8993d17a50 )>",
>      "<NSAutoresizingMaskLayoutConstraint:0x7f8993cbe180 h=-&- v=-&- V:[NSClipView:0x7f8993bb5f50]-(15)-|   (Names: '|':FI_TListScrollView:0x7f8993d54790 )>",
>      "<NSAutoresizingMaskLayoutConstraint:0x7f8993cbe130 h=-&- v=-&- V:|-(0)-[NSClipView:0x7f8993bb5f50]   (Names: '|':FI_TListScrollView:0x7f8993d54790 )>"
> )
>
> Will attempt to recover by breaking constraint
> <NSAutoresizingMaskLayoutConstraint:0x7f8993cbe180 h=-&- v=-&- V:[NSClipView:0x7f8993bb5f50]-(15)-|   (Names: '|':FI_TListScrollView:0x7f8993d54790 )>
>
> Set the NSUserDefault NSConstraintBasedLayoutVisualizeMutuallyExclusiveConstraints to YES to have -[NSWindow visualizeConstraints:] automatically called when this happens.  And/or, break on objc_exception_throw to catch this in the debugger.
>
> </error>
>
> This is on OS X 10.10 with Java 8u25. Perhaps it was happening before and I didn?t notice. Everything still works once the dialog is open, but that is quite slow.
>
> Is there anything I can do to remove the error?
>
> Thanks in advance
>
> William


-- 
Best regards, Sergey.


From sergey.bylokhov at oracle.com  Tue Feb 10 00:56:41 2015
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 9 Feb 2015 16:56:41 -0800 (PST)
Subject: java2d performance java7 / java8
Message-ID: <21fae38e-ab0d-405f-9d3e-51e9a85c6355@default>

Hello,
> On 2/9/15 10:32 AM, Sergey Bylokhov wrote:
> OK, but CreateCompatibleImage() always gives me TYPE_INT_RGB, which is> 
> not optimal when using OpenGL blitting.  That's why I have to go to
> the 
> trouble of detecting Java 1.7-1.8 on Mac and forcing the use of a 
> TYPE_INT_ARGB_PRE image in that case.

Probably you do not provide the third argument of this method?

> (1) Why didn't the Quartz blitter from Apple's Java 1.6 ever make it 
> into Oracle Java?  Was there a licensing issue with that code?

I do not remember a details but it was a discussion about it, and as a result Quartz pipeline was not ported to the openjdk.

> 
> (2) What benchmarks are you using to measure Java 2D performance? 
> That 
> is, what is the data that is driving the design decision to use only 
> OpenGL blitting on Mac?  On other platforms, there are multiple
> blitter options.

There are a few benchmars:
Most useful is J2DBench, which located in the openjdk repo:
http://hg.openjdk.java.net/jdk9/client/jdk/file/cf29d39bf0de/src/demo/share/java2d/J2DBench
Report example:
http://cr.openjdk.java.net/~serb/8029253/perf.04/osx-retina-intel/results.txt

> 
> (3) Is Java 9 supposed to make this faster in any way?  Your other 
> message 
> (http://mail.openjdk.java.net/pipermail/2d-dev/2014-October/004870.html)
> 
> indicated that there was some change introduced in the Java 9 
> pre-releases that might affect this, but after testing the pre-release
> 
> builds, I can't make them perform any differently than Java 7 or 8.

Same fixes were pushed to 8u40. All of them related to the BufferedImage2surface scaleblit.
Example report http://cr.openjdk.java.net/~serb/8059942/ogl_nvidia_win_fix14/results_ogl.txt

> 
> As far as rewriting the Java 2D blitter, that is more monumental of a
> 
> task than I have time for.  I'm mainly trying to figure out:
> 
> -- why the Quartz blitter went away
> -- whether there's any chance of bringing it back

I suppose this is impossible in this moment.

> -- whether I'm doing the right thing to achieve peak performance under the OpenGL blitter
> 
> The OpenGL blitter is slower in two key ways:
> (a) even when using ARGB_PRE images, the raw pixel throughput is still
> 
> slower by about 1/3 relative to the Quartz blitter, and
> (b) the OpenGL blitter seems to want to redraw the entire image when I
> 
> repaint, even if only a small portion has changed.  The Quartz
> blitter, on the other hand, seems smart enough to only update the changed 
> portion, which is much faster when dealing with a lot of small updates to the back buffer.

All this should be measured first, because most of the time ogl texture2texture blit is quite fast. And problems became obvious when some BufferedImages is not cached in the texture or incorrect/not best image formats are used. 

> All of this Java 2D stuff is kind of a black box, and the only way I
> was 
> able to figure out what Java 2D was doing behind the scenes was to
> build 
> the OpenJDK source and insert print statements into it.  But it still
> 
> seems that the back-end behavior can be somewhat different depending
> on which Java 2D blitter is used.

There are some options which can help:
# export J2D_TRACE_LEVEL=4
# java -Dsun.java2d.opengl=True -Dsun.java2d.trace=log YourApp

http://docs.oracle.com/javase/7/docs/technotes/guides/2d/flags.html
http://www.oracle.com/technetwork/java/javase/java2d-142140.html

Using these options you can check what blits are used in your program, and then you can measure their performance using J2DBench using different pipelines/platforms/options.

From Sergey.Bylokhov at oracle.com  Tue Feb 10 13:52:15 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 10 Feb 2015 16:52:15 +0300
Subject: java2d performance java7 / java8
In-Reply-To: <54D96C5E.1010007@users.sourceforge.net>
References: <21fae38e-ab0d-405f-9d3e-51e9a85c6355@default>
	<54D96C5E.1010007@users.sourceforge.net>
Message-ID: <54DA0D0F.7020008@oracle.com>

On 10.02.2015 5:26, DRC wrote:
> You're missing my point.  ARGB_PRE images are faster with OpenGL but 
> not as fast with other blitters, so currently in order to achieve 
> optimal performance, my program has to somehow predict when OpenGL 
> blitting will be used and use an ARGB_PRE image only in those cases.
Do you mean that in some other pipelines like d3d,gdi,xrender an image 
returned from CreateCompatibleImage is working not as fast as some 
another image? it can be a bug. I suppose 
createCompatibleImag(x,y,Transparency.TRANSLUCENT) should be faster in 
any case on all pipelines, since it takes care of best image format.(and 
it should return argb_pre in case of ogl)
>
>>> (3) Is Java 9 supposed to make this faster in any way?  Your other
>>> message
>>> (http://mail.openjdk.java.net/pipermail/2d-dev/2014-October/004870.html) 
>>>
>>>
>>> indicated that there was some change introduced in the Java 9
>>> pre-releases that might affect this, but after testing the pre-release
>>>
>>> builds, I can't make them perform any differently than Java 7 or 8.
>>
>> Same fixes were pushed to 8u40. All of them related to the 
>> BufferedImage2surface scaleblit.
>> Example report 
>> http://cr.openjdk.java.net/~serb/8059942/ogl_nvidia_win_fix14/results_ogl.txt
>
> So when would that code path be activated?
You can run this test on jdk 8u31 and 8u40 to see a difference:
http://cr.openjdk.java.net/~serb/8029253/webrev.04/test/java/awt/image/DrawImage/UnmanagedDrawImagePerformance.java.html
And the test from this bug report:
https://bugs.openjdk.java.net/browse/JDK-8017247
>
> It was measured.  Please refer to my original post describing how to 
> reproduce my results:
>
> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2014-August/006700.html 
>
>
> On the benchmark that simulates my specific workload (ImageDrawTest), 
> the performance is always considerably slower under Java 1.7 and later 
> on Mac when compared to Java 1.6.
Can you share standalone jar file of this workload?

> Using pre-computed ARGB images helps, but in no case can I make the 
> OpenGL blitter achieve the same performance as the Quartz blitter used 
> to.  In other words, from my point of view, the performance of Java 
> 1.7 and later have regressed.  I am not the only one reporting this 
> issue.
In general it will be good to reduce the number of OGLSwToSurfaceBlit blits.



-- 
Best regards, Sergey.


From dcommander at users.sourceforge.net  Thu Feb 12 05:28:38 2015
From: dcommander at users.sourceforge.net (DRC)
Date: Wed, 11 Feb 2015 23:28:38 -0600
Subject: java2d performance java7 / java8
In-Reply-To: <54DA0D0F.7020008@oracle.com>
References: <21fae38e-ab0d-405f-9d3e-51e9a85c6355@default>
	<54D96C5E.1010007@users.sourceforge.net>
	<54DA0D0F.7020008@oracle.com>
Message-ID: <54DC3A06.9060704@users.sourceforge.net>

On 2/10/15 7:52 AM, Sergey Bylokhov wrote:
> You can run this test on jdk 8u31 and 8u40 to see a difference:
> http://cr.openjdk.java.net/~serb/8029253/webrev.04/test/java/awt/image/DrawImage/UnmanagedDrawImagePerformance.java.html
>
> And the test from this bug report:
> https://bugs.openjdk.java.net/browse/JDK-8017247

After looking at those tests, they are definitely not related to the 
issue I'm seeing here.  Although the TurboVNC Viewer (my application) 
does use bilinear interpolation if desktop scaling is enabled, that is 
not the "common" usage case.  Normally, it's just going to be drawing a 
BufferedImage with no interpolation, so that at least clarifies that I 
shouldn't be expecting any different behavior with Java 9.  The question 
now becomes:  how to optimally take advantage of the OpenGL pipeline. 
As you pointed out (and I agree, based on my research) reducing the 
software-to-surface blits is key, although I don't have a firm grasp on 
how to do that.  My code is basically just doing the following:

   public void paintComponent(Graphics g) {
     Graphics2D g2 = (Graphics2D) g;
     if (scaling enabled) {
       g2.setRenderingHint(RenderingHints.KEY_INTERPOLATION,
                           RenderingHints.VALUE_INTERPOLATION_BILINEAR);
       g2.drawImage(im.getImage(), 0, 0, scaledWidth, scaledHeight, null);
     } else {
       g2.drawImage(im.getImage(), 0, 0, null);
     }
     g2.dispose();
   }

   public void updateWindow() {
     Rect r = damage;
     if (!r.isEmpty()) {
       if (scaling enabled) {
         blah blah blah (adjust coordinates, mainly)
         paintImmediately(x, y, width, height);
       } else {
         paintImmediately(x, y, width, height);
       }
       damage.clear();
     }
   }

As VNC rectangles from the server are decoded, the "damage" rectangle 
gets updated to reflect the extent of the "damaged" pixels, and that 
extent is passed into paintImmediately().  In examining the OpenJDK 
source, however, it appears that glDrawPixels() is always called with 
the full extent of the BufferedImage, regardless of whether only a small 
portion of that image has actually changed.  If there is something else 
I can do to help debug this, please let me know.  I have a working JDK 
build.  I fully admit that I may be doing something wrong or 
suboptimally, but bear in mind that I've spent probably over 100 hours 
on this, so it's not as if I'm a naive n00b here.  If there's something 
I'm missing, then trust me that it isn't obvious!


> Can you share standalone jar file of this workload?

Here is everything you need to reproduce the issue:
http://www.turbovnc.org/turbovnc_mac_performance_stuff.tar.gz

Untar, then do
> cd turbovnc_mac_performance_stuff
> java -server -d64 -Dsun.java2d.trace=count -cp VncViewer.jar com.turbovnc.vncviewer.ImageDrawTest
   (let it run for 20 seconds or so, then CTRL-C it.)
> java -server -d64 -jar VncViewer.jar -bench compilation-16.rfb -benchiter 3 -benchwarmup 2
   (let it run to completion.)

   Results from Java 6u51 on my Mac Mini (2009 vintage, 2 GHz Intel Core 
Duo, nVidia GeForce 9400):
   ImageDrawTest:   ~100 Mpixels/sec
     (all calls are to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, 
IntArgbPre))
   compilation-16:  Average 1.392763 s (Decode = 0.198173 s, Blit = 
1.005974 s)

   Results from Java 8u31 on my Mac Mini:
   ImageDrawTest:   ~70 Mpixels/sec
     (Calls are split between
      sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL Surface 
(render-to-texture)", AnyAlpha, "OpenGL Surface") and
      sun.java2d.opengl.OGLSwToSurfaceBlit::Blit(IntArgbPre, AnyAlpha, 
"OpenGL Surface"))
   compilation-16:  Average 6.216550 s (Decode = 0.194989 s, Blit = 
5.534781 s)

   Results from Java 8u31 on my Mac Mini without alpha-enabled image 
(-Dturbovnc.forcealpha=false):
   ImageDrawTest:   ~18 Mpixels/sec
     (Calls are split between:
      sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL Surface 
(render-to-texture)", AnyAlpha, "OpenGL Surface") and
      sun.java2d.opengl.OGLSwToSurfaceBlit::Blit(IntRgb, AnyAlpha, 
"OpenGL Surface"))
   compilation-16:  Average 27.153480 s (Decode = 0.200333 s, Blit = 
26.523137 s)

So, as you can see, using an alpha-enabled image improved the 
performance under Java 7/8 by about 4x, both when drawing large images 
(ImageDrawTest) and when doing smaller image updates (compilation-16.) 
However, the blitting performance under Java 7/8 for small image 
workloads is still about 5x slower than it was under Java 6.  Results 
from a different machine:

   Results from Java 6u51 on my Macbook Pro (2011 vintage, 2.4 GHz Intel 
Core i5, Intel HD Graphics 3000):
   ImageDrawTest:   ~100 Mpixels/sec
     (all calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgbPre))
   compilation-16:  Average 0.592772 s (Decode = 0.113879 s, Blit = 
0.351596 s)

   Results from Java 8u31 on my Macbook Pro:
   ImageDrawTest:   ~66 Mpixels/sec
     (Calls split between
      sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL Surface 
(render-to-texture)", AnyAlpha, "OpenGL Surface") and
      sun.java2d.opengl.OGLSwToSurfaceBlit::Blit(IntArgbPre, AnyAlpha, 
"OpenGL Surface"))
   compilation-16:  Average 6.806324 s (Decode = 0.188252 s, Blit = 
6.457852 s)

   Results from Java 8u31 on my Macbook Pro without alpha-enabled image 
(-Dturbovnc.forcealpha=false):
   ImageDrawTest:   ~50 Mpixels/sec
     (Calls split between
      sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL Surface 
(render-to-texture)", AnyAlpha, "OpenGL Surface") and
      sun.java2d.opengl.OGLSwToSurfaceBlit::Blit(IntRgb, AnyAlpha, 
"OpenGL Surface"))
   compilation-16:  Average 10.272508 s (Decode = 0.147805 s, Blit = 
9.955666 s)

Using an ARGB_PRE BufferedImage didn't help out nearly as much on this 
machine, and whereas the large image performance looks similar to that 
of the Mac Mini, the small image blitting performance still suffers by 
nearly a factor of 20 (although it is improved-- before the use of 
ARGB_PRE images, it was about a factor of 30 slower.)

The architecture of this solution makes the use of VolatileImages 
impractical-- basically, I have to decode the VNC rectangles in real 
time as they arrive, so if the VolatileImage were to go away, I would 
have no way of rebuilding it.

From Sergey.Bylokhov at oracle.com  Tue Feb 17 14:01:33 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 17 Feb 2015 17:01:33 +0300
Subject: java2d performance java7 / java8
In-Reply-To: <54DC3A06.9060704@users.sourceforge.net>
References: <21fae38e-ab0d-405f-9d3e-51e9a85c6355@default>
	<54D96C5E.1010007@users.sourceforge.net>
	<54DA0D0F.7020008@oracle.com>
	<54DC3A06.9060704@users.sourceforge.net>
Message-ID: <54E349BD.9080701@oracle.com>

Hello,
Thanks for the provided info! I am able to reproduce this bug even on 
windows: gdi vs ogl. I will take a look at it.

On 12.02.2015 8:28, DRC wrote:
> On 2/10/15 7:52 AM, Sergey Bylokhov wrote:
>> You can run this test on jdk 8u31 and 8u40 to see a difference:
>> http://cr.openjdk.java.net/~serb/8029253/webrev.04/test/java/awt/image/DrawImage/UnmanagedDrawImagePerformance.java.html 
>>
>>
>> And the test from this bug report:
>> https://bugs.openjdk.java.net/browse/JDK-8017247
>
> After looking at those tests, they are definitely not related to the 
> issue I'm seeing here.  Although the TurboVNC Viewer (my application) 
> does use bilinear interpolation if desktop scaling is enabled, that is 
> not the "common" usage case.  Normally, it's just going to be drawing 
> a BufferedImage with no interpolation, so that at least clarifies that 
> I shouldn't be expecting any different behavior with Java 9.  The 
> question now becomes:  how to optimally take advantage of the OpenGL 
> pipeline. As you pointed out (and I agree, based on my research) 
> reducing the software-to-surface blits is key, although I don't have a 
> firm grasp on how to do that.  My code is basically just doing the 
> following:
>
>   public void paintComponent(Graphics g) {
>     Graphics2D g2 = (Graphics2D) g;
>     if (scaling enabled) {
>       g2.setRenderingHint(RenderingHints.KEY_INTERPOLATION,
> RenderingHints.VALUE_INTERPOLATION_BILINEAR);
>       g2.drawImage(im.getImage(), 0, 0, scaledWidth, scaledHeight, null);
>     } else {
>       g2.drawImage(im.getImage(), 0, 0, null);
>     }
>     g2.dispose();
>   }
>
>   public void updateWindow() {
>     Rect r = damage;
>     if (!r.isEmpty()) {
>       if (scaling enabled) {
>         blah blah blah (adjust coordinates, mainly)
>         paintImmediately(x, y, width, height);
>       } else {
>         paintImmediately(x, y, width, height);
>       }
>       damage.clear();
>     }
>   }
>
> As VNC rectangles from the server are decoded, the "damage" rectangle 
> gets updated to reflect the extent of the "damaged" pixels, and that 
> extent is passed into paintImmediately().  In examining the OpenJDK 
> source, however, it appears that glDrawPixels() is always called with 
> the full extent of the BufferedImage, regardless of whether only a 
> small portion of that image has actually changed.  If there is 
> something else I can do to help debug this, please let me know.  I 
> have a working JDK build.  I fully admit that I may be doing something 
> wrong or suboptimally, but bear in mind that I've spent probably over 
> 100 hours on this, so it's not as if I'm a naive n00b here.  If 
> there's something I'm missing, then trust me that it isn't obvious!
>
>
>> Can you share standalone jar file of this workload?
>
> Here is everything you need to reproduce the issue:
> http://www.turbovnc.org/turbovnc_mac_performance_stuff.tar.gz
>
> Untar, then do
>> cd turbovnc_mac_performance_stuff
>> java -server -d64 -Dsun.java2d.trace=count -cp VncViewer.jar 
>> com.turbovnc.vncviewer.ImageDrawTest
>   (let it run for 20 seconds or so, then CTRL-C it.)
>> java -server -d64 -jar VncViewer.jar -bench compilation-16.rfb 
>> -benchiter 3 -benchwarmup 2
>   (let it run to completion.)
>
>   Results from Java 6u51 on my Mac Mini (2009 vintage, 2 GHz Intel 
> Core Duo, nVidia GeForce 9400):
>   ImageDrawTest:   ~100 Mpixels/sec
>     (all calls are to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, 
> IntArgbPre))
>   compilation-16:  Average 1.392763 s (Decode = 0.198173 s, Blit = 
> 1.005974 s)
>
>   Results from Java 8u31 on my Mac Mini:
>   ImageDrawTest:   ~70 Mpixels/sec
>     (Calls are split between
>      sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL 
> Surface (render-to-texture)", AnyAlpha, "OpenGL Surface") and
>      sun.java2d.opengl.OGLSwToSurfaceBlit::Blit(IntArgbPre, AnyAlpha, 
> "OpenGL Surface"))
>   compilation-16:  Average 6.216550 s (Decode = 0.194989 s, Blit = 
> 5.534781 s)
>
>   Results from Java 8u31 on my Mac Mini without alpha-enabled image 
> (-Dturbovnc.forcealpha=false):
>   ImageDrawTest:   ~18 Mpixels/sec
>     (Calls are split between:
>      sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL 
> Surface (render-to-texture)", AnyAlpha, "OpenGL Surface") and
>      sun.java2d.opengl.OGLSwToSurfaceBlit::Blit(IntRgb, AnyAlpha, 
> "OpenGL Surface"))
>   compilation-16:  Average 27.153480 s (Decode = 0.200333 s, Blit = 
> 26.523137 s)
>
> So, as you can see, using an alpha-enabled image improved the 
> performance under Java 7/8 by about 4x, both when drawing large images 
> (ImageDrawTest) and when doing smaller image updates (compilation-16.) 
> However, the blitting performance under Java 7/8 for small image 
> workloads is still about 5x slower than it was under Java 6.  Results 
> from a different machine:
>
>   Results from Java 6u51 on my Macbook Pro (2011 vintage, 2.4 GHz 
> Intel Core i5, Intel HD Graphics 3000):
>   ImageDrawTest:   ~100 Mpixels/sec
>     (all calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, 
> IntArgbPre))
>   compilation-16:  Average 0.592772 s (Decode = 0.113879 s, Blit = 
> 0.351596 s)
>
>   Results from Java 8u31 on my Macbook Pro:
>   ImageDrawTest:   ~66 Mpixels/sec
>     (Calls split between
>      sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL 
> Surface (render-to-texture)", AnyAlpha, "OpenGL Surface") and
>      sun.java2d.opengl.OGLSwToSurfaceBlit::Blit(IntArgbPre, AnyAlpha, 
> "OpenGL Surface"))
>   compilation-16:  Average 6.806324 s (Decode = 0.188252 s, Blit = 
> 6.457852 s)
>
>   Results from Java 8u31 on my Macbook Pro without alpha-enabled image 
> (-Dturbovnc.forcealpha=false):
>   ImageDrawTest:   ~50 Mpixels/sec
>     (Calls split between
>      sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL 
> Surface (render-to-texture)", AnyAlpha, "OpenGL Surface") and
>      sun.java2d.opengl.OGLSwToSurfaceBlit::Blit(IntRgb, AnyAlpha, 
> "OpenGL Surface"))
>   compilation-16:  Average 10.272508 s (Decode = 0.147805 s, Blit = 
> 9.955666 s)
>
> Using an ARGB_PRE BufferedImage didn't help out nearly as much on this 
> machine, and whereas the large image performance looks similar to that 
> of the Mac Mini, the small image blitting performance still suffers by 
> nearly a factor of 20 (although it is improved-- before the use of 
> ARGB_PRE images, it was about a factor of 30 slower.)
>
> The architecture of this solution makes the use of VolatileImages 
> impractical-- basically, I have to decode the VNC rectangles in real 
> time as they arrive, so if the VolatileImage were to go away, I would 
> have no way of rebuilding it.


-- 
Best regards, Sergey.


From hs at tagtraum.com  Tue Feb 17 14:09:21 2015
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Tue, 17 Feb 2015 15:09:21 +0100
Subject: java2d performance java7 / java8
In-Reply-To: <54E349BD.9080701@oracle.com>
References: <21fae38e-ab0d-405f-9d3e-51e9a85c6355@default>
	<54D96C5E.1010007@users.sourceforge.net>
	<54DA0D0F.7020008@oracle.com>
	<54DC3A06.9060704@users.sourceforge.net>
	<54E349BD.9080701@oracle.com>
Message-ID: <BF5C0142-56FF-4B76-A18D-1F7A3E80F0FC@tagtraum.com>


> On Feb 17, 2015, at 15:01, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello,
> Thanks for the provided info! I am able to reproduce this bug even on windows: gdi vs ogl. I will take a look at it.

This is good news.
Thanks, both of you!
I'm always appreciating a faster 2d pipeline!

-hendrik

From dcommander at users.sourceforge.net  Tue Feb 17 15:37:05 2015
From: dcommander at users.sourceforge.net (DRC)
Date: Tue, 17 Feb 2015 09:37:05 -0600
Subject: java2d performance java7 / java8
In-Reply-To: <54E349BD.9080701@oracle.com>
References: <21fae38e-ab0d-405f-9d3e-51e9a85c6355@default>
	<54D96C5E.1010007@users.sourceforge.net>
	<54DA0D0F.7020008@oracle.com>
	<54DC3A06.9060704@users.sourceforge.net>
	<54E349BD.9080701@oracle.com>
Message-ID: <54E36021.2010308@users.sourceforge.net>

I can't remember if I mentioned it, but in my testing (same tests as I 
described below), the GDI pipeline is definitely always the fastest on 
Windows.  D3D is the next fastest, and OGL is the slowest.  I tested on 
four very different machines (2011 high-end Dell workstation with nVidia 
Quadro FX 5000, 2013 high-end HP laptop with AMD Radeon APU, 2009 
low-end HP PC with nVidia onboard graphics, and Parallels Desktop 
running on my Mac Mini.)  Both D3D and OGL benefit from the use of 
ARGB_PRE images, but in neither case can they achieve the same 
performance as GDI.  This is true for Java 6 on Windows as well 
(performance is pretty much unchanged between Java 6 and 8, AFAICT.)  My 
application tries to disable D3D Java 2D blitting on Windows machines 
for that reason.

I look forward to your findings.


On 2/17/15 8:01 AM, Sergey Bylokhov wrote:
> Hello,
> Thanks for the provided info! I am able to reproduce this bug even on
> windows: gdi vs ogl. I will take a look at it.

From janssen at parc.com  Fri Feb 20 17:34:37 2015
From: janssen at parc.com (Bill Janssen)
Date: Fri, 20 Feb 2015 09:34:37 -0800
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
Message-ID: <23736.1424453677@parc.com>

David DeHaven <david.dehaven at oracle.com> wrote:

> Are you linking against JavaVM.framework? If you just need the JNI
> headers, it's better to use those provided in the JDK (the headers are
> even correct these days...). You shouldn't need to link anything to
> just open and use libjvm. This is generally true for JNI libraries too
> since native methods are dynamically looked up by symbol name. So,
> instead of "-framework JavaVM" use "-I${JDK_HOME}/include
> -I${JDK_HOME}/include/darwin" and it will find jni.h (assuming
> JDK_HOME is defined and correct).

Follow-up question here: I'm trying to use autoconf to identify the
location of the proper include directories and libraries for subsequent
use of libtool to create a .libjni JNI dynamic library.  The Mac's
/usr/libexec/java_home will identify JAVA_HOME; is there some way to
test for the location of the jni_md.h file that is platform-specific?
Is there some standard JDK tool that, when run, will produce the
appropriate include directories?

Or, is there some way to detect these configuration details by compiling
and running a Java program that autoconf could then use as an auxiliary?

Thanks.

Bill

From david.dehaven at oracle.com  Fri Feb 20 17:50:42 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 20 Feb 2015 09:50:42 -0800
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <23736.1424453677@parc.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<23736.1424453677@parc.com>
Message-ID: <4ACA9288-FAAE-4D6C-B814-B17CC5CBEE1C@oracle.com>


>> Are you linking against JavaVM.framework? If you just need the JNI
>> headers, it's better to use those provided in the JDK (the headers are
>> even correct these days...). You shouldn't need to link anything to
>> just open and use libjvm. This is generally true for JNI libraries too
>> since native methods are dynamically looked up by symbol name. So,
>> instead of "-framework JavaVM" use "-I${JDK_HOME}/include
>> -I${JDK_HOME}/include/darwin" and it will find jni.h (assuming
>> JDK_HOME is defined and correct).
> 
> Follow-up question here: I'm trying to use autoconf to identify the
> location of the proper include directories and libraries for subsequent
> use of libtool to create a .libjni JNI dynamic library.

You should be using .dylib for JNI libs these days.


>  The Mac's
> /usr/libexec/java_home will identify JAVA_HOME; is there some way to
> test for the location of the jni_md.h file that is platform-specific?
> Is there some standard JDK tool that, when run, will produce the
> appropriate include directories?

Not really. The include directory is always the same on any platform: ${JDK_HOME}/include and on OSX you also include the darwin directory for the machine dependent files. I don?t forsee this changing any time soon, so the only thing I?d do that involves autoconf is detect if you?re building on OSX and add the darwin directory.

-DrD-


From hs at tagtraum.com  Fri Feb 20 18:05:31 2015
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 20 Feb 2015 19:05:31 +0100
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <4ACA9288-FAAE-4D6C-B814-B17CC5CBEE1C@oracle.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<23736.1424453677@parc.com>
	<4ACA9288-FAAE-4D6C-B814-B17CC5CBEE1C@oracle.com>
Message-ID: <7CBB357A-4C19-466B-A9B4-E99D6C593ECC@tagtraum.com>

>> 
>> Follow-up question here: I'm trying to use autoconf to identify the
>> location of the proper include directories and libraries for subsequent
>> use of libtool to create a .libjni JNI dynamic library.
> 
> You should be using .dylib for JNI libs these days.

Please excuse my ignorance, but

Why?
And what's the difference?

Thank you,

-hendrik

From david.dehaven at oracle.com  Fri Feb 20 18:34:37 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 20 Feb 2015 10:34:37 -0800
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <7CBB357A-4C19-466B-A9B4-E99D6C593ECC@tagtraum.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<23736.1424453677@parc.com>
	<4ACA9288-FAAE-4D6C-B814-B17CC5CBEE1C@oracle.com>
	<7CBB357A-4C19-466B-A9B4-E99D6C593ECC@tagtraum.com>
Message-ID: <83ED15D0-3E4D-49FB-9EAA-4CC12C190B6F@oracle.com>


>>> Follow-up question here: I'm trying to use autoconf to identify the
>>> location of the proper include directories and libraries for subsequent
>>> use of libtool to create a .libjni JNI dynamic library.
>> 
>> You should be using .dylib for JNI libs these days.
> 
> Please excuse my ignorance, but
> 
> Why?
> And what's the difference?

.dylib is the standard extension used by the dynamic loader on OSX, .jnilib was originally used by Apples JRE specifically for JNI libraries and (I believe) we?ve never really supported it except to allow legacy applications to continue to work. We certainly no longer use it internally. For example, there was a time (before the OSX port was done) when it was used in JavaFX. When 7u6 was released and Oracle took over ownership of the OSX JRE, we switched everything over.

There is no functional difference, the files are exactly the same except there?s no guarantee that .jnilib will continue to be supported. And look at the loading mechanism in jdk; loading a JNI lib will first attempt to load using the .dylib extension then fall back on .jnilib for legacy support, so there?s a (admittedly pretty small) performance consideration since it has to do extra work to load a .jnilib library.

-DrD-


From janssen at parc.com  Fri Feb 20 18:48:34 2015
From: janssen at parc.com (Bill Janssen)
Date: Fri, 20 Feb 2015 10:48:34 -0800
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <83ED15D0-3E4D-49FB-9EAA-4CC12C190B6F@oracle.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<23736.1424453677@parc.com>
	<4ACA9288-FAAE-4D6C-B814-B17CC5CBEE1C@oracle.com>
	<7CBB357A-4C19-466B-A9B4-E99D6C593ECC@tagtraum.com>
	<83ED15D0-3E4D-49FB-9EAA-4CC12C190B6F@oracle.com>
Message-ID: <26397.1424458114@parc.com>

> >>> Follow-up question here: I'm trying to use autoconf to identify the
> >>> location of the proper include directories and libraries for subsequent
> >>> use of libtool to create a .libjni JNI dynamic library.
> >> 
> >> You should be using .dylib for JNI libs these days.

I actually haven't seen the reply that included that last line, but...

More accurately, I should be using the appropriate dynamic library
extension for my platform.  Which is one of the reasons I'm using
libtool in the first place; it knows what those are.  I just wrote
".jnilib" because I thought the question would be clearer to the
audience.

However, my question remains unanswered by this no doubt
well-intentioned advice -- how do I identity the locations of the
appropriate include files?  Any help on that?

Bill

From mik3hall at gmail.com  Fri Feb 20 23:06:35 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 20 Feb 2015 17:06:35 -0600
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <7CBB357A-4C19-466B-A9B4-E99D6C593ECC@tagtraum.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<23736.1424453677@parc.com>
	<4ACA9288-FAAE-4D6C-B814-B17CC5CBEE1C@oracle.com>
	<7CBB357A-4C19-466B-A9B4-E99D6C593ECC@tagtraum.com>
Message-ID: <4AAAE4C8-C74F-4A4C-AB4E-69B752F1B191@gmail.com>

On Feb 20, 2015, at 12:05 PM, Hendrik Schreiber <hs at tagtraum.com> wrote:

>>> 
>>> Follow-up question here: I'm trying to use autoconf to identify the
>>> location of the proper include directories and libraries for subsequent
>>> use of libtool to create a .libjni JNI dynamic library.
>> 
>> You should be using .dylib for JNI libs these days.
> 
> Please excuse my ignorance, but
> 
> Why?
> And what's the difference?

If I remember right at one point during the port, jnilib was broken at least for some functionality. I bug reported and the ?legacy? behavior was restored. 
It is a little strange. Java tends to deprecate a lot but doesn't actually break backward compatibility very often.
I?m not sure what the deprecation reasoning would be either. Maybe just to eliminate java having a unique special case file extension for something the platform already has it?s own extensions for. If the jnilib executable itself isn?t cross-platform, like a native lib compiled on OS X won?t run on Windows, then having a cross-platform file extension maybe doesn?t make sense either.

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter



From hs at tagtraum.com  Sat Feb 21 09:14:30 2015
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Sat, 21 Feb 2015 10:14:30 +0100
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <83ED15D0-3E4D-49FB-9EAA-4CC12C190B6F@oracle.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<23736.1424453677@parc.com>
	<4ACA9288-FAAE-4D6C-B814-B17CC5CBEE1C@oracle.com>
	<7CBB357A-4C19-466B-A9B4-E99D6C593ECC@tagtraum.com>
	<83ED15D0-3E4D-49FB-9EAA-4CC12C190B6F@oracle.com>
Message-ID: <456D05D9-C6FC-44B8-924D-B0E52027E33F@tagtraum.com>


> On Feb 20, 2015, at 19:34, David DeHaven <david.dehaven at oracle.com> wrote:
>> 
>> Please excuse my ignorance, but
>> 
>> Why?
>> And what's the difference?
> 
> .dylib is the standard extension used by the dynamic loader on OSX, .jnilib was originally used by Apples JRE specifically for JNI libraries and (I believe) we?ve never really supported it except to allow legacy applications to continue to work. We certainly no longer use it internally. For example, there was a time (before the OSX port was done) when it was used in JavaFX. When 7u6 was released and Oracle took over ownership of the OSX JRE, we switched everything over.
> 
> There is no functional difference, the files are exactly the same except there?s no guarantee that .jnilib will continue to be supported. And look at the loading mechanism in jdk; loading a JNI lib will first attempt to load using the .dylib extension then fall back on .jnilib for legacy support, so there?s a (admittedly pretty small) performance consideration since it has to do extra work to load a .jnilib library.

Thanks, David.

So just to recap: They both are identical in content, it's just the file extension that's different.

Cheers,

-hendrik

From mik3hall at gmail.com  Sat Feb 21 14:33:36 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 21 Feb 2015 08:33:36 -0600
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <456D05D9-C6FC-44B8-924D-B0E52027E33F@tagtraum.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<23736.1424453677@parc.com>
	<4ACA9288-FAAE-4D6C-B814-B17CC5CBEE1C@oracle.com>
	<7CBB357A-4C19-466B-A9B4-E99D6C593ECC@tagtraum.com>
	<83ED15D0-3E4D-49FB-9EAA-4CC12C190B6F@oracle.com>
	<456D05D9-C6FC-44B8-924D-B0E52027E33F@tagtraum.com>
Message-ID: <72076D62-3C12-4348-88C8-8677F3A2BC81@gmail.com>

Probably David should answer, but I think the short answer is yes.

I tried to track down discussion of the issues I had during the port. For some background discussion on a longer answer?
http://grokbase.com/t/openjdk/core-libs-dev/123vsxhkm9/rfr-7134701-macosx-support-legacy-native-library-names
http://webmail.dev411.com/t/openjdk/macosx-port-dev/1241wanbck/rfr-7134701-macosx-support-legacy-native-library-names
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003031.html

Although I didn?t find any specific reference to the bug report I had. I also didn?t think jnilib was that Apple specific. But the discussions seem to have it that way. 

I think for now dylib would probably just be much preferred?

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter





From janssen at parc.com  Sat Feb 21 18:54:22 2015
From: janssen at parc.com (Bill Janssen)
Date: Sat, 21 Feb 2015 10:54:22 -0800
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <72076D62-3C12-4348-88C8-8677F3A2BC81@gmail.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<23736.1424453677@parc.com>
	<4ACA9288-FAAE-4D6C-B814-B17CC5CBEE1C@oracle.com>
	<7CBB357A-4C19-466B-A9B4-E99D6C593ECC@tagtraum.com>
	<83ED15D0-3E4D-49FB-9EAA-4CC12C190B6F@oracle.com>
	<456D05D9-C6FC-44B8-924D-B0E52027E33F@tagtraum.com>
	<72076D62-3C12-4348-88C8-8677F3A2BC81@gmail.com>
Message-ID: <28490.1424544862@parc.com>

In case anyone's interested, the answer to my original question is

http://www.gnu.org/software/autoconf-archive/ax_jni_include_dir.html

Bill

From mik3hall at gmail.com  Sat Feb 21 18:59:21 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 21 Feb 2015 12:59:21 -0600
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <28490.1424544862@parc.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<23736.1424453677@parc.com>
	<4ACA9288-FAAE-4D6C-B814-B17CC5CBEE1C@oracle.com>
	<7CBB357A-4C19-466B-A9B4-E99D6C593ECC@tagtraum.com>
	<83ED15D0-3E4D-49FB-9EAA-4CC12C190B6F@oracle.com>
	<456D05D9-C6FC-44B8-924D-B0E52027E33F@tagtraum.com>
	<72076D62-3C12-4348-88C8-8677F3A2BC81@gmail.com>
	<28490.1424544862@parc.com>
Message-ID: <B46A6CCF-D71D-476A-B4E0-71025547AEB1@gmail.com>

On Feb 21, 2015, at 12:54 PM, Bill Janssen <janssen at parc.com> wrote:

> In case anyone's interested, the answer to my original question is
> 
> http://www.gnu.org/software/autoconf-archive/ax_jni_include_dir.html

So a parameter specific to autoconf with a default that doesn?t work for you on OS X?

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter





From david.dehaven at oracle.com  Mon Feb 23 15:45:53 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 23 Feb 2015 07:45:53 -0800
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <456D05D9-C6FC-44B8-924D-B0E52027E33F@tagtraum.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<23736.1424453677@parc.com>
	<4ACA9288-FAAE-4D6C-B814-B17CC5CBEE1C@oracle.com>
	<7CBB357A-4C19-466B-A9B4-E99D6C593ECC@tagtraum.com>
	<83ED15D0-3E4D-49FB-9EAA-4CC12C190B6F@oracle.com>
	<456D05D9-C6FC-44B8-924D-B0E52027E33F@tagtraum.com>
Message-ID: <A215642D-19CA-4744-B51C-76394F04F2E5@oracle.com>


>>> 
>>> Please excuse my ignorance, but
>>> 
>>> Why?
>>> And what's the difference?
>> 
>> .dylib is the standard extension used by the dynamic loader on OSX, .jnilib was originally used by Apples JRE specifically for JNI libraries and (I believe) we?ve never really supported it except to allow legacy applications to continue to work. We certainly no longer use it internally. For example, there was a time (before the OSX port was done) when it was used in JavaFX. When 7u6 was released and Oracle took over ownership of the OSX JRE, we switched everything over.
>> 
>> There is no functional difference, the files are exactly the same except there?s no guarantee that .jnilib will continue to be supported. And look at the loading mechanism in jdk; loading a JNI lib will first attempt to load using the .dylib extension then fall back on .jnilib for legacy support, so there?s a (admittedly pretty small) performance consideration since it has to do extra work to load a .jnilib library.
> 
> Thanks, David.
> 
> So just to recap: They both are identical in content, it's just the file extension that's different.

Yes, exactly.

-DrD-


From david.dehaven at oracle.com  Mon Feb 23 15:52:27 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 23 Feb 2015 07:52:27 -0800
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <28490.1424544862@parc.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<23736.1424453677@parc.com>
	<4ACA9288-FAAE-4D6C-B814-B17CC5CBEE1C@oracle.com>
	<7CBB357A-4C19-466B-A9B4-E99D6C593ECC@tagtraum.com>
	<83ED15D0-3E4D-49FB-9EAA-4CC12C190B6F@oracle.com>
	<456D05D9-C6FC-44B8-924D-B0E52027E33F@tagtraum.com>
	<72076D62-3C12-4348-88C8-8677F3A2BC81@gmail.com>
	<28490.1424544862@parc.com>
Message-ID: <09FF68EA-7E86-4B06-950C-E2556A4133B0@oracle.com>


> In case anyone's interested, the answer to my original question is
> 
> http://www.gnu.org/software/autoconf-archive/ax_jni_include_dir.html

Ah, nice find!

-DrD-


From david.dehaven at oracle.com  Mon Feb 23 15:56:47 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 23 Feb 2015 07:56:47 -0800
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <4AAAE4C8-C74F-4A4C-AB4E-69B752F1B191@gmail.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<23736.1424453677@parc.com>
	<4ACA9288-FAAE-4D6C-B814-B17CC5CBEE1C@oracle.com>
	<7CBB357A-4C19-466B-A9B4-E99D6C593ECC@tagtraum.com>
	<4AAAE4C8-C74F-4A4C-AB4E-69B752F1B191@gmail.com>
Message-ID: <DF4D62E8-7396-42A8-B08C-5CAB9D06A743@oracle.com>


>>>> 
>>>> Follow-up question here: I'm trying to use autoconf to identify the
>>>> location of the proper include directories and libraries for subsequent
>>>> use of libtool to create a .libjni JNI dynamic library.
>>> 
>>> You should be using .dylib for JNI libs these days.
>> 
>> Please excuse my ignorance, but
>> 
>> Why?
>> And what's the difference?
> 
> If I remember right at one point during the port, jnilib was broken at least for some functionality. I bug reported and the ?legacy? behavior was restored. 
> It is a little strange. Java tends to deprecate a lot but doesn't actually break backward compatibility very often.

That attitude is changing somewhat. A number of things that were deprecated in earlier releases have already been removed from 9. Probably the biggest I can think of is the extension/optional package mechanism. It will be interesting to see how many apps break when 9 gets more widespread adoption. Hopefully sooner rather than later?

-Dr ?knee deep in jigsaw? D-


From mik3hall at gmail.com  Mon Feb 23 21:45:00 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 23 Feb 2015 15:45:00 -0600
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <DF4D62E8-7396-42A8-B08C-5CAB9D06A743@oracle.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<23736.1424453677@parc.com>
	<4ACA9288-FAAE-4D6C-B814-B17CC5CBEE1C@oracle.com>
	<7CBB357A-4C19-466B-A9B4-E99D6C593ECC@tagtraum.com>
	<4AAAE4C8-C74F-4A4C-AB4E-69B752F1B191@gmail.com>
	<DF4D62E8-7396-42A8-B08C-5CAB9D06A743@oracle.com>
Message-ID: <3855380D-C162-44F3-B6FE-880F581D5D7D@gmail.com>

On Feb 23, 2015, at 9:56 AM, David DeHaven <david.dehaven at oracle.com> wrote:

> -Dr ?knee deep in jigsaw? D-

Going off-topic again. So how is Jigsaw going? 

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From mik3hall at gmail.com  Fri Feb 27 01:13:23 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 26 Feb 2015 19:13:23 -0600
Subject: Jigsaw
Message-ID: <D547628D-43C9-400C-85C5-1E9CC66FF8C6@gmail.com>

Still a little curious on this. There had been past speculation that one benefit of this project would be smaller OS X application bundles with embedded JRE?s.
I see that the current JDK 9 early access is now in fact a jigsaw (JSR 220?) one.
I downloaded it. I joined the jigsaw-dev mailing list where I suppose I could ask this. But I?d rather start with a noob question here I guess.
Documentation, examples, tutorials still look a little scarce. I did find?
http://openjdk.java.net/projects/jigsaw/doc/quickstart.html
But that talks about commands like jmod and jpkg. 
I don?t seem to find those anywhere?

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter





From Alan.Bateman at oracle.com  Fri Feb 27 08:22:14 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Feb 2015 08:22:14 +0000
Subject: Jigsaw
In-Reply-To: <D547628D-43C9-400C-85C5-1E9CC66FF8C6@gmail.com>
References: <D547628D-43C9-400C-85C5-1E9CC66FF8C6@gmail.com>
Message-ID: <54F02936.1030108@oracle.com>

On 27/02/2015 01:13, Michael Hall wrote:
> Still a little curious on this. There had been past speculation that one benefit of this project would be smaller OS X application bundles with embedded JRE?s.
> I see that the current JDK 9 early access is now in fact a jigsaw (JSR 220?) one.
> I downloaded it. I joined the jigsaw-dev mailing list where I suppose I could ask this.
Correct, the macosx-port-dev list is the wrong list to start.


>   But I?d rather start with a noob question here I guess.
> Documentation, examples, tutorials still look a little scarce. I did find?
> http://openjdk.java.net/projects/jigsaw/doc/quickstart.html
> But that talks about commands like jmod and jpkg.
> I don?t seem to find those anywhere?
This is a quick start documentation from the original Jigsaw prototype 
of a few years ago, I guess it's a reminder that some of these obsolete 
pages needs to be updated to make it clear that they are obsolete. So 
start again at the top-level page and follow the links from here.

-Alan

From mik3hall at gmail.com  Fri Feb 27 08:53:41 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 27 Feb 2015 02:53:41 -0600
Subject: Jigsaw
In-Reply-To: <54F02936.1030108@oracle.com>
References: <D547628D-43C9-400C-85C5-1E9CC66FF8C6@gmail.com>
	<54F02936.1030108@oracle.com>
Message-ID: <589C3773-06E0-481D-A0C7-092DCD1CC13A@gmail.com>

On Feb 27, 2015, at 2:22 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 27/02/2015 01:13, Michael Hall wrote:
>> Still a little curious on this. There had been past speculation that one benefit of this project would be smaller OS X application bundles with embedded JRE?s.
>> I see that the current JDK 9 early access is now in fact a jigsaw (JSR 220?) one.
>> I downloaded it. I joined the jigsaw-dev mailing list where I suppose I could ask this.
> Correct, the macosx-port-dev list is the wrong list to start.

OK, i?ll move over to jigsaw-dev.

> 
> 
>>  But I?d rather start with a noob question here I guess.
>> Documentation, examples, tutorials still look a little scarce. I did find?
>> http://openjdk.java.net/projects/jigsaw/doc/quickstart.html
>> But that talks about commands like jmod and jpkg.
>> I don?t seem to find those anywhere?
> This is a quick start documentation from the original Jigsaw prototype of a few years ago, I guess it's a reminder that some of these obsolete pages needs to be updated to make it clear that they are obsolete. So start again at the top-level page and follow the links from here.

If for top-level page you mean 
http://openjdk.java.net/projects/jigsaw/
I have looked at it a couple times but haven?t yet noticed any links to documentation, tutorials, examples, javadoc? I have seen mention of a new file system. Some talk of features not in place yet. But all a little vague and incomplete enough so far as to not make much sense. 
But I can bring this up on jigsaw-dev.

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter



From Alan.Bateman at oracle.com  Fri Feb 27 08:57:23 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Feb 2015 08:57:23 +0000
Subject: Jigsaw
In-Reply-To: <589C3773-06E0-481D-A0C7-092DCD1CC13A@gmail.com>
References: <D547628D-43C9-400C-85C5-1E9CC66FF8C6@gmail.com>	<54F02936.1030108@oracle.com>
	<589C3773-06E0-481D-A0C7-092DCD1CC13A@gmail.com>
Message-ID: <54F03173.1050804@oracle.com>

On 27/02/2015 08:53, Michael Hall wrote:
> :
>
> If for top-level page you mean
> http://openjdk.java.net/projects/jigsaw/
> I have looked at it a couple times but haven?t yet noticed any links to documentation, tutorials, examples, javadoc? I have seen mention of a new file system. Some talk of features not in place yet. But all a little vague and incomplete enough so far as to not make much sense.
> But I can bring this up on jigsaw-dev.
>
JSR 376 is just starting and so there isn't a JEP for the module system 
yet. It will all come in time. The changes that are in JDK 9 already are 
JEP 201 and JEP 220, plus dozens of other changes related to JDK 
modularizations.

-Alan

From mik3hall at gmail.com  Fri Feb 27 09:01:10 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 27 Feb 2015 03:01:10 -0600
Subject: Jigsaw
In-Reply-To: <54F03173.1050804@oracle.com>
References: <D547628D-43C9-400C-85C5-1E9CC66FF8C6@gmail.com>	<54F02936.1030108@oracle.com>
	<589C3773-06E0-481D-A0C7-092DCD1CC13A@gmail.com>
	<54F03173.1050804@oracle.com>
Message-ID: <0137E00C-BAF8-4992-87A7-6D2C2C5B06B5@gmail.com>

On Feb 27, 2015, at 2:57 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 27/02/2015 08:53, Michael Hall wrote:
>> :
>> 
>> If for top-level page you mean
>> http://openjdk.java.net/projects/jigsaw/
>> I have looked at it a couple times but haven?t yet noticed any links to documentation, tutorials, examples, javadoc? I have seen mention of a new file system. Some talk of features not in place yet. But all a little vague and incomplete enough so far as to not make much sense.
>> But I can bring this up on jigsaw-dev.
>> 
> JSR 376 is just starting and so there isn't a JEP for the module system yet. It will all come in time. The changes that are in JDK 9 already are JEP 201 and JEP 220, plus dozens of other changes related to JDK modularizations.

Maybe for now then I?ll monitor the jigsaw list and wait until I hear more is available. The JDK in place seems like a big step.

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter