Hi, I’m Sten the Product Manager of JRebel for Android.
As a team, we’ve made the decision to halt active development on JRebel for Android. All JRebel for Android Free version users can continue using the product until March 31, 2019. However, we will not be accepting any new users.
Enterprise license users can continue using JRebel for Android until the license expires. And, as promised, we’ll also continue adding annotation processors for our Enterprise customers. We will continue integrating new Android Studio, Android Gradle Plugin, and Gradle versions throughout this time. However, we will not be building new features or working to further optimize the build process.
We would like to thank everyone who has been part of this awesome journey for the past three years. It has been challenging and fun. For those who are interested in the history, here’s a recap of how JRebel for Android came to be.
JRebel for Android started three years ago with the porting of our legacy JRebel core to Android. Our very first proof of concept worked on Eclipse and ANT projects. By spring 2015, we had moved to Android Studio and Gradle, and announced our private beta program. It was by far the most successful beta launch we had with almost 1000 sign-ups registered in the first 24 hours.
We spent the late spring and summer of 2015 to get our code reloading technology on Android as solid as possible. Back then, we didn’t focus on what happens before in the build process. We gathered feedback and sent out Beta invitations in regular batches. By autumn 2015, we had the confidence to start figuring out the go-to-market plan. Our initial offering consisted of annual Individual and Business subscriptions. The first sales came in very quickly.
A lot of those deals came from existing JRebel customers. Once bigger companies started adopting the tool, the hard reality of slow build times started to hit us. We worked hard to reduce the initial installation overhead. But we knew that we’d need to look into the build process a lot more.
JRebel for Android 1.0, looking into the build process
In late 2015, we also decided to launch JRebel for Android 1.0. We adjusted our Individual license pricing to increase the market presence. Google had just announced Instant Run in Android Studio and we felt the need to react. We gained new visibility and presence in the Android community.
By this time, we had discovered that a lot of the steps in build process were not incremental. We detected three major bottlenecks. The first to tackle was configuration time. This is the time needed to generate the Gradle tasks and understand the project layout. We did quite a clever trick: By starting the Gradle task in the background, it would complete the configuration phase and continue once the user decided to “Apply changes”. Eureka, it worked!
But we knew this wasn’t enough. We also saw a drop-off in product sales, with many deals lost because the product wasn’t fast enough. We had the option to pick between working on the Java compiler or Android resources packaging. In early 2016, the Java compiler looked like a better bet and we went forward with it. Although Gradle had incremental Java compiler behind a flag, it did not support annotation processors. By talking to our users and understanding their projects, we knew annotation processors had to be supported. Dagger, Dagger2, Butterknife, and many more were becoming popular.
JRebel for Android 2.0
Getting the incremental compiler in good shape and testing it with new customers took up most of 2016. By October 2016 we introduced this to a larger customer base and launched JRebel for Android 2.0. We also worked hard on reducing the memory footprint during runtime. Code reloading was looking solid. It looked like once the Android resources packaging was solved, the build times would scale, and there would be no slow scenarios independent of whether you were changing code or resources.
Android resources are packaged with a tool called aapt. In the summer of 2016, Android Developers Backstage hosted a talk on aapt2 becoming incremental. We had played around with the thought of building our own from scratch, but this was no longer feasible. aapt2 was shipped as a binary in early 2017, but it was lacking the Gradle integration. It did not look like it would ship any time soon. So, we built the integration for JRebel for Android ourselves.
JRebel for Android 2.5
We continued to experiment with our go-to-market strategy and opted to launch JRebel for Android 2.5 in April 2017. It had become evident that our Individual license was creating more friction for ourselves and the customers. As a company in general, we moved more towards bigger enterprise customers. We dropped the Individual license and replaced it with a completely free version. The reception for the free version was good, but as it didn’t include the incremental Java compiler or aapt2, it would bring the most value only for smaller projects.
So, now it’s down to the Enterprise offering, but the business impact doesn’t justify the investment. The Android ecosystem is still quite young and continuing to develop rapidly. Introduction of Kotlin with kapt (to support annotation processing on Kotlin), D8 dexer, and Java 8 with desugar has once again put us into the position where we have an extensive backlog before we can offer a product with true value for our enterprise customers.
So, with looking at our business metrics, we have decided not to continue to invest in JRebel for Android. But our team is solid, and we’ll all focus on our core Java products JRebel and XRebel APM.
Thank you, and rest in peace, JRebel for Android
We as a team are super proud of the product we have built. We have taken on massive challenges and we have worked with awesome customers. We would like to extend our sincere gratitude toward everyone who has taken the time to provide us with valuable feedback — be it bug reports, interviews, tweets, reddit comments, or other.
If you have any questions, please write to us in the comments or reach out to me directly.