Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 18 / JDK 18: General Availability

mail.openjdk.java.net

Post reply on HN
Print view View original

131–140 of 304 posts

Re: Java 18 / JDK 18: General Availability

#131

Post by paskozdilar »

zero_shift wrote: post #110
paskozdilar wrote: post #62

Earlier quoted context omitted.

IMHO, Marketing. Java had so many marketing crazes that it's crazy. I still remember the "Java mobile game" fad from a dozen of years ago - Java this, Java that, Java for phone, Java for toaster... At some point, the public mind starts to associate "programming" with Java. Since there were (and probably always will be, unless we evolve into utopia) hordes of job-desperate people who would do anything to feed themselv…

I see this post is getting some downvotes; I'm not sure I agree with all of it myself. But I would ask those, who reject the premise here outright, to think back really hard to how things were in the 1990s. The Java brand was everywhere . It was a truly massive endeavour and one of the first languages to really go "viral" as the Solution For Everything. People laugh at the cute "Java runs on four billion devices!" ta…

People don't like to see their favorite languages bashed. It's completely understandable.

I suppose there are many Java enthusiasts on here.

Re: Java 18 / JDK 18: General Availability

#132

Post by shellac »

desdiv wrote: post #105

>JEP400: UTF-8 by Default This changes the default charset of the Java APIs to UTF-8. I read that the Java 8's JVM's internal string representation is UTF-16 [0][1]. Is that still the case after JEP400? [0] https://docs.oracle.com/javase/8/docs/technotes/guides/intl/... [1] http://tutorials.jenkov.com/java/strings.html

Yes, that won't change anything internal. However:

> ...JVM's internal string representation is UTF-16

Hasn't been try for a while. They switched to using a byte array internally for storage, plus an encoding. Currently that's either UTF-16 or Latin 1, unless compact strings are disabled in which case it's all UTF-16.

Re: Java 18 / JDK 18: General Availability

#133

Post by marginalia_nu »

kaycebasques wrote: post #5

This is tangential and possibly too open ended to be productive but worth a shot anyway. Why is Java so popular? I know of a major Silicon Valley company that's migrating their backend to it. Why Java over other languages? Or maybe there's not really other viable options? I'm speaking as someone who spent the last 6 years focused on frontend web technology.

I can tell you why I choose Java for my projects:

* It's very fault tolerant. In almost every case C++ would mushroom cloud, Java can walk it off. It's easy to write code that cleans itself up on error. try-with-resources is great.

* Modern JVM JIT and GC are pretty damn good, and the tooling is great.

* It's very boring and stable. I see this as the killer feature. Cool is a conserved quantity. It's extremely hard to write cool software in a cool language, as that attracts cool developers too busy getting cool jobs to maintain their cool framework you depended on. There's a lot of mature high quality libraries available. APIs are stable, stuff very seldom breaks. You can often use code that's 10-15 years old just fine. This has changed a bit lately, but it's still extremely reliable.

There are drawbacks as well, primarily memory mapping files is difficult, some of the aforementioned libraries are a bit bloated as well and overall the language sort of encourages large complicated solutions to simple problems.

Re: Java 18 / JDK 18: General Availability

#134

Post by marginalia_nu »

dtech wrote: post #87
junon wrote: post #28

Earlier quoted context omitted.

If you actually understand Java, you'll understand why this is wrong. Only newbies have confusion about this, most of which dissipates when you actually learn the language you're working with. Tired of this 20+ year old "flaw" being used as cannon fodder.

Just because something is a well known-flaw doesn't make it a glaring flaw. There's a reason newer JVM languages like Kotlin use == as an alias for equals instead of reference equality.

What if you are interested in reference equality?

Re: Java 18 / JDK 18: General Availability

#135

Post by _old_dude_ »

desdiv wrote: post #105

>JEP400: UTF-8 by Default This changes the default charset of the Java APIs to UTF-8. I read that the Java 8's JVM's internal string representation is UTF-16 [0][1]. Is that still the case after JEP400? [0] https://docs.oracle.com/javase/8/docs/technotes/guides/intl/... [1] http://tutorials.jenkov.com/java/strings.html

Since Java 9/11 (9 is not a LTS), String internals was reworked to use either 8 bits or 16 bits per char. [1]

[1] https://openjdk.java.net/jeps/254

Re: Java 18 / JDK 18: General Availability

#136

Post by NoSorryCannot »

ok123456 wrote: post #104
giaour wrote: post #35

Earlier quoted context omitted.

Java values backwards compatibility very highly, so if something runs today, it's likely to keep running without modification on future JVMs. (Though the 8->9 transition was pretty rough for some.) Compiled Java artifacts are usually portable across OSes and CPU architectures, so your build pipeline can be pretty simple even if your infrastructure is not. JVM performance is generally fine, and the language prevents y…

> Java values backwards compatibility very highly, so if something runs today, it's likely to keep running without modification on future JVMs. Then why do I have to have multiple JVMs installed, which I need to go through via trial-and-error, if I'm given some random java application?

I don't know, why do you?

There are occasionally breaking changes but most old jars out there will run fine in the latest runtime, so the answer to your question is going to depend on how squirrely your use case is.

Re: Java 18 / JDK 18: General Availability

#137

Post by kaba0 »

pfortuny wrote: post #37
hu3 wrote: post #20

Earlier quoted context omitted.

Thanks! So why would I pick Oracle's implementation?

I do not know but apart from just vendor lock in, oracle might provide guarantees (maintenance?) that the other providers cannot.

There is no vendor lock-in, other than perhaps the logo, OpenJDK is the same as OracleJDK, since Oracle develops the former 90+%.

Re: Java 18 / JDK 18: General Availability

#138

Post by stevoski »

ok123456 wrote: post #104
giaour wrote: post #35

Earlier quoted context omitted.

Java values backwards compatibility very highly, so if something runs today, it's likely to keep running without modification on future JVMs. (Though the 8->9 transition was pretty rough for some.) Compiled Java artifacts are usually portable across OSes and CPU architectures, so your build pipeline can be pretty simple even if your infrastructure is not. JVM performance is generally fine, and the language prevents y…

> Java values backwards compatibility very highly, so if something runs today, it's likely to keep running without modification on future JVMs. Then why do I have to have multiple JVMs installed, which I need to go through via trial-and-error, if I'm given some random java application?

> Then why do I have to have multiple JVMs installed, which I need to go through via trial-and-error, if I'm given some random java application?

You don't. Almost any Java program written ever will run on Java 18.

Re: Java 18 / JDK 18: General Availability

#139

Post by Angius »

freedomben wrote: post #93

It's legitimately fascinating to see the rise of pattern matching, to the point that even Java will have it [1]! Combined with lambdas, this is a different language than the Java 1.5 that I first learned. If you would have told me that this would be valid Java code: static void testStringOrNull(Object o) { switch (o) { case null, String s -> System.out.println("String: " + s); } } I would never have believed you. And…

Java turning more and more into poor man's C# with each release

Re: Java 18 / JDK 18: General Availability

#140

Post by ohgodplsno »

dfee wrote: post #66
fifticon wrote: post #46

Earlier quoted context omitted.

Actually, i like it for basic desktop apps, because it just works, and i stay clear of the last 12 years of front-end dumpster fires, where nothing that is over 18 months old, can build, compile or get support anymore. In my day job, I inherit "fun" tasks as 'get this thing someone glued together with webpack4 and frontend-du-jour to work with webpack5 in 2022. Java thank you, any day of the week.

There are a lot of problems in the JS and Swift communities, as there are for Java. I think you’ve got to meet your customer where they are, and if you can ship Java desktop apps, and they’re happy… keep going. But you’re not shipping apps to their iPhones using Java. It’s either JS or Swift. And, on Android it’s JS or Kotlin. So the common target is JS.

Or Kotlin Multiplatform, which generates .frameworks/cocoapods/spm files that you can use, and all you have to do is write your UI layer in Swift.
Post reply on HN