Cloud Foundry Java Client 2.0.0.M5

As the fifth of our fortnightly milestone releases, this milestone begins the move onto a Reactor Netty based network stack. It also completes the Doppler Client API.

• Introduced a Reactor Netty based Network Stack
• Updated CC API Compatibility to 2.54.0
• Entire Doppler API Implementation
• Migrated entire existing UAA to Reactor Netty Implementation
• Migrated existing Client Applications, Application Usage Events, Domains, Droplets, Environment Variable Groups, Events, Feature Flags, Info, Jobs, Organization Quota Definitions, Organizations, Processes, Stacks, Tasks, and Users, to Reactor Netty Implementation
• Removed Loggergator Implementation
• Additional Buildpacks Operations API implementations
• Additional Security Group Client API implementations
• Additional Service Key Client API implementations
• Additional Service Operations API implementations
• Improved Integration Test coverage

Cloud Foundry Java Client 2.0.0.M4

As the fourth of our fortnightly milestone releases, this milestone updates us to Reactor Core 2.5.0.M4 and adds a number of new Client APIs and Operations APIs.

• Update Reactor Core to 2.5.0.M3
• Fixed serious bug in PaginationUtils that resulted in only collections being returned
• Exposed a DelayUtils.immediate() method for retrying without delay
• Additional Application Operations API implementations
• Additional Buildpacks Client API implementations
• Additional Buildpacks Operations API implementations
• Additional Domains Operations API implementations
• Additional Organization Admin Client API implementations
• Additional Organization Admin Organization API implementations
• Additional Route Mapping Client API implementations
• Additional Security Group Client API implementations
• Additional Service Binding Organization API implementations
• Additional Service Operations API implementations
• Improved Integration Test coverage

Cloud Foundry Java Client 2.0.0.M3

As the third of our fortnightly milestone releases, this milestone updates us to CC API 2.51.0 compatibility and adds a number of new Client APIs.

• Update compatibility to CC API 2.51.0
• Added exponential backoff implementation for use with retryWhen()
• Bind service operation now binds user provided services.
• Additional Service operations
• Additional Buildpacks Client API implementations
• Additional Environment Variable Group Client API implementations
• Additional Feature Flag Client API implementations
• Additional Route Mapping Client API implementations
• Additional Shared Domains Client API implementations
• Improved Integration Test coverage

Cloud Foundry Java Client 2.0.0.M2

As the second of our fortnightly milestone releases, this milestone contains a number of improvements based on the usage for the previous milestone.

• Applications.delete() will remove application with bound services (#419)
• Conformance with the V3 Package.upload() behavior
• Addition of missing CreateApplicationRequest.ports argument (#420)
• OSGi ClassLoader compatibility (#423)
• User configurable staging and start timeouts in the Operations API
• Additional Service operations
• Additional Application Usage Event Client API implementations
• Improved Integration Test coverage

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.