Re: How to Include a License File in Self-Contained Application Package
This is awesome news! Congrats Sent from Objectwheel Mike On Aug 6, 2015, at 1:11 PM, Tai Hu tai...@veroanalytics.com wrote: Hi all, I am preparing our product (built in JavaFX 8) for submission to Apple Mac Store. All code signing and self-contained installer generation are done. However, I couldn’t figure out how I could add our license file into pkg package, which will show the end user before installation. Based on JavaFX 8 deployment document, this could be done by using drop in resources. I could find any more details or sample online. Could anyone point me to a right direction? Thanks, Tai
Another JavaFX Application Thread
Hello all; I'm developing AsciidocFX https://github.com/asciidocfx/AsciidocFX . Everything is good with JavaFX but I have some trouble of it's threading model. My case is; AsciidocFX converts AsciiDoc documents to another formats (html, docbook, etc.) with asciidoctor.js using a WebView component . When we are using big AsciiDoc files (for example a book), generating docbook or something takes some seconds. While converting AsciiDoc documents, UI is being unresponsive until conversion completed because Asciidoctor.js must be run on JavaFX Application Thread and conversion takes long time. I think there must be a hack or something to handle that scenario. I thought to use HTML 5 Web Worker in WebView, but it will brings me more complexity in JavaScript side. I need a solution in Java FX side. Thanks. -- Rahman USTA Istanbul JUG https://github.com/rahmanusta http://www.kodcu.com/
Re: Another JavaFX Application Thread
Am Donnerstag, 6. August 2015, 12:25:19 schrieb Rahman USTA:
Hello all;
I'm developing AsciidocFX https://github.com/asciidocfx/AsciidocFX .
Everything is good with JavaFX but I have some trouble of it's threading
model.
My case is;
AsciidocFX converts AsciiDoc documents to another formats (html, docbook,
etc.) with asciidoctor.js using a WebView component . When we are using big
AsciiDoc files (for example a book), generating docbook or something takes
some seconds. While converting AsciiDoc documents, UI is being unresponsive
until conversion completed because Asciidoctor.js must be run on JavaFX
Application Thread and conversion takes long time. I think there must be a
hack or something to handle that scenario.
I thought to use HTML 5 Web Worker in WebView, but it will brings me more
complexity in JavaScript side. I need a solution in Java FX side.
Thanks.
Can you tell me the classes (method) which you call and the freeze occure?
You should stop your ExecuterService, and avoid using System.exit
Take a look at javafx.concurrent.Task;
and do not calculate the result in FX Thread
example:
https://github.com/asciidocfx/AsciidocFX/blob/master/src/main/java/com/kodcu/boot/AppStarter.java
StartupNotification.registerStartupListener(parameters - {
threadService.runActionLater(() - {
String[] files = parameters.split( );
for (String file : files) {
file = file.replace(\, );
tabService.addTab(Paths.get(file).toAbsolutePath());
}
});
});
if replace may be expensive
StartupNotification.registerStartupListener(parameters - {
String[] files = parameters.split( );
for (String file : files) {
final Path myFile =
Paths.get( file.replace(\, )).toAbsolutePath();
threadService.runActionLater(() - {
tabService.addTab(myFile); // only do this
in FX thread
});
}
});
this would be better to avoid freeze.
replace is just for illustrate the problem.
--
Jens Kapitza
p.s. sorry for my bad english
Re: Another JavaFX Application Thread
That seems like a roundabout way to do things. The web tells me: The asciidoctor.js project is a direct port of Asciidoctor from Ruby to JavaScript using the Opal Ruby-to-JavaScript cross compiler Why don't you use JRuby and run the original Asciidoctor code directly in a background thread? That way, no webview is needed and it can all be done in the background.
Re: How to Include a License File in Self-Contained Application Package
Currently the Mac App Store support for java packager does not support a click-through license. One could be added if a web-bug feature request was posted, and we could add it to the queue. We do support click-through licenses for .DMG and .PKG distributions on mac, just not MAS right now. Right now we only use synthesized distribution.xml files created by productbuild and don't create our own, this is much more resilient to the OS changing underneath us. --Danno On Aug 6, 2015, at 2:11 PM, Tai Hu tai...@veroanalytics.com wrote: Hi all, I am preparing our product (built in JavaFX 8) for submission to Apple Mac Store. All code signing and self-contained installer generation are done. However, I couldn’t figure out how I could add our license file into pkg package, which will show the end user before installation. Based on JavaFX 8 deployment document, this could be done by using drop in resources. I could find any more details or sample online. Could anyone point me to a right direction? Thanks, Tai
Re: How to Include a License File in Self-Contained Application Package
Danno, Thanks so much for the information. Could you show a sample about how to include a click-thought license in my build? Right now I have entire build process set up and could successfully build all DMG, PKG and PKG_MacAppStore and signed by our Developer certificate. What should I do to put our license file into build? Any info are really appreciate. Thanks, Tai On Aug 6, 2015, at 10:39 PM, Danno Ferrin danno.fer...@oracle.com wrote: Currently the Mac App Store support for java packager does not support a click-through license. One could be added if a web-bug feature request was posted, and we could add it to the queue. We do support click-through licenses for .DMG and .PKG distributions on mac, just not MAS right now. Right now we only use synthesized distribution.xml files created by productbuild and don't create our own, this is much more resilient to the OS changing underneath us. --Danno On Aug 6, 2015, at 2:11 PM, Tai Hu tai...@veroanalytics.com wrote: Hi all, I am preparing our product (built in JavaFX 8) for submission to Apple Mac Store. All code signing and self-contained installer generation are done. However, I couldn’t figure out how I could add our license file into pkg package, which will show the end user before installation. Based on JavaFX 8 deployment document, this could be done by using drop in resources. I could find any more details or sample online. Could anyone point me to a right direction? Thanks, Tai
JEP 253: UI control skins and input mapping discussion
Hi all, As you might be aware, JEP 253 is all about getting private JavaFX UI control and CSS APIs out into the public. You can read all about JEP 253 at [1]. This JEP is split into three sub-projects: 1) Make UI control skins into public APIs 2) Improve support for input mapping 3) Review and make public relevant CSS APIs Today I'm posting a first javadoc that contains a proposed set of API for project 1) and 2). The javadoc for project 3) will come in a week or two, once it is closer to completion. You can find the javadoc for the first two projects at [2]. In this javadoc you'll see three packages. Here's a few brief comments: 1) javafx.scene.control: This package is unchanged. It is only here for completeness (so you can compare control classes to skin classes). 2) javafx.scene.control.skin: This package is entirely new. It consists of many of the classes that previously inhabited com.sun.javafx.scene.control.skin. Look closely at the skin classes you are interested in - almost all classes do not resemble their original form. This is because up until now, skin classes have never been considered public API, and as such not much was done to ensure a sane API. With JDK 9 this changes, and so the amount of API on each class is significantly less than what existed previously. We will take the normal approach of growing the API as demand is shown - so if something is missing, please comment ASAP! 3) javafx.scene.input: This package contains just the new classes as part of this JEP. In general the classes here are the most preliminary of the bunch - they are likely to go under the most change between now and JDK 9 being released. Please review and comment. The primary implementation change is that whilst Skins are mostly unchanged, they handle behaviors differently than now. Input mappings are now created by the skin and installed on the control. It is conceivable that in a future release these behaviors will themselves become public API, but for JEP 253 that is out of scope. There are still a few things to be thought through: 1) How to document the available input mappings so they can be easily searched for at runtime (javadoc? Java API?) 2) Controls have an empty inputMap until skin is instantiated - this means manipulating the mappings can't happen as soon as the control is created. 3) No plan on how this might support Action-style API in the future. 4) There is no API to access context menus in controls such as TextField (to add / remove functionality). I look forward to any feedback you may have. Feel free to email me on- or off- list. [1] http://openjdk.java.net/jeps/253 [2] http://jonathangiles.net/javafx/jdk9/public-skins/2/ Thanks, -- Jonathan
Results of review of private JavaFX API for consideration to make public in JDK 9
Hi all. In April of this year a discussion began when news broke that with JDK 9 access to private com.sun.* APIs would be disappearing [1]. A while back I posted a request to openjfx-dev for people to send me their JDeps output so that it could be analysed and used to inform our decisions around which API we should try to promote into public API. The response was very useful (and I should note: its too late now, please don't send me anymore JDeps files), and I believe we have the beginnings of a plan on how to move forward. Before I outline the plan, please note that this discussion would ideally _not_ devolve into a feature requests discussion. What we are wanting to talk about today is simply API that exists in the com.sun.* package namespace which we can conceivably bring out of this namespace for JDK 9. Developing new API is expressly out of scope (unless it is related to simplifying or wrapping the com.sun.* API). Another important point - UI control skins and a lot of very useful CSS API are being made public under JEP 253 [2]. A lot of the skin code has already been cleaned up, simplified, documented, etc, and will be merging into a repo very soon. I'll also post a separate post about JEP 253 soon. So, what does my JDeps analysis show (ignoring UI Controls and CSS usage, which has been largely resolved by JEP 253)? I can sum it up in the following categories: == 'Toolkit' API == A lot of people use a small amount of API from Toolkit, such as the API for nested event loops, to fire a pulse, and to add / remove pulse listeners. Based on this analysis, the current thinking is to add API into the javafx.application.Platform class to enable the first two use cases above (nested event loops and pulse firing). The third use case needs more engineering effort, and is a far less common use case, so isn't being considered for JDK 9. == 'Traversal' API == This API lives in com.sun.javafx.scene.traversal, and is quite useful when writing custom controls to ensure that keyboard traversal puts the focus in the right node at the right time. My ControlsFX open source project is a common (ab)user of this API, so I have a vested interest in making this public. Having said this, the API is actually in quite good shape, and it is possible with just a little JavaDoc work it could make the move into javafx.scene.traversal. == 'Collections Event' API == There exists classes in com.sun.javafx.collections that are quite useful if you create your own custom ObservableList implementation and want to fire events at certain times. In my analysis there are only two projects using these APIs: ControlsFX and JVx by SIB Visions. The other pertinent point is that this code is quite easy to reproduce, so, whilst I would like to see this API public, it doesn't seem to make sense for JavaFX 9. == 'Utils' API == There exists three classes that are quite commonly used by people for the various utility methods contained within. These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and com.sun.javafx.application.PlatformImpl. As most of these classes are just a collection of self-contained methods, it is quite likely that a number of these methods will find public API alternatives in a new class (although there are no plans to move all the methods over!). == Miscellaneous API == Finally, there are a few classes that popped up quite frequently. Here is the list, and my thoughts on what to do with them: 1) com.sun.javafx.runtime.VersionInfo: Questionable about usefulness - not a likely candidate for JDK 9. 2) com.sun.javafx.event.EventHandlerManager: Only used in ControlsFX - not a likely candidate for JDK 9. 3) Robot: A good API to make public, but not a small API, so the scope is possibly too great for JDK 9. 4) PerformanceTracker: Same as Robot - good, but API might require more time than is available for JDK 9. == What about other private API == If I've stated that an API you use isn't likely to make the cut for 9, there is another option: pull up your sleeves and work with us to get the API into a shape where it is good enough to commit to as public API. I should note that you shouldn't just dive in and do this - ping us and let us know first, so we can sync up and make sure the plan is feasible (and not overlapping). Because any large chunk of work would require moving through the JEP process, it is unlikely that anything other than small tweaks would be acceptable. One such example might be the PerformanceTracker. == Where to from here? == The first milestone is to get JEP 253 into the main repo. That should hopefully be done before the end of August. Once that is done, focus can shift to the areas identified in this email. In the mean time, if there is any community feedback, please get it in ASAP so it can be included in the consideration. [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017017.html [2]
Re: Another JavaFX Application Thread
@Mike JRuby brings me ~ +30 MB. I tried to use Nashorn also but it is so slow. I'm thinking to continue with WebView. The question is why there is HTML 5 Web Workers. Why there is no like that for JavaFX threading model. @Jens Expensiveness comes from JavaScript code that runs on UI thread. Script execution takes long time normally. For example docbook conversion execution starts from here https://github.com/asciidocfx/AsciidocFX/blob/master/src/main/java/com/kodcu/component/HtmlPane.java#L56 2015-08-06 13:45 GMT+03:00 Mike Hearn m...@plan99.net: That seems like a roundabout way to do things. The web tells me: The asciidoctor.js project is a direct port of Asciidoctor from Ruby to JavaScript using the Opal Ruby-to-JavaScript cross compiler Why don't you use JRuby and run the original Asciidoctor code directly in a background thread? That way, no webview is needed and it can all be done in the background. -- Rahman USTA Istanbul JUG https://github.com/rahmanusta http://www.kodcu.com/
Re: Another JavaFX Application Thread
Am Donnerstag, 6. August 2015, 14:00:27 schrieb Rahman USTA:
@Mike
JRuby brings me ~ +30 MB. I tried to use Nashorn also but it is so slow.
I'm thinking to continue with WebView.
The question is why there is HTML 5 Web Workers. Why there is no like that
for JavaFX threading model.
@Jens
Expensiveness comes from JavaScript code that runs on UI thread. Script
execution takes long time normally. For example docbook conversion
execution starts from here
https://github.com/asciidocfx/AsciidocFX/blob/master/src/main/java/com/kodcu
/component/HtmlPane.java#L56
i would replace:
JSObject result = (JSObject)
webEngine().executeScript(String.format(convertDocbook(editorValue,docbookOptions)));
return
with:
CompletableFutureJSObject future = CompletableFuture.supplyAsync(
() - {
return
(JSObject)
webEngine().executeScript(String.format(convertDocbook(editorValue,docbookOptions)));
}
);
return new ConverterResult(future); you should check if future is
present
change your method an provide a consumer to call on completion an do not
return the result (would be better)
--
Jens Kapitza
Re: Another JavaFX Application Thread
Jens;
executeScript must be run on JavaFX Application Thread, and execution of my
script takes long time. There is an unavoidable freezing case if your
script takes long time.
CompletableFuture can't help us because the issue arise from JavaScript
execution.
2015-08-06 14:17 GMT+03:00 Jens Kapitza j.kapi...@schwarze-allianz.de:
Am Donnerstag, 6. August 2015, 14:00:27 schrieb Rahman USTA:
@Mike
JRuby brings me ~ +30 MB. I tried to use Nashorn also but it is so slow.
I'm thinking to continue with WebView.
The question is why there is HTML 5 Web Workers. Why there is no like
that
for JavaFX threading model.
@Jens
Expensiveness comes from JavaScript code that runs on UI thread. Script
execution takes long time normally. For example docbook conversion
execution starts from here
https://github.com/asciidocfx/AsciidocFX/blob/master/src/main/java/com/kodcu
/component/HtmlPane.java#L56
i would replace:
JSObject result = (JSObject)
webEngine().executeScript(String.format(convertDocbook(editorValue,docbookOptions)));
return
with:
CompletableFutureJSObject future = CompletableFuture.supplyAsync(
() - {
return
(JSObject)
webEngine().executeScript(String.format(convertDocbook(editorValue,docbookOptions)));
}
);
return new ConverterResult(future); you should check if future is
present
change your method an provide a consumer to call on completion an do not
return the result (would be better)
--
Jens Kapitza
--
Rahman USTA
Istanbul JUG
https://github.com/rahmanusta http://www.kodcu.com/
JVM (8u60) crashing on ARM
Hi all, I'm running a java application on iMX.6 (Freescale) with javafx within it. The JVM crashes after some time. I have two files: hs_err_pid1101.log (few kbytes) and core (this is big, 500mb~). Where I can get help with that crashes? Should I provide the core dump here or shold be delivered to Oracle or something like that? Any help is helpful :) Best regards, - dhs -- *Do or do not. There is no try* *Yoda Master*
VNC alternative for JavaFX running directly on framebuffer.
Hi all, I'm running applications on Freescale's iMX.6 using JavaFX. It's known that it doesn't uses X but directly access the framebuffer instead, so x11vnc doesn't applies. I need to export the video input/output as VNC does. Does anybody knows an alternative solution for this? Best regards, - dhs -- Do or do not. There is no try Yoda Master
Re: VNC alternative for JavaFX running directly on framebuffer.
On 8/6/15, 9:36 AM, Daniel. wrote: Hi all, I'm running applications on Freescale's iMX.6 using JavaFX. It's known that it doesn't uses X but directly access the framebuffer instead, so x11vnc doesn't applies. I need to export the video input/output as VNC does. Does anybody knows an alternative solution for this? Best regards, - dhs I did have an older Glass module running with VNC at one point, mostly as a demonstration, but that was left behind when we moved to Monocle. The structure of Monocle is such that it would not take too much to make it VNC compatible, the biggest effort actually is the input mapping. I would probably stuff it in to the headless support we have in there. I don't have bandwidth to take on something like this right now, as fun as it would be. Dave -- David Hilldavid.h...@oracle.com Java Embedded Development A man's feet should be planted in his country, but his eyes should survey the world. -- George Santayana (1863 - 1952)
Re: RejectedExecutionException
I agree. Please file a bug. -- Kevin Tom Eugelink wrote: Indeed, this exception put me on the wrong track, trying to figure out why the test was failing based on the exception, while I was just asserting the wrong property. I now also understand what it is trying to tell me. And I must agree with Mike; given that the renderer is terminated, and it does no longer accept new jobs, there is no need to confuse coders and users with exceptions that neither have control over. Or can the coder do something to prevent these? Maybe allow for a way to hook into these exceptions with a callback / listener, or have them thrown via a command line setting, so if there is some kind issue they still can be tracked. On 4-8-2015 14:43, Mike Hearn wrote: Race free shutdown in multi-threaded programs is always very hard. At Google some programs and libraries simply didn't support it: for servers, the cost in terms of bugs and extra code was deemed to outweigh the benefits, so the only supported way for a process to end was for it to be killed. JavaFX does not have that luxury. It must be able to shut down cleanly without races. In this case, the message is probably harmless: who cares if a render job doesn't complete if you're busy tearing down process state? So perhaps Quantum should just set a custom reject handler that ignores the issue instead of throwing. On Mon, Aug 3, 2015 at 4:10 PM, Tom Eugelink t...@tbee.org mailto:t...@tbee.org wrote: Working on a new skin for JFXtras Agenda... What is JavaFX trying to tell me with this exception? java.util.concurrent.RejectedExecutionException: Task com.sun.javafx.tk.quantum.PaintRenderJob@33cf88 rejected from com.sun.javafx.tk.quantum.QuantumRenderer@1133212[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 30] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112) at com.sun.javafx.tk.quantum.QuantumRenderer.submitRenderJob(QuantumRenderer.java:218) at com.sun.javafx.tk.quantum.QuantumToolkit.addRenderJob(QuantumToolkit.java:467) at com.sun.javafx.tk.quantum.ViewScene.repaint(ViewScene.java:140) at com.sun.javafx.tk.quantum.PaintCollector.renderAll(PaintCollector.java:435) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:526) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:505) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$400(QuantumToolkit.java:334) at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/14510047.run(Unknown Source) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.lambda$null$145(WinApplication.java:101) at com.sun.glass.ui.win.WinApplication$$Lambda$43/19282349.run(Unknown Source) at java.lang.Thread.run(Thread.java:745)
Re: 8u60-b26 ?
Exactly. -- Kevin Phil Race wrote: I am going to guess its because when you get real close to release and start building candidates for release the build string no longer has EA in it, and someone might mistakenly think it is an actual confirmed FCS build you can use in production. That is not the case until it has passed final testing. So the FCS candidate builds are not ones you would put up for download as an EA. So it just sounds like a boo-boo to me that got semi-fixed. -phil. On 08/05/2015 10:52 AM, Scott Palmer wrote: It was there a few days ago, when I downloaded it for OS X. Now the page only shows b25. It’s the first FCS build, so I wonder if it was removed for a reason. It’s still there for download if you guess the URL. Scott
