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.
Good developers care about performance. However, even the best developers don’t realize that performance tools are not a one-size-fits-all type deal, rather they’re components in a suit of armor. You see, a suit of armor has many pieces – a breastplate, a helmet, gauntlets, etc. – all of which are designed specifically for different parts of the body. We’ll be defining 4 major types of performance tools and which areas of the (figurative) body they’re designed for, and finally, honing in on the solution best suited for development.
This post continues our series of the most useful and beautiful cheat sheets from which software engineers can learn the most frequently used commands, idioms, and best practices on various topics.
Today, we’re talking about unit tests and JUnit, one of the most popular unit test libraries in the JVM ecosystem, including some of the really useful updates in JUnit 5, which brings the library up to speed with the new features in Java 8. Now, it’s very tempting to just grab the image, print it out and start looking for a place on the wall to pin it up. By all means, do it! But make sure you stay with us, and continue reading this post, as we’ll explain the content of the cheat sheet in much more depth. The cheat sheet will then serve as a visual hint for your future testing.
ZeroTurnaround is further improving the ease of use for JRebel’s Eclipse remote server users. The UI for remote server configuration has been redesigned to provide more precise control over projects.
Spring and Java EE are largely considered competing technologies. Our recent RebelLabs tools and technologies report asked whether which Java EE versions people used and whether or not they used Spring.
However, we’re trying to understand better what exactly developers mean when they say “I use Spring” or “I use Java EE.” Are we talking about the servlet classes being used underneath it all or the full blown profile? We’ll find it out by asking you for a little more detail in our new 5 question mini-survey.
We recently released the RebelLabs Java Tools and Technology report 2016. In case you missed it, we showed you the survey results from over 2000 fellow geeks. There were winners and losers in the report, but in this post, we’re going to focus on the success stories! First of all, here’s an image that shows 12 winners from the report that we were excited to tell you about.