Last updated October 16, 2024

What kind of skill sets are required to build Java applications on Heroku (JEE, Spring, etc)?

You can deploy any Java application on Heroku. It is not limited to JEE or other frameworks. You can deploy Java web applications packaged as WAR files using WAR deployment or you can deploy Maven based Java projects of any kind using the git versioning system. In both cases you are free to use any frameworks and libraries that you choose, including Spring and JEE components such as Servlets, JSPs, JDBC drivers, etc.

Can I deploy standard Java web applications to Heroku?

Yes. You can build and deploy Java web applications that use all the common APIs: Servlet, JSP, JDBC, taglibs, JSF etc. You can deploy Java web applications in two ways. You can build it locally and deploy as a WAR package to Heroku or you can set it up as a Maven WAR project that includes an embedded web app runner and deploy to Heroku using git. The former is a more familiar approach to most Java developers. The latter is better optimized for continuous delivery.

Do Java applications run in a JEE container on Heroku?

Applications deployed as WAR files run in a Tomcat container. Applications deployed using Git are not deployed to a container. Instead you bundle in a web server library like Jetty or embedded Tomcat and the application can execute as a self-contained unit. Frameworks like Thorntail do this for you. The latter approach gives you the most optimal setup for continuous delivery with the best control over changes to the environment. The former is a more common approach that most Java developers are familiar with.

There are some 3rd party buildpacks for installing JEE containers on Heroku.

Can I deploy an application packaged as a WAR file to Heroku?

Yes. See our article on deploying WAR files.

Can I run a stand-alone Java application (that is not a web application) on Heroku?

Yes. In fact, to Heroku there is no difference between a stand-alone application and a web application. They are both Java processes. The web application happens to listen for web requests on a TCP port and process them using some framework like the Servlet API.

Your application can be run either as a worker process (that never exits), a one-off batch script that you launch with the heroku run command, or as a scheduled process that gets executed by the Heroku Scheduler.

Can I spawn and control threads?

Yes.

Can I read from and write to the file system?

Yes. But the file system is ephemeral. Any data you write to the file system will not be available to other dynos of your application. Generally you can assume that a file written in the beginning of a request will be available for the duration of the request, subject to the previous constraint (your dyno may get restarted in the middle of a request). Do not rely on the local filesystem for any data you want to keep around.

What happens to data written to standard out?

Standard out is piped to the Heroku logging service. You can use the heroku logs command to retrieve this log stream (in streaming mode if you add the –tail options). You can also add syslog sinks that will retrieve the log stream and can store it in log files or index it for searching and reporting.

Is there any constraints on using the core Java APIs?

No. Your application will be executed using a recent version of OpenJDK with no modifications.

How do I specify which JDK I would like my application to use?

Heroku provides a declarative way to specify your Java version from within your application. See Specifying a Java version for more information.

Do I need to push my source code to Heroku?

No, Heroku will build your app for you if you push up your source code, but if you’d like to build your application to a WAR file on your own you can also deploy WAR files directly to Heroku.

Are there benefits to pushing my source code to Heroku?

Yes, there are numerous benefits to pushing the contents of your Git repository to the platform:

• Differences between the build environment and the runtime environment are a common source of bad deploys in traditional deployment environments. Doing the app’s build in the same environment that the app will later run greatly reduces this risk.
• Pushing code rather than builds gives you and your team greater visibility into what code is deployed where. For example, the command git diff production/master staging/master will show the exact code differences between staging and production.
• Git is highly optimized for transmitting only what has changed. This means that most code pushes (after the first one) will take only seconds, instead of many minutes that it may take to transfer a full build artifact.
• Deploying with revision control makes for smoother collaboration between team members with deploy rights. For example, it provides an overrideable safeguard against accidentally overwriting a more recent deploy with an older one.

Can I use other build systems than Maven?

If you’d like Heroku to build your application for you, then you can choose from Maven or Gradle. But Ant based builds are available through 3rd party contributed buildpacks like this one. When taking advantage of our Maven support you must specify a pom.xml file at the top level of your project. If you prefer, you can use Maven to kick off Ant scripts and other types of build scripts.

If you’re deploying a WAR file you can, of course, build it with any build system you’d like.

Any other type of build can be supported on Heroku via custom Buildpacks

How do I build Force.com and Database.com Java applications on Heroku?

Use the Database.com SDK for Java.

What constraints should I be aware of when developing applications on Heroku?

Here are some things to keep in mind when designing applications on Heroku

• Your application source code plus built artifacts must be less than 500 MB when compressed. Use .slugignore to prevent files in your git repo from being included in the deployed package
• You can have many process types in a single application, but only one of those types can be a web process that receives requests from the routing layer.
• The web process must listen on one and only one port. The port must be the one specified in the $PORT variable. If your process listens on other ports, it will be shut down by Heroku.
• The Heroku routing infrastructure does not support “sticky sessions”. Requests from clients will be distributed randomly to all dynos running your application.
• Individual dyno processes of the same process type (e.g. the web process type) cannot communicate directly with each other. For example, they cannot replicate state between them. Heroku is a share-nothing architecture where each node is completely isolated.
• A single dyno (for example, a single instance of your web process type) may be restarted by Heroku at any point in time. Your application must be designed to anticipate restarts without losing data or affecting the user experience in a material way. Your dyno will receive a SIGTERM signal before it is killed. You can trap this signal to perform an orderly shutdown.
• Any data you write to the file system will not be available to other dynos of your application. Generally you can assume that a file written in the beginning of a request will be available for the duration of the request, subject to the previous constraint (your dyno may get restarted in the middle of a request). Do not rely on the local filesystem for any data you want to keep around.
• Your application must boot in one minute or less.
• You can increase the memory setting for your application from the default specified in the JAVA_OPTS config variable. But performance will eventually suffer. You should always design for horizontal scale-out when possible instead of relying on increasing the heap. You can check the setting with heroku config

Can I Use Heroku’s Built in PostgreSQL Databases With Java?

Yes, You can connect to either a shared or Heroku Postgres database from Java. You can use JDBC or any other means of database connectivity that you’re used to. You can also connect to a Heroku Postgres database from your local machine to troubleshoot your application. The Dev Center has more information on Heroku Postgres.