Announcement

Collapse
No announcement yet.

Fedora's Java Packages Have Fallen Into Rough Shape

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

  • #61
    Originally posted by bug77 View Post
    Thanks, I missed that. Just like I missed when Oracle moved LTS releases from the promised "every 3 releases" to "every 3 years"
    I don't believe it was ever promised to be every three releases. A lot of people, including myself, believed that to be the case - but when I went looking for confirmation of that, I was unable to find any sources that said anything other than three years. I suspect that it was a misunderstanding, possibly on the assumption that releases would be yearly.

    Comment


    • #62
      Originally posted by krzyzowiec View Post

      Rust is never replacing Java on the server side. It’s a good language, but the mental overhead involved in having to manage memory yourself is not worth it in web programming, not unless you are Google or Amazon anyway.
      Sure. It's just funny when people complain that some contemporary technology is outdated, but can't really come up with any reasonable alternatives. For instance, ANSI C and Perl aren't necessarily any better in the back-end / cloud.

      Comment


      • #63
        Originally posted by caligula View Post

        Could be. I'm not saying other projects are doing any better. I suppose Oracle would be willing to add Wayland support to Swing and even if they weren't maintaining JavaFX themselves, they might be in favor of improving JavaFX more than SWT. Meanwhile, doesn't XWayland work for Java apps?
        JetBrains have made recently some noises on working with upstream on this, see https://youtrack.jetbrains.com/issue/JBR-3206

        tl;dr:

        Maxim Kartashev commented 7 Jul 2021 18:09

        There's a new Call for Discussion : New Project to support the Wayland display server on Linux on the OpenJDK mailing list.

        [...] there have already been informal discussions for some time with various parties that have expressed
        interest in helping towards the outcome of supporting Wayland

        JetBrains is one of those parties that will be helping with Wayland support. But this is a large project and even reaching short-term goals will take quite some time. Please, stay tuned.
        I don't know if there have been any actual efforts being made yet though.

        Comment


        • #64
          Originally posted by caligula View Post

          Sure. It's just funny when people complain that some contemporary technology is outdated, but can't really come up with any reasonable alternatives. For instance, ANSI C and Perl aren't necessarily any better in the back-end / cloud.
          For backend/cloud type applications, Java still remains quite popular, Go is recently gaining good traction as well. Rust is used in some specific cases where performance is critical and garbage collection overhead is not acceptable.

          Comment


          • #65
            Originally posted by caligula View Post

            Sure. It's just funny when people complain that some contemporary technology is outdated, but can't really come up with any reasonable alternatives. For instance, ANSI C and Perl aren't necessarily any better in the back-end / cloud.
            Perl CGI is pretty much dead in backend/cloud, its only in maintenance mode for old applications written in it. No one seriously uses Perl for new applications, its likely going to turn into a COBOL for webserver specifically in the next 10-20 years.

            Usage of C is extremely rare in backend cloud, its incredibly common for security/memory vulnerabilities to slip through and since we are dealing with cloud where you are more exposed the risks are more catastrophic. Hence its usage is only delegated in the areas where performance/memory usage is absolutely critical (i.e. databases, reverse proxies, load balancers). Rust is also eating C's lunch here, Dropbox/Cloudflare have publicly stated that they use Rust for areas where performance is critical. Typically though in terms of economics in the cloud, its just far cheaper to throw memory/CPU at the problem and use a safer language such as Go/JVM/Ruby/Python (which is something you can't do as easily for a personal desktop/laptop/tablet/phone).
            Last edited by mdedetrich; 30 September 2021, 09:14 AM.

            Comment


            • #66
              Originally posted by Delgarde View Post

              I don't believe it was ever promised to be every three releases. A lot of people, including myself, believed that to be the case - but when I went looking for confirmation of that, I was unable to find any sources that said anything other than three years. I suspect that it was a misunderstanding, possibly on the assumption that releases would be yearly.
              Yeah, I guess you are right: https://www.infoq.com/news/2017/09/Java6Month/
              My bad.

              Comment


              • #67
                Originally posted by caligula View Post

                Sure. It's just funny when people complain that some contemporary technology is outdated, but can't really come up with any reasonable alternatives. For instance, ANSI C and Perl aren't necessarily any better in the back-end / cloud.
                Agreed. Java is the perfect blend of simplicity and power for the back end, in the same way that JavaScript is so good for the front end. People will bring up Kotlin (or Clojure if you're me), but they are producing Java bytecode so it seems pointless to distinguish them if you are talking about language performance. I do find it amusing that most of the people saying Java is outdated / useless probably wouldn't say the same about C or C++, though Java is more modern than both.

                Comment


                • #68
                  Originally posted by mdedetrich View Post
                  Usage of C is extremely rare in backend cloud, its incredibly common for security/memory vulnerabilities to slip through and since we are dealing with cloud where you are more exposed the risks are more catastrophic. Hence its usage is only delegated in the areas where performance/memory usage is absolutely critical (i.e. databases, reverse proxies, load balancers). Rust is also eating C's lunch here, Dropbox/Cloudflare have publicly stated that they use Rust for areas where performance is critical. Typically though in terms of economics in the cloud, its just far cheaper to throw memory/CPU at the problem and use a safer language such as Go/JVM/Ruby/Python (which is something you can't do as easily for a personal desktop/laptop/tablet/phone).
                  To be correct when you get into where performance is absolutely critical horrible things like unikernel turn up as well.

                  https://www.tiobe.com/tiobe-index/ Python these days has gone head of JVM for a lot of cloud based things.

                  Also this increase in python has seen increase in usage of items like https://cython.org/ yes python to C. So you don't code C instead code in python and covert to C for performance. So C usage in the backend of cloud is not as rare as it use to be. But will you be coding in C directly more often than not no instead you will be coding in a different language and converting to C. For the reason you stated with security and memory vulnerabilities risk coding straight in C is normally not worth it. But the performance of C cannot always be ignored either.

                  At Dropbox Python and rust are both kind of eating C lunch. Dropbox does use python to C in places why PEP in 2019 for type to be part of python came from dropbox.

                  Nice write up on it.

                  So its not exactly we have to throw more memory/CPU at it any more to use a safer language. There is more than more with python that you can use a python that is a safer language than C and still get all the C performance because of python to c conversion. Yes in places python is starting to eat java lunch.

                  Originally posted by krzyzowiec View Post
                  Agreed. Java is the perfect blend of simplicity and power for the back end, in the same way that JavaScript is so good for the front end. People will bring up Kotlin (or Clojure if you're me), but they are producing Java bytecode so it seems pointless to distinguish them if you are talking about language performance. I do find it amusing that most of the people saying Java is outdated / useless probably wouldn't say the same about C or C++, though Java is more modern than both.
                  Sorry but a lot of ways Java is slowly losing market share. Oracle vs Google over license has not done java any favours. Oracle vs Google result in the loss of items like gcj that java to native binary.

                  Java might be more modern than C and C++ but without a native binary production tool it does not end up as high performance as python that has python to C or the other languages like rust and go that can also make native binaries. Like or not JIT brings some horrible overheads.

                  Yes Oracle vs Google fight has put java in a bad location leading to slow but progressive market loss due to lack of performance. At this stage the biggest winner of that market loss is python. Is it possible java to turn around at this stage yes it is. But it would require people making java to admit native binary/AOT feature is important.

                  Comment


                  • #69
                    Originally posted by oiaohm View Post
                    Java might be more modern than C and C++ but without a native binary production tool it does not end up as high performance as python that has python to C or the other languages like rust and go that can also make native binaries. Like or not JIT brings some horrible overheads.

                    Yes Oracle vs Google fight has put java in a bad location leading to slow but progressive market loss due to lack of performance.
                    Why we chose Java for our High-Frequency Trading application - Oct 21, 2020 - 8 min read
                    https://medium.com/@jadsarmo/why-we-...n-600f7c04da94

                    Comment


                    • #70
                      Originally posted by reba View Post

                      Why we chose Java for our High-Frequency Trading application - Oct 21, 2020 - 8 min read
                      https://medium.com/@jadsarmo/why-we-...n-600f7c04da94
                      I actually interviewed someone who used Java for HFT, and yeah it was interesting. Basically they turned off the GC in the JVM for the slight time window when the trading happened and then turned it on again after the time window.

                      Java is not as slow as people mistankingly think it is, if you code in Java in a very similar way to C (i.e. very iterative, keep abstractions to a minimum) the performance is quite competitive.

                      Originally posted by oiaohm View Post

                      To be correct when you get into where performance is absolutely critical horrible things like unikernel turn up as well.

                      https://www.tiobe.com/tiobe-index/ Python these days has gone head of JVM for a lot of cloud based things.

                      Also this increase in python has seen increase in usage of items like https://cython.org/ yes python to C. So you don't code C instead code in python and covert to C for performance. So C usage in the backend of cloud is not as rare as it use to be. But will you be coding in C directly more often than not no instead you will be coding in a different language and converting to C. For the reason you stated with security and memory vulnerabilities risk coding straight in C is normally not worth it. But the performance of C cannot always be ignored either.

                      At Dropbox Python and rust are both kind of eating C lunch. Dropbox does use python to C in places why PEP in 2019 for type to be part of python came from dropbox.
                      https://dropbox.tech/application/our...ines-of-python
                      Nice write up on it.

                      So its not exactly we have to throw more memory/CPU at it any more to use a safer language. There is more than more with python that you can use a python that is a safer language than C and still get all the C performance because of python to c conversion. Yes in places python is starting to eat java lunch.



                      Sorry but a lot of ways Java is slowly losing market share. Oracle vs Google over license has not done java any favours. Oracle vs Google result in the loss of items like gcj that java to native binary.

                      Java might be more modern than C and C++ but without a native binary production tool it does not end up as high performance as python that has python to C or the other languages like rust and go that can also make native binaries. Like or not JIT brings some horrible overheads.

                      Yes Oracle vs Google fight has put java in a bad location leading to slow but progressive market loss due to lack of performance. At this stage the biggest winner of that market loss is python. Is it possible java to turn around at this stage yes it is. But it would require people making java to admit native binary/AOT feature is important.
                      The issue with Python (and I had to deal with this in many companies) is that its only performant if you have a C library, if you don't then you have to write one yourself which brings us back to square one. The python developers even kept the python interpreter slower by generating bytecode that is easy to read/understand at runtime but slower to execute (i.e. it deliberately doesn't do many stack based optimizations). Also note that python has a GIL (global interpreter lock) which makes multithreading in Python terrible

                      Python is popular in backend/cloud but mainly in two areas

                      1. For web/rest API's where performance usually isn't that critical (until sometimes it is and then they have to use something else, you can't solve the Python's performance problems with C in this specific area in a nice way)
                      2. In data science/statistics and this is only because there are very old/mature C libraries that Python piggy backs off (i.e. numpy). A lot of data scientists also use Python for this because they don't care about code quality/maintenance, they generate their models using Python and when that is done they throw it away


                      If you want a generally high performance backend application/library (i.e. much faster than Ruby/Python/Perl/PHP but not as fast as highly optimized C/Rust) the JVM is your best bet simply because you don't have to fall back to C which is actually a massive benefit. Go is eating JVM's lunch here a bit, but Go also has its own problems and its largely solving an economic and not a language problem.
                      Last edited by mdedetrich; 01 October 2021, 04:02 AM.

                      Comment

                      Working...
                      X