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!
We believe Couchbase is one of the most popular and widely adopted NoSQL data storages.
Today, I’m excited to announce a significant milestone in the development of JRebel for Android. JRebel for Android has reached the 2.0 status. This is the first major release we have introduced since the release of JRebel for Android v1.0 in December last year.
We have been listening to your feedback and turned it into features that will help JRebel for Android make your development process faster and simpler. Literally, hundreds of fixes and improvements have been added in the v2.0 release.
In this post, I want to shed some light on the main features we’ve added since v1.0 and why we think it’s a really big deal.
A couple of months ago, we released our annual Developer Productivity Report, where we looked at the results of asking Java developers about what tools and technologies they use. Among all kinds of cool findings, like what IDE is the most popular, whether microservices offer a salvation from solving hard problems, and so on, we got the data about the web frameworks our respondents use.
We saw that both Spring and Java EE are pretty popular choices, and the general consensus is that both are quite excellent. That realization made us ask a deeper question. What components of the platform do you actually use?
In this post we analyze the data we gathered to answer that question
Since we launched JRebel for Android last year, we’ve learned a lot about the Android build system, how it behaves in real-world projects, and where actual build time bottlenecks occur. Most of this invaluable feedback came from our JRebel for Android users and provided us ideas on how to make it even faster!
Today, I’m pleased to announce that the JRebel for Android now includes an incremental compiler that makes the performance of code and resource updating even snappier.
When you use the default toolchain, specifically Android Studio and Gradle, there are two major tasks in the build process of an Android app that are not entirely incremental. First is the compilation of Java source files and the other is resource packaging. In this post, I wanted to share some details about the compilation aspect and how we made it incremental, what challenges still exist and where it can take you performance wise.
RebelLabs is the media partner for the Virtual JUG, the online Java User Group which brings you the best sessions by world class speakers. The best part? You don’t have to leave your house or office to enjoy them! You can educate yourself and become a better developer even from the comfort of your home!
This time I want to recap a magnificent session we had just recently: “Java 8 Puzzlers: The Strange, the Bizarre, and the Wonderful”. The speakers who brought it to our screens are two established experts in the Java community: Baruch Sadogursky and Viktor Gamov.
Well, if for the last ten years you haven’t been living under a rock, or not on the JVM, you probably have at least some experience with JUnit. You’ll know it’s the most used library to write unit tests in for Java projects.
JUnit is quite mature and is pretty good as libraries go, however recently, after the release of the JDK 8, the JUnit team worked hard and delivered a major rewrite of the test engine. One of the main syntactical reasons was to adopt lambdas, so you can write code that is full of them and benefit from unit tests that use a similar code style. However, the differences between JUnit version 4 (or older, if you’re still half under the rock) and the fresh version 5 do not stop there.