Combobox issue with Windows 10
After upgrading to windows 10, I've had many reports of users hitting this issue (https://bugs.openjdk.java.net/browse/JDK-8132897) whereby clicking any unfocused combobox in our application completely freezes it up. (Interestingly, tabbing so the combobox is selected first before clicking provides a workaround, but clearly this is not a good solution.) I haven't been able to reproduce unfortunately, but it's certainly causing problems our end and I can't imagine we're the only ones. Has anyone else noticed this and been able to reproduce it more reliably? I would look to contribute a fix, but not being able to reproduce makes it pretty much impossible. Michael
Re: Can we use JavaPackager and a get full JRE?
You can add a post-image script to your javapackager build to manually add the
java.exe into your application. If you search the output from the javapackager
for “post-image” I think it will tell you what file to create and where to put
it. Here is a post-image file that I use to move java.exe into my native app on
Windows:
MyApp-post-image.wsf:
?xml version=1.0 ?
package
job id=postImage
script language=JScript
![CDATA[
var oFSO = new ActiveXObject(Scripting.FileSystemObject);
var oFolder = oFSO.getFolder(.);
var from = C:\\Program Files\\Java\\jdk1.8.0_40\\bin\\java.exe;
var to = oFolder.path + “\\MyApp\\runtime\\bin;
if (!oFSO.FolderExists(to)) {
oFSO.CreateFolder(to);
}
to += \\;
oFSO.CopyFile(from, to);
]]
/script
/job
/package
On MacOS, I just build a native “image” as opposed to a .dmg. So it’s easy to
add the java binary in an external script (I do some codesign stuff there as
well, which has to happen after I modify the native package).
Jeff Martin
214.513.1636
On Aug 8, 2015, at 6:16 PM, Scott Palmer swpal...@gmail.com wrote:
I’m using the JavaFX gradle plugin to build a very simple application with
the new java packager and I’ve noticed a problem with the embedded JRE, at
least on OS X.
Specifically, the ‘bin’ folder is missing from the embedded JRE, presumably
because the embedded launcher replaces it.
However my application (and many others) needs to launch a new java process.
Part of the reason for doing so is so it can be launched with new JVM options
that are determined at runtime. For example modifying the java.library.dir
after finding “plugins” that have native code.
Now it fails when running from the app bundle (works fine from a command
line). The problems is that it fails to launch a new ‘java’ process because
it expects to find 'bin/java' in the JRE folder.
What is the solution?
Since I’m using Gradle, I’m thinking I could tweak things to copy the JRE bin
folder into the .app/Contents/PlugIns/Java.runtime/Contents/Home/jre/
folder, but really the javapackager should have an option to include the
“full” JRE.
Or perhaps we need a new API in Java 9 to support launching a new Java
process?
Regards,
Scott
Re: JavaFX Self-contained PKG and MacAppStore_PKG did not work
Mac installer is weird. The install location in the installer is at best a strongly worded suggestion to the pkgutil code and I don't completely understand when it follows it and when it doesn't. What I have seen in my development is that if the package has been installed and or run anywhere else on the machine then the pkgutil will install the app into that location as an update to the existing application. So in my case I had an instance of the app that I had run from my source control build directory, and pkgutil chose to update that instance of the application rather than one I had in /Applicaitons that I drug in from a DMG. It appears that this is driven by the CFBundleIdentifier, so changing the identifier may get a clean install. Running pkgutil --pkg-info PKGID may tell you where it is installed or where it thinks it is installed. On Aug 7, 2015, at 9:11 PM, Tai Hu tai...@veroanalytics.com wrote: Hi, I used JavaFX ant tasks to create all native packages on Mac OS X (JDK 8u51 on latest Mac OS X). Both .app and .dmg packages are working flawlessly. However, for PKG package, the very first installation was successful and my application show up in /Applications folder. However, if I delete my app from /Applications and use PKG package to install again, the installation process will always run successfully. However, my application did not show up inside of /Applications. I already tried to use pkgutil —forget application id and rebooted my Mac. It is still the same result. Installation of PKG package are always successful. But my application is not installed under /Applications folder. Thanks, Tai
Re: JEP 253: UI control skins and input mapping discussion
The plan is for this kind of detail to be included in the javadoc documentation. Thanks, -- Jonathan On 7/08/2015 10:36 p.m., Mike Hearn wrote: I don't know much about skins and how they work, as I haven't implemented custom controls. My only knowledge comes from rummaging around inside the code to find some hacky way to get a particular effect, often via CSS. I was hoping to read about the skins infrastructure, what it's for, how it works etc in the jfx.s.c.skins package description but no such luck. Is the plan for the JavaDocs to give a high level description of skinning, how to implement it in your own code etc, or are there plans for other articles to describe this?
Re: Can we use JavaPackager and a get full JRE?
On Aug 8, 2015, at 5:16 PM, Scott Palmer swpal...@gmail.com wrote: I’m using the JavaFX gradle plugin to build a very simple application with the new java packager and I’ve noticed a problem with the embedded JRE, at least on OS X. Specifically, the ‘bin’ folder is missing from the embedded JRE, presumably because the embedded launcher replaces it. We deliberately strip that folder from the package. The functionality provided by the launcher is not equivalent and is only sufficient to support application launch. The goal is to have a JRE embedded just for the application, and leaving the bin folder leaves entry points for non-embeded use of the JRE. However my application (and many others) needs to launch a new java process. Part of the reason for doing so is so it can be launched with new JVM options that are determined at runtime. For example modifying the java.library.dir after finding “plugins” that have native code. Now it fails when running from the app bundle (works fine from a command line). The problems is that it fails to launch a new ‘java’ process because it expects to find 'bin/java' in the JRE folder. What is the solution? It's not easy, since this is functionality that is deliberately removed in the name of security. You could copy the .../bin/java file somewhere else prior to packaging and then copy it back into place after packaging, but that would be platform specific. Since I’m using Gradle, I’m thinking I could tweak things to copy the JRE bin folder into the .app/Contents/PlugIns/Java.runtime/Contents/Home/jre/ folder, This would be very difficult to accomplish with the current gradle plugin. It's an unconventional step and hence the plugin makes unconventional stuff difficult unless hand wired soup to nuts. but really the javapackager should have an option to include the “full” JRE. I haven't seen how the bugs.openjdk.java.net http://bugs.openjdk.java.net/ transition has affectied it, but in the JIRA days I would say open a JIRA and we can add it to our feature queue. But this would have an additional step of going through a security audit (since the removal was deliberate for security) and the security engineers may not be cool with it (then again, if it is a non default option they may accept it), so it's not a slam dunk. Or perhaps we need a new API in Java 9 to support launching a new Java process? Officially it's not too late to get new features such as this into the 9.0 release, but unless it is related to the module system and making it work somehow my thoughts are that it won't get accepted into 9.0. Regards, Scott
Re: Combobox issue with Windows 10
I don't have a Windows 10 set up here yet, although if necessary I can go through the process of installing Windows 10 as another boot option on my PC. As it stands I can not reproduce this issue on my Windows 8 install. It would probably be beneficial to try to get more data from your users. Depending on how technical they are you can have them run a tool like VisualVM to see if something is locking up. Thanks, -- Jonathan On 10/08/2015 1:13 a.m., Michael Berry wrote: After upgrading to windows 10, I've had many reports of users hitting this issue (https://bugs.openjdk.java.net/browse/JDK-8132897) whereby clicking any unfocused combobox in our application completely freezes it up. (Interestingly, tabbing so the combobox is selected first before clicking provides a workaround, but clearly this is not a good solution.) I haven't been able to reproduce unfortunately, but it's certainly causing problems our end and I can't imagine we're the only ones. Has anyone else noticed this and been able to reproduce it more reliably? I would look to contribute a fix, but not being able to reproduce makes it pretty much impossible. Michael
Re: Can we use JavaPackager and a get full JRE?
UpdateFX has code that can restart a javapackager packaged process, look here: https://github.com/vinumeris/updatefx/blob/master/api/src/main/java/com/vinumeris/updatefx/UpdateFX.java#L60 It's not beautiful but it works. You could extract the code and use it in your app: UpdateFX is Apache licensed.
