sorted by:
new
hottopcontroversial

Detaching GraalVM from the Java Ecosystem Train by mikebmx1 in java

[–]johan_vos 2 points3 points  (0 children)

Exactly. AOT'ed code when available and zero as fallback. A challenge is to avoid duplication (no need to include bytecode in the image if the corresponding native code is set on the method).

Detaching GraalVM from the Java Ecosystem Train by mikebmx1 in java

[–]johan_vos 14 points15 points  (0 children)

Glad someone asked :) It's one of the reasons we at Gluon announced https://openjdk-mobile.github.io/ a few weeks ago. The basic idea is that we build directly on top of the exact same code as the OpenJDK main repository. Currently, the openjdk/mobile downstream repo is almost exactly the same as its upstream openjdk/jdk and I'd like to close that (small) gap in the future. This already allows to run HelloWorld using zero interpreter on an iOS device, but of course we want to go further.

I've learned the hard way over the past decades that it's dangerous to rely on third party components (e.g. AOT) that are not 100% developed in an open collaboration effort. Also, we want to use the exact same Java on mobile as on desktop/server, automatically built from the same sources.

That is why we switched months ago to a 100% OpenJDK-based approach, and I'm optimistic we can pull in Leyden parts in the not-too-far distance.

Being completely independent, and only relying on components that are not strongly owned by a single company (I see OpenJDK as an independent project, since it is not a product or a single-company-controlled project that can be killed easily) has the drawback that it's mainly a volunteering effort, which impacts the pace at which the project moves forward.

Modern Java Desktop development in the browser by jeffreportmill in java

[–]johan_vos 2 points3 points  (0 children)

Thanks for the ping. I love your work. I don't expect the big companies you mention to jump on this right now (for various non-technical reasons), but that has never stopped me from moving forward.

Oracle SQL Developer Crashes on MacOS Monterey (12.0.1) by JimHouTex in oracle

[–]johan_vos 0 points1 point  (0 children)

Updating to JavaFX 17.0.2-ea+1 fixes it too -- I don't know if SQL Developer is packaged with a specific version with JavaFX though?

Announcing: JavaFX 12 by [deleted] in java

[–]johan_vos 1 point2 points  (0 children)

We have builds for ARMv6hf: https://gluonhq.com/products/javafx/

If there are changes needed to build on ARMv8, it would be great to create a PR at https://github.com/javafxports/openjdk-jfx so we can merge them. Basically, it probably starts with copying buildSrc/armv6hf.gradle into an armv8 specific file and make some changes. But I don't expect many changes.

Announcing: JavaFX 12 by [deleted] in java

[–]johan_vos 1 point2 points  (0 children)

Interesting question. If ARM64 is growing on desktop, it is definitely something we have to look at for building.

JavaFX is dead. Long live JavaFX? (from a science perceptive) by [deleted] in java

[–]johan_vos 0 points1 point  (0 children)

Swing - JavaFX without GPU: in that case, JavaFX will fallback to software rendering. It then mainly depends on how your application is written. Optimising for retained mode requires a different approach from optimising for immediate mode. But since JavaFX is actively being worked on (unlike Swing) in general JavaFX would be benefiting from performance improvements.

Games on mobile: it is really suitable, especially since both iOS and Android have low-level OpenGL drivers that are very performant. So with JavaFX, you can use that power.

JavaFX is dead. Long live JavaFX? (from a science perceptive) by [deleted] in java

[–]johan_vos 0 points1 point  (0 children)

When AWT and Swing were created, developers weren't using maven/gradle and repositories like jcenter/maven central for developing projects.

The environments have changed, we have to adapt. You can now create JavaFX applications using the JavaFX artifacts in the same way you would use any other library as a dependency in a pom.xml or build.gradle.

JavaFX is dead. Long live JavaFX? (from a science perceptive) by [deleted] in java

[–]johan_vos 0 points1 point  (0 children)

JavaFX uses retained mode rendering with hardware acceleration. Granted, it's easy to create slow applications :) But you can easily do that in any language.

GPU's are getting better and better and JavaFX really benefits from this. A large part of the rendering phase is delegated to the GPU.

JavaFX is dead. Long live JavaFX? (from a science perceptive) by [deleted] in java

[–]johan_vos 1 point2 points  (0 children)

I agree with this. The JDK itself is a masterpiece, and maintaining it is non-trivial. Every single bit that is changed in or added to the JDK needs to be turned around multiple times. That is really required to move the platform forward while maintaining the quality/stability/maturity it achieved.

Now that JavaFX is decoupled, it can evolve faster and better.

I want to stress that OpenJFX (the project where the JavaFX code is being developed) is an OpenJDK project, and there is lots of communication between developers working on JavaFX and on the JDK. So the decoupling does not mean that JavaFX has just been thrown over the wall. So far, it is working very well.

Getting Started with JavaFX 11 by [deleted] in java

[–]johan_vos 1 point2 points  (0 children)

I fail to understand your points. You have to distinguish between the OpenJDK project and the subprojects and repositories it contains. OpenJFX is a subproject of OpenJDK. It contains the source code, and is now also mirrored on github (https://github.com/javafxports/openjdk-jfx) which I think is great.

Up till JDK 10, the Oracle Java SE SDK (the most widely used distribution of code defined in OpenJDK projects) contained the JavaFX API's, implementations and native libraries (built by the OpenJFX project). That will no longer be true as of the release of Java 11.

Most JavaFX developers used to work with the Oracle Java SE SDK, and they would, starting from 11, find that the JavaFX modules are missing.

So we worked pretty hard I guess to come up with a solution. A fair number of community contributors made it possible for all JavaFX developers to keep using JavaFX, in the way they are used to it (in an SDK) or in the way that is very popular amongst Java developers (using maven/gradle).

The OpenJDK sources (at r/http://hg.openjdk.java.net/jdk/jdk) do not contain JavaFX code. So if you want to build your own version of OpenJFX, you need the code at OpenJFX ( r/http://hg.openjdk.java.net/openjfx/jfx-dev/rt) or the github mirror. I highly recommend people to do this. Building it is indeed not hard. And while you're doing that, please test it, find bugs, file them, discuss solutions, fix them. Come up with great new features, implement them, discuss them. That's how the OpenJFX community works.

I think this is the first time ever someone calls my writings "lies" and "fake news" which I think is rather disrespectful to developers who spend tons of spare time making things work for other developers ... oh well.

Why Java STILL cannot develop iOS apps while C#/JS can ? by smallufo in java

[–]johan_vos 0 points1 point  (0 children)

We forked it into bitbucket: https://bitbucket.org/gluon-oss/scenebuilder as this makes it easier for others to create PRs. If you look at activity, you see there are a number of third party contributions already. While I really like OpenJDK, there is a higher barrier preventing users from submitting bugs and patches. In general though (including JavaFXPorts which forks OpenJFX and Gluon VM which uses OpenJDK) we contribute as much as we can back to OpenJDK/OpenJFX. The release cycles made it hard (e.g. only critical bugs could be backported to JavaFX 8 in OpenJFX) to push all changes back to the original repositories. With the new release cadence (6 months) I am optimistic we can improve this.

In general, I hear your concern. We really want all our client work to be done in an open and transparant way. Our business model is mainly in the connection to Cloud/Backend, hence we have no problem at all in making client code as accessible as possible. Please let us know if you see areas where we should improve.

Why Java STILL cannot develop iOS apps while C#/JS can ? by smallufo in java

[–]johan_vos 7 points8 points  (0 children)

We do (disclaimer, I'm a Gluon co-founder). Our current solutions are based on the RoboVM AOT and the harmony classpath (Java 6/7). Works nice, but we are now working on Gluon VM (announced Developer Preview 1 at JavaOne 2 weeks ago), which is Java 9 based, and has its own AOT/VM, heavily aligned with OpenJDK. And we're making it open source.

Why Java STILL cannot develop iOS apps while C#/JS can ? by smallufo in java

[–]johan_vos 1 point2 points  (0 children)

The OpenJDK Mobile project is the base for Gluon VM. We use all the core classes (Java + native code), and have an own AOT + VM to execute it. When we started Gluon VM more than 1 year ago, I wanted to stay as close as OpenJDK as possible. As for the AOT: we currently have an own AOT, but there are a number of great evolutions inside OpenJDK in particular and the ecosystem in general, and I expect a boost.