Announcement

Collapse
No announcement yet.

OpenJDK 18 Released With A Simple Web Server, UTF-8 By Default

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

  • OpenJDK 18 Released With A Simple Web Server, UTF-8 By Default

    Phoronix: OpenJDK 18 Released With A Simple Web Server, UTF-8 By Default

    Oracle today announced the general availability of JDK/OpenJDK 18 as the reference implementation of Java 18...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Is there any reason why do they have to evaluate publishing the source code of OpenJDK for every country?

    Comment


    • #3
      Originally posted by tildearrow View Post
      Is there any reason why do they have to evaluate publishing the source code of OpenJDK for every country?
      Tap into the latest open source publications. Discover insights from our projects and open technology thought leaders.

      Comment


      • #4
        Having UTF-8 by default only in 2022 is just mind-blowing.

        Comment


        • #5
          Originally posted by Sin2x View Post
          Having UTF-8 by default only in 2022 is just mind-blowing.
          Yeah, UTF-8 by default finally in 2022, that's insane!

          Oracle should just fork .NET 7 and replace every reference to "dotnet" with "java".

          Comment


          • #6
            Another noteworthy addition with OpenJDK 18 is including a simple web server as part of the package.
            Great, even more stdlib bloat that nobody asked for.

            Comment


            • #7
              Originally posted by Sin2x View Post
              Having UTF-8 by default only in 2022 is just mind-blowing.
              That is just a default for APIs. From the JEP:
              Standard Java APIs for reading and writing files and for processing text allow a charset to be passed as an argument. A charset governs the conversion between raw bytes and the 16-bit char values of the Java programming language. Supported charsets include, for example, US-ASCII, UTF-8, and ISO-8859-1.

              Current APIs just use the platform default. And not many people are aware an encoding is involved, so they rarely specify one (Idea will slap your wrist when you do that, tho), leading to some very "interesting" bugs when you do all your testing on just one platform, but deploy on something else. Or when you do all your testing using only plain ASCII strings.

              Strings in Java have been UTF-[s]8[/s]16 since v1.0.
              Last edited by bug77; 22 March 2022, 06:35 PM.

              Comment


              • #8
                Originally posted by bug77 View Post
                Strings in Java have been UTF-8 since v1.0.
                Strings in java are UTF-16 not UTF-8. (nothing wrong with that)

                Comment


                • #9
                  Originally posted by paulpach View Post

                  Strings in java are UTF-16 not UTF-8. (nothing wrong with that)
                  My mistake, you are correct. Fixed.

                  Comment


                  • #10
                    Originally posted by bachchain View Post
                    Great, even more stdlib bloat that nobody asked for.
                    Even better, I bet this will cause just as many security exploits as JNDI/LDAP! Thanks Oracle! You really keep infosec people busy!

                    Comment

                    Working...
                    X