The Oracle Java Platform Extension for Visual Studio Code(inside.java)
inside.java
The Oracle Java Platform Extension for Visual Studio Code
https://inside.java/2023/10/18/announcing-vscode-extension/
121 comments
I love VS Code, but I will never be able to work with Java code outside of IntelliJ. Hopefully this extension is a bit more stable than the Red Hat one, whenever I've attempted to use VS Code for Java it's hit or miss whether plugins or the language server crash.
I feel even Pycharm and Goland are superior to VS code.
The gap is closing but it's still noticable.
The gap is closing but it's still noticable.
> Intellij's refactoring crown
Not sure IntelliJ has a crown here. I use Eclipse and it has some pretty amazing refactoring options. And I really prefer it to IntelliJ (for my use cases at least). Are there particular things IntelliJ can do that Eclipse can't?
Not sure IntelliJ has a crown here. I use Eclipse and it has some pretty amazing refactoring options. And I really prefer it to IntelliJ (for my use cases at least). Are there particular things IntelliJ can do that Eclipse can't?
I tried eclipse again last year and, while I cannot say it has bette for worse refactoring, I don’t understand how it could possibly be better given that its detection of available symbols seems to be little more than an RNG.
Yeah. I've been doing software engineering (mostly Java) for 20 years now. Eclipse stooped being relevant among professionals around 2008.
You'll still find eclipse or NetBeans users though, just like you'll find people browsing the web with Lynx : - )
You'll still find eclipse or NetBeans users though, just like you'll find people browsing the web with Lynx : - )
2008 was 15 years ago and many of the people I've spoken to formed their opinion of Eclipse (and IntelliJ) at that time. But what you saw back then and now isn't anywhere near being the same software.
Can you explain why Eclipse is worse than IntelliJ today?
Can you explain why Eclipse is worse than IntelliJ today?
I think I last used eclipse about 5 years ago, when I switched to VSCode. At the time, eclipse still felt like 2008 software, extremely sluggish and clunky. In particular, it really suffered taking advantage of multiple monitors.
What's changed since then? Has it gone through some kind of massive redesign?
What's changed since then? Has it gone through some kind of massive redesign?
Intellij's vim plugin is good.
Could you please explain? You say you don't know if it's better or worse for refactoring and then you say it's detection of symbols is like a random number generator? How so?
When I used eclipse, it is suggesting symbols from locations that are not even contextually available. Given how much refactoring often relies on accurate contextual symbol detection, there’s about a 0% chance that it does better than IntelliJ.
I didn’t even get to trying eclipse features because everything else in it is so remarkably stupid, useless, and actively battling me compared to IntelliJ.
I didn’t even get to trying eclipse features because everything else in it is so remarkably stupid, useless, and actively battling me compared to IntelliJ.
I have been working on enterprise Java projects (basic consulting) which uses eclipse almost exclusively. We do not use Smurf naming convention (SmurfDto, SmurfDao, SmurfService, SmurfController) just for being able to find related classes. We do it because eclipse seems to randomly refactor classes based on non fully qualified names. No to naming something Constants as that will (randomly) refactor the codebase to break partially if you decide later to refactor something in that class.
I have tried everything from no vendor plugins for app servers to a vanilla eclipse and it still messes up.
I do like the product, but it can be very frustrating at times.
I have tried everything from no vendor plugins for app servers to a vanilla eclipse and it still messes up.
I do like the product, but it can be very frustrating at times.
Kotlin. I switched to Intellij due to Kotlin, in is slow in Eclipse
But seriously, Eclipse was helping me more then Intellij does and has better defaults. It shows all errors and warnings at once etc. Even things Intellij actually has like call hierarchy tend to be sort of hidden by default.
But seriously, Eclipse was helping me more then Intellij does and has better defaults. It shows all errors and warnings at once etc. Even things Intellij actually has like call hierarchy tend to be sort of hidden by default.
"The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin."
From https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...
From https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...
I find all these posts slamming java and suggesting to use all the either much smaller jvm languages or something like python / go / rust utterly hilarious. If you want to get paid the big bucks in a high col city, you are a java or c++ dev, simple as. Sure work on your smaller languages, more pay for the rest of us!
I don't get it - Is this an LSP, or specific to SCode? If it is an LSP, it would be nice if the project advertised this in the README.
Any comparision with the Redhat one + "Extension pack for Java" that was the main way to go for Java in VSCode?
RedHat one is buggy and slow, but it works after tinkering and display a lot of warnings and code suggestions.
This extension loads instantly without any issues but it show 0 warnings/errors in my project. "Find all references" works as expected.
same, also interested in a comparison before I switch from the Redhat one
Java developers are spoilt for choice right now. IntelliJ is on it's own plane of existence, newest versions of Eclipse are really really nice, and now this which is based on the Netbeans engine!
Hands down Java tooling, and especially the JVM debugger, is the absolute best across all languages available today. Truly is an incredible platform
Hands down Java tooling, and especially the JVM debugger, is the absolute best across all languages available today. Truly is an incredible platform
As someone who's happy with using VS Code for everything including Java projects, could someone explain to me how VS Code falls short vs IntelliJ?
I think 5 years ago I would've preferred IntellJ, but VS Code has made a monstrous amount of progress since then and it's only accelerating.
I think 5 years ago I would've preferred IntellJ, but VS Code has made a monstrous amount of progress since then and it's only accelerating.
I think it's something you have to try out. I use all three.
IntelliJ has just a billion little streamlined features that make the entire experience just smooth. Eclipse is in second place here, but VsCode with Java is a very distant third.
IntelliJ is functions without a lot of annoying bugs; everything is well tested and just works. Eclipse is buggier, and usually lags behind on supporting the latest JVM/Java/Framework features without bugs, but Eclipse has nothing compared to VsCode. VsCode just is just full of half completed features that work in very narrow circumstances. I don't know what to say; it's just not very well integrated, lacks a singular vision, and things generally are just broken.
IntelliJ has just a billion little streamlined features that make the entire experience just smooth. Eclipse is in second place here, but VsCode with Java is a very distant third.
IntelliJ is functions without a lot of annoying bugs; everything is well tested and just works. Eclipse is buggier, and usually lags behind on supporting the latest JVM/Java/Framework features without bugs, but Eclipse has nothing compared to VsCode. VsCode just is just full of half completed features that work in very narrow circumstances. I don't know what to say; it's just not very well integrated, lacks a singular vision, and things generally are just broken.
So - I'm not a Java programmer, but I do a lot of C# in Visual Studio 2022, Visual Studio Code and JetBrains Rider (which is built on the InteliJ engine), so I guess I have a unique perspective. Rider is hands down better at refactoring and generally having features "out of the box". Visual Studio 2022 is pretty buggy recently, especially for mobile, which is the bulk of what I do recently. VSCode is okay... got better recently (the C# Plugin is now a full on full Microsoft first party offering), but VSCode is still less like an IDE, more like a code editor.
I guess VSCode seems to march to its own drum and some of how it integrates things is really clunky still. I spent a long time ignoring JetBrains, but once I started to use Rider (and Android Studio) I realised how much better they were in general.
With Android development (which to be fair I mainly do on the side), I remember Eclipse being reasonably hard to get set up. That might have just been with how immature the Android tooling was back then. But from the very first version of Android Studio, it all seemed coherent. And with all the built in refactoring and tooling there is now, it is really a full circle and you don't exactly need anything else.
Edit: it is also worth pointing out that adding Resharper to VS2022 makes it a lot nicer, but in my book that is basically the same as using Rider because then most of the refactoring is taken away from the Microsoft IDE's engine and goes though the same/similar path as it does in Rider (as Rider uses the Resharper Engine too.)
I guess VSCode seems to march to its own drum and some of how it integrates things is really clunky still. I spent a long time ignoring JetBrains, but once I started to use Rider (and Android Studio) I realised how much better they were in general.
With Android development (which to be fair I mainly do on the side), I remember Eclipse being reasonably hard to get set up. That might have just been with how immature the Android tooling was back then. But from the very first version of Android Studio, it all seemed coherent. And with all the built in refactoring and tooling there is now, it is really a full circle and you don't exactly need anything else.
Edit: it is also worth pointing out that adding Resharper to VS2022 makes it a lot nicer, but in my book that is basically the same as using Rider because then most of the refactoring is taken away from the Microsoft IDE's engine and goes though the same/similar path as it does in Rider (as Rider uses the Resharper Engine too.)
Java and .NET ecosystems are the closest in modern computing to how Lisp Machines and Smalltalk used to be.
It isn't 100% there, but close enough.
Hence why I have been an happy camper on both of them since they exist.
It isn't 100% there, but close enough.
Hence why I have been an happy camper on both of them since they exist.
So, do we have two competing Java extensions for VSCode now?
Seems like it, one based on NetBeans/Oracle the other Eclipse/RedHat.
[deleted]
Better Java LSP is beneficial not only to VSCode users, but for all LSP-powered editors too.
How many LSP-powered editors are there?
All of them? At least the ones under active development, like Emacs, Vim/Neovim, SublimeTree, Helix, and Kakoune...
Most of the serious programmer oriented editors support LSP to some degree now. Vim, emacs, Sublime, etc. Even JetBrains’s IDEs support it in addition (or alternative) to their own custom tooling.
I mean there is Visual Studio Code and then there is ... Visual Studio code. So it seems there many editors in market.
It looks like all of the JetBrains IDEs support LSP as well:
https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-d...
https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-d...
vim, emacs, atom, elipse, intellij, kate, sublime text, the list goes on.
https://microsoft.github.io/language-server-protocol/impleme...
https://microsoft.github.io/language-server-protocol/impleme...
Sorry if dumb question, but is LSP similar to what Steve Yegge talked about years ago, I think on a StackOverflow podcast, whereby a language would declare its capabilities to tooling?
I haven't listened to the podcast you mention, but the answer to your question is yes. Quoting the langserver.org homepage[0]:
> The Language Server protocol is used between a tool (the client) and a language smartness provider (the server) to integrate features like auto complete, go to definition, find all references and alike into the tool
In LSP terms, these are called "capabilities". The relevant section in the LSP spec is here [1].
There's some variation across editors in exactly how the config works - or, at least, part of it. Some config is done in native files that form part of the plugin. Those are largely editor-specific. The protocol itself defines messages for the server to indicate which facilities it supports. Those are (mostly) editor neutral from my experience thus far (mostly VSCode, a little Emacs).
--
EDIT: added link to capabilities section in the LSP spec.
[0]: https://langserver.org/
[1]: https://microsoft.github.io/language-server-protocol/specifi...
> The Language Server protocol is used between a tool (the client) and a language smartness provider (the server) to integrate features like auto complete, go to definition, find all references and alike into the tool
In LSP terms, these are called "capabilities". The relevant section in the LSP spec is here [1].
There's some variation across editors in exactly how the config works - or, at least, part of it. Some config is done in native files that form part of the plugin. Those are largely editor-specific. The protocol itself defines messages for the server to indicate which facilities it supports. Those are (mostly) editor neutral from my experience thus far (mostly VSCode, a little Emacs).
--
EDIT: added link to capabilities section in the LSP spec.
[0]: https://langserver.org/
[1]: https://microsoft.github.io/language-server-protocol/specifi...
Yes, the genius of LSP is that it doesn't attempt to define common semantic operations across languages, which would be (and has been) an endless impossible task to get right. It operates at the level of editor UI. So you don’t ask LSP “what are the members of this struct”, you ask it “what are the autocompletions of this code fragment”. It leaves the decisions about what would be appropriate in the language to the language server written by the experts in the language.
Sort of, except not really. It’s largely the other way around: LSP gives the editor a way to declare its capabilities to the language.
The key insight with LSP is that languages are _way_ too different to have that notion of language capabilities. Instead, the LSP defines functionality that the editor wants to use (syntax highlighting, refactoring, autocomplete, etc) and the language server tells the editor what to display.
When you trigger autocomplete in VSCode, the editor has no clue whether it’s autocompleting a method, a class name, or a variable. It’s just telling the language server “hey the user asked for autocomplete in file X, offset Y” and the language server tells the editor what completion options to offer.
The key insight with LSP is that languages are _way_ too different to have that notion of language capabilities. Instead, the LSP defines functionality that the editor wants to use (syntax highlighting, refactoring, autocomplete, etc) and the language server tells the editor what to display.
When you trigger autocomplete in VSCode, the editor has no clue whether it’s autocompleting a method, a class name, or a variable. It’s just telling the language server “hey the user asked for autocomplete in file X, offset Y” and the language server tells the editor what completion options to offer.
> The key insight with LSP is that languages are _way_ too different to have that notion of language capabilities.
And yet the very opposite of this is the source of JetBrains success.
And yet the very opposite of this is the source of JetBrains success.
Haven’t seen the podcast
Lsp doesn’t declare language capability, the editor asks it what the editor should do and the LSP responds
This is great news. I'm trying to move from Idea to vscode and Java support could be better. I think that Jetbrains missed the chance to introduce their tooling to vscode.
That would eat into their profits.
All the relevant parts of IntelliJ that could be turned into Java language server are already open source so monetization would be tricky.
All the relevant parts of IntelliJ that could be turned into Java language server are already open source so monetization would be tricky.
Cool, a headless netbeans LSP server is great. It was a while ago but I failed to get the Eclipse based LSP client to work smoothly in neovim.
More LSP servers for Java is good. The Eclipse based one seems to work for me as part of lsp-mode for Emacs, but equally I'd love to see the IntelliJ one mature, and a Netbeans one isn't bad to have either.
Are you able to get proper jump-to-definition for stuff in jars? Say you’ve declared an import from a jar, and you get to that import and run ‘jump-to-definition’ (or whatever it is), are you taken to the source of the import? I’m sure IntelliJ idea does this but I cannot get emacs+jdtls+eglot to do this
Works fine for me in lap-mode, never tried eglots.
still bloated and takes to long event for startup compare to netbeans as an IDE.
But does it require a herd of consultants to install and maintain like all other oracle technologies?
Oracle needs to refocus on Eclipse and leave Visual Code crap alone, focus on Eclipse and kick the enterprise Red Hat yahoos out of the Java space. Red Hat gave up on developers when they split Red Hat into the enterprise version and Fedora garbage.
By making their own implementation of a Java LSP they could integrate this in any number of editors and IDEs, including JetBrains products:
https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-d...
https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-d...
I think you'd have to be crazy to use a different Java LSP for JetBrains, but it's a useful feature for other languages to be sure.
Netbeans you mean.
Eclipse has always been mostly about Red-Hat and IBM, which is what Red-Hat alongside Microsoft use for their VS Code extension.
Eclipse has always been mostly about Red-Hat and IBM, which is what Red-Hat alongside Microsoft use for their VS Code extension.
Eclipse must have started as a joke about covering the "Sun".
"It turned out Sun wasnt the target of the Eclipse moniker, though. In his keynote at the EclipseCon 2005 conference in March, Lee Nackman, chief technology officer and vice president of Design, Construction, and Test Tools at IBMs Rational Software division, said Microsoft Corp. was actually the company IBM wanted to 'eclipse' and was the true object of IBMs attention."
- https://www.eweek.com/development/eclipse-behind-the-name/
- https://en.wikipedia.org/wiki/Eclipse_(software)#Name
- https://www.eweek.com/development/eclipse-behind-the-name/
- https://en.wikipedia.org/wiki/Eclipse_(software)#Name
Serious question, is Red Hat a risk to the Quarkus project? I haven't started any new applications on anything but Quarkus for a couple of years. I would love to use Helidon, but the features and production stability just aren't there yet.
Any single vendor product that does not conform to a specification is, ergo Quarkus (was).
Now, Quarkus _finally_ got pulled into JakartaEE certification kicking and screaming, however, it has a million out-of-spec features that I see as risky and likely to break in the future... Spring Framework is now big fat and ugly for this reason!
Quarkus's initial philosophy of "Kubernetes first" really isn't such a good rally cry anymore. They've toned down on that, but it does influence the framework to this day.
I think if you program and stick to "just the" Jakarta Spec you are in good hands (which Quarkus now implements, along with other APIs). CDI absolutely rocks and is probably the easiest to write fast code for, but also make it composable so it's very testable.
I'm hoping someday the Apache Foundation (maybe the TomEE crew?) comes out with a leaner competitor to Quarkus, basically something thats "just the cdi container" and you can pull in stuff as needed.
Now, Quarkus _finally_ got pulled into JakartaEE certification kicking and screaming, however, it has a million out-of-spec features that I see as risky and likely to break in the future... Spring Framework is now big fat and ugly for this reason!
Quarkus's initial philosophy of "Kubernetes first" really isn't such a good rally cry anymore. They've toned down on that, but it does influence the framework to this day.
I think if you program and stick to "just the" Jakarta Spec you are in good hands (which Quarkus now implements, along with other APIs). CDI absolutely rocks and is probably the easiest to write fast code for, but also make it composable so it's very testable.
I'm hoping someday the Apache Foundation (maybe the TomEE crew?) comes out with a leaner competitor to Quarkus, basically something thats "just the cdi container" and you can pull in stuff as needed.
Red Hat owns Quarkus, so they are a risk or a benefit depending upon your perspective.
"Leave Visual Code crap alone".
Except that the vast majority of new and even old developers moving to VSCode prefer it over janky 20+ year old IDEs.
I like working on multiple ecosystems and not having to re-learn the wheel for each.
Except that the vast majority of new and even old developers moving to VSCode prefer it over janky 20+ year old IDEs.
I like working on multiple ecosystems and not having to re-learn the wheel for each.
What are you talking about? What is the relation between Fedora’s decision and the JBoss acquisition?
I used to love netbeans back in the day for java development
> Fedora garbage
Care to explain ?
Care to explain ?
Stop using Java just let it die for the love of all that is holy
It's more alive than it has been in years.
It's not going anywhere due to masses of legacy code. It's less of a popular choice for new projects than it ever was.
I'd totally pick Java for a new project in 2023.
The stable and mature ecosystem and fantastic tooling along with very low amount of library churn makes it one of the better options for anything server-side.
The stable and mature ecosystem and fantastic tooling along with very low amount of library churn makes it one of the better options for anything server-side.
You get all of this by choosing Kotlin or Scala.
Yeah, but why though? Seems like mostly a bandaid for old Java version.
It's probably the most widely chosen language for new projects today across the board from enterprises to startups.
I've not seen a new project started in Java in a decade, and it's pretty far down in the StackOverflow developer survey [1]. Do you have some data to back your claim up?
[1]: https://survey.stackoverflow.co/2023/#section-most-popular-t...
[1]: https://survey.stackoverflow.co/2023/#section-most-popular-t...
Every language above Java in that list (except possibly TypeScript) is forced by the development target or domain. JavaScript and HTML are forced by web dev. SQL is forced by databases. Python is forced by machine learning. Bash is forced by targeting UNIX.
Also there’s no such thing as “an HTML project” or “a SQL project.” So I don’t think your survey link is telling you what you seem to think it’s telling you.
Also there’s no such thing as “an HTML project” or “a SQL project.” So I don’t think your survey link is telling you what you seem to think it’s telling you.
What Java Application can't be written in Javascript/node?
You can write anything in JS, but it's not suitable for a great deal of things.
[deleted]
[deleted]
> It's less of a popular choice for new projects than it ever was.
Totally disagree. I think it was at its trough of popularity in the Java 8 initial release timeframe around 10 years ago, when many companies were still stuck on Java 6 and other languages had moved way ahead. In the last few years, since around Java 17, there has been a ton of enthusiasm and I think it would be the best choice for a huge number of use cases.
Totally disagree. I think it was at its trough of popularity in the Java 8 initial release timeframe around 10 years ago, when many companies were still stuck on Java 6 and other languages had moved way ahead. In the last few years, since around Java 17, there has been a ton of enthusiasm and I think it would be the best choice for a huge number of use cases.
Java/JVM is still the best platform for large/complex/enterprise server applications.
Java is not the JVM. Lots of new projects on the JVM go with Kotlin or Scala.
JVM is the Java. It is literally reference implementation. JVM changes to accommodate changes in the Java language, not the other way around.
Are you saying that there are no other languages than Java that target the JVM?
You're loose with the terms. Java is not "literally reference implementation", it's the platform language of JVM.
While this is a major advantage, Java has also its fair amount of problems, some of them unfixable (or rather, the Java team is unwilling to fix them). It looks like Java will never get a proper fix for the whole in the type system named null, while there are some great languages running on JVM solving that.
While this is a major advantage, Java has also its fair amount of problems, some of them unfixable (or rather, the Java team is unwilling to fix them). It looks like Java will never get a proper fix for the whole in the type system named null, while there are some great languages running on JVM solving that.
Whatever problems it has, Java calls the shots on JVM.
Nah, a drop in the Java ocean outside Android.
That is simply not true. In the Enterprise space it is probably in the top two.
What does "Enterprise space" even mean?
Medium to big companies outside the HN bubble.
Do you mean non-tech/non-software companies?
No quite. Amazon (including AWS), Google, Netflix, Snowflake. From my own personal experience.
[deleted]
What's the other one ? C# ?
> It's less of a popular choice for new projects than it ever was.
[Citation needed]
[Citation needed]
Aside from the meme-y "Java is slow" argument, what's wrong with Java? What language would you use instead?
Java has an incredibly mature ecosystem, and Java 11/17/21 fix a _lot_ of the problems Java had.
Java has an incredibly mature ecosystem, and Java 11/17/21 fix a _lot_ of the problems Java had.
Java is the new COBOL, though modern and more vibrant obviously, and that's not a bad thing. Plenty of work to be had for a long time to come.
COBOL is probably better compared to PHP or Ruby. COBOL was never as popular as Java, and its popularity was relatively short lived; by the time it was 20 it was quickly falling out of favour. In 2023, Java is the #1 most popular choice for serious server side applications, and is in the top 3 overall on pretty much any language ranking you can find. In terms of longevity and super-popularity, its only counterparts are C, JS, and Python. Comparing Java, or Python or JS for that matter, to COBOL completely misses both COBOL's history and the current state of the ecosystem.
Honestly, Java has a lot going for it. Amazing library ecosystem. Simple to learn, like Go but with essential quality-of-life improvements. Community without PLT sadists. Fast as all hell when written with care. Vast variety of jobs. Super-polished dev tooling.
I know there problems too (verbose, OOP and enterprise over-design, some horrible legacy systems) but Java is as strong as ever I think.
I'm interested, have you worked in Java before on a bad project and have scars, or have you built up a negative impression from afar?
I know there problems too (verbose, OOP and enterprise over-design, some horrible legacy systems) but Java is as strong as ever I think.
I'm interested, have you worked in Java before on a bad project and have scars, or have you built up a negative impression from afar?
..and a real debugger
> have you worked in Java before on a bad project and have scars
My guess is that the opinion is just used as a way to signal their status as a 'pro' developer much in the same way people used to hate on PHP/Perl/VB/etc. endlessly.
Ironically, this makes them look like amateurs posing as pro developers, as real pro developers demonstrate their status through their work, not their posts on social media.
> have you worked in Java before on a bad project and have scars
My guess is that the opinion is just used as a way to signal their status as a 'pro' developer much in the same way people used to hate on PHP/Perl/VB/etc. endlessly.
Ironically, this makes them look like amateurs posing as pro developers, as real pro developers demonstrate their status through their work, not their posts on social media.
What's wrong with it? I don't program really (at least yet) and Java actually seems like a neat language to learn.
Nothing is wrong with Java.
Java has some plusses and minuses like any language.
Java has:
* Fantastic concurrency support (Better than Javascript, Python, or C)
* One of the largest most mature library systems in existence, with far fewer amateurish "left pad" type libraries like Javascript or Python
* Supported basically everywhere by any vendor you can imagine
* Pretty good strong type system to reduce bugs, and making refactoring very easy
* plethora of frameworks for your use case, whether its server side rendering, monolithic apps, Raw SQL or ORM, microservices, reactive.
* Probably the best tooling and ides in software development.
* getting lots of new features to alleviate pain points with the newer rapid development
Negatives for Java:
* C# has linq
* Type system isn't as advanced as OCaml
* Generics have type erasure due to backwards compatibility
* verbose and lots of boiler plate
Java has some plusses and minuses like any language.
Java has:
* Fantastic concurrency support (Better than Javascript, Python, or C)
* One of the largest most mature library systems in existence, with far fewer amateurish "left pad" type libraries like Javascript or Python
* Supported basically everywhere by any vendor you can imagine
* Pretty good strong type system to reduce bugs, and making refactoring very easy
* plethora of frameworks for your use case, whether its server side rendering, monolithic apps, Raw SQL or ORM, microservices, reactive.
* Probably the best tooling and ides in software development.
* getting lots of new features to alleviate pain points with the newer rapid development
Negatives for Java:
* C# has linq
* Type system isn't as advanced as OCaml
* Generics have type erasure due to backwards compatibility
* verbose and lots of boiler plate
> * Probably the best tooling and ides in software development.
Agreed on the IDEs, nothing can beat IntelliJ... but general tooling? Definitely not. Maven is a hot mess of XML where people tend to do horrible horrible hacks just to survive, and Gradle projects tend to be even messier because of Groovy's syntax allowing about five different ways of doing the same thing.
Agreed on the IDEs, nothing can beat IntelliJ... but general tooling? Definitely not. Maven is a hot mess of XML where people tend to do horrible horrible hacks just to survive, and Gradle projects tend to be even messier because of Groovy's syntax allowing about five different ways of doing the same thing.
> Gradle projects tend to be even messier because of Groovy's syntax allowing about five different ways of doing the same thing.
Spoken like a true "I've never seen Gradle beyond copy pastes from Stackoverflow". Modern Gradle is all about plugins written in Kotlin. Your buildscripts shouldn't have anything beyond `implementation` block.
Spoken like a true "I've never seen Gradle beyond copy pastes from Stackoverflow". Modern Gradle is all about plugins written in Kotlin. Your buildscripts shouldn't have anything beyond `implementation` block.
> Spoken like a true "I've never seen Gradle beyond copy pastes from Stackoverflow".
Which is what the majority of legacy, grown Gradle scripts are in my experience among multiple government and private companies' projects. The older the project, the worse state the build scripts tend to be. The worst I ever encountered was a project that was mainly done with Maven, but that called out to Gradle and Ant for weird manipulations to get the build artifact to the formats required... gives me nightmares to this day.
Which is what the majority of legacy, grown Gradle scripts are in my experience among multiple government and private companies' projects. The older the project, the worse state the build scripts tend to be. The worst I ever encountered was a project that was mainly done with Maven, but that called out to Gradle and Ant for weird manipulations to get the build artifact to the formats required... gives me nightmares to this day.
I'll give you gripes with maven/gradle (even though maven tends to just work for me), but look at all of the observability tools like Mission Control, Flight Recorder, and VisualVM. What other language has all of this?
Is it any good for beginners?
There's nothing really wrong with it, but it's core design is pretty outdated in ways that are difficult to fix without putting together a totally new language. Couple of examples
- Support for nullable values. Swift and Kotlin have first class support for these, which are meant to minimize or reduce the number of null pointers in your code. You can mostly fix this with annotations, but those your team using them very consistently, and are not supported by most java libraries.
- It's approach to concurrency. Java built in synchronization primitive is based upon an older model of concurrency whose name I cant remember but it involves every object basically being able to maintain internal consistency with it's own state. No one still uses it like this, with most method creating an `Object lock` as a synchronization primitive.
- Serialization. Java has built in binary serialization support that ended up being a massive security hole. Most people are now forced to use some json serialization, but the old serialization format is still lurking in the background to ensnare less knowledgeable programmers.
- Generics. Smarter people than me can probably give you more detail on this, but generics were grafted on to the language long after it was introduced, and it shows. At runtime, there are no generic types kept, meaning it is technically possible to break the generic typing of an object.
None of these it should be noted are deal breakers or reasons why you shouldn't use the language. Almost every single one has some form of workaround for it. But if you're not aware of them (or stuck with an older legacy codebase like a lot of people are) they can be major headaches that can just be avoided by using a more modern language.
- Support for nullable values. Swift and Kotlin have first class support for these, which are meant to minimize or reduce the number of null pointers in your code. You can mostly fix this with annotations, but those your team using them very consistently, and are not supported by most java libraries.
- It's approach to concurrency. Java built in synchronization primitive is based upon an older model of concurrency whose name I cant remember but it involves every object basically being able to maintain internal consistency with it's own state. No one still uses it like this, with most method creating an `Object lock` as a synchronization primitive.
- Serialization. Java has built in binary serialization support that ended up being a massive security hole. Most people are now forced to use some json serialization, but the old serialization format is still lurking in the background to ensnare less knowledgeable programmers.
- Generics. Smarter people than me can probably give you more detail on this, but generics were grafted on to the language long after it was introduced, and it shows. At runtime, there are no generic types kept, meaning it is technically possible to break the generic typing of an object.
None of these it should be noted are deal breakers or reasons why you shouldn't use the language. Almost every single one has some form of workaround for it. But if you're not aware of them (or stuck with an older legacy codebase like a lot of people are) they can be major headaches that can just be avoided by using a more modern language.
Care to explain why. I am in favor of all the maturity of several libraries and framework
No minds will be changed here, but -
I use the termal and I make binaries for my use. I'm not going to try to pipe input through several stages of "java -jar myUtil.jar", even if I bother to clear the hurdles of trying to find and configure the right maven plugin to build a "fat" jar.
Null drives a big hole through whatever you try to achieve with the type system. Need a Key for this Lock? Open the Lock anyway, just find out at runtime that the Key was null, rather than at compile time.
Bizarre omissions from the standard library. What do you do with Sets: Union? Intersect? Nope, write them yourself. Wait for a multiple futures? Write a for-loop. Cancel a future? Forget about it. Wait - better than forgetting about it: include cancel() on the class but make it a no-op.
Non-extensible. Let's say the language designers for some reason didn't put takeWhile into Stream. Can you add it?
No way to avoid mutation in order to avoid non-local reasoning about state. If I submit a list as a parameter or accept a list as a parameter, who else has mutated or will mutate that list.
No transactions. Synchronised blocks don't compose: synchronised get() and synchronised set() do not become synchronised getThenSet();
I'm sick of the 'backward compatibility' at all costs. The 'legacy code' that you're thinking of that you don't want to break was written after any of these problems could have been fixed.
I use the termal and I make binaries for my use. I'm not going to try to pipe input through several stages of "java -jar myUtil.jar", even if I bother to clear the hurdles of trying to find and configure the right maven plugin to build a "fat" jar.
Null drives a big hole through whatever you try to achieve with the type system. Need a Key for this Lock? Open the Lock anyway, just find out at runtime that the Key was null, rather than at compile time.
Bizarre omissions from the standard library. What do you do with Sets: Union? Intersect? Nope, write them yourself. Wait for a multiple futures? Write a for-loop. Cancel a future? Forget about it. Wait - better than forgetting about it: include cancel() on the class but make it a no-op.
Non-extensible. Let's say the language designers for some reason didn't put takeWhile into Stream. Can you add it?
No way to avoid mutation in order to avoid non-local reasoning about state. If I submit a list as a parameter or accept a list as a parameter, who else has mutated or will mutate that list.
No transactions. Synchronised blocks don't compose: synchronised get() and synchronised set() do not become synchronised getThenSet();
I'm sick of the 'backward compatibility' at all costs. The 'legacy code' that you're thinking of that you don't want to break was written after any of these problems could have been fixed.
> I use the termal and I make binaries for my use. I'm not going to try to pipe input through several stages of "java -jar myUtil.jar", even if I bother to clear the hurdles of trying to find and configure the right maven plugin to build a "fat" jar.
https://docs.gradle.org/current/userguide/distribution_plugi...
> Null drives a big hole through whatever you try to achieve with the type system. Need a Key for this Lock? Open the Lock anyway, just find out at runtime that the Key was null, rather than at compile time.
https://github.com/uber/NullAway and bunch of rest.
https://docs.gradle.org/current/userguide/distribution_plugi...
> Null drives a big hole through whatever you try to achieve with the type system. Need a Key for this Lock? Open the Lock anyway, just find out at runtime that the Key was null, rather than at compile time.
https://github.com/uber/NullAway and bunch of rest.
After 20 years of writing C# I was planning to pick up Java as my go-to language.
C# and Java are so close they could be siblings.
If you want to grow, I'd look at diving into a language with a fundamentally different paradigm like Common Lisp/Clojure/Scheme/Erlang/Elixir/F#/OCaml/Haskell.
If you want to grow, I'd look at diving into a language with a fundamentally different paradigm like Common Lisp/Clojure/Scheme/Erlang/Elixir/F#/OCaml/Haskell.
What's wrong with C# ?
It's open source now... I miss the restrictive licensing. Call me weird.
You are weird :D
No. Java is awesome.
It's not nothing, it's a solid step on from the Redhat Java LSP. Intellij's refactoring crown is not at risk here though.