VSCode is growing which is concerning, not from a competitive point of view but actually from the point of view that there is clearly a lack of understanding of what an IDE gives you. VSCode is a code editor with some features that you’d find in an IDE, and extensions that can provide additional functionality – so if people are turning to VSCode for developing it may imply that developers don’t know what a fully-featured IDE can give them. In the web space it is understandable to use an editor as web developers are typically working with dynamic languages, and often use other tools like browser plugins to give them what they need.. But in Java, especially professional Java, you really get a lot out of a good tool that has integration with the application server and you can really use the analysis and refactoring and everything.
IME a lot of developers don't like their IDE heavily coupled to backend servers and environments, but actually prefer the "code editor + useful features" approach. It makes combining with CI/CD a lot simpler for one, since the activities run on a project can simply be the same as those run on the pipeline. A quick "mvn install" is often enough for many/most modules. Many devs only really want advanced editing + syntax highlighting + language server.
What an absolutely tone deaf thing to say. "It can't be our product that's using out dated philosophies. It's the users that don't know how to use it properly"
In good faith, I read it as "users don't even know what they're missing out on". To be honest, I feel like some of the comments here are at least partially proving them right in this regard.
The article now has an update that confirms your reading:
I can see that by using an abridged and edited version of my analysis of the data for this blog post that I’ve unintentionally spread confusion. I’d like to clarify the intention behind my comments on developers and IDEs. For me, if developers don’t understand what IntelliJ IDEA gives them as a fully-featured IDE, that’s a failure on my part, since it has been my job for six years to educate developers on what an IDE (specifically IntelliJ IDEA) can do for you. I feel very strongly that one should never blame users, or prospective users, for failing to understand a product.
My personal viewpoint on IDEs for Java developers comes from having been a Java developer for 20+ years, working on production Java projects large and small. I can’t imagine trying to create a complex enterprise application without the considerable help you get from an IDE like IntelliJ IDEA. I have also seen lots of developers using VSCode and I completely see the use cases that code editors cover well. There’s always room for more than one tool in your toolkit, and understanding what a tool does well helps us pick the right one for the right job.
I used IntelliJ for almost two years, JS and Java. I hope I never have to use it again. It's laggy, clunky and with a less than intuitive UI. Yes, it is powerful but it doesn't weigh up for its shortcomings.
I never did understand all the Eclipse hate, especially when compared to IntelliJ. I use both regularly and the only thing Eclipse is missing for me is a proper searchable command pallete. Code navigation, refactoring, debugging and version control all work great, it's much faster and resource-friendly than IntelliJ and many things are a lot more straight forward (like the lack of IntelliJ's confusing changesets and non-native file pickers).
I work on an enterprise project with 100+ gradle projects and a pile of targets for docker containers, kubernetes deployments, DB schemas, Redis stuff, etc..
Eclipse is incredibly slow in this use case compared to IntelliJ and would frequently gobble 10GB of Ram. I switched from Eclipse to IntelliJ earlier this year after years on this project and IntelliJ is amazingly better.
But if you're using some different build system and a different type of project configuration maybe it's the other way around..
The last project I used Eclipse on consisted of like 50 different maven modules. Plus we were also using a mix of Java and Scala code. The Scala plugin we were using seemed to make everything run very, very slowly. At times, it couldn't even keep up with my typing.
This was back in 2011 though. Obviously things have changed.
The difference between Eclipse and IntelliJ was like night-and-day, however, in terms of performance.
I used Eclipse a long time ago and it had horrible performance. But IntelliJ quality had been really bad in recent years. Minor updates causing major performance regression, taking massive CPU when nothing is being worked on. It was way more stable product in earlier versions.
Perhaps Eclipse has improved. The last time I personally used it for a project was back in 2011. It was slow, laggy, and I found the UI to be less friendly than IntelliJ. Obviously some of that is personal preference.
Neither did I. I was introduced to Eclipse before I got my first job and today, 9 years later it still gets the job done. I briefly use IntelliJ IDEA CE only for one static analysis plugin that works better in IDEA, most code editing is in Eclipse.
I don't love eclipse, not a person to get too attached to an IDE, but it is an incredible piece of open source software. It works.
Also too much effort in rewiring keyboard shortcuts that have made their way to my muscle memory. So eclipse it is.
Thanks!! I opened it once by accident and haven't managed to find it again (it's not called "command pallete" so I couldn't find anything in the docs). I suck at remembering keyboard shortcuts, so this is going to be a significant productivity boost!
Funny InteliJ made me love Eclipse again, and other than Android Studio, I don't plan to touch anything made by JetBrains unless required to do so due to work contracts.
I recently used VS Code for a personal project involving embedded C++ development. I used the PlatformIO extension. It was nice! I will definitely try it for other projects in the future.
I haven't had this experience - but I do have a relatively powerful PC (16gb ram, SSD, Ryzen 3600). IntelliJ has always been really responsive for me, even on large projects.
In my experience helping others get set up, slow JetBrains tools are usually an AV problem, or a (shudder) spinning rust problem. It seems like the developers agree, given that new versions will offer to setup AV exceptions for you automatically.
Well, seems heavy handed either way to give vscode such attention when vscode was only 4% of respondants. Seems reasonable that you wouldn't want a full fledged IDE in certain cases. For example, a small simple project, or if you're mainly a frontend dev who just needs to add a small API
It would make much less sense to wait until the cool, free tool was more popular before reacting to it, no? They're not worried about eclipse, it's not very well liked. VS Code by comparison has a lot of shine on it.
I feel like it's on the product to make those benefits apparent and easy to use. They're selling me (the user) not the other way around. The message comes off very privileged IMO.
I'm admittedly an IntelliJ fanboy but I also make extensive use of VS Code and I think JetBrains are 100% correct. The kind of extra features you get from a really good IDE are so easily worth it if you spend even a small amount of time learning how. You may need to invest an hour or two getting it to understand your project setup but then you have real-time debugging, refactoring, granular test running (and debugging) right away. I think the move away from IDEs is coupled to the move away from strict typing (which I also hate) because IDEs lose value when they can't reliably understand your code.
Yes, but on the other hand, IDEs are slow. I don't mean to say VSCode is lightning fast, but it starts in less than a second. By that time, IntelliJ didn't even open it's loading window. And were talking about a top-of-the-line Ryzen 7 laptop with an NVMe SDD.
For longer sessions that's not a problem, but when you're on battery or quickly hopping into the project to look something up it makes a lot of difference. Also, opening up a foreign project is two clicks and one second, compared to project creation and then loading+indexing when using IntelliJ.
I love the IntelliJ line of IDEs. But VSCode outcompetes it in simplicity by far. Especially when we're talking about something like a simple Node project, where compilation+execution is far simpler than something with a full build pipeline with artefacts.
But the trade off here is indexing. Visual Studio code provides no indexing functionality by default (some LSPs provide basic caching but not much). This is the killer feature for me. I can load up Kubernetes in Goland, cook an egg on my laptop while it indexes (about a minute) and have lightning fast goto def and find reference for the rest of the day. VS Code will load quickly but every single goto def will take ages.
I prefer to have the application ran on my machine in a fashion similar to how I'm going to deploy it. Using a "large" ecosystem IDE detracts from that as the application is now ran by an application rather than in a system. And almost all the features you listed are possible in VSCode. You just have to take an hour or two to set your system up to run it.
> And almost all the features you listed are possible in VSCode
As someone who wishes they could drop everything else and just use Kate or VS Code, I disagree. IDEs like those that JetBrains offers have refactoring tools that are unmatched by what VS Code and its plugin ecosystem currently provide.
Depending on the language you're writing VS code plugins are a bit hit and miss. I've tried using it for Rust dev for example, and everything kind of worked, but with way too much jank. I constantly had problems with autocomplete suggestions being duplicated and linting being slow or not updating errors. Enough to make me wish I had a dedicated IDE.
More widely used langs have better experiences though I'm pretty sure. And maybe Rust support has gotten better? Seems that other commenters in this thread had positive experiences.
There has been rapid improvement in rust-analyzer for a while, so yeah, stuff has been getting way better for quite a long time. Every week there's new stuff with it.
I think there's room for both. And if I've learned anything watching node developers working in VS Code it's that they work exclusively in webpack dev mode and let npm worry about production.
I get real-time debugging, refactoring, and granular test running/debugging in VS Code. I also work almost exclusively in TypeScript, F#, and Rust. My anecdata says that this argument isn't very accurate.
How is there a move away from strict typing? If anything it's the opposite in dynamic languages - Python/typing, Ruby/Sorbet, JS/Typescript, PHP/type hints.
For those who don't know, JetBrains has a plugin for Rust (I think really targeted at CLion but i think its installable from multiple IDEs like Pycharm as well)
VSCode doesn't interpolate HTML variables for me. Its the small features that add up over time I miss whenever I try to switch development environments.
VSCode has a really good TypeScript/JavaScript and admittedly Python developer story, and the ecosystem has produced some pretty robust Style editing extensions, but if you want things like autocompletion for your template variables, I've always found you have to look elsewhere, whether it be handlebars, django templates, Jinja templates etc (and this is one example, among many)
VSCode doesn't autoload JSON schema (need an extension or hope for the best)
VSCode Extensions are also suffering from some pretty serious lack of maintenance too. Lots of extensions, very little movement on updates. I've had more than one of them break on me in major ways.
I wonder how much of that is just the lack of really good IDE tooling for Rust? GoLand is pretty good, so I don’t know if similar question applies to Go.
Java pretty much requires an IDE because it's verbose, bloated, everything is inconvenient without IDE assistance and it's easy to create bugs.
Something as simple as opening a file of code requires IDE, because everything is hidden behind `./src/main/java/com/whatever` nonsense. The language was designed for IDE.
In Rust there is hardly any need for IDE (or a debugger), as long as your text editor has LSP support. Hell, even without LSP support it feels quite OK to write Rust code.
I use Intellij for Java, and Kakoune for Rust, and I really dislike working with Java. The fancy refactoring features don't make up for how verbose, clunky and inexpressive Java is.
The Rust way is to have great modular and reusable tooling for everything. Even stuff like complex refactoring can be achieved without an IDE with something like https://github.com/google/rerast
Yes but they are clearly missing something and that's simplicity. I use goland because ei get go refractor and move utilities but I get annoyed when I feel like I have to fight it to do simple things. I think the default keyboard shortcuts between the two products show a lot.
Yeah, they just don't get it, they have stayed for so long in the enterprise java world that they can't comprehend that everybody else moved on from those bloated IDEs. On my case if I had a choice even between Notepad++ and IntelliJ (to pick an extreme example), I would still use Notepad++.
VScode is a very nice middle ground where the defaults make sense and you can get powerful extensions for everything else you want, there's a reason it's so popular.
Am I the only one who finds it a little bit ironic to call IntelliJ bloated, and then recommend VS Code, which may not be that "bloated" feature-wise, but is based on a browser engine, so also not really light on resources? A VS Code-like product using the Sublime Text engine would be the ideal development tool for me. As long as that's not available, I'm using PHPStorm at work (my company is paying for it) and VS Code for my private projects in Go - still haven't tried out Goland, IntelliJ's Go IDE, but so far I'm happy with VS Code.
HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing. I don't know what Electron does under similar circumstances because I've never tried to measure it, but I know that I regularly see Electron apps using less than 70MB, so we can estimate an upper bound on Electron's typical contribution to bloat as being no more than ~30% of Java's.
For a slightly more apples-to-apples comparison that's also quite a bit more apples-to-jicama, if I open vscode and IDEA on the same project (a small one I'm just getting started on), vscode and all its helpers are using 316MB, and IDEA is using 1.08GB. I doubt that much of that difference is actually attributable to using a browser rendering engine for GUI layout. In fact, I'm guessing that Chromium's net impact on the situation falls below the noise threshold of this comparison. So, yeah, not worried about it. FWIW, vscode also started up quite a bit faster, and I experience less keyboard lag when using it.
And, if we're looking for mature and full-featred cross-platform GUI toolkits, that's about it for your options. Yes, there's QT, but, with a sticker price of $4000/developer/year, it's hard to criticize people for not choosing it. And there's GTK+, which is fine, I suppose, but not exactly everyone's cup of tea.
Long story short: This Electron-flaming meme is getting old. If you don't like JavaScript, just come out and say it. If you don't like how Chromium is eating the world, that's a fair point, too. But stop scapegoating Electron for things like how Slack's desktop app used to leak memory at an astonishing rate. That was always the app developer's fault, not Electron's.
> HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing.
This is much lower in newer jdk's [0].
> For a slightly more apples-to-apples comparison that's also quite a bit more apples-to-jicama, if I open vscode and IDEA on the same project (a small one I'm just getting started on), vscode and all its helpers are using 316MB, and IDEA is using 1.08GB
I believe this to just be intellij bloat and not JVM because it just does too much. I run VSCode with the Java plugins and ZGC (read: eclipse language server, which is all jvm) and the language server only ends up using around 250mb of ram.
I that you're right that it's just IntelliJ doing too much. Similar to how the Slack app's formerly astonishing memory consumption was because it was trying to retain all of Giphy in memory for all time.
Somewhat related, back when I was a C# developer, I spent a long time being confused over the community's somewhat polar opinions on whether Visual Studio is slow and bloated, or lean and snappy. Eventually I realized that the difference of opinions was because some people's employers buy them copies of ReSharper, and others don't.
IntelliJ has more features than even the best language service I’ve used, C#’s. The language server tools are catching up but for integration and polish you still can’t beat JetBrains.
On the subject of the (lack of) snappiness in Visual Studio + ReSharper, Jetbrains Rider comes with the ReSharper functionality built in and feels a lot snappier.
HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing
Mmmm, I have two projects open in IntelliJ right now, one of which is quite large, quite a few tabs, and it's using 366mb of heap.
You have to watch out though - Java won't collect garbage if it doesn't have to. This fools a lot of people. They look at memory usage and assume it must really be using that much memory, even when it's not. From the perspective of the JVM if the memory is there, it may as well be used, because freeing RAM just to leave it pointlessly empty just wastes CPU time, battery, generates waste heap etc. Why not use it? The only time it matters is if you have something else that wants the memory and it can react to that I believe. Or if you're measuring it against other tools of course.
I guess over time this will go away as a talking point because the JVM is getting more aggressive at collecting memory even when there's RAM spare, partly because of containers and partly because of threads like this one.
That's already happening with modern JDKs and GCs; as of JDK 12, G1 uncommits unused heap eagerly (see https://openjdk.java.net/jeps/346), and the parallel GCs Shenandoah and ZGC do the same.
Considering how avid Electron user tell others how files should not be even bigger than few hundred lines considering electron croaks on that. Or without irony they tell how fast Electron is on 6-core/32GB machines and that everyone should upgrade. They should be last person to talk anything about performance.
> Long story short: This Electron-flaming meme is getting old.
No I think it remains perfectly relevant today. And Electron products are not really enough shit that they so well deserve.
I think this is a great comaprison of the wrong things - i do not believe RAM used is what matters, not if it's under 4 Gb.
I think it's CPU, and VS code consistently takes more CPU to achoeve the same job, and for longer.
> HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing.
Citation needed. Because right now we're running most our Apache TomEE and Tomcat applications in prod on a 64m or 128m heap and handle hundreds of requests or messages per second. And this is on an ancient JDK1.8. On JDK11, we're thinking of running between 16m and 32m heaps.
Yes. So the absolute worst case scenario is one our 128mb heap apps that uses direct memory byte buffers for off-heap object caching. It's resident set size is roughly 387m, which up to 196m of that is byte buffers. I can tell using JPS the heap is full allocated, and the application has been running for several weeks so I imagine the cache is full. That leaves an overhead of 64m.
For funzies, I looked at one our ActiveMQ Message brokers, which are ran on 1g machines with a 640m heap. The heaps are fully allocated and the resident set size is ~658m. Linux reports it has 66M of free memory and 95M of available ram. 440m of swap is being used and is only lightly being paged out under light load of 400 msgs/s. This same setup can push 2000msg/s before GC thrashing becomes an issue and we need more heap.
So no, I don't think there's any truth to the claim "Hotspot always uses an extra 256m of memory". Sounds like the kernel is doing what it's supposed to: free memory is wasted memory.
Slack's bloat may be the developer's fault, but the same could be said about Atom, and Discord, and Evernote, and Skype. And even if you can't say it about VSCode itself, you can certainly say it once you introduce a handful of extensions.
Electron isn't the problem. All of the technologies it is built on are the problem. They require extreme measures to control quality and maintain performance for anything larger than a trivial crud app.
You'll have to post more about the OS and how you measured memory consumption. If you're just looking at something like htop, it can be pretty misleading.
I dread the day Siemens inevitably buys Qt (it will happen) and the license structure changes to $65k/per-seat buy-in to the “base” toolkit which includes QObject and nothing else. Also, a $7k/year per-seat maintenance fee for “base”.
If you want the QtGui module, look north of $100k buy-in.
I'm well aware that VSCode as a tech product is also full of bloat internally, the difference is that this bloat is mostly hidden to the user. What they have going for them is that it's a well designed text editor with sensible defaults in the first place, it "just works" and it's simple, that's also why it's so popular. You can add as much (or as little) as you want on top of it.
The UI is also a lot cleaner. There are only a couple of icons and each of them does something I use regularly. Jetbrains products have 300 icons and I use about 5 of them. Once I worked out I could do everything I use rubymine for in vscode with plugins I stopped paying that license fee.
> VS Code ... is based on a browser engine, so also not really light on resources?
You say that, but IntelliJ is not exactly slouching on resource usage. I see far lower memory usage in VS Code than I do IntelliJ opening the same projects.
I see this critisism of VSCode a lot - but the job of a browser engine is to render text really fast! Rendering text is something you want to do in a text-editor is it not? Why not use the best tool for the job?
You're probably right that something like Sublime Text is faster - but that's a massive undertaking that would take a lot of engineering to get right.
The job of a browser is to render a wide range of UI specifications reliably and support a collection of broken but grandfathered web languages, not to render them quickly. Speed is nice, but it comes after those concerns.
The point of Electron is to allow people to develop UIs quickly, leveraging their experience with the web. Electron is extremely bloated & slow. To some degree it has to be.
If browsers were about speed, they wouldn't interpret Javascript. I'd argue they'd probably force the UI to be specified in a form that explicitly disallows inefficiencies and probably isn't turing complete. I'd argue a domain-specific solution for rendering highlighted code specifically could be a lot faster than a browser, like multiple orders of magnitude. We know that's the case by virtue of the fact we could even do it at all in the 80s.
As someone who used to heavily use intellij and visual studio, and briefly defended them when I transitioned to a shop that was full of vim/emacs hipsters, I throw up in my mouth a little bit every time I recall the times when I was using them.
Funnily enough, I also found myself using Java and .net less and less. I never had much love for Java, but C# was an amazing language that somehow got gobbled up by the Enterprise black hole and it's a huge shame.
This is the central question in my mind too. In a typical work day I might launch a project once. Heck, I might only launch it once a week to be honest.
I spend all day navigating and reasoning about the codebase I'm working in, so I need strong tools that aide me in that. That's where VSCode doesn't hold a candle to Rider IME. So Rider is my daily driver at work.
The responses from some devs leave me wondering what their env/projects/work day actually look like and how does their tooling actually work for them in practice.
It would be incredibly interesting to see the landscape of different work envs and tooling and do a comparison of what happens in each given env when you swap out the tooling.
A typical work day has me working in at least two different projects. Visual Studio/Rider is so heavy that I don't want to keep two instances of it running all the time and it's so slow that switching between projects in a single instance carries a heavy context switching cost. I also have a set of markdown files that I use as a second brain which I like to open periodically to check notes or jot down ideas.
> Do you work on multiple things that don't require coding?
I also write documentation, answer emails, review PRs, occasionally modify art assets, maintain team documents, etc. I don't always want Visual Studio/Rider hogging all of my memory or chewing up the CPU.
> Why does launch-time matter at all?
I hope what I already wrote made it clear but TL;DR I jump between projects, don't want multiple instances consuming all my resources, and (bonus) I frequently need to restart Visual Studio because it can get in to a weird state when working in C#/F# hybrid projects.
Maybe VSCode could show a little traffic light next to each plugin indicating its latency impact.
What IDEs have going for them is that the features are generally constructed by people who know what they are doing and test them at the same time. Whereas a plugin could be written by anyone. Also there's a great "works on my machine" when it comes to performance: the plugin author will just test the plugin on its own rather than with a bunch of other plugins, so their performance target is artificially low.
The number of new non-enterprise projects built on C# is off by a factor of 10-100x compared to Python/Node/Rust. And even in enterprise, it's now dying. .net core is an attempt to rescue it on the cloud but it's too little too late.
No matter how amazing the language is, it has become hard associated with enterprise work and not much else. It didn't need to be that way, that's Microsoft's doing.
> it has become hard associated with enterprise work and not much else
Maybe you are right on that, but why do you consider that a bad thing? Different languages are for different things.
Your statement of non-enterprise projects off by a factor of 10-100x is partly because people jumped on the non-statically typed mess that Python is. Especially with all the AI related stuff.. yeah if you are doing some random little research project and you are a math person but don't want to take the time to do programming "correctly", then sure you can jump into python, use some libraries and get some results. It has it's purpose.
I don't know it's just silly to bulk everything together and pretend you can compare them.
Also saying .net is dying in enterprise is basically laughable.
Languages have evolved. Now developers EXPECT languages to come with a FREE suit of command line tools for linting, static analysis, formatting, package management and what not. FROM there ANY text editor should be able to take advantage of all these command line tools to provide a good developer experience.
The time of bloated IDEs is over. And you're right, I need to be able to run all CI tools the same I do on my development machine and the CI server.
Obviously, WYSIWYG and other graphical builders will always need a specific IDE in order to do RAD, but these are special cases, not the norm anymore.
Nothing prevent jetbrains from selling CLI tools that perform all the tasks in their IDE, especially when many of their IDE do rely on open source CLI tools at first place.
But If I'm developing say an Android app and I'm not the design integrator, I shouldn't have to fire an slow and heavy IDE just to write a bunch of Java classes. I have my maven manifest and it should be all I need to compile a project.
Re: Obviously, WYSIWYG and other graphical builders will always need a specific IDE in order to do RAD, but these are special cases, not the norm anymore.
I don't know why it died, WYSIWYG and GUI-friendly IDE's allowed higher productivity in that "one-man-bands" (small staff) could do the entire project. Now development is often layered into specialists. Things like UI design and ORM's have longer learning curves, which emphasizes specialists. But staff is larger per feature: less productive. (There are many times I wanted to shoot Bootstrap in the head when I couldn't get it to act how I wanted. Something in WYSIWYG that would take 20 seconds becomes a 2 day trial-and-error session in Bootstrap.)
WYSIWYG/GUI-IDE saved money. Most businesses don't run their internal productivity software on mobile anyhow. "Progressive" UI's are a money sink in practice.
The trend predictors got it WRONG: desktops live on in biz. Our anti-state-GUI web standards don't help. Businesses really want cheap rich desktop-like GUI's for productivity software.
I'm not against flow-based layouts, but they should be an option, along with WYSIWYG.
Can I ask where you you see this demand, is it industry specific?
I was under the impression that the benefits (easy deployment to a known runtime aka the browser, open ports (80/443) in the firewall, large developer pool, potentially cross-platform use) outweigh the UI shortcomings and budgets were shifted to web-based productivity software.
The features you list are not necessarily mutually exclusive, but too many think they are, and that's the problem. For some reason people seem to think it's either rich GUI -or- web. With a decent stateful GUI markup standard, we can have the best of both. HTML wasn't meant to be stateful nor for rich interactive GUI's. Faking it with JavaScript has proved a bloated crashy mess.
End users who care about productivity want rich GUI's. Rich GUI's use screen real-estate better than "progressive" web apps and have abilities like right-click, rollover text, etc.; and it's cheaper to develop because they (optionally) can use WYWIWYG for many parts of it. WYWIWYG is just plain cheaper and easier to get right. You don't need "flow layout" specialists who can tame sucky CSS/DOM, which makes alchemy look logical.
Remember that businesses don't really care how software works as long as it does the job and is affordable in creation and maintenance. The bloated web stacks are not. It's too much code to do the same thing UI-fit tools did with less because they were closer to the CRUD/GUI domain itself. Web stacks are too fucking layered such that you spend most of the time managing communication between layers instead of on real biz logic. I stand by this and if you look at the code you should agree.
We DEVOLVED. Current web standards may be fine for social media, but not real work. We let the "cool stuff" pollute real work in cubicle-land. Oh, and git off my lawn! ;-)
I thought you meant native desktop apps, not web apps.
I remember when ExtJS was positioned in the late 2000s to mimik rich desktop UIs and I think there are still lots of component based frameworks to use and pay for, if Bootstrap doesn't cut it. The prices are steep though.
As far as developer productivity, the desktop-oriented IDE's were indeed better. Yes, you had less choice, but that didn't matter much if tried to think like a plumber instead of Picasso. The problem was that deployment and installation was a pain. Microsoft actually improved that for its products, but I believe if we had a stateful GUI markup standard, we could have very similar tools without desktop installs (other than installing a GUI browser).
Oracle Forms kind of worked like this (mostly before Java era), although its GUI control language was proprietary and not XML. Oracle Forms had its warts, but was a good proof concept for the GUI browser. Developers got a lot of work done under it.
In the case of developing a Android application there is nothing keeping you from using the tool of your choice to write the code in, and simply using what ever plugins are available to your editor of choice to run the compile steps, deployment to a device or an emulator etc. After all you only need a single line command to compile a properly configured Android project into a releasable APK.
But when I want to write my code, get correct linting, inline documentation, Java-to-Kotlin conversion of old code, the whole range of interacting with the device I am running my code on, management of my Gradle tasks, VCS integration, Task contexts, remote connections to test databases (and the whole other metric ton of features I wont get into) I will always take Android Studio over what ever flavour of the year text editor.
> Now developers EXPECT languages to come with a FREE suit of command line tools for linting, static analysis, formatting, package management and what not.
The key selling point of Intellij IDEA is they come with semantic refactoring tools, for something like "move this method into its parent class" or "extract the selected methods to a new interface", which is still rarely seen in the wild, and didn't get mentioned at all in your list, but it saves real time.
It saves real time if you write your code the way IntelliJ wants you to write your code.
If you structure things differently - say, by steering clear of subclass inheritance, or keeping interfaces small, or not using the Bean pattern, then you can pretty quickly discover that there aren't all that many IDE refactorings that you actually use.
At this point, most the refactorings and code actions that I'm actually using exist in vscode as well; IntelliJ's main advantage is that I'm (somewhat) more able to use them efficiently without taking my hands off the keyboard.
Extract interface, implement interface, extract method, move(to own file) only exist for go and c# via jet rains and are practical for anyone writing real world code.
Interesting, I'm not a Java dev (mostly C, C++ and Python) but I turned to VSCode exactly because it is more lightweight than Visual Studio. The many little pauses and delays in "Visual Studio proper" drive me nuts, and most of the features in VStudio each only serve a tiny section of users, while making the IDE slow for everyone (and TBH when I tried the various Jetbrains IDEs, they are even worse in terms of laggy UI than VStudio).
VSCode with its flexible plugin system got this right. Even though it isn't a speed wonder itself, it's still better on average than most "heavy weight IDEs" I've seen).
You can configure linters for VS Code and other editors. If it's just "what IntelliJ enables by default" then that's pretty subjective. I've seen some terrible code as a result of developers changing things just because their IDE decided the old code was smelly.
The developers in the team do not change linting rules as they want. But I am not referring at small stuff, recent things for last weeks(maybe VS code does this by default or maybe you need 12 extra extensions that makes things much slower, let me know)
- I go to fix some issue and my IDE shows me that the code is copy-pasted in 3 places so I knew I have to extract a function, do some cleanup and fix all 3 affected places.
- bug appeared other a refactor, checking the code in the IDE I can see a red variable name, it was red because it was undefined(this is in JS code)
- sometimes when using soem inner function I would try to do something like "this.something" but the IDE notices it and warns me that in this scope "this" is soemthing else
I am also impressed that it can most of the time understands frameworks and libraries like angular or jQuery
It is an old project, setting up a strict automated CI would just block us until we fix all warnings or disable them. With a good IDE you can spot the issue int the location you work, you say change most of the "var" to "let" and "const" but you can ignore the ones that are not related with the thing you are working on. With an automated thing you either fix all at once or you have to set ignore rules or write ignore statements int he code.
I would be interested to read more on how to add such a strict CI to an existing project.
I'm sure you could get the linting tool to run only on changed files (we have a pre-commit git hook that does this at work, although we have CI set up to run against the whole codebase). To be honest though, I think the best approach would to pick a few of the rules you consider to be the most important and just be suck it up and spend a couple of days fixing all the errors. It likely wouldn't take you long to make that time back.
Agreed, but for sure having a CI with parts of the rule won't be as good as having that and on top an IDE that has all the rules On and even more you can see the warning as you type not after you committed and submitted a PR.
Well sure, but text editors like VS Code and Sublime can do this too. You usually need to install a plugin but everybody I know who uses these editors installs the relevant plugins for the languages they use.
VS Code is particularly smart in that will pull in TypeScript definitions for libraries and use those for auto-completion even if you are not using TypeScript (and are using plain JavaScript).
This is definitely true. The tradeoff being that JetBrains IDEs are much slower (particularly to startup), much more resource intensive, and of course more expensive.
Startup time is bad, yes, but I think it’s a reasonable trade off for the features I get and plus I tend to launch it once and then open files with the command line tools, which is basically instant. Granted I’m spoiled on my personal machine with a six core i7, 16GB RAM, and an NVMe SSD.
> Granted I’m spoiled on my personal machine with a six core i7, 16GB RAM, and an NVMe SSD.
I think this makes a big difference. I also have 16GB RAM and a fast SSD, but I'm on a 2-core MacBook processor. I find that with all of the various different projects I have to interact with in a day (I'm the tech lead at my company) I can't leave an IntelliJ-based IDE open without it slowing the rest of computer down to the point that it's impacting my productivity.
IntelliJ rocks but you’re seriously underestimating tools like SonarQube and CI pipelines. If you’re working in a crusty old system, you will be blown away by the kinds of things they uncover out of the gate. “Strict” CI is all relative, one option is baselining your project, which adds suppressions everywhere that has errors, allowing you to track new violations and fix the old ones as you go.
I recently spent a day configuring SonarQube rules for Java and I'm not particularly impressed. It does not reveal much more than standard Intellij code analysis.
Also nice advantage of Intellij hints is that most times they also offer auto-fixer so it's very safe to apply the fixes.
If you have relatively modern code with reasonably good practices, sure. I ran it with the default rule set on a 15 year old C# codebase of about 150kloc and it found several quite serious vulnerabilities and a whole boatload of logic errors.
> Setting up eslint or related tools in a CI pipeline would let you catch these in an enforceable, consistent, decoupled way.
…minutes, hours or sometimes even days after the code was written. Not every project can run its CI pipeline in seconds, incrementally, or on the developer’s system.
The advantage of any IDE is the “integrated” part. Linting is one thing, showing the results in a way that makes it as easy as possible to act on them is where an IDE beats a DE that does the linting in a “decoupled way”.
Really? Are CI tools parsing the code and will detect that this.something is not defined here? I am presently surprised so let me know what tool does this.
Most cli tools can be easily integrated with continuous integration platforms like GitHub actions / Travis CI.
See static analysis tools and code quality one's, in php these are Psalm, php-stan, php code sniffer and others.
For JavaScript see ESLint with recommended rules from different companies, typescript with allow js turned on to analyse javascript code and other tools for statically checking css, html and more.
Do you know more? I am assuming the IDE has only one AST and uses custom tools and not running 10 different tools in background but my assumption could be wrong.
> The many little pauses and delays in "Visual Studio proper" drive me nuts, and most of the features in VStudio each only serve a tiny section of users, while making the IDE slow for everyone (and TBH when I tried the various Jetbrains IDEs, they are even worse in terms of laggy UI than VStudio).
I don't know how long ago you tried Rider, but after more than a decade of using Visual Studio I had had enough of the lag, broken features and instability - I moved to Rider, and couldn't be happier. In fact, I'd say it's one of my favourite ever pieces of software. It obviously loads much slower than VS Code, but then in operation if feels snappier and never lags. I've also never once had a release version crash, which for such a complex tool is pretty impressive.
I use it every day, but onyl for it's CMake support, syntax highlighting and 'go to definiton' etc functionality. I don't use it for building though, that's still done on the command line.
I did! Mainly on Linux because QtCreator is one of the very few Linux IDEs where the debugger worked out of the box (now I switched to VSCode too there, mainly because it allows the same development environment across Windows, Linux and Mac).
True, QtCreator performance is fine. But I found the whole toolchain integration (Kits?) and cmake integration a bit weird if I remember right.
Java people always tout their advanced IDEs as a major benefit of working in Java. But the thing is that Java is a language that is unusable without a strong IDE and that is not an advantage.
Unusable? I wrote java with a text editor for three years and got a lot done. I wrote C++ for about 10 years with a text editor (It was called an IDE but it was a text editor with a debugger).
But having a language that enables the functions of an IDE is a big advantage. A good text editor that manipulates characters efficiently is absolutely valid. But an IDE that treats code as an AST gives you a lot. After all when you think of code you think of it in trees/graphs: You go to fix a bug, one of the first things you will probably ask is "what calls this code?". Being able to do that, right up to the top of the call hierarchy, instantly, without having to run the system is a huge advantage.
An IDE gives you the tools to reverse engineer the design (or lack of it) from the code.
> You go to fix a bug, one of the first things you will probably ask is "what calls this code?". Being able to do that, right up to the top of the call hierarchy, instantly, without having to run the system is a huge advantage.
This is indeed useful, and languages with semantic IDE tools are indeed better at it. But this works for me in JavaScript 90% of the time with just text-based (and I think it probably tracks imports) tooling.
One should always strive to use the simplest tool that gets the job done. Java comes with an insane stack by default. Not only must you understand all those parts (the vm and IDE), you must have a strong enough computer to work with it. Java developers always need the beefiest most expensive machines to work.
No, I don’t think this is a supportable assertion. The “simplest tool that gets the job done” is obviously a ridiculous over-simplification, since even Notepad will allow you to write Java apps. The choice between different development tools is down to the specific environment, developer requirements, and preferences.
Also it’s not 2000. A Java IDE will work fine on any computer you can buy.
IDEs can help to learn programming and can facilitate exploration. Step-by-step debugging and refactoring are a crapshoot in less advanced editors, but both are powerful learning aids if they are easy to access - which they are in IDEs. Both IntelliJ and Eclipse are very easy to explore - just point-and-click, no need to set anything up if your language is well supported. Experienced devs also benefit, since IDEs are made to manage and navigate complexity that will inevitably show up in any mature codebase.
Your runtime and tooling will always be a dependency, and you will always have to learn enough to troubleshoot it regardless of the language. PHP, JavaScript, Ruby and Python are no different to Java - the SDK must also be installed and kept upgraded, you still have to fix your application to work with a newer runtime when the language changes or when fixes are backwards-incompatible, and your SDK version might still clash.
Performance is not an issue in practice. I only ever noticed IntelliJ being slow on a machine that was too slow to run a web browser, and I don't think that such machines would be very common because people would just get rid of them. Resource use has ballooned over the past few years due to the rise of Electron, so your machine already needs to be powerful enough to run Discord, Slack, Postman, or whatever other applications you wish to run in parallel. Adding a JVM alongside that is not much of an ask, given that IntelliJ consumes around 500 MB with two fairly sizable projects open.
> One should always strive to use the simplest tool that gets the job done.
why in earth would you think that. we get further as a species because we develop more complex tools to achieve our goals, be they nuclear reactors, smartphones, etc.
Simplest tool that gets the job done does not mean it is simple. There's still the the part that gets the job done, so it still can be essentially complex tool.
Accidental complexity, on the other hand, will only slow you down in the future, or even make you incapable to continue further development.
In a professional sphere, appropriate tools are the best one can afford (i.e. the best that justify their cost).
Simple tools are only appropriate for cheap, low-value projects (e.g. don't set up an IDE and build automation when some trial and error with Maven to compile something occasionally is enough).
It's very naive to assume that just because the general category of the base material is the same, the construction techniques are similar. Even the materials are not actually the same, modern bricks are a lot more complex than basic bricks. I doubt any civilization even 500 years ago, let alone thousands of years ago could have made them. And we make them like this for reasons such as increased durability, better thermal insulation, probably reduced production costs, etc.
For all intents and purposes a modern brick might as well be carbon fiber compared to ancient bricks.
I don't think Java the language is particularly unusable without an IDE compared to eg ad-hoc approaches extending weakly-typed languages with type annotations such as TypeScript and Python (while not 100% relevant, I even refactored maven+ant driven builds into Makefiles calling plain javac *.java as recently as a couple months ago, using vim as code editor).
Java IDEs are so thorough that I learned Java from NetBeans autocomplete rather than any tutorial.
Which is not to say that my understanding of Java extends to working professionally in it; I'm a functional programmer and broadly unfamiliar with modern Java's specific patterns.
Conversely I'd say that a language that doesn't enable an IDE to provide some of the features Java does (first and foremost: call graphs) is unusable, period.
Java developers seem to habitually use metaprogramming facilities that make it impossible to determine what code is calling what other code by hand, let alone using single command in an IDE. When not doing this, they are usually creating interfaces with a dozen implementations that wrap and delegate to one another. So I would very much like to know what calls what, and this is a reason I cannot use Java.
> Java developers seem to habitually use metaprogramming facilities make it impossible to determine what code is calling what other code by hand
I assume you mean reflection - this would be very untypical for normal business logic code and would get smashed very quickly in any code review. It's also far from nice and easy code. You can program "dynamically" in Java, but it gets ugly quickly which in itself discourages you from doing that habitually.
Reflection is used mostly in frameworks only.
> When not doing this, they are usually creating interfaces with a dozen implementations that wrap and delegate to one another.
Sure, Java devs have so much time that they don't implement the business logic once, they create dozen different implementations just for the fun of it. Again, this situation (one interface, many implementations) happens mostly in frameworks and rarely in business code.
If you want to hate on Java, use some real arguments ...
> I assume you mean reflection - this would be very untypical for normal business logic code
No, a lot of java critics complain about it being hard to tell what's calling what at the framework-to-user-code boundary
That means not only reflection, but also most Dependency Injection (Spring autowiring, Guice...), anything that runs on annotations (including @Test and JAX-RS), any code auto-generation (e.g. Protobufs, Jooq), most mock libraries (e.g. Mockito) and most configurable logging, especially the logging libraries that try to auto-detect one another.
Of course, some would say those problem are with Corporate Java Culture choosing to use all those things, rather than the Java language itself.
The loosely coupled metaprogramming of frameworks like Spring is an indication of how feature-poor Java is in those areas. Autowiring and mocking should be first-class features with dedicated syntactic elements, rather than something that's handled by third parties with opaque annotations that mean nothing before the application is run.
I understand that Java wants to remain conservative with its development roadmap, but the fact that the majority of an ecosystem uses a third-party framework is a good reason incorporate something similar into the language.
> No, a lot of java critics complain about it being hard to tell what's calling what at the framework-to-user-code boundary
That's rather an industry criticism since these problems exist everywhere and are often direct consequence of trade off for looser coupling.
There are also often alternatives - e.g. Dagger for DI and MapStruct for mapping which go the code generation path which allow you to statically inspect the whole code path, you can also always trade the looser coupling for more directed paths e.g. for logging by avoiding the wrapper and using a logging library directly.
> That's rather an industry criticism since these problems exist everywhere and are often direct consequence of trade off for looser coupling.
No they don't. Java is just not expressive enough, so library/framework authors have to decide between bloat or magic and they often choose magic for better or worse. There are languages that doing better in this regards.
As we are talking about Java, the closest language would be Scala. The language is much more flexible and powerful. This brings different problems onto the table, but it resolves the issue with awkward framework annotation/wiring problems that I have experienced in Java way to often.
> Of course, some would say those problem are with Corporate Java Culture choosing to use all those things, rather than the Java language itself.
I'm not sure this is necessarily a culture, either. Java tends to be picked more for applications with more demanding/richer requirements, and so they need to do a lot. This demand for features drives a demand for richer frameworks. You see this exact thing happening with JS on the client. So to the extent this is a problem, perhaps it is a general software design problem.
The main metaprogramming facility in Java is annotations. Some annotations work like higher-order functions, except that my advanced Java IDE is unable to find what function is wrapping the annotated function. Some other annotations work more like macros, but there's not a convenient way to evaluate the macro to have a look at the code it would generate.
I previously asked in another forum about this sort of thing and heard that I should read the docs. I suppose when working at a big company ships internal libraries that expose annotations and use inheritance extensively, but do not have docs, I should just pretend that I am not actually in such a situation, or something.
> Some annotations work like higher-order functions, except that my advanced Java IDE is unable to find what function is wrapping the annotated function.
Intellij can show you which aspects have been applied for e.g. AspectJ or Spring AOP.
I mean if you or your company really insist on writing your own metaprogramming library then yes, IDE can't do much to help you, but that hardly represents industry practice.
It's funny, because I always complain about interfaces with just one implementation, I've never complained about an interface with dozens of implementations :)
This is a real world problem, and I say that as someone who has been doing Java and Scala for many years. When you are exploring code trying to figure out how it works and what it does, it's easy to follow the chain of what method is this, where is it implemented, where is this symbol imported from, etc. Subclassing introduces some ambiguity in method parameter types, but at least you can get some information from the documentation of the interface or abstract class, and you can find usages of the method and see what concrete types are passed in different places. Where it really breaks down is dependency injection and annotations. When you hit these, it's no longer "command-click" or "google for Javadoc" to find out what's going on; it's a minor research project. With annotations, if you can't find the information you need in the documentation, you will have to search the source code of the framework and study the code that processes the annotation before you can even locate the code you're looking for[0].
You might be thinking this is pretty awful, but hey, software is complicated, you have to understand the code you're working on —- fine. It's reasonable to put this amount of effort into the code you are actually working on. But when you're working on service A and have a question about service B, it's nice to be able to pop over to service B's source code and find the answer without investing a lot of time understanding the technologies underlying it.
This is why "enterprise" Java programmers end up obsessed with anointing "best practice" frameworks. Me relying on a big magical framework for everything I do is only problematic because some other people don't use it. Solution: let's establish my framework as the "de facto standard," and then nobody can complain that it's ridiculous overkill for simple applications. Let's make proficiency with my preferred framework part of the definition of being a professional Java developer, and then nobody can complain about how time-consuming it is to get up to speed with it.
The alternative is to use libraries instead of frameworks, use as little magic as possible, and work in a language that is powerful enough that you can write straightforward code and still say everything you need to say in a reasonable amount of space.
Consider the simple, ubiquitous case of writing a method to implement a POST endpoint in a database-backed CRUD web service. Suppose you need to authorize the request according to some business logic, deserialize the entity body, validate the body according to some business rules, get a database connection, construct a query, run the query, process the query results into a response object, set the status code and headers for the HTTP response, and serialize the response body. Why shouldn't all of this functionality be discoverable in the code via chains of method calls from the method that implements the endpoint? With a concise language and a well-organized codebase, this is entirely possible. Readers of your code can see: here's where to dig in if I want to see how the request is deserialized, here's where to dig in if I want to see how the database query is constructed. If your code becomes exhaustingly verbose when you express it in this straightforward way, then your language is failing you.
As a fan of Scala, I have to admit that Scala introduces a similar difficulty with implicits (and the horrible practice of using wildcard imports to import entire menageries of implicit methods and values, which is epidemic in FP-style Scala.) Implicits are indisputably widely abused, but at least IDEs can show you how implicits are resolved at compile time, and in your own code, you can make implicits reasonably readable without IDE support by declaring them in an enclosing scope with a good name.
[0] I'll make an exception for one style of annotation: annotations that point you directly to the relevant code, like @ExceptionMapper(MyExceptionMapper.class). This is almost always all the information I need, the only exception being if the person who wrote MyExceptionMapper misunderstood some subtlety in how it gets wired in via ExceptionMapper.
A lot of problems with modern programming can be traced to the "pipe compiler" like model, where your development environment is nothing more than a file editor with a shortcut to run the compiler. It doesn't understand the code, and it can't really help you, and the compiler only really outputs errors.
Java is perfectly usable without an IDE. Just like any other language is usable without one.
The question is: why? Why would you not use an IDE? Looking at refactoring capabilities alone you'd want those for any language [1] And on the fly actionable code analysis [2]? Why would you not want that for a programming language?
I guess it is partly the design of the application: Enterprise Java apps often contain lots and lots of classes and have deep inheritance trees. So if you have a piece of code that says "foo.save(a, b);", then which of the 132 different "save" methods that your codebase contains is being called here?
And because Java is statically typed, this enables you to do things like changing the name of the "save" method in 83 of the different 132 instance, namely the method from class "Widget" and all its subclasses. And, of course, update the right callers.
If you are doing Python or JavaScript, you often don't have much of a clue what the type of "foo" is in that "foo.save(a, b);" call, and so you don't know which of the "save" methods are being called. And you know that when creating your app, so you stay clear of class hierarchies that require this IDE functionality to untangle :-)
> I guess it is partly the design of the application: Enterprise Java apps often contain lots and lots of classes and have deep inheritance trees. So if you have a piece of code that says "foo.save(a, b);", then which of the 132 different "save" methods that your codebase contains is being called here?
Deep inheritance trees came out of fashion (everywhere, not just in Java) long time ago. Inexperienced developers can misuse inheritance in Python just like in Java.
> And because Java is statically typed, this enables you to do things like changing the name of the "save" method in 83 of the different 132 instance, namely the method from class "Widget" and all its subclasses. And, of course, update the right callers.
As opposed to Python or JS where "we don't know for sure so it's gonna be safer to not refactor".
> And you know that when creating your app, so you stay clear of class hierarchies that require this IDE functionality to untangle :-)
Inheritance in JS is not widely used since even the concept of classes is still very new and technically not safe for use (not supported in IE), not because JS devs are somehow wiser and self-limiting themselves to one level inheritance.
(unless you mean prototype based inheritance which is very different beast)
> unless you mean prototype based inheritance which is very different beast
All inheritance in JS is prototype based inheritance. The class syntax is just syntax sugar prototypes. In theory you can do all sorts of crazy things with prototypes. In practice people use them just like classes. The reason people don't use inheritance in JS has nothing to do with browser support.
> All inheritance in JS is prototype based inheritance. The class syntax is just syntax sugar prototypes.
And async/await is promise based yet it results in quite different programming style. It doesn't matter which primitives are used for feature implementation.
> The reason people don't use inheritance in JS has nothing to do with browser support.
I don't think so. Since the advent of ES6/Babel/TypeScript I see inheritance on frontend daily.
I do a lot of work with Emacs and it's my preferred text editor. I think of myself as productive with it and I do a lot within Emacs; for instance using Magit to work with Git. Typically I'm working with Python or Clojure.
That said, when I need to work on a Java or C# project I put Emacs aside and reach for my preferred IDE. There is overlap between a text editor and an IDE; certainly I can _make_ a text editor do _most_ of what I get from an IDE but is it really worth the effort?
In my opinion, IntelliJ is on point here in some cases; I suspect developers coming from a background in front-end or a language like Python or Ruby are very comfortable with their text editor and tend to use these same tools for work with Java or C#. In this case it is likely that they are to some degree unaware of the benefits of a more integrated IDE.
In terms of CI integration, in my experience this has never been a problem (I have never really used Eclipse). My Java IDE uses the Maven configuration to manage the project and the CI process calls Maven from the command line. In the C# environment, the command line tools works in a similar way.
This is the place I'm in too. In projects more under my own control, I use Emacs for JS and Clojure.
At work, I deal with JS, Python, and Java. I don't really care to spend the effort to configure Emacs to handle all the oddities of a super old codebase reliably. I just grab vscode or intellij. They're fine.
I am the same way. I use emacs for git, org notes, small adhoc scripts, but for actual project work – IDE, hand down. I have converted a long time emacs user to try PyCharm once. He was skeptical for a long time, then he switched.
Indeed. I hate it when my code runs in an IDE and not from command line, or vice versa. Maven, custom JAVA_HOME and JVM arguments, conda environments, ... are a pain to integrate across different environments, especially since every IDE does its own thing.
Pretty easy to use and IDE to dev stuff and just run it on the command line. I used to do that all the time. You aren't forced to actually run the software through the IDE.
Depends. IDE is usually just invoking the build tool chain. That usually can be invoked from CLI too. Like for Java the gradle or maven stuff or .NET the MSBuild stuff.
I sort of mix and match depending on what works best for a given project.
While they're very obviously in the "competition-induced" panic, there is still a point.
The disconnected VSC model - main company in charge of the editor, and third parties in charge of certain language plugin[s] - puts some languages' support at risk of being insufficiently developed.
I "only really want advanced editing + syntax highlighting + language server", and use VSC, but, while its support for "statically typed languge #1" is ok, the support for "dynamic language #2" is atrocious, to the point of being unusable (poor "go to definition", editor aggressively misaligning lines of code, etc.). I'm not sure it will ever reach sufficient support.
On an IDE, this doesn't happen, because the developing company must, within a certain qualititative extent, take care of all the functionalities.
I'm not sure what your definition of an IDE is, but the notion of a core platform with language-specific extensions on top long predates VSCode. Visual Studio proper works in exactly the same way, for one; and then there's Eclipse, NetBeans etc. If anything, this has been the conventional way to do IDEs since early 00s or so.
With Code they’re running out of process and communicating via IPC/RPC most of the time which introduces instability that I’ve never experienced in Visual Studio, Rider, or IntelliJ
There are many things in Visual Studio that run out-of-process, and coordinate via IPC. It's an implementation detail, and does not change the fundamental approach.
Also, many things in VSCode can be done in-proc as well if one so desires, including debuggers and language servers. Most extensions do them out-of-proc because it gives them more flexibility (esp. wrt implementation language for those components), and because it's easier to test such isolated components.
>IME a lot of developers don't like their IDE heavily coupled to backend servers and environments, but actually prefer the "code editor + useful features" approach
Personally, I use VSCode for generic text editing, scripting, taking markdown notes, general purpose review/browsing repos (e.g., opening up a project to review a couple of python classes), etc. It's nice for switching between a variety of languages and use cases. I like the integrated terminal, the directory search feature (so much less clunky than the equivalent Mac Jetbrains IDEs' features), the multiselect text editing experience, the ease of configuration, and the general responsiveness.
But if I need to do a deep dive on a language, I generally switch to a fully featured IDE. For example, if I need to refactor 10000 lines of C#, I'm definitely going to switch to Rider or VS with Resharper where the built-in refactoring, debugging, and static analysis tools are so much more powerful.
So really I see them as different tools for different use cases. VS Code is nice for my fluffier, tech lead work, where I tend to bounce around between fifty disparate tasks in fifty different contexts. Rider, Pycharm, CLion, etc. are more useful for me when I have to fall back into doing deep dive technical work personally.
This is pretty much exactly how I use VS Code and Rider too. I find VS Code great as a general text editor with syntax highlighting, and for searching files, writing markdown etc. But for real work, I want a real IDE (Rider) with a debugger, refactoring utils, cloud tooling, database tooling etc.
Seriously? They should have a look into what VS Code (and friends) can actually do! Once you outsource your refactoring machinery into something like TypeScript or Roslyn (C# Compiler) you suddenly have these features available everywhere.
And in that regards, the should also just look what their Resharper Product is doing in Visual Studio and JetBrains Rider.
I think the only lack in editors is visualizations. I think that will be soon a theme in VS Code ;)
I’m a big user of C# and no, despite the language and the editor being developed by Microsoft, the IDE support in VSCode is poor to say the least. For one it doesn’t even support solutions with multiple projects which requires to open another instance of the editor for debugging. Then there is the constant red highlighting that appears in valid files. Then the installation of Ionide tools in C# project... the list goes on, with extensions not working properly yet being required for basic things like XML formatting, the annoying default settings that require Googling because of their naming, the poor performance because it’s an Electron app, etc.
VSCode, when it works, gives one a glimpse of what you be a good IDE (Visual Studio proper, JB Rider), yet is light-years away of being one.
Well it is still developed. It will get better over the years to come.
I was addressing the c# refactoring s. They were delivered with roslyn to VS and exposed to VS Code via OmniSharp. The gap of C# refactoring in the VS 2008/2010 era is due to the Roslyn project blocking all other efforts. So C# refactoring are only realized via Roslyn Analyzers and with that available to VS Code.
And VS Code is executing them nicely. There is no gap.
A transcript of a talk by Charles Petzold that I think is relevant to the conversation in the replies to this comment: "Does Visual Studio Rot the Mind? Ruminations on the Psychology and Aesthetics of Coding"[1].
It is not heavily coupled to backend servers and environments. Disable all plugins and it'll be pure Java IDE. That's what I'm doing: I'm very careful about Idea plugins. For example I don't use any Spring plugins even when I'm developing Spring projects. Spring without XML is just Java code and I don't need anything else to be productive.
The Delphi, C++ Builder, Forms/WPF/UWP, Swing/JavaFX soul in me begs to differ.
In fact that is the biggest pain in Web projects to this day and I can hardly wait for stuff like Uno and Blazor to bring "Flash" back, if Web Components don't do it first.
After reading your comment I've spent a good 10 minutes trying to find out what are RAD tools (seems to stand for Rapid Application Development tools).
Still no idea. Seems to be a synonym of IDE, but not really?
Think Visual Basic, Lazarus, Delphi, C++ Builder, etc. RAD IDE is essentially an IDE which has deep knowledge about the language and allows for visual design of the GUI - among others.
For example in Lazarus, Delphi and C++ Builder when you edit components in the visual editors (be it the form editor for making a GUI or a data module editor for non-visual components - e.g. editing the routing for HTTP requests in an fcl-web application) you are actually editing live objects which are serialized as part of your application when you save the project (contrast this to something like Qt Designer, Gtk's GLADE or wxFormBuilder for wxWidgets, which only create stand-in controls that pretend to be what you are designing). The IDE exposes the properties and events of those components by using their RTTI information of the object instances directly (instead of hardcoded knowledge of using some configuration file) and it has full knowledge of the source code you are editing so that it can automatically create event handlers, functions, variable declarations, etc for you (no need for special comments or whatever) as you edit the components and the code (this isn't just for component editing btw, in Lazarus you can do something like start writing a `for I:=0 to 100 do` loop, then move the cursor to the `I:=` part, press a key and have the IDE deduce the type and declare the `I` variable if it is missing).
One way to think of it is like if you are making a game in Unreal or Unity where you also work with live objects, but instead of those objects being levels, pick up items and monsters, they are forms, modules and buttons for your application.
This is why it's worth contributing to your language's LSP server[0] and why I encourage every Kotlin dev I see to contribute to Kotlin's[1].
I personally find IDEs are way too complex and cluttered for my personal tastes. To boot, a code editor allows for unified workflows across a broad swathe of languages in ways that IDEs simply can't replicate. It's a pity Jetbrains has long held a dismissive attitude[2] toward developers that don't want a full blown IDE, but that's what you get when there are financial incentives attached.
>you really get a lot out of a good tool that has integration with the application server
I like the really powerful code completion and refactoring tools a good IDE brings to the table but this one strikes me as extremely odd. In 2020, I would want all IDEs to remove this kind of functionality because I don't want to deploy from my IDE ever and I don't want teams that work with/for me to ever use it either. I want to push my git commit and have everything building in my CI/CD pipeline.
I share the sentiment with IntelliJ and I'll never understand the crackheads who use VSCode/Sublime/Atom for strongly-typed languages instead of a proper IDE like Netbeans/IntelliJ/VS.
It's absolute pain to write Rust/Java/C++ in any of those. No safe refactorings (moving classes? good luck), completely random code completion, 0 awares of available libs/SDKs, and so on.
It would seem that most of the developers have no clue what's the difference between a lightweight editor and a full-featured IDE. I think it's just Dunning–Kruger effect on a scale.
I understand that I'll be voted down into oblivion but it really rubs me the wrong way when people confuse some kind of server/application server (???) integrations with an IDE that can offer sophisticated refactorings, a proper type inference, and can infer which functions from which lib/SDK I am using.
Completely agree. Sure, any editor can be paired with static analysis tools to make sure I probably didn't break things, but only a full IDE can just handle the refactor for me so that I don't have to spend time searching, fixing, and checking to begin with.
No, I don't need or use all the IDE features. I don't use the integrated shell, I don't use the git integration, I don't have it handle my packages. I don't see a need for these things when I always have multiple terminals open anyways, but proper code intelligence is not something an editor+plugins can provide like a real IDE can.
Sounds like you're unaware of LSP (Language Server Protocol). "Proper code intelligence" is absolutely something that an editor+plugins can provide, and LSP means that intelligence can be developed once and used with many editors, rather than "integrating" the editor with the code analysis so your choice of one dictates your choice of the other. LSP is just one of those things that makes sense, turning something quadratic into something linear.
I don't care at all if someone prefers IntelliJ over Emacs (that's a pure matter of taste) but the idea that it's impossible for an editing environment that isn't delivered as a single, integrated monolith to expose powerful language-specific tools such as interactive lints, large scale refactorings, debuggers (check out DAP for the debugging equivalent of LSP), etc was never true as a technical matter and is increasingly untrue in the real world.
One of the best developments in dev tooling in recent years is that it is starting to be seen as the norm for new languages to provide canonical language server implementations. Long may that trend continue.
Language server protocols are just re-inventing IDEs, but instead of using shared memory and interacting with the compiler directly you have to use an inefficient JSON pipeline.
No, the choice of a client/server model was a design decision, one that is not unique to LSP and is also used by some IDEs for various reasons (see, for example, JetBrains Rider). Performance is absolutely fine - the only data that needs to be transferred is that needed to drive the UI, which is trivial over a local socket. Had that not been the case, there are plenty of ways LSP could have been designed as an in-proc library interface and remained just as open as it is.
What makes LSP not 'integrated' in the sense of the I in IDE is the fact that it is decoupled from the editor, allowing one editor to work with many language servers and one language server to work with many editors.
> No safe refactorings (moving classes? good luck), completely random code completion, 0 awares of available libs/SDKs, and so on.
Seems like you haven't used VSCode in a long time. It is my primary everyday editor for Typescript, and it has all of those things you listed: I can move a class to a separate file in one click, code completion always follows type system, it is aware of all packages that I have in package.json and offers to import them, and so on.
The IDE/editor distinction really doesn't have as much meaning as it once did.
Try to use it for python or c++ and you will see the problem. I switched to clion as I work in node, python and c++. vscode python support is bellow average and c++ support is bad. clion works great for all those environments.
My biggest problem with vscode is lack of UI configuration. You can have only one panel which is huge waste on big screen. Some useful features compete for screen space (outline vs. project explorer, project explorer vs. debug window etc.). This makes me way less productive than using heavyweight configurable IDE.
I use VS Code on a daily basis. It's my go-to tool for config-based projects (Kubernetes), simple and quick HTML/CSS editing, and the likes.
I've tried it for more serious development for Rust, Python, and TypeScript. While for Typescript the inference is barely acceptable it complete sucks for Rust/Python.
I use vscode daily and recommended it, but to be fair, it's heavily optimized for typescript. The feature may be not available for other language such as java.
This is true, but it demonstrates that VSCode extension model supports this, and nothing stops extension developers from attaining the same level in any other language. Hence my point about IDE/editor distinction.
Sure, why would it not be possible. Intellij and Eclipse also implement all their language support in plugins so why wouldn't VSCode.
But the thing is this is all hypothetical - it is possible if somebody invests those thousands of hours into it. But so far it did not happen for most languages and Intellij IDEs are still vastly superior to VSCode for e.g. Java, Python or C++ development.
Referring to them as "the crackheads" might be a barrier gaining understanding of their choice of tools. :-D
My guess is that was intended as hyperbole, like saying you think they are "crazy" for doing so. Still, I'm thinking you'd be more likely to get interesting feedback by stepping it down a bit.
>I think it's just Dunning–Kruger effect on a scale.
I find it incredibly pompous that you believe that people who have been writing C++/C even Java for decades in editors like Emacs, Vim or even Sublime don't know what they are doing. The IDE vs Editor argument is nearly as old as Emacs vs Vim.
I've seen people who have been on vi/emacs for decades. They truly have zero idea of what an IDE can do.
As a personal anecdote, I've seen people switch from vi to IDEA after a pair programming session. In that session they learned that IDEA has full understanding of the frameworks, configurations, code annotations and bindings etc. that we used in a project, and that you don't need to spend 15 minutes furiously searching in files for stuff when you have to change something in two or more places.
This is a pretty weird take. I've always used two tools - one full featured IDE for whatever project I'm working on, and a more lightweight plugin enabled text editor for SQL, writing notes, markdown etc etc. VS Code has become my goto for the latter, but I can absolutely see myself using it as the main editor for a project. About the only IDE I really can't tear myself away from is IntelliJ for Java - everything else is just ok.
I can use the tool I’m already familiar with, that also supports other languages, that has a huge number of extensions and configuration settings, etc. I personally see this as more important than an IDE, that’s why I for example use VSCode instead of Visual Studio (on windows).
> IME a lot of developers don't like their IDE heavily coupled to backend servers and environments
I think the issue is more how snappy/bloated they are. I don't mind all the integrated features, but IntelliJ has gotten slower and slower over the years, and its starting to get annoying, especially on anemic laptops.
I personally saw no value in intellij compared to what vscode offers.
VScode has won both the intellij Vs eclipse AND vi Vs Emacs holy wars for me. Nothing else matters anymore (unless you need to SSH directly into a box and make edits there of course, for which we have vi) - it really is an amazing editor in my view.
I can't see the need for an IDE like intellij at all when you have an "editor" as capable as vscode.
100%, I'd much rather use the command line if I need to work with Docker, or a database, or the cloud. IDE integrations for these things are limited and have just never worked with real-world projects. I slept on debuggers for too long though; Java debuggers are brilliant.
I still use Netbeans for Java. It's simply the best.
I use VSCode instead of IntelliJ products because it's lighter-weight and I don't have to learn about or fuss with settings. What am I missing out on? Can anyone give me a good blog or video? Not knowing what I'm missing, I'm willing to invest about two hours.
The author clearly should have gone into the specific use-cases he was talking about. An IDE _is_ nothing more than a text editor with advanced features. There's a huge continuum from a basic text-editor like notepad to a full fledged IDE.
I'd particularly like to see a use-case laid out where something like VSCode + Extensions wasn't actually enough. I've been using IntelliJ nearly every day for the past 4 years and I still don't understand how it is any different from a text editor + extensions. IntelliJ is even architected similarly with so many different "plugins" adding full fledged language support for other langages. Goland, Pycharm, etc, are basically extensions for the intellij text editor.
VSCode is 100% free. IntelliJ has a free and enterprise license. I could download the free one, but I feel like I'm missing out on features and would rather go with the option that has everything free. Then I don't have to worry about it. Even though it may not be as good.
The last time I used a Java IDE was in university in 2012, and I've never really touched it since.
I've been recently using VSCode with TypeScript (and Prettier/ESLint). TS is pretty neatly integrated with VSCode, and I've been wondering how similar the VSCode + TS combo is to writing Java on an IDE like IntelliJ?
>VSCode is growing which is concerning, not from a competitive point of view but actually from the point of view that there is clearly a lack of understanding of what an IDE gives you. VSCode is a code editor with some features that you’d find in an IDE, and extensions that can provide additional functionality – so if people are turning to VSCode for developing it may imply that developers don’t know what a fully-featured IDE can give them.
I've found that VSCode can trivially be expanded to be more fully-featured than any IDE I've used -- includiding Eclipse, Idea and XCode.
It's not even the difficult kind of trying to make Vim or ST or even Emacs an "IDE-like" editor with a mismatch of third party plugins of varying quality and integration.
VSC has a few first-class, officially-supported (e.g. MS) plugins that immediately give you nearly all IDE superpowers (inline debugging, intellisense, build environments, git, remote development, testing, etc) with very tight integration.
In fact VSC is so well designed for extensibility / plugin integration, that even third party plugins feel native and integrated to the UI/experience. Despite it's origins as the Monaco editor or Visual Studio's "little cousin", it's more of a "a la cart IDE" today than a text editor + some plugins.
I use Visual Studio for C# (haven't tried Rider yet) for the reasons you mentioned. However, I feel that VSCode more than capable as a platform. The intersection of tooling for C# and VSCode is really lacking compared to TypeScript.
The Java auto-completion plugin-ins for Emacs mostly call out to Eclipse in the background through Eclim. IMHO, you kind of are using an IDE at that point. :-P
I did not know about this project! Thank you for mentioning it, I think I will check it out.
I had weird issues with Eclim that kind of came and went and that was a big part of my dropping it. If this is more reliable I can see situations where I might prefer to try and edit my Java code in Emacs.
fully-featured IDE only works well for languages that support these features, like Java and C#. In C++, I don't have reliable refactoring, I can't "extract a method to free function" with few clicks, so why not just use VSCode.
Blaming the customer isn't a great strategy. They should do customer research to understand these users and decide if they are a niche they should target or can safely ignore.
I think it helps that Erich Gamma worked on Eclipse before. Lessons Learnt I would call that. Also, treating VS Code as a Code Editor is naive from JetBrains. Visual Studio (the big one) is a technology dead end. It has a dozen tech stacks in it (COM, .NET, C++, ...) and faces challenges (macOS, Linux, Web, lightweightness, ...) that it can never overcome without a rewrite of most of it. Surprise: VS Code.
I mean that is my theory ... and I think a lot of people share that theory.
Yeah, but nobody, statistically speaking of course, cares for those today :-)
For most devs, and especially HN-mingling devs, it's either system work, embedded work, ML/AI/Data Science, backend work, html/js frontend, or Electron -- and as for native apps, most focus on iOS or Android (rather than desktop native).
Somehow RAD native apps became the forgotten stepchild.
> so if people are turning to VSCode for developing it may imply that developers don’t know what a fully-featured IDE can give them.
I think the author doesn't know what VSCode can deliver.
> In the web space it is understandable to use an editor as web developers are typically working with dynamic languages
So? Most popular dynamic languages have optional static typecheckers, and the VSCode ecosystem has extensions that leverage these to provide many features common in IDEs for statically typed languages. Of course, the VSCode ecosystem also does this for already-statically typed languages.
> But in Java, especially professional Java, you really get a lot out of a good tool that has integration with the application server and you can really use the analysis and refactoring and everything.
“Analysis and refactoring and everything” isn't something VSCode overlooked developers interest in, and application server integrations are also part of the VSCode ecosystem.
IntelliJ definitely wins for large-scale refactors... but for everything else it feels sluggish next to VSCode in my experience.
For projects built in a microservices architecture, these massive refactors are becoming less and less common from what I'm seeing. Usually if you want to change a method/class/library used by multiple different modules, it'll be a breaking change and most likely better handled by depending on a semver-versioned import anyway.
> “Analysis and refactoring and everything” isn't something VSCode overlooked developers interest in, and application server integrations are also part of the VSCode ecosystem.
I have yet to see vscode perform one third of the refactoring options provided by e.g. qtcreator for c++
The Java/ Kotlin editing experience on VS Code is pretty bare-bones. Unacceptably bare bones IMHO. But each tot their own.
Although, I'd be probably be pretty harsh reviewing any PRs where because of the lousy tooling the code is full of unaddressed warnings, misorganized imports, or where the author can't be bothered to refactor because they lack the tools.
The reality is that on most projects you can use whatever you want as long as it does the job, properly. VS Code is mostly not very practical on such projects for Java projects because standards tend to be pretty high because of the tooling.
VS Code is still valid of course for those who only occasionally need to do any changes. I tend to use it for things like javascript/typescript and rust or other things I use less frequently. I switched to pycharm for python though because it seems marginally better at supporting that.
Honestly I think you're misleading and haven't actually used the tool.
The Java experience in VSCode is quite acceptable, it is the Eclipse language server after all. The warnings and inspections are on par with intellij most of the time, but your devs should be using sonarlint/cube which provide far superior inspections on either platform.
As for organized imports in my experience Intellij just organizes them into one giant list alphabetically while the language server does the same except it's organized by JDK imports, javax.* imports, third party imports, and finally in project imports.
If the Eclipse language server is anything like using Eclipse, I would not call it acceptable. The difference between Intellij and Eclipse is night and day in so many areas.
At least for JavaScript, it seems like it still doesn't support Inline Variable. I can Extract Variable, but not Inline. Of course, that's a different matter than whether it's supported for Java. Last time I tried using the Java extensions for a non-trivial Spring Boot project, it was intolerably slow. I managed to convince a coworker to switch to IntelliJ after he saw the difference between my setup with IntelliJ and his with VS Code.
I see that JetBrains is again pretending that Taiwan doesn't exist in the analytics of its survey results. In prior year's survey you can still get at this demographic data in the raw results that they released, we'll see if it's the same for this year.
> It's not Jetbrains' responsibility to resolve these geopolitical tensions
It's everyone's responsibility to stand up against tyranny, for ethics. Saying it's not your problem because you'd lose money if you did the ethical thing doesn't absolve you- it makes you just as bad.
I'm reminded of the small and rather racist town I grew up in. I heard someone say once "I have no problem with <race>, but I couldn't possibly hire one of them because too many of my customers would get upset". They weren't racist, but they'd cater to racists because it was financially better for them. Oh, I'll do the right thing, unless it costs me a penny.
I have learned the hard way that large corporations will not think like this.
Lots of them will stand up for LGBTQ+ rights, because it's a relatively easy thing to do. They will even put up posters in their offices or make press releases supporting this cause or that.
But stand up for Hong Kong where so many people are being brutalized or repressed every day and your biggest customer is out. Look at the contrast with Blizzard's acquiescence. It's stark.
The companies only really do this in situations where the incentives line up - low risk, high financial/PR return. I hate being cynical when it comes to "changing the world" style arguments, but the fact is that companies are only going to make them when it's convenient, and nobody is going to confront China because they simply have too much power.
It would be better if the media or another powerful enough entity would really against companies being ethically shot for these transgressions, but it seems like they have more or less forgotten about Blizzard and the like by now.
As long as the charter for corporations is profit, then yes, this is the definition of what they want. And don't blame companies for this, blame governments for not incentivizing the right things.
> Oh, I'll do the right thing, unless it costs me a penny.
There are so very few people that fit that criteria of doing the right thing even if it costs them.
As an example: its the reason we kid ourselves into thinking we care about global warming while driving cars into supermarkets for shopping. Sure, we'll protest but that costs us just an afternoon and acts as guilt-offset as opposed to giving up habits that bring us great convenience but do significant environmental damage like supermarkets and cars.
So its the same here, there is barely _anyone_ who would give up something _real_ for Taiwan so IMO its a bit harsh to expect Jetbrains to give up something when we ourselves probably have very little to lose.
Now if we were speaking from a position of a company that did have something to lose, _that_ would be something.
>There are so very few people that fit that criteria of doing the right thing even if it costs them.
The world would be a much better place if there were many more people like this. Trying to get people to meet that standard is not a bad effort to exert.
Yes but it has to started by someone who is willing to sacrifice something to obtain it. If its only people who have nothing to lose that are supporting it then its hollow and nobody will shift. Its by having positive examples that we can inspire more intransigent types to come with.
What's the actual lever that including Taiwan in the Jetbrain's survey result will actually pull? In smaller examples like yours there's actually the chance to move but China's strong enough to face down actual geopolitical pressure what in the world does a tiny IDE company stand to do?
> On top of this, Oracle introduced bi-yearly releases, and so not all releases are supported for a long time so Java 9, Java 10, Java 12, and Java 13 are only supported for 6 months, which is probably why they all have such a very small number of users.
Java feature releases have always been supported for 6 months. 7u4, the feature release that introduced G1, was supported for 6 months; 7u6, the feature release that introduced JavaFX and support for Linux on Arm was supported for 6 months; 7u40, the feature release that introduced Java Flight Recorder and Mission Control was supported for 6 months; 8u40, that introduced AppCDS and support for Mac OS was supported for 6 months. What seemed to be supported for more than six months were the major releases that these big feature releases were considered to "support" (which, back then, were called "limited updates" to the major release). What's changed is that major releases are gone. If you want to think about it using old terminology, all feature releases are now part of the "support" for the last major release -- 9 -- which is supported for all eternity or as long as Java lasts, whichever comes first.
The fact that after major releases were abolished, the feature releases were given new names has certainly had a big psychological effect, but I think the main issue is that many companies are severely overestimating the cost of the one last major upgrade past 8, and severely underestimating the monetary gains in hardware/hosting due to the lower footprint and higher performance of new versions.
Your vision of the Java version numbers seems different from the way all developers I know see the Java version numbers.
It doesn't matter that minor releases within Java 7 or Java 8 introduced new features. What matters is compatibility. If your code ran on a given Java 7 release, it would work unchanged on all later Java 7 releases; the same for Java 8. The same pattern still applies for later Java versions; if your code ran on a given Java 9 release, it should work unchanged on all later Java 9 releases, but not necessarily on Java 10 or Java 11 (this is not a theoretical concern, I've seen it happen in practice).
> but I think the main issue is that many companies are severely overestimating the cost of the one last major upgrade past 8
I worked on upgrading one large codebase from Java 8 to also compile and run on Java 9 and Java 11 (making it run on Java 9 is a good first step to making things run on Java 11, but it's not enough; there are important breaking changes on Java 11), so I have a good idea of the costs. It's not just the compiler being slightly more strict with generics and a new class in java.lang conflicting with a wildcard import, which are very easy to fix, or the whole system failing to initialize when ran on the Java 9 or Java 11 JVM, which is annoying but hard to miss; it's also less used parts of the system failing to work when it's on a Java 9 or Java 11 JVM, many months later.
You not only have to upgrade your code (and hope your QA and unit tests caught all relevant cases) for the new Java version, but you also have to upgrade all your dependencies, recursively (and hope they didn't introduce any compatibility breaks themselves), and sometimes even introduce new dependencies (especially for Java 11). As late as this year, I was still seeing open source libraries releasing compatibility updates for Java 9 and/or Java 11.
Add to this that multi-release JARs created a way for Java 9 to break your code even when you're staying on Java 8†, and it's pretty easy to see why long-time Java shops are jumpy. Things had been moving along relatively slowly and placidly for quite a long time, and then, all of a sudden, Java gets a bee in its bonnet and decides that it, too, needs to move fast and break things.
† Admittedly only if you're getting feisty with run-time reflection fanciness. Which you probably shouldn't, in principle, be doing in the first place. But, in practice, it's pretty standard practice in Java.
Change is not made for the thrill, but because changing hardware, hosting, software requirements and changes in the wider software ecosystem demand it. Most of what Java broke and is about to break is the ability of libraries to too-strongly depend on implementation details -- what you admit you know is bad but do anyway; if every implementation detail is exposed and relied on, then the necessary changes cannot be made in a backward compatible way. In other words, Java is breaking the ability of libraries to break its backward compatibility. I'm sure this will require some adjustment, but is overall a better plan for backward compatibility in the long term than reducing investment in the platform and not coping with necessary change.
All of this is true. But avoiding change is not just knee-jerk stodginess, either. In a large, long-lived Java codebase, the cost to test for breaks can be immense. So you've got to convince yourself that the cost to stay on the old JDK is greater than the cost of moving to a new one.
I think we can see from the Python 2->3 precedent that it's easy for new projects to adopt the new platform. That, in turn, incentivizes library maintainers to make the migration. But the only thing that will really motivate many business users to migrate is an end of support. Which, in Java 8's case, means we'll start seeing more movement as 2030 looms closer. That's an entirely rational business decision. 2030 is a long way away. Anything could happen on that kind of a time scale, including things that would render a migration past Java 8 a waste of resources, like the project being canceled or migrated off of Java entirely.
True, some businesses will likely stay on 8 for as long as their application lasts, and this can certainly be a rational decision. But I completely reject the comparison to Python.
The effort required to update from 8 to 9+ is nowhere near that of Python 2->3. Virtually all code runs unchanged... except for code that hacks into the JDK and depends on implementation details that have changed, which mostly exists in libraries. The snags are usually in libraries that have made some major API change 5 years ago that the application hasn't adapted to, and the old versions don't run on 9+ for some reason. So the obstacles are real, but it's not like the platform could have avoided them. In the future, such problems will hopefully be avoided when hacking into the JDK is blocked (which might happen as soon as JDK 16, due next March).
The benefits are also quite different from the Python case. The hardware/hosting savings in recent versions compared to JDK can easily more than offset the cost of migration in a big number of cases if not the majority. If you upgrade to a new JDK you get money, possibly quite a lot. That wasn't the case with Python.
So while there could be good reasons to stay on 8 for the lifetime of an application, the cost of upgrade is substantially lower, and the benefit is substantially higher than the case of Python (and by "substantially" I mean something like 10x).
8 -> 9+ is an entirely different story, because not only was 9 the last (ever) major release, but it was a particularly big one.
> If your code ran on a given Java 7 release, it would work unchanged on all later Java 7 releases; the same for Java 8. The same pattern still applies for later Java versions; if your code ran on a given Java 9 release, it should work unchanged on all later Java 9 releases, but not necessarily on Java 10 or Java 11 (this is not a theoretical concern, I've seen it happen in practice).
But the situation now is even better. If your code works on 9, it will work with no or very few changes on 10 and if it works on 14 it will work with no or very few changes on 15, but while there might be slightly more work between 14 and 15 than between 8u20 and 8u40, in exchange you never have another major upgrade again. So the work is just spread differently, and in a way that makes it less costly overall, true, once you've got used to it.
But there's one more difference to those who do remember how things were: It is true that in the Java 6-7 era there weren't as many breaking changes, but that was mostly because Sun was dying and Java barely changing. With Oracle's growing investment, change is picking up, and the new release model makes it easier to cope with, not harder, as those who'll skip too many feature releases are sure to find out.
> You not only have to upgrade your code (and hope your QA and unit tests caught all relevant cases) for the new Java version, but you also have to upgrade all your dependencies,
I'd say that such a policy is based on folklore and/or luck rather than actual long-term experience. You have to do that for every patch release, too (although "upgrading your code" is not something that's very common in Java; most JDK 1.4 code still runs unchanged, and the required changes are mostly on the command line, not in the code). It is not the small spec changes that are most likely to break your code in complex ways, but internal changes that occur even in patches. The change that required the most code changes since 9 has been this one [1], in 11.0.2/8u202 -- i.e. a patch release, not a feature release.
The one area where there is more need to update dependencies on feature releases than patch releases is in bytecode parsing/manipulating libraries, some of which for some historical reason (a bad ASM accident about 8 years ago) still insist on shadowing ASM into their JARs. As a consumer of such libraries, you should advise them to stop.
"Vendor of a product afraid of competing, free product."
Come on, IntelliJ. You are still THE standard in Java development and it's on you to keep that first place. Those "opinins" on Visual Studio Code are ridiculous...
This really makes me want to try out Visual Studio Code for Java.
The biggest competitor to IntelliJ IDEA Ultimate is their own Community Edition; I don't think they're seriously afraid of VS Code in the JVM languages space (JS is another story obviously).
I havent used Eclipse in like 8 years, but if it is as slow and clunky as it was before then for sure VSCode is better.
I remember trying both Netbeans and Eclipse. Both were nice but very slow. Nowadays I sometimes use programs based on eclipse (birt or xmind) and God they make me happy that I'm not doing java dec on Eclipse.
It's not slow anymore, it's mostly as heavyweight as it always was, what means it's a lightish application nowadays.
Clunky can mean several things, and I don't think Eclipse changed in any of them since early 00's. If you consider it an specialized IDE (that means you'll download a full one for each kind of development, prepackaged), and disposable (non-upgradable, you'll download the next version and delete the current one), Eclipse is quite ok for many kinds of development (even some you do with Java).
As a JetBrains customer of their full product suite for many years, I actually agree with this sentiment.
In fact, I think VSCode is one of the best things to ever happen to JetBrains. In particular, Live Share forced them to finally respond with their equivalent product Code With Me (several years too late, but at least it's here).
Without VSC, I don't think JetBrains would be responding nearly as well. It's baffling they consider themselves a full-feature IDE product while having an inferior alpha live share that was rushed through only in response to competition. It's been suggested for years.
> IntelliJ. You are still THE standard in Java development
I figured Eclipse was the most popular, followed by IntelliJ, followed by NetBeans. Is this mistaken? (I couldn't find a definitive answer with a quick google.)
Who knows how realistic it is though... I personally enjoyed working with Eclipse. It simply suffers from a reputation problem because people developed monoliths with hundred thousands of lines in a single maven project in it...
These numbers are probably very much inflated, they are taken from JetBrains' own survey. One could put a similar survey on eclipse.org and claim that 72% percent of Java developers use Eclipse.
The only time I've ever used Eclipse was when it was mandated by my employer. That happened to me twice.
I didn't stay long at either place - for some reason both companies were horrible places to work.
I have noticed a lot of new grads come out of College knowing Eclipse (and only Eclipse). Which is probably why it persists - and I still have to deal with it when I have to help junior devs figure out what's wrong with their eclipse config. Occasionally I can get one to convert to IntelliJ - the rest won't try a new IDE and that's a pretty good indicator of what kind of engineer they're going to be :)
What if I tried both and find eclipse far more efficient, more to the point, and I have built muscle memory and feel intellij slows me down... Am I that 'kind of engineer'? The tool is fine and works. Especially the barebones 'just plain java please no fucking plugins I'll handle git in terminal and C/C++ in Vim THANKS'.
I understand the annoyance with not being able to fix one's setup and that's on them.
But it seems very strange to fixate on what other people use as tools... Especially when both propositions are on the same productivity level. It's not like your colleagues are coding java in vim (and even then if productive AF, why does it bother anyone?).
I'll clarify: I'm specifically talking about junior devs who are having a lot of trouble with their IDE, have no experience with anything else, and aren't willing to give any other options a shot. It shows a lack of curiosity and/or desire to explore new tools. Some of them don't even know how to do a build outside of Eclipse (worse, I've known some "senior" devs with the same problem).
I know one good senior dev who prefers Eclipse. I'm not sure why, but he doesn't seem to have any major issues with it, and he's good, so... ok.
The software world is driven by hype, not by objective quality. See Go, Git (vs Mercurial), every project put out then subsequently abandoned by $PUPPYKILLER_CO after being depended on.
Go's mediocrity is a feature, since it's supposed to allow larger teams to get more work done. That seems to have worked fairly well in practice. The authors hypothesized that a inexpressive language might actually be superior for the types of things that Google used to do in C++ (in terms of development time including onboarding and defect rate [especially with regards to concurrency]).
Git's implementation is stronger and more useful for larger projects than Mercurial's, even if the user interface is less logical.
It's not that the software world is driven by hype but that the software world is driven by what the giants do. Often, what Google does isn't right for a small project.
Same was told of Java (blue collar language) and here we are 25 later where Go people consider Java a PhD level language, while the eco-system is trying to steer a battle cruise to learn new tricks that should have been part of Java 1.0.
Removing complexity from the language just moves it onto the developer and end-user code, it doesn't eliminate it. Go's mediocrity is a ticking timebomb.
My takeaway from this is "I should probably bite the bullet and learn about Spring Boot." I started writing server-side Kotlin about a year ago and find the JVM ecosystem mostly really nice (leagues better than the Node/TypeScript world I escaped from - as much I still like writing TS on the frontend, server-side TS is still too immature to recommend), but I could not wrap my head around Spring/Boot. My understanding is that Spring Boot wraps a bunch of the same libraries used in Spring MVC into an easier to comprehend package, but it still seemed like a very intimidating ecosystem.
I went ahead and used Javalin, which I'm a little bummed to not see represented on the survey - it's meant as a successor to Spark (which I haven't used), and I really like it. It uses similar patterns to Koa/Express in Node, which made it easy to understand. The big downside of not using an integrated ecosystem like Spring Boot, of course, is more glue code, but I actually haven't found it _that_ bad.
Kotlin + Spring Boot is pretty nice and going to get nicer as the Spring people roll out more Kotlin friendly features and DSLs.
The trick with Spring Boot is to keep things simple and avoid some of the stuff that is there for legacy code bases. Also, there is a lot of complexity lurking in using stuff like JPA (which I tend to avoid), spring data (like wise), spring-batcg and a few other things that IMHO are not so great. But the core of spring's dependency injection and e.g. MVC with kotlin's co-routines is pretty nice. If you want graphql, there's a great spring library for that from expedia that makes this super easy to setup.
The reason javalin and other frameworks are not mentioned is because it's part of an enormous long tail of stuff. A quarter of a century of Java means that there are a lot of things out there that are still being maintained and actively developed.
Technically, Spring MVC and Spring Boot are the actually the same thing pretty much. Spring Boot basically just packages up Spring 5.x with a lot of convenient things. I've actually migrated a few old spring projects to spring boot at some point.
Spring Boot is a "convention over configuration" framework for modern 12-factor apps. It integrates the other Spring libraries (like MVC) by providing "starters" that come with a basic configuration. For instance, adding the Spring Security starter package automatically configures Basic Authentication for all endpoints.
Spring MVC is the Servlet-based web library, it includes functionality for serving HTTP endpoints as well as an HTTP client.
This is in contrast to Spring Webflux which is the new reactive web library. It also includes server and client functionality.
One extremely useful part of Spring Boot is spring-boot-starter-parent, which specifies a compatible set of versions for all the various dependencies you're likely to pull in, which is otherwise tricky and tedious.
I wasn't equating them just merely stating that MVC, Flux, and lots of other things are part of Spring 5.x. Spring Boot technically is basically a lot of auto configuration around a large amount of spring libraries and third party components. You could replicate pretty much all of what it does by adding those dependencies manually and manually configuring them. That's pretty much how Spring used to work before Spring Boot became a thing (been there done that). It's actually not that hard if you keep it simple.
> Also, there is a lot of complexity lurking in using stuff like JPA (which I tend to avoid), spring data (like wise), spring-batcg and a few other things that IMHO are not so great.
If you are accessing databases, JPA/Spring Data are pretty much the most common options. For typical use cases, the configuration is straightforward and features like Query Creation[0] can get rid of so much boilerplate.
I'm doing server-side Kotlin as well, with Spring Boot. I initially was against the idea of Spring Boot, because I had memories of using the old bloated Spring Framework from 10+ years ago with giant XML files full of bean definitions and coding-in-XML horribleness with Apache Ivy and Ant. Oh, yea, I also was using all of the above with OSGi as well (Never use OSGi. Ever).
But, Spring Boot is much more modular and I'm impressed with compile and startup speeds. No more XML - unless you want to, but not on my project :) It also supports automagic docker image building using build packs, which keeps the size of images down (not as small as a service built using Go or node, but not as horribly big as you'd expect from Java).
I still have a preference for Clojure and integrating small libraries, but on larger projects where you're working with other devs and need to get moving quickly, Kotlin + Spring Boot is a powerful combo that's hard to argue against :)
Springboot still has not solved the issue with bad dependencies at runtime being an easy debuggable experience. I still struggle after several years pinpointing where exactly my springboot app crashed, because stack traces are perhaps several hundred lines long in some cases.
I don't think TS is immature, but whether it's true or not, Java is still used by 90% of the enterprises. I am amazed why Node.js (TS in server) could not yet challenge Java, especially in large enterprise systems.
because enterprises run huge and old systems performing critical functions, these systems get modified around the edges (small extensions, bugfixes, performance tuning), not completely re-written.
To justify switching the stack (at gigantic expense in training and engineering), a vastly superior technology would have to present itself. I don't think switching from Java to Node would make a big difference for the bottom line.
As a daily typescript developer coming from C#, I don't think TS will replace Java / C# even with it's typing system. For daily CRUD simple system, sure. For more complex operation I still vouch for C#.
I don't know why, just feel like that, maybe stricter typing system and more verbose language is giving me more confidence.
>because enterprises run huge and old systems performing critical functions, these systems get modified around the edges (small extensions, bugfixes, performance tuning), not completely re-written.
Not every enterprise runs a single huge monolithic app or codebase.
it's baffling that at least even after a decade, no major adoption of Node.js ecosystem happened in enterprise. At least we expected new projects to migrate to Node.js but it did not happen yet. I believe the Node.js is yet to have large backing that Java had in it's early days which made things like JDBC and JMS and associated drivers from almost all vendors. Node.js feels like a not so solid, light-weight, scripting language in comparison.
I'm still planning to write a longer blog post about it with more details. I think in terms of enterprise usage, there is no equivalent to a batteries-included framework like Spring Boot - especially not one with paid support available for big companies.
Boot is just an embedded Tomcat/Jetty included with all the different Spring libraries. That makes for an easily bundled application (single executeable jar which launches the web server including all the application code).
There are a lot of Spring libraries to learn about, but only a couple are actually required in a Spring boot app.
Spring Boot brings magic, my like RoR. I can see its super productive, I'm deeply uncomfortable with the magic still, waiting for problems that will be hard to debug, but actually haven't had any.
I was quite amazed by IntelliJ's refactoring capabilities just few days back. I had code like below
switch(sort) {
case "asc":
sortedComments = topicComments
.stream().map(Comment::getThreadComments).filter(Objects::nonNull).flatMap(Collection::stream)
.sorted(Comparator.comparingLong(PostResponse::getCommentPostedTimeMilles)).collect(Collectors.toList());
break;
case "desc":
sortedComments = topicComments
.stream().map(Comment::getThreadComments).filter(Objects::nonNull).flatMap(Collection::stream)
.sorted(Comparator.comparingLong(PostResponse::getCommentPostedTimeMilles).reversed()).collect(Collectors.toList());
break;
}
I selected the first case and applied "Extract to method" and IntelliJ automatically suggested and applied the method to the second case also. Not sure if Eclipse will do that.
Sometimes Idea finds duplicated code without your interaction and suggests to extract it into method. I don't always like it, but it's an interesting feature.
I find sometimes duplicated code is from a business domain quite separate from another, yet intellij wants to bring them together. Sure, one day I will get my shit together on that duplicated code and fix the issue, but sometimes the hassle is not worth the hours put in to refactor. Nice that intellij lets you know though.
I find it funny how they carefully avoid mentioning Kotlin in the article. Especially considering that it is popular and that they created it. I guess they did not want to be party-poopers on Java's birthday ;-).
Basically, Spring + Kotlin is a great combination currently. Spring has first class support for Kotlin and it arguably makes a lot of things easier. E.g. async io with Flows instead of Spring Flux is a lot nicer. I've done several projects with that in the last few years. The Spring people have done a lot of good work in recent years of making it work seamlessly with kotlin. E.g. their flux stuff is a bit clunky but interoperates nicely with Kotlin's co-routines and flows, so you mostly don't have to deal with it.
Also on Android, basically most projects are Kotlin at this point.
But Android isn't Java, and Kotlin's penetration on the Java platform is ~2-4% and no greater than Scala's (or not much greater, and certainly no bigger than Scala's at its peak). It's a great achievement for an "alternative" Java-platform language compared to others -- and because Java (the platform) is so big, this translates to a respectable number people compared to many other languages, especially when you add the Kotlin-on-Android people to the Kotlin-on-Java people -- but let's not get carried away.
Reading these comments, I feel like a heathen for this opinion, but here goes:
I find I prefer Jetbrains IDEs to VSC, massively so. VSC is nice, and I tend to use it as my daily driver, but I experience a host of issues with it that I've never been able to solve. In no particular order:
- Autocomplete/Intellisense/whatever-you-call-it just stops working, constantly. This has persisted across many languages: Rust, C, PHP, Elixir, Java, Javascript, Typescript, Scala, ... despite having the relevant extensions installed. It's incredibly frustrating. Reinstalling VSC, disabling all extensions, etc etc etc has made no change. I've found absolutely nothing that indicates what could possibly be the issue, and fixes I've found online haven't helped. I admit I have a habit of leaving VSC open for days on end, but that shouldn't impact anything -- Jetbrains IDEs work reliably for me under the same circumstances.
- Performance-wise, I find it slower. Sure, a window opens up fast, but that's about it. I have a few extensions for symbol/token colourisation (think rainbow parens, rainbow do/end in Elixir, ...), since it makes it easier for me to read the code, and I find that these have a giant impact on its performance. Things like smooth scrolling -- which I like -- tend to lag out a lot for me when there's a lot of text in the terminal, even when not coloured or anything. It's not like I'm running this on a low-end machine, either; specs are R7 1800X / GTX 1080 / 64GB, so to me it's absolutely inexcusable that it's this slow.
- Unreadable themes are an issue I've run into, tho I understand this isn't a VSC-specific issue. With VSC specifically, I can't find a theme that actually has comments that feel readable to me -- I strongly dislike green comments, and all the themes I've looked at make comments a really low-contrast colour that blends into the editor background. I have neither the time nor the patience to make my own theme (or customise someone else's), so using VSC just becomes frustrating at times because someone thought low-contrast comments were a good idea.
- Stuff like jump-to-definition, refactorings, ... are consistently either not-very-functional, or just don't work. Jump-to-definition specifically loves to just give "No definition found" even when the relevant symbol is in the same file.
Maybe I'm doing something wrong, I don't know. But I've used VSC for the last ~2 years and it's been consistently far less usable for me than a Jetbrains IDE. VSC feels like I'm using a plain text editor with syntax highlighting, an integrated file browser, and an integrated terminal.
Similar experience here. I find IntelliJ autocomplete, syntax highlighting, compilation etc. to be laggy occasionally as well, but I can usually see why and wait for it to finish reindexing or whatever. With VSCode, I don't bother waiting because 1) I often can't visually see why it's not working or when it's ready to work again, and 2) sometimes it's never going to be ready, because something stopped working. I am still actively using both, because I prefer VSCode for Javascript and expect it to eventually catch up for Java and Scala, but I often switch from VSCode to IntelliJ in the middle of a session, never vice-versa.
I literally switched from VSCode to Webstorm purely because JS/TS 'no definition found' errors kept coming up. If I ctrl click a function, I really really want to go to the defintion. I know there is a definition because my code compiles. How can my IDE not know where that definition is? I count that as one of the core features of an IDE, and VSCode doesn't consistently hit that mark.
I dont know what all this fuss is about. Intellij is great, no need to use all the extra features. If your application wont run by typing java -jar myjar.jar, you have bigger problems than what type of IDE you're using.
I don't think it is possible for 72% Java Developers to pay for IDE. Maybe just developers who uses jetbrains answers these serveys. While reading survey need to consider that as well.
I'm not much of a Spring fan (overengineering) but that's how a mature stack looks like. There were plenty alternatives 10-20 years ago. What's a bit more surprising IMO is the prevalence of Spring MVC in 2020 which doesn't mix well with modern JS-centric frontend approaches, just as splitting frontend and backend work between JS and Java is flying in the face of agile job rotation.
We haven't used Spring MVC since 2015, all our services are running Spring Boot because it is the most mature solution on the market to create the webservice layer. Our Spring apps are then containerized and optimized with jib[1]. Our frontend is built on React Hooks + TypeScript, fully SPA. All the work nowadays in our company is focused on data engineering, by that I mean: databases, parsers, managing the data pipelines, orchestration, Python for creating the models and Java for inference in production, our teams consist of data scientists that are using Python and software engineers that are using Java and TypeScript.
I don't understand why people consider Spring to be overengineered. We find it very productive, time to market is huge and we can focus on other parts of development instead of reinventing the wheel. We are also considering Quarkus for some of our services that aren't supposed to run for a long time.
I'm not sure why they separated them. Spring is Spring imo. There's a lot of tooling that is very quickly accessible and "just works". We have 15 microservices and three or four UIs that are all Spring backend with React frontends and it isn't even a little cumbersome. We don't serve the static content from Spring as a webserver though (we use a separate nginx instance).
Nobody forces you to use it, there are a lot of alternatives out there.
But I have to admit that Spring Boot combined with Kotlin is the most productive development environment I have ever worked in. I am not surprised it is so popular among Java devs.
> Nobody forces you to use it, there are a lot of alternatives out there.
That assumes you're starting a greenfield development. If you're joining existing companies with a mature tech stack, you won't be able to unseat their existing choices because there's a lot of risk involved.
If there is no both WORTH to maintain and hard to maintain code in your language of choice, it's because that language of choice was not used to solve the type of problem Java is used for...
In this current post monolith, micro-service world, most java applications remain very maintainable though.
Actually my language of choice has been used mostly as a Java replacement. And while there is no perfectly maintainable language, little else is remotely close to the awfulness of trying to maintain a Spring Boot application.
Spring boot specifically; regular Spring is relatively ok. I'm using it professionally at the moment. It's just impossible to find where anything is coming from or understand how your application is wired up, because everything magically appears based on what's on the classpath - it's like the COME FROM statement joke. Even just changing your dependency versions can suddenly radically change your application's behaviour (e.g. now it's suddenly running a webserver).
I don't understand why is it better to have something wired up by annotations than explicitly writing java code. Is 'new' obsolete? At least tools (including IDE) can look for method calls, annotation strings not so much.
I'm completely baffled by the popularity of Spring.
> I don't understand why is it better to have something wired up by annotations than explicitly writing java code.
The argument is that most of your services will be global-ish singletons, and so the details of which services are used from which other services are ceremony rather than business logic; if you've made a code change that means service A now calls service C instead of service B, you want the diff to be about the actual code change in A rather than the plumbing of where it's getting service C from. Since there are problems with language-level singletons (e.g. testability) you want to use plain objects passed to the constructor, but since 99.9% of the time the FooService is always going to be the FooServiceImpl, you don't want the trouble of explicitly wiring it all up yourself. I don't necessarily think Spring is worth it, but wiring by hand certainly does involve writing a lot of code that's more or less irrelevant to your actual business logic.
> At least tools (including IDE) can look for method calls, annotation strings not so much.
Actually one of the things that makes Spring almost tolerable is that IDEs generally do have integration with it, and so "find references" will work properly even for things that are reflectively instantiated by Spring.
(That only applies as long as your wiring is "static" though. With Spring Boot's conditional bean annotations all that goes out of the window and you have no hope of understanding where anything is coming from or where anything is used).
I am not sold on the premise that plumbing code is bad or not business logic, being explicit is no trouble, it is part of the story. How is writing a factory method worse than writing Spring configurations? Personally I prefer to write Java to Spring DSL.
The point is you don't have to write the Spring configuration (except in the rare cases where you need to override with something specific). Just mark each class's constructor as @Autowired, make an AnnotationConfiguredApplicationContext passing the list of all your classes, and you don't have to manually keep track of which services need which other services - Spring takes care of instantiating everything in order and passing dependencies into the things that need them.
Annotations make dependency injection simpler. If you have a Controller that has a Service autowired into the constructor then you can test it by passing a mock service into the constructor.
An alternative would be to have a Main method construct all of the objects and pass them into each other, but @Autowired takes care of that for you.
I don't see any problem with that, in fact, being explicit is a huge plus. I would take that any day of the week over untraceable code.
To be more precise, I'm not just baffled by the popularity of Spring, I don't even comprehend how any of that is a good idea to begin with. It solves a non problem and brings in enormous baggage.
That is true, there's a lot of "magic" that comes with boot. It can be helpful to take a look at what all of that auto-configuration code is actually doing, but reading that stuff is pretty difficult as well.
> It can be helpful to take a look at what all of that auto-configuration code is actually doing
You can't tell by reading it either, because it's all dynamic: all of the autoconfigurations create beans conditionally only if other beans of that type aren't defined, if certain classes are present on the classpath, if particular values are defined in the configuration that's written in magical self-transforming YAML, or all three. The only way I've found is to breakpoint at the point where something is wired in to see what the concrete class is, then breakpoint again in the constructor of that class to find where it's being constructed from, so you have to restart your application and run the (slow) spring boot startup twice for each thing you care about. And even that doesn't always work because spring encourages doing AOP with bytecode-manipulation-based proxies.
If you want to move away from the servlet spec. with all the limitations it's implementations have and take control over the foundation of your projects; I made a app server and distributed database that fits in a 166KB .jar unobfuscated:
Already back in 2003, Greg Wilkins, the author of the Jetty Web container and contributor to the Servlet specifications, blogged about some issues with Servlets:
- No clear separation between the protocol concerns and the application concerns.
- Unable to take full advantage of the non-blocking NIO due to blocking IO assumptions.
- Full Servlet Web containers are overkill for many applications.
My design fixes all of them and adds many features:
- It has classloader hot-deploy, which means you can replace the implementation while people are requesting things from the server for zero turnaround development over HTTP distributed across continents securely.
- It uses non-blocking sockets, concurrent lock-free data and async. network implementations to allow for joint parallel scaling (many threads accessing the same memory).
- It implements "transfer-encoding: chunked" to allow real-time server -> client messages without over-engineering.
- It has a distributed JSON file database hosted on-top-of HTTP so it can scale.
To answer your question specifically:
The Service.java is similar, but Event.java and Reply.java are different as they allow hold() and wakeup() for NIO concurrent async. features!
> - Full Servlet Web containers are overkill for many applications.
This is true. Servlets are clearly part of the Component Oriented Distributed Middleware architectural vision of Sun Microsystems' architects circa late 90s. A beautiful component oriented architecture, imho, but yes, too overblown for your basic web-apps.
> My design fixes all of them and adds many features:
I'll take a look. I don't think (per above) that your solution is really demonstrating a short-coming in the design of Servlets. You have entirely distinct design goals that merely share a network protocol in common.
p.s. so here is an example of a J2EE startup back in ancient days. I remember interviewing with these guys in Boston. They were dreaming of the future "Component Market" and clearly attempting to execute on Sun's vision. [Sold to BEA and now Oracle] People either don't remember, or never understood, why Sun created JEE. (And apparently, neither did the execs in Sun who completely blew it.)
The funny thing is, I actually really enjoyed java in the early days. Before it went all "enterprisey" with FactoryFactory over-engineering, XML, annotations and all the other crap. I mean, how is that stuff fun?
You're not obliged to overengineer you code, use XML or annotations. Well, annotations are too prevalent, so not sure about those, but you definitely can limit their use to absolute minimum. There are plenty of libraries with different approaches. Many people don't like magic code which auto-discovers everything, so there are many libraries where you have to be explicit. And modern Java with lambdas often very helpful for such APIs.
I suggest you not to follow the mob and think critically about libraries you're going to pick up or the way you're going to use them. For example Spring can be magic, but you have an option to make it very explicit.
In all fairness, I do like some of the more recent additions to the core language. And I still write the occasional Java program even today - when I do, I certainly do it the way you describe, ignoring all the cruft.
But there's not doubt about the fact that mainstream Java has taken a wrong turn at some point.
All those abstract factories originated in the Gang of Four patterns book. And this book was written with C++ examples. So I'm not sure that it's a Java to blame. More like general approach of software development at that time and Java happened to be the most popular language at that time as well.
> Still, we don’t deny the information could be a bit skewed – even with the weighting we give to our survey results – given that this is from the JetBrains State of Developer Ecosystem survey, and one of JetBrains main products is IntelliJ IDEA.
They claim to have 72% of the market based on their own survey (given to their own users), and eclipse only has 13%. Can't believe they would even bother to publish that.
Personally I prefer to use languages that don't require refactoring tools to make them bearable - but in my experience back in the day with Java, most IDE users didn't know what 99% of the functionality was for anyway.
I'm not good enough to write my code in a way that won't need changing at least a couple-few times over a 5 year or 10 year period. I'm grateful for refactoring tools.
If you are doing OSGi, Eclipse is the logical and optimal choice. Personally I have yet to see an OSGi project in my professional (US) work, but do see a lot of French (Sr.) devs with OSGi on their resume.
Interesting to see that fragmentation in versions being used. I guess that’s to be expected with a faster release cycle. 75% still on Java 8 is surprising though, isn’t it already EOL?
IME a lot of developers don't like their IDE heavily coupled to backend servers and environments, but actually prefer the "code editor + useful features" approach. It makes combining with CI/CD a lot simpler for one, since the activities run on a project can simply be the same as those run on the pipeline. A quick "mvn install" is often enough for many/most modules. Many devs only really want advanced editing + syntax highlighting + language server.