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[1] 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[2] is a
good place to start. As you progress deeper into using the client, you can
probably piece something together from the Javadocs[3] and the Cloud
Foundry API[4] documentation. Finally, the best examples are found in our
integration tests[5]. 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.


-Ben Hale
Cloud Foundry Java Experience


[1]:
https://github.com/cloudfoundry/cf-java-client/blob/c35c20463fab0e7730bf807af9e84ac186cdb3c2/cloudfoundry-client-spring/src/main/lombok/org/cloudfoundry/spring/util/AbstractSpringOperations.java#L73-L127
[2]: https://github.com/cloudfoundry/cf-java-client
[3]: https://github.com/cloudfoundry/cf-java-client#documentation
[4]: https://apidocs.cloudfoundry.org/latest-release/
[5]:
https://github.com/cloudfoundry/cf-java-client/blob/master/integration-test/src/test/java/org/cloudfoundry/operations/RoutesTest.java#L114-L135