Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

JRebel Remoting to Push Changes to Your Toaster (in The Cloud)

In late November, we announced that JRebel Remoting will be available for SAP Netweaver Cloud. That little announcement marked a major milestone in our efforts during the last year: namely, that we have added support for JRebel Remoting to all the major app servers and all the major IDE’s.

Our next goal is making JRebel Remoting available in all kinds of cloud environments such as Amazon EC2 (it’s done, try it), SAP Netweaver Cloud (we’re in beta), Heroku (it actually works), Jelastic, CloudBees, CloudFoundry and OpenShift.

With JRebel Remoting in the mix, you can enjoy instant reloading of class files, resource files and framework configuration, either locally or remotely. But we won’t be satisfied until JRebel Remoting can push changes to your toaster (once it starts running Java).

In the past, the cloud prevented you from using JRebel to reload classes in a running application. But not anymore: with JRebel Remoting, you can push changes to a remote server right from your favorite IDE (unless it’s notepad), using the same HTTP channel that the browser uses for accessing it (even through proxies). This means you only need to copy paste the URL from the address bar to an IDE and start breaking changing stuff. No complex configuration, no holes to poke into firewall.

Why Bring JRebel to “The Cloud”

We believe “the cloud” can significantly simplify developing and delivering software for companies both small and large. Why is that? Well moving your stack to the cloud can help you:

  • Optimize your OPEX by removing the overhead of managing your own hardware infrastructure
  • Gain the flexibility you need to handle short term spikes in usage. No longer need you spend gazillion dollars on the fancy server since for an e-card service because there are 100 million users at thanksgiving and a whopping 7 for the rest of the year.
  • For small startups, this means you can buy a domain and be up and running with minimal costs in 30 minutes (majority of which is taken by DNS propagation). Compare this to a period 20 years ago when you could buy a house with the money required to set up a web server .

We know that the cloud is by no means perfect, and in addition to concerns about privacy and security, updating your apps in the cloud may not be as straightforward as it could be. For Java apps, you will have to compile and build it, upload the files and restart the app server. You can mitigate this to some degree by also running the server on your own machine, but cloud environments offer increasingly more services for your application to make use of, especially the PaaS offerings. This can effectively prevent testing on a developer’s machine.

Even more, as applications get larger and larger, running them places even greater demands on the developer’s machine resources. You can use a netbook to run Eclipse and write the code, but often you need a quad-core with a petabyte of RAM to deploy it. That is why you may find it convenient to test on the cloud also. At my last company, for example, we had to buy brand new computers for the whole team because we needed to develop stuff using a well-known portal. (Confession: I was actually glad at that time, because engineers love shiny new toys!)

Here is what we have so far for getting started with JRebel Remoting:

We really hope you get the most out of JRebel Remoting….and if you have Java EE certified toaster (can be Web Profile), please let us know. We have a promise to fulfill.