Announcement

Collapse
No announcement yet.

Java 17 / OpenJDK 17 Hits GA With Maturing Vector API, Removal Planned For Applet API

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • krzyzowiec
    replied
    Originally posted by Leprechaunius View Post
    The point is jfx is like a web browser - you can even use CSS to style the UI components. Plus yes, it has the embedded WebView component so you can just embed a full Webkit, display a webpage and interact via JS. JFX is much more easier to port due to simpler architecture. Let me just quote Oracle, as they summed it up nicely in the docs:
    JavaFX is not a browser rendering engine though, it is a UI toolkit. Gnome/GTK uses CSS for styling too, but that's only because CSS is the best standard we have so far for UIs.

    Leave a comment:


  • Delgarde
    replied
    Originally posted by mdedetrich View Post
    Yup, or basically sealed in scala (i.e. sealed abstract class or sealed trait) so you can get proper exhaustive checking in pattern matching
    Yeah, for all that I'm one of those still stuck on Java 8, that's something I'm really looking forward to. They've been slowly adding the building blocks (e.g. named instanceof, sealed classes, switch expressions) over the last few releases, and full pattern matching on sealed classes will be the capstone of that. Not a feature I'd use every day, but incredibly useful for certain use cases...

    Leave a comment:


  • Leprechaunius
    replied
    Originally posted by krzyzowiec View Post

    I think he may be confusing the fact that it has a webview component with that being the basis of the toolkit, which it is not.
    I'm not confusing that, although now that I read it back I could have made my point clearer, sorry for that.

    The point is jfx is like a web browser - you can even use CSS to style the UI components. Plus yes, it has the embedded WebView component so you can just embed a full Webkit, display a webpage and interact via JS. JFX is much more easier to port due to simpler architecture. Let me just quote Oracle, as they summed it up nicely in the docs:

    "The Glass toolkit is also responsible for managing the event queue. Unlike the Abstract Window Toolkit (AWT), which manages its own event queue, the Glass toolkit uses the native operating system's event queue functionality to schedule thread usage. Also unlike AWT, the Glass toolkit runs on the same thread as the JavaFX application. In AWT, the native half of AWT runs on one thread and the Java level runs on another thread. This introduces a lot of issues, many of which are resolved in JavaFX by using the single JavaFX application thread approach."


    Btw also part of this discussion - all of the java UI toolkits use GTK3 as a native backend in linux. This was always the case, although previously we had just GTK2 support and then it became a fallback path. https://openjdk.java.net/jeps/283

    gstreamer is also used for media playback if anyone is wondering.

    Leave a comment:


  • Delgarde
    replied
    Originally posted by krzyzowiec View Post

    I think he may be confusing the fact that it has a webview component with that being the basis of the toolkit, which it is not.
    Yeah, JavaFX has nothing to do with the web. I've never used it personally, but I understand that it originally started out as a new API built on top of Swing widgets... basically a third attempt to get Java UI right, after the original AWT and then Swing.

    Leave a comment:


  • krzyzowiec
    replied
    Originally posted by mazumoto View Post

    Are you sure JavaFX (2+) has anything to do with Webkit or even a Browser? I don't think Webkit is written in Java nor that it'd fit in those few small Jars you as dependencies to use it ...
    I think he may be confusing the fact that it has a webview component with that being the basis of the toolkit, which it is not.

    Leave a comment:


  • mazumoto
    replied
    Originally posted by Leprechaunius View Post
    The idea is to first try to migrate the JavaFX toolkit as that is basically just an embedded web browser / webkit in a window, so probably less effort.
    Are you sure JavaFX (2+) has anything to do with Webkit or even a Browser? I don't think Webkit is written in Java nor that it'd fit in those few small Jars you as dependencies to use it ...

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by GreenToad View Post

    Actually that's not it, java always had "final" classes that are exactly what c# calls "sealed" classes. What Java calls "sealed" classes c# will be getting as "closed" types

    https://github.com/dotnet/csharplang/issues/485
    Yup, or basically sealed in scala (i.e. sealed abstract class or sealed trait) so you can get proper exhaustive checking in pattern matching

    Leave a comment:


  • Leprechaunius
    replied
    There's some misinformation in this thread. Let me make this right from a position of a long time Java dev.

    First of all - no, java does not support wayland yet. There was a very recent push on this front by the people from Jetbrains, because they really need it for their IDEs. There's a thread on the mailing list, (google for it, I'm on my vacation with no computer in sight, typing on a phone). The idea is to first try to migrate the JavaFX toolkit as that is basically just an embedded web browser / webkit in a window, so probably less effort. Swing is entirely different beast and will come probably later. Btw Swing is actually based on AWT under the hood, so no point in trying to distinguish them here.
    The main concern in porting jfx is caused by so called Robot classes that provide utilities to simulate input and interaction to facilitate automated testing and whatnot. This as was said is not so straightforward to make "WORE".

    Second - sealed classes are in no way about making them "final", java had that for years. The usefulness of this feature is still debated by top architects, but the idea is if you're writing a framework, you can mark some of the classes as sealed to prevent downstream of extending them by subclassing, while allowing you to fully use inheritance in your code. This gives you much more fine grained control over who can extend your code and how.

    And third - on the topic of adoption. In my company we currently use jdk 16 and will probably migrate to 17 before the end of the year. Some projects of my friends and previous colleagues (especially government sector) are still stuck with jdk8, - that we always knew would be the case. That's how Oracle gets their money. Extended support licenses and so on... Most of the projects (even the fintech sector) are steadily using jdk11. With 17, being another LTS release, will probably get similar adoption rate.
    Last edited by Leprechaunius; 15 September 2021, 03:29 PM.

    Leave a comment:


  • Vistaus
    replied
    Originally posted by jacob View Post

    I could be mistaken but I believe that AWT was based on Motif and Swing is more or less raw Xlib so yeah, no chance of ever moving to Wayland.
    Swing doesn't use much platform-specific code, so it could be ported rather easily. In fact, OpenJDK is already porting it to Wayland under the project name Wakefield.

    Leave a comment:


  • onlyLinuxLuvUBack
    replied
    Originally posted by vb_linux View Post
    Michael Can we have a GraalVM EE vs GraalVM CE vs Graal Native vs Hotspot comparison?
    Here is example source for graalvm with sqlite if that helps....
    https://github.com/mageddo/graalvm-e...0ad0685/sqlite

    Leave a comment:

Working...
X