[HN Gopher] Java at 30: Interview with James Gosling
___________________________________________________________________
Java at 30: Interview with James Gosling
Author : chhum
Score : 133 points
Date : 2025-05-16 13:05 UTC (9 hours ago)
(HTM) web link (thenewstack.io)
(TXT) w3m dump (thenewstack.io)
| mark_l_watson wrote:
| Right on, James Gosling's work is amazing, and he and the whole
| Java ecosystem have my gratitude: I went to the first Java World
| Tour conference and wrote a little blog article about it that was
| linked on Sun's home Java page for about a year. I was very
| lucky, and since I was the first search hit for 'Java consultant'
| for a very long time that gave my wife and I the freedom to live
| in a rural area and I could get remote work for a decade.
|
| As long as I am expressing gratitude, I would also like to call
| out the Clojure team for developing a wonderful ecosystem in top
| of Java and the JVM.
|
| It must be wonderful to do work that positively affects the lives
| of millions of people.
| jgneff wrote:
| I am also very grateful to James Gosling. I was working with
| C++ at Taligent (an Apple, IBM, and HP joint venture) in the
| fall of 1995 when I first downloaded Java to give it a try. I
| literally jumped up and down with joy after writing my first
| "Hello, World" program. It was such a breath of fresh air
| compared to the Taligent CommonPoint application framework we
| were building.
|
| I took the severance package when Taligent imploded, dropped
| everything I was doing at the time, and have been working with
| Java and its related software ever since.
| fidotron wrote:
| I think it's incredible with hindsight how Java countered
| many of the mid 90s C++ problems, especially by avoiding
| multiple inheritance.
|
| It remains a shame that it didn't launch with generics
| though, and I still think operator overloading would have
| been good. Had it done so I think a lot more people would
| have stuck around for when the performance improved with
| HotSpot.
| dragandj wrote:
| Both James Gosling (Java) and Rich Hickey (Clojure) are amazing
| creators! Each brought a breath of fresh air to programming at
| their respective times.
| jbellis wrote:
| On my list of programmers I want to meet before it's too late,
| along with Brian Kernighan.
| cloudking wrote:
| Why is Java so popular in enterprise?
| tylerflick wrote:
| My guess is the size of the talent pool to hire from.
| hackthemack wrote:
| I worked in IT from the 90s to today. My perspective is it grew
| and grew because Sun supported it, then IBM supported it,
| RedHat supported it. It had the glimmer that it was the
| "Enterprise Way" of doing "Real IT" programming for "Real
| Businesses". I am not saying any of that is the "Truth", just
| the perception that was held by the majority of people who
| could choose what to write enterprise code in.
| toyg wrote:
| _> Sun supported it, then IBM supported it, RedHat supported
| it_
|
| And Oracle (well before the Sun acquisition - in fact,
| control of Java was basically the main cause of that move).
|
| Any technology that could bag both IBM and Oracle is (or
| rather was) likely to dominate the enterprise space.
| fidotron wrote:
| What was the viable alternative?
|
| Microsoft had C#, at one point IBM pushed SmallTalk. C++ for
| these environments is doable but going to slow you down at
| development a lot, as well as being much harder to secure.
|
| At that time the dynamic alternative was Perl, and that
| remained true basically until Rails came along.
| hackthemack wrote:
| I am not sure. C# came long after Java already made inroads
| into the Enterprise space. It was a different time.
|
| I would say that many things in IT are not chosen on
| technical merits alone. You have people that do not want to
| accrue any blame. Back then, by choosing what IBM endorses
| or what Microsoft endorses, you absolve yourself of fallout
| from if and when things go wrong.
|
| Back in the 90s, it felt like IBM, Redhat, Sun kind of,
| sort of, got together and wanted to keep Microsoft from
| taking over the Enterprise space by offering Java
| solutions.
| nradov wrote:
| Right. Before Microsoft created .NET and C# they first
| tried to play their "embrace, extend, extinguish" trick
| with Java. They released a JVM and "Visual J++" language
| which was sort of Java, but had incompatible proprietary
| extensions to lock customers in to Windows. Eventually
| they were forced to stop that for legal reasons so they
| completely dropped all Java support, and built their own
| replacement virtual machine and associated languages from
| scratch.
| SoftTalker wrote:
| C++ or maybe Objective-C.
|
| Of course those were much more hazardous languages than
| Java.
| aaronbaugher wrote:
| Yes, its early popularity was very much management-driven,
| based on magazine articles and the like. Its object-oriented
| design (often presented as if something new) was supposed to
| make programmers fungible, and its portability was supposed
| to let you build an app that would run on anything. And it
| had a Real Corporation behind it, which appealed to corporate
| management.
|
| In the late 90s, I got stuck making a scheduling program in
| Java, but it had to run on the 16-bit Windows systems of the
| time. That was a huge pain, because the 16-bit version didn't
| have all the capabilities that management was expecting based
| on the hype. These days, I sometimes have to install enormous
| enterprise applications that tie up north of 32G of RAM even
| though they're just basic hardware management tools that
| would take a fraction of that if built in something like C++
| with a standard GUI library. I manage to avoid Java most of
| the time, but it's been an occasional thorn in my side for 30
| years.
| locopati wrote:
| it hits a sweet spot of reliable, C-like, fast enough for most
| things, with a ton of library/framework support. plus Sun and
| later Oracle pushed it hard in the 90s/00s. it'll be the new
| COBOL.
| mpalfrey wrote:
| Decent talent pool.
|
| Decent tooling. Been around for long enough that a lot of the
| quirks of it are well known and documented. Basically it's a
| blue collar programming language without too many gotchas.
| Modern(ish) day Cobol.
|
| (I'm predominantly a Java dev still, even after diversions over
| the years to Javascript, Python and C#).
| lemonwaterlime wrote:
| Among other things, because the structure of the code
| corresponds to the structure of the organization itself.
|
| Things tend to form fractal systems of systems for efficiency.
| A cleanly delineated org chart maps to a cleanly delineated
| codebase.
| keeganpoppen wrote:
| on one level this is clearly "shipping the org chart", but...
| honestly, even as no fan of Java this is clearly efficient on
| many levels, especially when you consider the humans and org
| to be part of the system (which everyone should. or it's just
| my HCI brain talking.).
| eBombzor wrote:
| Spring Boot
| j45 wrote:
| Another way to look at it based on coming across it in
| enterprise:
|
| How did he build something adopted by so many enterprises?
|
| It does some things at scale very well and has been afforded
| the performance improvements of very smart people for 30y.
|
| It's not to say the language isn't verbose, one of my favourite
| features was the ability to write code in other languages right
| inside the a Java app pretty well in-line by using the JVM,
| thanks to JSR-223.
|
| It was possible to write Ruby or Python code via Jruby or
| Jython and run it in the JVM.
|
| https://www.jython.org/
|
| https://www.jruby.org/
|
| Clojure also runs on the JVM.
|
| https://docs.oracle.com/javase/8/docs/technotes/guides/scrip...
| izacus wrote:
| 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 the best language in any of the categories
| (speed - runtime and compile time, tooling, ecosystem,
| portability, employee pool), but there's pretty much almost no
| languages that are as good in all categories at once.
|
| And to top it off, JVM can host other languages so it can
| easily interoperate with more modern takes on language design
| like Kotlin while still running on pretty much all major
| operating systems used in the wild and most CPU architectures
| as well. It'll run on your car's SoC, your phone and on your
| server. In many cases, using the same libraries and same code
| underneath.
| js8 wrote:
| 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.
| zabzonk wrote:
| > syntactically compatible with C++
|
| Not. And certainly not semantically.
| ben7799 wrote:
| Java beta & 1.0 were released my Freshman year of college and
| I've been writing Java ever since. With the exception of one
| job where we tried to write a Java-style Enterprise security
| cloud application in Python every commercial product I've
| worked on has been built in primarily Java, often times with
| other languages on the edges of the application.
|
| The key thing I think with Java is the programming model &
| structure scale well with team size and with codebase size,
| perhaps even in a way that tolerates junior developers,
| outsourced sub-teams, and even lower quality developers. All of
| those things end up becoming part of your reality on big
| Enterprise products, so if the language is somehow adding some
| tolerance for it that is a good thing.
|
| The other things around Syntax and such that people complain
| about? Those are often minor considerations once the team size
| and code base size get large enough. Across my career there has
| always been the lone guy complaining that if we did everything
| in a LISP derived language everything would be perfect. But
| that guy has almost always been the guy who worked on a small
| tool off by himself, not on the main product.
|
| Java has changed a tremendous amount as well. A modern Java
| system has very little in common with something written before
| Generics and before all the Functional code has been added.
| Where I work now we have heavily exploited the Functional java
| add-ons for years, it has been fantastic.
| snovymgodym wrote:
| Because it was in the right place at the right time to supplant
| C++ and C for application code.
| octo888 wrote:
| It's safe. It's easy to hire anyone from anywhere to write
| Java. You generally can't create an ungodly mess apart from
| layers and thousands of classes. There's a library for almost
| everything. It'll still be around in 10/20 years. It's good
| enough
| exabrial wrote:
| 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.
| dragandj wrote:
| Throw in Clojure into the mix, and you get superpowers!
| exabrial wrote:
| I'm still trying to mentally grok the Clojure model and
| syntax hah. On my todo list. Clojure users seem to love it
| though. Do you have a tutorial that could sell it to me?
| dragandj wrote:
| Many Clojure tutorials are free! It's difficult to say
| without knowing nothing about your preference and
| experience. Everyone's welcome to join Clojure Slack
| community (for example) which has several tens of thousands
| of members and dedicated beginners channel. I'm sure if you
| asked there, you'd get tons of recommendations tailored to
| you. https://clojurians.slack.com/
|
| (BTW Clojure, as a Lisp dialect, has almost no syntax. You
| can learn THAT in 5 minutes. The challenge is in training
| your programming mind to think in totally new concepts)
| wry_discontent wrote:
| Start doing any year of Advent of Code with Clojure and
| you'll get it.
|
| They're really amenable to the REPL.
| mark_l_watson wrote:
| My Clojure AI book won't teach you the language, but
| afterward you read through a tutorial my book contains
| interesting examples; read it online
| https://leanpub.com/clojureai/read
| dan_fornika wrote:
| "Clojure for the Brave and True" is free online:
| https://www.braveclojure.com/clojure-for-the-brave-and-
| true/
| znpy wrote:
| > Java memory management seems weird from a Unix Philosophy
| POV, till you understand whats happening. Again, not perfect,
| but a good tradeoff.
|
| The GC story is just great, however. Pretty much the best you
| can get in the entire ecosystem of managed-memory languages.
|
| You have different GC algorithms implemented, and you can pick
| and tune the one that best fits your use-case.
|
| The elephant in the room is of course ZGC, which has been
| delivering great improvements in lowering the Stop-the-world GC
| pauses. I've seen it consistently deliver sub-millisecond
| pauses whereas other algorithms would usually do 40-60 msec.
|
| Needless to say, you can also write GC-free code, if you need
| that. It's not really advertised, but it's feasible.
| nxobject wrote:
| > The elephant in the room is of course ZGC, which has been
| delivering great improvements in lowering the Stop-the-world
| GC pauses. I've seen it consistently deliver sub-millisecond
| pauses whereas other algorithms would usually do 40-60 msec.
|
| As someone who's always been interested in gamedev, I
| genuinely wonder whether that would be good enough to
| implement cutting-edge combo modern acceleration
| structures/streaming systems (e.g. UE5's Nanite level-of-
| detail system.)
|
| I have the ability to understand these modern systems
| abstractly, and I have the ability to write some high-
| intensity nearly stutter-free gamedev code that balances
| memory collection and allocation for predicable latency, but
| not both, at least without mistakes.
| fidotron wrote:
| > As someone who's always been interested in gamedev, I
| genuinely wonder whether that would be good enough to
| implement cutting-edge combo modern acceleration
| structures/streaming systems (e.g. UE5's Nanite level-of-
| detail system.)
|
| The GC would be the least of your problems.
|
| Java is neat, but the memory model (on which the GC relies)
| and lack of operator overloading does mean that for games
| going for that level of performance would be incredibly
| tedious. You also have the warm up time, and the various
| hacks to get around that which exist.
|
| Back when J2ME was a thing there was a mini industry of
| people cranking out games with no object allocation,
| everything in primitive arrays and so on. I knew of several
| studios with C and even C++ to Java translators because it
| was easier to write such code in a subset of those and
| automatically translate and optimize than it was to write
| the Java of the same thing by hand.
| neonsunset wrote:
| > Needless to say, you can also write GC-free code, if you
| need that. It's not really advertised, but it's feasible.
|
| It is not feasible under the JVM type system. Even once
| Valhalla gets released it will carry restrictions that will
| keep that highly impractical.
|
| It's much less needed with ZGC but even the poster child C#
| from the GC-based language family when it comes to writing
| allocation-free and zero-cost abstraction code presents
| challenges the second you need to use code written by someone
| who does not care as much about performance.
| brightball wrote:
| 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.
| cogman10 wrote:
| 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.
| jsight wrote:
| Yeah, that and the portability are really incredible and
| underrated. It is funny, because I constantly hear things
| like "write once, debug everywhere", but I have yet to see
| an alternative that has a higher probability of working
| everywhere.
|
| Although Python is pretty close, if you exclude Windows
| (and don't we all want to do that?).
| bhaak wrote:
| I often run into problems running Python code under
| Linux.
|
| I don't know if it is a me problem or if I'm missing the
| right incantations to set up the environment or whatever.
| Never had that much problems with Java.
|
| But I'm a Java and Ruby person so it might really be
| missing knowledge.
| cestith wrote:
| Python can be tricky with the big differences between 2
| and 3.
| loloquwowndueo wrote:
| Python 3 came out in 2008. If the 2 vs 3 differences are
| still biting you you probably have bigger problems to
| solve (deprecated, insecure, unmaintained dependencies
| for example).
| icedchai wrote:
| As late as 2022, I was at a company still in the middle
| of "migrating" from 2 to 3. I wouldn't be surprised if
| the migration project was still going on. The system had
| gone beyond tech debt and was bordering on bankruptcy.
| jonhohle wrote:
| For anything more than just a one off script, look into
| venv. I've not written any python until this past year
| and can't imagine maintaining an ongoing project without
| it.
|
| Prior to that I would frequently have issues (and still
| have issues with one-off random scripts that use system
| python).
| kevin_thibedeau wrote:
| It's not you. Python packaging has regressed into a worse
| mess than it was 20 years ago. I limit myself to simple
| scripts that only rely on builtins. Anything more
| complicated goes to a more dependable language.
| icedchai wrote:
| I rarely run into issues when using Poetry. If you use
| pip, add packages to requirements.txt willy-nilly and
| don't pin versions then you are asking for trouble.
| jsight wrote:
| Honestly, it isn't just you. I had to hold off on 3.13
| for quite a while too, because of various package
| conflicts. It isn't terrible, especially thanks to things
| like pyenv, but it is far from perfect.
| cestith wrote:
| 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 language but dozens. There's
| JRuby, Jython, Clojure, Scala, Kotlin, jgo, multiple
| COBOL compilers that target JVM, Armed Bear Common Lisp,
| Eta, Sulong, Oxygene (Object Pascal IIRC), Rakudo (the
| main compiler for Perl's sister language Raku) can target
| JVM, JPHP, Renjin (R), multiple implementations of
| Scheme, Yeti, Open Source Simula, Redline (Smalltalk),
| Ballerina, Fantom, Haxe (which targets multiple VM
| backends), Ceylon, and more.
|
| Perl has a way to inline other languages, but is only
| really targeted by Perl and by a really ancient version
| of PHP. The JVM is a bona fide target for so many. Even
| LLVM intermediate code has a tool to target the JVM, so
| basically any language with an LLVM frontend. I wouldn't
| be surprised if there's a PCode to JVM tool somewhere.
|
| JavaScript has a few languages targeting it. WebAssembly
| has a bunch and growing, including C, Rust, and Go.
| That's probably the closest thing to the JVM.
| sigzero wrote:
| > 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.
| maxlybbert wrote:
| 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 ).
| vram22 wrote:
| Interesting about that long list of languages.
|
| There's also Groovy.
|
| I wonder what other languages run on the JVM. What about
| Perl, Icon, SNOBOL, Prolog, Forth, Rexx, Nim, MUMPS,
| Haskell, OCaml, Ada, Rust, BASIC, Rebol, Haxe, Red, etc.?
|
| Partly facetious question, because I think there are some
| limitations in some cases that prevent it (not sure, but
| a language being too closely tied to Unix or hardware
| could be why), but also serious. Since the JVM platform
| has all that power and performance, some of these
| languages could benefit from that, I'm guessing.
|
| #lazyweb
| dotancohen wrote:
| > I can run basically any Perl code back to Perl 4 (March
| 1991) on Perl 5.40.2 which is current.
|
| Yes, but can you _read_ it?
|
| I'm only half joking. Perl has so many ways to do things,
| many of them obscure but preferable for specific cases.
| It's often a write-only language if you can't get ahold
| of the dev who wrote whatever script you're trying to
| debug.
|
| I wonder if modern LLMs could actually help with that.
| johnisgood wrote:
| > I wonder if modern LLMs could actually help with that.
|
| From experience, they can.
| invalidname wrote:
| I just spent 30 minutes trying to get a python package
| running on my Mac... Not feeling that. Pythons version
| compatibility is just awful and the mix of native is
| deeply problematic. Don't get me started on tooling and
| observability.
| cbm-vic-20 wrote:
| I've got a jar that does one small thing and does it well
| that was compiled in 1998. Still works fine, no reason to
| update it.
| brightball wrote:
| 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.
| fpoling wrote:
| 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.
| eppp wrote:
| I know that what you said is supposed to be true. However
| in my real world experience it is anything but. Cisco java
| programs are a disaster and require certain JVMs to run.
| aaronbaugher wrote:
| The enterprise Java applications we use require specific
| versions of specific Linux distros. It's possible that
| they would run on other distros, or even other operating
| systems, if you got the right JVM. But there's enough
| question about it that the companies that sell them for a
| substantial price aren't willing to promise even a little
| portability.
| fpoling wrote:
| I have C++ code from 1997 that I occasionally compile. So
| far it runs. 10 yeas ago compiling with -Wall exposed an
| inconsequential bug and that was it. I suspect when it
| stops to compile it will be from an absence of a particular
| X11 library that I used to parse a config in otherwise
| command-line utility.
|
| Which also points to another thing where Java compatibility
| shines. One can have a GUI application that is from
| nineties and it still runs. It can be very ugly especially
| on a high DPI screen, but still one can use it.
| AnimalMuppet wrote:
| That's not the virtues of Java the _language_. That 's the
| virtues of Java the backward-compatible platform. That is,
| you didn't say anything about the language (syntax and
| semantics), you only talked about backward compatibility.
|
| (It's still a valid point. It's just not the point you
| labeled it as.)
| worik wrote:
| I have been badly burned, twice, by Python's cavalier
| attitude to backwards compatibility
| johnisgood wrote:
| > You can take pretty much any code written for Java 1.0
| and you can still build and run it on Java 24.
|
| This is not my experience with Java at all. I _very_ often
| have to modify $JAVA_HOME.
| jbverschoor wrote:
| Oh yeah. I still don't understand why we even moved away from
| the original JEE model, including the different roles (app
| dev, deployed, etc).
|
| The whole spec was great with the exception of entitybeans.
|
| It provided things that are still not available it anything
| else.. why do we store configuration/credentials in git
| (encrypted, but still).
|
| And the context were easy to configure/enter.
|
| Caucho's resin, highly underrated app server. Maybe not
| underrated, but at least not very well known
| brightball wrote:
| I remember Resin.
|
| I grew to be a big fan of JBoss and was really disappointed
| when the Torquebox project stopped keeping up (Rubyized
| version of JBoss).
| liveoneggs wrote:
| resin was okay but I never got what it offered over tomcat
| icedchai wrote:
| Entity Beans were terrible, representing the height of JEE
| over complexity. I remember editing at least 3 classes, a
| couple interfaces, and some horrific XML deployment
| descriptors to represent an "entity." A lot of the tooling
| was proprietary to the specific app server. On top of that,
| it was slow.
|
| In the early 2000's, I used to work on JEE stuff for my day
| job, then go home and build PHP-based web apps. PHP was at
| least 10x more productive.
| nxobject wrote:
| Third best consistently used over 3 decades adds up to a great,
| great deal. Although, to be fair, a great deal has been
| invested in cutting edge GCs for the JVM - some fresh out of
| research.
| jbellis wrote:
| more like 100x faster than Python/Ruby
|
| and that's before you throw in real multithreading
| tootie wrote:
| The language has/had some rough edges that have been improved
| over the years, but the developer experience of using a
| strongly-typed, object-oriented language within a sturdy IDE
| like Idea is just second to none. The debugging process is so
| very straightforward. Java became synonymous with enterprisey
| bloated systems for good reason, but there is no pile of mud
| Java system that can't be stepped through cleanly with a
| debugger.
|
| I'd also throw in what was possibly their greatest idea that
| sped adoption and that's javadoc. I'm not sure it was a 100%
| original idea, but having inline docs baked into the compiler
| and generating HTML documentation automatically was a real
| godsend for building libraries and making them usable very
| quickly. Strong typing also lined up nicely with making the
| documents hyper-linkable.
|
| Java was really made to solve problems for large engineering
| teams moreso than a single developer at a keyboard.
| Terr_ wrote:
| I find these discussions have an interior split between the
| folks who are more concerned with getting the feature out now
| versus the folks who have had to keep a thousand ancient
| features running.
| badc0ffee wrote:
| > 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.
|
| Fastest at what, exactly?
| jonhohle wrote:
| I'm slightly surprised there isn't more KVM/Virtualized bare
| metal JVM environments. While I haven't used it in a while,
| the decade+ I spent running Javan's in production basically
| have the entire system over to the JVM (with some overhead
| for some small non-JVM background daemons). Most things were
| built not to use POSIX standards, but Java equivalents.
| Occasionally direct file system access for writes was
| necessary (logging being a big exception).
|
| So giving the entire system to the JVM, performing some
| warmup prior to a service considering itself "healthy", and
| the JVM was reasonably fast. It devoured memory and you
| couldn't really do anything else with the host, but you got
| the Java ecosystem, for better or worse).
|
| There was a lot of good tooling that is missing from other
| platforms, but also a ton of overhead that I am happy to not
| have to deal with at the moment.
| briankelly wrote:
| Having a hard time finding it now, but someone put together a
| benchmark with two categories - naive and optimized -
| comparing implementations across languages with a workload
| vaguely resembling a real-world business application server
| with a mix of long and short lived objects. Java was at the
| top of the naive benchmark by a landslide and behind C and
| C++ (edit: and probably Rust) for the optimized ranking, but
| with a gap before the rest of the field.
|
| With the JVM you basically outsource all the work you need to
| do in C/C++ to optimize memory management and a typical
| developer is going to have a hell of a time beating it for
| non-trivial, heterogenous workloads. The main disadvantage
| (at least as I understand) is the memory overhead that Java
| objects incur which prevent it from being fully optimized the
| way you can with C/C++.
| lelanthran wrote:
| > Java performance isn't the fastest, that's ok, a close 3rd
| place behind C/CPP ain't bad.
|
| When Java got popular, around 1999-2001, it _was not_ a close
| third behind C (or C++).
|
| At that time, on those machines, the gap between programs
| written in C and programs written in Java was about the same as
| the gap right now between programs written in Java and programs
| written in pure Python.
| javier2 wrote:
| > Java syntax isn't perfect, but it is consistent, and
| predictable
|
| This is something I greatly value with the recent changes to
| Java. They found a great way to include sealed classes, switch
| expression, project Loom, records that feels at home in the
| existing Java syntax.
|
| The tooling with heap dump analyzers, thread dump analyzers, GC
| analyzers is also top notch.
| aardvark179 wrote:
| I think Gavin Bierman is an unsung hero as far as steering
| the Java language is concerned. I had the privilege to sit
| next to him in the office when I was working on TruffleRuby,
| and our conversations on language design were always
| elucidating, and his ability to gently steer others away from
| pitfalls was something I wish I could do as well.
|
| Hearing the work he and others did to gradually introduce
| pattern matching without painting themselves into a corner
| was fascinating and inspiring.
| neonsunset wrote:
| > a close 3rd place behind C/CPP
|
| Not anymore, the competition is doing much better these days.
| hintymad wrote:
| > 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 writing concurrency code is to use
| Java's amazing containers. Sometimes, I do miss the
| java.util.concurrent and JCTools.
| zwnow wrote:
| 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.
| paulddraper wrote:
| The x86 instruction set is available as well.
| PaulDavisThe1st wrote:
| The only replacement for locks/mutexes is a lock free data
| structure. Locks are not what make concurrency possible,
| they are what makes it data-safe.
|
| You can use platform threads, user-space threads, language-
| provided "green" threads, goroutines, continuations or
| whatever you wish for concurrency management, but that's
| almost orthogonal to data safety.
| eikenberry wrote:
| 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.
| hintymad wrote:
| 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.
| fidotron wrote:
| My experience is a shocking amount of the golang community
| believe channels are a performance problem for whatever
| they're doing, and they use mutexes in some misguided
| effort at optimization.
|
| But then I have also encountered Rust people that will look
| down on Java but had no idea buffered I/O had higher
| throughput than unbuffered.
| interleave wrote:
| I miss writing Java 1.4 with Eclipse and svn. Even though I am
| also super-happy with Ruby and Swift today, I know that
| control-space flow. Good times!
|
| Edit: 1.4, not 1.7
| lkuty wrote:
| I am wondering what was the role of Guy L. Steele in the creation
| of Java if he had any. From the article, it looks like it was
| Gosling alone. I did not cheat by checking on Wikipedia
| steelbird wrote:
| He worked on it after, no?
| neom wrote:
| James 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)
| cmrdporcupine wrote:
| Kenneth Iverson (APL) could be your fifth even if none of us
| use APL, its reputation and influence is probably deeper than
| we realize
| toprerules wrote:
| I 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 our aspirations away
| and embrace mediocrity.
|
| My other issues with the JVM is how much of a black box it is
| from a platform perspective, which makes debugging a PITA with
| standard ops tools like strace, gdb, etc. The JVM's over
| allocation of memory robs the kernel of real insight as to how
| the workload is actually performing. When you use the JVM, you
| are completely locked in and god help you if there isn't a JVM
| expert to debug your thing and unravel how it translates to a
| platform implementation.
|
| Then of course there's the weird licensing, it's association with
| Oracle, managing JDK versions, it's lack of it factor in 2025,
| and a huge boatload of legacy holding it back (which is not
| unique to Java).
|
| I have successfully navigated my career with minimal exposure to
| Java, and nowadays there's a glut of highly performant languages
| with GC that support minimal runtimes, static compilation, and
| just look like regular binaries such that the problems solved by
| something like the Java or Python VMs just aren't as relevant
| anymore - they just add operational complexity.
|
| To reiterate, I admire JG just like any tech person should.
| Java's success is clear and apparent, but I'm glad I don't have
| to use it.
| the_overseer wrote:
| IT factor! Am I on a fashion website now? What kind of argument
| is that? Also, why on earth would you use strace or gdb for
| Java? It has enormously performant debugging tools in the JDK.
| Also, IDE debugging integration is second to none.
| exabrial wrote:
| >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?
| marginalia_nu wrote:
| > what legacy code?
|
| The Java API has its fair deal of baggage due to its extreme
| backward compatibility. Boolean.getBoolean[1] is one of the
| more accessible examples of a bad API that exists only
| because of legacy reasons, but there quite a number of them.
|
| [1] https://docs.oracle.com/javase/8/docs/api/java/lang/Boole
| an....
| throwaway7783 wrote:
| In my 20+ years using java, not once have I used strace or gdb.
| Java itself has fantastic debugger support, and IDEs have built
| in step through capabilities.
|
| Mentioning Java and Python in the same way in the context of
| performance is really odd. Python is nowhere near the JVM when
| it comes to performance
| briankelly wrote:
| The tooling is pretty easy to learn if scary looking at first
| and becoming a JVM expert, at least in the context of GC
| tuning, might take you a week or less. Some of the defaults are
| surprising though.
|
| And I think there is some parallel with the kernel vs GC and
| mmap vs buffer pools - the GC simply has better context in the
| scope of the application. With other processes in the picture,
| though, yeah there is some provisioning complexity there.
| aabajian wrote:
| Just going to remind y'all of this:
| https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...
|
| I went to a Java school. I remember my operating systems class
| involved writing _simulated_ OS code in Java (for example, round
| robin for context switching). The argument was that it would be
| easier to understand the algorithms if the hardware complexities
| were minimized. I understand that sentiment, but I don 't think
| Java was the right choice. Python would have accomplished the
| same task even better (understanding algorithms). I think there
| was a huge influence from industry to teach college students Java
| from day one. I had taught myself BASIC and some C back in high
| school, so it was a bit of a step backwards to learn a high-level
| language just to do simulated low-level OS programming.
| cbm-vic-20 wrote:
| A lot of the arguments Joel makes in that article also apply to
| Python, and pretty much any other higher-level language that
| doesn't make you think about pointers. Ironically, he points
| out the Google had a great leap over Microsoft with MapReduce,
| which was built in Java.
| jonhohle wrote:
| Back in the early 2000s, I was taught in C, C++, Motorola
| 68HC11, and MIPs assembly. I can clearly understand how Java
| works, even if I don't know its GC is implemented. I can
| understand how programs were written from the 80s to
| currently. Had I learned programming in Java or, worse,
| Python, I doubt I'd have the same understanding. It's
| relatively easy to go from low level to high level languages
| if you're willing to give up control. My experience is that
| the opposite is less true. It's certainly possible, but not
| as straightforward as understanding some foundational ideas.
| briankelly wrote:
| My school started us off in microcontroller programming in C
| then Java for intro to data structures and OOP then back to C
| (and MIPS assembly) for systems/OS/concurrency. One thing I
| appreciate Java over Python for DS/Algo is the clear
| delineation between abstract data type and underlying data
| structure - IMO is easy to get a wrong mental model with
| Python. But teaching OS concepts in Java seems a little crazy
| to me.
| Koshkin wrote:
| Hm... Why? Java seems to be a perfect language in which to
| understand things at a _conceptual_ level!
| briankelly wrote:
| Good to get your hands in the dirt as well.
| PathOfEclipse wrote:
| I've been working in .NET/C# for the past few years, and while
| I'm happy with it, I still think the JVM/Java are the best
| ecosystem overall I've worked in. It's amazing how many things
| the Java ecosystem gets right that .NET gets wrong.
|
| For instance, Java introduced the fork/join pool for work
| stealing and recommended it for short-lived tasks that decomposed
| into smaller tasks. .NET decided to simply add work-stealing to
| their global thread pool. The result: sync-over-async code, which
| is the _only_ way to fold an asynchronous library into a
| synchronous codebase, frequently results in whole-application
| deadlocks on .NET, and this issue is well-documented:
| https://blog.stephencleary.com/2012/07/dont-block-on-async-c...
|
| Notice the solution in this blog is "convert all your sync code
| to async", which can be infeasible for a large existing codebase.
|
| There are so many other cases like this that I run into. While
| there have been many mistakes in the Java ecosystem they've
| mostly been in the library/framework level so it's easier to move
| on when people finally realize the dead end. However, when you
| mess up in the standard library, the runtime, or language, it's
| very hard to fix, and Java seems to have gotten it more right
| here than anywhere else.
| neonsunset wrote:
| > frequently results in whole-application deadlocks on .NET
|
| Tell us you don't write any sort of .NET code without telling
| us so explicitly.
|
| You should pick a platform you have better command of for back-
| handed comments.
|
| Or at least you should try to do a better job than referencing
| a post from 13 years ago.
| PathOfEclipse wrote:
| That's a very harsh reply with zero evidence behind it. Based
| on your response, I am willing to bet I understand the
| platform better than you do. And the deadlocks I'm referring
| to are happening in apps written by other people who've been
| in the .NET ecosystem exclusively for more than a decade, or
| even two decades.
|
| Here's an article from 5 years ago:
|
| https://medium.com/criteo-engineering/net-threadpool-
| starvat...
|
| But does citing a more-recent article matter to you? Probably
| not. A source being 13 years old only matters if something
| relevant has changed since then, and you certainly couldn't
| be bothered to point out any relevant change to support your
| otherwise fallacious and misleading comment.
|
| What actually amazes me most about this is that people in
| .NET seem to want to blame the person writing sync-over-async
| code like they are doing something wrong, even going so far
| as to call it an "anti-pattern", when in reality it is the
| fault of poor decision-making from the .NET team to fold
| work-stealing into the global thread queue. The red-blue
| function coloring problem is real, and you can't make it go
| away by pretending everyone can just rewrite all their
| existing synchronous code and no other solution is needed.
|
| If all you know is one ecosystem, then it seems you are
| susceptible to a form of Stockholm syndrome when that
| ecosystem abuses you.
| neonsunset wrote:
| > But does citing a more-recent article matter to you?
|
| It does. For example, starting with .NET 6 there is a pure
| C# threadpool implementation that acts differently under
| problematic scenarios.
|
| You do not understand performance profile and _UX_ pros
| /cons of why async model is better than opting into
| stackful coroutine based design. You're probably of opinion
| that the only way to use async is to always await
| immediately rather than idiomatically composing
| tasks/futures.
|
| I'm certain you're basing this off of your personal
| experience from more than a decade ago of some forsaken
| codebase written in an especially sloppy way. Do you know
| why sloppy async code is possible in the first place?
| That's because even the initial threadpool implementation
| was so resilient.
|
| Because that's where this kind of sentiment from supposed
| "seasoned experts" on .NET stack usually comes from.
|
| Moreover, there isn't a single mention that the real way to
| get into actual deadlock situation is when dealing with
| applications enriched with synchronization context. You
| will only ever run into this in GUI scenarios, where .NET's
| implementation of async continues to be a better
| alternative to reactive frameworks or, worse, manual
| threading.
|
| > If all you know is one ecosystem, then it seems you are
| susceptible to a form of Stockholm syndrome when that
| ecosystem abuses you.
|
| Pathetic attempt at strawman.
|
| My opinion of .NET kept improving since .NET Core 2.1/3.1
| days up until today _because_ of researching the details of
| and getting exposed to other languages (like Rust, Go,
| Java, Kotlin, Swift, C and C++, you name it).
|
| Hell, I'm not even arguing that what we have today is the
| holy grail of writing concurrent and parallel programs,
| only that most other alternatives are worse.
| PathOfEclipse wrote:
| > For example, starting with .NET 6 there is a pure C#
| threadpool implementation that acts differently under
| problematic scenarios.
|
| We're seeing this issue entirely in .NET core. We started
| on .NET 6, are currently on .NET 8, and will likely
| migrate to 10 soon after it is released. It's again worth
| mentioning that you provide zero evidence that .NET 6
| solves this problem in any way. Although, as we will see
| below, it seems like you don't even understand the
| problem!
|
| > I'm certain you're basing this off of your personal
| experience from more than a decade ago of some forsaken
| codebase written in an especially sloppy way.
|
| No, I'm referring to code written recently, at the job I
| work at now, at which I've been involved in discussions
| about, and implementations of, workarounds for the issue.
|
| > Moreover, there isn't a single mention that the real
| way to get into actual deadlock situation is when dealing
| with applications enriched with synchronization context.
|
| 100% false. This deadlock issue has nothing to do with
| synchronization contexts. Please actually read the 2020
| article I linked as it explains the issue much better.
|
| > Pathetic attempt at strawman.
|
| I realize responding to this is to just fight pettiness
| with more pettiness, but I can't resist. You should
| probably look up the definition of a strawman argument
| since you are using the word incorrectly.
| neonsunset wrote:
| To me a claim "how many things the Java ecosystem gets
| right that .NET gets wrong" borders on insanity if we
| consider having to interact with Maven or even Gradle on
| a daily basis after .NET's CLI and NuGet, or having to
| deal with type erasure in generics, or weird stream API
| shape, or not having common slice and sequence types that
| everything nicely unifies under because primitives cannot
| be generalized, or not being able to author properties
| and extension methods, creating dozens upon dozens of
| type copies or just boilerplate accessors, or having to
| tolerate Hibernate after EF Core, and so on and so forth.
|
| As for async and tasks - have you ever considered just
| not writing the code that is so bad it managed to bypass
| cooperative blocking detection and starvation
| mitigations? It's certainly an impressive achievement if
| you managed to pull this off while starting with .NET 6.
|
| Edit: I agree with the subsequent reply and you are
| right. Concurrency primitives are always a _contentious_
| topic.
| PathOfEclipse wrote:
| I have no problem with you preferring .NET to Java, and I
| apologize that my first-cited article was not the best
| one to share to describe the problem (I should have read
| it more carefully first), but if you had responded with
| something like:
|
| "Your deadlock scenario is related to synchronization
| contexts and can be avoided by ..."
|
| rather than:
|
| "You clearly don't know what you're talking about (but I
| won't bother telling you why)"
|
| Then we could have had a much more productive and
| pleasant conversation. I would have responded with:
|
| "Sorry, that article wasn't the right one to share. Here
| is a better one. The issue I am talking about isn't
| synchronization context-related at all. It's actually
| much more insidious."
| octo888 wrote:
| > having to tolerate Hibernate after EF Core,
|
| Enjoying or tolerating Hibernate is undiagnosed Stockholm
| Syndrome :D
| MarkSweep wrote:
| The thread pool starvation problem in .NET is annoying when you
| encounter it. Personally I have not bumped into since the .NET
| framework days.
|
| The thread pool implementation has been tweaked over the years
| to reduce the impact of this problem. The latest tweak that
| will be in .NET 10:
|
| https://github.com/dotnet/runtime/pull/112796
|
| I'm not sure a thread pool implementation can immune to misuse
| (many tasks that synchronously block on the completion of other
| tasks in the pool). All you can do is add more threads or try
| to be smarter about the order tasks are run. I'm not a thread
| pool expert, so I might have no idea what I'm talking about.
| geodel wrote:
| > Growing up with "pretty close to zero money,"
|
| Zero money programmers >> Zero interest rate programmers :-)
| snovymgodym wrote:
| Java, especially modern Java, is a fine language. The JVM is an
| awesome runtime. I'm tired of pretending it isn't.
| kaliszad wrote:
| The java.net.Inet4Address and Inet6Address could be more
| lightweight.
|
| For a simple IPv4 address normally representable using 4 bytes/
| 32 bits Java uses 56 bytes. The reason for it is Inet4Address
| object takes 24 B and the InetAddressHolder object takes another
| 32 B. The InetAddressHolder can contain not only the address but
| also the address family and original hostname that was possibly
| resolved to the address.
|
| For an IPv6 address normally representable using 16 bytes/ 128
| bits Java uses 120 bytes. An Inet6Address contains the
| InetAddressHolder inherited from InetAddress and adds an
| Inet6AddressHolder that has additional information such as the
| scope of the address and a byte array containing the actual
| address. This is an interesting approach especially when compared
| to the implementation of UUID, which uses two longs for storing
| the 128 bits of data.
|
| Java's approach is causing 15x overhead for IPv4 and 7.5x
| overhead for IPv6 which seems excessive. What am I missing here?
| Can or should this be streamlined?
| dmurray wrote:
| What a wonderfully HN response to a biographical piece on James
| Gosling.
|
| For my part, most of the Java code that I have written that
| needs to use IP addresses needs somewhere between 1 and 10 of
| them, so I'd never notice this overhead. If you want to write,
| like, a BGP server in Java I guess you should write your own
| class for handling IP addresses.
| klim2media wrote:
| My biggest gripe with Java is the only really viable IDE option
| is from a for-profit company and that it routinely gobbles up my
| RAM. I used Eclipse and Netbeans back in the day but IntelliJ is
| superior before it becomes unusable.
| whartung wrote:
| Ode to Java. Boy, I love Java. When I switched jobs way back, a
| condition was that the new project was going be using Java.
|
| GC. Single file modules. No "forward". The Collection suite. Fast
| compiles.
|
| The magic of the ClassLoader. The ClassLoader, that was
| insightful. I don't know how much thought went into that when
| they came up with it, but, wow. That ClassLoader is behind a
| large swath of Java magic. It really hasn't changed much over
| time, but boy is it powerful.
|
| When I started Java, I started it because of the nascent Java web
| stack of the day. Early servlets and JSP. I picked because of two
| things. One, JSPs were just Servlets. A JSP was compiled down
| into a Servlet, and shazam, Servlet all the way down. Two, single
| language stack. Java in JSPs, Java in Servlets. Java in library
| code. Java everywhere. In contrast to the MS ASP (pre .NET)
| world.
|
| Mono-language meant my page building controller folks could talk
| to my backend folks and share expertise. Big win.
|
| Servlets were a great model. Filters were easy and powerful. Free
| sessions. Free database connection pools in the server. I mean,
| we had that in '98, '99.
|
| And, of course, portability. First project was using Netscapes
| server, which was spitting up bits 2 weeks before we went live,
| so we switched to JRun in a day or two (yay standard-ish
| things...). Then, Management(tm) decided "No, Sun/Oracle, we're
| going NT/SQL Server". Oh no. But, yup, transitioned to that in a
| week. Month later, CTO was fired, and we went back to Sun/Oracle.
|
| Java EE had a rough start, but it offered a single thing nobody
| else was offering. Not out of the box. Not "cheap", and that was
| a transaction manager, and declarative transactions on top of
| that. We're talking about legit "Enterprise grade" transaction
| manager. Before you had Tuxedo, or MS MTS. Not cheap, not "out of
| the box", not integrated. JBoss came out and gave all that tech
| away. Then Sun jumped on with early, free, Sun Java Enterprise 8
| which begat Glassfish which was open source. Glassfish was
| amazing. Did I mention that the included message queues are part
| and parcel of the integrated, distributed transaction model for
| Java EE? Doesn't everyone get to rollback their message queue
| transactions when their DB commit fails? Message Driven Beans,
| _sigh_ , warms my heart.
|
| There were certainly some bad decisions in early Java EE. The
| component model was far too flexible for 95% of the applications
| and got in the way of the Happy Path. Early persistence (BMP,
| CMP) was just Not Good. We punted on those almost right away and
| just stuck with Session Beans for transaction management and
| JDBC. We were content with that.
|
| The whole "everything is remote" over CORBA IIOP and such. But
| none of that really lasted. EJB 3 knocked it out of the park with
| local beans, annotations in lieu of XML, etc. Introduction of the
| JPA. Modern Jakarta EE is amazing, lightweight, stupid powerful
| (and I'm not even talking Spring, that whole Other Enterprise
| Stack). There's lots of baggage in there, you just don't have to
| use it. JAX-RS alone will take you VERY far. Just be gentle, Java
| Enterprise offers lots and lots of rope.
|
| None of this speaks to the advances in the JVM. The early HotSpot
| JIT was amazing. "Don't mind me, I'm just going to seamlessly
| sneak in some binary compiled code where that stack machine stuff
| was a nano-second ago. I've been watching it, this is better. Off
| you go!" Like presents from Santa. The current rocket ship that
| in JDK development (this is good and bad, I still do not like the
| Java 9 JPMS module stuff, I think it's too intrusive for the vast
| majority of applications). But OpenJDK, the Graal stuff. Sheesh,
| just get all light headed thinking about it.
|
| Along with the JVM we have the JDK, its trivial install. Pretty
| sure I have, like, 20 of them installed on my machine. Swapped
| out with a PATH and JAVA_HOME change. The JVM is our VM, the
| Servlet container is our container. Maven is our dependency
| manager. Our WAR files are self-contained. And all that doesn't
| go stomping on our computer files like Paul Bunyan and Blue
| making lakes in Minnesota.
|
| It's no wonder I was struggling to grok all the talk about VMs,
| Dockers, and containers and all that stuff folks mess with to
| install software. We never had to deal with that. It just was not
| an issue.
|
| I can distribute source code, with a pom.xml, and a mvnw wrapper
| script, and anyone can build that project with pretty much zero
| drama. Without breaking everything on their system. And whatever
| IDE they're using can trivially import that project. It's also
| fast. My current little project, > 10K lines of code, < 3s to
| clean/build/package.
|
| Obviously, there's always issues. The Stories folks hear are all
| true. The legacy stuff, the FactoryInterfaceFactoryImpl stuff.
| The Old Days. It's all real. It's imperfect.
|
| But, boy, is it impressive. (And, hey, portable GUI folks, Java
| FX is pretty darn good...)
| kccqzy wrote:
| The servlet really is a powerful concept behind a bad name.
| I've seen more than once where people reinvent servlets in
| other languages.
| Koshkin wrote:
| Also, ls and mservices...
| theanonymousone wrote:
| 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.
| kazinator wrote:
| Mr. Gosling; please hunt down and release the source code for
| _Ace: a syntax-driven C preprocessor_.
|
| You can keep the Java, thanks.
| w10-1 wrote:
| Java is a great success story. Though, to be fair, James Gosling
| was the spark but has not been the steward.
|
| Even as early as Java 1.1 and 1.2 he was not particularly
| involved in making runtime, library, or even language decisions,
| and later he wasn't the key to generics, etc.
|
| Mark Reinhold has been the hand's-on lead since 1.1, first
| integrating early JIT's, HotSpot, the 1.2 10X class explosion,
| and has been running the team all the way through Oracle's
| purchase, making the JVM suitable for dynamic language like
| Kotlin and Clojure, open-sourcing, moving to a faster release
| cadence, pushing JVM method and field handles that form the basis
| for modern language features, migrating between GC's, and on and
| on.
|
| As far as I can tell, everything that makes Java great has come
| down to Mark Reinhold pushing and guiding.
| elric wrote:
| The whole core team is amazing. Gosling wanted a language that
| was practical from a development POV. Over the years, it's been
| refined into a language with a fair amount of mechanical
| sympathy on top of the development experience. Thanks to folks
| like Mark Reinhold and Brian Goetz.
|
| I have no love for Oracle the big bad company. But I am deeply
| greatful they've managed to keep that group moving forward.
| rootbear wrote:
| When Gosling was at Sun, he was one of two principal architects
| of the NeWS Window system. The X Window system was designed for
| "dumb" display devices and so the display elements were all
| static, not requiring much work from the server. NeWS was
| designed to run on a (Sun) workstation, where there was a lot of
| computational power available, so it was based on Postscript. A
| NeWS client would send a program to the server, not just static
| commands.
|
| Gosling, unsurprisingly, designed Java with the NeWS model in
| mind, where web pages were programs, not just static HTML
| documents. When I got him to sign my copy of "The Java
| Programming Language", I asked him if Java was the revenge of
| NeWS. He just smiled.
| AStonesThrow wrote:
| The corollary of this was Display PostScript. At my first job
| we had a SPARCStation 2 with a SPARCprinter. The SPARCStation
| was a mighty wonder to behold, with a storage pedestal and a
| lovely OpenWindows GUI on a luxurious Sun monitor and color
| framebuffer. The operator sitting at the desk was often just a
| novice clerical worker, but we ran a few Internet services on
| the machine as well. However, our department depended on that
| SPARCprinter to spit out hundreds of sheets of paper daily.
|
| We could not depend on the printer to stay functional, though.
| Have you heard of a Winmodem? SPARCprinters were essentially
| that: they were configured as a "dumb display device" where all
| the imaging logic was contained in the software and run on the
| server. A page was written in PostScript, rendered on the print
| server, and dispatched to the printer as if it were a
| framebuffer/monitor.
|
| Unfortunately, for whatever reason, the server software was not
| so reliable, or the printer hardware wasn't reliable, and
| because of this peculiar symbiotic parasitism, whenever our
| printer wedged, our server was also toast. Every process went
| into "D" for device wait; load averages spiked and all our work
| ground to a halt. We would need to pull the worker off the
| desktop, reboot the whole server, and start over with the
| printer.
|
| That printer haunted my dreams, all though my transition from
| clerk, to network operator, to sysadmin, and it wasn't until
| 2011 when I was able to reconcile with printers in general. I
| still miss SunOS 4 and the whole SPARC ecosystem, but good
| riddance to Display PostScript.
| nelup20 wrote:
| I personally appreciate Java (and the JVM) much more after having
| tried other languages/ecosystems that people kept saying were so
| much better than Java. Instead, I just felt like it was a "the
| grass is greener" every time. The only other language that I felt
| was an actual massive improvement is Rust (which so far has been
| a joy to work with).
|
| It's a shame imo that it's not seen as a "cool" option for
| startups, because at this point, the productivity gap compared to
| other languages is small, if nonexistent.
| sapiogram wrote:
| My feelings exactly. Go was particularly disappointing, it
| promised everything but only felt like a sidegrade from Java.
| Screw it, a downgrade, until go errors get stack traces.
| overfeed wrote:
| The reason _I_ prefer the Go ecosystem to Java is cultural,
| rather than technical. Sure, the JVM is very impressive and
| the language has been evolving, but the culture around Java
| seems to encourage needless complexity.
|
| Of all the languages I've had to work with trying to get to
| know unfamiliar code-bases, it's the Go codebases I've been
| quickest to grok, and yielded the fewest surprises since as
| the code I'm looking for is almost always where I expect it
| to be.
| skydhash wrote:
| I think kotlin is what Java should have been like. The same
| capabilities but with less cumbersome constraints.
| ori_b wrote:
| When I used Kotlin, it felt like Java, but with the
| antipatterns baked in as language features.
| whartung wrote:
| The don't embrace that culture. Embrace a simpler culture.
| Strive for simplicity. Push for fewer dependencies.
|
| Simple example, JAX-RS running on top of Java SE. I agree,
| JAX-RS is not what one might call "simple". It IS complex,
| or I should say, it CAN be complex. But Happy Path, staying
| in the middle of the road, it's pretty sweet for knocking
| out HTTP backed services. The Jersey reference
| implementation will do most anything you need (including
| stuff not "included" in raw JAX-RS). No need for a
| container, no need for a lot that stuff and all that
| hanger-on. The core runtime is pretty broad and powerful.
|
| Consider my current project, it uses the built in Java HTTP
| server. Which works! It's fast, it's functional, it's free.
| (Yes, it's in a com.sun.net... package, but it's not going
| anywhere.) It's awkward to use. It's aggravatingly raw. It
| follows the tenet "why be difficult, when, with just a
| little effort, you can be impossible."
|
| So, I wrote a simple "servlet-esque-ish" inspired layer for
| response and request handling, a better path based regex-y
| router, and a nicer query parser for queries and forms. 500
| lines. Add on a JSON library and I can process JSON-y web
| request/response, easily. (I also wrote my own Multipart
| processor -- that was another 500 lines, boy that was fun,
| but most folks don't need that.)
|
| A little bit of code and the built in server is MUCH easier
| to use. No tomcat, no deploys, zip. ...and no dependencies
| (save the JSON library).
|
| Something all of these cool frameworks and such have shown
| me is what's really nice to have, but at the same time,
| just what isn't really necessary to get work done. I mean,
| CDI is really neat. Very cool. But, whoo boy. So I have a
| single singleton to handle application life cycle and
| global services. It works great with tests. I have a 50
| line Event Bus. I have a 100 line "Workflow Engine". 150
| line java.util.Logger wrapper (which is mostly, you know,
| wrapper). I wrote that way back whenever they introduced
| varargs to java (Java 5? 6?). The modern Java logging
| landscape is just...oh boy. I'm content with JUL -- I can
| make it work.
|
| My current project is "magic free". I think @Overide in the
| single annotation anywhere in it. But it's comfortable to
| use, the cognitive load is quite load (outside of the
| actual application itself, which is NOT low -- sheesh). No
| swearing at frameworks. It's all my fault :).
|
| Anyway, the point is that "simple Java" lurks in there. It
| needs a bit of uplifting, but not a lot.
| LtWorf wrote:
| True, but the culture around go isn't any better. In my
| experience go developers are former java developers so they
| have the same culture of thinking it's ok to ignore how a
| unix system works. So you will have awful logging, daemons
| that never report they're ready, badly handmade command
| line parsing and so on.
| arccy wrote:
| funny. java is known for its stacktraces where you need 3
| vertical monitors stacked together to see the whole thing and
| it still doesn't tell you anything useful about why the app
| crashed.
| marginalia_nu wrote:
| I think that's a bit unfair. Generally the stacktraces tell
| you exactly what and where the problem is. Generally
| shouldn't be more than a dozen lines or so.
|
| The main area they get excessively lengthy is in certain
| frameworks and testing tools that can add like 100 lines to
| the trace.
| bdangubic wrote:
| same! mid-way through my almost 3 decade career I got bored and
| thought lets try some non-JVM projects, for 2 years I took
| projects using other languages etc... worse two years of my
| career :)
| bsaul wrote:
| Funny. I've been trying rust for the past 2 months fulltime,
| and i'm really wondering how you can call it a "joy to work
| with" when compared to java, at least for server development.
|
| Rust feels like walking on a minefield, praying to never meet
| any lifetime problem that's going to ruin your afternoon
| productivity ( recently lost an afternoon on something that
| could very well be a known compiler bug, but on a method with
| such a horrible signature that i never can be sure. in the end
| i recoded the thing with macros instead).
|
| The feeling of typesafety _is_ satisfying , i agree. But
| calling the overall experience a "joy" ?
| mynameisash wrote:
| > I've been trying rust for the past 2 months fulltime,
|
| > recently lost an afternoon on something that could very
| well be a known compiler bug
|
| With respect, at two months, you're still in the throes of
| the learning curve, and it seems highly unlikely you've found
| a compiler bug. Most folks (myself included) struggled for a
| few months before we hit the 'joyful' part of Rust.
| johnisgood wrote:
| Okay, but I have hit the joyful part of some other
| languages long before a few months. What gives?
| bsaul wrote:
| i didn't "find" it. As i said, it's a well known one :
| https://github.com/rust-lang/rust/issues/64552
|
| Simply using axum with code using multiple layers of async
| was enough.
|
| But then again, it _looked_ like this bug (the error
| message is the same), however at this point i 'm really
| unsure if it's exactly the same. The error message and the
| method signature was so atrocious that i just gave up and
| found a simpler design using macros that dodged the bullet.
| heavyset_go wrote:
| IME, new users do weird things that can expose bugs no one
| ran into because they wouldn't think to do things the weird
| way.
| asa400 wrote:
| I'm not discounting your experience, or saying you're wrong
| or anything like that. I've been writing Rust for a while,
| and for me, that feeling went away. Lifetime/ownership
| problems used to run me over but it almost never happens
| anymore. I think Rust has a rather severe "hump" that a lot
| of people run headlong into, but it does get better, I
| promise you. You start thinking in ownership/borrowing terms
| and it just fades into the background at some point. Rust is
| easily my most productive language now. Again, not
| discounting your experience at all, it can be rough starting
| out.
| bsaul wrote:
| i do feel much more comfortable with lifetimes than at the
| beginning. I get the general concept, and i barely have to
| explicitely set them (i did start by religiously reading
| the rust book, of course).
|
| However, at the moment i still feel i'm using a huge amount
| of layers upon layer of complex type definitions in order
| to get anything done. Just using an object's reference
| across async calls in a safe manner leads to insane types
| and type constraints, which read like ancient egyptian
| scripture. And at every layer, i feel like changing
| anything could blow everything up with lifetimes.
|
| The language has this very special feel of something both
| advanced and extremely raw and low-level at the same time.
| It's very unique.
| charlotte-fyi wrote:
| In my experience, beginners often make the mistake of
| assuming just because you _can_ do things with references
| and lifetimes that you _should_. Unless you've done
| profiling, just start with the easy thing and clone an
| `Arc` (or whatever other data structure helps you avoid
| lifetime problems)!
|
| Also, it's worth saying, you probably don't need async.
| bsaul wrote:
| oh, believe me, cloning and Arc-ing is something i
| realized very early that i was going to use. But that's
| the point: you still end up with this like :
| Arc<tokyo::RwLock<dyn MyTrait>> for every single
| dependency.
|
| Then you want to declare a function that takes a closure
| over that dependency. And you end up with a total garbage
| of a method signature.
| worik wrote:
| > I've been trying rust for the past 2 months fulltime
|
| Rust has a horrid learning curve
|
| I've programmed for decades in many languages, and I felt the
| same as you
|
| Persevere.
|
| Surrender! to compile
|
| Weather the ferocious storm
|
| You will find, true bliss
| bsaul wrote:
| I am keeping up, but honestly i feel like rust dev is a bit
| like a trap : people like us love challenges and solving
| technical problems. So whenever we "triumph" over a rust
| tricky compilation issue, we feel intense gratification in
| solving it.
|
| However, at some point you have to ask yourself _why_ you
| 're accepting to face all those challenges. Is it worth it
| ? When was the last time i faced a race condition when
| developping a backend ?
|
| The reason i started with rust was for a very specific need
| on building a cross-platform library (including wasm), and
| that was a good justification, and i'm happy that i did.
| However now that i'm using it for the server as well and
| face the same kind of challenges, i seriously question
| whether this is a wise choice.
| deepsun wrote:
| My opinion on that is the projects scale. Typically people came
| from a 10+ year Java project of 100+ engineers, to a greenfield
| advanced hello-world -- of course it's going to feel better and
| more productive.
|
| Also, as open-source folks say, "rewrite is always better". It
| also serves as a good security review. But companies typically
| don't have resources to do complete rewrites every so often, I
| saw it only in Google.
| sabellito wrote:
| I've worked in 3 of the biggest rails codebases in the world
| (Shopify being the last) and I can say from experience that
| rails legacy monoliths are infinitely worse to work with than
| some awful, but harmless, sea of struts XML legacy.
| kllrnohj wrote:
| Personally I think C# is miles ahead of Java and in meaningful
| ways (like a _drastically_ better implementation of generics,
| not to mention value types have existed for eons at this point
| and an FFI system that doesn 't hate you for using it)
|
| But nobody seems to talk about or care about C# except for
| Unity. Microsoft really missed the boat on getting mindshare
| for it back in the day.
| echelon wrote:
| That's because the Microsoft of 2000 - 2014, the Ballmer era,
| was Microsoft-first. It didn't care about other platforms, it
| didn't care about the web, and it didn't care about open
| source. C# could be great, but it existed in a bubble.
|
| Java kept growing and wound up everywhere. It played nice
| with Linux. Enterprise Mac developers didn't have trouble
| writing it with IntelliJ. It spread faster because it was
| open.
|
| Satya Nadella fixed a lot of Microsoft's ills, but it was too
| late for C# to rise to prominence. It's now the Github /
| TypeScript / AI era, and Satya is killing it.
|
| The one good thing to say about Ballmer is that he kicked off
| Azure. Microsoft grew from strength to strength after that.
| jayd16 wrote:
| Its actually quietly very popular in very boring contexts
| outside of Silicon Valley. Its also slowly entering new areas
| now that Linux builds are rock solid.
|
| MS does have an uphill PR battle though.
| bsaul wrote:
| Problem with C# isn't the language, it's the enterprise
| ecosystem. You always feel like you're going to have to pay
| at some point down the road for using the tech.
| watwut wrote:
| Definitely not. All the stuff I was used to get for free and
| advice I that was one google search away ... just dont exist
| in dotnet. Or is expensive. But most of the time, there is
| weaker library not doing nearly enough and that is all that
| exists.
| dagw wrote:
| _nobody seems to talk about or care about C# except for
| Unity_
|
| C# is extremely popular in all kinds of 'boring' industries.
| Having worked in areas like logistics and civil engineering,
| C# is everywhere.
| watwut wrote:
| Same here. I started to really like java after working with
| js/ts on small to medium project. I started to love java after
| working in on medium to little big project.
| kubb wrote:
| Worth remembering how much marketing effort and money there was
| in pushing Java in the 90s:
|
| https://m.youtube.com/watch?v=NVuTBL09Dn4
| jcadam wrote:
| Been coding on the JVM for a good chunk of my career. Though the
| last several years has been in languages other than Java - Scala,
| Clojure (my personal favorite), and Kotlin.
|
| Finally managed to get a job offer (after being unemployed for a
| bit) doing Python. It's starting to look like demand for JVM
| experience is beginning to wane. Might be time to move on anyway
| :shrug:
|
| I'm old... as long as there's a steady paycheck involved, I'll
| code in whatever language you say.
|
| Though, currently working on a little personal project in Scala.
| :)
| throwaway7783 wrote:
| Java stagnated for a while, but has now picked up steam. With
| things like GraalVM, the stellar ecosystem, generally very good
| performance and changes to the language, it is more and more
| pleasant to use.
|
| It may not be cool to use Java for startups, but we do and are
| immensely productive with it.
| zombiwoof wrote:
| Legend
| keybored wrote:
| I don't think there's a point to discussing Java. There's two
| rhetorical lanes, and they can be switched between smoothly.
|
| - Bad language and standard library design, all the
| inconsistencies that make you waste your time to this date unless
| perhaps you have very good static analysis: but history happened,
| nothing we can do about fate and circumstance
|
| - Great implementation of the technology itself (surface design
| not really relevant): heroic deeds and feats triumphed over fate
| and circumstance, this is all to our own credit
| rr808 wrote:
| Java is completely revitalized now and is my favorite platform.
|
| The main problem is the legacy code and attitude out there,
| dependency injection, using Spring or Spring Boot etc SUCKS.
| VertX is/was good but now with virtual threads you dont need all
| the async complexity.
___________________________________________________________________
(page generated 2025-05-16 23:00 UTC)