This time around, we’re going to start looking at a slightly different take on MicroProfile implemenations. Whereas Payara Micro, Thorntail, OpenLibery, and TomEE are all based on application servers (albeit stripped down versions), our implementation in this post, Hammock, is based on a CDI container. Rather than start what amounts to an app server under which a web is deployed, we’ll be spinning up a plain ol' CDI container, which will look for CDI beans to load/start/etc. That may sound weird, and I may not be describing it clearly, so let’s just jump in to the code and take a look.

In this installment of our series, we’re going to take a look at the last of what I think of as the more traditional, app-server-based/-spawned implementations, TomEE. TomEE is a fully Java EE-enabled distribution of the venerable workhorse Tomcat, and comes with support for creating MicroProfile applications, so let’s see what that looks like.

Having looked at Thorntail last time, we’ll take a look at OpenLiberty this time. OpenLiberty is the open source project under which, as I understand the state of things, IBM’s WebSphere Liberty is developed. In this installment, we’ll give its MicroProfile support a quick spin.

In the last installment, we talked about Payara Micro. In this, we’re going to look at Thorntail. Thorntail, née WildFly Swarm, is based on WildFly from Red Hat and is said to be "just enough app-server". Much like Payara Micro, Thorntail exposes a battle-tested application server platform, stripped down for microservices usage. Let’s a take a look at what it takes to deploy our application on Thorntail.

Payara Micro is a MicroProfile implementation from the good folks at Payara, based on Payara Server, which is itself based on GlassFish. Whew! If you’re familiar with either GlassFish or Payara, you should feel right at home with Payara Micro.

To start our investigation, we need an application to work with. Part of the problem with getting started applications is making sure that your example is complicated enough to be interesting, but not so complicated that the greater message is lost in the details of the app. MicroProfile 2.0 is made up of a number of components:

To include all of those in this would probably be a bit too much technical weight for a getting started effort, so, for this example, I’ve leaned (probably too far) toward simple. Our application will have a single JAX-RS resource, into which is injected a single CDI bean. The point is to have a working REST endpoint, with an inject "service layer", to show a MicroProfile in action, allowing us to verify that our basic environment is configured and working correctly. From there you are free to load on all the complexity you find you need. That’s exactly what I’ll be doing in a separate project. :)

The Eclipse MicroProfile is a community-driven profile initially developed by Red Hat, IBM, TomiTribe, Payara and the London Java Community (LJC). Launched in 2016, it was intended to sit alongside Java EE’s Web and Full profiles, offering Java EE developers a smaller, lighter set of standards with which they could build microservices. Today, MicroProfile lives as an Eclipse project, and is being supported and actively developed by its creators as well as many more, including both corporations and individuals, giving us an embarassment of riches, if you will, when it comes to implementations.

By my count, there are at least 6 implementations from which to choose, leading to the question: Which one do I choose? While there are many aspects that factor in to such a decision, it is not my intent here to answer those questions. Rather, what I’d like to do is provided some small "getting started" projects to help you kick off your own investigation. With that in mind, here are the implementations (in no particular order) that we’re going to look at:

In Part 1, we’ll cover the (admittedly absurdly basic) application, and in subsequent parts, we’ll see what it takes to deploy that application using each of these MicroProfile implementations.

Copying files in Java is, I think, header than it seems it should be. Typically, I see that done with, say, a ByteArrayInputStream and a ByteArrayOutputStream . Thanks to Kotlin’s extension function capabilities, this operation is a one-liner:

That could even be an extension function itself:

My work machine runs Windows (go ahead and laugh. I’ll wait). While I’ve been able to tweak the machine and get a moderately acceptable setup, there are times when I’d really like to use Linux for something, so I spin up a virtual machine with VirtualBox. While that works, I don’t really like having source code — especially with changes in flight — on the VM, as it makes it a bit more dangerous/difficlt to destroy the VM should I need the disk space (which happens more often than I’d like). I set out, then to get shared folders working so I can keep the source on my host machine, and just do the work in the VM. Unfortunately, it doesn’t seem to be as simple as adding a shared folder to the VirtualBox config. This post, then, will detail the steps I took to make things work for me.

If you wrote software on a DOS system in the 80s or 90s, you probably used one of the Borland products, Turbo Pascal or Turbo C, with that beautiful, beautiful blue, mouse-enabled text-based user interface (TUI, if you will). Those IDEs were powered by a library called Turbo Vision (TV), which Borland documented and published for others to use. I loved it. While we all live in a GUI world and there are lots of libraries for building GUIS, I have for years now been dying to be able to use TV again, if for no other reason than hard core nostalgia. The problem being that I have used C in about 2 decades, and, to be honest, I’m not sure I’m too excited about writing even toy apps in the language. Dead end, right? Not so fast.

Enter, stage left: SWIG. SWIG, the Simplified Wrapper and Interface Generator, is a tool for building wrappers for libraries written in, say, C or C, for languages such as Python, PHP, and... Java. While it may not be the best option, it's an option, and I've been tinkering with it off and on for many, many moons now with the C version of the library open source by Borland long ago, before they were sold off and the Borland brand quietly disappeared. Tonight, I made great progress on it.