Conditional breakpoints in IntelliJ were big for me when I discovered them. It's helpful when there's many iterations of the same function so you can stop at specific inputs.
There's a lot of options you can put on each breakpoint in IntelliJ, every developer should know about them. Right click on the breakpoint and click the "More" link.
Using "Run to cursor" is my favorite less known feature in debugging, it's really useful.
Don't forget about "Reset Frame". When you're manually stepping over something and accidentally go too far, this will take you back to the previous stack frame so you can try again.
Apologies, I didn't mean to imply DCEVM went poof, just that I was sad it didn't make it into OpenJDK so one need not do JDK silliness between the production one and the "debugging one" since my experience is that's an absolutely stellar way to produce Heisenbugs
And I'll be straight: Graal scares me 'cause Oracle but I just checked and it looks to the casual observer that it's straight-up GPLv2 now so maybe my fears need revisiting: https://github.com/oracle/graal/blob/vm-23.1.0/LICENSE
I find this to be one of the most useful tools in debugging.
For example, if an exception is being logged in some random location (but poorly) I can throw a breakpoint on the log message, pop up several stack frames, look at the inputs into those frames (what are all the local variables) and replay down to whatever level I want or what other breakpoint I want to hit.
The only catch is if your functions are mutating input data (or some shared state somewhere), then you could be looking at different executions from one stack to the next.
One more reason to prefer pure functions over side-effects.
I use those & the 'evaluate expression' feature pretty regularly to transform the data into a friendlier format once stopped at my breakpoint. Super useful & quicker than source changes for one off things.
we used the on-demand debugger when creating our sdk extended by lombok and found it very helpful. we also built an IDE plugin that lets you call a Java function directly, without having to expose an http end point, check us here: unlogged.io
I actually thought about preempting your reply about that GH repo since (a) it's not the IJ plugin (b) it's not GPLv3, but I thought "surely they won't chirp about their linked GitHub repo knowing full well that the plugin isn't in the repo ... surely"
This may be a very ignorant question, but is anyone using Java for new projects these days? Or are most of the projects legacy projects? I've not heard of anyone electing to use it anywhere as their first choice.
Sure, it is not a problem as long as you are aware of it.
> but is anyone using Java for new projects these days?
I work with large financial companies, think banks, brokerage houses, payments, etc.
Pretty much every large company in finances runs on Java and most new projects are in Java.
Java is uniquely suitable for this. I spent a lot of time thinking why is this. I think it is a combination of Java being relatively poor, handicapped language suitable for mediocre programmers not able to do much more than copy/paste. I love Common Lisp or Clojure but I quickly found using any powerful language with a software development team at a large bank must lead to a disaster. With Java, that disaster if it happens is limited a bit because there is less abstractions you can shoot your foot with.
Huge amount of boilerplate code means all projects look pretty much the same and every developer finds himself/herself right at home in a new project. If you know one Spring REST API you know pretty much all of them. Which is hugely important if your developers are barely able to learn new things.
Aside of the above, Java gained popularity due to its virtual machine, garbage collection, object orientation and pretty good standard library and ease of adding more dependencies to the project. Right now it is self sustaining situation because the amount of dependencies that are available, amount of software written and the fact that all those financial institutions have to maintain Java teams means, that it is almost always cheaper to hire more Java devs than try to use other languages.
Some companies have a lot of tooling made for and internal frameworks built in Java. It would be a lot of effort to rewrite all of that in another language, and also a lot of effort to just forego all these goodies and implement them myself. In the end I'm getting paid to ship a product.
Sure, Java is not "cool", and new devs fresh out of university might prefer something else, but let's not forget that modern Java is nothing like the Java that a lot of people used a while back. Most of the criticism we heard ("boilerplate") is not really valid anymore.
Most companies > 1000 employees that were founded before 2000 will have most of their critical internal systems written in Java and/or .NET.
If you don't know anything about a large company and have a meeting with someone in IT there, it's a safe bet that boning up on Spring Boot before the meeting will be beneficial.
If there's a lot of Java knowledge around in a company it can certainly be beneficial to use it ;). I set up a simple REST backend service last year using Quarkus and can think of worse frameworks I could have picked.
Also, if a new system has to connect to a legacy system using SOAP there are about 2 languages with a complete and interoperable implementation: Java and .NET. There are lots of toy libraries for other languages but I've never found one fully supporting the entire WS-* standard set.
Sorry, I should have clarified. Yes, if a company has most of its legacy code in Java, it likely also still does new projects in Java. The Java ecosystem is robust, well-supported, and performs well. When you are working in big enterprise tech, third parties with whom you work will often only support Java and .NET as first-class citizens for interop.
It's not trendy, but that alone is not enough to overcome the advantages of choosing the fleet standard in a company that already has a substantial investment in Java.
At our company, most of the greenfield projects (with a high-performance profile) are in Java. So, for what our anecdotal example is worth, I can confirm that Java is used for new projects.
IMHO, Java fell a bit behind with the rise of the microservices/lambda paradigm because of its memory footprint and slow start. On the other hand, it's an amazing piece of technology, and I would expect that with ahead-of-time compilation and JVM snapshots, it will become more appealing for these use cases.
I genuinely like Java and find Spring Boot enables me to be more productive and let me focus on the business logic. Spring Boot may seem a bit scary for junior developers with its focus on "magical" annotations, but once you get past the initial learning threshold it really pays off relatively quickly due to the eco system of modules that work well together.
There are of course smaller Java frameworks that you can use if you have made an honest try and dont like Spring, but the eco system is hard to beat. Go also does not have any benefits that are of any real value to me. I have admittedly not tried Elixir, but it seems to me that the mature eco system around Java is better for someone like me who is not interested in spending time on less mature 3rd party dependencies. I like the concept behind Phoenix Liveview, so I will try it sometime.
Java as a language has improved a lot recently, and while there it could be better at handling nulls, it's not enough to make me choose Kotlin.
If you had told me I would have Java+Spring Boot as my first choice 10 years ago, I would have doubted you. Java at the time seemed to stagnate, but this has changed .
C# is a close second. It depends on what the customer knows.
TypeScript third. But first for frontend.
Kotlin could have been on the list. It is a nice language but not worth the hassle (tied to one ide, extra configuration, examples that doesn't work etc).
I want to learn Clojure, and I'd be interested to try modern PHP again.
Every other language I will only recommend if people already use them and know them.
I have used Javascript, Python, Perl and VB (and used to prefer them over Java) but as I get older anf Java gets better I wouldn't waste my time on any of them except Perl, and only because I haven't used it in the last 15 years.
Of course there's a big legacy component in Java that's not there with languages that weren't around 20 years ago.
I don't think less of Java than other languages, old or new. It has its flaws but so do the others. It's battle tested, almost as efficient as native code and still evolving.
