Blog

Java is not dead…in fact, it’s got more than enough energy to kick your app in the butt. Too often, critics focus on niche issues and make unfair comparisons to other technologies or languages that do not have the same level of widespread use, applicability or history as Java. It’s like comparing a car to a carpet.

Children today are able to learn Java. It’s widely adopted among Web and Enterprise App producers. It has seen some amazing improvements in recent years and even more good stuff is on the way. But even excluding those latest additions, Java is still pretty darn cool: consider the widespread applicability and excellent engineering behind the JVM platform, the clarity of syntax, the rich ecosystem of tools and libraries and the fact that Oracle says there are over 9 million Java developers out there (and many billions of app/device users). So why do I hear remarks about Java being “on its way out” or, since back in 2007, that it is becoming “the Cobol of the 21st century”?

The Java platform is an engineer’s dream

First there’s the Java platform. The HotSpot JVM is a marvelous piece of engineering. It does stuff the CLR can only dream of and is so heavily optimized that often Java apps can even match the performance of C programs. Also, there is quite a selection of other virtual machines available (such as JRockit, Zing), should your environment have some specialized requirements.

Secondly there’s a multitude of JVM-based languages, which makes the platform even more amazing. It goes way beyond the famous ones like Groovy, Jython, JavaFX and Scala. Java now includes such treats like invokedynamic opcode and the java.lang.invoke package, making it easier to build dynamic languages for the JVM. There’s already a line up of over 50 JVM-based languages, one of the most interesting ones being php.reboot, which aims to keep the philosophy of PHP but remove its shortcomings. And it also works for Android, too.

Java is mature, but not a language for old people

Java as a language has been the target of much criticism, whining and cursing. I say the language is not dying or Cobol’ish either, quite the contrary. When complaining about Java and recommending better alternatives, people often use strange comparisons. Some people seem to think that Java is still in version 1.4, written in Notepad and requires EJB2 to write a simple guestbook. It is then compared to a high level framework or even a CMS!

As a Java developer, this comparison doesn’t make any sense to me. It is wiser to compare how Java measures up to more intelligently-chosen contestants…How about pure Java vs pure PHP, Python or Ruby? Or comparing the Play! Framework vs Ruby on Rails? Or Spring MVC vs Zend Framework? When put in this light, I feel that Java does not seem like a “language for old people” anymore.

Java is verbose? Of course it is!

People say Java is so verbose, and it slows them down. Critics often refer to the strong static typing and lack of bleeding-edge features in the language. However, I believe this is actually deliberate and a good feature of Java.

Dynamic languages are popular when starting a new small project, but consider this – with the help of modern frameworks and proper tools (i.e. consider using an IDE instead of Notepad), creating a “Hello Guestbook” type of application in Java is a simple, 10-minute affair.

If you want to test that, try Spring Roo and use a stopwatch if needed. Now, let’s take a step outside the trivial CRUD matrix used by cool languages and frameworks in their marketing talk.

Imagine you’re building a system for a mobile carrier and want to allow clients to sign up on their website. You will have to collect a lot of data and possibly invoke various subsystems in the backend. Cool frameworks often break down the minute your program model does not match the user model anymore. For more, I can recommend this wonderful post on that topic by Joel Spolsky.

Java is strong with static typing

Strong static typing has many benefits. I love its simple visual appearance. I can glance at a piece of code and usually figure out immediately what’s going on. It’s like the visual feedback in English – the lgnaugae is so esay to raed taht the lettres can be miexd up isinde wrods, and it’s sitll redaalbe.

Some other benefits of the type system include strong IDE support. Dynamic languages will always be at a disadvantage here. Having a simple, no-nonsense language in a huge project with great IDE and tooling support is priceless. Nothing else comes even close IMHO.

Critics have a point that Java may lack some of the expressiveness when reading a file, transforming xml or iterating through a collection, but you can always create a sub method to handle common cases, or use FileUtils.readLines(). There is also a huge number of libraries available for Java that handle most of the “expressiveness shortcomings” of the language.

Java 7 saw some neat enhancements such as auto-closable resources, String support in switch statements and underscores in numeric literals (I urge you to read up on project Coin). Java 8 promises even more (most interesting part being closures).

The takeaway here is that the language is getting some fresh blood. However, the features will not be some experimental ideas which may or may not be around in two years, but proven and mature concepts. This does not mean the philosophy is mutually exclusive with having fun when programming. It isn’t.

A Fanboy Rests His Case

Is everything about pure Java perfect and justifiable? Of course not. And that is why there is Java 8 in the works. And Java 9. What I personally dislike most about Java is the not-so-smooth core API, and there is a debate whether this has actually more to do with the platform than the language. The core contains the evolution of API design spanning two decades, and modernizing it all will break backwards compatibility. Some parts are too abstract, some not abstract enough. Some bits are too fragmented. Some are just plain weird. Looking at the competition, the core API could do well with the unified communications API like .NET for example. Java 8, with the help of project Jigsaw, may change that.

So there you have it. Pure Java, used properly, is an awesome language. Even more so than Klingon. It will continue to improve and will not go away anytime soon. The effort should not be on replacing pure Java, but using it together with other JVM languages where it makes sense. But for my next Pet Clinic, I’ll stick with Java.

***

P.S… An Example of Java in Use

This article, like Java, is a bit verbose, so I’ll leave this example for any readers who want to continue.

Say you need to build a web application and you need control over the html output or http requests. Consider the stack of pure Java, Spring MVC and Hibernate. Yes, it’s an old combination, almost like a cliche, but it works beautifully. It has many benefits and little downsides, most of which can be eliminated with a little help from your tools.

Writing Java code is fast when using a modern IDE (Eclipse, Netbeans, IntelliJ). All of them have code completion and shortcuts that take much verbosity-related angst out of your day. Using relatively modern (i.e. less than 3 years old), versions of Spring and Hibernate, you don’t need to write five miles of xml to have red buttons with rounded corners (it has never been that bad but people love exaggerating). You can use annotations most of the time. Even when you need applicationContext.xml, using a Spring IDE plugin makes that a breeze. With JEE 6, you don’t even need a web.xml. Even if you have to use an older servlet spec, IDE will generate web.xml for you. It can generate a project layout and add servlets just like Grails’s command line console, but better.

The last bit you might complain about is the turnaround. Making a small change and seeing the result has always been fast in PHP, but not so much in Java. Again, tools are there to help you. Without tooting our own horn, JRebel, for example, will instantly reload classes in the running application regardless of your stack. Same goes for refreshing Spring and Hibernate configuration. It goes even further by mapping resources between the workspace and the deployed application. This makes your life easier when working with static resources too – you don’t need to copy jsp’s to the right place or run any build script to see the changes. Just press ctrl-s.

You get to keep all that’s good about Java. In short – you’ll have the best of both worlds.

That’s pretty big news.  JRebel for free?

Now, you may be thinking,

“But how can a company that survives off of their JRebel revenue (and employs >25 people) release a free version of the productivity tool? It even won a bunch of awards (JOLT Productivity Award, JAX 2011 Most Innovative Java Technology, Estonian Innovation 2011, and one more we can’t talk about yet)! Is their management team totally crazy?”

Here’s some background:

Imagine if those 9 million developers code on projects for 5 hours per day, over a 20 day period. That’s 900 million work hours, in what vaguely represents a month of work. JRebel could save 153 million hours of wasted time, per month, if every java developer in the world was using it. That’s more than 17,000 years of development time saved, every month. But JRebel costs about $1 per developer, per day – so some people can’t afford it. We want to change that. For about a year now, we’ve been thinking about different ways that we could give away JRebel for free – with one caveat – we can’t cannibalize our revenue and bankrupt the company — after all, we’ve got customers to think about, support cases to handle, and lots of new features to add – if we can’t do that stuff, then we’d be letting a lot of people down, and no one wants that. So our thoughts were… do we release a free version of JRebel…

  • …with a limited feature set? If so, how do we separate the features?
  • …for a limited amount of time?  We already offer a free 30-day evaluation…
  • …and ask for donations?
  • …that is free for a certain audience?  If so, what audience?  Hmmm… maybe we’re on to something here….

Introducing JRebel Social

JRebel Social is free to use for non-commercial development, and the only thing you need to do to use it, is let your network know it exists, once per month. Simply login and register using your Twitter or Facebook account and then pickup your online or offline license keys. As icing on the cake, you can see how much time you’ve saved by eradicating redeploys (and builds) from your Java development process, on your personal dashboard. You need to Download JRebel 4.5 to connect to Social. Try it out, and let others know what you think: https://social.jrebel.com I’m personally curious to see what will come of the thousands of hours that JRebel Social will save for the Java industry this year.. feel free to let me know what you’ll do with the extra time!

Click me for details on the 4.5 release.

David

Oh PS — we’re hiring! Engineers & Developers in Estonia, Marketing in Prague, and a Sales Team in Boston. Feel free to email us at jobs@zeroturnaround.com or Join The Rebellion

Some time ago we ran a survey asking a few questions about the build process, specifically the tools that are used to do incremental builds and how much time those builds take. We had over 600 responses, so now it’s time to count the results.

This is the first time that we’ve published results on the incremental build process, so the information is more likely to serve as a guide than an authoritative information source. That being said, the information is still quite interesting, and if it serves to start a conversation that improves the process of even one team, then we’re proud to have helped out. If you haven’t answered the 3-question survey yet, take two minutes and go for it – and do let your community know about it – as more answers trickle in we’ll update this post with the new data. If you’d like to play with the results on your own we‘ve provided all the data and our calculations in a handy Excel sheet that you can download here.

(more…)

How to install and use JRebel (formerly JavaRebel) in GlassFish with Eclipse IDE

In the recently published Java EE Container Restart & Redeploy Report, the GlassFish v2 application container was the best of the fully fledged Java EE containers in the terms of time spent redeploying. That’s the good news. The not so good news is that on average respondents report spending 14% of their coding time waiting for server redeploys/restarts. That’s just over 170 hours annually, per developer – approximately 4.3 full weeks of development time. JRebel eliminates the need to redeploy in about 80% of redeploy situations – and it’s easy to get started. This tutorial explains how to install and use it step-by-step.

Here we assume that you are using Eclipse 3.x with GlassFish v2. Most of the steps will be applicable to other versions as well, but it may look different from the screenshots included.

NOTE: Although GlassFish is tightly integrated with NetBeans, the JRebel support for that IDE is in Beta at the moment – for now, we recommend using Eclipse or IntelliJ IDEA instead. We’ll make sure to announce when better NetBeans support is available (it’s coming soon).

First, take a quick look at how coding looks when using JRebel (formerly JavaRebel).

Contents:

STEP 1: Install JRebel

The latest stable version of JRebel can be downloaded here. Unpack it to a directory of your choice.

2009-07-03_124429

STEP 2: Installing JRebel Eclipse IDE plugin

The JRebel Eclipse IDE plugin was introduced with JRebel 2.0 and makes configuring and using JRebel considerably easier. You can install the plugin by going to Help » Software updates » Available software » Add site and use the http://www.zeroturnaround.com/update-site/ URL as the update site.

2009-07-15_142449

STEP 3: Make a rebel.xml for your application

In order to do it’s magic, JRebel needs to know where your classes and resources are. We’ll use a rebel.xml configuration file to tell it. This is mandatory when you deploy your app as a WAR/EAR. You’ll need to have one rebel.xml file per module. This includes both web and EJB modules. The rebel.xml configuration file should be placed in your WEB-INF/classes directory in the case of a web module and in the jar root in the case of an ejb module. Put it in the root of a source or resource folder in your project (the same place where the .properties files are).

If you use Maven you can use the JRebel Maven plugin that will generate the rebel.xml in accordance with the module pom.xml as described in the Maven Plugin configuration manual.

In 99% of cases, people tend to use one module per project. In these cases, the JRebel Eclipse IDE plugin can generate the rebel.xml file for you, on a per project basis. If your project is one of the exceptions, edit the file manually as described in the Installation manual, otherwise generate the rebel.xml like this:

Click on your project and pick Generate rebel.xml

2009-07-15_143501

STEP 4: Configuring the Eclipse WTP IDE

You may skip this step if you run GlassFish outside of the Eclipse IDE.

Open the Servers View and double click the GlassFish v2 that your application is deployed to (if you don’t see the Servers View go to Window » Show View » Servers).

2009-07-15_140106

Open Publishing and choose Never publish automatically.

2009-07-15_135824

It may seem wrong to disable automatic publishing, but as JRebel will take care of updates from now on it will just slow you down.

STEP 5: Configuring Eclipse IDE

Go to Window » Preferences and from there to Java » Debug » Step Filtering. Check Use Step Filters and Filter synthetic methods and Step through filters. Now check all the default filters and use the Add Filter button to add com.zeroturnaround.* and org.zeroturnaround.*.

2009-07-03_143321

Now go to Project » Build automatically and make sure it is checked.

2009-07-03_144612

STEP 6: Success!

To check that the installation was successful access a page that uses a class, change that class in the IDE, press Save, access the page again and look for the following message in the console:

2009-07-15_142301

Now that you’re up and running, it’s time to enjoy coding without the need to redeploy. If you have any specific questions JRebel, the Forum is the best place to ask, so that other people get to hear the answer as well. Otherwise, you can contact us at support@zeroturnaround.com.

If you like what you see, please give us a quick mention on your blog or twitter (you can even follow us here).

Have a great day!

Find out more:

We’re looking into incremental builds — trying to document the differences in popularity & productivity between using tools like Ant and Maven versus IDEs.  We haven’t seen a study like this before, so thanks for taking a minute to fill this out.  If you’re interested in winning a free license of JRebel (formerly JavaRebel), include your email address in the optional email section.

For the study, click here.

Thanks,

Dave

Although this tutorial concerns the Tomcat container, exactly the same instructions also can be used for JBoss and Jetty containers.

Compared to other containers out there, the Tomcat web container is one of the fastest when it comes to startup and redeploy times. Still, in a survey we conducted, developers estimate spending 18% of their coding time (about 145 hours annually, per developer – somewhere between 3-4, full, 40-hour workweeks) waiting for applications to redeploy. JRebel eliminates the need to redeploy in 80% of situations, and it’s easy to get started. In the embedded video you can take a quick look at how coding looks when using JRebel.

Tutorial

In this tutorial we explain how to install and use it step-by-step. We assume that you are using Eclipse 3.x with Tomcat 5.x or later. Most of the steps will be applicable to other versions as well, but it may look different from the screenshots included.

Contents:

STEP 1: Install JRebel

The latest stable version of JRebel can be downloaded here. Unpack it to a directory of your choice.

2009-07-03_124429

STEP 2: Installing JRebel Eclipse IDE plugin

The JRebel Eclipse IDE plugin was introduced with JRebel 2.0 and makes configuring and using JRebel considerably easier. You can install the plugin by going to Help » Software updates » Available software » Add site and use the http://www.zeroturnaround.com/update-site/ URL as the update site.

2009-07-15_142449

STEP 3: Make a rebel.xml for your application

In order to do it’s magic, JavaRebel needs to know where your classes and resources are. We’ll use a rebel.xml configuration file to tell it. This is mandatory when you deploy your app as a WAR/EAR. You’ll need to have one rebel.xml file per module. This includes both web and EJB modules. The rebel.xml configuration file should be placed in your WEB-INF/classes directory in the case of a web module and in the jar root in the case of an ejb module. Put it in the root of a source or resource folder in your project (the same place where the .properties files are).

If you use Maven you can use the JavaRebel Maven plugin that will generate the rebel.xml in accordance with the module pom.xml as described in the Maven Plugin configuration manual.

In 99% of cases, you probably use one module per project. In these cases, the JavaRebel Eclipse IDE plugin can generate the rebel.xml file for you, on a per project basis. If your project is one of the exceptions, edit the file manually as described in the Installation manual, otherwise generate the rebel.xml like this:

Click on your project and pick Generate rebel.xml.

2009-07-15_143501

Repeat this for all projects that you’d like to update with JRebel.

If you’d like to use one rebel.xml for your whole team, start with the generated rebel.xml, then replace the absolute paths to your workspace with a system property. JavaRebel will expand expressions like “${myProject.root}” in rebel.xml to a system property that you can pass to the application container as -DmyProject.root=c:/myWorkspace/myProject. This allows to you to use a single configuration for everyone and then customize it when starting the server.

STEP 4: Configuring the Eclipse WTP IDE

You may skip this step if you run Tomcat outside of the Eclipse IDE.

Open the Servers View and double click the Tomcat Server that your application is deployed to (if you don’t see the Servers View go to Window » Show View » Servers).

2009-07-15_144828

Open Publishing and choose Never publish automatically.

2009-07-15_144654

It may seem strange to disable automatic publishing, but as JRebel will take care of updates from now on it would just slow you down.

Open JavaRebel Integration and check Enable JavaRebel agent.

2009-07-15_145028

STEP 5: Configuring the Eclipse IDE

Go to Window » Preferences and from there to Java » Debug » Step Filtering.

Check Use Step Filters, Filter synthetic methods, and Step through filters. Now check all the default filters and use the Add Filter button to add com.zeroturnaround.* and org.zeroturnaround.*.

2009-07-03_143321

Now go to Project » Build automatically and make sure it is checked.

2009-07-03_144612

STEP 6: Success!

To check that the installation was successful, access a page that uses a class, change that class in the IDE, press Save, access the page again and look for the following message in the console:

2009-07-15_150006

Now that you’re up and running, it’s time to enjoy coding without the need to redeploy. If you have any specific questions JRebel, the Forum is the best place to ask, so that other people get to hear the answer as well. Otherwise, you can contact us at support@zeroturnaround.com.

If you like what you see, please give us a quick mention on your blog or twitter (you can even follow us here).

Have a great day!

Find out more:

Though JRebel does not depend on any IDE or development tools in particular, (besides a compiler) it’s nice to have tight integration with your IDE. Enter – the JRebel Eclipse Plugin. Remember: as long as you overwrite your old class files with new ones, JRebel will reload your changes and cut down on time spent redeploying.

Please see the updated tutorial here.

There has been a lot of discussion regarding the use of JavaRebel with Eclipse Web Tools Project (WTP). JavaRebel does work with WTP but the configuration is not that straightforward. In this article we’ll try to give step by step instructions on how to make WTP and JavaRebel get along.

The article is divided into two parts. If you have JavaRebel installed under WTP you can skip to the configuration section. If you are an old time WTP user just enable autopublishing and disable auto reloading for modules.

JavaRebel Installation under WTP

Lets get started by downloading the JavaRebel zip archive from the download page. Unzip the archive somewhere on your harddisk. Copy the javarebel.jar from the uncompressed folder to a location that you can use later on. We’ll assume on Windows that this is c:\javarebel.jar and on Linux /home/john/javarebel.jar.

We’ll configure the startup of the container next. I will be using Tomcat v6.0 version. Open up the “Run Configurations” dialog from the Eclipse menu Run » Run Configurations. You should see the following dialog.

Click for original size - Run Configurations dialog

Next open the (x)= Arguments tab in the dialog and edit the VM arguments text area as seen on the next screenshot. Add the following option to the end of the area.

Windows
-noverify -javaagent:c:\javarebel.jar

Linux
-noverify -javaagent:/home/john/javarebel.jar

Click for original size - Run Configurations JavaRebel Configured

Now apply the settings and run the configuration. You should see the following message in the console output.

Installation Confirmation

You have installed JavaRebel under WTP now. Next you need to configure some WTP options so that WTP auto publish would not interfere with JavaRebel class reloading.

Automatic publishing should be enabled in the server configuration. Double click on your server name and a configuration page opens. Under the Publish section you should have the Automatically publish when resources change option selected. I’ve outlined the automatic publishing settings in the following screenshot.

Click for original size - Automatic Publishing Settings

All your modules should have Auto Reload disabled. You can achieve this by opening the Modules tab of the server configuration and editing each module to disable auto reloading.

Click for original size - Disable Auto reloading

This is it. Once you have these configurations in place and you have restarted the container you are ready to use JavaRebel with WTP.

Make changes to your Java source files and they will be reloaded by JavaRebel. Make changes to your static content under you WebContent and they will be copied by WTP to your deployment folder.

If you have any questions or problems about setting up WTP and JavaRebel leave a comment or send an email to support [at] zeroturnaround.com.

Eclipse 3.4 and WTP 3.0 were used to test the functionality. The article is inspired by Utilisation de JavaRebel avec Eclipse.

Join the Rebellion Facebook Twitter RSS feed