←back to thread

Java at 30: Interview with James Gosling

(thenewstack.io)
253 points chhum | 2 comments | 16 May 25 13:05 UTC | HN request time: 0.414s | source
Show context
exabrial ◴[16 May 25 14:51 UTC] No.44006194[source]▶
Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby.

Java syntax isn't perfect, but it is consistent, and predictable. And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), it's just pressing control-space all day and you're fine.

Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff.

What do you get for all of these tradeoffs? Speed, memory safety. But with that you still still have dynamic invocation capabilities (making things like interception possible) and hotswap/live redefinition (things that C/CPP cannot do).

Perfect? No, but very practical for the real world use case.

replies(17): >>44006269 #>>44006358 #>>44006411 #>>44006567 #>>44006570 #>>44006865 #>>44007100 #>>44007464 #>>44007662 #>>44007666 #>>44009121 #>>44009861 #>>44011219 #>>44011642 #>>44012473 #>>44015715 #>>44016458 #
brightball ◴[16 May 25 15:08 UTC] No.44006411[source]▶
When I got out of college and was still firmly in the "Java is the solution to everything" mentality I didn't realize that my admiration was really for the JVM and the Java App Server tooling that was so much more advanced than anything else at the time. It was basically Docker + K8s for anything running on the JVM more than 2 decades earlier.

Java the language eventually drove me away because the productivity was so poor until it started improving around 2006-2007.

Now I keep an eye on it for other languages that run on the JVM: JRuby, Clojure, Scala, Groovy, Kotlin, etc.

IMO JRuby is the most interesting since you gain access to 2 very mature ecosystems by using it. When Java introduced Project Loom and made it possible to use Ruby's Fibers on the JVM via Virtual Threads it was a win for both.

Charles Nutter really doesn't get anywhere close to enough credit for his work there.

replies(4): >>44006504 #>>44006676 #>>44012215 #>>44012446 #
cogman10 ◴[16 May 25 15:17 UTC] No.44006504[source]▶
Let me extol the virtues of Java the language.

You can take pretty much any code written for Java 1.0 and you can still build and run it on Java 24. There are exceptions (sun.misc.Unsafe usage, for example) but they are few and far between. Moreso than nearly any other language backwards compatibility has been key to java. Heck, there's a pretty good chance you can take a jar compiled for 1.0 and still use it to this day without recompiling it.

Both Ruby and Python, with pedigrees nearly as old as Java's, have made changes to their languages which make things look better, but ultimately break things. Heck, C++ tends to have so many undefined quirks and common compiler extensions that it's not uncommon to see code that only compiles with specific C++ compilers.

replies(11): >>44006688 #>>44006821 #>>44006953 #>>44009308 #>>44009663 #>>44009839 #>>44010152 #>>44010332 #>>44012452 #>>44015773 #>>44020134 #
1. KronisLV ◴[17 May 25 17:37 UTC] No.44015773[source]▶
> Moreso than nearly any other language backwards compatibility has been key to java.

The Java 8 and 8+ divide very much works against this. It was a needed change (much like Python 2 vs 3) but nowhere near pleasant, especially if some of your dependencies used the old Java packages that were removed in, say, OpenJDK 11.

Furthermore, whenever you get the likes of Lombok or something that has any dynamic compilation (I recall Jaspersoft having issues after version upgrade, even 7 to 8 I think), or sometimes issues with DB drivers (Oracle in particular across JDK versions) or with connection pooling solutions (c3p0 in particular), there's less smooth sailing.

Not to say that the state of the ecosystem damns the language itself and overall the language itself is pretty okay when it comes to backwards compatibility, though it's certainly not ideal for most non-trivial software.

replies(1): >>44021404 #
2. cogman10 ◴[18 May 25 13:48 UTC] No.44021404[source]▶
The Java 9 change was to remove access to unofficial APIs.

I agree it was somewhat painful, but not nearly to the level of the 2->3 change which ended up changing python syntax. Most dependencies worked throughout the change and still work.

> Furthermore, whenever you get the likes of Lombok or something that has any dynamic compilation ... there's less smooth sailing.

Not sure about c3p0, but Lombok goes out of it's way to inject itself into javac internals in order to make it's output changes. It's using the most internal of internal code in order to make that @Getter annotation work. Plenty of other annotation processing APIs are completely unaffected by javac updates because they choose not to use internal APIs. Immutables, Autovalue, dagger2, all examples of dynamic compilation that continue to work regardless the version of java. Lombok is a horrible little dependency that I wish people would abandon. It's making a mess and then complaining that it's somehow Java's fault because Lombok decided it needed access to the AST.

I get it, things have broken. But what has been broken is literally the undefined and non-public APIs which went so far as to call their packages things like `sun.misc.unsafe` just to try and ward off people from using these APIs. (With the javadocs to boot which told people not to use this).

And even with the break, the Java devs went out of their ways to make stand-in apis.