One of the best things about the Devoxx Java Conference in Antwerp each year, is that even after our 5th time going there we still meet lots of new developers who aren’t quite sure what JRebel actually is. They might have heard different speakers mention it during their talks as being helpful for speeding up development, or saw the ZeroTurnaround team at the booth in the exhibition hall, or just ran into someone wearing a new JRebel t-shirt in the beer line.
Welcome to the tenth RebelLabs cheat sheet! This time we’ll focus on the useful JVM options you might want to use, but forget about. In this post, we’ll describe what each of the featured options do.
We have previously published articles that, surprisingly, are not about JRebel for Android, but are useful for every Android developer. We’ve talked about your Gradle build times, about getting started with Retrofit 2 and so on.
Today, I’ll take a look at build cache that is coming to Android development toolbelt in the future. This can potentially have a great impact on improving build times. Which is universally a good thing, since no one likes to spend more time waiting for the project to build.
Not long ago, I inherited a bunch of spaghetti code sitting inside a big legacy enterprise application, and I found myself hoping that everything I needed to deal with was already there (and hopefully working properly). But when I needed to change something, how could I tell what will be affected? The side effects of any changes I make should be clear from the beginning. If only I could do unit tests AND see the ripple effect across the code too…
Well, I can. It’s called Mocking, and it lets you create alternative realities for your application to play through, without having any side effects or consequences in reality.
This post continues our series of one-page printable cheat sheets about Java and related technologies that we’ve been producing for almost a year now.
Today it’s all about Java generics. The feature was added to Java 10 years ago, and even today it still confuses many Java developers.
Every webapp in development holds a great supply of surprises for the developer. When something is behaving unexpectedly, there are two ways to troubleshoot it: either add debug logging or attach a remote debugger. Both have their pros and cons. Which is the lesser of the two evils? What compromises are you willing to make? If only there was a way to get the best of both worlds. Now there is. The Logs view is the newest addition to XRebel’s issue-finding capabilities.
Two years have passed since the release of JRebel 6. Throughout this time, two JRebel agents have been available in parallel (JRebel Agent and Legacy Agent). Now that the new JRebel Agent has fully matured, we are making it the default. JRebel’s support for remote servers has also been significantly enhanced. In addition, we have updated integrations with many of the frameworks and application servers to support their latest versions.
When upgrading to JRebel 7 from a previous version, check out our upgrade guide.
What do buying a fire extinguisher and not smoking inside the house have in common? Both are aimed at mitigating the effects from a potential fire. The important difference is that one measure is proactive, and the other is reactive. Same applies to performance: monitoring reacts to damage and testing prevents damage.
This post continues with the series of the cheat sheets that we’ve been producing all year. And this time it’s all about Spring Framework annotations. We look at the annotations that make Spring a flexible, but at the same time a very stable choice of a framework.
You can find tons of tutorials about how you should use Spring — its configuration and a myriad of excellent Spring projects on the internet. We, however, want to provide a one-page reference for the most commonly used annotations. With this, you will always remember which annotations go where. Here we go!