Re: [9] Review request: JDK-8147781: Javapackager installer needs to cleanup temporary folders

Hi, are you sure that there is a bug? The verbose paramter is explicitly documented to leave temporary files around, as a starting point for customization. Quote from https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html Verbose mode includes the

Re: [9] Review request: JDK-8169443 Deprecate Java Packager Blob Signing

signing via the mechanism, which was never fully supported or part of any standard. To sign webstart applications (even FX apps) just use jarsigner or the associated ant signjar task. -DrD- [1] https://ant.apache.org/manual/Tasks/signjar.html On Dec 13, 2016, at 11:02 AM, Stefan Fuchs <s

Re: [9] Review request: JDK-8169443 Deprecate Java Packager Blob Signing

as blob is a self signed jars. 2. There will be a replacement for modules that will be better. Chris On Dec 12, 2016, at 11:56 PM, Stefan Fuchs <snfu...@gmx.de> wrote: Hi, so blog signing as deprecated. What are the reasons for deprecating blog signing? Are there alternatives? How do

Re: [9] Review request: JDK-8169443 Deprecate Java Packager Blob Signing

Hi, so blog signing as deprecated. What are the reasons for deprecating blog signing? Are there alternatives? How do I sign a webstart application? Stefan David, Please review these changes to deprecate the blob signing from the Java Packager. JIRA:

Re: JDK-8163078 ArrayIndexOutOfBounds is thrown in Parent.updateCachedBounds

. Note that JDK-8163078 contains a code example which reproduces the exception but adds and removes listeners on the JavaFX thread. Kind regards, Daniel -Original Message----- From: Stefan Fuchs [mailto:snfu...@gmx.de] Sent: Wednesday, November 09, 2016 7:59 PM To: Daniel Glöck

Re: JDK-8163078 ArrayIndexOutOfBounds is thrown in Parent.updateCachedBounds

Hi Daniel, are you registering or removing the listeners on a thread other than the JavaFX Application Thread? I think the Observables are not thread save. -- regards Stefan Hi guys, We're facing an exception triggered from Parent.updateCachedBounds. I've pasted the stack trace below.

Re: JavaFX 9: Expose PlatformImpl.runAndWait() as Platform.runAndWait()

Hi, in my experience blocking your working thread for the JavaFX application thread is almost always a sign of bad application design. You can easily deadlock your application. In our quite complex JavaFX Application, we could eliminate almost all of its uses. However, in one case it is

JDK-8153350 - JavaFX webstart with javaws.exe selects wrong toolkit (unnecessary relaunch)

Hi, it may be unrelated to these relaunches, but I have been wondering for awhile, what the toolkit parameter in the ant element is supposed to do. see: https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/javafx_ant_task_reference.html#CIAGCAFH At least in my tests changing the

Re: Handling Enter key presses on Buttons in JavaFX

Tomas Mikula wrote: On Tue, Jun 7, 2016 at 6:33 PM, Stefan Fuchs <snfu...@gmx.de <mailto:snfu...@gmx.de>> wrote: Hi, well, if my dialog would include a TextField, an cancel- and an ok-button, I would obviously want to have the TextField the initial focu

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

Hi Kevin, well, removing libjfxwebkit.dylib from dmg files would definitely break our application, as we heavily rely on WebView. Our application is not distributed via Mac App Store, but as a download from our website. I think removing libjfxwebkit.dylib from the dmg should be an opt-in for

Re: Fwd: HostServices on Linux Ubuntu 14.04 trusty

Hi, this works for us on all platforms, including Ubuntu 14.04 // Desktop methods must be executed on the Swing Event Thread SwingUtilities.invokeLater(() -> { Desktop.getDesktop().open(pdfFile); }); Regards, Stefan To: Rahman USTA My problem is

Re: Private APIs not usable in Java 9?

I' ll try to compile a list of the private apis we currently use in our application and why. Looking forward to using only public apis in java 9 then :-) - Stefan On Apr 8, 2015, at 1:52 PM, Robert Krüger krue...@lesspain.de wrote: our only workaround is to use private API For the benefit

Re: Private APIs not usable in Java 9?

to work. If you're using Unsafe, this is the year to explain where the API is broken and get it straight Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do so as quickly as possible to the ultimate benefit of everyone. - Don On 08/04/2015 2:56 PM, Stefan Fuchs wrote

Re: Private APIs not usable in Java 9?

Hi, then I can only hope, that this flag is available to webstart applications. Webstart applications have no control over the installed jre. In the past we encountered various bugs in the jre, which required using internal apis for workarounds. For example in some releases of Java 7 the swing

Re: Private APIs not usable in Java 9?

of everyone. - Don On 08/04/2015 2:56 PM, Stefan Fuchs wrote: Hi, then I can only hope, that this flag is available to webstart applications. Webstart applications have no control over the installed jre. In the past we encountered various bugs in the jre, which required using internal apis

Re: Heads up... changing the rt/build/*sdk/ directory

Hi, hm, is there now a way to crossbuild the apps like Ensemble8? Seems to me that the apps are now always build against the default sdk. I ask this, because for the dalvik port, we currently use a stripped down version of the sdk, which only contains the classes, we got working. - Stefan

Re: Android replaces Dalvik with ART

Hi, well if I understand it correctly, ART is just an Ahead of Time compiler like robovm. Therefore we can only hope, that they open-source it, so that we can use it on iOS :). See the German article on heise:

Re: Why is almost everything in the API final

Mario Torre wrote: In this case, since JavaFX is Free Software! you can actually suggest the fix, prototype and propose the patch yourself, limiting the round trip time substantially. This also increases the chances to get a better fix in the end, since more eyes are focusing on it. Cheers,

Re: Why is almost everything in the API final

Richard Bair wrote: Wouldn't it be better to allow developers to override methods at their own risk. There's no such thing. When some big customer overrides methods, we have no choice but to support their app for the foreseeable future. Which is why deprecated stuff never could be removed from

Re: Why is almost everything in the API final

Fabrizio Giudici wrote: On Mon, 02 Sep 2013 18:10:17 +0200, Christian Schudt christian.sch...@gmx.de wrote: I agree with that and I also recommend to have a look at Item 17: Design and document for inheritance or else prohibit it from Effective Java.