IDE productivity, and it started with Smalltalk and Lisp Machines, was adopted by C++, Visual Basic and Delphi, among several 4GLs, several years before Java was invented.
Everyone is free to use Java in vi with make, if they feel happy doing so.
In fact, there were hardly any Java IDEs when the language was released in 1996, which were quickly provided by Smalltalk, Delphi and C++ vendors.
I've worked on plenty of projects where I can navigate around in a pretty dumb text editor and run "make" and things mostly work. In Java land most things are several folders deep and things are injected in from places I don't understand without tooling to show me what is going on. I mean, have you tried using jdb? It basically exists as an advertisement for an integrated debugger.
No, you’re being facetious. GDB and jdb are not comparable at all. jdb is not meant for actual use. This becomes immediately obvious if you spend like ten seconds with it. There’s no readline support, no tab completion, no fancy breakpoints, poor expression evaluation…I can go on and on. GDB has a learning curve but is unquestionably a professional tool that sees heavy use. Similarly, people can make also sorts of spaghetti projects with C(++) but you can also make very nice ones. With Java the state of the art basically requires you to juggle a classpath at all times. You surely know this: all the tools are designed to be driven by automation. Why are you claiming otherwise?
It's not so much that you can't do Java without an IDE—Java is verbose in part because it doesn't assume that you have an IDE to give you context—it's that IntelliJ is such a good IDE that it's hard to go back to weaker tooling once you've become comfortable with it.
All my co-workers use VS Code for TypeScript, but I feel crippled when I can't use WebStorm. Not because I can't program without it, but because I'm missing a powerful force multiplier.
I used to think that WebStorm was terrible for refactoring; but somehow it's still very far ahead of other editors like vscode, and vscode itself is very far ahead of almost everything else too.
WebStorm is worse than IntelliJ Java, but that's because TypeScript is much harder to statically analyze. There are fewer safe refactorings in a language that has so much flexibility.
Thats because Java IDE's are ridiculously powerful. When I work in vscode and Python, I am always like: This is so much easier when I am using Java and Intellij.
It is not mere IDE Dependency. It is IDE Supremacy. Java is the leader of the IDE master race - the other PL IDE's need to squint to see how far ahead Java IDE's are.
I've seen many frameworks shared in hackernews. But rarely do I see
anyone commenting on their IDE's capability to be able to use that framework for go-lang, rust, c, c++, etc.
But then they complain they had to manually type an import statement ... before going back to their opinionating on how bad IDEs are.
I find the whole notion of software engineers rejecting software applications being useful as a concept while it being the primary focus of their own profession quite fascinating.
If a developer does not want to try this framework because an IDE
does not yet support a particular version of java, then the situation
has gone beyond an IDE being just useful.
Personally I use various IDEs, light weight IDE/Editors and even vi/vim
depending on the language & situation.
Think of it this way:
If I asked my team to develop a project/POC with this framework and they
came back to me saying that they have to wait for (or prefer to wait for,
or whatever) jet brains to add java 21 support to do this,
I would not be very happy.
JDK21 hasn't even hit general availability yet according to its own schedule [0]. It seems a little impatient to get upset that tooling isn't 100% there before it's even released. Naturally tool vendors aren't going to release their official support until they can test against the final version. This indeed is part of the maturity people do like about the Java ecosystem.
So you're saying that you are unhappy that Jetbrains doesn't officially support JDK21 yet? Cool story bro. It's a tool preference. Same deal with any other language. Nothing is preventing your developers writing code for JDK21 today, even with the Jetbrains IDE. You can write and compile JDK21 projects and ignore any related highlighted syntax/semantic errors.
Good job on distorting my comments. Hopefully the developer who
made the original comment will read your recommendations and
will decide to give this framework a try.
I'm saying your comments basically boiled down to that. You are unhappy that developers might prefer a tool that doesn't officially support newer features of a language, even though it doesn't really prevent them developing with the new features using the same or different IDE or a text editor or whatever. Same deal with C# or C++ and every other language supported by IDE's, hence C.S.B. This is an issue with programming in general, not Java specific.
If a developer says "The blocker for me is IntelliJ supporting Java 21",
clearly there's an IDE dependency. Powerful enough for a developer
not to adopt a new framework.
It's entirely possible to write Java without an IDE. I've done it, and one of my colleagues has been using VSCode quite happily (we've bullied him into stopping because it doesn't have a formatter and he keeps checking in wonky code - but that's another story).
But writing any language is much more productive with a good IDE. For me, the added value in using Java 21 now rather than in a few months is not enough to outweigh giving up the use of an IDE.
ip_conntrack_tcp_be_liberal is still in kernel sources and it is enabled in distributions like openwrt. The author does not mention this, so very likely that his/her custom router will drop traffic. Recently I ran into the issue with Netflix traffic which seemed to use window scaling. In my case I did not disable scaling, but had to enable this option on arch Linux.
This is false. Nginx will spawn new workers with the changed config and gracefully shutdown the old ones once the new ones are online. There should be no drop in traffic or dropped requests while this happens.
Before making this statement, think of how the following states can really be non-disruptively handled:
1) requests in transit to nginx (in-flight)
2) TCP handshakes just completed (not yet accepted)
3) TCP handshakes in progress (clients will retry if server doesn't RST)
Nginx cannot know if requests are in transit nor it can handle just established TCP conns. It also does not drain
the backlog queue in the old processes. It simply tears down
estimated 'idle' connections.
Try a test with heavy load and you will see. More network latency more errors...
That's exactly why Nginx Plus offers dynamic upstream modification features as opposed to relying on reload.
Reload runs old/new processes in parallel, so switch is super quick and new connections always land on new processes. So error rate between reload and restart is huge.
