I have heard it about the situation in 1995, but it probably also holds to a good extent now: You appreciate Java (only) after you have experienced/experience other languages.
Java at 30: Interview with James Gosling
91–100 of 437 posts
Re: Java at 30: Interview with James Gosling
#92I admire Java as a success story, but I still have a deeply ingrained aversion to it for many reasons. I will admit that many of the reasons are due to Java's legacy as the language of bloated corporations, and its creation of overly verbose, magic fueled frameworks and poorly written code. Java as a language goes hand in hand with the idea that code is coal to be shoveled into the furnace, and we should all throw ou…
>My other issues with the JVM is how much of a black box it is from a platform perspective, which makes debugging a PITA
Java has one the greatest debugging capabilities ever. dynamic breakpoints, conditional breakpoints, hell you can ever restart a stack frame after hot deploying code without a restart. You can overwrite any variable in memory, set uncaught exception breakpoints, and even have the JVM wait for a debugger to connect before starting. There is no equivalent in any other language that does _all_ of these things. And to top this off, there is 0 equivalent to Idea or Eclipse for any other language.
For runtime dynamics, JMX/JConsole is good enough for daily use, Java Flight Recorder gives you deep insight, or in a system you don't have direct access to. Hell even running jstack on a JVM is a good debug tool. If those don't do the trick, there's plain old HPROF (similar to other languages) and Eclipse Memory Analyzer.
>Then of course there's the weird licensing,
The JVM is open source. There are no licensing issues. OpenJDK can be freely downloaded and run in production without restrictions on any use. If you really want to buy a JVM from Oracle... well thats your prerogative.
> it's lack of it factor in 2025,
sdkman
> a huge boatload of legacy holding it back
what legacy code?
Re: Java at 30: Interview with James Gosling
#93Earlier quoted context omitted.
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…
That is an excellent point too. It always made me wonder why I hear about companies who are running very old versions of Java though. It always seemed like backwards compatibility would make keeping up to date with the latest an almost automatic thing.
Java version updates typically change GC behavior. If one has highly tuned setup there is no guarantee that a newer version would not regress.
Another problem is crashes. Java runtime is highly reliable, but still bugs happens.
Re: Java at 30: Interview with James Gosling
#94Earlier quoted context omitted.
I can run basically any Perl code back to Perl 4 (March 1991) on Perl 5.40.2 which is current. I can run the same code on DOS, BeOS, Amiga, Atari ST, any of the BSDs, Linux distros, macOS, OS X, Windows, HP/UX, SunOS, Solaris, IRIX, OSF/1, Tru64, z/OS, Android, classic Mac, and more. This takes nothing away from Java and the Java ecosystem though. The JVM allows around the same number of target systems to run not one…
> I can run THE SAME CODE on DOS, BeOS, Amiga, Atari ST, any of the BSDs, Linux distros, macOS, OS X, Windows, HP/UX, SunOS, Solaris, IRIX, OSF/1, Tru64, z/OS, Android, classic Mac, and more. No, you really can't. Not anything significant anyway. There are too many deviations between some of those systems to all you to run the same code.
Honestly, the main difference I run into is just file paths, and that’s easy to sidestep ( https://perldoc.perl.org/File::Spec ).
There are differences, but they’re usually esoteric ( https://perldoc.perl.org/perlport#PLATFORMS ).
Re: Java at 30: Interview with James Gosling
#95Java 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…
> And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), Java's tools are really top notch. Using IntelliJ for Java feels a whole new different world from using IDEs for other languages. Speaking of Go, does anyone know why Go community is not hot on developing containers for concurrent data structures? I see Mutex this and lock that scattering in Go code, while in Java community the #1 advice on w…
Just implement concurrency with actors and u save up on some locks and mutexes...
The patterns are available, its up to the community to apply proper concurrency patterns.
Re: Java at 30: Interview with James Gosling
#96Earlier quoted context omitted.
Because there was nothing else quite like it at the time most enterprise software was created or recreated. And it's still stable, fast and reliable with a massive ecosystem of stable, fast and reliable libraries and software. With good developer tooling, profilers and debuggers to go with it. And big enterprise support teams from RedHat, Oracle, IBM, etc. throwing in their (paid) support services. It might not be th…
I believe there were alternatives at the time, but expensive. Java was free and also syntactically compatible with C++. I think that rather these properties (than being somewhat unique) are the main causes of its success.
> syntactically compatible with C++
Not. And certainly not semantically.
Re: Java at 30: Interview with James Gosling
#97Mr. Gosling; please hunt down and release the source code for Ace: a syntax-driven C preprocessor.
You can keep the Java, thanks.
Re: Java at 30: Interview with James Gosling
#98Java 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…
> And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), Java's tools are really top notch. Using IntelliJ for Java feels a whole new different world from using IDEs for other languages. Speaking of Go, does anyone know why Go community is not hot on developing containers for concurrent data structures? I see Mutex this and lock that scattering in Go code, while in Java community the #1 advice on w…
It's a core principle.
Don't communicate by sharing memory; share memory by communicating.
Re: Java at 30: Interview with James Gosling
#99James Gosling, Robert Pike and Geoffrey Hinton are my top 3 "Canadians who meaningfully changed things in technology" (tho, I should probably make it a top 5, add Brian Kernighan and figure out someone else)
Kenneth Iverson (APL) could be your fifth even if none of us use APL, its reputation and influence is probably deeper than we realize
Re: Java at 30: Interview with James Gosling
#100Earlier quoted context omitted.
> And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), Java's tools are really top notch. Using IntelliJ for Java feels a whole new different world from using IDEs for other languages. Speaking of Go, does anyone know why Go community is not hot on developing containers for concurrent data structures? I see Mutex this and lock that scattering in Go code, while in Java community the #1 advice on w…
It's a core principle. Don't communicate by sharing memory; share memory by communicating. The overuse of Mutex and Lock are from developers bringing along patterns from other language where they are used to communicating via shared memory. So this aspect of the language just doesn't click as well for many people at first. How long it takes you to get it depends on your experience.
Thanks! What about data structure shared by multiple goroutines? Say, an in-memory cache object? Or do we always have multiple goroutines talk to a dedicated goroutine for the shared value? Would the performance be okay for all use cases? A reason that people use JCTools is that it can easily support hundreds of millions of concurrent reads/writes to its data structures on a 10-year old laptop.