The future of Java EE as discussed at recent JCP Executive Committee meetings

If you’ve been following Java EE related news over the past few months, you’ll know that Oracle cut back on a number of its Java Evangelist employees, others such as Reza Rahman appear to have left of their own accord, and there’s a general concern than Oracle appears to have slowed down input on any Java EE JSR. Rahman has formed a group called the Java EE Guardians to drive community activity to support future development of Java EE and EE JSRs.

If you want more of an inside view to what’s going on, there’s some interesting reading in the form of the JCP Executive Committee meeting minutes which are public record. The minutes for June 2016 and May 2016 both had agenda items to discuss the future of Java EE. The minutes from the May meeting are very interesting, including comments such as :

“…concern that Oracle, despite its role as steward of Java, has not made any public statements or explanations for the apparent lack of activity on Java EE”

and recording of a statement to Oracle from the JCP Executive Committee formally voicing their concern:

“EC members expressed their serious concerns about the lack of progress on Java EE. They believe that Java EE is critical to the Java ecosystem and to their organizations and customers. They fully accept Oracle’s right to direct its investment where it wishes, but expressed the hope that they and other members of the Java community be permitted to step in and help with the ongoing development of the platform, particularly in areas where Oracle wishes to reduce its investment. They therefore requested a dialog with Oracle about how to make such a transition.”

Other concern recorded in the minutes was that Oracle holds IP rights for the majority of the JSRs that are in progress, and so passing responsibility on to other parties requires Oracle’s involvement to pass on ownership of this IP… something which they may agree to, or may not.

Minutes from April 2016 note:

“Martijn Verburg reported on behalf of the London Java Community that it now seems clear that little if any progress is being made on Oracle-led Java EE JSRs. (Some Oracle Spec Leads have admitted publicly that they are unable to spend any time on their JSRs, having been directed to work elsewhere.) He estimated that work on Java EE seems to have stopped around November 2015.”

So, it’s clear there is industry concern that Oracle has backed off from involvement with development of JSRs for Java EE8. The question is, what happens now?

Docker Swarm container orchestration to be built in to Docker 1.12

After spending some time over the past few days getting up to speed with Docker Compose, one of the major announcements at DockerCon this week so far is that the Compose functionality is to be integrated into the core Docker Engine (rather than being a separate feature as it has been up until now).

If you missed my most recent getting up to speed with Docker posts, here’s a quick recap:

docker-compose.yml for 1x MongoDB container plus 1x data volume container

I’m starting to dabble with docker-compose to link up some container goodness. If you’ve followed my other Docker related posts the past couple of days (here), then you might have noticed that I have something Raspberry Pi related cooking 🙂

Although I’ll have to redo these with a Pi compatible base images, to get MongoDB running in one container with a separate data volume container is actually pretty simple. Here’s what I ended up with. To start it up, ‘docker-compose up -d’ and you’re up and running (copy this to docker-compose.yml):

mongodata: 
 image: mongo:3.2
 volumes:
 - /data/db
 entrypoint: /bin/bash
mongo: 
 image: mongo:3.2
 volumes_from:
 - mongodata
 ports:
 - "27017:27017"

Spring Boot REST app in a Docker Container on the Raspberry Pi

Docker on the Raspberry Pi? Sure, with help from Hypriot who provide an iso image ready to go, getting docker up and running on the Pi is as simple as burning their image to an sd card and booting it up. Ok, so that part is simple.

Building an image to run on the Pi is not as straightforward as it sounds. Well, it’s no more complicated than building an image from a Dockerfile, but given that the Pi is ARM based and not x86, you have to build an image that is built/compiled with executables/libraries for ARM.

This makes complete sense when you think about it, you’re not going to get an image containing x86 executables and libraries to run on a Pi, but it’s rather sad that it isn’t possible to build an image for example from my Mac and and I can run on my Mac, or Linux, or on the Pi. Well, you can build the image on any architecture, but you can’t run an ARM compatible image on the Mac (or docker-machine/boot2docker).

Ok, so that in mind, there are a number of ARM compatible images on Docker Hub already – Hypriot also have base images ready to go. So to run Spring Boot in a container on the Pi, I need an ARM image with Java. Luckily, here’s one ready to go.

For a quick test, I took my simple Sprig Boot REST app I already have on GitHub, and threw together a Dockerfile using Alpine first to check it would run locally:

FROM java:openjdk-8-alpine

ADD SpringBootREST-0.0.1-SNAPSHOT.jar /opt/SpringBootREST-0.0.1-SNAPSHOT.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "/opt/SpringBootREST-0.0.1-SNAPSHOT.jar"]

This runs as expected in docker-machine on my Mac.

To push to the Pi, the only change is to replace the base image with an ARM compatible image with Java, so this looks like:

FROM hypriot/rpi-java

ADD SpringBootREST-0.0.1-SNAPSHOT.jar /opt/SpringBootREST-0.0.1-SNAPSHOT.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "/opt/SpringBootREST-0.0.1-SNAPSHOT.jar"]

To get it to my Pi, I set up a local Registry to push the image to, and then pulled it from the Pi. So tag the image to the registry:

docker tag spring-boot-rest-rpi registry-ip:5000/spring-boot-rest-rpi

…push to the registry:

docker push registry-ip:5000/spring-boot-rest-rpi

and then pull from the Pi:

docker pull registry-ip:5000/spring-boot-rest-rpi

And then fire it up!

docker run -it -p 8080:8080 registry-ip:5000/spring-boot-rest-rpi

Spring Boot in a Docker Container on the Pi!

Docker typical workflow (rough notes)

I’m still scratching the service getting up to speed with Docker, but here’s some rough notes for what seems to be a typical development workflow.

Build an image (from Dockerfile):

docker build - imagename .

Run an image (create a container):

docker run -d -p port:port imagename

 

If pushing an image to a local Registry to share to other machines:

Tag an image:

docker tag imagename ip-of-registry:port/imagename

Push image to registry:

docker push ip-of-registry:port/imagename

For my other notes and experiences in Dockerland so far, see here.

Running a local insecure Docker Registry for testing

To start and run a local Repository for sharing images between machines (from here):

docker run -d -p 5000:5000 --restart=always --name registry registry:2

To tag a local image and push it into your repository:

docker tag imagename [ip of your docker machine]:5000/imagename

And then push it into your repo:

docker push [ip of your docker machine]:5000/imagename

By default, the docker client fails when attempting to push an image to a locally running registry if you haven’t configured TLS and certificates. If you’re running a registry locally for testing, you can configure the local client to trust an insecure Registry by:

  • docker-machine ssh [name of docker machine]
  • sudo vi /var/lib/boot2docker/profile
  • Add this line to the EXTRA_ARGS var:
--insecure-registry=[ip of your docker machine]:5000

This tip from this article.

Update1: if running on Linux (no docker-machine), add the above property to /etc/default/docker and then

sudo service docker restart

Update2: if docker is running as a service using systemd (e.g. the Hypriot Raspberry Pi image), you need to edit

/etc/systemd/system/docker.service

… append the –insecure-registry option to the end of the line that starts: ExecStart (further details here)

Now trying the push again, and success!

$ docker push 192.168.99.100:5000/spring-boot-rest-alpine

The push refers to a repository [192.168.99.100:5000/spring-boot-rest-alpine]

d5a685774b12: Pushed 

726baddb2cde: Pushed 

bb81ee534db3: Pushed 

77f08abee8bf: Pushed 

latest: digest: sha256:cafa45a64cf25533a1544f37ef7ee3fac614cb2a8d8be30efe9b3c84cebabc52 size: 1159

Managing Docker containers with Shipyard

There’s plenty of things that amaze me about Docker, but one of the things I find interesting is the number of available images with all sorts of stuff preconfigured and ready to spin up, including Docker management related tools like Shipyard that also run within Docker containers themselves.

Installing couldn’t be simpler, just pull down a script and run it, and it pulls down a number of images and spins them up:

curl -sSL https://shipyard-project.com/deploy | bash -s

Within a few seconds Shipyard is up and running, and after logging on, you get the snappy looking dashboard:

Now, off to do a bit more studying to configure a spin up a Swarm cluster 🙂