Cloud Foundry Java Client 2.0.0.M1

As some of you may know, the Cloud Foundry Java Client has gone through various levels of neglect over the past couple of years. Towards the end of last year, my team started working on the project with the goal of making it a piece of software that we were not only proud of, but that we could build towards the future with. With that in mind, I’m exceedingly pleased to announce our 2.0.0.M1 release.

We’ve taken the opportunity of this major release to reset what the project is:

• What was a once hodgepodge of Java APIs both mapping directly onto the REST APIs and onto higher-level abstractions is now two clearly delineated APIs. We expose a -client API mapping to the REST calls and an -operations API mapping to the higher-level abstractions that roughly match the CLI.
• What once was an implementation of a subset of the Cloud Foundry APIs is now a target of implementing every single REST call exposed by any Cloud Foundry component (nearly 500 individual URIs across 4 components)
• What was once a co-mingled interface and Spring-based implementation is now an airtight separation between the two allowing alternate implementations (addressing one of the largest complaints about the previous generation)
• Finally, we’ve chosen to make the API reactive, building on top of Project Reactor, but interoperable with any Reactive Streams compatible library

Obviously, the biggest change in this list is the move to a reactive API. This decision was not take lightly. In fact our original V2 implementation was imperative following the pattern of the V1 effort. However, after consulting with both internal and external users, we found that many teams were viewing “blocking” APIs as a serious issue as they implemented their high-performance micro-service architectures.

As an example, we worked very deeply with a team right at the beginning as they were creating a new Cloud Foundry Routing Service. Since each HTTP request into their system went though this service, performance was a primary concern and they were finding that the blocking bit of their implementation (Java Client V1) was the biggest hit for them. We’ve mitigated a lot of the performance bottle neck with what we’ve got today, but for M2 we’re planning on removing that last blocking component completely and moving to a full non-blocking network stack. This isn’t an isolated use case either, we’ve been seeing a lot of this theme; micro-service architectures require throughput that can’t be achieved without either a non-blocking stack or “massive” horizontal scaling. Most companies would prefer the former simply due to cost.

As a general rule you can make a reactive api blocking (just tack .get() onto the end of any Reactor flow) but cannot make a blocking API non-blocking (see the insanity we do to fake it, with non-optimal results, on RestTemplate today). So since we had a strong requirement to support this non-blocking design we figured that going reactive-first was the most flexible design we could choose.

If you want to get started with this new version, I’m sad to say that we’re a bit lacking in the “on boarding experience” at the moment. We don’t have examples or a user-guide, but the repository’s README is a good place to start. As you progress deeper into using the client, you can probably piece something together from the Javadocs and the Cloud Foundry API documentation. Finally, the best examples are found in our integration tests. Improving this experience is something we’re quite sensitive to, so you can expect significant improvements here.

The reason that we’re laying this foundation is you. We’re already seeing customers adopting (and contributing back to!) the project, but we’ve really done it to accelerate the entire Cloud Foundry ecosystem. If you need to interact with Cloud Foundry, I want you to be using the Java Client. If you find that it’s not the best way for you to get your work done, I want you to tell me, loudly and often. We’re also excited about being in the vanguard of reactive APIs within the Java ecosystem. Having recently experienced it, I’m sure that this transition will not be trivial, but I am sure that it’ll be worthwhile.

A special thanks goes out to Scott Fredrick (Pivotal) for nursing the project along far enough for us to take over, Benjamin Einaudi (Orange Telecom) for his constant submissions, and of course Chris Frost (Pivotal), Glyn Normington (Pivotal), Paul Harris (Pivotal), and Steve Powell (Pivotal) for doing so much of the hard work.