Re: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation
On Tue, 26 Nov 2019 09:22:04 GMT, Kevin Rushforth wrote:
> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas wrote:
>
>> **Issue :**
>> https://bugs.openjdk.java.net/browse/JDK-8193445
>>
>> **Background :**
>> The CSS performance improvement done in
>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be
>> backed out due to functional regressions reported in
>> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709),
>> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and
>> [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951).
>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for
>> more details on this backout.
>>
>> **Description :**
>> This PR reintroduces the CSS performance improvement fix done in
>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while
>> addressing the functional regressions that were reported in
>> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709),
>> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and
>> [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951).
>> For ease of review, I have made two separate commits -
>> 1) [Commit
>> 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334)
>> - Reintroduces the CSS performance improvement fix done in
>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of
>> the patch applied cleanly.
>> 2) [Commit 2
>> ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)-
>> fixes the functional regressions keeping performance improvement intact +
>> adds a system test
>>
>> **Root Cause :**
>> CSS performance improvement fix proposed in [JDK-8151756
>> ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the
>> redundant CSS reapplication to children of a Parent.
>> What was missed earlier in [JDK-8151756
>> ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication
>> to the Parent itself”.
>> This missing piece was the root cause of all functional regressions reported
>> against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756)
>>
>> **Fix :**
>> Fixed the identified root cause. See commit 2.
>>
>> **Testing :**
>> 1. All passing unit tests continue to pass
>> 2. New system test (based on
>> [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in
>> this PR - fails before this fix and passes after the fix
>> 3. System test JDK8183100Test continues to pass
>> 4. All test cases attached to regressions
>> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709),
>> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and
>> [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with
>> this fix
>>
>> In addition, testing by community with specific CSS performance /
>> functionality will be helpful.
>>
>>
>>
>> Commits:
>> - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test
>> - d964675e: Reintroduce JDK-8151756 CSS performance fix
>>
>> Changes: https://git.openjdk.java.net/jfx/pull/34/files
>> Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193445
>> Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod
>> Patch: https://git.openjdk.java.net/jfx/pull/34.diff
>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34
>
> The fix itself looks good and is a much safer approach than the previous one.
> I've done a fair bit of testing and can see no regressions as a result of
> this fix. I did find one unrelated issue while testing (a visual bug
> introduced back in JDK 10) that I will file separately.
>
> The test is pretty close, but still needs a few changes. The main problem is
> that it does not catch the performance problem, meaning if you run it without
> the fix, it will still pass. Your test class extends
> `javafx.application.Application`, which can cause problems, since JUnit will
> create a new instance of the test class that is different from the one
> created by the call to `Application.launch` in the `@BeforeClass` method.
> This in turn leads to the `rootPane` instance used by the test method being
> different from the one used as the root of the visible scene. The fix is to
> use a separate nested (static) subclass of Application, and make the rootPane
> field a static field. I have left inline comments for this and a few other
> things I noticed.
>
> tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line
> 63:
>
>> 62:
>> 63: public class QuadraticCssTimeTest extends Application {
>> 64:
>
> Remove `extends Application`
>
> tests/system/src/test/java/test/javafx/scene/QuadraticCssTimeTest.java line
> 66:
>
>> 65: static private CountDownLatch startupLatch;
>> 66: static private Stag
Re: Request for permission to backport fixes to jfx-11
Could JavaFX 11 also get backported the fix related for JDK-8193502? It might have been solved in the fix for JDK-8179073. I noticed this regression right after JDK 9 build 161. Recently also JavaFX 8 got this regression after update 181. It seems this was fixed in JavaFX 13. I asked on GitHub in #222 a while back if this could be backported. Considering that repository is now closed, I will repeat it here. Kevin Rushforth wrote: > That's a good question for @johanvos -- it seems this might be a good candidate for backport, although there is one report of a possible regression caused by this fix when using GTK 2 as reported in #475 /Sverre [1] https://bugs.openjdk.java.net/browse/JDK-8193502 [2] https://bugs.openjdk.java.net/browse/JDK-8179073 [3] https://github.com/javafxports/openjdk-jfx/pull/456 [4] https://github.com/javafxports/openjdk-jfx/issues/222 man. 21. okt. 2019 kl. 14:39 skrev Kevin Rushforth < kevin.rushfo...@oracle.com>: > +1 > > -- Kevin > > On 10/21/2019 3:16 AM, Johan Vos wrote: > > Hi Kevin, > > > > I request permission to backport the following issues to the jfx-11 > > repository. All patches apply clean or with minor changes (e.g. > > build.properties must keep jfx.release.major.version to 11) > > > > Thanks, > > > > - Johan > > > > https://bugs.openjdk.java.net/browse/JDK-8221302 : Upgrade to gcc 8.2 on > > Linux > > https://bugs.openjdk.java.net/browse/JDK-8221299 : Upgrade to Visual > Studio > > 2017 version 15.9.6 > > https://bugs.openjdk.java.net/browse/JDK-8221300 : Upgrade to Xcode 10.1 > > https://bugs.openjdk.java.net/browse/JDK-8214716 : Record the versions > of > > tools used to build FX in the repo > > https://bugs.openjdk.java.net/browse/JDK-8222788 : javafx.web build > fails > > on XCode 10.2 > > https://bugs.openjdk.java.net/browse/JDK-8225203 : Update SQLite to > version > > 3.28.0 > > https://bugs.openjdk.java.net/browse/JDK-8219362 : Update to 608.1 > version > > of WebKit > > https://bugs.openjdk.java.net/browse/JDK-8227079 : Cherry pick GTK > WebKit > > 2.24.3 changes > > https://bugs.openjdk.java.net/browse/JDK-8230361 : [web] Cookies are not > > enabled in WebKit v608.1 > > https://bugs.openjdk.java.net/browse/JDK-8229328 : [windows] > > PlatformFileHandle type should be JGObject rather than void * > > https://bugs.openjdk.java.net/browse/JDK-8227431 : [Windows] Fix > assertion > > failure on X86 32-bit when enabling CLOOP based JavaScript interpreter > > https://bugs.openjdk.java.net/browse/JDK-8222912 : Websocket client > doesn't > > work in WebView > > https://bugs.openjdk.java.net/browse/JDK-8226537 : Multi-level > > Stage::initOwner can crash gnome-shell or X.org server > > https://bugs.openjdk.java.net/browse/JDK-8212060 : [GTK3] Stage > sometimes > > shown at top-left before moving to correct position > > https://bugs.openjdk.java.net/browse/JDK-8211302 : DragAndDrop no longer > > works with GTK3 > > https://bugs.openjdk.java.net/browse/JDK-8213510 : MediaPlayer does not > > play some mp3 with artwork stream in mjpeg > > https://bugs.openjdk.java.net/browse/JDK-8207942: Add new protected > > VirtualFlow methods for subclassing > >
Re: Bug in TreeTableView rendering
A comment on the JDK-8231644 issue was added by Jeanette Winzenburg
https://bugs.openjdk.java.net/browse/JDK-8231644
> hmm .. no testing done but: the data object looks pathological - it's
always problematic to have nodes as data (even though technically
possible). That will explode with the known glitches with
graphics/disclosureNode in treeTableRow
I would like to know more about what you are saying here:
1) That OurDataObject and AlsoOurDataObject as data model/type to
TreeTableView is pathological?
2) "Having nodes as data". Are you referring to using a Label node in the
Column CellValueFactory?
column.setCellValueFactory(param -> new ReadOnlyObjectWrapper<>(
new OurDataObjectLabel(param.getValue().getValue(;
Instead of using:
column.setCellValueFactory(new TreeItemPropertyValueFactory<>("name"));
The reason we are using OurDataObjectLabel, is because we want to style a
specific type of data determined by AlsoOurDataObject.
3) What known glitches?
/Sverre
Re: JavaFX dialog window size regression
Can we get the fix for JDK-8179073 [1] backported to JavaFX 11? As discussed on the openjfx GitHub issue #222 [2]. It seems to have a fix already in PR #456 [3]. [1] https://bugs.openjdk.java.net/browse/JDK-8179073 [2] https://github.com/javafxports/openjdk-jfx/issues/222 [3] https://github.com/javafxports/openjdk-jfx/pull/456 /Sverre tor. 26. apr. 2018 kl. 21:35 skrev Sverre Moe : > I filed a bug report a while back. Since I didn't have access I could > not comment or update in that issue. > > https://bugs.openjdk.java.net/browse/JDK-8179073 > > With Java 9, a JavaFX dialogs got tiny and did not size up to its content. > This worked fine when I was running JDK 9 build 161, but after JDK 9 > build 165 the dialog window did not size up to show any of its > content. > > The code exampled I provided with that bug report still produces a > tiny dialog window with both jdk-9.0.4 and jdk-10.0.1 > > Setting the Dialog size to fixed width/height does not work, but if > with setResizable(true) the Dialog gets its full size. > > It has been a while since I have used Java 9. Today I got the same > problem while trying to exit SceneBuilder 9 downloaded from Gluon. > > I was wondering if I should re-create this bug report on the GitHub > OpenJFX repository? >
Re: Bug in TreeTableView rendering
I filed it on bugreport.java.com > We will review your report and have assigned it an internal review ID : 9062382. /Sverre man. 30. sep. 2019 kl. 14:49 skrev Kevin Rushforth < kevin.rushfo...@oracle.com>: > Hi Sverre, > > Thanks for bringing this to our attention. Can you please file a bug at > bugreport.java.com [1]? > > This seems like a good time to remind everyone that JBS [2] is our bug > tracking system. This GitHub issue tracker is not actively tracked or > managed. The official GitHub repos in the openjdk organization will not > have the issue tracker enabled, which should help avoid this confusion. > > -- Kevin > > [1] https://bugreport.java.com/ > [2] https://bugs.openjdk.java.net/ > [3] https://github.com/openjdk/ > > On 9/30/2019 3:08 AM, Sverre Moe wrote: > > I have created an issue for this on GitHub. > > https://github.com/javafxports/openjdk-jfx/issues/607 > > > > /Sverre > > > >
Re: Bug in TreeTableView rendering
I have created an issue for this on GitHub.
https://github.com/javafxports/openjdk-jfx/issues/607
/Sverre
man. 26. aug. 2019 kl. 20:03 skrev Sverre Moe :
> I think I have found a bug/regression with Java 11 regarding TreeTableView.
> This has worked fine on JavaFX 8, but is messed up with JavaFX 11.
> 1) The arrow button is on the text
> 2) No text indentation levels: Each row (no matter the level) is at the
> left edge of the TreeTableView.
>
> I can file an issue at GitHub if this is a real bug/regression. I just
> wanted to check first here.
>
> TreeTableColumn column = new
> TreeTableColumn<>("Column");
> column.setCellValueFactory(param -> new ReadOnlyObjectWrapper<>(new
> OurDataObjectLabel(param.getValue().getValue(;
>
> We are using Label here so we can set StyleClass based on some information
> in the OurDataObject.
>
> class OurDataObject {
> private String name;
> public String getName() { return name; }
> }
>
> class AlsoOurDataObject extends OurDataObject {
> public boolean isSomething() { ... }
> }
>
> class OurDataObjectLabel extends Label() {
> public OurDataObjectLabel(OurDataObject ourDataObject) {
> setText(ourDataObject.getName());
> if (ourDataObject instanceof AlsoOurDataObject) {
> if (((AlsoOurDataObject) ourDataObject).isSomething()) {
> getStyleClass().add("style");
> }
> }
> }
> }
>
> A workaround was to use OurDataObject for both types in the
> TreeTableColumn, create a CellFactory to do what has been done in
> OurDataObjectLabel and in addition to the CellValueFactory.
>
> Code Example for reproducing the problem:
> This is using a String instead of an Object as the data model for
> simplicity.
> I have attached a screenshot that illustrates this problem. Made with the
> example code below.
>
> import javafx.application.Application;
> import javafx.beans.property.ReadOnlyObjectWrapper;
> import javafx.scene.Scene;
> import javafx.scene.control.TreeItem;
> import javafx.scene.control.TreeTableColumn;
> import javafx.scene.control.TreeTableView;
> import javafx.scene.layout.StackPane;
> import javafx.scene.text.Text;
> import javafx.stage.Stage;
>
> public class App extends Application {
>
> public static void main(String[] args) {
> App.launch(args);
> }
>
> @Override
> public void start(Stage stage) throws Exception {
> StackPane root = new StackPane();
>
> TreeTableView treeTableView = new TreeTableView<>();
> treeTableView.setShowRoot(false);
> root.getChildren().add(treeTableView);
>
> TreeTableColumn column = new
> TreeTableColumn<>("Column");
> column.setPrefWidth(200);
> treeTableView.getColumns().add(column);
>
> column.setCellValueFactory(param -> new ReadOnlyObjectWrapper<>(
> new Text(param.getValue().getValue(;
>
> TreeItem rootItem = new TreeItem<>("");
> treeTableView.setRoot(rootItem);
>
> TreeItem item1 = new TreeItem<>("LEVEL1");
> item1.setExpanded(true);
> rootItem.getChildren().add(item1);
>
> TreeItem item2 = new TreeItem<>("LEVEL2");
> item2.setExpanded(true);
> item1.getChildren().add(item2);
>
> TreeItem item3 = new TreeItem<>("LEVEL2_1");
> item3.setExpanded(true);
> item2.getChildren().add(item3);
>
> Scene scene = new Scene(root, 250, 150);
>
> stage.setTitle("JavaFX11");
> stage.setScene(scene);
> stage.show();
> }
> }
>
>
> /Sverre
>
>
Re: JavaFX 11 Web Module Linux Requires libavcodec-ffmpeg
tor. 19. sep. 2019 kl. 15:36 skrev Kevin Rushforth < kevin.rushfo...@oracle.com>: > The dependency on libavcodec56 / libavcodec-ffmpeg56 is almost certainly > coming from javafx.media. The javafx.web module depends on > javafx.media, which explains why javafx.web pulls in that dependency. > It must have been some error on my side. Removing both the javafx.media and javafx.web will omit the libav* Requires from my RPM package built by jpackage. > The javafx.media module includes dynamic libraries that are stubs for > different versions of libav. If you download the JavaFX SDK, you will > see them in the sdk/lib directory with the names libavplugin-NN.so and > libavplugin-ffmpeg-NN.so. > > Alexander can provide more information. > > The runtime image produced with jlink and the JavaFX jmods do have these so-files present in the lib directory of the runtime image. If they are present there should not be any need to specify them as Requires on the RPM package built by jpackage. Does the problem then lie on the jpackage "scanning" for Linux Package Dependencies? What linux distribution and package where these bundled so-files built from? The libav56 should come from ffmpeg2 package, while libav57 is from ffmpeg3 package, but none of these ffmpeg packages produce a libavcodec-ffmpeg.so. My Linux distribution OpenSUSE, and I have checked with Fedora, do not have the libavcodec-ffmpeg.so. They do however have the libavcodec.so.57 which is among the requires (version 56 and 57). > > On 9/19/2019 1:52 AM, Sverre Moe wrote: > > Building an JavaFX application with the jpackage tools adds many > additional > > Linux RPM Requires. > > > > Among these are libavcodec56 and libavcodec-ffmpeg56. It is ffmpeg2 that > > has libavcodec56, but the libavcodec-ffmpeg is nowhere to be found. It > does > > not seem to exist. > > > > If building an Java runtime image with the JavaFX 11 Web module, these > are > > among the RPM Requires added to the RPM package built by jpackage. One > > could actually think it would be the media module that had these > requires, > > but no it doesn't. > > > > The jpackage tool does not have any of these Require packages itself. It > is > > getting them from the javafx.web module. If I omit the javafx.web from > the > > java runtime image, these Requires are omitted from the built RPM > package: > > > > libavcodec-ffmpeg.so.56()(64bit) > > libavcodec-ffmpeg.so.56(LIBAVCODEC_FFMPEG_56)(64bit) > > libavcodec.so.54()(64bit) > > libavcodec.so.54(LIBAVCODEC_54)(64bit) > > libavcodec.so.56()(64bit) > > libavcodec.so.56(LIBAVCODEC_56)(64bit) > > libavcodec.so.57()(64bit) > > libavcodec.so.57(LIBAVCODEC_57)(64bit) > > libavformat-ffmpeg.so.56()(64bit) > > libavformat-ffmpeg.so.56(LIBAVFORMAT_FFMPEG_56)(64bit) > > libavformat.so.54()(64bit) > > libavformat.so.54(LIBAVFORMAT_54)(64bit) > > libavformat.so.56()(64bit) > > libavformat.so.56(LIBAVFORMAT_56)(64bit) > > libavformat.so.57()(64bit) > > libavformat.so.57(LIBAVFORMAT_57)(64bit) > > > > The problem is since libavcodec-ffmpeg does not exist installing this > built > > package is impossible (or cumbersome at best). > > > > It Requires either ffmpeg2 (libavcodec56) or ffmpeg3 (libavcoded57), so > > most Linux distributions are covered. Even if a Linux distribution has > > ffmpeg3 it will not install the package because of libavcodec-ffmpeg. > > > > > > What part of the JavaFX Web module requires ffmpeg and libavcodec? I > would > > like to try using this to see if the application works on Linux. Perhaps > > the libavcodec-ffmpeg is provided by some other package or other named > > library. > > > > /Sverre > >
JavaFX 11 Web Module Linux Requires libavcodec-ffmpeg
Building an JavaFX application with the jpackage tools adds many additional Linux RPM Requires. Among these are libavcodec56 and libavcodec-ffmpeg56. It is ffmpeg2 that has libavcodec56, but the libavcodec-ffmpeg is nowhere to be found. It does not seem to exist. If building an Java runtime image with the JavaFX 11 Web module, these are among the RPM Requires added to the RPM package built by jpackage. One could actually think it would be the media module that had these requires, but no it doesn't. The jpackage tool does not have any of these Require packages itself. It is getting them from the javafx.web module. If I omit the javafx.web from the java runtime image, these Requires are omitted from the built RPM package: libavcodec-ffmpeg.so.56()(64bit) libavcodec-ffmpeg.so.56(LIBAVCODEC_FFMPEG_56)(64bit) libavcodec.so.54()(64bit) libavcodec.so.54(LIBAVCODEC_54)(64bit) libavcodec.so.56()(64bit) libavcodec.so.56(LIBAVCODEC_56)(64bit) libavcodec.so.57()(64bit) libavcodec.so.57(LIBAVCODEC_57)(64bit) libavformat-ffmpeg.so.56()(64bit) libavformat-ffmpeg.so.56(LIBAVFORMAT_FFMPEG_56)(64bit) libavformat.so.54()(64bit) libavformat.so.54(LIBAVFORMAT_54)(64bit) libavformat.so.56()(64bit) libavformat.so.56(LIBAVFORMAT_56)(64bit) libavformat.so.57()(64bit) libavformat.so.57(LIBAVFORMAT_57)(64bit) The problem is since libavcodec-ffmpeg does not exist installing this built package is impossible (or cumbersome at best). It Requires either ffmpeg2 (libavcodec56) or ffmpeg3 (libavcoded57), so most Linux distributions are covered. Even if a Linux distribution has ffmpeg3 it will not install the package because of libavcodec-ffmpeg. What part of the JavaFX Web module requires ffmpeg and libavcodec? I would like to try using this to see if the application works on Linux. Perhaps the libavcodec-ffmpeg is provided by some other package or other named library. /Sverre
Bug in TreeTableView rendering
I think I have found a bug/regression with Java 11 regarding TreeTableView.
This has worked fine on JavaFX 8, but is messed up with JavaFX 11.
1) The arrow button is on the text
2) No text indentation levels: Each row (no matter the level) is at the
left edge of the TreeTableView.
I can file an issue at GitHub if this is a real bug/regression. I just
wanted to check first here.
TreeTableColumn column = new
TreeTableColumn<>("Column");
column.setCellValueFactory(param -> new ReadOnlyObjectWrapper<>(new
OurDataObjectLabel(param.getValue().getValue(;
We are using Label here so we can set StyleClass based on some information
in the OurDataObject.
class OurDataObject {
private String name;
public String getName() { return name; }
}
class AlsoOurDataObject extends OurDataObject {
public boolean isSomething() { ... }
}
class OurDataObjectLabel extends Label() {
public OurDataObjectLabel(OurDataObject ourDataObject) {
setText(ourDataObject.getName());
if (ourDataObject instanceof AlsoOurDataObject) {
if (((AlsoOurDataObject) ourDataObject).isSomething()) {
getStyleClass().add("style");
}
}
}
}
A workaround was to use OurDataObject for both types in the
TreeTableColumn, create a CellFactory to do what has been done in
OurDataObjectLabel and in addition to the CellValueFactory.
Code Example for reproducing the problem:
This is using a String instead of an Object as the data model for
simplicity.
I have attached a screenshot that illustrates this problem. Made with the
example code below.
import javafx.application.Application;
import javafx.beans.property.ReadOnlyObjectWrapper;
import javafx.scene.Scene;
import javafx.scene.control.TreeItem;
import javafx.scene.control.TreeTableColumn;
import javafx.scene.control.TreeTableView;
import javafx.scene.layout.StackPane;
import javafx.scene.text.Text;
import javafx.stage.Stage;
public class App extends Application {
public static void main(String[] args) {
App.launch(args);
}
@Override
public void start(Stage stage) throws Exception {
StackPane root = new StackPane();
TreeTableView treeTableView = new TreeTableView<>();
treeTableView.setShowRoot(false);
root.getChildren().add(treeTableView);
TreeTableColumn column = new
TreeTableColumn<>("Column");
column.setPrefWidth(200);
treeTableView.getColumns().add(column);
column.setCellValueFactory(param -> new ReadOnlyObjectWrapper<>(
new Text(param.getValue().getValue(;
TreeItem rootItem = new TreeItem<>("");
treeTableView.setRoot(rootItem);
TreeItem item1 = new TreeItem<>("LEVEL1");
item1.setExpanded(true);
rootItem.getChildren().add(item1);
TreeItem item2 = new TreeItem<>("LEVEL2");
item2.setExpanded(true);
item1.getChildren().add(item2);
TreeItem item3 = new TreeItem<>("LEVEL2_1");
item3.setExpanded(true);
item2.getChildren().add(item3);
Scene scene = new Scene(root, 250, 150);
stage.setTitle("JavaFX11");
stage.setScene(scene);
stage.show();
}
}
/Sverre
Re: Distributing JavaFX 11 Application
You could use the new jpackage to create a native runtime of your
application.
The jpackager is now targeted for JDK 13, but can still be used to create a
native Java 11 application.
You can download an EA build of JDK 13 with jpackage
http://jdk.java.net/jpackage/
You would need to build on each platform, Linux, Windows, Mac.
You mentioned you use Maven. When Java 9 came out I had already moved over
to Gradle, so not familiar with the maven configuration.
Here is a Gradle task to create a Java 11 runtime using jlink with the Java
11 jmods
task createRuntime(type: Exec) {
dependsOn installDist
inputs.dir(installDist.outputs.files.singleFile)
outputs.dir("${buildDir}/runtime")
doFirst {
delete "${buildDir}/runtime"
}
def libDir = new File(installDist.outputs.files.singleFile, "lib").path
commandLine '/usr/java/jdk-11/bin/jlink',
'--module-path', "/usr/java/jdk-11/jmods:${libDir}",
'--add-modules', 'eu.yourmodule.application',
'--output', "${buildDir}/runtime"
}
You then use this runtime with jpackage to create a native application
image or installer.
task createPackage(type: Exec) {
dependsOn createRuntime
commandLine '/usr/java/jdk-13/bin/jpackage', 'create-installer',
'--verbose',
'--force',
'--name', project.name,
'--app-version', project.version,
'--module', "${mainClassName}",
'--resource-dir', "${buildDir}/package",
'--runtime-image', "${buildDir}/runtime",
'--output', "${buildDir}/native"
}
/Sverre
Den ons. 20. feb. 2019 kl. 19:57 skrev Nicolas Therrien <
nicolas.therr...@motorolasolutions.com>:
> Hi!
>
> What is the proper way to create distributable packages of a JavaFx
> Application?
>
> I have a Java 11 application which I build as a module. The distribution
> includes a "modules" folder with all dependencies in it, and a script to
> launch the module.
>
> This assembly works if I build it on the same machine as I am going to be
> running it on. However, I realized that depending on which build agent the
> assembly is going to be created, the platform specific javafx dependencies
> may not match the target assembly. For example, if the build agent is a
> linux build agent, the windows and mac assembly contains linux javafx
> runtime.
>
> Maven will always pull the platform-specific libraries of the system it is
> running on.
>
> This was not a problem when JavaFx was part of the JDK since the correct
> runtime libraries were installed on the system already.
>
> What is the correct way to create a windows or linux package in a build
> platform independent way?
>
> I found an article which showed how to force maven to include all platforms
> as dependencies, but then I have to add dependency on each transitive
> library. Sounds like a lot of trouble for a simple task.
>
> How do you guys package your apps for various platforms?
>
> *Nicolas Therrien*
>
> Senior Software Developer
>
> *[image:
>
> https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]*
>
> *o*: +1.819.931.2053
>
Re: Filling the Packager gap
Den fre. 14. des. 2018 kl. 13:47 skrev Johan Vos : > Hi Sverre, > > Scene Builder 11 is built using that backported packager, but not > everything was working yet. > It is not the intention to make a real product based on this backported > code -- we just did it to fill the gap until the jpackage tool is available. > > My understanding is that once the jpackage tool is released, you should be > able to use it to bundle Java(FX) 11 based apps. > > The first EA version of the jpackage tool is available now, so I think > this is now the way forward: http://jdk.java.net/jpackage/ > > - Johan > Thanks for the clarification. I have been looking through the source code of your backported jpackager to gain some insight, and I should perhaps instead be looking at the main source code for the jpackage. I will start using this JDK12 build of jpackager and see if it has the same issues regarding the bundle resources. Perhaps also the core-libs-...@openjdk.java.net is the better place to discuss jpackage on forward. I reported some issues with jpackage some time ago that has been added to its JDK bugs list. /Sverre
Re: Filling the Packager gap
Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos :
> Hi,
>
> As promised, we looked into an interim solution for the packager-gap. Work
> for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
> We backported the required changes to an OpenJDK 11 mirror:
> https://github.com/johanvos/openjdk-mobile11/tree/packager
>
> With this, we created modified OpenJDK 11 builds that contain the packager
> (wrapper/exe + module including native library). They can be downloaded and
> tested/used at
>
> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
> http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
>
> For Windows, you have to unzip the bundle in the same directory as the JDK,
> as the packager wrapper expect to find the java binary at the same level.
>
> Note that these are not products. We use them internally to create
> installers (e.g. we're using them for Scene Builder 11 and that works
> fine), and they do what we expect them to do, but there are no guarantees
> of course so at least for now I recommend using them in development only
> (or even better, look at the changes and contribute to
> https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
>
> - Johan
>
Has anyone been able to use jpackager with bundle resources?
The jpackager says to put these on the class path
Using default package resource [menu icon] (add package/linux/app.png to
the class path to customize)
Using default package resource [Menu shortcut descriptor] (add
package/linux/app.desktop to the class path to customize)
Using default package resource [RPM spec file] (add package/linux/app.spec
to the class path to customize)
I have mentioned on corejdk mailinglist that the help output should mention
how to do this.
The jpackager does not support any classpath argument. The old javapackager
did have an argument for setting classpath.
Editing the jpackager bash script to include "-cp
/path/to/project/build/deploy/" does not work.
Considering that jdk.packager is a java module, I even tried to add the
directory where package/linux is to the module-path.
--module-path "/path/to/project/build/deploy":${JAVA_PACKAGER_PATH}
It seems jpackager has been re-targeted for Java 13. I just hope it will
continue to be usable for package Java 11 applications. The backported
jpackager is working fine except for this resource problem.
/Sverre
Re: Filling the Packager gap
Johan, has there been any new updates to jpackager in JDK12 since you backported it? I have found some problems with jpackager. Perhaps they might have been fixed later. I mentioned this to core-list-dev mailinglist on jpackager thread. 1) The control file for debian package does not set correct description --name test --description This is a Test Application /tmp/jdk.packager607148779833718376/linux/control Package: test Description: test The RPM gets it correctly Summary : test Description : This is a Test Application 2) Category is not set on either DEB or RPM --category Category or group of the application. --category "Some/Category/Application" Group: Unspecified Section: unknown Perhaps I have misunderstood what this category is for, because I see this it is set in the generated application.desktop, but It should definitely also be set in the RPM and DEB. /Sverre Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos : > Hi, > > As promised, we looked into an interim solution for the packager-gap. Work > for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. > We backported the required changes to an OpenJDK 11 mirror: > https://github.com/johanvos/openjdk-mobile11/tree/packager > > With this, we created modified OpenJDK 11 builds that contain the packager > (wrapper/exe + module including native library). They can be downloaded and > tested/used at > > http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip > > For Windows, you have to unzip the bundle in the same directory as the JDK, > as the packager wrapper expect to find the java binary at the same level. > > Note that these are not products. We use them internally to create > installers (e.g. we're using them for Scene Builder 11 and that works > fine), and they do what we expect them to do, but there are no guarantees > of course so at least for now I recommend using them in development only > (or even better, look at the changes and contribute to > https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport) > > - Johan >
Re: Using the jpackager
Den fre. 9. nov. 2018 kl. 16:22 skrev Rachel Greenham :
> Build the JRE needed using JLink, supplying the needed modules. The
> JLink task referenced is actually written in Java and wraps
> ToolProvider, but it's pretty trivial and could almost-more-easily be
> done with an Exec. NB: The JLink task as written puts it in a "java"
> subdirectory of the given destinationDir.
>
> task buildAdminJre(type: JLink) {
> description 'Build the Client JRE for ' + nativeOsName
> destinationDir
> rootProject.file("deploy/bindist/"+requiredJava.merusNativeAdminJreName)
> modules = [
> 'java.base',
> 'java.desktop',
> 'java.xml',
> 'java.logging'
> ]
> bindServices false
> modulePath =
> [System.properties.getProperty('java.home')+File.separatorChar+'jmods']
> noHeaderFiles true
> noManPages true
> stripDebug true
> }
>
>
> Which gradle plugin are you using that gives you type JLink?
Re: Maybe a TitledPane bug
I am now not so sure it is a bug. Seems the problem is the hover pseudo
state that resets the background color.
>From modena.css
.titled-pane > .title:hover {
-fx-color: -fx-hover-base;
}
Try this example:
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.TitledPane;
import javafx.scene.control.ToggleButton;
import javafx.scene.layout.Background;
import javafx.scene.layout.BackgroundFill;
import javafx.scene.layout.Region;
import javafx.scene.layout.StackPane;
import javafx.scene.paint.Color;
import javafx.stage.Stage;
public class TitledPaneApplication extends Application {
public static void main(String[] args) {
launch(args);
}
@Override
public void start(Stage primaryStage) throws Exception {
final StackPane root = new StackPane();
final TitledPane titledPane = new TitledPane();
titledPane.setText("Title");
titledPane.setAnimated(false);
titledPane.setCollapsible(false);
root.getChildren().add(titledPane);
final ToggleButton button = new ToggleButton("Change");
button.setOnAction(event -> {
boolean selected = button.isSelected();
final Region titleNode = (Region) titledPane.lookup(".title");
if (selected) {
titleNode.setBackground(new Background(new
BackgroundFill(Color.GREEN, null, null)));
} else {
titleNode.setBackground(null);
}
});
button.setSelected(false);
titledPane.setContent(button);
final Scene scene = new Scene(root, 400, 400);
scene.getStylesheets().add(getClass().getResource("light.css").toExternalForm());
primaryStage.setScene(scene);
primaryStage.setTitle("TestApplication");
primaryStage.show();
}
}
Here is the CSS content for light.css
.titled-pane > .title {
-fx-color: rgb(220, 220, 220);
}
/Sverre
Den tor. 1. nov. 2018 kl. 14:45 skrev David Grieve :
> It's hard to tell without some short, self-contained, correct example.
> This sample I crafted here doesn't reproduce the issue.
>
> @Override public void start(Stage primaryStage) {
>
> final TitledPane titledPane =new TitledPane("Button Pane",new
> Button("Button"));
> final HBox root =new HBox();
> root.getChildren().add(titledPane);
>
> primaryStage.setTitle("Maybe a TitledPane bug");
> primaryStage.setScene(new Scene(root,300,250));
> primaryStage.show();
>
> final Region titleNode = (Region)titledPane.lookup("*.title");
> titleNode.setBackground(new Background(new
> BackgroundFill(Color.GREEN,null,null)));
> }
>
>
>
> On 10/31/18 6:58 PM, Sverre Moe wrote:
> > I am not sure if I have stumbled upon a bug in JavaFX, or perhaps it is
> > simply something I am doing wrong.
> >
> > After setting the TitledPane title background programmatically, then when
> > hovering the background color is reset to the previous value from CSS.
> > I get same behavior in both JavaFX 8 and JavaFX 11.
> >
> > Color color = Color.valueOf("#00ff11");
> > titleNode.setBackground(new Background(new BackgroundFill(color, null,
> > null)));
> >
> > titleNode.setStyle("-fx-background-color:#00ff11;");
> >
> > Setting the style property seems to work, but why doesn't the
> > programmatically approach work?
> >
> >
> https://stackoverflow.com/questions/53083005/javafx-titledpane-changed-title-background-is-reset-on-mouse-entered/
> >
> > /Sverre
>
>
Maybe a TitledPane bug
I am not sure if I have stumbled upon a bug in JavaFX, or perhaps it is
simply something I am doing wrong.
After setting the TitledPane title background programmatically, then when
hovering the background color is reset to the previous value from CSS.
I get same behavior in both JavaFX 8 and JavaFX 11.
Color color = Color.valueOf("#00ff11");
titleNode.setBackground(new Background(new BackgroundFill(color, null,
null)));
titleNode.setStyle("-fx-background-color:#00ff11;");
Setting the style property seems to work, but why doesn't the
programmatically approach work?
https://stackoverflow.com/questions/53083005/javafx-titledpane-changed-title-background-is-reset-on-mouse-entered/
/Sverre
Re: openJFX11 app deployed in browser?
Den tir. 23. okt. 2018 kl. 07:49 skrev Martin Ciglan : > Thank you, I'll take a look. > > If you say it works up to Java 10, how does it look with browser support. > > Are you able to run JavaFX app in latest versions of Chrome or Firefox? > Thanks. > > You don't have to contend with browser support. The application does not run within the browser, but with Java. The Java Web Start is about deployment. You download an JNLP file, which you then execute using the Java Web Start utility installed with the JDK. The application still runs in a java process started by the Java Web Start, after it has downloaded all resources for the application. /Sverre
Re: openJFX11 app deployed in browser?
You also mentioned a "up-to-date" manual. Take a look at javafx-gradle-plugin https://github.com/FibreFoX/javafx-gradle-plugin You can use it to build an JavaFX 8 application with Java Web Start deployment. /Sverre Den man. 22. okt. 2018 kl. 19:20 skrev Sverre Moe : > Yes it still works with Java 8 and up to Java 10. The Java Web Start was > removed in Java 11. > > /Sverre > > > Den man. 22. okt. 2018 kl. 19:15 skrev Martin Ciglan : > >> OK. >> >> Is it still possible to do it with Java8? >> Dňa 22/10/2018 o 19:14 Sverre Moe napísal(a): >> >> Deployment by web browser is no longer possible with Java 11 as they >> removed Java Web Start. >> If you want your JavaFX application to run in a web browser, take a look >> at JPro https://www.jpro.one/. >> >> /Sverre >> >> >> Den man. 22. okt. 2018 kl. 14:53 skrev Martin Ciglan : >> >>> Hi >>> >>> I am developing openJFX11 desktop client application and I would like to >>> deploy it to browser, to be able to have 2 options - thick and thin >>> client. >>> >>> Is there any up-to-date manual how to do it? Many thanks >>> >>> -- >>> >>> Best Regards >>> >>> Martin >>> >>> -- >> >> S pozdravom >> >> Martin >> >>
Re: openJFX11 app deployed in browser?
Yes it still works with Java 8 and up to Java 10. The Java Web Start was removed in Java 11. /Sverre Den man. 22. okt. 2018 kl. 19:15 skrev Martin Ciglan : > OK. > > Is it still possible to do it with Java8? > Dňa 22/10/2018 o 19:14 Sverre Moe napísal(a): > > Deployment by web browser is no longer possible with Java 11 as they > removed Java Web Start. > If you want your JavaFX application to run in a web browser, take a look > at JPro https://www.jpro.one/. > > /Sverre > > > Den man. 22. okt. 2018 kl. 14:53 skrev Martin Ciglan : > >> Hi >> >> I am developing openJFX11 desktop client application and I would like to >> deploy it to browser, to be able to have 2 options - thick and thin >> client. >> >> Is there any up-to-date manual how to do it? Many thanks >> >> -- >> >> Best Regards >> >> Martin >> >> -- > > S pozdravom > > Martin > >
Re: openJFX11 app deployed in browser?
Deployment by web browser is no longer possible with Java 11 as they removed Java Web Start. If you want your JavaFX application to run in a web browser, take a look at JPro https://www.jpro.one/. /Sverre Den man. 22. okt. 2018 kl. 14:53 skrev Martin Ciglan : > Hi > > I am developing openJFX11 desktop client application and I would like to > deploy it to browser, to be able to have 2 options - thick and thin client. > > Is there any up-to-date manual how to do it? Many thanks > > -- > > Best Regards > > Martin > >
Re: Window opening glitch on ubuntu 18.04
Den tor. 11. okt. 2018 kl. 19:32 skrev Sverre Moe : > Den tor. 11. okt. 2018 kl. 19:17 skrev Kevin Rushforth < > kevin.rushfo...@oracle.com>: > >> https://bugs.openjdk.java.net/browse/JDK-8212060 >> >> > I have not noticed this on OpenSUSE Leap 15. The window pop up right in > the center of my screen in an instant. > NVIDIA graphics with NVIDIA proprietary drivers. > > Running my modular test application on Java 11 and JavaFX 11. > https://github.com/DJViking/FxMovies.git > > /Sverre > > I did however noticed for a split second that a dialog I opened was in the upper left corner. It was hardly noticeable. /Sverre
Re: Window opening glitch on ubuntu 18.04
Den tor. 11. okt. 2018 kl. 19:17 skrev Kevin Rushforth < kevin.rushfo...@oracle.com>: > https://bugs.openjdk.java.net/browse/JDK-8212060 > > I have not noticed this on OpenSUSE Leap 15. The window pop up right in the center of my screen in an instant. NVIDIA graphics with NVIDIA proprietary drivers. Running my modular test application on Java 11 and JavaFX 11. https://github.com/DJViking/FxMovies.git /Sverre
Re: Filling the Packager gap
I am having some problems accessing the jpackager from symlinks, seems it cannot find the jdk.packager.jar /usr/bin/jpackager -> /etc/alternatives/jpackager /etc/alternatives/jpackager -> /usr/java/jpackager/jpackager :/ # jpackager --help Error occurred during initialization of boot layer java.lang.module.FindException: Module jdk.packager not found Though accessing the jpackager directly works fine: /usr/java/jpackager/jpackager Any suggestion what the problem might be and how to remedy this? /Sverre
Re: JavaFX 11 on Android
Den tor. 4. okt. 2018 kl. 19:01 skrev Johan Vos : > Hi, > > I worked from the openjfx/develop repository and created a version that > works on Android (will work on iOS soon). > This required some changes, as we're running on top of the Android VM, > which is not really Java (not even close). > > How so? Didn't Google replace their own Java implementation with OpenJDK? That switch was made in Android N two years ago. Maybe I am off base here. I haven't been fiddling around Android much for some years. /Sverre
Re: Later OpenJFX Compatibilty with JDK 11 LTS
Den tor. 27. sep. 2018 kl. 22:38 skrev Jan Tosovsky : > On 2018-09-27 Sverre Moe wrote: > > Den tor. 27. sep. 2018 kl. 20:06 skrev Johan Vos >: > > > > > 3. Stick with an LTS release and get commercial support to get updates > > > > > Thanks. Option 3 looks very interesting. It would allow us to deliver a > > stable application on the current LTS while the same time get updates on > > JavaFX. > > If I understand correctly, there will be 4th option in near future: > 4. Bundle module based app with JDK modules you need > > From that moment you are becoming independent on any future FX and JDK > releases. Especially handy if your app doesn't evolve much and it is > distributed in controlled environment (several users within company). > Unless your app becomes famous, I don't think it will attract attackers to > employ any vulnerabilities found in those older versions as time goes. > > Jan > > Being a SCADA application, keeping it stable and secure is very important, even though our application is not famous or known beyond the industry we deliver it to. /Sverre
Re: Later OpenJFX Compatibilty with JDK 11 LTS
Den tor. 27. sep. 2018 kl. 20:06 skrev Johan Vos : > We would probably target the Java 11 because it is LTS. Changes to JDK will >> be backported up to september 2023 by the community. If we are interested >> in getting updates on OpenJFX also we would then need to always upgrade >> it. >> I reckon there will not be a OpenJFX 11 LTS. >> > > Actually, there is. See > https://gluonhq.com/javafx-11-release-and-support-plans/ for commercial > support for JavaFX 11 LTS. > > Basically, you have 3 options: > 1. Move along with the latest and greatest JavaFX releases (free) > 2. Stick with a given release (free, unsupported) > 3. Stick with an LTS release and get commercial support to get updates > > - Johan > Thanks. Option 3 looks very interesting. It would allow us to deliver a stable application on the current LTS while the same time get updates on JavaFX. I have not seen Oracle offering an JavaFX 11 LTS, just the JDK 11 LTS. Is Gluon the only one with a JavaFX 11 LTS? /Sverre
Later OpenJFX Compatibilty with JDK 11 LTS
On tor. 27. sep. 2018 kl. 18:18 wrote Kevin Rushforth < kevin.rushfo...@oracle.com>: > > I missed seeing the swing exception in your earlier message. Yes, the Swing issue is a known problem in openjfx11, JDK-8210759 [1], and is documented in the release notes [2]. > > It will be fixed in openjfx12 just as soon as I push the fix for JDK-8210092 [3] later today (the review was just finished earlier this morning). This was one of the bugs waiting until the fix requiring JDK 11 for openjfx 12 was pushed. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8210759 > [2] https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md#known-issues > [3] https://bugs.openjdk.java.net/browse/JDK-8210092 > On tor. 27. sep. 2018 kl. 18:50 wrote Kevin Rushforth < kevin.rushfo...@oracle.com>: > > Backporting this fix would mean an openjfx 11.x update release would stop building or running with JDK 10. Not something that would be done lightly, since it would break the "FX N runs with JDK N-1" policy we have been discussing lately. There is an easy workaround for that bug that needs to be done when running "jlink" to create your image. It's documented in the release notes. > > -- Kevin How can we continue to upgrade to newer OpenJFX as time goes by. Will the later OpenJFX 13+ work with JDK 11 or is it just "FX N run JDK N-1" (one version backward support)? We would probably target the Java 11 because it is LTS. Changes to JDK will be backported up to september 2023 by the community. If we are interested in getting updates on OpenJFX also we would then need to always upgrade it. I reckon there will not be a OpenJFX 11 LTS. /Sverre
Re: Filling the Packager gap
Den tor. 27. sep. 2018 kl. 18:50 skrev Kevin Rushforth < kevin.rushfo...@oracle.com>: > You mean openjfx11, not JDK 11, right? Backporting this fix would mean an > openjfx 11.x update release would stop building or running with JDK 10. Not > something that would be done lightly, since it would break the "FX N runs > with JDK N-1" policy we have been discussing lately. There is an easy > workaround for that bug that needs to be done when running "jlink" to > create your image. It's documented in the release notes. > > -- Kevin > Yes, I meant OpenJFX 11. I will take a look at the release notes to find the workaround. /Sverre
Re: Filling the Packager gap
Any chance of getting the fix for JDK-8210759 backported to JDK 11? I remember reading the OpenJDK will be patched up to 2023 (while Oracle JDK will be patched up to 2026). We deliver software that our customers could be running for a decade or more. The LTS is the version we will then target when we move away from Java 8. /Sverre Den tor. 27. sep. 2018 kl. 18:18 skrev Kevin Rushforth < kevin.rushfo...@oracle.com>: > I missed seeing the swing exception in your earlier message. Yes, the > Swing issue is a known problem in openjfx11, JDK-8210759 [1], and is > documented in the release notes [2]. > > It will be fixed in openjfx12 just as soon as I push the fix for > JDK-8210092 [3] later today (the review was just finished earlier this > morning). This was one of the bugs waiting until the fix requiring JDK 11 > for openjfx 12 was pushed. > > As for your other question, yes, if you add the javafx.* modules to your > Java runtime image, then that runtime image contains the javafx.* modules. > If your application were modularized, then the Java runtime image would > contain your application, too. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8210759 > [2] > https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md#known-issues > [3] https://bugs.openjdk.java.net/browse/JDK-8210092 > > > On 9/27/2018 9:03 AM, Sverre Moe wrote: > > Without the reliance on javafx-swing I was able to create an image, > package and execute my test application. > Is the Swing problem a known bug in JavaFX 11? > > The jlink runtime image I reckon now also contains the JavaFX modules? > Seems unnecessary when they already are dependencies. > > /Sverre > > Den tor. 27. sep. 2018 kl. 10:42 skrev Sverre Moe : > >> Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth < >> kevin.rushfo...@oracle.com>: >> >>> No, jlink won't link in a non-modular application. So the steps are: >>> >>> 1) Run jlink to create a Java runtime image, possibly stripped down, and >>> include the javafx.* modules you need >>> 2) Run jpackager to package your non-modular application with the above >>> Java runtime image. >>> >>> -- Kevin >>> >> >> So we have to create the image with the jlink first before we use >> jpackager, and we have to link in with the javafx modules. We cannot use >> the javafx dependencies in the project? >> >> jlink --add-modules=ALL-SYSTEM --output image >> Error: Module ALL-SYSTEM not found >> >> The just to make sure we have everything we need I add the actual modules >> jlink --add-modules=java.base --add-modules=java.desktop >> --add-modules=java.net.http --add-modules=java.xml >> --add-modules=java.prefs --add-modules=java.logging --output image >> >> Linking in with the JavaFX jmods from Gluon: >> jlink --add-modules=java.base --add-modules=java.desktop >> --add-modules=java.net.http --add-modules=java.xml >> --add-modules=java.prefs --add-modules=java.logging --module-path >> /usr/java/javafx-jmods-11/ --add-modules=javafx.base >> --add-modules=javafx.controls --add-modules=javafx.fxml >> --add-modules=javafx.graphics --add-modules=javafx.web >> --add-modules=javafx.media --add-modules=javafx.swing --output image >> >> I managed to build our Java 8 project with Java 11, using the JavaFX >> dependencies. >> Then using jpackager with the runtime image from jlink >> /usr/java/jpackager/jpackager create-installer --input >> build/distributions/application-1.0.0-SNAPSHOT/lib/ --output outputDir >> --runtime-image image/ --verbose --echo-mode --main-jar >> application-1.0.0-SNAPSHOT.jar >> >> Running the application image from jpackager >> First try: >> I thought I had added all necessary modules to the runtime image, but I >> needed one more, java.management. >> >> Second try: >> InteropFactory: cannot load >> com.sun.javafx.embed.swing.newimpl.InteropFactoryN >> Exception in thread "GUIBuilderWorker" java.lang.IllegalAccessError: >> class com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module >> javafx.swing) cannot access class sun.swing.JLightweightFrame (in module >> java.desktop) because module java.desktop does not export sun.swing to >> module javafx.swing >>at >> javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.(SwingNodeInteropO.java:71) >>at >> javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42) >>at >> javafx.swing/javafx.embed.swing.SwingNode.(SwingNode.java:271) >>at no.company.application.fx.MySwingComponent.initNode( >> MySwingComponent.java:155) >> >> The module java.desktop should include the AWT/Swing. >> >> At least I now have been able to create an native application using both >> jlink and the new jpackager. >> >> /Sverre >> > >
Re: Filling the Packager gap
Without the reliance on javafx-swing I was able to create an image, package and execute my test application. Is the Swing problem a known bug in JavaFX 11? The jlink runtime image I reckon now also contains the JavaFX modules? Seems unnecessary when they already are dependencies. /Sverre Den tor. 27. sep. 2018 kl. 10:42 skrev Sverre Moe : > Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth < > kevin.rushfo...@oracle.com>: > >> No, jlink won't link in a non-modular application. So the steps are: >> >> 1) Run jlink to create a Java runtime image, possibly stripped down, and >> include the javafx.* modules you need >> 2) Run jpackager to package your non-modular application with the above >> Java runtime image. >> >> -- Kevin >> > > So we have to create the image with the jlink first before we use > jpackager, and we have to link in with the javafx modules. We cannot use > the javafx dependencies in the project? > > jlink --add-modules=ALL-SYSTEM --output image > Error: Module ALL-SYSTEM not found > > The just to make sure we have everything we need I add the actual modules > jlink --add-modules=java.base --add-modules=java.desktop > --add-modules=java.net.http --add-modules=java.xml > --add-modules=java.prefs --add-modules=java.logging --output image > > Linking in with the JavaFX jmods from Gluon: > jlink --add-modules=java.base --add-modules=java.desktop > --add-modules=java.net.http --add-modules=java.xml > --add-modules=java.prefs --add-modules=java.logging --module-path > /usr/java/javafx-jmods-11/ --add-modules=javafx.base > --add-modules=javafx.controls --add-modules=javafx.fxml > --add-modules=javafx.graphics --add-modules=javafx.web > --add-modules=javafx.media --add-modules=javafx.swing --output image > > I managed to build our Java 8 project with Java 11, using the JavaFX > dependencies. > Then using jpackager with the runtime image from jlink > /usr/java/jpackager/jpackager create-installer --input > build/distributions/application-1.0.0-SNAPSHOT/lib/ --output outputDir > --runtime-image image/ --verbose --echo-mode --main-jar > application-1.0.0-SNAPSHOT.jar > > Running the application image from jpackager > First try: > I thought I had added all necessary modules to the runtime image, but I > needed one more, java.management. > > Second try: > InteropFactory: cannot load > com.sun.javafx.embed.swing.newimpl.InteropFactoryN > Exception in thread "GUIBuilderWorker" java.lang.IllegalAccessError: class > com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module > javafx.swing) cannot access class sun.swing.JLightweightFrame (in module > java.desktop) because module java.desktop does not export sun.swing to > module javafx.swing >at > javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.(SwingNodeInteropO.java:71) > >at > javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42) > >at > javafx.swing/javafx.embed.swing.SwingNode.(SwingNode.java:271) >at no.company.application.fx.MySwingComponent.initNode( > MySwingComponent.java:155) > > The module java.desktop should include the AWT/Swing. > > At least I now have been able to create an native application using both > jlink and the new jpackager. > > /Sverre >
Re: Filling the Packager gap
Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth < kevin.rushfo...@oracle.com>: > No, jlink won't link in a non-modular application. So the steps are: > > 1) Run jlink to create a Java runtime image, possibly stripped down, and > include the javafx.* modules you need > 2) Run jpackager to package your non-modular application with the above > Java runtime image. > > -- Kevin > So we have to create the image with the jlink first before we use jpackager, and we have to link in with the javafx modules. We cannot use the javafx dependencies in the project? jlink --add-modules=ALL-SYSTEM --output image Error: Module ALL-SYSTEM not found The just to make sure we have everything we need I add the actual modules jlink --add-modules=java.base --add-modules=java.desktop --add-modules=java.net.http --add-modules=java.xml --add-modules=java.prefs --add-modules=java.logging --output image Linking in with the JavaFX jmods from Gluon: jlink --add-modules=java.base --add-modules=java.desktop --add-modules=java.net.http --add-modules=java.xml --add-modules=java.prefs --add-modules=java.logging --module-path /usr/java/javafx-jmods-11/ --add-modules=javafx.base --add-modules=javafx.controls --add-modules=javafx.fxml --add-modules=javafx.graphics --add-modules=javafx.web --add-modules=javafx.media --add-modules=javafx.swing --output image I managed to build our Java 8 project with Java 11, using the JavaFX dependencies. Then using jpackager with the runtime image from jlink /usr/java/jpackager/jpackager create-installer --input build/distributions/application-1.0.0-SNAPSHOT/lib/ --output outputDir --runtime-image image/ --verbose --echo-mode --main-jar application-1.0.0-SNAPSHOT.jar Running the application image from jpackager First try: I thought I had added all necessary modules to the runtime image, but I needed one more, java.management. Second try: InteropFactory: cannot load com.sun.javafx.embed.swing.newimpl.InteropFactoryN Exception in thread "GUIBuilderWorker" java.lang.IllegalAccessError: class com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module javafx.swing) cannot access class sun.swing.JLightweightFrame (in module java.desktop) because module java.desktop does not export sun.swing to module javafx.swing at javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.(SwingNodeInteropO.java:71) at javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42) at javafx.swing/javafx.embed.swing.SwingNode.(SwingNode.java:271) at no.company.application.fx.MySwingComponent.initNode( MySwingComponent.java:155) The module java.desktop should include the AWT/Swing. At least I now have been able to create an native application using both jlink and the new jpackager. /Sverre
Re: Filling the Packager gap
I have tried this jpackager a bit. It is working fine packaging a Java modular project. However it fails to package a none modular project. I modified my project and removed the modularization and tried again to see if it would work to package our legacy Java 8 project (though now built with JDK 11 and with dependencies on openjfx 11). I was under the impression that the jpackager should also work to package non-modular projects. The Gradle distribution task produces an tar archive with all the dependencies and my own JAR, which I am using as input to the jpackager. This produces the RPM for the modular project: sverre@mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib> ~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir --verbose --echo-mode --module-path . --module no.smeaworks.movies/no.smeaworks.movies.MoviesApplication Using the jpackager to package non modular project: sverre@mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT> ~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output outputDir --verbose --echo-mode --class no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar ECHO-MODE: Running [rpmbuild, --version] "Adding modules: [] to runtime image." ECHO-MODE: Running jlink [ --output = /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime --module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods] --add-modules = [] --limit-modules = [] --exclude-files = .*\.diz --strip-native-commands = false ] /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException: jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing for java.base module Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use them to customize package. Exception in thread "main" jdk.packager.internal.PackagerException: Error: Bundler "RPM Bundle" (rpm) failed to produce a bundle. at jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642) at jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582) at jdk.packager/jdk.packager.Main.run(Main.java:71) at jdk.packager/jdk.packager.Main.main(Main.java:47) Is my presumption wrong that it should package also non modular projects, or am I missing some runtime flags to jpackager? Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I reckon that Gluon has yet to modularize SceneBuilder? Can you provide some insight how you use jpackage to build the project? I could not find anything on it in the Gluon SceneBuilder GitHub repository. /Sverre Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos : > Hi, > > As promised, we looked into an interim solution for the packager-gap. Work > for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. > We backported the required changes to an OpenJDK 11 mirror: > https://github.com/johanvos/openjdk-mobile11/tree/packager > > With this, we created modified OpenJDK 11 builds that contain the packager > (wrapper/exe + module including native library). They can be downloaded and > tested/used at > > http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip > > For Windows, you have to unzip the bundle in the same directory as the JDK, > as the packager wrapper expect to find the java binary at the same level. > > Note that these are not products. We use them internally to create > installers (e.g. we're using them for Scene Builder 11 and that works > fine), and they do what we expect them to do, but there are no guarantees > of course so at least for now I recommend using them in development only > (or even better, look at the changes and contribute to > https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport) > > - Johan >
Re: Cross-platform JavaFX 11 deployment
An all-in-one solution does exist when using OpenJFX as an SDK instead as
dependencies from Maven/Gradle.
There was a discussion about empty JARs here on the mailingslist. A problem
it seemed to be with Gradle and Eclipse
The Gradle build instruction for Java 11 suggest setting platform as a
classifier, thus taking only the one from the platform.
compile "org.openjfx:javafx-base:11:${platform}"
compile group: "org.openjfx", name: "javafx-base", version: "11",
classifier: platform
https://openjfx.io/openjfx-docs/#gradle
Den tor. 20. sep. 2018 kl. 16:20 skrev Geir Helleloid <
geir.hellel...@gmail.com>:
> I am working on moving my company's codebase from Java 8 to Java 11.
> Our build/deployment pipeline uses Maven, Jenkins, an internal Nexus
> repository, and custom deployment code. We deploy our software to
> multiple platforms (Linux, Windows, and Mac).
>
> I am wondering how to handle the JavaFX 11 dependencies for
> cross-platform deployment. I cannot just declare a dependency on (for
> example) org.openjfx:javafx-graphics:11 in our poms; the Jenkins build
> will only pull in the platform-specific
> org.openjfx:javafx-graphics:11:linux dependency, and deployment from
> Nexus to Windows or Mac will not include
> org.openjfx:javafx-graphics:11:win or
> org.openjfx:javafx-graphics:11:mac.
>
> I could explicitly declare org.openjfx:javafx-graphics:11:linux,
> org.openjfx:javafx-graphics:11:win, AND
> org.openjfx:javafx-graphics:11:mac as dependencies in our poms. Then
> all three dependencies would be deployed to every platform, but JavaFX
> would use the appropriate one at runtime. Not only is this clunky, but
> I think(?) that it fails if we switch to using the module path instead
> of the classpath, since there will be split/overlapping packages. That
> suggests that our custom deployment code needs special handling to
> only deploy the correct JavaFX artifacts for the target platform (or
> to set up the classpath to only include the correct JavaFX artifacts).
> Perhaps this is avoidable by building an uber-jar of JavaFX
> dependencies with the maven-shade-plugin, although I believe the
> maven-shade-plugin will at least spit out a lot of warnings about the
> overlapping packages.
>
> I think one solution to all of this is for OpenJFX is to provide
> org.openjfx:javafx-{name}:11:all artifacts that contain all the code,
> include the platform-specific code for each platform, but those do not
> currently exist.
>
> I would love to hear how other people are handling this situation. Am
> I misunderstanding the situation? Is there a good (obvious or
> non-obvious!) solution that I'm missing? Is there something about this
> scenario that is atypical? (My guess is that this is a very typical
> scenario.)
>
> Thanks,
> Geir Helleloid
>
Re: JavaFX 11 is released
Thanks for the clarification. I tried to read the GPLv2-CE license, but it gave me a headache. /Sverre Den ons. 19. sep. 2018 kl. 14:51 skrev Kevin Rushforth < kevin.rushfo...@oracle.com>: > While this is not meant to be legal advice... The purpose of the > Classpath exception to GPL v2 [1], both for the JDK itself and for > JavaFX, is to allow applications to use it without requiring that the > application itself be licensed under GPL nor requiring that the source > for the application be provided. This applies whether you use OpenJDK 11 > + OpenJFX 11 or Oracle JDK 11 + OpenJFX 11. > > -- Kevin > > [1] http://openjdk.java.net/legal/gplv2+ce.html > > > On 9/19/2018 12:22 AM, Sverre Moe wrote: > > Great work with JavaFX 11. Looking forward to trying it out. > > > > About license for OpenJDK and OpenJFX: > > > > Given that OpenJDK has a GPLv2-CE license, is it possible to use it > > with a commercial application, when bundling with a native runtime, or > > do we need a commercial license from Oracle? We will not be providing > > the source code for our application which is required when using > > software with GPL. > > > > We deliver both software and hardware to our customers. The server > > hardware running SUSE Linux Enterprise Server, which provides the > > OpenJDK builds, comes preinstalled with our applications. SLES 15.0 > > has the OpenJDK 10 build, but I reckon later SP will probably provide > > OpenJDK 11. We pay for SLES and are getting LTSS updates from SUSE > > which includes the OpenJDK. > > > > Given that Oracle JDK which we have used up to now to build our > > application cannot any longer be used in production without license > > from Oracle, we then would either need a license or use the OpenJDK to > > build and deliver with out application. Using the OpenJDK I am not > > sure we can because of the GPLv2 license it is under. > > > > I guess it would not be an issue if we did not bundle the JRE runtime, > > but required the client computer to have it installed, like we do > > today when using Java Web Start. However with the removal of Java Web > > Start we are looking into creating native packages for Linux, Windows > > and Mac. > > > > When it comes to third party Java libraries we have been carefully to > > only use those which is possible in a commercial application, like > > Apache, BSD and LGPL, such as JFXtras (BSD License 2.0), Medusa > > (Apache License v2.0) and JFreechart-FX (LGPL 2.1). > > Now that we will provide JavaFX in the same way as a OpenJFX > > dependency I have the same concern with it as I do with OpenJDK if it > > also is under GPLv2. > > > > /Sverre > >
Re: JavaFX 11 is released
Great work with JavaFX 11. Looking forward to trying it out. About license for OpenJDK and OpenJFX: Given that OpenJDK has a GPLv2-CE license, is it possible to use it with a commercial application, when bundling with a native runtime, or do we need a commercial license from Oracle? We will not be providing the source code for our application which is required when using software with GPL. We deliver both software and hardware to our customers. The server hardware running SUSE Linux Enterprise Server, which provides the OpenJDK builds, comes preinstalled with our applications. SLES 15.0 has the OpenJDK 10 build, but I reckon later SP will probably provide OpenJDK 11. We pay for SLES and are getting LTSS updates from SUSE which includes the OpenJDK. Given that Oracle JDK which we have used up to now to build our application cannot any longer be used in production without license from Oracle, we then would either need a license or use the OpenJDK to build and deliver with out application. Using the OpenJDK I am not sure we can because of the GPLv2 license it is under. I guess it would not be an issue if we did not bundle the JRE runtime, but required the client computer to have it installed, like we do today when using Java Web Start. However with the removal of Java Web Start we are looking into creating native packages for Linux, Windows and Mac. When it comes to third party Java libraries we have been carefully to only use those which is possible in a commercial application, like Apache, BSD and LGPL, such as JFXtras (BSD License 2.0), Medusa (Apache License v2.0) and JFreechart-FX (LGPL 2.1). Now that we will provide JavaFX in the same way as a OpenJFX dependency I have the same concern with it as I do with OpenJDK if it also is under GPLv2. /Sverre
Re: OpenJFX status update
> > The javapackager tool and associated jdk.packager and > jdk.packager.services modules have been removed from the JDK along with > JavaFX. They are not part of the standalone JavaFX builds. > > -- Kevin > > What options are there if one relies on the javapackager to create native runtime images and native package installers? We cannot then upgrade to Java 11 since it has been removed. Neither can we use jlink instead since our application is not yet modularized. Though jlink does not create the There is a draft for a new jpackager tool, but when it will be ready seems to be undetermined. http://openjdk.java.net/jeps/8200758 Have anyone tried to build the javapackager code with OpenJDK 11 and create a javapackager executable file? It could be used as a standalone tool until the new jpackager is ready. /Sverre
Re: JavaFX 11 snapshots in maven sonatype
I thought I replied to the list, and not just you. Probably easier to use the module name as artifactId, but it seems odd though and stands out against all the rest of dependencies naming using a dash delimiter. Den tor. 5. jul. 2018, 19:02 skrev Johan Vos : > The name is the same name as the module (in module-info.java). > I'm very open to discuss this though, so if you want to start a > discussion, send it to the list? I personally have no real preference for > naming, but it's better to change the name now instead of next year :) > > - Johan > > On Thu, Jul 5, 2018 at 6:27 PM Sverre Moe wrote: > >> Great work. >> >> One oddity. Shouldn't artifactId be javafx-controls, instead of >> javafx.controls? >> Never seen any dependencies that used punctuation as delimiter in >> artifactId. >> >> /Sverre >> >> Den tor. 5. jul. 2018 kl. 11:04 skrev Johan Vos : >> >>> A first batch of snapshots for the JavaFX 11 modules is now in the maven >>> sonatype snapshot repository (see >>> https://oss.sonatype.org/content/repositories/snapshots/org/openjfx/ >>> although >>> you probably don't want to work with these artifacts directly but use >>> build >>> tools like maven or gradle to do that) >>> >>> This is work based on the not-yet-merged PR#83: >>> https://github.com/javafxports/openjdk-jfx/pull/83 >>> >>> Basically, you need to specify which modules you need (transitive >>> dependency management will be handled by maven as the modules contain a >>> pom.xml with the same dependencies as the module-info.java), e.g. >>> >>> >>> >>> org.openjfx >>> javafx.controls >>> 11.0.0-SNAPSHOT >>> >>> >>> >>> I have a few samples that show how you can use those artifacts in your >>> maven project: >>> https://github.com/johanvos/javafx11samples (note that this is a >>> temporary >>> repository) >>> the topics/javafx3d directory contains a number of standalone samples >>> that >>> can be executed via >>> mvn clean install exec:java >>> >>> Note that some of the samples create a build.gradle as well, but I never >>> managed to get gradle working with the combination of classifiers and >>> SNAPSHOT versions (it's actually the reason why I went back from gradle >>> to >>> maven in other projects -- e.g. dl4j related). >>> >>> If someone else can somehow fix the build.gradle, that would be great of >>> course. >>> >>> Before PR#83 is merged, it would be nice to have a few reports from >>> people >>> using the snapshots. >>> >>> - Johan >>> >>
Re: Support additional video codec and container format
I wanted to revive this discussion when I saw Java 9 has gotten
upgraded GStreamer in JEP-257.
Also Java 11 has an upgrade to GStreamer 1.14
https://bugs.openjdk.java.net/browse/JDK-8199527
The formats supported are very few:
https://docs.oracle.com/javase/10/docs/api/javafx/scene/media/package-summary.html
What does it take to implement support for these Video formats?
It cannot be a license problem because Java 10 already has x264 as the
Only supported video format.
Is there any work scheduled to improve on this in JavaFX?
Den søn. 10. sep. 2017 kl. 20:49 skrev Sverre Moe :
>
> Some very old issues for this kind of change
> https://bugs.openjdk.java.net/browse/JDK-8091063
> https://bugs.openjdk.java.net/browse/JDK-8091656
>
> One new comment on the latter issue suggesting to add new formats like
> "Ogg/{Vorbis,Theora}, flac, matroska (MKV), Opus, VP8, 3GPP, GSM"
>
> This would be great to have on JavaFX. I seriously hope they would add it for
> Java 10 at least, or a later Java 9 update.
>
>
>>
>> Date: Fri, 8 Sep 2017 20:51:06 +1000
>> From: John-Val Rose
>> To: Sverre Moe
>> Cc: openjfx-dev@openjdk.java.net
>> Subject: Re: Support additional video codec and container format
>> Message-ID: <51d7ca89-1d83-4e0f-a9f8-ef59a00b6...@gmail.com>
>> Content-Type: text/plain; charset=us-ascii
>>
>> +1
>>
>> > On 8 Sep 2017, at 19:05, Sverre Moe wrote:
>> >
>> > Why is JavaFX not supporting open video container and codec?
>> > From Java 9 VP6 is deprecated.
>> >
>> > The only relevant supported coded for JavaFX is H.264/AVC. The only other
>> > alternative is VP6 which has been deprecated in Java 9.
>> >
>> > We cannot use H.264 without paying lisence fee for a commercial
>> > application.
>> >
>> > Support for Ogg Theroa/Vorbis should be considered, at least VP8 and/or VP9
>> > in place for the deprecated VP6. The MediaPlayer for Java 10 has not gotten
>> > any changes either. I reckon it is too late for Java 9 to get new formats.
>
>
Re: JavaFX and it use of GTK3
> > What does GTK have to say for JavaFX (disregard any AWT/Swing and SWT) ? > > FX is not a GTK app from a rendering perspective. > It is used for all needed interaction with the Windowing System Makes sense. For GUI components such as the FileChooser. The FileChooser in JavaFX is using the system GTK theme, regardless of Modena or any other configured styling. > > Does it mean JavaFX supports GTK3 themes? If one have selected a > > desktop GTK theme could it be used in the JavaFX application for > > styling? > No .. and no. I was wondering because I know Eclipse have been effected in the past by my installed GTK themes. To be able to utilize the GTK theme would have helped to keep theme consistent. Since dialogs such as FileChooser are using the GTK theme. > > Has Qt ever been a consideration for JavaFX instead of GTK? > > No. Why not? Would it be difficult to implement an Qt alternative for GTK in Java? If it is even feasible. In effect it means JavaFX will not work on systems that doesn't have GTK installed, though OpenJDK have no install requirement on GTK. I am running KDE which uses Qt, and apart from a very few applications I have very little reliance on GTK.
JavaFX and it use of GTK3
Pardon me for asking this on the dev mailing list, but I wanted to get this directly from the source. I was glad to read that Java had gotten support for GTK3. Prior to this I was oblivious with JavaFX relationship with GTK, apart from the various Gtk-WARNING when starting applications. Then I began to ponder, what does GTK do for JavaFX. What does GTK have to say for JavaFX (disregard any AWT/Swing and SWT) ? The JEP for GTK3 support mentioned the motivation for it: * Active development is on GTK3 and GTK2 may not be available on Linux in the future lifetime of JDK 9/10/11. * Mixing of packages using different GTK versions causes application failures. They mention this problem affects applications when using Eclipse which are SWT-based. I tried running Eclipse with GTK3 enabled without problem. Other than that: Does it provide better graphics with GTK3 Does it provide different visual graphics with GTK3 Does it provide better performance with GTK3 Does it mean JavaFX supports GTK3 themes? If one have selected a desktop GTK theme could it be used in the JavaFX application for styling? Has Qt ever been a consideration for JavaFX instead of GTK?
Re: Removal of apps/scenebuilder from OpenJFX repo
Looks like Gluon has moved SceneBuilder from Bitbucket for GitHub. https://github.com/gluonhq/scenebuilder I like this move. GitHub is much better to work with. Den fre. 27. apr. 2018 kl. 13:31 skrev Sverre Moe : > > I would like to hear from Gluon about their work on SceneBuilder. > Do they have any plans for improve on SceneBuilder, both bug fixed and > new features? > > I guess Gluon only work on their own fork of SceneBuilder, but do they > send changes back to the OpenJFX repository? > > We have migrated our application from Swing to JavaFX and have thus > begun to use SceneBuilder. I therefor hope it will be actively > maintained further. > > How can we the community contribute to the continued development of > SceneBuilder. > Should we work against the OpenJFX SceneBuilder or the Gluon SceneBuilder? > https://bitbucket.org/gluon-oss/scenebuilder > https://github.com/javafxports/openjdk-jfx/tree/develop/apps/scenebuilder > > /Sverre > > > 2018-03-13 22:11 GMT+01:00 Kevin Rushforth : > > That will be a question for Gluon. > > > > -- Kevin > > > > > > > > Michael Paus wrote: > >> > >> How will these changes then be synchronized with the work Gluon is doing > >> for the version > >> distributed by them? Do they work on the same repo? > >> > >> Am 12.03.18 um 23:25 schrieb Kevin Rushforth: > >>> > >>> Hi Florian, > >>> > >>> By way of update, after thinking about this for a week (and getting some > >>> offline feedback), I no longer propose doing this -- at least not for the > >>> short-mid term. I've retargeted this RFE to tbd_major and lowered the > >>> priority to P4. > >>> > >>> Having said that, we don't have any plans to modify SceneBuilder, but > >>> will happily accept contributions. > >>> > >>> -- Kevin > >>> > >>> > >>> Florian Brunner wrote: > >>>> > >>>> OK, this still comes a bit as a surprise as the source code has been > >>>> kept in the repo and was not just provided as a ZIP file. > >>>> > >>>> I'm currently working on a tool based on the SceneBuilder Kit. I needed > >>>> to work on the code a bit and was planning to donate the code back to > >>>> OpenJFX once released, as I was under the impression OpenJFX would serve > >>>> as > >>>> the master / upstream-repo for all SceneBuilder forks. I was also under > >>>> the > >>>> impression that OpenJFX at least would make sure the code works with any > >>>> new > >>>> JDK / JavaFX version and hoped it would get support for new controls, if > >>>> any > >>>> were added to JavaFX. > >>>> > >>>> -Florian > >>>> > >>>> Am Freitag, 2. März 2018, 09:12:15 CET schrieb Kevin Rushforth: > >>>>> > >>>>> I filed the following JBS isuse to remova the SceneBuilder sources from > >>>>> the OpenJFX repo. > >>>>> > >>>>> https://bugs.openjdk.java.net/browse/JDK-8198961 > >>>>> > >>>>> As mentioned in the Description of that issue, the OpenJFX repo > >>>>> contains the source code for a no-longer-maintained version of the > >>>>> SceneBuilder tool. Active development on SceneBuilder in the OpenJFX > >>>>> repo > >>>>> was stopped over three years ago. Since that time, the only changes have > >>>>> been either jigsaw-related changes to keep it buildable and runnable, or > >>>>> global changes that happened to touch some of the files in > >>>>> apps/scenebuilder. > >>>>> > >>>>> A fork of SceneBuilder is maintained by Gluon, so anyone wanting to get > >>>>> the latest SceneBuilder should go there. > >>>>> > >>>>> Before I proceed, I wanted to poll the list to see whether anyone has a > >>>>> concern with this. I don't plan to take any action for at least a week. > >>>>> > >>>>> -- Kevin > >>>>> > >>>>> > >>>> > >>>> > >> > >
Bug in SceneBuilder 9
I think I have found a bug in SceneBuilder 9. I cannot find an existing bug report for this: https://www.oracle.com/search/results/_/N-8d?Ntt=SceneBuilder%20TitledPane&Dy=1&Nty=1&cat=bugs&Nr=106&Ntk=S3 When adding a TitledPane, its default styling is not applied. Within SceneBuilder the TitledPane lacks the border and title styles(background, collapsible arrow). An empty TitledPane shows only the title and nothing more. It looks just like a Label or Text. Running the FXML with an Java 9 application shows the TitledPane as it should be. Where should I submit this bug report? bugreport.java.com, GitHub mirror or with Gluon? /Sverre
JavaFX dialog window size regression
I filed a bug report a while back. Since I didn't have access I could not comment or update in that issue. https://bugs.openjdk.java.net/browse/JDK-8179073 With Java 9, a JavaFX dialogs got tiny and did not size up to its content. This worked fine when I was running JDK 9 build 161, but after JDK 9 build 165 the dialog window did not size up to show any of its content. The code exampled I provided with that bug report still produces a tiny dialog window with both jdk-9.0.4 and jdk-10.0.1 Setting the Dialog size to fixed width/height does not work, but if with setResizable(true) the Dialog gets its full size. It has been a while since I have used Java 9. Today I got the same problem while trying to exit SceneBuilder 9 downloaded from Gluon. I was wondering if I should re-create this bug report on the GitHub OpenJFX repository?
Re: More community participation in JavaFX
>> 2018-02-06 14:29 GMT+01:00 dalibor topic : >>> >>> >>> >>> On 02.02.2018 00:26, Kevin Rushforth wrote: We are specifically looking to discuss ideas around the following areas: * Easing barriers to contribution (e.g., making JavaFX easier to build, better documentation, making it easier to test changes) >>> >>> >>> >>> I'd suggest explicitly asking for feedback from the maintainers of >>> downstream builds, such as >>> >>> https://www.archlinux.org/packages/extra/x86_64/java-openjfx/ >>> https://packages.debian.org/source/sid/openjfx >>> https://admin.fedoraproject.org/pkgdb/package/rpms/openjfx/ >>> https://www.freshports.org/java/openjfx8-devel >>> >>> In the case of the JDK, downstream builders of OpenJDK tend to provide >>> very >>> useful first hand feedback of barriers to building & contribution, and >>> often >>> end up becoming regular contributors themselves, due to the hard, >>> fundamental nature of (build) problems one needs to resolve to be able to >>> provide a working build for one's own operating system. >>> >>> cheers, >>> dalibor topic >> >> >> I wanted to see OpenSUSE among those, but sadly there is no official >> maintainers for OpenJFX there like there are for OpenJDK. >> https://build.opensuse.org/package/show/openSUSE%3AFactory/java-9-openjdk >> >> There is however several users who has built OpenJFX for OpenSUSE: >> https://software.opensuse.org/package/java-1_8_0-openjfx >> >> Sadly though none have tried or provided java-9-openjfx builds at SUSE >> OBS. Perhaps making JavaFX easier to build and provide better >> documentation could remedy that shortcoming. >> I was thinking of trying to build java-9-openjfx on OpenSUSE and SLES. >> If successful perhaps it could be picked up by official SUSE >> maintainers. >> >> /Sverre >> > > 2018-02-06 23:38 GMT+01:00 dalibor topic : > Yeah, there was a bug in the SUSE tracker for it. See > https://bugzilla.opensuse.org/show_bug.cgi?id=991307 for details. ;) > > cheers, > dalibor topic > > Reading the comments there seems it is not an easy feat to build OpenJFX. Also there are some mention of SUSE does not build OpenJDK, but IcedTea which OpenJFX will not build with. Perhaps the solution is to build the "correct" OpenJDK on SUSE, then OpenJFX. Building both OpenJDK and OpenJFX should be so easy that IceadTea no longer would be necessary. /Sverre
Re: More community participation in JavaFX
> Date: Mon, 5 Feb 2018 08:11:05 +0100 > From: Alexander Ny?en > To: Kevin Rushforth > Cc: "openjfx-dev@openjdk.java.net" > Subject: Re: More community participation in JavaFX > Message-ID: <3c5ef409-a1a6-40de-a810-6d8d63fb4...@nyssen.org> > Content-Type: text/plain; charset=utf-8 > > Hi Kevin, > > the issue tracker is usually the first contact point for any future > contributor. Making it publicly accessible would IMHO be an important first > step. Be aware that before being appointed as author, one is not even allowed > to reply to questions related to those issues one has created via the web > interface. In my eyes that?s at least an unnecessary hurdle, maybe even a > deterrent. > > Regards, > Alexander Most definitely. Perhaps by opening up the OpenJDK JIRA issue tracker a bit. I myself have submitted a few bugs, but could not contribute further because I don't have access. I found contribution to Jenkins much easier because it was easy to create a user account on their JIRA issue tracker. Regards, Sverre
Re: javapackager feedback and questions
We are using the javapackager through the gradle/maven javafx plugin, to create: * Executable JAR: When we went from Swing to JavaFX the maven jar plugin could not create an executable JAR capable to start the JavaFX Application. * Native executable bundle: RPM (Linux), EXE (Windows), PKG (Mac) * Java Web Start bundle /Sverre > Date: Thu, 30 Nov 2017 16:16:19 -0800 > From: Kevin Rushforth > To: Michael Hall > Cc: "jdk9-...@openjdk.java.net" , > "openjfx-dev@openjdk.java.net" , Mani > Sarkar > Subject: Re: javapackager feedback and questions > Message-ID: <5a209f53.6080...@oracle.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Michael, > > We realized that the javapackger CLI JEP wasn't quite ready, and was out > of scope for JDK 10 anyway, so we withdrew it in order to file a new JEP > later. > > Related to this, we are soliciting input as to how people are using the > javapackager (see Victor's question below). > > So we'd love to hear how you and others are using it, and for what kind > of applications. > > -- Kevin > > > Michael Hall wrote: > >> On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote: > >> > >> Hi, Mani. > >> > >> Thanks for providing the feedback! > >> We will consider adding more examples and more details in the docs as you > >> proposed(there is an arg named jvmOptions but that's not mentioned in the > >> table). > >> Looks like there is a bug when you specify systemWide=true on the MacOSX > >> in non-gui mode. Can you provide more details about that (like full cmd > >> line)? > >> Actually, if you want you can clone the repo: > >> http://hg.openjdk.java.net/openjfx/10-dev/rt/ > >> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/) > >> and help to improve javapackager. Or you can just create Enhancements for > >> deploy/packager, as it's not always clear what users expect. > >> > >> > > > > Why was JEP 311 [1] Closed/Withdrawn? > > > > [1] http://openjdk.java.net/jeps/311 > > > >
Re: JEP 311: Java Packager API & CLI (Kevin Rushforth)
The preliminary list of new arguments has arguments for DEB, but not RPM. Really hope RPM is not phased out after refactoring arguments for later removal after JDK10. What is the reason for removing support for Java Web Start (JNLP) in the Java Packager? /Sverre > Date: Wed, 18 Oct 2017 16:13:29 -0700 > From: victor.droz...@oracle.com > To: openjfx-dev@openjdk.java.net > Subject: JEP 311: Java Packager API & CLI > Message-ID: <3fc4f584-a9d9-3264-107b-1630d981f...@oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > New JEP Candidate: > > JEP 311: Java Packager API & CLI: http://openjdk.java.net/jeps/311 > Mailing list for further discussion: jdk-...@openjdk.java.net > > --Victor > >
Re: Support additional video codec and container format
Some very old issues for this kind of change
https://bugs.openjdk.java.net/browse/JDK-8091063
https://bugs.openjdk.java.net/browse/JDK-8091656
One new comment on the latter issue suggesting to add new formats like
"Ogg/{Vorbis,Theora}, flac, matroska (MKV), Opus, VP8, 3GPP, GSM"
This would be great to have on JavaFX. I seriously hope they would add it
for Java 10 at least, or a later Java 9 update.
> Date: Fri, 8 Sep 2017 20:51:06 +1000
> From: John-Val Rose
> To: Sverre Moe
> Cc: openjfx-dev@openjdk.java.net
> Subject: Re: Support additional video codec and container format
> Message-ID: <51d7ca89-1d83-4e0f-a9f8-ef59a00b6...@gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> +1
>
> > On 8 Sep 2017, at 19:05, Sverre Moe wrote:
> >
> > Why is JavaFX not supporting open video container and codec?
> > From Java 9 VP6 is deprecated.
> >
> > The only relevant supported coded for JavaFX is H.264/AVC. The only other
> > alternative is VP6 which has been deprecated in Java 9.
> >
> > We cannot use H.264 without paying lisence fee for a commercial
> application.
> >
> > Support for Ogg Theroa/Vorbis should be considered, at least VP8 and/or
> VP9
> > in place for the deprecated VP6. The MediaPlayer for Java 10 has not
> gotten
> > any changes either. I reckon it is too late for Java 9 to get new
> formats.
>
Support additional video codec and container format
Why is JavaFX not supporting open video container and codec? >From Java 9 VP6 is deprecated. The only relevant supported coded for JavaFX is H.264/AVC. The only other alternative is VP6 which has been deprecated in Java 9. We cannot use H.264 without paying lisence fee for a commercial application. Support for Ogg Theroa/Vorbis should be considered, at least VP8 and/or VP9 in place for the deprecated VP6. The MediaPlayer for Java 10 has not gotten any changes either. I reckon it is too late for Java 9 to get new formats.
JDK-8092206 : TabPane renders content of all tabs even only one is active
This bug has Fix Version to 10. Does that mean it will not be fixed on JavaFX 8 or 9? JIRA: https://bugs.openjdk.java.net/browse/JDK-8092206
