Definitely underrates the impact of annotations. I'm personally not a fan of the way annotations are used to implicitly wire together applications, but I have to admit the impact. Maybe 5/10 is fair in light of the wide range of positive and extremely negative ways annotations can be used.
So many of these features were adopted after they were proven in other languages. You would expect that since Java took such a slow and conservative approach, it would end up with extremely polished and elegant designs, but things like streams ended up inferior to previous developments instead of being the culmination. Really disappointing. Java is now a Frankenstein's monster with exactly as much beauty and charm.
I used to joke that the direction spring was heading was that you’d have an application be a boilerplate main method with a dozen lines of annotations. Then I actually encountered this in the wild: we had an app that sent updates from db2 to rabbitmq, and the application literally was just configuration via annotations and no actual Java code other than the usual spring main method.
Is that strictly bad, though? Being able to run an enterprise service by setting configuration values declaratively, and get all the guarantees of a well-tested framework, seems like a pretty good thing.
Yes, it’s weird how that’s still Java, but using standard components and only using code as glue where it’s absolutely necessary seems very similar to other engineering disciplines to me.
this is exactly why spring succeeded. I need to run a scheduled job, @EnableScheduling then @Scheduled(cron = “xxxxxx”) - done. I need XYZ, @EnableXYZ the @XYZ… sh*t just works…
Absolutely. It seems that the author never touched Spring, for instance, or a dependency-injection framework of any kind. Annotations allow to do things in a completely different way, removing tons of boilerplate.
I'd give annotations 9/10 at least.
(And I lost the interest in the rest of the article, given such a level of familiarity with the subject matter.)
My experience using Dagger (2) was so unpleasant that it really soured me on the possible uses of this feature.
I understand the benefits of dependency injection, but to be totally honest I'm more likely to take the Go-style approach of wiring it all up manually, even if it's a bit of extra boilerplate. The indirection and abstractions built up in DI frameworks is rarely worth it IMO.
and that's before even touching on the compilation steps they can add, which are a pluggable codegen and macro system that is also integrated into IDEs, which is completely missing from almost every other language.
Do you really think that in 26 years of professional Java programming I’d have never touched Spring? I’ve been using Spring since it was first released. I’ve found CVEs in Spring (https://spring.io/security/cve-2020-5408). Trust me when I say that my dislike for Spring (and annotations) is not based on ignorance.
I don't really feel that Java uses proven features.
For example they used checked exceptions. Those definitely do not seem like proven feature. C++ has unchecked exceptions. Almost every other popular language has unchecked exceptions. Java went with checked exceptions and nowadays they are almost universally ignored by developers. I'd say that's a total failure.
Streams another good example. Making functional API for collections is pretty trivial. But they decided to design streams for some kind of very easy parallelisation. This led to extremely complicated implementation, absurdly complicated. And I've yet to encounter a single use-case for this feature. So for very rare feature they complicated the design immensely.
Modules... LoL.
We will see how green threads will work. Most languages adopt much simpler async/await approach. Very few languages implement green threads.
Those are from java 1.0 and thus don't appear to be relevant to the part of the discussion I think this part of the thread is about (namely: "Why doesn't java crib well designed features from other languages?").
> Java went with checked exceptions and nowadays they are almost universally ignored by developers.
They aren't.
Note that other languages invented for example 'Either' which is a different take on the same principle, namely: Explicit mention of all somewhat expectable alternative exit conditions + enforcing callers to deal with them, though also offering a relatively easy way to just throw that responsibility up the call chain.
The general tenet (lets lift plausible alternate exit conditions into the type system) is being done left and right.
> For example they used checked exceptions. Those definitely do not seem like proven feature.
Checked exceptions are an awesome feature that more languages should have. Just like static typing is a good thing because it prevents errors, checked exceptions are a good thing because they prevent errors.
Stuart Marks and Nicolai Parlog recently had a discussion about checked exceptions in the Java channel [0]. In short, while they mentioned that there are certainly some things to improve about checked exceptions, like the confusing hierarchy as well as the boilerplate-y way of handling them, they're not necessarily a failed concept. I do hope they get to work on them in the near future.
I agree with you w/r/t the streaming parallelization. I remember huge arguments about this on some of the lists back in the day, because that design decision had lots of ridiculous consequences.
Eg, mutable state capture in lambdas is largely restricted because of the thought that people would use parallel threads within the stream processing blocks. That decision lead to lots of ugly code, IMO.
I've also never seen a need to try to parallelize a simple stream processing step.
You're absolutely right about checked exceptions. However, I think they're an exception (forgive me) from the pattern of Java mostly sticking to the strategy of, we can build a practical, industrial, reasonably performant language that has all these nice bits from other languages: garbage collection, portable bytecode, no pointer arithmetic, collections in the standard library, etc.
I think streams are a great example of what I was saying about Java failing to take advantage of coming last. Scala (probably among others, but Scala was right there on the JVM) had already demonstrated that it was possible to enable simple, readable code for simple use cases, while also enabling complex and powerful usage. And the experience of Scala had shown that there's little demand for parallel collections outside of extremely niche use cases where people tend to use specialized solutions anyway. Somehow Java, with this example staring them in the face, managed to get the worst of both worlds.
Checked exceptions are for errors that are not possible to prevent. How else should the caller know which exceptions are really likely to happen?
Modules absolutely achieved their primary goal: stopping libraries from accessing JDK internals without the application's knowledge. The ecosystem is slow on the uptake since split packages and access to internal APIs is endemic, but it is happening ever so slowly. I wish libraries could opt into not being part of the unnamed module.
Virtual threads were designed with explicit cooperation of the community, with the explicit goal of making it easy to switch as much existing code over to it as possible. I really don't understand the scepticism there. Most other languages went with promises or reactive streams because they were inspired by how functional programming languages do it.
Checked errors aren’t universally ignored by developers. Rusts main error system is checked. Swift has really introduced checked typed throws. Kotlin is introducing checked error unions. Checked exceptions are the same thing.
You've never used parallel streams? They're my favorite way to do parallel computation in Java, and very easy if you've structured your problem around streams.
It's seriously puzzling. I just don't get how it's possible to look at what so many others have done better, and somehow design something worse. For what reason? Consistency with the rest of the language, possibly? But is that really so important. Do they just not want to tackle certain parts of the compiler?
OpenJDK redesigns massive swaths of the compiler every other month.
The true explanation, at least the way OpenJDK says it, is that designing language features is more complex than a casual glancer can fathom, and there's 30 years of "Java is in the top 5 most used languages on the planet, probably #1 especially if focussing on stuff that was meant to be supported for a long time" to think about.
From personal experience, essentially every single last "Just do X to add (some lang feature) to java; languages A and B do it and it works great!" would have been bad for java. Usually because it would cause a 'cultural split' - where you can tell some highly used library in the ecosystem was clearly designed before the feature's introduction.
Even if you introduce a new feature in a way that doesn't break existing code, it's still going to cause maintainability headaches if you've cornered the pillars of the ecosystem into total rewrites if they want to remain up to date with the language. Because they will (or somebody will write an alternative that will) and you've _still_ 'python 2 v python 3'd the language and split the baby in the half.
For what its worth, I think the OpenJDK team doesn't take this seriously enough, and a number of recently introduced features have been deployed too hastily without thinking this through. For example, `LocalDate`, which has 'this should be a record' written all over it, is not a record. Or how the securitymanager is being ditched without replacements for what it is most commonly used for here in the 2020s. (To be clear: Ditching it is a good idea, but having no in-process replacement for "let me stop attempts to access files and shut down the JVM, not for security purposes but simply for 'plan B' style fallback purposes" - that's a bit regrettable).
I'm nitpicking on those points because on the whole OpenJDK is doing a far better job than most languages on trying to keep its ecosystem and sizable existing codebase on board _without_ resorting to the crutch of: "Well, users of this language, get to work refactoring everything or embrace obsoletion".
Some of the weirder choices have been the result of a desire to avoid making breaking changes to JVM bytecode.
Also there was a long period when changes were very lumpy - it could be multiple years for a feature to make it into the release, and anything that might screw up other features got a lot of pushback. Then other conventions/tools emerged that reduced the urgency (e.g. the Lombok stuff)
Edit: I should add that it's now on a fixed 6-monthly release cycle which IMO works much better.
The list generally oversimplifies a lot of things, but you're on point with annotations.
Mandatory personal anecdote:
I'm not a java guy, but I've been around java since '99, and few years ago I was moved to a strictly java team. Upon introduction I decided to show them my party trick and implemented live a pseudo "wolf3d" in one day. As usual, java devs were sort of impressed by the fact that you can do graphics and user input in java, because nowadays that's extremely rare for most of them. I got my approval and in return I asked them to give me a quick one day deep dive into Spring.
At the end I was presented with a basic hello world project that was comprised mostly of... EMPTY CLASSES
I mean literally, class Foo {} END OF FILE!
Of course these empty classes had at least 5 lines of annotations on top of class declaration and in the end it somehow pushed the framework into the right direction, but oh my fucking god, I was throwing up in my mouth for the rest of the week.
That's not how the OpenJDK sees things. They tend to think that the features they deliver are at best mildly informed by other languages. Not out of some sense of hubris, but out of a sense of pragmatics: Simply copy and pasting features from other languages into java - that would produce a frankenstein.
For example, java is somewhat unique in having lambda syntax where the lambda *must* be compile-time interpretable as some sort of 'functional type' (a functional type being any interface that defines precisely 1 unimplemented method). The vast, vast majority of languages out there, including scala which runs on the JVM, instead create a type hierarchy that describe lambdas as functions, and may (in the case of scala for example) compile-time automatically 'box'/'cast' any expression of some functional type to a functional interface type that matches.
Java's approach is, in other words, unique (as far as I know).
There was an alternate proposal available at the time that would have done things more like other languages does them, completely worked out with proof of concept builds readily available (the 'BGGA proposal'). The JVM would autogenerate types such as `java.lang.function.Function2<A, B, R>` (representing a function that takes 2 arguments, first of type A second of type B, and returns a value of type R), would then treat e.g. the expression:
`(String a, List<Integer> b) -> 2.0;`
As a `Function2<String, List<Integer>, Double>`, and would also 'auto-box' this if needed, e.g. if passing that as the sole argument to a function:
This proposal was seriously considered but rejected.
The core problem with your comment is this:
Define the terms "polished" and "elegant". It sounds so simple, but language features are trying to dance to quite a few extremely different tunes, and one person's 'elegance' is another person's 'frankensteinian monster'.
The same mostly goes for your terms "beauty" and "charm", but, if I may take a wild stab in the dark and assume that most folks have a very rough meeting of the minds as to whatever might be a "charming" language: I know of no mainstream long-term popular languages that qualify for those terms. And I think that's inherent. You can't be a mainstream language unless your language is extremely stable. When you're not just writing some cool new toy stuff in language X - you're writing production code that lots of euros and eyeballs are involved in, and there's real dependence on that software continuing to run, then you __must__ have stability or it becomes extremely pricey to actually maintain it.
With stability comes the handcuffs: You need to use the 'deprecation' hammer extremely sparingly, essentially never. And that has downstream effects: You can't really test new features either. So far I have not seen a language that truly flourishes on the crutches of some `from future import ...` system. That makes some sense: Either the entire ecosystem adopts the future feature and then breaking _that_ brings the same headaches, or folks don't use these features / only for toy stuff, and you don't get nearly the same amount of experience from its deployment.
Said differently: If java is a frankenstein, so is Javascript, C#, Python, Ruby, Scala, and so on. They have to be.
I'd love to see a language whose core design principles are 100% focussed on preventing specifically that. Some sort of extreme take on versioning of a language itself that we haven't seen before. I don't really know what it looks like, but I can't recall any language that put in the kind of effort I'd want to see here. This is just a tiny sliver of what it'd take:
* The language itself is versioned, and all previous versions continue to be part of the lang spec and continue to be maintained by future compilers. At least for a long time, if not forever.
* ALL sources files MUST start with an indication about which version of the language itself they use.
* The core libraries are also versioned, and separately. Newer versions are written against old language versions, or can be used by source on old language versions.
* The system's compilers and tools are fundamentally operating on a 'project' level granularity. You can't compile individual source files. Or if you can, it's because the spec explains how a temporary nameless project is implied by such an act.
* All versions ship with a migrator tool, which automatically 'updates' sources written for lang ver X to lang ver X+1, automatically applying anything that has a near-zero chance of causing issues, and guiding the programmer to explicitly fixing all deprecated usages of things where an automated update is not available.
* The language inherently supports 'facades'; a way for a library at version Y to expose the API it had at version X (X is older than Y), but using the data structures of Y, thus allowing interop between 2 codebases that both use this library, one at version X and one at version Y.
That language might manage the otherwise impossible job of being 'elegant', 'simple', 'mainstream', 'suitable for serious projects', and 'actually good'.
which is kinda horrifying - it means the framework designers didn't find the language powerful enough to express app logic, and hotglued their own custom arbitrary behavior on top of it.
Clear language code should be endeavor to be readable/understandable when printed on a sheet of paper by anyone, acceptable code should be understandable by anyone who knows a bit about the technologies and has some IDE support.
Garbage code is what you have when the code in question is only understandable when you actually run it, as it uses arbitrary framework logic to wire things together based on metadata on the fly.
people have been gluing other languages on top of languages practically forever - it's a DSL.
no single language is ideally suited for every situation, it's not inherently a sign of failure that someone makes a DSL.
and since annotations are part of the language, this is still all "the language is flexible enough to build the framework [despite being wildly different than normal code]" so I don't think it even supports that part.
Joshua Bloch's work on Collections for Java2 was absolutely formative for me.
I was just starting real programming, I knew naming was hard so I was using thesaurus almost as extensively - if not more - than the reference manual.
But his work defined designing API for me for life.
Stuff we take for granted, and we often overlook as seemingly trivial.
Let's say you have a collection type that has a method ``put``. It takes two arguments - an object you want to insert, and an index you want to put it at. Which argument should go first? Could index be optional? What value should it default to? Does the function returns anything? A boolean to indicate whether insertion was successful? Or the index at which the object was put? If latter how you indicate an error?
All of these seems seemingly trivial but he and his team worked on that library for over a year and he throughly documented their work in series of presentations.
And we can't forget about his java puzzlers, absolute gem.
My read is that it's easy to be quite negative on Java features when you're not the person they were designed for. For example, the main "customer" of the module system is the JDK itself. The main customer of NIO/2 is the low-level libraries like Netty.
I highly recommend the Growing the Java Language talk by Brian Goetz to anyone who's interested in the philosophy behind evolving the modern Java language [1]. And Don’t be misled by the title, it’s not just about Java, it’s about software design.
> So yeah, why expose it to those who are not the "main customer"?
How did modules affect you as a user? I'd guess that you had to add `--add-opens`/`--add-exports` during one of the JDK migrations at some point. And the reason you had to do it was that various libraries on your classpath used JDK internal APIs. So modules provided encapsulation and gave you an escape hatch for when you still have to use those libraries. How else would you do it while still achieving the desired goal?
Modules are weird. In Java world there exists consensus on dependency management via Maven-style repositories (Maven Central is the primary distribution channel) and all tools support it. You handle your dependency tree outside of your code and just import packages from libraries available on classpath. It’s possible to continue doing that that without using modules, so the case for using them is still unclear to many people. Where the actual hate may have come from is an old story with migration from Java 8 to Java 9, where modules hidden the access to certain internal APIs, breaking some libraries which relied on them, making that migration painful. Today their value is probably 0/10, but there’s no reason to hate.
Directly or indirectly many (or most) projects ended up depending on something which was using an unsupported backdoor API because it provided a marginally useful capability. The module system restricted access to these APIs and everything stopped working, unless you added some magic command line arguments to gain access again.
So for most people, the initial impression of modules is negative, and then they just decided to rule the feature out completely. This has created a sea of useless criticism, and any constructive criticism is hardly observed. Improvements to module configuration (combine it with the classpath), would go a long way towards making modules "just work" without the naysayers getting in the way.
They're fine, but they're incompatible with building fat-jars ro have single file deployment and dead to me because of that.
Spring does some ugly jar-in-jar custom classloader stuff which I hate out of principle because it's spring.
Oracle hates that people build fat-jars and refuses to adress the huge benefit of single file deployables.
A cool thing about Doug Lea's java.util.concurrent (received a 10/10 rating here) is that its design also inspired Python's concurrent.futures package. This is explicitly acknowledged in PEP 3148[1] (under "Rationale"), a PEP that dates back to 2009.
It's nice to review the features, but the history of Java isn't really about features or even programmer popularity.
(1) It was the first disruptive enterprise business model. They aimed to make everyone a Java programmer with free access (to reduce the cost of labor), but then charge for enterprise (and embedded and browser) VM's and containers. They did this to undercut the well-entrenched Microsoft and IBM. (IBM followed suit immediately by dumping their high-end IDE and supporting the free Eclipse. This destroyed competition from Borland and other IDE makers tying their own libraries and programming models.)
(2) As an interpreted language, Java became viable only with good JIT's. Borland's was the first (in JDK 1.1.7), but soon Urs Holzle, a UCSB professor, created the HotSpot compiler that has seeded generations of performance gains. The VM and JIT made it possible to navigate the many generations of hardware delivering and orders-of-magnitude improvements and putting software in every product. Decoupling hardware and software reduced the vertical integration that was killing customers (which also adversely affected Sun Microsystems).
btw, Urs Holzle went on to become Google employee #8 and was responsible for Google using massively parallel off-the-shelf hardware in its data centers. He made Google dreams possible.
Ah Java. The language I never got to love. I came of coding age during the “camps” era of object oriented stuff: Eiffel, Smalltalk, CLOS, C++, etc. Java, from 95ish to oh 98ish, was like a giant backdraft. Completely sucked the air out of the room for everything else.
Does anyone remember the full page ads in WSJ for programming language, that no on quite yet knew what it really was? So my formative impressions of Java on were emotional/irrational, enforced by comments like:
“Of Course Java will Work, there’s not a damn new thing in it” — James gosling, but I’ve always suspected this might be urban legend
“Java, all the elegance of C++ syntax with all the speed of Smalltalk” - Kent Beck or Jan Steinman
“20 years from now, we will still be talking about Java. Not because of its contributions to computer programming, but rather as a demonstration of how to market a language” — ??
I can code some in Java today (because, hey, GPT and friends!! :) ), but have elected to use Kotlin and have been moderately happy with that.
One thing that would be interesting about this list, is to break down the changes that changed/evolved the actual computation model that a programmer uses with it, vs syntactic sugar and library refinements. “Languages” with heavy footprints like this, are often just as much about their run time libraries and frameworks, as they are the actual methodology of how you compute results.
In the early days javascript wasn't far enough along that you could make a web app without a lot of compromises, and the cross-platform nature of java was a big, big plus. I worked on an internal java client application that was developed on Linux for end users on PC. Ten years after we released the first version, and while it was still under development, a group of powerful managers at our company demanded they be issued Macs instead of the PC corporate standard.
When IT asked us if our application worked on Mac, we shrugged and said "We don't have a Mac to test it. We've never run it on a Mac. We won't support it officially, so if there are Mac specific bugs you're on your own. But... it should work. Try it."
And it did work. All the Mac users had to do was click on our Webstart link just like the PC users. It installed itself properly and ran properly. Never had a single issue related to the OS. Before Java was introduced that was an unobtainable dream in a full-featured windowed application.
> I can code some in Java today (because, hey, GPT and friends!! :) ),
I love GPT. Such a marvellous tool. Before ChatGPT came along, I had no medical experience. Thanks to GPT and friends, I am now a doctor. I've opened a clinic of my own.
I think the author is sleeping on Java assertions.
I really like the feature, and it's really one of the features I feel Java got right.
The syntax is very expressive, and they can easily be made to generate meaningful exceptions when they fail.
It's also neat that it gives the language a canonical way of adding invariant checks that can be removed in production but run in tests or during testing or debugging (with -da vs -ea).
You could achieve similar things with if statements, and likely get similar performance characteristics eventually out of C2, but this way it would be harder to distinguish business logic from invariant checking. You'd also likely end up with different authors implementing their own toggles for these pseudo-assertions.
I'm quite surprised that he said asserts are not found in production code. Is that really so? I rarely write Java, but in C code we use asserts (in production code) all the time. It's not uncommon for functions to contain 2 or 3 asserts.
I very rarely see assertions in "real" Java code; I think the author is right - in fact the place I see them the most often is in unit tests where they've been used by mistake in place of an assertion library's methods!
I think they're used less because the main reason for using them in C isn't a consideration in Java, and also they don't accomplish the same thing.
In C, asserts are used as sanity checks, and when one is violated, there's often reasonable suspicion that that memory corruption has occurred, or that memory corruption will occur if the code proceeds in the current state. Aborting the process, leaving a core dump for analysis, and starting fresh is often the safest thing to do to avoid the unpredictable results of corrupted state, which can be insidiously subtle or insanely dramatic. In my experience writing server-side C++, we always ran it in production with asserts enabled, because code that continued to run after memory was corrupted led to the the bugs that were the most destructive and the most mysterious.
Memory corruption is rare enough in Java that 99.9% of code completely ignores the possibility. Also, if you did suspect memory corruption in a Java program, an assert wouldn't help, because it would only throw a runtime exception that would probably get caught and logged somewhere, and the process would continue serving requests or whatever else it was doing.
If you're only doing like CRUD endpoints, they may be less useful, but that's hardly the extent of Java production code. I certainly use asserts in production code quite a lot in Java, though the use biases toward more low level functions, rarely in high level application logic.
At the time the feature was added, there was no way to make a parameter to a function be lazily evaluated. Something like `assert(condition, "error: " + stuff)` would eagerly concatenate the string even when the condition is always true (which it should be). Nowadays, the error parameter can be specified as a lambda, which can potentially be optimized to be just as cheap as the existing assert feature.
You can disable them at runtime (e.g. in prod) to avoid the performance overhead once you're satisfied the codebase is thoroughly enough tested.
For some things like requiring arguments to be non-null static checks with annotations have superseded them (in a confusing way inevitably - I think there are three different common non-nullness annotations).
The pros are that it can generate better error messages, without putting that responsibility on the programmer. Something that would otherwise require a preprocessor or some form of metaprogramming.
I’m sure there are better ways to do streams on the JVM, scala being a great example, but however imperfect the implementation is streams are such a net positive I can’t imagine the language without them. I pine for the streams API when I write go.
I totally agree with the criticism about exceptions. If you need exceptions inside a stream it turns into a mess.
Overall I agree with you. They are significantly better, even if a little verbose, than not having them. Love cleaning up old loops with a tiny stream that expresses the same thing more compactly and readably.
He’s also right on the parallel benefits not really being a thing I’ve ever seen used.
I feel this is overly harsh on Collections. You have to take into account just how awful that which it replaced was.
> Java Time: Much better than what came before, but I have barely had to use much of this API at all, so I’m not in a position to really judge how good this is.
Again, it is hard to overstate just _how_ bad the previous version is.
>Again, it is hard to overstate just _how_ bad the previous version [of Java time] is.
The original Java Time classes were likely a last-minute addition to Java. They were obviously a direct copy of C language time.h. It feels as if the Java team had a conversation like this: "Darn, we ship Java 1.0 in a month but we forgot to include any time functions!" "Oh no! We must do something!" "I know, let's just port C time.h!"
In my mind Java really got usable in 1.5 with collections and generics.
When you didn’t have collections everything was a complete pain. But after they were added you still had to cast everything back to whatever type it was supposed to be when you got stuff out of collections. Which was also a huge pain.
I know all the arguments about how genetics weren’t done “correctly“ in Java. I’ve run into the problems.But I’m so glad we have them.
I haven't written much Java but I am learning Kotlin and I really appreciate the language and the whole JVM ecosystem. Yeah yeah, Gradle is complicated but it's waaaaay easier to figure out than my adventures with Cmake, and when I read Java code there is a certain comfort I feel that I don't get with other languages, even ones I'm experienced with like Go. Java feels a bit like a stranger I've known my whole life, same with Kotlin. Perhaps despite all its flaws, there is a certain intrinsic quality to Java that has helped make it so popular.
I think you might be getting at one of my favourite features of Java. It's a pretty straightforward simple language. It deals with complexity well by not being too clever. I think Go has that too, except for its error handling and perhaps channels
Can't speak for everyone, but I think a substantial part of the shift from Maven to Gradle was the ability to write build scripts: you didn't need to write a plugin. I'm hoping that Maven (and Gradle) can take advantage of JEPs 458 and 512 to allow people to write build scripts for that Java projects in Java.
Once, after we had an application go live, we started getting reports after a few hours that new users were unable to log in.
It turns out, somewhere in the auth path, a dev had used `==` to verify a user's ID, which worked for Longs under (I believe) 128, so any users with an ID bigger than that were unable to log in due to the comparison failing.
Return false! They aren't equal. But of course we're comparing a reference to a primitive, so we either lift the primitive to a reference, or lower the reference... so here we are.
Interesting; I actually have grown pretty fond of NIO.
I will acknowledge that the interface is a bit weird, but I feel like despite that it has consistently been a "Just Works" tool for me. I get decent performance, the API is well documented, and since so many of my coworkers have historically been bad at it and used regular Java IO, it has felt like a superpower for me since it makes it comparatively easy to write performant code.
Granted, I think a part of me is always comparing it to writing raw epoll stuff in C, so maybe it's just better in comparison :)
There's one thing I deeply dislike with Java NIO: ClosedByInterruptException. If a thread is interrupted (for instance, due to a future.cancel(true) or similar), and it happens to be in the middle of a NIO operation, the channel will be closed, even if it's not owned by that thread. That single thing makes using NIO far more brittle than the older Java IO.
I haven’t used markdown in javadoc yet but this seems like at least 3/10? I often want to put paragraphs or bulleted lists in javadoc and find myself wanting to use markdown syntax for readability in the code but need to switch to less readable html tags for tooling to render it properly.
I really wish Javadoc was just plain text that honored line breaks. I really don’t care about the fact I can put HTML in there, that just seems dumb to me. I get you can’t remove it but I would be happy if you could.
I do like markdown. But I don’t see myself ever using it in a Javadoc.
Servlets (Together with MS ASP, JSP/Servlets have fuelled the e-commerce websites)
I think Java dominated the scene mostly because of its enterprise features (Java EE) and the supporting frameworks (Spring etc) and applications (Tomcat, Websphere, Weblogic etc) and support from Open source (Apache, IBM)
-10 for modules is fair, only 4 for lambdas is not. My programming style changed after using lambdas in Java, even when using a different programming language later that doesn't have lambdas as such.
In one of James Gosling's talks he tells a funny story about the origin of this design decision. He went around the office at Sun and gave a bunch of seasoned C programmers a written assessment on signed/unsigned integer behaviors. They all got horrible scores, so he decided the feature would be too complicated for a non-systems programming language.
Non-systems languages still need to interact with systems languages, over the network or directly. The lack of unsigned types makes this way more painful and error-prone than necessary.
It’s rare I have to do bit math but it’s so INCREDIBLY frustrating because you have to do everything while the values are signed.
It is amazing they haven’t made a special type for that. I get they don’t want to make unsigned primitives, though I disagree, but at least makes something that makes this stuff possible without causing headaches.
Sometimes I'd like to have unsigned types too, but supporting it would actually make things more complicated overall. The main problem is the interaction between signed and unsigned types. If you call a method which returns an unsigned int, how do you safely pass it to a method which accepts a signed int? Or vice versa?
Having more type conversion headaches is a worse problem than having to use `& 0xff` masks when doing less-common, low-level operations.
I owe Java a lot. Programming clicked for me when I was taught OOP in Java, my other programming module with event-driven design in C# which I hated.
Fast forward a few years later, and I'm actually at a C# shop.
Fast forward a decade, I'm at the same shop. I adore C# and I fondly remember my foray into Java.
I left Java around the time Streams were becoming a thing. I thought it looked like a mess, and then I ran into LINQ in C# land. Swings (pun intended) and roundabouts.
A little bit bias and opinionated... Tho limited, lambdas and streams were a paradigm shift so big that revamped the love for java into functional programming... Not just a set of features introduced in Java 8.
Didn't Java 1.3 (Sun's JDK) introduce the JIT?
I remember talking to colleagues about what a joke Java performance was (we were working in C++ then). And then with Java 1.3 that started to change.
(Today, even though I still C++, C, along with Java, I'll challenge anyone who claims that Java is slower then C++.)
Maybe not slower once it has warmed up, though for memory-bandwidth bound use cases I would still say the lack of mutable records has you fighting the language to get reasonable cache locality (and everybody will hate your code for not being good Java). The fact that everything is a pointer kills the CPU execution pipeline and cache.
But even for I/O bound applications it still feels slow because excessive memory usage means more swap thrashing (slowing down your entire OS), and startup time suffers greatly from having to fire up VM + loading classes and waiting for the JIT to warm up.
I can start a C/C++/Rust based web server in under a second. The corresponding server in Java takes 10 seconds, or minutes once I have added more features.
The first official JIT became available in JDK 1.1, in 1997. The Symantec JIT was available as an add-on sometime in mid 1996, just a few months after JDK 1.0 was released. Even better performance was possible with GCJ, available in 1998.
The release of HotSpot was in 1999, and became default with JDK 1.3 in 2000. It took JIT compilation to the next level, making tools like GCJ mostly obsolete.
Great list, even if I disagree with many of the ratings!
But astonished that Optional isn't mentioned either there or in the comments. A second way to represent no-value, with unclear and holy-war-ushering guidance on when to use, and the not exactly terse syntax I see everywhere:
Optional<Ick> ickOpt = Optional.ofNullable(ickGiver.newIck());
ickOpt.flatMap(IckWtfer::wtf).ifPresentOrElse((Wtf wtf) -> unreadable(wtf)), () -> { log.warn("in what universe is this clearer than a simple if == null statement?!"); });
You could maybe move the null check inside the method in the former and it cleans it up a bit, but in the latter you can have methods that are explicitly marked as taking NonNull in their type signature which is nice.
Wow I can’t believe try with resources is so old! I’ve been working with Java for years and only learned this exists recently, I thought it must be relatively new. 14 years!
It was such a lifesaver for doing raw database stuff. The boilerplate for making sure Connection, PreparedStatement, ResultSet and so on were all released properly was a huge pain before that.
the biggest things to change java have been type inference, lambdas, records, streams (functional ops on collections), and pattern matching. these are all must-have features for any modern programming language. at this point any language without these features will feel old and legacy. it’s impressive java was able to add them all on decades after release, but you do feel it sometimes
It reduces (often repetitive) visual noise in code, which can make it more readable. I wouldn’t recommend using it in all cases, but it’s a good tool to have.
To me var is what makes modern java somewhat readable and more bearable.
It was always a joke that it takes too long to write anything in java because of the excessive syntax repetitions and formalities. To me that joke is heavily based on a reality that modern Java is tackling with this quality of life features.
I get the attraction to var, but I, personally, don't use it, as I feel it makes the code harder to read.
Simply, I like (mind, I'm 25 year Java guy so this is all routine to me) to know the types of the variables, the types of what things are returning.
var x = func();
doesn't tell me anything.
And, yes, I appreciate all comments about verbosity and code clutter and FactoryProxyBuilderImpl, etc. But, for me, not having it there makes the code harder for me to follow. Makes an IDE more of a necessity.
Java code is already hard enough to follow when everything is a maze of empty interfaces, but "no code", that can only be tracked through in a debugger when everything is wired up.
Maybe if I used it more, I'd like it better, but so far, when coming back to code I've written, I like things being more explicit than not.
I have the opposite feeling. var makes it easier to write but harder to read/review. Without var you know the exact type of a variable without going through some functions for example
It's called type inference and it's the way things should be. You get the same types but you don't have to spell them out everywhere. Java doesn't even go all the way, check OCaml to see full program inference.
OCaml's type inference is truly amazing, makes it such a delight to write statically typed code - reading it on the other hand...
But I think that's easily solved by adding type annotations for the return type of methods - annotating almost anything else is mostly just clutter imo.
This is what it looks like to me. If you wanted to do this, why not use a scripting language where you can use this kind of practice everywhere? In Java, I don't expect to have to look up the return type of something to discover a variable type. Graciously, I can see how you can save rewriting the Type declaration when it's a function return you want to mutate.
Generally, you save some keystrokes to let other people (or future you) figure it out when reading. It seems like bad practice altogether for non trivial projects.
(Note: I put a subtle bug in there because it always happened)
SQL injection is horrible, but people were managing to do that all these years after prepared statements anyway without text blocks. I really don’t think they made things worse. Same thing with embedding HTML in the code. They were gonna do it anyway.
Primitive variables in Java, such as `int`, `boolean`, and `double`, store their actual values directly in memory. When they are local variables inside a method, this memory is typically allocated on the thread's stack. These primitives do not have the structure or overhead of an object, including the object header used by the Garbage Collector (GC) to manage heap-allocated objects.
If a primitive value must be treated as an object (e.g., when stored in a Java Collection like ArrayList or when passed to a method that requires an object), Java uses a process called `boxing` to wrap the primitive value into an instance of its corresponding Wrapper class (e.g., Integer, Boolean, Double). These Wrapper objects are allocated on the heap and do possess the necessary object header, making them subject to the GC's management.
It's because the collection types (and generics) don't support primitives, only objects. So you been to stuff the primitives into objects to use them with a lot of the standard library.
One of the more amusing bugs I had to figure out resulted from the fact that some of the autoboxed values get cached, resulting in peculiar behaviour when someone managed to reflectively change the boxed primitive value...
i.e. something like:
Integer x = 42
highlyQuestionableCode(x);
println(x); // "24" WAT?
I think your intuition is correct: you probably don’t.
That’s also very likely changing. Lookup “project Valhalla”. It’s still a work in progress but the high level goal is to have immutable values that “code like a class, work like an int”.
PS When I say “changing”: it’s being added. Java tries hard to maintain backward compatibility for most things (which is great).
java.util.Date and java.util.Calendar are the two packages I remember struggling with as a new programmer. Which I guess is solved with java.time after Java 8.
(I know the irony of Spring is that it became what it replaced. But it got a good ten or fifteen years of productivity before it began getting high on its own supply. )
Spring and the associated enterprise spaghetti developers have done more damage to the platform rather than the language itself. I've managed to work for almost a decade with Java without using Spring at this point (and count myself lucky for it), but the chances of finding a new job with the same requirement are slimmer and slimmer now.
As someone who has worked on code bases that did not have spring that really should have and had to do everything manually: when used well it’s fantastic.
Now people can certainly go majorly overboard and do the super enterprise-y AbstractBoxedSomethingFactoryFacadeManagerImpl junk. And that is horrible.
But simple dependency injection is a godsend. Ease of coding my just adding an annotation to get a new component you can reference anywhere easily is great. Spring for controllers when making HHTP endpoints? And validation of the data? Love it!
Some of the other modules like Spring Security can be extremely confusing. You can use the Aspect Oriented Programming to go overboard and make it nearly impossible to figure out what the hell is happening in the program.
Spring is huge, and it gets criticized for tons of the more esoteric or poorly designed things it has. But the more basic stuff that you’re likely to get 90+ percent of the value out of really makes things a lot better. The relatively common stuff that you’ll see in any Spring Boot tutorial these days.
The beautiful and essential technique of DI (dependency inversion) got namesquatted hard by DI (dependency injection).
Before, you used to write "loosely coupled" software by decoupling your business logic from your IO to keep it testable. You could take virtually anything worth testing, 'new' it in a unit test, and bob's your uncle.
Now you write "loosely coupled" software by keeping the coupling between components, but also couple them to a bunch of Spring dependencies too (check your imports!). Now you can't instantiate anything without Spring.
Sorry, but several of these ratings are just plain wrong. I am not even a Java developer these days, but it is extremely clear that author did not work in a domain that rightfully leveraged the Java features he rates as of little use.
He would have been better served by opening a poll - that would have opened his eyes to the use of these features.
Its like giving operator overload a rating of 1 in C++/Python. Sure, if you don't find any need for it in your domain, it would look stupid to you.
No, it's a 6 month release cadence. You might be confusing the initial release with a point release which are less regular. Edit: oh, my bad, I see the article author had the wrong year for 24.
22 was March 2024
23 was September 2024
24 was March 2025
25 was September 2025
This is much better than the old "release train" system where e.g Java 5 and Java 6 were released in Sept 2004 and Nov 2006 respectively!
I will make any excuse to use Streams but understand the negativity. They are difficult to debug and I feel the support for parallelism complicated, and in some cases even crippled, the API for many common use cases.
I'm that author. It has been more than a decade and still won't use streams nor lambdas. Makes the code too difficult to write and debug for me.
Really prefer to have more lines of code and understanding very clearly what each one is doing, than convoluting too many instructions on a single line.
For me it's the opposite: If I had to write the code that I usually use lambdas for in any other way then _that_ would be very difficult to write and to debug.
Especially when writing JavaFX code which is full of callbacks and event handlers I really don't see any other (useful) option.
Can lambdas be misused? Of course they can - but so can every other code construct.
I bet you don't like how it looks when you put huge code blocks inside a lambda. Me neither. But that's an issue with coding style; it forces you to extract processing code into a method. I'd argue the opposite way - imperative syntax constructs make spaghetti code too easy to work with.
They're a bit verbose, the interfaces are slightly convoluted and some basic operations are missing from the standard library.
It's also a little convoluted to work with different types of data.
For this one, I wish they would have taken a bit more inspiration from other languages and spent the time to make it more readable.
That said, I generally like streams a lot, and they do reduce the amount of branching, and having less possible code execution points makes testing easier too.
Yeah that's very much an explicit design philosophy of Java, dating way back. Let other languages experiment, and adapt what proves useful.
It hasn't worked out in terms of delivering perfect language design, but it has worked out in the sense that Java has an almost absurd degree of backward compatibility. There are libraries that have had more breaking changes this year than the Java programming language has had in the last 17 releases.
Definitely underrates the impact of annotations. I'm personally not a fan of the way annotations are used to implicitly wire together applications, but I have to admit the impact. Maybe 5/10 is fair in light of the wide range of positive and extremely negative ways annotations can be used.
So many of these features were adopted after they were proven in other languages. You would expect that since Java took such a slow and conservative approach, it would end up with extremely polished and elegant designs, but things like streams ended up inferior to previous developments instead of being the culmination. Really disappointing. Java is now a Frankenstein's monster with exactly as much beauty and charm.
I used to joke that the direction spring was heading was that you’d have an application be a boilerplate main method with a dozen lines of annotations. Then I actually encountered this in the wild: we had an app that sent updates from db2 to rabbitmq, and the application literally was just configuration via annotations and no actual Java code other than the usual spring main method.
Is that strictly bad, though? Being able to run an enterprise service by setting configuration values declaratively, and get all the guarantees of a well-tested framework, seems like a pretty good thing.
Yes, it’s weird how that’s still Java, but using standard components and only using code as glue where it’s absolutely necessary seems very similar to other engineering disciplines to me.
8 replies →
this is exactly why spring succeeded. I need to run a scheduled job, @EnableScheduling then @Scheduled(cron = “xxxxxx”) - done. I need XYZ, @EnableXYZ the @XYZ… sh*t just works…
41 replies →
Absolutely. It seems that the author never touched Spring, for instance, or a dependency-injection framework of any kind. Annotations allow to do things in a completely different way, removing tons of boilerplate.
I'd give annotations 9/10 at least.
(And I lost the interest in the rest of the article, given such a level of familiarity with the subject matter.)
My experience using Dagger (2) was so unpleasant that it really soured me on the possible uses of this feature.
I understand the benefits of dependency injection, but to be totally honest I'm more likely to take the Go-style approach of wiring it all up manually, even if it's a bit of extra boilerplate. The indirection and abstractions built up in DI frameworks is rarely worth it IMO.
2 replies →
and that's before even touching on the compilation steps they can add, which are a pluggable codegen and macro system that is also integrated into IDEs, which is completely missing from almost every other language.
1 reply →
Do you really think that in 26 years of professional Java programming I’d have never touched Spring? I’ve been using Spring since it was first released. I’ve found CVEs in Spring (https://spring.io/security/cve-2020-5408). Trust me when I say that my dislike for Spring (and annotations) is not based on ignorance.
7 replies →
I don't really feel that Java uses proven features.
For example they used checked exceptions. Those definitely do not seem like proven feature. C++ has unchecked exceptions. Almost every other popular language has unchecked exceptions. Java went with checked exceptions and nowadays they are almost universally ignored by developers. I'd say that's a total failure.
Streams another good example. Making functional API for collections is pretty trivial. But they decided to design streams for some kind of very easy parallelisation. This led to extremely complicated implementation, absurdly complicated. And I've yet to encounter a single use-case for this feature. So for very rare feature they complicated the design immensely.
Modules... LoL.
We will see how green threads will work. Most languages adopt much simpler async/await approach. Very few languages implement green threads.
> For example they used checked exceptions.
Those are from java 1.0 and thus don't appear to be relevant to the part of the discussion I think this part of the thread is about (namely: "Why doesn't java crib well designed features from other languages?").
> Java went with checked exceptions and nowadays they are almost universally ignored by developers.
They aren't.
Note that other languages invented for example 'Either' which is a different take on the same principle, namely: Explicit mention of all somewhat expectable alternative exit conditions + enforcing callers to deal with them, though also offering a relatively easy way to just throw that responsibility up the call chain.
The general tenet (lets lift plausible alternate exit conditions into the type system) is being done left and right.
3 replies →
> For example they used checked exceptions. Those definitely do not seem like proven feature.
Checked exceptions are an awesome feature that more languages should have. Just like static typing is a good thing because it prevents errors, checked exceptions are a good thing because they prevent errors.
6 replies →
Stuart Marks and Nicolai Parlog recently had a discussion about checked exceptions in the Java channel [0]. In short, while they mentioned that there are certainly some things to improve about checked exceptions, like the confusing hierarchy as well as the boilerplate-y way of handling them, they're not necessarily a failed concept. I do hope they get to work on them in the near future.
0: https://www.youtube.com/watch?v=lnfnF7otEnk
5 replies →
I agree with you w/r/t the streaming parallelization. I remember huge arguments about this on some of the lists back in the day, because that design decision had lots of ridiculous consequences.
Eg, mutable state capture in lambdas is largely restricted because of the thought that people would use parallel threads within the stream processing blocks. That decision lead to lots of ugly code, IMO.
I've also never seen a need to try to parallelize a simple stream processing step.
1 reply →
You're absolutely right about checked exceptions. However, I think they're an exception (forgive me) from the pattern of Java mostly sticking to the strategy of, we can build a practical, industrial, reasonably performant language that has all these nice bits from other languages: garbage collection, portable bytecode, no pointer arithmetic, collections in the standard library, etc.
I think streams are a great example of what I was saying about Java failing to take advantage of coming last. Scala (probably among others, but Scala was right there on the JVM) had already demonstrated that it was possible to enable simple, readable code for simple use cases, while also enabling complex and powerful usage. And the experience of Scala had shown that there's little demand for parallel collections outside of extremely niche use cases where people tend to use specialized solutions anyway. Somehow Java, with this example staring them in the face, managed to get the worst of both worlds.
2 replies →
Checked exceptions are for errors that are not possible to prevent. How else should the caller know which exceptions are really likely to happen?
Modules absolutely achieved their primary goal: stopping libraries from accessing JDK internals without the application's knowledge. The ecosystem is slow on the uptake since split packages and access to internal APIs is endemic, but it is happening ever so slowly. I wish libraries could opt into not being part of the unnamed module.
Virtual threads were designed with explicit cooperation of the community, with the explicit goal of making it easy to switch as much existing code over to it as possible. I really don't understand the scepticism there. Most other languages went with promises or reactive streams because they were inspired by how functional programming languages do it.
5 replies →
Checked errors aren’t universally ignored by developers. Rusts main error system is checked. Swift has really introduced checked typed throws. Kotlin is introducing checked error unions. Checked exceptions are the same thing.
You've never used parallel streams? They're my favorite way to do parallel computation in Java, and very easy if you've structured your problem around streams.
1 reply →
Go implements green threads.
It might only be one language, but it’s a pretty big one
IDK, I've worked in projects that didn't use the magic so much and I honestly think it was worse.
Instead of a config class and a bunch of apps with @Inject Config config;, we'd have giant *Config classes. Each one would have lots of methods like:
@Bean public fooProducer(FooConfig config, BazProvider provider, BarProvider barProvider, SoapClient soapClient) {...}
Want to know how they were produced? Find usages on the class' constructor.
The magic @Inject and @Autowired annotations don't seem worse than that to me.
It's seriously puzzling. I just don't get how it's possible to look at what so many others have done better, and somehow design something worse. For what reason? Consistency with the rest of the language, possibly? But is that really so important. Do they just not want to tackle certain parts of the compiler?
OpenJDK redesigns massive swaths of the compiler every other month.
The true explanation, at least the way OpenJDK says it, is that designing language features is more complex than a casual glancer can fathom, and there's 30 years of "Java is in the top 5 most used languages on the planet, probably #1 especially if focussing on stuff that was meant to be supported for a long time" to think about.
From personal experience, essentially every single last "Just do X to add (some lang feature) to java; languages A and B do it and it works great!" would have been bad for java. Usually because it would cause a 'cultural split' - where you can tell some highly used library in the ecosystem was clearly designed before the feature's introduction.
Even if you introduce a new feature in a way that doesn't break existing code, it's still going to cause maintainability headaches if you've cornered the pillars of the ecosystem into total rewrites if they want to remain up to date with the language. Because they will (or somebody will write an alternative that will) and you've _still_ 'python 2 v python 3'd the language and split the baby in the half.
For what its worth, I think the OpenJDK team doesn't take this seriously enough, and a number of recently introduced features have been deployed too hastily without thinking this through. For example, `LocalDate`, which has 'this should be a record' written all over it, is not a record. Or how the securitymanager is being ditched without replacements for what it is most commonly used for here in the 2020s. (To be clear: Ditching it is a good idea, but having no in-process replacement for "let me stop attempts to access files and shut down the JVM, not for security purposes but simply for 'plan B' style fallback purposes" - that's a bit regrettable).
I'm nitpicking on those points because on the whole OpenJDK is doing a far better job than most languages on trying to keep its ecosystem and sizable existing codebase on board _without_ resorting to the crutch of: "Well, users of this language, get to work refactoring everything or embrace obsoletion".
5 replies →
Some of the weirder choices have been the result of a desire to avoid making breaking changes to JVM bytecode.
Also there was a long period when changes were very lumpy - it could be multiple years for a feature to make it into the release, and anything that might screw up other features got a lot of pushback. Then other conventions/tools emerged that reduced the urgency (e.g. the Lombok stuff)
Edit: I should add that it's now on a fixed 6-monthly release cycle which IMO works much better.
The list generally oversimplifies a lot of things, but you're on point with annotations.
Mandatory personal anecdote:
I'm not a java guy, but I've been around java since '99, and few years ago I was moved to a strictly java team. Upon introduction I decided to show them my party trick and implemented live a pseudo "wolf3d" in one day. As usual, java devs were sort of impressed by the fact that you can do graphics and user input in java, because nowadays that's extremely rare for most of them. I got my approval and in return I asked them to give me a quick one day deep dive into Spring.
At the end I was presented with a basic hello world project that was comprised mostly of... EMPTY CLASSES I mean literally, class Foo {} END OF FILE!
Of course these empty classes had at least 5 lines of annotations on top of class declaration and in the end it somehow pushed the framework into the right direction, but oh my fucking god, I was throwing up in my mouth for the rest of the week.
That's not how the OpenJDK sees things. They tend to think that the features they deliver are at best mildly informed by other languages. Not out of some sense of hubris, but out of a sense of pragmatics: Simply copy and pasting features from other languages into java - that would produce a frankenstein.
For example, java is somewhat unique in having lambda syntax where the lambda *must* be compile-time interpretable as some sort of 'functional type' (a functional type being any interface that defines precisely 1 unimplemented method). The vast, vast majority of languages out there, including scala which runs on the JVM, instead create a type hierarchy that describe lambdas as functions, and may (in the case of scala for example) compile-time automatically 'box'/'cast' any expression of some functional type to a functional interface type that matches.
Java's approach is, in other words, unique (as far as I know).
There was an alternate proposal available at the time that would have done things more like other languages does them, completely worked out with proof of concept builds readily available (the 'BGGA proposal'). The JVM would autogenerate types such as `java.lang.function.Function2<A, B, R>` (representing a function that takes 2 arguments, first of type A second of type B, and returns a value of type R), would then treat e.g. the expression:
`(String a, List<Integer> b) -> 2.0;`
As a `Function2<String, List<Integer>, Double>`, and would also 'auto-box' this if needed, e.g. if passing that as the sole argument to a function:
``` void foo(MyOperation o) {}
interface MyOperation { Double whatever(String arg1, List<Integer> arg2); } ```
This proposal was seriously considered but rejected.
The core problem with your comment is this:
Define the terms "polished" and "elegant". It sounds so simple, but language features are trying to dance to quite a few extremely different tunes, and one person's 'elegance' is another person's 'frankensteinian monster'.
The same mostly goes for your terms "beauty" and "charm", but, if I may take a wild stab in the dark and assume that most folks have a very rough meeting of the minds as to whatever might be a "charming" language: I know of no mainstream long-term popular languages that qualify for those terms. And I think that's inherent. You can't be a mainstream language unless your language is extremely stable. When you're not just writing some cool new toy stuff in language X - you're writing production code that lots of euros and eyeballs are involved in, and there's real dependence on that software continuing to run, then you __must__ have stability or it becomes extremely pricey to actually maintain it.
With stability comes the handcuffs: You need to use the 'deprecation' hammer extremely sparingly, essentially never. And that has downstream effects: You can't really test new features either. So far I have not seen a language that truly flourishes on the crutches of some `from future import ...` system. That makes some sense: Either the entire ecosystem adopts the future feature and then breaking _that_ brings the same headaches, or folks don't use these features / only for toy stuff, and you don't get nearly the same amount of experience from its deployment.
Said differently: If java is a frankenstein, so is Javascript, C#, Python, Ruby, Scala, and so on. They have to be.
I'd love to see a language whose core design principles are 100% focussed on preventing specifically that. Some sort of extreme take on versioning of a language itself that we haven't seen before. I don't really know what it looks like, but I can't recall any language that put in the kind of effort I'd want to see here. This is just a tiny sliver of what it'd take:
* The language itself is versioned, and all previous versions continue to be part of the lang spec and continue to be maintained by future compilers. At least for a long time, if not forever.
* ALL sources files MUST start with an indication about which version of the language itself they use.
* The core libraries are also versioned, and separately. Newer versions are written against old language versions, or can be used by source on old language versions.
* The system's compilers and tools are fundamentally operating on a 'project' level granularity. You can't compile individual source files. Or if you can, it's because the spec explains how a temporary nameless project is implied by such an act.
* All versions ship with a migrator tool, which automatically 'updates' sources written for lang ver X to lang ver X+1, automatically applying anything that has a near-zero chance of causing issues, and guiding the programmer to explicitly fixing all deprecated usages of things where an automated update is not available.
* The language inherently supports 'facades'; a way for a library at version Y to expose the API it had at version X (X is older than Y), but using the data structures of Y, thus allowing interop between 2 codebases that both use this library, one at version X and one at version Y.
That language might manage the otherwise impossible job of being 'elegant', 'simple', 'mainstream', 'suitable for serious projects', and 'actually good'.
which is kinda horrifying - it means the framework designers didn't find the language powerful enough to express app logic, and hotglued their own custom arbitrary behavior on top of it.
Clear language code should be endeavor to be readable/understandable when printed on a sheet of paper by anyone, acceptable code should be understandable by anyone who knows a bit about the technologies and has some IDE support.
Garbage code is what you have when the code in question is only understandable when you actually run it, as it uses arbitrary framework logic to wire things together based on metadata on the fly.
people have been gluing other languages on top of languages practically forever - it's a DSL.
no single language is ideally suited for every situation, it's not inherently a sign of failure that someone makes a DSL.
and since annotations are part of the language, this is still all "the language is flexible enough to build the framework [despite being wildly different than normal code]" so I don't think it even supports that part.
The ratings are really all over the place. Jshell is a 6/10? What is the rubric?
Joshua Bloch's work on Collections for Java2 was absolutely formative for me.
I was just starting real programming, I knew naming was hard so I was using thesaurus almost as extensively - if not more - than the reference manual.
But his work defined designing API for me for life. Stuff we take for granted, and we often overlook as seemingly trivial.
Let's say you have a collection type that has a method ``put``. It takes two arguments - an object you want to insert, and an index you want to put it at. Which argument should go first? Could index be optional? What value should it default to? Does the function returns anything? A boolean to indicate whether insertion was successful? Or the index at which the object was put? If latter how you indicate an error?
All of these seems seemingly trivial but he and his team worked on that library for over a year and he throughly documented their work in series of presentations.
And we can't forget about his java puzzlers, absolute gem.
My read is that it's easy to be quite negative on Java features when you're not the person they were designed for. For example, the main "customer" of the module system is the JDK itself. The main customer of NIO/2 is the low-level libraries like Netty.
I highly recommend the Growing the Java Language talk by Brian Goetz to anyone who's interested in the philosophy behind evolving the modern Java language [1]. And Don’t be misled by the title, it’s not just about Java, it’s about software design.
[1]: https://www.youtube.com/watch?v=Gz7Or9C0TpM
>For example, the main "customer" of the module system is the JDK itself
As mentioned in TFA, "The general advice seems to be that modules are (should be) an internal detail of the JRE and best ignored in application code"
So yeah, why expose it to those who are not the "main customer"?
> So yeah, why expose it to those who are not the "main customer"?
How did modules affect you as a user? I'd guess that you had to add `--add-opens`/`--add-exports` during one of the JDK migrations at some point. And the reason you had to do it was that various libraries on your classpath used JDK internal APIs. So modules provided encapsulation and gave you an escape hatch for when you still have to use those libraries. How else would you do it while still achieving the desired goal?
It’s just too complex. They should have went with the internal modifier.
Yeah modules isn’t for end users, at least not for the most part
modules get a -10 because they were massively breaking
I'm sorry, please don't hate me (I'm tired and don't have anything better to do) https://files.catbox.moe/ge4el3.png
Why so much hate for modules? They seem to be almost universally disliked by everyone on this thread and I don't understand why.
Modules are weird. In Java world there exists consensus on dependency management via Maven-style repositories (Maven Central is the primary distribution channel) and all tools support it. You handle your dependency tree outside of your code and just import packages from libraries available on classpath. It’s possible to continue doing that that without using modules, so the case for using them is still unclear to many people. Where the actual hate may have come from is an old story with migration from Java 8 to Java 9, where modules hidden the access to certain internal APIs, breaking some libraries which relied on them, making that migration painful. Today their value is probably 0/10, but there’s no reason to hate.
5 replies →
Directly or indirectly many (or most) projects ended up depending on something which was using an unsupported backdoor API because it provided a marginally useful capability. The module system restricted access to these APIs and everything stopped working, unless you added some magic command line arguments to gain access again.
So for most people, the initial impression of modules is negative, and then they just decided to rule the feature out completely. This has created a sea of useless criticism, and any constructive criticism is hardly observed. Improvements to module configuration (combine it with the classpath), would go a long way towards making modules "just work" without the naysayers getting in the way.
3 replies →
They are only useful for a small group of people, and their addition broke/complicated lots of people's builds in non-trivial ways.
2 replies →
They're fine, but they're incompatible with building fat-jars ro have single file deployment and dead to me because of that. Spring does some ugly jar-in-jar custom classloader stuff which I hate out of principle because it's spring.
Oracle hates that people build fat-jars and refuses to adress the huge benefit of single file deployables.
Thanks so much for making this!
thank you so much. this should be included in the original post.
Dude, this is awesome
A cool thing about Doug Lea's java.util.concurrent (received a 10/10 rating here) is that its design also inspired Python's concurrent.futures package. This is explicitly acknowledged in PEP 3148[1] (under "Rationale"), a PEP that dates back to 2009.
[1]: https://peps.python.org/pep-3148/
That is why I think of java when using python's concurrent.future package.
It's nice to review the features, but the history of Java isn't really about features or even programmer popularity.
(1) It was the first disruptive enterprise business model. They aimed to make everyone a Java programmer with free access (to reduce the cost of labor), but then charge for enterprise (and embedded and browser) VM's and containers. They did this to undercut the well-entrenched Microsoft and IBM. (IBM followed suit immediately by dumping their high-end IDE and supporting the free Eclipse. This destroyed competition from Borland and other IDE makers tying their own libraries and programming models.)
(2) As an interpreted language, Java became viable only with good JIT's. Borland's was the first (in JDK 1.1.7), but soon Urs Holzle, a UCSB professor, created the HotSpot compiler that has seeded generations of performance gains. The VM and JIT made it possible to navigate the many generations of hardware delivering and orders-of-magnitude improvements and putting software in every product. Decoupling hardware and software reduced the vertical integration that was killing customers (which also adversely affected Sun Microsystems).
btw, Urs Holzle went on to become Google employee #8 and was responsible for Google using massively parallel off-the-shelf hardware in its data centers. He made Google dreams possible.
The business plan originally was to sell CPUs that ran Java natively. And these would be fast. That idea failed miserably.
Ah Java. The language I never got to love. I came of coding age during the “camps” era of object oriented stuff: Eiffel, Smalltalk, CLOS, C++, etc. Java, from 95ish to oh 98ish, was like a giant backdraft. Completely sucked the air out of the room for everything else.
Does anyone remember the full page ads in WSJ for programming language, that no on quite yet knew what it really was? So my formative impressions of Java on were emotional/irrational, enforced by comments like:
“Of Course Java will Work, there’s not a damn new thing in it” — James gosling, but I’ve always suspected this might be urban legend
“Java, all the elegance of C++ syntax with all the speed of Smalltalk” - Kent Beck or Jan Steinman
“20 years from now, we will still be talking about Java. Not because of its contributions to computer programming, but rather as a demonstration of how to market a language” — ??
I can code some in Java today (because, hey, GPT and friends!! :) ), but have elected to use Kotlin and have been moderately happy with that.
One thing that would be interesting about this list, is to break down the changes that changed/evolved the actual computation model that a programmer uses with it, vs syntactic sugar and library refinements. “Languages” with heavy footprints like this, are often just as much about their run time libraries and frameworks, as they are the actual methodology of how you compute results.
In the early days javascript wasn't far enough along that you could make a web app without a lot of compromises, and the cross-platform nature of java was a big, big plus. I worked on an internal java client application that was developed on Linux for end users on PC. Ten years after we released the first version, and while it was still under development, a group of powerful managers at our company demanded they be issued Macs instead of the PC corporate standard.
When IT asked us if our application worked on Mac, we shrugged and said "We don't have a Mac to test it. We've never run it on a Mac. We won't support it officially, so if there are Mac specific bugs you're on your own. But... it should work. Try it."
And it did work. All the Mac users had to do was click on our Webstart link just like the PC users. It installed itself properly and ran properly. Never had a single issue related to the OS. Before Java was introduced that was an unobtainable dream in a full-featured windowed application.
> I can code some in Java today (because, hey, GPT and friends!! :) ),
I love GPT. Such a marvellous tool. Before ChatGPT came along, I had no medical experience. Thanks to GPT and friends, I am now a doctor. I've opened a clinic of my own.
For whatever reason, gpt-5 writes java code like it is 1995. I think it was trained on decompiled code.
I think the author is sleeping on Java assertions.
I really like the feature, and it's really one of the features I feel Java got right.
The syntax is very expressive, and they can easily be made to generate meaningful exceptions when they fail.
It's also neat that it gives the language a canonical way of adding invariant checks that can be removed in production but run in tests or during testing or debugging (with -da vs -ea).
You could achieve similar things with if statements, and likely get similar performance characteristics eventually out of C2, but this way it would be harder to distinguish business logic from invariant checking. You'd also likely end up with different authors implementing their own toggles for these pseudo-assertions.
I'm quite surprised that he said asserts are not found in production code. Is that really so? I rarely write Java, but in C code we use asserts (in production code) all the time. It's not uncommon for functions to contain 2 or 3 asserts.
I very rarely see assertions in "real" Java code; I think the author is right - in fact the place I see them the most often is in unit tests where they've been used by mistake in place of an assertion library's methods!
I don't know why they're not more popular.
1 reply →
I think they're used less because the main reason for using them in C isn't a consideration in Java, and also they don't accomplish the same thing.
In C, asserts are used as sanity checks, and when one is violated, there's often reasonable suspicion that that memory corruption has occurred, or that memory corruption will occur if the code proceeds in the current state. Aborting the process, leaving a core dump for analysis, and starting fresh is often the safest thing to do to avoid the unpredictable results of corrupted state, which can be insidiously subtle or insanely dramatic. In my experience writing server-side C++, we always ran it in production with asserts enabled, because code that continued to run after memory was corrupted led to the the bugs that were the most destructive and the most mysterious.
Memory corruption is rare enough in Java that 99.9% of code completely ignores the possibility. Also, if you did suspect memory corruption in a Java program, an assert wouldn't help, because it would only throw a runtime exception that would probably get caught and logged somewhere, and the process would continue serving requests or whatever else it was doing.
If you're only doing like CRUD endpoints, they may be less useful, but that's hardly the extent of Java production code. I certainly use asserts in production code quite a lot in Java, though the use biases toward more low level functions, rarely in high level application logic.
What are the pros of making this a keyword vs just a standard function?
At the time the feature was added, there was no way to make a parameter to a function be lazily evaluated. Something like `assert(condition, "error: " + stuff)` would eagerly concatenate the string even when the condition is always true (which it should be). Nowadays, the error parameter can be specified as a lambda, which can potentially be optimized to be just as cheap as the existing assert feature.
You can disable them at runtime (e.g. in prod) to avoid the performance overhead once you're satisfied the codebase is thoroughly enough tested.
For some things like requiring arguments to be non-null static checks with annotations have superseded them (in a confusing way inevitably - I think there are three different common non-nullness annotations).
The pros are that it can generate better error messages, without putting that responsibility on the programmer. Something that would otherwise require a preprocessor or some form of metaprogramming.
I'm wondering this, too.
There's Guava and its Preconditions class[0] that is approximately as terse and I find to be more helpful than everything-is-an-AssertionError.
[0] https://guava.dev/releases/14.0/api/docs/com/google/common/b...
I’m sure there are better ways to do streams on the JVM, scala being a great example, but however imperfect the implementation is streams are such a net positive I can’t imagine the language without them. I pine for the streams API when I write go.
I totally agree with the criticism about exceptions. If you need exceptions inside a stream it turns into a mess.
Overall I agree with you. They are significantly better, even if a little verbose, than not having them. Love cleaning up old loops with a tiny stream that expresses the same thing more compactly and readably.
He’s also right on the parallel benefits not really being a thing I’ve ever seen used.
I'm in agreement, too. The intersection of streams and exceptions was not pretty. Streams are still good, but the feature is a little ugly
I feel this is overly harsh on Collections. You have to take into account just how awful that which it replaced was.
> Java Time: Much better than what came before, but I have barely had to use much of this API at all, so I’m not in a position to really judge how good this is.
Again, it is hard to overstate just _how_ bad the previous version is.
Though honestly I still just use joda time.
>Again, it is hard to overstate just _how_ bad the previous version [of Java time] is.
The original Java Time classes were likely a last-minute addition to Java. They were obviously a direct copy of C language time.h. It feels as if the Java team had a conversation like this: "Darn, we ship Java 1.0 in a month but we forgot to include any time functions!" "Oh no! We must do something!" "I know, let's just port C time.h!"
In my mind Java really got usable in 1.5 with collections and generics.
When you didn’t have collections everything was a complete pain. But after they were added you still had to cast everything back to whatever type it was supposed to be when you got stuff out of collections. Which was also a huge pain.
I know all the arguments about how genetics weren’t done “correctly“ in Java. I’ve run into the problems.But I’m so glad we have them.
I haven't written much Java but I am learning Kotlin and I really appreciate the language and the whole JVM ecosystem. Yeah yeah, Gradle is complicated but it's waaaaay easier to figure out than my adventures with Cmake, and when I read Java code there is a certain comfort I feel that I don't get with other languages, even ones I'm experienced with like Go. Java feels a bit like a stranger I've known my whole life, same with Kotlin. Perhaps despite all its flaws, there is a certain intrinsic quality to Java that has helped make it so popular.
I think you might be getting at one of my favourite features of Java. It's a pretty straightforward simple language. It deals with complexity well by not being too clever. I think Go has that too, except for its error handling and perhaps channels
Maven was peak Java build tool. I detest Gradle. Some people just hate XML enough to doom us all.
Can't speak for everyone, but I think a substantial part of the shift from Maven to Gradle was the ability to write build scripts: you didn't need to write a plugin. I'm hoping that Maven (and Gradle) can take advantage of JEPs 458 and 512 to allow people to write build scripts for that Java projects in Java.
- https://openjdk.org/jeps/458
- https://openjdk.org/jeps/512
I wouldn’t say I’m a fan of maven, but it is absolutely one of the best build/dependency tools I’ve ever used despite its warts.
So many things, even if they came much later, are somehow much worse.
Autoboxing's evil twin, auto-unboxing should knock the score down a few points.
Or my favourite...
Once, after we had an application go live, we started getting reports after a few hours that new users were unable to log in.
It turns out, somewhere in the auth path, a dev had used `==` to verify a user's ID, which worked for Longs under (I believe) 128, so any users with an ID bigger than that were unable to log in due to the comparison failing.
I’ll bite. Why does this not work as you’d expect?
1 reply →
That's another gotcha-- interning of strings and boxed primitives.
Are there linters for this sort of thing? I don't write Java much any more.
2 replies →
If JEP 401 is ever delivered (Value Classes and Objects), then this sort of problem should go away.
2 replies →
This is nuts lol
I'm not much of a PL nerd, what should it do?
Return false! They aren't equal. But of course we're comparing a reference to a primitive, so we either lift the primitive to a reference, or lower the reference... so here we are.
Fail to compile when you assign something which isn't an integer to an integer.
1 reply →
Seems reasonable to me
Interesting; I actually have grown pretty fond of NIO.
I will acknowledge that the interface is a bit weird, but I feel like despite that it has consistently been a "Just Works" tool for me. I get decent performance, the API is well documented, and since so many of my coworkers have historically been bad at it and used regular Java IO, it has felt like a superpower for me since it makes it comparatively easy to write performant code.
Granted, I think a part of me is always comparing it to writing raw epoll stuff in C, so maybe it's just better in comparison :)
There's one thing I deeply dislike with Java NIO: ClosedByInterruptException. If a thread is interrupted (for instance, due to a future.cancel(true) or similar), and it happens to be in the middle of a NIO operation, the channel will be closed, even if it's not owned by that thread. That single thing makes using NIO far more brittle than the older Java IO.
I haven’t used markdown in javadoc yet but this seems like at least 3/10? I often want to put paragraphs or bulleted lists in javadoc and find myself wanting to use markdown syntax for readability in the code but need to switch to less readable html tags for tooling to render it properly.
Personally it’s fine, I haven’t used it though.
I really wish Javadoc was just plain text that honored line breaks. I really don’t care about the fact I can put HTML in there, that just seems dumb to me. I get you can’t remove it but I would be happy if you could.
I do like markdown. But I don’t see myself ever using it in a Javadoc.
I hate using html in comments.
Markdown in javadoc is at least 7/10 for me. Improves comment readability for humans while allowing formatted javadocs.
I wish C# would add this too. I despise having to write docs in XML style
Applets (Java 1.1 - that's where I started),
Servlets (Together with MS ASP, JSP/Servlets have fuelled the e-commerce websites)
I think Java dominated the scene mostly because of its enterprise features (Java EE) and the supporting frameworks (Spring etc) and applications (Tomcat, Websphere, Weblogic etc) and support from Open source (Apache, IBM)
-10 for modules is fair, only 4 for lambdas is not. My programming style changed after using lambdas in Java, even when using a different programming language later that doesn't have lambdas as such.
Lambdas + streams is fantastic. I think if you didn’t have them streams would just be a total mess to use.
I can’t believe lambdas got a 4/10! I’m a student so maybe my opinion will change when I work on “real” code but I really like their conciseness
I've been a developer for over three decades now and I agree with you - Lambdas are really good.
Still no unsigned integer types in the standard library after 26 years?
In one of James Gosling's talks he tells a funny story about the origin of this design decision. He went around the office at Sun and gave a bunch of seasoned C programmers a written assessment on signed/unsigned integer behaviors. They all got horrible scores, so he decided the feature would be too complicated for a non-systems programming language.
Non-systems languages still need to interact with systems languages, over the network or directly. The lack of unsigned types makes this way more painful and error-prone than necessary.
It’s rare I have to do bit math but it’s so INCREDIBLY frustrating because you have to do everything while the values are signed.
It is amazing they haven’t made a special type for that. I get they don’t want to make unsigned primitives, though I disagree, but at least makes something that makes this stuff possible without causing headaches.
Sometimes I'd like to have unsigned types too, but supporting it would actually make things more complicated overall. The main problem is the interaction between signed and unsigned types. If you call a method which returns an unsigned int, how do you safely pass it to a method which accepts a signed int? Or vice versa?
Having more type conversion headaches is a worse problem than having to use `& 0xff` masks when doing less-common, low-level operations.
3 replies →
Which release did they add the URL class that checks for equality by connecting to the internet? 10/10
That mis-feature has been present since Java 1.0, so (as with checked exceptions mentioned above) it's not entirely within the scope of this post.
Bitten hard by this one. I kept a set of Urls to scan. Not all my Urls made it into the set because of IP address equality.
I owe Java a lot. Programming clicked for me when I was taught OOP in Java, my other programming module with event-driven design in C# which I hated.
Fast forward a few years later, and I'm actually at a C# shop.
Fast forward a decade, I'm at the same shop. I adore C# and I fondly remember my foray into Java.
I left Java around the time Streams were becoming a thing. I thought it looked like a mess, and then I ran into LINQ in C# land. Swings (pun intended) and roundabouts.
A little bit bias and opinionated... Tho limited, lambdas and streams were a paradigm shift so big that revamped the love for java into functional programming... Not just a set of features introduced in Java 8.
>little bit bias and opinionated Well, we are reading an individual's blog after all.
Didn't Java 1.3 (Sun's JDK) introduce the JIT? I remember talking to colleagues about what a joke Java performance was (we were working in C++ then). And then with Java 1.3 that started to change.
(Today, even though I still C++, C, along with Java, I'll challenge anyone who claims that Java is slower then C++.)
Maybe not slower once it has warmed up, though for memory-bandwidth bound use cases I would still say the lack of mutable records has you fighting the language to get reasonable cache locality (and everybody will hate your code for not being good Java). The fact that everything is a pointer kills the CPU execution pipeline and cache.
But even for I/O bound applications it still feels slow because excessive memory usage means more swap thrashing (slowing down your entire OS), and startup time suffers greatly from having to fire up VM + loading classes and waiting for the JIT to warm up.
I can start a C/C++/Rust based web server in under a second. The corresponding server in Java takes 10 seconds, or minutes once I have added more features.
The first official JIT became available in JDK 1.1, in 1997. The Symantec JIT was available as an add-on sometime in mid 1996, just a few months after JDK 1.0 was released. Even better performance was possible with GCJ, available in 1998.
The release of HotSpot was in 1999, and became default with JDK 1.3 in 2000. It took JIT compilation to the next level, making tools like GCJ mostly obsolete.
Great list, even if I disagree with many of the ratings!
But astonished that Optional isn't mentioned either there or in the comments. A second way to represent no-value, with unclear and holy-war-ushering guidance on when to use, and the not exactly terse syntax I see everywhere:
Optional<Ick> ickOpt = Optional.ofNullable(ickGiver.newIck()); ickOpt.flatMap(IckWtfer::wtf).ifPresentOrElse((Wtf wtf) -> unreadable(wtf)), () -> { log.warn("in what universe is this clearer than a simple if == null statement?!"); });
Well, it can make some chained function composition easier.
vs
You could maybe move the null check inside the method in the former and it cleans it up a bit, but in the latter you can have methods that are explicitly marked as taking NonNull in their type signature which is nice.
I don't grumble about Java much, I make my living with it and enjoy it. But Optional is a bane.
We use NullAway and I just never use Optional unless it really, really makes sense.
Wow I can’t believe try with resources is so old! I’ve been working with Java for years and only learned this exists recently, I thought it must be relatively new. 14 years!
It was such a lifesaver for doing raw database stuff. The boilerplate for making sure Connection, PreparedStatement, ResultSet and so on were all released properly was a huge pain before that.
Despite it being available at the time I too didn’t learn it until much later. I really wish I had known.
Don't know what version it was, but default functions in interfaces I think is an underrated feature that comes in extremely useful on occasion.
the biggest things to change java have been type inference, lambdas, records, streams (functional ops on collections), and pattern matching. these are all must-have features for any modern programming language. at this point any language without these features will feel old and legacy. it’s impressive java was able to add them all on decades after release, but you do feel it sometimes
For my part, returning to Java a couple years back after 15+ years away, streams + var/val were my favorite discoveries.
Can someone explain why developers like var?
Previously (or if you simply don't use var), a lot of java code takes the form of
This is just straight up a duplicate. With generics, generic parameters can be left out on one side but the class itself is still duplicated.
It reduces (often repetitive) visual noise in code, which can make it more readable. I wouldn’t recommend using it in all cases, but it’s a good tool to have.
To me var is what makes modern java somewhat readable and more bearable. It was always a joke that it takes too long to write anything in java because of the excessive syntax repetitions and formalities. To me that joke is heavily based on a reality that modern Java is tackling with this quality of life features.
I get the attraction to var, but I, personally, don't use it, as I feel it makes the code harder to read.
Simply, I like (mind, I'm 25 year Java guy so this is all routine to me) to know the types of the variables, the types of what things are returning.
doesn't tell me anything.
And, yes, I appreciate all comments about verbosity and code clutter and FactoryProxyBuilderImpl, etc. But, for me, not having it there makes the code harder for me to follow. Makes an IDE more of a necessity.
Java code is already hard enough to follow when everything is a maze of empty interfaces, but "no code", that can only be tracked through in a debugger when everything is wired up.
Maybe if I used it more, I'd like it better, but so far, when coming back to code I've written, I like things being more explicit than not.
2 replies →
I have the opposite feeling. var makes it easier to write but harder to read/review. Without var you know the exact type of a variable without going through some functions for example
It's called type inference and it's the way things should be. You get the same types but you don't have to spell them out everywhere. Java doesn't even go all the way, check OCaml to see full program inference.
OCaml's type inference is truly amazing, makes it such a delight to write statically typed code - reading it on the other hand...
But I think that's easily solved by adding type annotations for the return type of methods - annotating almost anything else is mostly just clutter imo.
2 replies →
It's another thing they adopted from Kotlin, since Kotlin is supposed to be a "better java". Now Java is retroactively adopting Kotlin freatures.
Kotlin didn't invent type inference, it's a feature from ML.
4 replies →
It's terse and it lines up the variable names.
It‘s a harmful code smell: It often obfuscates the type, forcing you to actively check for the type and should not be used.
It is used for things like "Foo x = new Foo()" where the type is obvious.
Your IDE can do that?
5 replies →
This is what it looks like to me. If you wanted to do this, why not use a scripting language where you can use this kind of practice everywhere? In Java, I don't expect to have to look up the return type of something to discover a variable type. Graciously, I can see how you can save rewriting the Type declaration when it's a function return you want to mutate.
Generally, you save some keystrokes to let other people (or future you) figure it out when reading. It seems like bad practice altogether for non trivial projects.
2 replies →
Fully agree with most votings but 3/10 text blocks?!
That has got to be one of the most useful recent features. :-)
The pleasure of just copying and paste text in plain ASCII that looks as intended rather than a huge encoded mess of "\r\n"+ concatenations.
But ok, I'm just an ASCII art fan. ^_^
String sql = “Not having “ +
“to break up “ +
“SQL statements” +
“like this for readability “ +
“thus making them hard to edit “ +
“was incredibly useful at my job.”;
(Note: I put a subtle bug in there because it always happened)
SQL injection is horrible, but people were managing to do that all these years after prepared statements anyway without text blocks. I really don’t think they made things worse. Same thing with embedding HTML in the code. They were gonna do it anyway.
> if you wanted to store an integer in a collection, you had to manually convert to and from the primitive int type and the Integer “boxed” class
I have never worked with Java. What is this? Why would one want to have a class for an Integer?
Primitive variables in Java, such as `int`, `boolean`, and `double`, store their actual values directly in memory. When they are local variables inside a method, this memory is typically allocated on the thread's stack. These primitives do not have the structure or overhead of an object, including the object header used by the Garbage Collector (GC) to manage heap-allocated objects.
If a primitive value must be treated as an object (e.g., when stored in a Java Collection like ArrayList or when passed to a method that requires an object), Java uses a process called `boxing` to wrap the primitive value into an instance of its corresponding Wrapper class (e.g., Integer, Boolean, Double). These Wrapper objects are allocated on the heap and do possess the necessary object header, making them subject to the GC's management.
Aside from this, having such a class provides a convenient place to hold all the int utility functions, and the same for the other primitive types.
It's because the collection types (and generics) don't support primitives, only objects. So you been to stuff the primitives into objects to use them with a lot of the standard library.
One of the more amusing bugs I had to figure out resulted from the fact that some of the autoboxed values get cached, resulting in peculiar behaviour when someone managed to reflectively change the boxed primitive value...
i.e. something like:
I'm a fan of JEP-500...
https://openjdk.org/jeps/500
That doesn't sound very pleasant.
9 replies →
I think your intuition is correct: you probably don’t.
That’s also very likely changing. Lookup “project Valhalla”. It’s still a work in progress but the high level goal is to have immutable values that “code like a class, work like an int”.
PS When I say “changing”: it’s being added. Java tries hard to maintain backward compatibility for most things (which is great).
java.util.Date and java.util.Calendar are the two packages I remember struggling with as a new programmer. Which I guess is solved with java.time after Java 8.
Java is great, Spring ruined the platform.
Clearly someone who never knew EJBs.
(I know the irony of Spring is that it became what it replaced. But it got a good ten or fifteen years of productivity before it began getting high on its own supply. )
Spring and the associated enterprise spaghetti developers have done more damage to the platform rather than the language itself. I've managed to work for almost a decade with Java without using Spring at this point (and count myself lucky for it), but the chances of finding a new job with the same requirement are slimmer and slimmer now.
As someone who has used Java pretty extensively for a few years (but in an environment where Spring was forbidden), why is that?
You’ll find differing opinions.
As someone who has worked on code bases that did not have spring that really should have and had to do everything manually: when used well it’s fantastic.
Now people can certainly go majorly overboard and do the super enterprise-y AbstractBoxedSomethingFactoryFacadeManagerImpl junk. And that is horrible.
But simple dependency injection is a godsend. Ease of coding my just adding an annotation to get a new component you can reference anywhere easily is great. Spring for controllers when making HHTP endpoints? And validation of the data? Love it!
Some of the other modules like Spring Security can be extremely confusing. You can use the Aspect Oriented Programming to go overboard and make it nearly impossible to figure out what the hell is happening in the program.
Spring is huge, and it gets criticized for tons of the more esoteric or poorly designed things it has. But the more basic stuff that you’re likely to get 90+ percent of the value out of really makes things a lot better. The relatively common stuff that you’ll see in any Spring Boot tutorial these days.
4 replies →
The beautiful and essential technique of DI (dependency inversion) got namesquatted hard by DI (dependency injection).
Before, you used to write "loosely coupled" software by decoupling your business logic from your IO to keep it testable. You could take virtually anything worth testing, 'new' it in a unit test, and bob's your uncle.
Now you write "loosely coupled" software by keeping the coupling between components, but also couple them to a bunch of Spring dependencies too (check your imports!). Now you can't instantiate anything without Spring.
Sorry, but several of these ratings are just plain wrong. I am not even a Java developer these days, but it is extremely clear that author did not work in a domain that rightfully leveraged the Java features he rates as of little use.
He would have been better served by opening a poll - that would have opened his eyes to the use of these features.
Its like giving operator overload a rating of 1 in C++/Python. Sure, if you don't find any need for it in your domain, it would look stupid to you.
so java 22, 23, 24 are all released in 2024?
No, it's a 6 month release cadence. You might be confusing the initial release with a point release which are less regular. Edit: oh, my bad, I see the article author had the wrong year for 24.
This is much better than the old "release train" system where e.g Java 5 and Java 6 were released in Sept 2004 and Nov 2006 respectively!
I don't know what to make of this list...
Very strange reasoning and even stranger results: Streams 1/10?! Lambdas (maybe the biggest enhancement ever) a mere 4/10?!
Sorry, but this is just bogus.
I will make any excuse to use Streams but understand the negativity. They are difficult to debug and I feel the support for parallelism complicated, and in some cases even crippled, the API for many common use cases.
I'm that author. It has been more than a decade and still won't use streams nor lambdas. Makes the code too difficult to write and debug for me.
Really prefer to have more lines of code and understanding very clearly what each one is doing, than convoluting too many instructions on a single line.
For me it's the opposite: If I had to write the code that I usually use lambdas for in any other way then _that_ would be very difficult to write and to debug.
Especially when writing JavaFX code which is full of callbacks and event handlers I really don't see any other (useful) option.
Can lambdas be misused? Of course they can - but so can every other code construct.
I bet you don't like how it looks when you put huge code blocks inside a lambda. Me neither. But that's an issue with coding style; it forces you to extract processing code into a method. I'd argue the opposite way - imperative syntax constructs make spaghetti code too easy to work with.
They're a bit verbose, the interfaces are slightly convoluted and some basic operations are missing from the standard library.
It's also a little convoluted to work with different types of data.
For this one, I wish they would have taken a bit more inspiration from other languages and spent the time to make it more readable.
That said, I generally like streams a lot, and they do reduce the amount of branching, and having less possible code execution points makes testing easier too.
[dead]
Zaxo
It appears that most of the good changes are imported from C#.
Most of original C# was imported from Java, so there's that...
Or Scala. Or Kotlin. Or any of the other languages that had most of these features years if not decades before Java. ;)
Yeah that's very much an explicit design philosophy of Java, dating way back. Let other languages experiment, and adapt what proves useful.
It hasn't worked out in terms of delivering perfect language design, but it has worked out in the sense that Java has an almost absurd degree of backward compatibility. There are libraries that have had more breaking changes this year than the Java programming language has had in the last 17 releases.
11 replies →