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:
File("/path/to/destination").writeBytes(File("/path/to/source").readBytes())
That could even be an extension function itself:
fun File.copyFile(dest: File): Unit = dest.writeBytes(this.readBytes())
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 madegreat progress on it.
I'm currently working on a DSLs-in-Kotlin presentation for my local JUG, so I need a good domain in which to work. HTML is a great sample domain, but it's been done to death. After a bit of head scratching, I've come up with what is, I think, a somewhat novel domain: REST application building. Sure, there are libraries like Ktor
, but suffers from some very serious NIH. I'm totally kidding, but the dearth of discussions regarding REST applications and DSL construction was good enough for me, so let's see what we have so far.
My name is Jason Lee. I am a software developer living in the middle of Oklahoma. I’ve been a professional developer since 1997,
using a variety of languages, including Java, Javascript, PHP, Python, Delphi, and even a bit of C#. I currently work for Red Hat
on the WildFly/EAP team, where, among other things, I maintain integrations for some MicroProfile specs, OpenTelemetry, Micrometer,
Jakarta Faces, and Bean Validation. (Full resume 