In terms of complexity, it really depends on what you want to do. Using a powerful framework like Spring can entail some config (albeit much less than it used to). Also you would typically use a build tool like maven or gradle to manage dependencies, build artifacts, etc.. Especially maven can be a little arcane. But another major upside of the aforementioned maturity is that there are reams of docs and stackoverflow answers which will almost certainly contain solutions for any problems you might encounter.
This is both a blessing and a curse. Some answers and docs are decades old and although still work, are not “fashionable java” (think streams, for instance).
Has that gotten better recently? It's been years since I've toyed with it.
A lot of cruft is still there; Date, File, InputStream/OutputStream, sun.misc.Unsafe, and the entire legacy reflection API are the bunch that stick out to me. Newer releases are actively mentioning their legacy status in documentation, and there are certainly JEPs to remove them or make them opt-in/opt-out.
If you look at OpenJDK internals, or even the foreign function/memory APIs as described in the article, it looks almost nothing like the Java I learned on and wrote for several years. Most of the Panama API is piggybacking on additions to the language made post-JDK9 or so, such as MethodHandle, VarHandle and @PolymorphicSignature methods. So I'd say the language and runtime is evolving nicely, even under the thumb of Oracle.
I think I missed the announcement of those being "legacy" APIs? They show up all over the place including in libraries, what is the replacement?
Did I miss something somewhere ? java.lang.reflect is still the standard way of doing Reflection.
This is it. There are things which are better in Java than in the other ecosystems you mentioned (e.g. dependency management) and there are things which are worse (the language is more chatty, maybe the designs tend to be more convoluted, but this differs project to project). Even enterprise Java has come a long way, it's different to what it has been a decade ago, it's definitely more lean.
Every sane developer uses either Jetbrains' product for JS, Python or Rust, or they use VS Code, which, after installing all plugins to reach the same productivity as with Jetbrains, becomes an IDE as well.
You seem to vastly overestimate the usage of IDEs with scripting languages. In my experience, the vast majority of developers working with scripting languages such as JavaScript, Python or Rust, still use plain text editors such as Vim or Sublime Text. They find these editors to be more convenient and faster than IDEs.
Even people who are on VS Code seem to be using only the built-in language support for scripting.
https://lp.jetbrains.com/python-developers-survey-2021/#Deve...
State of JS doesn't seem to include the question any more, but it found in 2019 that about 70% used one of the two (mostly VSCode).
https://2019.stateofjs.com/other-tools/
VSCode may not be a full IDE without extra plugins enabled, but it's a far cry from a plain text editor.
one of these, is not like the others :)
> They find these editors to be more convenient and faster than IDEs.
FWIW, survey responses from 2021 imply that 54% of Rust devs use VSCode, 28% use a vi variant and 21% use IntelliJ[1].
[1]: Page 19, https://raw.githubusercontent.com/rust-lang/surveys/main/sur...
Definitely not in my experience, most people I know use VSCode, which I wouldn't call a plain text editor (not necessarily an IDE either though). Most people will use the plugins for each language since those are auto-recommended when you open a new file in that language, such as Pylance for Python, and most people will click "install recommended plugins" and call it a day.
Vim users are few and far between in my experience, and Sublime Text even more so, most everyone has migrated to VSCode at this point that I know of.
And emacs users never had a plain text editor, never claimed as such, and woe be to you if you call it such in front of them. Lol.
But surely, for advent of code scripting you don’t need it, but neither does Java.
There are all kinds of things that you can pile on top of it, usually for managing big projects. Those can seem arduous when you're at the Hello World level. If you got introduced to those it will seem daunting and unnecessary (and for many projects, it is).
But basic Java is no more onerous than Python or JavaScript. About the only difference at that scale is that Java requires type notation, but no more so than C.
And I wrote Java for over a decade with vi. IDEs make it better, but they are not necessary. (And good ones are free anyway.)
- Pattern matching
- Sealed types
- Records (immutable, succinct data-classes)
- Multiline strings
Among other things. It's almost as nice to use as Kotlin, and I say this as a huge Kotlin fan. Its pattern matching in most recent releases is actually more powerful than Kotlins, since it allows deconstruction-bindings in patterns.
Since Java's history is very focused on not breaking things (and folks got really grumpy on the few occasions something has been broken), Java cannot ever match the feature pace of languages like C# either.
But the folks writing Java code (most of you here on HN by all metrics), mostly don't care. They enjoy backwards compatibility and stability far more than new features. The overwhelming majority of newly written Java code is targeting Java8 still - which doesn't use any of these new features anyway.
Backwards compatibility is also why things like lambda's and streams are the way they are in Java (and most FP folks would sneer at), and things like Records took years to release (still technically in the Preview stage).
The advantage Kotlin has, and the reason it's growing in popularity in backend development is you get all the FP tasty features you want right now, but maintain near drop-in compatibility with existing Java libraries and frameworks. This was the most brilliant move by the Kotlin designers in my opinion...
Java 8 users are now a minority. Some libraries still target it (although Spring 6 targets 17 as the baseline), but most Java code is in applications.
> Java can never be Kotlin
Java doesn't want to be Kotlin because it aims at a much wider audience. Back in the nineties James Gosling laid out a strategy of an innovative runtime wrapped in a conservative language that only adds the most beneficial features, and only after they've been successfully tried in other languages, and this has worked very well.
Also, the Java language has the advantage of controlling the runtime, which allows us to add a smaller number of features, which are more powerful (e.g. compare records with data classes, or virtual threads with syntactic coroutines), while Kotlin can neither change the runtime nor have a significant impact on the ecosystem, and so is more limited in what it can achieve. Moreover, Kotlin's features are increasingly mismatches with the evolution of the platform.
Nevertheless, we are happy that the platform offers more feature rich languages to the minority of developers that do prefer them (or languages with radically different approaches, such as Clojure), so the platform can cater to programmers with different language preferences.
That's by deliberate choice. They are going down the route of having the last mover advantage. Lots of people have complained about C#'s kitchen sink type of approach for example. And the more features you have, the more chance that they won't fit together neatly and cleanly.
A couple of examples that come to mind, Java's pattern matching/destructoring and upcoming string templates (JEP 430) are much more fully fledged compared to their Kotlin counterparts.
It also has the advantage of being the platform language. Now that we have virtual threads on the JVM, async/await immediately becomes irrelevant. However, Kotlin now has to maintain coroutines even though the platform offers a better way of doing things.
The amount of syntax I see literally 1:1 taken over by dozen other languages is really impressive and evidence for that.
That would be the case for pretty much any language that has lots of features (provided that most of those features aren't completely terrible). A good design (at least for a mainstream language) also strives to minimise the number of features, not adding everything you can but only adding things you absolutely need. In the case of C#, many of its features are not widely adopted, and Java in particular will never adopt them.
Java's philosophy has always been to wrap an innovative runtime in a conservative language that only adds features late, after they've proven their worth elsewhere and when most mainstream programmers are ready for them, with the realisation that every added feature adds a cost to learning the language. That strategy has worked very well for Java, but .NET has a different strategy (a more adventurous language built on top of a less adventurous runtime). We'd rather spend two years thinking about how to avoid adding a new language feature than spend six months adding it. This "last-mover" strategy has helped us maintain our philosophy and keep the number of features small compared to C#. We strive to only add features that have a big bang-for-the buck and that, preferably, solve many problems at once, rather than add many features, each addressing a relatively small problem. For example, virtual threads have allowed us to avoid adopting async/await; records are allowing us to avoid adopting properties, and will likely help us avoid adding named and default parameters as a separate feature (which, in languages like C#, Swift, and Kotlin breaks binary compatibility/separate compilation).
Very cool. Is there any material available about this for further reading?
A lot of its features for functional programming got swallowed up in later C# versions, and it's the Red-Headed Stepchild of the CLR (let's pretend VB.NET doesn't exist).
MS allows it to exist but it's a second-class citizen on the CLR, and, I think, always will be =(
And F# was created as a research project and is a lot more community driven than C#. So if Microsoft starts putting more people onto that, I think a part of that community will also scream that they should stay out.
I know those numbers, and can even refer to the blog post they were presented, if a big company like Microsoft wants people to use language XYZ, they can make it happen if management cares about it.
However they aren't caring enough to sort out the GUI civil war, so why would the .NET languages by any different, regarding coherent management across the board.
Thank God. Don’t get me wrong, C# is a cool language but languages suffocate under so many features, most devs will simply never ever learn most of them. And some of these features while invaluable in certain rare cases, I would rather prefer a better, more fundamental feature that takes more time and single-handedly solves for many situations.
Unfortunately modern languages really like to throw in everything they have seen from other languages ever, and even with very smart language designers these features will inevitably tangle (khm, swift).
I recently wrote a database buffer pool with it, allocating raw aligned memory and directly casting bytes from DB files into in-memory struct pointers.
It's very nearly a systems language in terms of capabilities.
CsWinRT and win32metadata are still quite far from a great usability experience.
The last things missing are properties (which should be coming with reconstructors), and nullable types. For me, nullable types are not worth the switch.
All that being said, I don't think the languages are mutually exclusive. As a JVM developer you retain all your knowledge of the JVM and it's standard library. Lastly, a language doesn't have to be the dominate language on a platform to be usable and employable (just look at Scala).
What Kotlin features are possible because of that freedom ? Genetics can be an example I can’t say it’s impossible for Java to add in out refied keywords
It's still a fairly verbose language, but it's miles from where it was 10 years ago.
I’m kind of excited now to try it again.
But to actually provide an answer, records shorten the language to a great degree in my opinion, there is also type inference with `var`, so on a local scope you can write really short code. The main method is still chatty, but it’s not like you actually have to write all that many times, plus it is just psvm for most IDE users.
I think the whole config/generated files thing is for old-school J2EE "enterprise Java". Most of the frameworks I've used have just involved writing code. Sure, sometimes you need a config file, but that's pretty normal -- most of the time I'd rather specify things like port numbers and logging configuration in a separate config file, rather than hard-code them in the app themselves. If you stay away from the old-school Java Servlet frameworks -- or use a framework that builds on top of servlets and hides the complexity -- then you don't have to deal with that crap.
The build ecosystem is a bit more fragmented than Rust (maven or gradle or sbt or...), and the build tools do require a bit more boilerplate to configure, for the most part (especially maven), but it's not too bad. JavaScript, IMO, has some of the most inscrutable build systems I've ever seen, so I don't think that's comparable to Rust, or even Java. Maybe the complexity of Java build systems is similar to Python, though in different ways.
The recent releases of Java have added a lot of quality-of-life improvements to the language, so it's a lot more pleasant (and less verbose) to write Java than it used to be. I still prefer something like Scala (2; haven't tried 3 yet), but it's a lot easier to build a team around Java than Scala.
And, yes, I agree 100% about your reference to low cost developers. From an enterprise view, it is cheap and easy to find (low quality and) low cost developers to maintain legacy Java software.
You also wrote: <<... static typing allows for deterministic refactoring of bad code. That's something you can't easily do in JavaScript.>> Most JavaScript devs would immediately reply: "Oh, use TypeScript for that." As I understand, you can incrementally upgrade a legacy JavaScript project to TypeScript, then slowly add types. Also, I have refactored lots of Java code that uses Object as a substitute for C's void*. That type of code is so difficult to understand without a debugger. Also, very difficult to refactor due to limited typing.
I worked take a second look at IntelliJ and Eclipse; learn the keyboard shortcuts. Modern Java is incredibly well put together.
Most of the tooling is provided, and it's coherent and robust.
Ultimately - both Maven and Groovy, which are used for production level build and packaging, are a 'weird'. But getting going with them is relatively easy.
Java has introduced the concept of 'Modules' - which if you don't get straight in your head, can be confusing, but ultimately it's not that bad.
Compilation is relatively fast as well.
The 'IDE' tends to 'hide a lot of things' in ugly ways - that is true. All of the JAVA IDEs are weird about that. However - because Java is a well maintained language, the IDE's can be powerful and are actually worthwhile. Jetbrains being one of them.
Sadly, Java on VSCode is a bit of a mess.
On Android, Google has introduced a bunch of odd conventions and complexities which I feel are unnecessary.
...Although I will admit that whether its feasible or useful to demystify the magic varies from case to case.
As for Java, an IDE helps a lot for Java because the build landscape is quite tedious otherwise.
If anything I’d say JS has a more complex configuration story than Java.
Also, sprint is not slow at all, especially that servers are very famously IO-heavy. Nonetheless, you can expect better performance for these with project loom.
I'll take that a a major plus. Sometimes things are improved by what is taken away.
> I don't see any real use of Java in 2022 and beyond.
Well, you see what you see; and the cloud infrastructures sees what it sees.
The last time I poked at it, there were just so many config and generated files and so much complexity that it felt like I must use an IDE that hides a layer of “magic”.
Or am I just confessing ignorance and this isn’t a thing and it’s no more complex and magical than Rust or JavaScript or Python?
Edit: thank you all for the helpful responses.