Historically, there was a no-go for default interface methods in the 8-tree
a long time ago, as those would break the android port (thanks Stephen
Northover for imposing that).
Hence, I was happy with the restrictions not to use new language features.
Android is a special case though, as that is th
Hi Ty,
Apart om jdk.jlink, who else is exporting jdk.tools.jlink.internal.packager
?
If that is the case, there must be something wrong.
The 12-sandbox version also exports that package:
http://hg.openjdk.java.net/jdk/sandbox/file/6972c0e75e23/src/jdk.jlink/share/classes/module-info.java
- Johan
On 9/19/18 3:55 AM, Johan Vos wrote:
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-mobile1
>
> but wouldn't go out of our way to stop it from running on JDK N-2
> unless/until there was a feature or bug fix that required something from
> JDK N-1.
>
I would be surprised if there will be a release without a language change,
as I don't recall any release without one, and Amber (and friends
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
On 9/26/20
Does jlink work for non-modular stuff? The last time I tried it complained to
me too. I guess it gives up because it can’t automatically figure out module
dependencies. The error below shows jlink is what is complaining.
Scott
> On Sep 26, 2018, at 3:44 PM, Kevin Rushforth
> wrote:
>
> j
Ty Young wrote:
And it's only going to get worse as time goes on. Would it not be
possible to support up until the last JDK LTS(Starting at 11) release
for building JavaFX? I feel like maybe that would be more reasonable.
FWIW, I would prefer it if jfx only followed the LTS jdk releases.
I agree with the idea of not actively breaking things if not needed, on the
other hand I like predictability (instead of remembering that JavaFX 19
works with Java 17 but JavaFX 20 doens't work with Java 18 etc).
But from a pragmatic point, I'm ok with it.
The main difficulty in the whole minimum
jpackager should work for non-modular applications as well as modular
ones. We've tested it for simple applications with or without FX. In the
latter case, the testing I've done has been done by first using jlink to
create a Java runtime with the needed JDK modules + the openjfx11
modules (usin
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
Is it possible to change the following page either to download the files
over HTTPS or provide their checksums on an HTTPS page (as Oracle does
for the JDK)?
JavaFX - Gluon
https://gluonhq.com/products/javafx/
The page redirects to an insecure HTTP connection when downloading the
Linux fi
So I think we should official define the JDK N-1 and JDK N but don't pro
actively break JDK N-2, ... if there's no real value.
Perhaps your suggestion is a good compromise: if we choose this
approach, then we would still claim support for only JDK N-1 and JDK N,
but wouldn't go out of our w
Hello Kevin,
I already use Platform.setImplicitExit(false) at startup so this can't be the
problem. All SWT FXCanvas are not closed (at least at startup).
Could it be that the initialisation of the SWT FXCanvas is different and could
cause the problem.
At the moment I use as java arguments:
I'm' not aware of anything that intentionally changed between FX in JDK
8 and FX 11, but my guess is that the FX runtime is being shutdown after
your first FXCanvas exits. Try making the following call (only needed
one time) before creating your first FXCanvas:
Platform.setImplicitExit(fal
First of all congratulation to the new release and thank you for the hard work
on JavaFX.
I have a problem with JavaFX which in my case is embedded in a Rich Client
Platform of Eclipse.
I integrated several SWT FXCanvas (some with SwingNode panels as a SWT_AWT
replacement) into my app.
T
On 9/22/18 9:01 AM, Kevin Rushforth wrote:
I have never seen this problem. As for including src.zip in the "lib"
directory, that matches what the JDK has done for years. It may have
something to do with how you are building your JDK?
No, I compile JavaFX the same everytime - remove -Werror
17 matches
Mail list logo
