A Picture of Java in 2020
blog.jetbrains.com
blog.jetbrains.com
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.
Also it’s not 2000. A Java IDE will work fine on any computer you can buy.
How much assistance are you used to or do you consider worthwhile? Where do you draw the line?
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.
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.
So, like we should all build houses with straws and mud, since that is the simplest and gets the job done (creates a habitable structure) too?
For all intents and purposes a modern brick might as well be carbon fiber compared to ancient bricks.
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).
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 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.
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.
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.
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.
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.
Such as?
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.
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.
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.
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.
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?
[1] https://www.jetbrains.com/help/idea/refactoring-source-code....
[2] https://www.jetbrains.com/help/idea/list-of-java-inspections...
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.
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.
How does Java need strong IDE more than other languages?
The only thing I can think of is the (long) import handling, but that's hardly a "strong" IDE feature, more like bare bones IDE feature.
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 :-)
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 :-)
That's an extremely optimistic view.
I haven't seen inheritance more than one level deep in JavaScript for years. And most code isn't using it at all.
(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.
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.
Throw something like eclipse/Jetbrains at it and the whole thing has an aneurysm .
If your language requires an IDE, you've already failed
> In the web space it is understandable to use an editor as web developers are typically working with dynamic languages
> But in Java, especially professional Java, you really get a lot out of a good tool
What are the reasons that make you intentionally "lose" the advantages of the IDEs?
What do you have in return?
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.
OTOH:
1. it encourages the main company to simplify and/or extend the plugin API to make writing plugins v simple, or even possible in the first place.
2. it gives a smoother path for the inclusion of new trending technologies into the IDE.
3. it encourages devs to offer improvements to features that aren't high priority for the large IDE company.
For the latter, I'm thinking of Lombok support which, via a plugin, is much better in VSCode than it is in either Intellij or Eclipse.
Studying how the IDE made use of Turbo Vision was a good introduction to OOP ideas.
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.
You really don't want to add ephemeral designer tools to your list of hard project dependencies.
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.
Still no idea. Seems to be a synonym of IDE, but not really?
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.
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 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).
True, QtCreator performance is fine. But I found the whole toolchain integration (Kits?) and cmake integration a bit weird if I remember right.
The fact that it played so nicely with CMake was an added bonus.
- 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
Of course, it sounds like there is no real testing or review before your team commits to master anyway, so there is your low-hanging fruit.
I would be interested to read more on how to add such a strict CI to an existing project.
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).
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.
Also nice advantage of Intellij hints is that most times they also offer auto-fixer so it's very safe to apply the fixes.
…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”.
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 sort of mix and match depending on what works best for a given project.
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 ;)
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.
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.
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.
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.
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.
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.
[0] https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht...
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.
If you want the QtGui module, look north of $100k buy-in.
Which to be fair is a very impressive piece of technology
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.
> 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.
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.
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.
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.
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 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.
That would be so far beyond impractical you wouldn't last an afternoon.
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 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..
I think the thing with these
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 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.
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
https://www.jetbrains.com/rust/
and of course, there is the GoLand IDE
Which I personally like alot.
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.
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.
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.
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.
When you start a longer session, the overhead is very much worth it, I agree fully.
I wouldn't blame that on VS Code but on the relevant extension. Go to Definition is instantaneous for me when I'm working in TypeScript
The way of the future is definitely lightweight code editors loaded with as much or little customisation as the user desires. Monolothic IDEs are long dead outside of the Enterprise™© world.
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.
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.
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.
What in the world do you mean by this? C# is more amazing than ever...
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.
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.
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.
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.
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.
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.
I really enjoy using VS code, but it is no IDE.
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.
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 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.
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.
I find this pretty dumbfounding considering the amount of efforts that goes into IDEA, Eclipse, Visual Studio, and X Code on a daily basis.
Also, watch how VS Code (and other text editors) are slowly turning into full blown IDE's as well.
The code we write today has never been more complex, it requires matching complex tools.
And Intellij's products come from decades-old thinking about how to manage that complexity.
They're not good enough; for many people they don't help manage complexity. They just increase the confusion.
I have Webstorm with 15 projects open using 500mb of ram, and IntelliJ using about 800 on a larger Java project.
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.
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
Personally I really like the freedom to switch editors.
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.
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.
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.
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'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.
[1]: https://charlespetzold.com/etc/DoesVisualStudioRotTheMind.ht...
I still use Netbeans for Java. It's simply the best.
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.
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.
[0]: https://microsoft.github.io/language-server-protocol/
[1]: https://github.com/fwcd/kotlin-language-server
[2]: https://discuss.kotlinlang.org/t/any-plan-for-supporting-lan...
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'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'm not an Electron fan, but VSC is a great app.
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.
Try to do iOS storyboards by hand in a text editor loved by the HN UNIX crowd.
Strange, and me thinking I've already covered that:
"as for native apps, most focus on iOS or Android (rather than desktop native). Somehow RAD native apps became the forgotten stepchild."
I mean that is my theory ... and I think a lot of people share that theory.
* Better refactoring
* Better linting and code cleanup; Most of the time I learn new language features from the IDE linting
* Awesome diff/merge tool; Not just for git but for local history (undo/redo)
* Debugging/running multiple projects at once is also nice
* Better dynamic language support; Easier to use on a large wild Javascript codebase
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.
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.
Can it Inline Variables yet?
And you'll find other refactoring options as well, e.g. rename, extract...
Here's refactoring and code inspection in IDEA [1], [2]. VSCode is just that: a code editor with some features tacked on.
> “Analysis and refactoring and everything” isn't something VSCode overlooked developers interest in
This is somenthing most VSCode developers (and emacs and vi developers, too) aren't even aware exists.
[1] https://www.jetbrains.com/help/idea/refactoring-source-code....
[2] https://www.jetbrains.com/help/idea/list-of-java-inspections...
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.
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.
That's just a configuration, you can absolutely define import groups in IntelliJ
I have yet to see vscode perform one third of the refactoring options provided by e.g. qtcreator for c++
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.
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.
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.
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.
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.
Profitable as well, it's always been about the $$$.
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.
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.
> 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.
[1]: https://pangin.pro/posts/computation-in-static-initializer
† 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.
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.
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).
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.
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.)
IntelliJ: 72%
Eclipse: 13%
Netbeans: 3%
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...
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 :)
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 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.
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.
I get it. Most software is boring, doesn't break new ground, and Go is well suited for those kinds of projects.
But I'm becoming an old, cranky developer who wants to work on problems where Go's mediocrity is more hindrance than advantage.
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.
Guess how Go will look like at 25?
Keyword being "supposedly", because in practice, it's quite terrible compared to established solutions like Java and C#.
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.
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.
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).
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.
care to explain?
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.
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.
Not every enterprise runs a single huge monolithic app or codebase.
I don't know why, just feel like that, maybe stricter typing system and more verbose language is giving me more confidence.
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.
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.
Neither are required in a Spring Boot app though.
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.
[0]: https://docs.spring.io/spring-data/jpa/docs/current/referenc...
There are a lot of Spring libraries to learn about, but only a couple are actually required in a Spring boot app.
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 :)
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;
}
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.
Android is going Kotlin because Google needs a way out of the mess they themselves created.
It is quite telling that they purposely always compare Kotlin to Java 7 code samples.
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.
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.
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.
It was used in one of the first big projects I did and it helped me become a better developer.
In this current post monolith, micro-service world, most java applications remain very maintainable though.
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.
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.
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).
Fixed it for you.
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.
Let's start with this: https://github.com/tinspin/rupy/blob/master/src/se/rupy/http...
How is the abstract class of yours less limited?
- 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!
Jetty has continuations per Servlet 3.0 spec.: https://www.eclipse.org/jetty/documentation/current/continua...
> - No clear separation between the protocol concerns and the application concerns.
Waiting for the link to see the details of this conclusion. In the interim, "application concerns" are addressable via https://docs.oracle.com/javaee/6/api/javax/servlet/ServletCo...
> - 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.
https://web.archive.org/web/19990417094359/http://www.theory...
No comments there, but you can read about his probable contributions to the continuations API in later posts maybe?
Sure we all try to implement HTTP the best we can, the difference is how fast and efficiently we do it.
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.
But there's not doubt about the fact that mainstream Java has taken a wrong turn at some point.
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.
1. It's too memory hungry for a project that uses microservices.
2. Lack of official support for OSGi & bndtools (although it looks like almost no one else is using it based on their data).