Jesper Joergensen jesperfj

Gigaom picked up Derek Collison's tweet about Go. The article singles out static typing as a reason why Go will become a popular systems language.

I will add another reason: It is not an object oriented language.

In the 15 years I have spent designing, building and marketing what is essentially networked services (web apps), object orientation has always feel like a poor fit. Object orientation is simply not a universally applicable modeling principle. Going further, I will argue that, in most cases, it is a poor modeling principle. Objects rarely exhibit behavior. More often, objects are subjected to behavior by some external force (functions operating on data structures).

I find that keeping functions and data structures separate yield the most well structured programs. Best practices for writing web apps follow the same pattern: Use data transfer objects, use compositi

Take a simple Maven app like this JAX-RS app:/

$ git clone http://github.com/heroku/template-java-jaxrs.git
Cloning into template-java-jaxrs...
remote: Counting objects: 348, done.
remote: Compressing objects: 100% (156/156), done.
remote: Total 348 (delta 97), reused 348 (delta 97)
Receiving objects: 100% (348/348), 39.70 KiB | 45 KiB/s, done.

$ mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webapp[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] >>> maven-archetype-plugin:2.2:generate (default-cli) @ standalone-pom >>>
[INFO]

This guide will get you started using Spark on Heroku/Cedar. Spark is basically a clone of Sinatra for Java. 'Nuff said.

Create your app

Create a single Java main class in src/main/java/HelloWorld.java:

:::java
import static spark.Spark.*;
import spark.*;

A better way to set up Java web apps

If you're building a Java web app that you yourself or your organization will be deploying then you can save yourself a lot of trouble by avoiding the whole build-to-war + deploy-to-server approach. Instead, you should build your web app as a normal Java application with an embedded web app server. Don't build a WAR, just compile the code and serve the files out of their source location. This has the following advantages:

You can code and test iteratively because you don't have to copy files and create war packages every time you make a change. This is similar to what the mvn jetty:run command is being used for by many developers today.
You run the same exact code in production as you do in development. Hopefully I don't have to elaborate on the advantages of that. Most developers today use mvn jetty:run or similar to achieve a quick, iterative dev cycle. But come time for deployment, they build a WAR and throw it over the wall to be deployed in some app server

	#!/usr/bin/env bash
	# bin/compile <build-dir> <cache-dir>

	# fail fast
	set -e

	BIN_DIR=$(cd $(dirname $0); pwd) # absolute path
	# parse args
	BUILD_DIR=$1
	CACHE_DIR=$2

	#!/usr/bin/env bash
	# bin/compile <build-dir> <cache-dir>

	# fail fast
	set -e

	BIN_DIR=$(cd $(dirname $0); pwd) # absolute path
	# parse args
	BUILD_DIR=$1
	CACHE_DIR=$2

	java.util.jar.JarFile jar =
	new java.util.jar.JarFile((thispackage.ThisClass.class.getProtectionDomain()
	.getCodeSource().getLocation()).getFile());
	System.out.println(jar.getManifest().getMainAttributes().getValue("Class-Path"));