Frequently Asked Questions about Java
Last updated 15 June 2015
Table of Contents
- Can I run Java applications free of charge?
- What kind of skill sets are required to build Java applications on Heroku (JEE, Spring, etc)?
- Can I deploy standard Java web applications to Heroku?
- Do Java applications run in a JEE container on Heroku?
- Can I deploy an application packaged as a WAR file to Heroku?
- Can I run a stand-alone Java application (that is not a web application) on Heroku?
- Can I spawn and control threads?
- Can I read from and write to the file system?
- What happens to data written to standard out?
- Is there any constraints on using the core Java APIs?
- How do I specify which JDK I would like my application to use?
- What about JNI?
- Do I need to push my source code to Heroku?
- Are there benefits to pushing my source code to Heroku?
- Can I use other build systems than Maven?
- How do I build Force.com and Database.com Java applications on Heroku?
- What constraints should I be aware of when developing applications on Heroku?
- Can I Use Heroku’s Built in PostgreSQL Databases With Java?
If you have questions about Java on Heroku, consider discussing them in the Java on Heroku forums.
Can I run Java applications free of charge?
Yes. Heroku offers a free dyno type.
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. 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.
Can I deploy an application packaged as a WAR file to Heroku?
Yes. WAR deployment support is included as part of our Heroku Enterprise Java offering.
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?
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 6, 7, or 8 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 Updating Existing Maven Apps to Use Java 7 for more information.
What about JNI?
JNI APIs are not guaranteed to work. Search Dev Center for information about specific JNI services supported by Heroku.
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/masterwill 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 Maven is currently the only build system supported by default. 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 200MB. 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
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.