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

  • #21
    Finally Java is getting sealed classes, something that C# have had for at least 6 years, probably longer. I found it mentioned in an article from 2015.

    Comment


    • #22
      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 could likely be ported. It only uses very little platform specific code just to create a window and draw to it (i.e Win32, Xlib, Cocoa) and then the rest is all custom drawing.

      This is why it can never look 100% native but the advantage is it is much more portable than those that wrap underlying toolkits (i.e AWT).

      The question is, what would you wrap for a Wayland port? The project is still too young for anything like Xlib. Perhaps they would wrap SDL2 or Gtk3 just to create a window? Gtk moves too much so would be a little fragile.
      All Wayland compositors need a standard client API library and will likely get one someday but SDL2 and Gtk3 isn't really quite right for this.
      Last edited by kpedersen; 15 September 2021, 06:47 AM.

      Comment


      • #23
        Michael Can we have a GraalVM EE vs GraalVM CE vs Graal Native vs Hotspot comparison?

        Comment


        • #24
          Originally posted by uid313 View Post
          Finally Java is getting sealed classes, something that C# have had for at least 6 years, probably longer. I found it mentioned in an article from 2015.
          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

          Comment


          • #25
            Originally posted by kpedersen View Post

            All Wayland compositors need a standard client API library and will likely get one someday but SDL2 and Gtk3 isn't really quite right for this.
            Something like libwayland-client?

            Comment


            • #26
              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

              Comment


              • #27
                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.

                Comment


                • #28
                  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.

                  Comment


                  • #29
                    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

                    Comment


                    • #30
                      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 ...

                      Comment

                      Working...
                      X