Java the language is cool. What the enterprise has done with it is not cool. Writing apps with layer upon layer upon layer upon layer of abstraction is ... self defeating. Then they'll holler, we need to rewrite it! All in the name of finding that one true architecture that can handle any business CR. Blech.
How do you feel about Spring? I'm a fan of Java itself as well, but find myself conflicted whenever I use Spring/Boot. It's very nice when it works. But when the magic formula isn't recited correctly....you get frustrated and wind up visiting HN to forget about how unpleasant it is.
Spring is obsessed with using anything but actual Java code to express business logic in Java programs.
XML bean configuration files. Annotations. Implicit code generation. Property and YAML files. Looking for files and resources in "default" locations. Executing code at runtime as the result of adding a dependency, without it ever being explicitly called anywhere.
The result is, you can never really predict what the hell your program is going to do when its running in production. Certainly not by carefully reading and inspecting the Java code you write.
My experience doing Web development in Java started with joining a team that was ramping up a project on WebSphere 5.1, alongside a migration from BEA WebLogic.
I went through a couple of WebSphere, JBoss and TomcatEE versions up to JEE 6, was the technical lead for an in-house JSF framework built on top of RichFaces, and on very last JEE project used PrimeFaces.
All the employers that I worked for, mostly used JEE stacks for their Java projects. Spring was the exception, rather than the norm.
Additionally, even if a bit slowly, many of the Spring improvements ended up in JEE and Spring also supports the JSR related to JEE anyway.
Nowadays I live in the .NET world, and the Java teams next door are happily delivering JEE based solutions.
So if I was suddenly asked to architect a Java based solution, naturally it would be JEE based.
>What the enterprise has done with it is not cool. Writing apps with layer upon layer upon layer upon layer of abstraction is ... self defeating. Then they'll holler, we need to rewrite it! All in the name of finding that one true architecture that can handle any business CR. Blech.
Those decisions were less to do with personal freedom or program simplicity, and more to do with the realities of large scale enterprise development. You end up having to adopt patterns that make individual programmers replaceable, and allow for a standardized pool of candidates with experience in $X framework. The reality is that most companies building Java software just need to be able to hire an average Java programmer to show up every day and manage their huge tangle of business logic.
Java made some fundamental design decisions at its inception which look like fairly bad ones from today's perspective. It also introduced flawed versions of features like generics later. It also has some pretty poorly designed core libraries. What about it do you consider cool? I find it hard to think of anything I'd want to take from Java if designing a new language today. Even its bad design decisions have mostly been done better by other later languages like C#.
how common was it for languages to ship with robust IO, collections, and threading libraries? It might be that a lot of the good ideas in Java have become so commonplace you don't recognize them as "from Java".
(Of course, there is very little new under the sun so I'm not claiming Java was the first to do anything in particular)
Java not only adopted a bad model of concurrency / parallelism, it enshrined it in the language in the form of language level synchronization / locking. True, it wasn't as widely appreciated at the time that it was a bad model but there were better alternatives out there even back then. The focus on a well defined memory model in the presence of parallelism is one thing Java can take some credit for but it is to some degree a consequence of the sub-optimal threading/locking model they adopted at the language level.
The original collections library in Java was poor due to lack of generics. Again, there were better models out there and some of them were even in fairly wide use at the time (C++). Java is only recently catching up to better models for collections with streams that many other languages have been doing in some form for a long time.
I don't have much of an opinion on Java IO or how it compared to contemporary alternatives but most languages have pretty robust support for basic IO in their standard libraries. What about Java do you think was particularly good for the time?
One thing that I think Java deserves some credit for popularizing is reflection, although the Java model of dynamic reflection isn't what I'd pick if designing a language from scratch today.
Some languages do at least one thing particularly well, setting the standard in that regard. Some introduce or popularize new concepts that slowly see adoption elsewhere. Several make you think about programming in a different way. Some just have an overall elegance, unity, consistency or simplicity of design that make the whole greater than the sum of the parts.
Languages that check at least one of those boxes for me include C, C++, Lisp, F#, Haskell, Lua, Python, Elm, APL, SQL, ISPC and Rust (I don't claim to be an expert in all or even most of those languages). Other languages that seem interesting / different but I know almost nothing about include Erlang, Clojure, Smalltalk, Prolog, Forth, Coq, Idris and Kotlin. By contrast I've not really seen anything in Java that checks any of those boxes and isn't done better elsewhere (admittedly sometimes by languages that came later like C#).
Java popularised GC. GC wasn't taken seriously as an option for high performance code before Java, and it altered the mindset of the majority of programmers globally.
Java's biggest mistake IMO is checked exceptions.
Java is more notable for the things it left out than what it added. It was designed for success and achieved more than most of the languages you list.
I don't love Java. However there are many cases in which it's still the best option.
I'd argue that GC still isn't taken seriously as an option for high performance code by people who actually write high performance code and Java is not the language of choice when performance is a primary goal. The lack of value types hurts it there even compared to other similar GC languages like C#.
Tell that to the high-frequency-trader crowd, they almost use java exclusivly, because even 1ms equals a few thousands to them, correctness is apparently worth it for them.
My understanding is that C++ is commonly used in that ___domain due to the performance requirements, though I don't know how common Java is relatively. C++ is used enough that there is a performance focused Study Group SG14 on the standards committee that explicitly includes trading as a use case: https://groups.google.com/a/isocpp.org/forum/m/#!forum/sg14
I'm from the games programming world where C++ still dominates for performance reasons. Where GC is widely used with C# in Unity, Unity are building their own C# compiler without GC for performance critical code (the Burst compiler) and GC is a major cause of performance issues in existing Unity games.
C++ and another non GC language (Fortran) are also the most used languages for HPC ( High Performance Computing) in scientific computing.
C and C++ also dominate in performance sensitive and resource constrained embedded programming.
I don't really know what you mean. I took issue with the claim that Java demonstrated that GC was suitable for high performance code and pointed out that even though GC is more common today than it was when Java came out that it is still avoided in applications that prioritize performance. Maybe those are 'niche' but some of them are rather large niches and there are several of them.
I personally don't find GC very useful nor do I think it's a particularly good idea and it's great to see new languages like Rust taking new approaches to memory management but I recognize that it's now the default in the majority of applications that don't prioritize performance or deal with severe resource constraints and that many programmers find it valuable. There are actually several languages I like that rely on a GC, Java is just not one of them.
