From mik3hall at gmail.com  Wed Apr  1 22:39:49 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 1 Apr 2015 17:39:49 -0500
Subject: Deployment
In-Reply-To: <8146612B-416B-4CE5-975D-9B25D233FA17@oracle.com>
References: <03CCC699-F943-44A9-B875-614D9ABD11EC@gmail.com>
	<78CD18D8-59E3-4BBB-99E5-5273DEA55D87@oracle.com>
	<43DAB354-6BFE-4C1B-A8BA-0F4E159C518F@gmail.com>
	<7CD5D77D-E7A5-4E7D-B2C4-5B59039E3565@oracle.com>
	<C8333695-27FA-47A6-ACC1-C16E3D5E71A8@gmail.com>
	<8146612B-416B-4CE5-975D-9B25D233FA17@oracle.com>
Message-ID: <9CF74EB7-9563-4EBD-9859-463B613E887B@gmail.com>

On Mar 31, 2015, at 4:52 PM, David DeHaven <david.dehaven at oracle.com> wrote:
>> 
>> Do you know should JavaAppLauncher work with the Java 9 builds?
> 
> Yes, it should since it uses JLI (libjli.dylib) to start the vm. At least, I'm not aware of any problems with it. The same code should work with any reasonable version of JLI (JDK 7+).
> 
> -DrD-
> 

OK, basically I figured if I could any kind of application bundle built I could modify it from there.
So, I created the javapackager type jar from my application launching jar.

javapackager -createjar -appclass us.hall.hp.common.LoaderLaunchStub -srcdir . -srcfiles launcher.jar -noembedlauncher -outdir . -outfile launcher9.jar -v
-noembedlauncher is deprecated
Updating jar file: /Users/mjh/HalfPipe/launcher.jar

Then made my bundle?

javapackager -deploy -srcdir . -srcfiles halfpipepkg.jar -outdir . -outfile HalfPipePkg -appclass us.hall.hp.common.LoaderLaunchStub -native -name HalfPipe
No base JDK. Package will use system JRE.
Creating app bundle: /Users/mjh/HalfPipe/./bundles/HalfPipe.app
Building DMG package for HalfPipe
Result DMG installer for HalfPipe: /Users/mjh/HalfPipe/./bundles/HalfPipe-1.0.dmg
Building PKG package for HalfPipe
Bundler Mac App Store Ready Bundler skipped because of a configuration problem: No Mac App Store App Signing Key  
Advice to fix: Install your app signing keys into your Mac Keychain using Xcode.

So I had a bundle, it overachieved a little bit and also signed it and created a .dmg, etc.
I cut and pasted in everything from my full application that this skeleton build had left out. 
I checked plugins and saw that it had used the last JDK 8 I that I have installed. There might be a more current JRE 8 I haven?t got the matching JDK for yet. Anyhow, I replaced that with my JDK 9 and updated the Info.plist to reflect that.

Launching the application gets?

4/1/15 5:21:41.617 PM HalfPipe[3114]: Could not get function pointer for JLI_Launch.: (
	0   CoreFoundation                      0x00007fff8c5fe25c __exceptionPreprocess + 172
	1   libobjc.A.dylib                     0x00007fff8db96e75 objc_exception_throw + 43
	2   CoreFoundation                      0x00007fff8c5fe10c +[NSException raise:format:] + 204
	3   HalfPipe                            0x000000010b3b4de1 launch + 593
	4   HalfPipe                            0x000000010b3b4366 main + 70
	5   HalfPipe                            0x000000010b3b4314 start + 52
	6   ???                                 0x0000000000000001 0x0 + 1
)


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  Wed Apr  1 23:49:52 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 1 Apr 2015 18:49:52 -0500
Subject: Deployment
In-Reply-To: <9CF74EB7-9563-4EBD-9859-463B613E887B@gmail.com>
References: <03CCC699-F943-44A9-B875-614D9ABD11EC@gmail.com>
	<78CD18D8-59E3-4BBB-99E5-5273DEA55D87@oracle.com>
	<43DAB354-6BFE-4C1B-A8BA-0F4E159C518F@gmail.com>
	<7CD5D77D-E7A5-4E7D-B2C4-5B59039E3565@oracle.com>
	<C8333695-27FA-47A6-ACC1-C16E3D5E71A8@gmail.com>
	<8146612B-416B-4CE5-975D-9B25D233FA17@oracle.com>
	<9CF74EB7-9563-4EBD-9859-463B613E887B@gmail.com>
Message-ID: <9639E901-52B2-49BC-868D-33CA36D79533@gmail.com>

On Apr 1, 2015, at 5:39 PM, Michael Hall <mik3hall at gmail.com> wrote:

> Anyhow, I replaced that with my JDK 9 and updated the Info.plist to reflect that.
> 

I reversed this to use the 1.8 JDK same error.
I replaced the MacOS executable with the one from my old application.
I then get a alert window with JRELoadError.
Same it seems as here?
http://www.projectlibre.org/discussion/jreloaderror

I removed the Plugins embedded jdk and changed the plist to reflect that.
The app seems to start loading then disappears, nothing going to Console.app.

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  Thu Apr  2 00:04:46 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 1 Apr 2015 19:04:46 -0500
Subject: Deployment
In-Reply-To: <9639E901-52B2-49BC-868D-33CA36D79533@gmail.com>
References: <03CCC699-F943-44A9-B875-614D9ABD11EC@gmail.com>
	<78CD18D8-59E3-4BBB-99E5-5273DEA55D87@oracle.com>
	<43DAB354-6BFE-4C1B-A8BA-0F4E159C518F@gmail.com>
	<7CD5D77D-E7A5-4E7D-B2C4-5B59039E3565@oracle.com>
	<C8333695-27FA-47A6-ACC1-C16E3D5E71A8@gmail.com>
	<8146612B-416B-4CE5-975D-9B25D233FA17@oracle.com>
	<9CF74EB7-9563-4EBD-9859-463B613E887B@gmail.com>
	<9639E901-52B2-49BC-868D-33CA36D79533@gmail.com>
Message-ID: <0F1223D6-C7A7-47FE-9FE0-9D09E2B9B343@gmail.com>

On Apr 1, 2015, at 6:49 PM, Michael Hall <mik3hall at gmail.com> wrote:

> The app seems to start loading then disappears, nothing going to Console.app.
> 

Sorry, should wait until I?m done here before updating. 
I corrected a error in the JVMMainJarName that I introduced when I decided a different name for the jar was more appropriate. It didn?t occur to me it was now a Info.plist entry.
Made a couple other changes to the plist to make it more consistent with the full ?old? app?s and it now launches with the default JRE.
Now to backtrack and see if these changes fix either of the embedded versions.
 
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  Thu Apr  2 00:21:26 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 1 Apr 2015 19:21:26 -0500
Subject: Deployment
In-Reply-To: <0F1223D6-C7A7-47FE-9FE0-9D09E2B9B343@gmail.com>
References: <03CCC699-F943-44A9-B875-614D9ABD11EC@gmail.com>
	<78CD18D8-59E3-4BBB-99E5-5273DEA55D87@oracle.com>
	<43DAB354-6BFE-4C1B-A8BA-0F4E159C518F@gmail.com>
	<7CD5D77D-E7A5-4E7D-B2C4-5B59039E3565@oracle.com>
	<C8333695-27FA-47A6-ACC1-C16E3D5E71A8@gmail.com>
	<8146612B-416B-4CE5-975D-9B25D233FA17@oracle.com>
	<9CF74EB7-9563-4EBD-9859-463B613E887B@gmail.com>
	<9639E901-52B2-49BC-868D-33CA36D79533@gmail.com>
	<0F1223D6-C7A7-47FE-9FE0-9D09E2B9B343@gmail.com>
Message-ID: <A8838B7B-4BD9-46D1-BBB0-AE7EAC679F5F@gmail.com>

On Apr 1, 2015, at 7:04 PM, Michael Hall <mik3hall at gmail.com> wrote:

> Sorry, should wait until I?m done here before updating. 

Started over for (default) 1.8 embedded jdk. I think I made the same changes. No go. Seems to be launching for a second. Then disappears with nothing in console. 
Think I?ll leave it at that for today. Maybe try a simpler app or some reduced test case later.

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  Thu Apr  2 16:18:30 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 2 Apr 2015 09:18:30 -0700
Subject: Deployment
In-Reply-To: <A8838B7B-4BD9-46D1-BBB0-AE7EAC679F5F@gmail.com>
References: <03CCC699-F943-44A9-B875-614D9ABD11EC@gmail.com>
	<78CD18D8-59E3-4BBB-99E5-5273DEA55D87@oracle.com>
	<43DAB354-6BFE-4C1B-A8BA-0F4E159C518F@gmail.com>
	<7CD5D77D-E7A5-4E7D-B2C4-5B59039E3565@oracle.com>
	<C8333695-27FA-47A6-ACC1-C16E3D5E71A8@gmail.com>
	<8146612B-416B-4CE5-975D-9B25D233FA17@oracle.com>
	<9CF74EB7-9563-4EBD-9859-463B613E887B@gmail.com>
	<9639E901-52B2-49BC-868D-33CA36D79533@gmail.com>
	<0F1223D6-C7A7-47FE-9FE0-9D09E2B9B343@gmail.com>
	<A8838B7B-4BD9-46D1-BBB0-AE7EAC679F5F@gmail.com>
Message-ID: <299D6F8F-BBF7-4191-850F-6B5480EE9027@oracle.com>


>> Sorry, should wait until I?m done here before updating. 
> 
> Started over for (default) 1.8 embedded jdk. I think I made the same changes. No go. Seems to be launching for a second. Then disappears with nothing in console. 
> Think I?ll leave it at that for today. Maybe try a simpler app or some reduced test case later.

I suggest moving this over to openjfx-dev where Danno and Chris are more active, they're both actively maintaining the packager. They could have some pointers on something you might be missing.

-DrD-


From mik3hall at gmail.com  Thu Apr  2 19:32:58 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 2 Apr 2015 14:32:58 -0500
Subject: Deployment
In-Reply-To: <299D6F8F-BBF7-4191-850F-6B5480EE9027@oracle.com>
References: <03CCC699-F943-44A9-B875-614D9ABD11EC@gmail.com>
	<78CD18D8-59E3-4BBB-99E5-5273DEA55D87@oracle.com>
	<43DAB354-6BFE-4C1B-A8BA-0F4E159C518F@gmail.com>
	<7CD5D77D-E7A5-4E7D-B2C4-5B59039E3565@oracle.com>
	<C8333695-27FA-47A6-ACC1-C16E3D5E71A8@gmail.com>
	<8146612B-416B-4CE5-975D-9B25D233FA17@oracle.com>
	<9CF74EB7-9563-4EBD-9859-463B613E887B@gmail.com>
	<9639E901-52B2-49BC-868D-33CA36D79533@gmail.com>
	<0F1223D6-C7A7-47FE-9FE0-9D09E2B9B343@gmail.com>
	<A8838B7B-4BD9-46D1-BBB0-AE7EAC679F5F@gmail.com>
	<299D6F8F-BBF7-4191-850F-6B5480EE9027@oracle.com>
Message-ID: <8CD8B222-781B-470D-BE6E-B9EFC4FFC302@gmail.com>

On Apr 2, 2015, at 11:18 AM, David DeHaven <david.dehaven at oracle.com> wrote:

> 
>>> Sorry, should wait until I?m done here before updating. 
>> 
>> Started over for (default) 1.8 embedded jdk. I think I made the same changes. No go. Seems to be launching for a second. Then disappears with nothing in console. 
>> Think I?ll leave it at that for today. Maybe try a simpler app or some reduced test case later.
> 
> I suggest moving this over to openjfx-dev where Danno and Chris are more active, they're both actively maintaining the packager. They could have some pointers on something you might be missing.

OK, I thought I might hear from someone still on this list with some experience using it on OS X. I will get on the other list and if there do seem to be some issues with the codes use, Java 9 or otherwise. I will bring them up there. I didn't want to make too much of a thing concerning OS X deployment on what is mainly a JavaFX list.

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 Apr 11 20:46:02 2015
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Sat, 11 Apr 2015 22:46:02 +0200
Subject: codesign crashes since XCode 6.3/OS X 10.10.3
Message-ID: <D9B50B36-E3BA-4BAC-994C-50F35C72F58B@tagtraum.com>

Hey there,

since upgrading to XCode 6.3 codesign crashes when signing the bundled JRE (without the JRE, signing works just fine) in my app bundle.

This is what happens:

>> codesign --deep -vvv -f --sign "Developer ID Application: MyID" MyApp.app

2015-04-10 13:48:12.595 codesign[3040:506416] Internal error unloading bundle CFBundle 0x7f990162f3e0 <(null)> (framework, not loaded)
Segmentation fault: 11


The same line worked just fine before the upgrade to XCode 6.3/ OS X 10.10.3.
Does anybody else have this problem (and perhaps a solution)?

Cheers,

-hendrik

PS: I posted more of the crash log on https://devforums.apple.com/message/1124508

From mik3hall at gmail.com  Sat Apr 11 21:05:47 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 11 Apr 2015 16:05:47 -0500
Subject: Fwd: javapackager
References: <9B2211E6-16B4-4273-B042-9653725DC085@gmail.com>
Message-ID: <24638CC3-9DD7-4718-A6FC-1C69C98905C9@gmail.com>

Forward a copy of this to the port list as well if of any interest. 
My understanding is that the support list for javapackager though is openjfx-dev. My further understanding is that javapackager represents the on-going support of appbundler. It does code signing, builds application dmg?s, package installers, etc. 
I am trying to embed a Java 9 JDK into my application based off of javapackager builds.
It appears you have to manually replace the default embedded JDK (8 for me) with the Java 9 one. How this is added seems a little different from how I remember appbundler applications but I didn?t do a lot with embedded previously. For the Java 9 early access having an embedded test version for the application seemed like a good idea.
I got a small test app to work but the full application is currently as shown below.
 
Michael Hall




Begin forwarded message:

> From: Michael Hall <mik3hall at gmail.com>
> Subject: Re: javapackager
> Date: April 11, 2015 at 3:48:21 PM CDT
> To: Danno Ferrin <danno.ferrin at oracle.com>
> 
> On Apr 9, 2015, at 6:53 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> On Apr 9, 2015, at 6:19 PM, Michael Hall <mik3hall at gmail.com> wrote:
>> 
>>> I was just going to add java version to the JFrame title to make sure this is working right but it seems to be.
>> 
>> Still 1.8 for some reason. But differences in the jdk layout are as you suggested probably the reason.
>> 
> 
> Not sure if you still want to leave this off-list.
> I got my small test application working with Java 9.
> I am still having problems with the full application I?m trying to test.
> The error seems to be?
> 
> ./HalfPipe9.app/Contents/MacOS/HalfPipe9
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at us.hall.osx.OSXApplication.<init>(OSXApplication.java:31)
> 	at us.hall.osx.OSXApplication.getApplication(OSXApplication.java:118)
> 	at us.hall.hp.common.LoaderLaunchStub.<clinit>(LoaderLaunchStub.java:35)
> Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "canProcessApplicationEvents")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:468)
> 	at java.security.AccessController.checkPermission(AccessController.java:894)
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:541)
> 	at com.apple.eawt.Application.checkSecurity(Application.java:73)
> 	at com.apple.eawt.Application.<clinit>(Application.java:61)
> 	... 3 more
> 2015-04-11 14:44:50.148 HalfPipe9[3528:1403] .:Failed to launch JVM
> 
> The .:Failed to launch JVM is all that shows up in console so I tried launching the app itself command line.
> 
> The normal works when launched this way.
> The Info.plist includes?
> 
> -Djava.security.manager
> -Djava.security.policy=$APP_ROOT/Contents/JavaApp/all.policy
> 
> I?m not sure if your version of the launcher supports the same env variable type settings like $APP_ROOT?
> I notice the JVMRuntime property is set to?
> $APPDIR/plugins/Java
> I?m not familiar with $APPDIR, would that be <the.app>/Contents? plugins should be Plugins shouldn?t it, a little surprised thats not case sensitive.
> 
> Michael Hall
> 
> 
> 
> 
> 


From hs at tagtraum.com  Sun Apr 12 15:21:10 2015
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Sun, 12 Apr 2015 17:21:10 +0200
Subject: codesign crashes since XCode 6.3/OS X 10.10.3
In-Reply-To: <D9B50B36-E3BA-4BAC-994C-50F35C72F58B@tagtraum.com>
References: <D9B50B36-E3BA-4BAC-994C-50F35C72F58B@tagtraum.com>
Message-ID: <07AB5700-6439-408E-B2D4-4F191948EAD7@tagtraum.com>

> 
> The same line worked just fine before the upgrade to XCode 6.3/ OS X 10.10.3.
> Does anybody else have this problem (and perhaps a solution)?

Or asked the other way around:

Has anybody succeeded signing an app with a bundled JDK 1.8.0_40?
Just trying to figure out whether it?s me doing something stupid or codesign is simply broken.

Thanks,

-hendrik

From mik3hall at gmail.com  Sun Apr 12 19:05:28 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 12 Apr 2015 14:05:28 -0500
Subject: codesign crashes since XCode 6.3/OS X 10.10.3
In-Reply-To: <07AB5700-6439-408E-B2D4-4F191948EAD7@tagtraum.com>
References: <D9B50B36-E3BA-4BAC-994C-50F35C72F58B@tagtraum.com>
	<07AB5700-6439-408E-B2D4-4F191948EAD7@tagtraum.com>
Message-ID: <46ADF829-7DAC-4323-8668-D5F29EA941C5@gmail.com>

On Apr 12, 2015, at 10:21 AM, Hendrik Schreiber <hs at tagtraum.com> wrote:

>> 
>> The same line worked just fine before the upgrade to XCode 6.3/ OS X 10.10.3.
>> Does anybody else have this problem (and perhaps a solution)?
> 
> Or asked the other way around:
> 
> Has anybody succeeded signing an app with a bundled JDK 1.8.0_40?
> Just trying to figure out whether it?s me doing something stupid or codesign is simply broken.

Seemed to work fine for me from Terminal

My.app: replacing existing signature
My.app: signed bundle with Mach-O thin (x86_64) [some.identifier.of.mine]

Michael Hall







From hs at tagtraum.com  Sun Apr 12 19:23:02 2015
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Sun, 12 Apr 2015 21:23:02 +0200
Subject: codesign crashes since XCode 6.3/OS X 10.10.3
In-Reply-To: <46ADF829-7DAC-4323-8668-D5F29EA941C5@gmail.com>
References: <D9B50B36-E3BA-4BAC-994C-50F35C72F58B@tagtraum.com>
	<07AB5700-6439-408E-B2D4-4F191948EAD7@tagtraum.com>
	<46ADF829-7DAC-4323-8668-D5F29EA941C5@gmail.com>
Message-ID: <00AA97AA-4F77-4532-9BDB-802E6C8C221F@tagtraum.com>


> On Apr 12, 2015, at 21:05, Michael Hall <mik3hall at gmail.com> wrote:
> 
> On Apr 12, 2015, at 10:21 AM, Hendrik Schreiber <hs at tagtraum.com> wrote:
> 
>>> 
>>> The same line worked just fine before the upgrade to XCode 6.3/ OS X 10.10.3.
>>> Does anybody else have this problem (and perhaps a solution)?
>> 
>> Or asked the other way around:
>> 
>> Has anybody succeeded signing an app with a bundled JDK 1.8.0_40?
>> Just trying to figure out whether it?s me doing something stupid or codesign is simply broken.
> 
> Seemed to work fine for me from Terminal
> 
> My.app: replacing existing signature
> My.app: signed bundle with Mach-O thin (x86_64) [some.identifier.of.mine]

Thanks, Michael.
Are you copying the whole JDK or just parts?

-hendrik

From mik3hall at gmail.com  Sun Apr 12 19:30:00 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 12 Apr 2015 14:30:00 -0500
Subject: codesign crashes since XCode 6.3/OS X 10.10.3
In-Reply-To: <00AA97AA-4F77-4532-9BDB-802E6C8C221F@tagtraum.com>
References: <D9B50B36-E3BA-4BAC-994C-50F35C72F58B@tagtraum.com>
	<07AB5700-6439-408E-B2D4-4F191948EAD7@tagtraum.com>
	<46ADF829-7DAC-4323-8668-D5F29EA941C5@gmail.com>
	<00AA97AA-4F77-4532-9BDB-802E6C8C221F@tagtraum.com>
Message-ID: <7EEF49B0-9F19-4CC4-8D72-24F74FA9F139@gmail.com>

On Apr 12, 2015, at 2:23 PM, Hendrik Schreiber <hs at tagtraum.com> wrote:

>> e]
> 
> Thanks, Michael.
> Are you copying the whole JDK or just parts?
> 

Actually that was a version of my application I was trying to embed the Java 9 early access into to have a test version with that.
As far as the jdk goes I think what I did was generate a default Java 8 application with javapackager. This signed it, automatically, I didn?t have to identify the signing ID. I went into the application Plugins directory until I saw the Home directory. I removed that one and copied in the one from the Java 9 JDK. 
Probably should of broke the signature.
I then signed that bundle as indicated in your email. Didn?t remember the codesign options myself.
I probably should of done that before uploading the application. But anyone interested in the uploaded is probably interested in hacking on it anyhow so a valid signature wouldn?t matter.

Michael Hall






From nick at transparentech.com  Sun Apr 12 20:23:58 2015
From: nick at transparentech.com (Nicholas Rahn)
Date: Sun, 12 Apr 2015 22:23:58 +0200
Subject: codesign crashes since XCode 6.3/OS X 10.10.3
In-Reply-To: <07AB5700-6439-408E-B2D4-4F191948EAD7@tagtraum.com>
References: <D9B50B36-E3BA-4BAC-994C-50F35C72F58B@tagtraum.com>
	<07AB5700-6439-408E-B2D4-4F191948EAD7@tagtraum.com>
Message-ID: <CAP3J-cPM+ebBw-ka4ZQTaN25CDZw+dBrSk4+OQXgE=jyaVe-Pw@mail.gmail.com>

I am able to sign an app bundled with JDK 1.7.0_67 using OS X 10.10.3 and
xcode 6.3.  Had no problems. Everything went as it has in the past.

Nick


On Sun, Apr 12, 2015 at 5:21 PM, Hendrik Schreiber <hs at tagtraum.com> wrote:

> >
> > The same line worked just fine before the upgrade to XCode 6.3/ OS X
> 10.10.3.
> > Does anybody else have this problem (and perhaps a solution)?
>
> Or asked the other way around:
>
> Has anybody succeeded signing an app with a bundled JDK 1.8.0_40?
> Just trying to figure out whether it?s me doing something stupid or
> codesign is simply broken.
>
> Thanks,
>
> -hendrik

From hs at tagtraum.com  Thu Apr 16 08:48:54 2015
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 16 Apr 2015 10:48:54 +0200
Subject: codesign crashes since XCode 6.3/OS X 10.10.3
In-Reply-To: <CAP3J-cPM+ebBw-ka4ZQTaN25CDZw+dBrSk4+OQXgE=jyaVe-Pw@mail.gmail.com>
References: <D9B50B36-E3BA-4BAC-994C-50F35C72F58B@tagtraum.com>
	<07AB5700-6439-408E-B2D4-4F191948EAD7@tagtraum.com>
	<CAP3J-cPM+ebBw-ka4ZQTaN25CDZw+dBrSk4+OQXgE=jyaVe-Pw@mail.gmail.com>
Message-ID: <0142E435-2253-4EB2-A2DF-80FC0A9A645B@tagtraum.com>

The problem seems to be connected to Apple?s timestamp server timestamp.apple.com/17.151.28.7.
When I add the flag --timestamp=none signing works as expected.

Just FYI: In the meantime Apple has acknowledged the bug as a duplicate of 20249918.
Sounds like other people are having this problem as well and Apple is ?working on it?.

Cheers,

-hendrik


> On Apr 12, 2015, at 22:23, Nicholas Rahn <nick at transparentech.com> wrote:
> 
> I am able to sign an app bundled with JDK 1.7.0_67 using OS X 10.10.3 and xcode 6.3.  Had no problems. Everything went as it has in the past.
> 
> Nick
> 
> 
> On Sun, Apr 12, 2015 at 5:21 PM, Hendrik Schreiber <hs at tagtraum.com> wrote:
> >
> > The same line worked just fine before the upgrade to XCode 6.3/ OS X 10.10.3.
> > Does anybody else have this problem (and perhaps a solution)?
> 
> Or asked the other way around:
> 
> Has anybody succeeded signing an app with a bundled JDK 1.8.0_40?
> Just trying to figure out whether it?s me doing something stupid or codesign is simply broken.
> 
> Thanks,
> 
> -hendrik
> 


From mik3hall at gmail.com  Thu Apr 16 08:58:30 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 16 Apr 2015 03:58:30 -0500
Subject: codesign crashes since XCode 6.3/OS X 10.10.3
In-Reply-To: <0142E435-2253-4EB2-A2DF-80FC0A9A645B@tagtraum.com>
References: <D9B50B36-E3BA-4BAC-994C-50F35C72F58B@tagtraum.com>
	<07AB5700-6439-408E-B2D4-4F191948EAD7@tagtraum.com>
	<CAP3J-cPM+ebBw-ka4ZQTaN25CDZw+dBrSk4+OQXgE=jyaVe-Pw@mail.gmail.com>
	<0142E435-2253-4EB2-A2DF-80FC0A9A645B@tagtraum.com>
Message-ID: <9809C72C-A6D1-40A6-9604-FAE490D4BA5D@gmail.com>

On Apr 16, 2015, at 3:48 AM, Hendrik Schreiber <hs at tagtraum.com> wrote:

> The problem seems to be connected to Apple?s timestamp server timestamp.apple.com/17.151.28.7.
> When I add the flag --timestamp=none signing works as expected.
> 
> Just FYI: In the meantime Apple has acknowledged the bug as a duplicate of 20249918.
> Sounds like other people are having this problem as well and Apple is ?working on it?.

http://stackoverflow.com/questions/11712322/error-the-timestamp-service-is-not-available-when-using-codesign-on-mac-os-x

Michael Hall





From mik3hall at gmail.com  Wed Apr 29 20:34:29 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 29 Apr 2015 15:34:29 -0500
Subject: jdeps command
Message-ID: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com>

It was suggested on the jigsaw-dev list that I raise this issue here.
The jeps command appears to have no /usr/bin symlink.

which jdeps
/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/jdeps

I believe this command was introduced with JDK 8.

One thing that I considered a minor issue is that this misses the JDK 9 early access I have installed.

It was indicated by Mandy Chung on the jigsaw-dev list that...
> /usr/bin/j* are linked to
> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands
> probably part of OS install and I guess it's a snapshot of JDK 7
> commands.

If this is true, ?part of OS install?, I would guess they may not of even been updated for JDK 7, and no new Java commands from Java 6 on will ever have OS X /usr/bin links going forward. 

That seems to be the concern?

Michael Hall





From david.dehaven at oracle.com  Wed Apr 29 21:41:42 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 29 Apr 2015 14:41:42 -0700
Subject: jdeps command
In-Reply-To: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com>
References: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com>
Message-ID: <8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com>


> It was suggested on the jigsaw-dev list that I raise this issue here.
> The jeps command appears to have no /usr/bin symlink.
> 
> which jdeps
> /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/jdeps
> 
> I believe this command was introduced with JDK 8.
> 
> One thing that I considered a minor issue is that this misses the JDK 9 early access I have installed.
> 
> It was indicated by Mandy Chung on the jigsaw-dev list that...
>> /usr/bin/j* are linked to
>> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands
>> probably part of OS install and I guess it's a snapshot of JDK 7
>> commands.
> 
> If this is true, ?part of OS install?, I would guess they may not of even been updated for JDK 7, and no new Java commands from Java 6 on will ever have OS X /usr/bin links going forward.

We had one added for jmc, IIRC that's the last tool we've requested. The issue with the stub Java tools in /usr/bin is they're maintained by Apple, so if we add or remove tools it gets out of sync and worse yet is entirely dependent on when or even IF Apple releases a Java update for that particular OS version, which on older systems is not guaranteed to happen.


My solution is to put this in ~/.profile and skip using the stub tools in /usr/bin:
--- cut here ---
# add to front of path
prepend_path() {
  if ! eval test -z "\"\${$1##*:$2:*}\"" -o -z "\"\${$1%%*:$2}\"" -o -z "\"\${$1##$2:*}\"" -o -z "\"\${$1##$2}\"" ; then
    eval "$1=$2:\$$1"
  fi
}

export JDK_HOME=`/usr/libexec/java_home -v 1.8`
prepend_path PATH "${JDK_HOME}/bin"
--- cut here ---

Prepending it overrides the stub tools in /usr/bin. You're free to set whatever path you want for JDK_HOME, but if you use java_home then you don't have to manually juggle links or variables to track it.


This also allows javapackager to be run without scraping up a path first :)


Using PATH tools, you can change which JDK you use on the fly:
--- cut here ---
# add to front of path
prepend_path() {
  if ! eval test -z "\"\${$1##*:$2:*}\"" -o -z "\"\${$1%%*:$2}\"" -o -z "\"\${$1##$2:*}\"" -o -z "\"\${$1##$2}\"" ; then
    eval "$1=$2:\$$1"
  fi
}

# removes a path
remove_path() {
  eval "$1=$(eval echo \$$1 | tr -s ":" "\n" | grep -vwE "($2)" | tr -s "\n" ":" | sed "s/:$//")"
}

# check if the given dir is already in the path, returns 1 or 0
check_path() {
  test `echo $PATH | grep --quiet -v "$1"`
}

# JDK path functions
switch_jdk() {
  NEW_JDK_HOME=$1
  test -d "${NEW_JDK_HOME}/bin" || {
    echo "Invalid JDK path"
    return
  }

  check_path "${NEW_JDK_HOME}/bin" && return

  test -n "${JDK_HOME}" && {
    remove_path PATH "${JDK_HOME}/bin"
  }

  eval JDK_HOME="${NEW_JDK_HOME}"
  prepend_path PATH "${JDK_HOME}/bin"
}

find_jdk() {
  # usage: find_jdk <version>
  FOO=`/usr/libexec/java_home -F -v $1 2>/dev/null`
  test -z "$FOO" && {
    echo "No JDK for version $1 found."
    return
  }
  switch_jdk "$FOO"
}

# default to the latest JDK 8
find_jdk 1.8

--- cut here ---


-DrD-


From mik3hall at gmail.com  Wed Apr 29 22:13:58 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 29 Apr 2015 17:13:58 -0500
Subject: jdeps command
In-Reply-To: <8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com>
References: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com>
	<8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com>
Message-ID: <D7D9E09C-E3C9-429B-9D17-C874E73EFA7B@gmail.com>

On Apr 29, 2015, at 4:41 PM, David DeHaven <david.dehaven at oracle.com> wrote:

> My solution is to put this in ~/.profile and skip using the stub tools in /usr/bin:

Again, I have no problem with a user having their own fix in a startup shell script. Although, this one I might have to take a closer look at to completely understand what it?s doing.
But what about a distributed shell script? You would probably assume that anyone providing one for OS X would have tested on the platform.
But what if they try to write a generic Unix type script. It seems like most of those that I see prefer specifying /usr/bin/java rather than just ?java?. 
I just wonder if there wouldn?t be some way to have a platform wide mechanism. Build something in the java installer maybe that makes sure the complete set of /usr/bin links is there? 
Or if scripts like this start getting to OS X with /usr/bin/jdeps they will break.

Michael Hall






From swingler at apple.com  Thu Apr 30 17:31:24 2015
From: swingler at apple.com (Mike Swingler)
Date: Thu, 30 Apr 2015 10:31:24 -0700
Subject: jdeps command
In-Reply-To: <8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com>
References: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com>
	<8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com>
Message-ID: <1C429076-EAD9-4E9F-9F46-0CBEC5FCAF55@apple.com>

> On Apr 29, 2015, at 2:41 PM, David DeHaven <david.dehaven at oracle.com> wrote:
> 
>> It was suggested on the jigsaw-dev list that I raise this issue here.
>> The jeps command appears to have no /usr/bin symlink.
>> 
>> which jdeps
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/jdeps
>> 
>> I believe this command was introduced with JDK 8.
>> 
>> One thing that I considered a minor issue is that this misses the JDK 9 early access I have installed.
>> 
>> It was indicated by Mandy Chung on the jigsaw-dev list that...
>>> /usr/bin/j* are linked to
>>> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands
>>> probably part of OS install and I guess it's a snapshot of JDK 7
>>> commands.
>> 
>> If this is true, ?part of OS install?, I would guess they may not of even been updated for JDK 7, and no new Java commands from Java 6 on will ever have OS X /usr/bin links going forward.
> 
> We had one added for jmc, IIRC that's the last tool we've requested. The issue with the stub Java tools in /usr/bin is they're maintained by Apple, so if we add or remove tools it gets out of sync and worse yet is entirely dependent on when or even IF Apple releases a Java update for that particular OS version, which on older systems is not guaranteed to happen.
> 
> 
> My solution is to put this in ~/.profile and skip using the stub tools in /usr/bin:
> --- cut here ---
> # add to front of path
> prepend_path() {
>  if ! eval test -z "\"\${$1##*:$2:*}\"" -o -z "\"\${$1%%*:$2}\"" -o -z "\"\${$1##$2:*}\"" -o -z "\"\${$1##$2}\"" ; then
>    eval "$1=$2:\$$1"
>  fi
> }
> 
> export JDK_HOME=`/usr/libexec/java_home -v 1.8`
> prepend_path PATH "${JDK_HOME}/bin"
> --- cut here ---
> 
> Prepending it overrides the stub tools in /usr/bin. You're free to set whatever path you want for JDK_HOME, but if you use java_home then you don't have to manually juggle links or variables to track it.
> 
> 
> This also allows javapackager to be run without scraping up a path first :)
> 
> 
> Using PATH tools, you can change which JDK you use on the fly:
> --- cut here ---
> # add to front of path
> prepend_path() {
>  if ! eval test -z "\"\${$1##*:$2:*}\"" -o -z "\"\${$1%%*:$2}\"" -o -z "\"\${$1##$2:*}\"" -o -z "\"\${$1##$2}\"" ; then
>    eval "$1=$2:\$$1"
>  fi
> }
> 
> # removes a path
> remove_path() {
>  eval "$1=$(eval echo \$$1 | tr -s ":" "\n" | grep -vwE "($2)" | tr -s "\n" ":" | sed "s/:$//")"
> }
> 
> # check if the given dir is already in the path, returns 1 or 0
> check_path() {
>  test `echo $PATH | grep --quiet -v "$1"`
> }
> 
> # JDK path functions
> switch_jdk() {
>  NEW_JDK_HOME=$1
>  test -d "${NEW_JDK_HOME}/bin" || {
>    echo "Invalid JDK path"
>    return
>  }
> 
>  check_path "${NEW_JDK_HOME}/bin" && return
> 
>  test -n "${JDK_HOME}" && {
>    remove_path PATH "${JDK_HOME}/bin"
>  }
> 
>  eval JDK_HOME="${NEW_JDK_HOME}"
>  prepend_path PATH "${JDK_HOME}/bin"
> }
> 
> find_jdk() {
>  # usage: find_jdk <version>
>  FOO=`/usr/libexec/java_home -F -v $1 2>/dev/null`
>  test -z "$FOO" && {
>    echo "No JDK for version $1 found."
>    return
>  }
>  switch_jdk "$FOO"
> }
> 
> # default to the latest JDK 8
> find_jdk 1.8
> 
> --- cut here ---
> 
> 
> -DrD-

Please file a bug at <http://bugreporter.apple.com> asking for this command to be added to /usr/bin, and send me the bug ID. We can ensure that these stubs are in the base OS without any Apple Java being installed.

Thanks,
Mike Swingler
Apple Inc.


From david.dehaven at oracle.com  Thu Apr 30 18:21:02 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 30 Apr 2015 11:21:02 -0700
Subject: jdeps command
In-Reply-To: <D7D9E09C-E3C9-429B-9D17-C874E73EFA7B@gmail.com>
References: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com>
	<8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com>
	<D7D9E09C-E3C9-429B-9D17-C874E73EFA7B@gmail.com>
Message-ID: <AA989B23-0471-46DA-A272-27A65AEFDF6A@oracle.com>


> I just wonder if there wouldn?t be some way to have a platform wide mechanism. Build something in the java installer maybe that makes sure the complete set of /usr/bin links is there? 
> Or if scripts like this start getting to OS X with /usr/bin/jdeps they will break.

The issue (for Oracle...) is installing things in /usr/bin is (putting it lightly) generally frowned upon, that's an Apple managed area (along with all the symlinks into JavaVM.framework). Users are, of course, free to modify at will but are wholly responsible for the consequences of modifying the system.

Ultimately, this is no different than Windows, Linux or Solaris. At least in some Linux distributions there are symlinks managed by the flavor provider (e.g., Ubuntu with it's "alternatives") but even those are subject to becoming stale when things change in the JDK and in my experience the whole system is extremely fragile, allowing tools to be out of sync with other tools. For example, javac, javah and javap could all end up being symlinked to different JDKs (that's a bit extreme, but I've had a similar situation happen, more than once).

IMHO, the best solution is to not have centralized stub tools or symlinks and rely on setting the path correctly (that's exactly what PATH is for). At most, provide tools for discovering the desired toolset, like /usr/libexec/java_home. Then these problems simply don't exist because you're always running the tools directly rather than via symlinks or stub binaries.


I do agree that it would be ideal if we could provide something that would basically accomplish what my script does. There's been discussion about this, but as you can see it hasn't gone anywhere.

-DrD-


From mik3hall at gmail.com  Thu Apr 30 22:02:44 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 30 Apr 2015 17:02:44 -0500
Subject: jdeps command
In-Reply-To: <1C429076-EAD9-4E9F-9F46-0CBEC5FCAF55@apple.com>
References: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com>
	<8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com>
	<1C429076-EAD9-4E9F-9F46-0CBEC5FCAF55@apple.com>
Message-ID: <4003789C-4821-439B-9E57-88837D6B55B2@gmail.com>

> Please file a bug at <http://bugreporter.apple.com> asking for this command to be added to /usr/bin, and send me the bug ID. We can ensure that these stubs are in the base OS without any Apple Java being installed.
> 
> Thanks,
> Mike Swingler
> Apple Inc.
> 

Thanks much Mike. I haven?t done one for a while but it seems to have gotten out there. 
I still look to have one bug open actually. I was a little surprised to see Java still has a bugreporter slot for Java.

20770788
Bug report was submitted successfully.

Michael Hall






From mik3hall at gmail.com  Thu Apr 30 22:17:22 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 30 Apr 2015 17:17:22 -0500
Subject: jdeps command
In-Reply-To: <AA989B23-0471-46DA-A272-27A65AEFDF6A@oracle.com>
References: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com>
	<8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com>
	<D7D9E09C-E3C9-429B-9D17-C874E73EFA7B@gmail.com>
	<AA989B23-0471-46DA-A272-27A65AEFDF6A@oracle.com>
Message-ID: <B2F5EA88-234C-4F2A-A5FD-9EB1620186C3@gmail.com>

On Apr 30, 2015, at 1:21 PM, David DeHaven <david.dehaven at oracle.com> wrote:

> 
>> I just wonder if there wouldn?t be some way to have a platform wide mechanism. Build something in the java installer maybe that makes sure the complete set of /usr/bin links is there? 
>> Or if scripts like this start getting to OS X with /usr/bin/jdeps they will break.
> 
> The issue (for Oracle...) is installing things in /usr/bin is (putting it lightly) generally frowned upon, that's an Apple managed area (along with all the symlinks into JavaVM.framework). Users are, of course, free to modify at will but are wholly responsible for the consequences of modifying the system.
> 
> Ultimately, this is no different than Windows, Linux or Solaris. At least in some Linux distributions there are symlinks managed by the flavor provider (e.g., Ubuntu with it's "alternatives") but even those are subject to becoming stale when things change in the JDK and in my experience the whole system is extremely fragile, allowing tools to be out of sync with other tools. For example, javac, javah and javap could all end up being symlinked to different JDKs (that's a bit extreme, but I've had a similar situation happen, more than once).
> 
> IMHO, the best solution is to not have centralized stub tools or symlinks and rely on setting the path correctly (that's exactly what PATH is for). At most, provide tools for discovering the desired toolset, like /usr/libexec/java_home. Then these problems simply don't exist because you're always running the tools directly rather than via symlinks or stub binaries.
> 
> 
> I do agree that it would be ideal if we could provide something that would basically accomplish what my script does. There's been discussion about this, but as you can see it hasn't gone anywhere.
> 
> -DrD-
> 

I still have to look at what yours does more closely. At least to sort of understand what it is doing if not exactly how it does it.
I?m still not sure how that addresses the shell scripts that get passed around that often seem to hardcode the /usr/bin paths. 
Googling ?/usr/bin/jdeps?
gets 5,960 hits. Not tons, but this is a pretty new command. The hits mostly seem to be Unix system set up and not application installs.
Maybe the scripts from Unix to other Unix aren?t that common. Or the authors can some day be convinced to stay away from the /usr/bin hardcoded paths.

Michael Hall






From mandy.chung at oracle.com  Thu Apr 30 22:39:12 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 30 Apr 2015 15:39:12 -0700
Subject: jdeps command
In-Reply-To: <4003789C-4821-439B-9E57-88837D6B55B2@gmail.com>
References: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com>	<8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com>	<1C429076-EAD9-4E9F-9F46-0CBEC5FCAF55@apple.com>
	<4003789C-4821-439B-9E57-88837D6B55B2@gmail.com>
Message-ID: <5542AF10.2000500@oracle.com>



On 04/30/2015 03:02 PM, Michael Hall wrote:
>> Please file a bug at <http://bugreporter.apple.com> asking for this command to be added to /usr/bin, and send me the bug ID. We can ensure that these stubs are in the base OS without any Apple Java being installed.
>>
>> Thanks,
>> Mike Swingler
>> Apple Inc.
>>
> Thanks much Mike. I haven?t done one for a while but it seems to have gotten out there.
> I still look to have one bug open actually. I was a little surprised to see Java still has a bugreporter slot for Java.
>
> 20770788
> Bug report was submitted successfully.

One thing to say about JDK  tools: New tools may be added in any JDK 
release (e.g. jjs in another tool added in JDK 8) and existing tool may 
be removed (e.g. jhat [1]).  This should be taken into account.

Mandy
[1] http://openjdk.java.net/jeps/241


From mik3hall at gmail.com  Thu Apr 30 22:46:11 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 30 Apr 2015 17:46:11 -0500
Subject: jdeps command
In-Reply-To: <5542AF10.2000500@oracle.com>
References: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com>	<8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com>	<1C429076-EAD9-4E9F-9F46-0CBEC5FCAF55@apple.com>
	<4003789C-4821-439B-9E57-88837D6B55B2@gmail.com>
	<5542AF10.2000500@oracle.com>
Message-ID: <822380B3-BF7E-4187-AF8A-575201A65467@gmail.com>

On Apr 30, 2015, at 5:39 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> One thing to say about JDK  tools: New tools may be added in any JDK release (e.g. jjs in another tool added in JDK 8) and existing tool may be removed (e.g. jhat [1]).  This should be taken into account.

I was thinking about asking if anything else should be included.
Mike, would the existing bug report be ok to handle these changes as well or should I update it? Or for now should we leave it at jdeps as far as what is done? 

Michael Hall






From mik3hall at gmail.com  Thu Apr 30 23:17:37 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 30 Apr 2015 18:17:37 -0500
Subject: jdeps command
In-Reply-To: <5542AF10.2000500@oracle.com>
References: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com>	<8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com>	<1C429076-EAD9-4E9F-9F46-0CBEC5FCAF55@apple.com>
	<4003789C-4821-439B-9E57-88837D6B55B2@gmail.com>
	<5542AF10.2000500@oracle.com>
Message-ID: <E0E9DAF6-7497-4A2F-B2BE-85A73B114392@gmail.com>

On Apr 30, 2015, at 5:39 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> and existing tool may be removed (e.g. jhat [1]).  

Not through Java 9 ea?

jhat -version
jhat version 2.0 (java version 1.9.0-ea)

So I would think it might be a little premature for Mike to remove the link on this one?

Michael Hall






From mandy.chung at oracle.com  Thu Apr 30 23:21:20 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 30 Apr 2015 16:21:20 -0700
Subject: jdeps command
In-Reply-To: <E0E9DAF6-7497-4A2F-B2BE-85A73B114392@gmail.com>
References: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com>	<8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com>	<1C429076-EAD9-4E9F-9F46-0CBEC5FCAF55@apple.com>
	<4003789C-4821-439B-9E57-88837D6B55B2@gmail.com>
	<5542AF10.2000500@oracle.com>
	<E0E9DAF6-7497-4A2F-B2BE-85A73B114392@gmail.com>
Message-ID: <5542B8F0.5080003@oracle.com>



On 04/30/2015 04:17 PM, Michael Hall wrote:
> On Apr 30, 2015, at 5:39 PM, Mandy Chung <mandy.chung at oracle.com 
> <mailto:mandy.chung at oracle.com>> wrote:
>
>> and existing tool may be removed (e.g. jhat [1]). 
>
> Not through Java 9 ea?
>
> jhat -version
> jhat version 2.0 (java version 1.9.0-ea)
>
> So I would think it might be a little premature for Mike to remove the 
> link on this one?
>

Right - things may change during JDK 9 development and should wait until 
GA.  My main point is that the list of JDK tools could be different for 
any release.

Mandy

From mik3hall at gmail.com  Thu Apr 30 23:36:00 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 30 Apr 2015 18:36:00 -0500
Subject: jdeps command
In-Reply-To: <5542B8F0.5080003@oracle.com>
References: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com>	<8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com>	<1C429076-EAD9-4E9F-9F46-0CBEC5FCAF55@apple.com>
	<4003789C-4821-439B-9E57-88837D6B55B2@gmail.com>
	<5542AF10.2000500@oracle.com>
	<E0E9DAF6-7497-4A2F-B2BE-85A73B114392@gmail.com>
	<5542B8F0.5080003@oracle.com>
Message-ID: <6FA024C2-D6C8-4BC1-803B-FDB8AE999EA8@gmail.com>

On Apr 30, 2015, at 6:21 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> 
> 
> On 04/30/2015 04:17 PM, Michael Hall wrote:
>> On Apr 30, 2015, at 5:39 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> 
>>> and existing tool may be removed (e.g. jhat [1]).  
>> 
>> Not through Java 9 ea?
>> 
>> jhat -version
>> jhat version 2.0 (java version 1.9.0-ea)
>> 
>> So I would think it might be a little premature for Mike to remove the link on this one?
>> 
> 
> Right - things may change during JDK 9 development and should wait until GA.  My main point is that the list of JDK tools could be different for any release.
> 
> Mandy

OK, I guess for the Apple changes it would be up to Mike Swingler how he wants to handle this. This is good to be aware of. 
My main concern was jdeps since my understanding is it will be an important tool for Java 9 and jigsaw coming up.

Thanks all.

Michael Hall