Knock knock Who's there? long pause Java
Oh, I see, jokes from 30 years ago!
What else are you supposed when keeping up with platforms proves too difficult!
Java 27
301–310 of 427 posts
Re: Java 27
#302Re: Java 27
#303Earlier quoted context omitted.
Same question for .net or C# Why should anyone use it over Java? Ms is hostile towards its developers, it creates new versions of things, deprecates previous versions, uses confusing naming for newer versions.. etc.
Null pointer dereference problem. Solved for greenfield C# projects and Kotlin
Also solved for Java:
Re: Java 27
#304Earlier quoted context omitted.
Whoever works with, or chooses Java, is not doing it for the language itself, be it beautiful or not. Java has a huge ecosystem, from battle tested integrations to optimized images to build pipelines to whatever, so at the same you're buying access to all this world (yes, more than an environment). And of course transferable skills. I'm not saying Java is alone offering this, also not saying every feature is the best…
Java's ecosystem is lingering since Oracle brought the language, and it's at the point where you should really look if the things you want to use are still in the state of the art, or if they felt behind every other language. And if you are starting from scratch, whatever part of the ecosystem you use, I'm not optimist on its situation improving with time.
It hasn't been lingering since they were bought by Oracle. We've seen a rapid increase in the pace of feature and performance development.
Re: Java 27
#305Earlier quoted context omitted.
In the absence of a sarcasm tag, would you care to explain your reasoning?
I have a strong belief (mostly borne out by my years as Java dev) that the larger the possibility space of a language (and its ecosystem) the more room there is for inappropriate use and unclear code. Add time and an assortment of rolling devs of mixed ability level, and crap mounts faster then a "simpler" language. Let me be clear: Do I think it is possible to write good, clear, performant code in Java? Of course -…
Golang tried to be simple, but reality hit and they started adding features (generics, and now generics on method, iterators, fixed loop variable scoping). Yet when you program in it, you can feel so much resistance because it took a naive approach to simplicity.
Re: Java 27
#306Earlier quoted context omitted.
Which features exactly? Java got exhaustive pattern matching before C# (through sealed interfaces), it has switch expressions, multi-line strings, green threads and structured concurrency, is getting value types, and even type classes in the work.
Granted, I havent' used either for a couple of years, so my knowledge is a little rusty. Yes, some of them are "just syntax sugar", but man oh man does it make C# such a pleasant language to work with. Used to work at a company which had services both in Java and C#, so some of Java's decisions or indecisions felt like pain points when switching between the two: - Proper IEnumerable with proper iterators that in turn…
> Proper IEnumerable with proper iterators that in turn enables Linq
Are you referring to generators?
> Properties
As far as I'm aware, it is a deliberate choice not to implement them, and I can see their point of view.
> object initialisers
I believe the same justification applies here, it's mainly syntactic sugar, and can result in certain undesired behavior by bypassing constructors where validation can happen.
> extension methods
Typeclasses are currently being explored, which are a superior approach.
> named and optional arguments in functions
Those would be nice (at least named arguments). I can see how optional arguments could complicate things.
> generics over primitive types
As you mentioned, it's in the works
> async/await... verbiage could still probably be hidden behind a friendlier syntax
The approach they took does not need any extra syntax.
Re: Java 27
#307Serious question: when should one use Java for greenfield projects in 2026?
When building boring web applications with a sizeable team that need to run for a long time. Hiring developers is easy since there are many, there is nearly no magic and the language is quite strict and type safe so it works well with a large team. And that "team" nowadays may also consist of many AI agents. In my experience Claude Code for example works very well with a typed, slightly boring language with lots of f…
> Hiring developers is easy
> And that "team" nowadays may also consist of many AI agents.
And that's the part where the hireability arguments collapse. Sure Claude Code works pretty well with Java. It also works well with Typescript, Python, Go and Rust. It would use types on all of these languages, and run a type checker or LSP on the dynamic ones. And while Java is statically typed, Rust has a stricter type system that prevents some types of runtime bugs that Java's type system won't like data races and forgetting to release a resource.
Re: Java 27
#308Earlier quoted context omitted.
Why not Kotlin?
Most organizations that use Java tend to be pretty conservative with their technology picks and nowadays with newer Java versions the only real gap with Kotlin is null-safety which is supposed to also come to Java at some point. There is also an organization culture component most of the time, one our engineers actually proposed to use Kotlin for one of the new projects but it got rejected because "We are a Java shop…
> Most organizations that use Java tend to be pretty conservative with their technology picks
That part i s true.
> with newer Java versions the only real gap with Kotlin is null-safety
But that part isn't. Kotlin has:
- Structured Concurrency: Coming to Java sometime in the future, but it's been in preview for very long now.
- Standalone functions that don't have to live in classes
- Properties
- Property delegation
- Data classes: more powerful than records. Can be used for large DTOs that you can modify with copy(). Java needs something like Lombok to make records more useful.
- Extension methods
- Context parameters
- Operator overloading
- Implementation delegation
- Inline functions (which can receive returning closures and reified types)
- Block syntax (supports `it` for unnamed arguments)
- Sequence abstractions: more powerful and more efficient than Java streams due to the inlining and block syntax.
This is just a partial list, but Kotlin clearly has a lot of things that Java doesn't. If you only personally care about NPEs that's fine, but that's not the only thing.
Re: Java 27
#309Re: Java 27
#310Earlier quoted context omitted.
> Go has null pointer dereference problem. Which Java famously does not have. > Rust is too low-level for typical enterprise app where requirements changes twice a day. You end up spending time and tokens fighting with borrow checker. In my experience, you do not spend tokens fighting with the borrow checker anymore, newer models are smarter. But it might not be ideal for a lot of CRUD applications. > C# is MS produc…
> Rust is just as ergonomic as any other popular language today if you're using an agent Have you worked on large (>500KLOC) codebases with an agent? Not only do you have to be an expert at the language, but even if you're lucky and everything is fine, Java code is likely to be particularly fast by comparison, because the agents aren't very good at manual optimisation, especially as the code grows (they're even worse…
Have you worked on large (>500KLOC) codebases with an agent?
Yes. But keep in mind KLOCs are not easily comparable across languages. Java is notoriously verbose. A 500KLOC codebase in Java would usually be half that size in Rust. If your argument is that large codebases makes life harder for agents, you should go with a less verbose language.
I'm not sure what "manual optimization" means (isn't it a bit of an oxymoron when the agent does it?), but if your agent has the proper tools (e.g. ast-grep, rg, semble) it can deal with large codebases. Would the agent create slop? Yes. But it wouldn't be worse on the slop that humans created on every moderately-sized Java project I've worked on.
> in fact, agent-written code in a low-level language gets pretty slow well below that size
I've never seen this happening. I've seen agents writing suboptimal Rust code (e.g. copies instead of Cow). But while this occassionally happens with Rust, I've never seen an agent optimizing for Java where necessary (e.g. using object pools to avoid GC churn). Java is not magic.