Announcement

Collapse
No announcement yet.

OpenJDK Java's Native Wayland Support Progressing

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

  • #11
    Originally posted by Steffo View Post
    Does anyone know why they implement it from scratch and don't use libraries like wlroots?!
    wlroots is for making compositors, not clients.

    Comment


    • #12
      Originally posted by caligula View Post

      Only morons use Java on the client side. Competent programmers learnt it the hard way. VM startup takes forever. GC absolutely kills the performance. Toolkits look ancient. Applets are a joke. Oh applet support is actually deprecated in all modern browsers.

      If you want to use a dynamic client side language, Python 2 or 3 would be the best. Ref counting has much better interactive performance. Qt bindings also look decent and the Qt company provides excellent open source support for free. Qt has much better performance. Also each Kde release has lots of Wayland fixes, which helps Qt.
      Python being interpreted absolutely kills the performance.

      Comment


      • #13
        Originally posted by caligula View Post

        Only morons use Java on the client side.
        Yup. JetBrains must be utter dum-dums. Due to that awful decision their products are useless and literally no one will ever pay for them

        Comment


        • #14
          Originally posted by caligula View Post

          Only morons use Java on the client side. Competent programmers learnt it the hard way. VM startup takes forever. GC absolutely kills the performance. Toolkits look ancient. Applets are a joke. Oh applet support is actually deprecated in all modern browsers.

          If you want to use a dynamic client side language, Python 2 or 3 would be the best. Ref counting has much better interactive performance. Qt bindings also look decent and the Qt company provides excellent open source support for free. Qt has much better performance. Also each Kde release has lots of Wayland fixes, which helps Qt.
          do you enjoy baiting people?

          Comment


          • #15
            Originally posted by tildearrow View Post

            Python being interpreted absolutely kills the performance.
            While I agree, if you're talking about pure "how responsive does this feel to the user?", PyQt or PySide feels much snappier than Swing, SWT, or JavaFX on X11 in my experience. No idea why and I'll admit I've never compared QtJambi.

            Comment


            • #16
              Originally posted by slagiewka View Post

              Yup. JetBrains must be utter dum-dums. Due to that awful decision their products are useless and literally no one will ever pay for them
              Both Java and Electron based IDEs ship with a VM of their own. Jetbrains isn't even compatible with the standard OpenJDK, thus there's a need for a custom VM.

              Comment


              • #17
                Originally posted by ssokolow View Post

                While I agree, if you're talking about pure "how responsive does this feel to the user?", PyQt or PySide feels much snappier than Swing, SWT, or JavaFX on X11 in my experience. No idea why and I'll admit I've never compared QtJambi.
                Surprise, surprise: Qt is better for the most part, but... Swing's file picker is 10 times faster than Qt's (on HDD).

                Swing took 1 second to read a 3870 file directory, whereas Qt at best takes 10 seconds on the same directory.

                Comment


                • #18
                  Originally posted by tildearrow View Post

                  Surprise, surprise: Qt is better for the most part, but... Swing's file picker is 10 times faster than Qt's (on HDD).

                  Swing took 1 second to read a 3870 file directory, whereas Qt at best takes 10 seconds on the same directory.
                  Have you compared KDE's? It's been years since the last time I accidentally saw the stock Qt file picker and, with the rise of XDG portals and my push to Flatpak as many GUI apps as possible for easier customizable sandboxing, the KDE file picker is fast becoming the only option applications are allowed to request.

                  I know that whatever version Kubuntu 20.04 has takes longer to become responsive than GTK's during the process of loading a very large folder, but I don't know how it compares to Swing's, and I consider it a necessary evil to get a file picker that supports things like renaming, deletion, and non-buggy "type a path in" support right in the picker, like every other sane common dialog picker in the world.

                  (I'd also point to the support for per-application bookmarks, but they haven't rearchitected that yet, so it sees the portal host rather than the requesting applications as the "application" to scope the per-application bookmarks to.)

                  Comment


                  • #19
                    Originally posted by caligula View Post

                    Only morons use Java on the client side. Competent programmers learnt it the hard way. VM startup takes forever. GC absolutely kills the performance. Toolkits look ancient. Applets are a joke. Oh applet support is actually deprecated in all modern browsers.

                    If you want to use a dynamic client side language, Python 2 or 3 would be the best. Ref counting has much better interactive performance. Qt bindings also look decent and the Qt company provides excellent open source support for free. Qt has much better performance. Also each Kde release has lots of Wayland fixes, which helps Qt.
                    not sure if you're just trolling or if your last experience with Java is from 1995.

                    Comment


                    • #20
                      Originally posted by caligula View Post

                      Both Java and Electron based IDEs ship with a VM of their own. Jetbrains isn't even compatible with the standard OpenJDK, thus there's a need for a custom VM.
                      Yes, which if you check intellij runtime page at https://github.com/JetBrains/JetBrainsRuntime/wiki, is basically a fork of OpenJDK which implements bleeding edge features not in the official OpenJDK, many of which are ironically Linux related (Wayland, subpixel font rendering etc etc). Modern JDK's also don't have the performance problems you are insinuating since OpenJDK now supports many low latency GC options i.e. ZGC/Shenandoah (there are performance issues with JDK 8 which didn't have these low latency GC options but thats in the past now, JDK8 open source version is no longer supported).

                      And the Jetbrains Runtime is fully open source and rebases with upstream frequently, so you can just use it as your bundled JDK if you want. And while doing GUI programming with Java swing is a bit painful, the JVM has a lot of nice languages which makes GUI programming much nicer then python, i.e. https://github.com/scala/scala-swing.

                      And yeah Python is trash when it comes to performance for GUI apps. Its GIL design means that its hard to offload rendering to the UI thread because shared data structures are slow as hell, where as Java solved this problem 20+ years ago and Scala/Kotlin have much nicer concurrency abstractions (Scala has an ExecutionContext for Swing UI thread, Kotlin has a coroutine dispatcher for swing, see https://kotlinlang.org/api/kotlinx.c...outines-swing/) for easily handling this problem.
                      Last edited by mdedetrich; 25 September 2022, 02:51 PM.

                      Comment

                      Working...
                      X