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

Java Turns 25 – Whats Next? [pdf]

oracle.com

Post reply on HN
Print view View original

241–250 of 286 posts

Re: Java Turns 25 – Whats Next? [pdf]

#241

Post by imtringued »

cesarb wrote: post #82
AnimalMuppet wrote: post #49

Earlier quoted context omitted.

I think it's the libraries. They're like Barbie - they have everything . You need, say, to store affine transforms in your SQL database? Java can bridge those very different worlds. (It literally has affine transforms in the library.)

> I think it's the libraries. [...] they have everything. On the other hand, they need to have everything. In many other languages, it's common to just use a library written in a different language. For some reason, the foreign function interface of Java seems to have been designed to be hard to use, so instead of using an already existing library, Java developers tend to go through the route of "Rewrite It In Java".

It wouldn't be portable if it wasn't written in Java.

Re: Java Turns 25 – Whats Next? [pdf]

#242

Post by imtringued »

throwaway189262 wrote: post #114
topspin wrote: post #69

One thing that is hurting Java today is memory usage. Conventional JVMs use a lot of memory relative to essentially everything else and this is drives up cloud bills. There are alternative JVMs and other tools, some of which is embryonic at this point, but what the world wants and what Java really needs to continue thriving is efficient memory use by the bog standard JVMs that work with everything.

That's not always true. Most of the time when Java uses a ton of memory it's because people use the default memory settings. If you tell Java to use up to 90% of system RAM, it will. Garbage collection is expensive so it will delay until memory is depleted. This is a different GC design than V8 and Go, which use older collector designs with high overhead. They need to collect very frequently because their stop the wo…

I have never managed to get a JVM to use less than 100MB RAM. The application in question needed significantly less than 32MB of Java heap. Meanwhile equivalent lua programs can do just fine with 1MB RAM.

Re: Java Turns 25 – Whats Next? [pdf]

#243

Post by watt »

pron wrote: post #65
gonzo41 wrote: post #9

Earlier quoted context omitted.

Everything is OpenJDK now, forget oracle. AWS put out LTS JRE's etc. Try and get your employer to pay for a jetbrains IDE, IntelliJ IDEA. Use Maven for builds. It's simple-ish. Use Spring for frameworks. Everything's been done so you wont be first with any problems here. And all the stuff from 12 years ago is probably what people know and do, so it's still on point. No one does inheritance anymore composition's all t…

> Everything is OpenJDK now, forget oracle. OpenJDK is the name of Oracle's (one and only) Java implementation project (take a look at the logo at http://openjdk.java.net/ ). Oracle JDK is the name of the commercially supported product built from OpenJDK, and Oracle also distributes the JDK under a 100% free license ( http://jdk.java.net/ ). While OpenJDK has been the open-source part of the Sun/Oracle JDK since 2007…

There is so much risk associated with anything that Oracle touches, I suspect some very large organizations run the other way without really looking. Instead of Java, they switch to GoLang, and costs be damned.

The real damage that Oracle caused by their Android lawsuit, and by their JDK licencing scheme change, will reverberate for long time.

Re: Java Turns 25 – Whats Next? [pdf]

#244

Post by imtringued »

rcoveson wrote: post #225
throwaway189262 wrote: post #114

Earlier quoted context omitted.

That's not always true. Most of the time when Java uses a ton of memory it's because people use the default memory settings. If you tell Java to use up to 90% of system RAM, it will. Garbage collection is expensive so it will delay until memory is depleted. This is a different GC design than V8 and Go, which use older collector designs with high overhead. They need to collect very frequently because their stop the wo…

When I hear "Java uses too much ram," lazy reclamation of the heap and other GC overhead are not the first things that come to my mind, personally. Java doesn't have a "struct". If you want to represent an array of 64-bit signed integers, Java has you covered with its primitive arrays. But if you want to represent an array of anything more interesting than that, (say, a tuple of a double and a long), you have to seri…

What you are saying is true but even when you use optimized frameworks like Micronaut and stay below e.g. 50MB java heap usage you still end up using more RAM than what the Java heap says. Even the most optimized Java program on the planet will be beaten by a carelessly written C++ program. At least in terms of memory usage. I know it because I once wrote a React app with a C++ backend that also included sqlite. The C++ version needed 4MB of RAM at worst. Meanwhile the Java version didn't even include a database!

Re: Java Turns 25 – Whats Next? [pdf]

#245

Post by cuddlecake »

spullara wrote: post #126
cuddlecake wrote: post #122

Earlier quoted context omitted.

Not sure if being "deployable" is an issue, considering docker exists. So, anything is deployable in the future by default, given a machine running the correct docker image. Or am I misinterpreting the argument?

Java code will run on the new ARM machines Apple will ship. Running your Docker code in the same environment is not going to be pleasant.

I must admit I am completely ignorant to how much of an issue this is in real life, but I'm also in the privileged position of having the backend code compiled and run on remote servers, rarely on my own machine. On the other hand, I'm a junior developer, so I might yet stumble on this problem's relevancy at some point.

To be fair, docker is already a pain on my machine (using Fedora 32). I gave up on using docker at some point.

Re: Java Turns 25 – Whats Next? [pdf]

#246

Post by madmax108 »

ed25519FUUU wrote: post #64
bird_monster wrote: post #31

Earlier quoted context omitted.

Yeah it's a losing battle to suggest Java is mostly fine on HN. In this bubble we only use FP and/or Go/Rust and/or C++.

Those are the languages we love at least. I’m willing to bet that most of us are java developers to pay the bills.

This is practically a trope at this point. Sure, most of us who started off with Java 1.5-1.6 felt the same and Java was pretty much taken seriously only in the enterprise world, but in the last decade so much has happened in the JVM world.

In retrospect, as an early adopter of languages like Scala/Groovy, I really like how Java just waited and watched for a few years to see what was good in those languages and let them make mistakes on the way to building something stable and then adopted a lot of things that made those languages fun.

Java since 11.x onwards had been a great mix of developer productivity, stable core (other than people writing trivial projects, most people want something that lasts for years without random bugs), portability, and great tooling (specially from the IntelliJ side, as well as from the debugging side).

I'd much more openly recommend Java as a loved language now than back in 2010 (though Elixir is the new and shiny project I'm playing around with right now ;)).

Re: Java Turns 25 – Whats Next? [pdf]

#247

Post by imtringued »

throwaway189262 wrote: post #190
topspin wrote: post #171

Earlier quoted context omitted.

> That's tough to figure out. Indeed. That fact obviates this option in most cases. You have to spend time tweaking obscure, unstable knobs (the X in Xmx means Oracle is free to alter its meaning at any time) and risk either a.) serious failures in production or b.) poor results because the conservative choices necessary to avoid 'a' achieved little improvement and you wasted your time. The real world for most enterp…

The cost of setting a few command line args? They're not really obscure or unstable, just different depending on the GC you use. Turning on ZGC and setting the right options is like 4 command line flags. It's very easy, the reason it's not frequently done is that nobody reads documentation and it's not the default. Go's approach of minimal knobs leads to unfixable problems in production. Java gives more options to tu…

I think you're ignoring that people don't want to "tune" their GC. They just want it to work. So instead, they are going with the obvious route of just buying more RAM. This is perfectly fine on servers, which is where Java shines. As soon as Java has to be used for e.g. CLI scripts, daemons, or situations in which multiple process instances have to run at the same time, then Java is an incredibly poor choice and there is nothing you can do about that. If you are a genius at memory optimization in Java then you'll see even bigger gains in C++ or Go or Lua or Javascript or Python. Some of these options may not be as fast as the JVM but this discussion is purely about memory usage.

Re: Java Turns 25 – Whats Next? [pdf]

#248

Post by MaxBarraclough »

bandris wrote: post #94
MaxBarraclough wrote: post #44

Earlier quoted context omitted.

In defence of Java, I read somewhere it's 25 years old ;-) Part of the reason for its success has been its strong commitment to backward compatibility, so it's to be expected that it might accumulate many ways of doing things. Python wisdom tells us this is often a Bad Thing. [0] I imagine Java's approach to concurrency and parallelism might be quite different if it were designed today. [0] https://wiki.python.org/mo…

Actually BEAM and Erlang pre-dates Java. ;-) As for compatibility: why is Java 8 market share so high in 2020?

> BEAM and Erlang pre-dates Java

That's not really fair. The point of the Erlang language was its novel and opinionated approach to concurrency. Java wasn't trying to be like Erlang, it was trying to lure programmers by having significant similarities to C/C++.

Re: Java Turns 25 – Whats Next? [pdf]

#249

Post by Reelin »

coliveira wrote: post #39
yagodragon wrote: post #12

Java might be the most successful programming language. It is a solid choice among many different fields. It is used on huge infrastructure projects (Apache Foundation), governments, big tech companies such as amazon, ibm, google, apple for many large scale services. It can do web, ml, GUIs, it's still strong among academics. On top of that it offers a great programming experience with excellent IDE support and it's…

The main problem with Java is its concurrency model, which gives incentive to the creation of threads that fight for resources and introduce bugs. This seemed a wise choice in the 90s, but as concurrency has increased several-fold in the last 25 years, the model cannot scale to real software needs. It is the Java equivalent to pointers in C.

This is just silly. What concurrency model doesn't "fight for resources and introduce bugs"?

Threads (and pointers, which you compared them to) are the abstraction at the hardware level - everything else has to be built on top of them in one way or another. Just because you have access to threads (or pointers) doesn't mean you have to make poor architectural decisions. I'd like to draw your attention to Doom Eternal which takes the thread pool model through to its logical conclusion. (https://twitter.com/axelgneiting/status/1241487918046347264) I hope you'll agree that's an example of meeting the needs of real software. (I'm sure it's not the first or only example of that approach, it was just on my mind because it came up recently.)

Re: Java Turns 25 – Whats Next? [pdf]

#250

Post by thu2111 »

tasogare wrote: post #199
hota_mazi wrote: post #183

Earlier quoted context omitted.

> Ironically, while Java was the original "write once, run anywhere" language, it never succeeded in that regard (e.g. browser applets were never popular). Ironically, I believe Javascript has. It completely succeeded in that! Java (well JVM) developers today can - Write code on any of Windows/Linux/macOS - Deploy that code on any of Windows/Linux/macOS Not a lot of language/platforms can claim to this amount of succ…

C# (largely inspired by Java) run on even more platforms, because there is compiler/runtimes for mobile platform. It’s also the second biggest "entreprise" language, which fix a lot of Java pain points.

There are for Java too. You can - obviously - run Java on Android, using either the native runtime or, less obviously, OpenJDK with JavaFX.

You can also compile JavaFX apps AOT for iOS! It's called Gluon Substrate, check it out.

Java really does run on a lot of stuff, even if OpenJDK itself may not.

Post reply on HN