Java 18 / JDK 18: General Availability • Hacker News Board

Re: Java 18 / JDK 18: General Availability

#291

Post by igouy » Wed, Mar 23, 2022, 6:07 PM UTC

munificent wrote: post #155

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 think it's a combination of four things: 1. GC is an enormous productivity improvement for applications whose performance characteristics can afford it. Seriously, I can't think of a single programming language feature/concept/technology that makes a bigger difference in developer velocity than memory safety and GC. 2. Static types are also a large productivity improvement for developers comfortable using them and…

> Java was the first heavily…

Free-as-in-beer?

Re: Java 18 / JDK 18: General Availability

#292

Post by munificent » Wed, Mar 23, 2022, 6:47 PM UTC

igouy wrote: post #289

munificent wrote: post #257

Earlier quoted context omitted.

> (assuming that's a typo there, the things people don't like/the things people criticize?) Oops, yes, sorry. > Java 6 and prior were very very verbose and very very slow. It's kind of verbose, when looking at it from today's perspective, but at the time I didn't think it was that bad. I think they deliberately tried to be less cryptic and more wordy than C/C++ (which can often be impenatrable). I think they overcorr…

> But almost every managed language at the time had poor performance. Slow compared to Smalltalk. Slow compared to Lisp.

Depends on which implementations you're talking about.

But even fast Smalltalks weren't very fast relative to C, just relative to most other dynamic languages. And, of course, the people who made Smalltalk fast ended up making Java even faster.

Re: Java 18 / JDK 18: General Availability

#293

Post by pkolaczk » Wed, Mar 23, 2022, 6:57 PM UTC

kaba0 wrote: post #283

pkolaczk wrote: post #274

Earlier quoted context omitted.

But noone cares about hello world. You're not building hello-worlds in real life. Slow startup time is a problem in automated testing of big codebases - when you aim to test the whole codebase, but each test alone does not stress any code path hard enough for the hotspot compiler to kick in. So basically most of your Java code in testing runs in interpreted mode, which is like 20x-100x slower than properly compiled a…

That’s just not how it works. If no code path gets run enough times, then frankly, it simply doesn’t matter, they could have been written in bash and still be “fast enough”. Like, I can’t fathom a program that doesn’t have loops where the actually important part happens. You simply can’t write enough “linear” code to make a modern CPU sweat even just a little. And if you do have said loop, than it will be JIT compile…

But it's not just interpreting linear code. It is also classloading which involves a non-trivial amount of work before any code in a class can even run. Also I never said the testing code doesn't have any loops. There often are loops but they need to run for a really long time until hotspot kicks in. So if you lose a few tens of millisecond here and there in a single test, you will get minutes or hours in total in a codebase that has hundreds of thousands tests. And it gets terribly worse if many of your tests are end-to-end tests that e.g. launch new JVMs.

Re: Java 18 / JDK 18: General Availability

#294

Post by darkhorn » Wed, Mar 23, 2022, 7:11 PM UTC

kaba0 wrote: post #273

darkhorn wrote: post #261

Earlier quoted context omitted.

Another surprise is it that it has issues on Turkish localized Windows operating systems.

What do you mean? Can you give a source where I can read more on that?

http://haacked.com/archive/2012/07/05/turkish-i-problem-and-... http://www.i18nguy.com/unicode/turkish-i18n.html https://community.jaspersoft.com/questions/1065746/jasperrep... https://userapps.support.sap.com/sap/support/knowledge/en/14... https://github.com/java-native/jssc/issues/80 https://issues.apache.org/jira/plugins/servlet/mobile#issue/...

Re: Java 18 / JDK 18: General Availability

#295

Post by kaba0 » Wed, Mar 23, 2022, 10:03 PM UTC

darkhorn wrote: post #294

kaba0 wrote: post #273

Earlier quoted context omitted.

What do you mean? Can you give a source where I can read more on that?

http://haacked.com/archive/2012/07/05/turkish-i-problem-and-... http://www.i18nguy.com/unicode/turkish-i18n.html https://community.jaspersoft.com/questions/1065746/jasperrep... https://userapps.support.sap.com/sap/support/knowledge/en/14... https://github.com/java-native/jssc/issues/80 https://issues.apache.org/jira/plugins/servlet/mobile#issue/...

Well, I think it’s just the usual gotcha of programmers assuming things about languages that are not true.

Though I’m not sure why wasn’t two new i’s added instead of modifying the latin i? It is a different letter after all in this case.

Re: Java 18 / JDK 18: General Availability

#296

Post by mmastrac » Thu, Mar 24, 2022, 12:26 AM UTC

papercrane wrote: post #220

mmastrac wrote: post #208

Earlier quoted context omitted.

I believe reference queues are the way to go about this now. Once you wrap your brain around them, it's far simpler to reason about. The only really issue is that you effectively need to litter your code with queue checks, or dedicate a thread to watching them.

You can use the Cleaner API instead. It's pretty straightforward to use. https://download.java.net/java/early_access/jdk18/docs/api/j...

Thanks for the pointers - my Java knowledge is apparently out-of-date!

Re: Java 18 / JDK 18: General Availability

#297

Post by rambojazz » Thu, Mar 24, 2022, 7:16 AM UTC

halestock wrote: post #2

Here's the openjdk page which includes links to details of all new features: https://openjdk.java.net/projects/jdk/18/

The link is in the email itself

Re: Java 18 / JDK 18: General Availability

#298

Post by native_samples » Thu, Mar 24, 2022, 11:02 AM UTC

kevincox wrote: post #198

native_samples wrote: post #191

Earlier quoted context omitted.

UTF-16 represents a fairly reasonable compromise, not sure what your disgust is for. UTF-32 (with no BMP concept) doubles the memory usage of most international text and quadruples the memory usage of ASCII text (which is the most common), yet characters outside the BMP are barely used outside of emoji. Native UTF-8 in memory makes character indexing a non-constant time operation, which would bite people badly in cas…

> Native UTF-8 in memory makes character indexing a non-constant time operation The only reason that Java's UTF-16 has constant time indexing is because they use a braindead definition of character which is "UTF-16 codepoint". If you want constant time character indexing you need to go UTF-32. But obviously the downsides are too great for most users. So in practice everyone uses UTF-8 because it is usually the most m…

But in practice the Java definition of a character basically always works, because characters that aren't in the BMP are vanishingly rare in real software outside of emoji, and of course, Java long pre-dates emoji.

Re: Java 18 / JDK 18: General Availability

#299

Post by nsxwolf » Thu, Mar 24, 2022, 1:20 PM UTC

ianopolous wrote: post #254

nsxwolf wrote: post #187

The simple HTTP server is a nice addition. I end up using python's SimpleHTTPServer for all sorts of things so it will be nice to have an alternative right in the JDK.

Ever since Java 11 enabled running single Java files directly without compiling them I've been using my own trivial single file web server for this purpose: https://github.com/ianopolous/simple-http-server

I did not know about this direct execution trick!

Re: Java 18 / JDK 18: General Availability

#300

Post by jollybean » Thu, Mar 24, 2022, 2:04 PM UTC

igouy wrote: post #286

jollybean wrote: post #278

Earlier quoted context omitted.

Sorry, but this is textbook. Go ahead and run some code on V8 and the equivalent Java. You'll notice V8 is 'extremely fast' at getting up and running, while Java takes quite some time - often thousands of iterations of a specific bit of code before it optimises.

> Go ahead and run some code… https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Oi Vei, I literally said 'fast at getting up and going' and 'over time Java is more optimised'.

Those tests ultimately measure 'peak performance'.

Java takes much longer to reach that level than V8.

Given the fact that a lot of software does not run for a long period of time, and especially UI/Web code (and possibly serverless), the net result is that V8 is basically faster. It gets too near 100% performance after 1 or 2 iterations. Java takes 1000's of iterations.

For many applications, the 'advantage of being fast soon' considerably outweighs any kind of incremental performance benefit that Java might offer over time.

This is mostly true for UI software.

V8 'is fairly quick, and right away'. Java is 'sticky and slow for a bit, and then a bit faster over time but it's not noticeable'.

V8 is a regular car: stops and starts as needed. Java is a race-track stock car - accelerates up to a high speed and stays there. You don't need a race-track car to do food delivery, because the added peak performance is pointless.