Skip to content

WildFly Swarm applications can be deployed to Heroku, simply by adding a few files to the deployment. In this post, I'll show the changes that are needed to be made to a WildFly Swarm application and how to then deploy the application to Heroku. I'll show how to deploy my Fruits example WildFly Swarm application to Heroku. The source for this application can be cloned from GitHub at https://github.com/doobrie/swarm-rs

Creating a Heroku Application

Assuming that you've got the Heroku Toolbelt installed, creating a Heroku application is a matter of opening a command prompt/terminal in the root of a WildFly Swarm project (for this example, a Maven project), and executing the heroku create command.

$>heroku create
Creating app... done, stack is cedar-14
https://mighty-temple-xxxxx.herokuapp.com/ | https://git.heroku.com/mighty-temple-xxxxx.git

This creates a Heroku application, adding a git remote, heroku, ready for deploying your application.

Defining the Java Runtime

Heroku can automatically determine that your application is Java based, but needs to be told which version of Java to run. To define this, create a file called system.properties in the root of the project containing a single line indicating the version of Java required.

java.runtime.version=1.8

How To Execute The Application

Heroku uses a Procfile to determine how your application should be executed. This file should also be located in the root of your project. To run a web application, we need to tell Heroku to run a Web Dyno. We also need to tell it what command to run and what port to run on.

In Heroku, the port that applications must listen on is defined by the $PORT environment variable. A default WildFly Swarm application runs on port 8080, but this can be changed by adding the `swarm.http.port` environment variable. To execute a WildFly Swarm application, the Procfile should look something like

web:    java -Dswarm.http.port=$PORT -jar target/swarm-rs-1.0-SNAPSHOT-swarm.jar

Since we're running a WildFly Swarm "fat" Jar, there are no additional class path entries required - all that is needed is the name of the Jar file containing the application, swarm-rs-1.0-SNAPSHOT-swarm.jar in this example.

Deploying The Application

That's all that is required to get going with Heroku and WildFly Swarm. You can see that we've made no changes to the application itself other than adding a system.properties file to determine which Java runtime to use, and a Procfile to define how to start the application.

To deploy the application on Heroku, ensure these files are added and committed to the local Git repository and then push the changes to Heroku.

$>git push heroku master

remote:        [INFO] ------------------------------------------------------------------------
remote:        [INFO] BUILD SUCCESS
remote:        [INFO] ------------------------------------------------------------------------
remote:        [INFO] Total time: 01:14 min
remote:        [INFO] Finished at: 2016-02-07T21:49:57+00:00
remote:        [INFO] Final Memory: 36M/389M
remote:        [INFO] ------------------------------------------------------------------------
remote: -----> Discovering process types
remote:        Procfile declares types -> web
remote:
remote: -----> Compressing...
remote:        Done: 96.9M
remote: -----> Launching...
remote:        Released v4
remote:        https://mighty-temple-xxxxx.herokuapp.com/ deployed to Heroku
remote:
remote: Verifying deploy.... done.
To https://git.heroku.com/mighty-temple-xxxxx.git
 * [new branch]      master -> master

To verify that the application works, browse to the /api/fruit Url of the application. The Url of the application is displayed on the console after pushing to Heroku.

Conclusion

I've given an overview of how to deploy WildFly Swarm applications to Heroku. Hopefully you'll agree that this is a straightforward process that allows you to be quickly up and running on Heroku.

Last week, a new version, 1.0.0.Alpha6 of WildFly Swarm was released. One of the main features of this release, from a development point of view, is the simplified handling of dependencies within a project's pom.xml file.

All of the artifactId values for WildFly Swarm dependencies have been simplified from wildfly-swarm-artifactName to simply artifactName

Recently, I showed how to create a simple JAX-RS application using WildFly Swarm. With the previous version of WildFly Swarm, 1.0.0.Alpha5, the JAX-RS Swarm dependency was defined as:

<dependency>
  <groupId>org.wildfly.swarm</groupId>
  <artifactId>wildfly-swarm-jaxrs</artifactId>
  <version>${swarm.version}</version>
</dependency>

Now, with version 1.0.0.Alpha6 of WildFly Swarm, the dependency looks like:

<dependency>
  <groupId>org.wildfly.swarm</groupId>
  <artifactId>jaxrs</artifactId>
  <version>${swarm.version}</version>
</dependency>

It's a relatively small change, but it makes the pom.xml file more compact and readable.

I've updated my sample JAX-RS application on GitHub to support this latest version of WildFly Swarm.

A new Darcula theme based upon the Darcula Look and Feel for IntelliJ has been released as a plugin for NetBeans.

This new plugin can be installed via the NetBeans Tools | Plugins option so there is no need to manually download the plugin to install it.

After installing the plugin, NetBeans needs to be restarted. Probably the first thing you notice after installation is that the editor window still retains the existing NetBeans colour scheme. The can be changed to a dark look and feel, for example, by using the Norway Today profile. After specifying this profile, you can customize the colours used within the editor window exactly how you like them, whilst retaining a full dark look and feel.

I really like this plugin. There are still some issues with it, for example the --fontsize NetBeans parameter doesn't work with it, however that doesn't detract from the use of the plugin which I now enable on all my NetBeans installations.

I’m proud that Packt Publishing have announced my latest book – NetBeans IDE 8 Cookbook.

We’re expecting that the book will be available in November this year, however you can now make pre-orders for the book in either print or e-book format.

The book is an easy-to-follow, recipe-based guide to using NetBeans for Java development. Each recipe is designed to help you maximize your producitvity while using NetBeans. Tips provide real-world advice in conjunction with the recipes’ explanations.

For more information on the book, check out Packt’s details page.

J2SE 5.0 has been available for download since the end of 2004. This new release included many changes and enhancements to the Java platform such as speed and stability. Additionally, some changes were made to the Java language itself. These fairly major changes made to the language are:

  1. Generics
  2. Enhanced for loop
  3. Annotations (sometimes called metadata)
  4. Autoboxing and unboxing
  5. Typesafe enumerations
  6. Variable arguments (varargs)
  7. Static imports

Using these new language features in your applications can have a big effect on your code, so this article aims to provide an overview of these new features so that you can start leveraging them in your code. As a Java developer I make extensive use of these features now and find that they bring the Java language much more upto date.

Generics

The latest version of J2SE could have a collection of any type of object). Prior to Java 5, if you wanted to extract the contents of a collection, you would use code such as that below:

import java.util.*;

public class Generic {

    public static void main(String[] args) {
        // Create a collection and add some items to
        // it.
        Collection languages = new ArrayList();
        languages.add(“Java”);
        languages.add(“C#”);
        // Now get the items from the collection.
        Iterator iterator = languages.iterator();
        while (iterator.hasNext()) {
            System.out.println(
                (String)iterator.next());
        }
    }
}

Notice that to extract objects from the collection, we have to explicitly cast the retrieved objects to be Strings (or whatever class the collection consists of), potentially allowing us to get the dreaded ClassCastException if we had inadvertently added the wrong type of object to the collection in the first place. Also, its difficult to see from looking at the code what the collection contains. If there was an API method like the following, what exactly would the collection contain?

public doStuff(Collection items);

Using generics, our simple application can be re-written to get rid of the cast and made type safe.

import java.util.*;

public class Generic2 {

    public static void main(String[] args) {

        // Create a collection and add some items to it.
        Collection languages = new ArrayList()<String>;
        languages.add(“Java”);
        languages.add(“C#”);

        // Now get the items from the collection.
        Iterator iterator = languages.iterator();
        while (iterator.hasNext()) {
            System.out.println(iterator.next());
        }
    }
}

You can see that the collection has been explicitly declared to contain only String objects. Also note, that there is no cast required to extract items from the collection. The VM knows exactly what type of object is in the collection and knows how to return it to the calling application. If we tried to put something into the collection that isn’­t of the required type (in our small example, anything other than a String), then the code will simply fail to compile.

If we now re-wrote our rather obscure method doStuff, it may look something like the following. Here we can see exactly what type of object the collection contains.

public doStuff (Collection<String> items)

Enhanced for Loop

The enhanced for loop construct available in Java 5 allows us to refine this code even further and remove the need for using the Iterator to loop through the collection. This construct allows our simple application to be re-written, yet again, as:

import java.util.*;

public class Generic3 {

    public static void main(String[] args) {

        // Create a collection and add some items to it.
        Collection languages = new ArrayList()<String>;
        languages.add(“Java”);
        languages.add(“C#”);

        // Now get the items from the collection.
        for (String language : languages) {
            System.out.println(language);
        }
    }
}

This new construct is declaring that the code should loop through each entry in the collection languages. Each entry in the collection will be declared as a String called language which is then printed out to the console.

Hopefully you'll agree that these new features of Generics and the enhanced for-loop allow Java developers to write cleaner and safer code.

Annotations

Annotations provide a new feature to the Java language that potentially allow a vast amount of time to be saved when developing applications. They’ve been available in C# from the beginning and are now available to Java developers.

Annotations allow developers to add “hints” into their code (in a similar fashion to Xdoclet or JavaDoc tags) that the compiler can interpret at compile time. This allows the build process to do a variety of things such as produce artifacts that would otherwise have to be manually created, or to check that code complies with certain criteria.

There are 3 annotations that are supplied with J2SE 5.0, but developers have the ability to write additional annotations if they desire. These 3 basic annotations are @Override, @Deprecated and @Suppress.

@Override is applied to methods and is used by the compiler to check that overridden methods are declared correctly. A simple example of this would be to apply it to the toString() method of a class. @Override checks that the method to which it is applied correctly overrides its parent object. If the method is overridden incorrectly (e.g. it is spelt incorrectly or has the wrong signature) then a compile time error will be generated.

public class Annotation1 {

    @Override
    public String toStrng() {
        return “…”;
    }
}

In this code fragment above, the method toString() has been declared incorrectly, e.g. public String toStrng() – note the deliberate spelling mistake. The @Override tag causes an error to be issued at compilation time.

C:>javac Annotation1.java
Annotation1.java:3: method does not override a method from its superclass
@Override
^
1 error

@Deprecated is applied to methods in a similar fashion to @Override. This annotation will cause a compiler warning to be issued if a deprecated method is used. Finally, @Supress is used to tell the compiler to suppress specified warnings.

The use of annotations is particularly of importance in the J2EE arena and is becoming more important in the strive to make J2EE easier. A couple of examples of this are Webservices (JAX-WS 2.0) and Enterprise Java Beans (EJB 3). The J2EE 1.4 way of creating web service and EJBs involves creating several different interfaces and various verbose XML configuration files that describe the webservices and EJBs being developed. With JAX-WS annotations, it will be possible to declare that a class should be exposed as a web service simply by putting a @WebService annotation before the class declaration. With EJBs its very similar. To declare a class as a stateless session bean is simply a matter of putting the @Stateless annotation before the class declaration. Of course there are more options that can be added into web services and EJBs to control their behaviour, but the fundamental principal is that all these options can be specified in code as annotations.

Autoboxing / Unboxing

Autoboxing and unboxing allows Java code to automatically convert between the basic primitive types (int, long, double etc) and their class equivalents (Integer, Long, Double etc.) and vice-versa. Prior to Java 5, if you needed to convert an Integer to an int, the code required would look something like:

public class Autoboxing {

    public static void main(String[] args) {
        int value = 10;
        Integer newValue = new Integer(value);
        Autoboxing ab = new Autoboxing();
        ab.doStuff(newValue);
    }

    public void doStuff(Integer value) {
        System.out.println(value);
    }
}

In this code, the wrapper class newValue has to be directly instantiated from the variable value to be passed into the method. With Autoboxing, this is no longer required as the int will be converted into an Integer for us:

public class Autoboxing2 {

    public static void main(String[] args) {
        int value = 10;
        Autoboxing2 ab = new Autoboxing2();
        ab.doStuff(value);
    }

    public void doStuff(Integer value) {
        System.out.println(value);
    }
}

Static Import

Static imports are probably one of the least used features available to Java 5. They allows you to specify static variables in another class without having to specify the fully qualified name of the class being imported. Members can be statically imported into a class using the import static construct.

import static my.class.static.member;

Summary

Java 5 introduced new language features that allow developers to write code that is more robust whilst at the same time reducing the amount of boiler-plate code that needs to be written. If you’­re new to Java or are still using JDK 1.4, then its worth while investigating all the new features provided in Java 5.