|
As many of you are aware, the Cloud Foundry Java Client has been a bit neglected lately. There are various reasons for this, but today I’m pleased to announce that we’ve begun a V2 effort and that progress is swift. We on the Cloud Foundry Java Experience team have been aware for some time that the current implementation of the Java Client is less than ideal. Among the most common complaints were the lack of separation between interface and implementation, the subpar network performance, and the requirement that users understand how to orchestrate common concepts like `push` on their own. (For a more in-depth treatment of issues we identified, please see the stellar work done by Scott Fredrick[1].) V2 aims to address all of these issues with a ground-up redesign of the client. To address the issue of a lack of separation between interface and implementation, we’ve broken out the API into a project containing no implementation. This project (`cloudfoundry-client`) consists of a collection of interfaces and immutable datatypes. There is only a single dependency, and it isn’t Spring! The intent here was to create an API that could be implemented with multiple strategies, but requiring the minimal amount of code for each of those implementations. The API itself is now reactive (the single dependency is on Reactive Streams, the precursor to reactive support in Java 9) which we believe will more closely align with the trends towards non-blocking network communication. We will be providing a single implementation of this API, based on Spring (`cloudfoundry-client-spring`) but welcome additional implementations. We believe we’ve created a good environment for alternatives and would be happy to hear suggestions on how to improve if that turns out not to be the case. In V1, the coverage of the APIs[2] was incomplete (about half, if I had to guess). Our commitment is to deliver a complete API and implementation in V2, including all 300+ documented APIs. We’ve observed that this API might not actually be the right level of abstraction for many users though. Knowing that you need to create an application, create a package, stage a droplet, create and start a process, etc. for `push` is quite a burden on many users of the project. So, we’re also providing a `cloudfoundry-operations` project that builds on the `cloudfoundry-client` API but instead of mapping onto the low-level REST API, we’re going to map roughly onto the `cf` CLI API. We suspect that nearly all users will want to `cloudFoundryOperations.push()` instead of the low-level alternative, so both choices are useful. This API and implementation will only depend on `cloudfoundry-client` allowing any implementation of that API to be used. Finally, we’ll be bringing the build-system plugins up to date with the systems that they are built for and ensuring that they cover a breadth of useful functionality at build time. This leaves the question about what will happen to V1. We have a commitment to fixing up the bugs that have been identified in the code-base, but we’re not going to be doing any work that involves adding APIs. We feel that users who need those APIs are better served moving to V2. I’ll be feeding open issues from the backlog into the V2 stream of work to ensure that we aren’t seeing any resource starvation and you can expect future releases out of the `1.x` branch. I hope that this comes as welcome news to the community and look forward to the feedback. I highly encourage users to keep an eye Pivotal Tracker[3] to see our progress and submit requests through GitHub[4]. -Ben Hale Cloud Foundry Java Experience [1]: https://docs.google.com/document/d/1Ui-67dBPYoADltErL80xXYEr_INPqdNJG9Va4gPBM-I/edit?usp=sharing[2]: http://apidocs.cloudfoundry.org/221/[3]: https://www.pivotaltracker.com/projects/816799[4]: https://github.com/cloudfoundry/cf-java-client
|
|
|
Josh Long <starbuxman@...>
This is awesome! Using reactive-streams is particularly inspired. Congrats
and I'm very much looking forward to this work.
Will v1 receive support for individually addressable IPs, or will that be
unique to v2?
toggle quoted message
Show quoted text
On Thursday, October 15, 2015, Ben Hale <bhale(a)pivotal.io> wrote: As many of you are aware, the Cloud Foundry Java Client has been a bit
neglected lately. There are various reasons for this, but today I’m
pleased to announce that we’ve begun a V2 effort and that progress is swift.
We on the Cloud Foundry Java Experience team have been aware for some time
that the current implementation of the Java Client is less than ideal.
Among the most common complaints were the lack of separation between
interface and implementation, the subpar network performance, and the
requirement that users understand how to orchestrate common concepts like
`push` on their own. (For a more in-depth treatment of issues we
identified, please see the stellar work done by Scott Fredrick[1].) V2
aims to address all of these issues with a ground-up redesign of the client.
To address the issue of a lack of separation between interface and
implementation, we’ve broken out the API into a project containing no
implementation. This project (`cloudfoundry-client`) consists of a
collection of interfaces and immutable datatypes. There is only a single
dependency, and it isn’t Spring! The intent here was to create an API that
could be implemented with multiple strategies, but requiring the minimal
amount of code for each of those implementations. The API itself is now
reactive (the single dependency is on Reactive Streams, the precursor to
reactive support in Java 9) which we believe will more closely align with
the trends towards non-blocking network communication. We will be
providing a single implementation of this API, based on Spring
(`cloudfoundry-client-spring`) but welcome additional implementations. We
believe we’ve created a good environment for alternatives and would be
happy to hear suggestions on how to improve if that turns out not to be the
case.
In V1, the coverage of the APIs[2] was incomplete (about half, if I had to
guess). Our commitment is to deliver a complete API and implementation in
V2, including all 300+ documented APIs. We’ve observed that this API might
not actually be the right level of abstraction for many users though.
Knowing that you need to create an application, create a package, stage a
droplet, create and start a process, etc. for `push` is quite a burden on
many users of the project. So, we’re also providing a
`cloudfoundry-operations` project that builds on the `cloudfoundry-client`
API but instead of mapping onto the low-level REST API, we’re going to map
roughly onto the `cf` CLI API. We suspect that nearly all users will want
to `cloudFoundryOperations.push()` instead of the low-level alternative, so
both choices are useful. This API and implementation will only depend on
`cloudfoundry-client` allowing any implementation of that API to be used.
Finally, we’ll be bringing the build-system plugins up to date with the
systems that they are built for and ensuring that they cover a breadth of
useful functionality at build time.
This leaves the question about what will happen to V1. We have a
commitment to fixing up the bugs that have been identified in the
code-base, but we’re not going to be doing any work that involves adding
APIs. We feel that users who need those APIs are better served moving to
V2. I’ll be feeding open issues from the backlog into the V2 stream of
work to ensure that we aren’t seeing any resource starvation and you can
expect future releases out of the `1.x` branch.
I hope that this comes as welcome news to the community and look forward
to the feedback. I highly encourage users to keep an eye Pivotal
Tracker[3] to see our progress and submit requests through GitHub[4].
-Ben Hale
Cloud Foundry Java Experience
[1]:
https://docs.google.com/document/d/1Ui-67dBPYoADltErL80xXYEr_INPqdNJG9Va4gPBM-I/edit?usp=sharing
[2]: http://apidocs.cloudfoundry.org/221/
[3]: https://www.pivotaltracker.com/projects/816799
[4]: https://github.com/cloudfoundry/cf-java-client
--
Josh Long
Spring Developer Advocate, Pivotal
joshlong.com | @starbuxman
|
|
|
exciting work ben, scott, and all involved thus far! this is great news to
anyone wanting to integrate with cloud foundry from a client with java api
interoperability, which covers a large number of situations.
toggle quoted message
Show quoted text
On Fri, Oct 16, 2015 at 11:12 PM, Josh Long <starbuxman(a)gmail.com> wrote: This is awesome! Using reactive-streams is particularly inspired. Congrats
and I'm very much looking forward to this work.
Will v1 receive support for individually addressable IPs, or will that be
unique to v2?
On Thursday, October 15, 2015, Ben Hale <bhale(a)pivotal.io> wrote:
As many of you are aware, the Cloud Foundry Java Client has been a bit
neglected lately. There are various reasons for this, but today I’m
pleased to announce that we’ve begun a V2 effort and that progress is swift.
We on the Cloud Foundry Java Experience team have been aware for some
time that the current implementation of the Java Client is less than
ideal. Among the most common complaints were the lack of separation
between interface and implementation, the subpar network performance, and
the requirement that users understand how to orchestrate common concepts
like `push` on their own. (For a more in-depth treatment of issues we
identified, please see the stellar work done by Scott Fredrick[1].) V2
aims to address all of these issues with a ground-up redesign of the client.
To address the issue of a lack of separation between interface and
implementation, we’ve broken out the API into a project containing no
implementation. This project (`cloudfoundry-client`) consists of a
collection of interfaces and immutable datatypes. There is only a single
dependency, and it isn’t Spring! The intent here was to create an API that
could be implemented with multiple strategies, but requiring the minimal
amount of code for each of those implementations. The API itself is now
reactive (the single dependency is on Reactive Streams, the precursor to
reactive support in Java 9) which we believe will more closely align with
the trends towards non-blocking network communication. We will be
providing a single implementation of this API, based on Spring
(`cloudfoundry-client-spring`) but welcome additional implementations. We
believe we’ve created a good environment for alternatives and would be
happy to hear suggestions on how to improve if that turns out not to be the
case.
In V1, the coverage of the APIs[2] was incomplete (about half, if I had
to guess). Our commitment is to deliver a complete API and implementation
in V2, including all 300+ documented APIs. We’ve observed that this API
might not actually be the right level of abstraction for many users
though. Knowing that you need to create an application, create a package,
stage a droplet, create and start a process, etc. for `push` is quite a
burden on many users of the project. So, we’re also providing a
`cloudfoundry-operations` project that builds on the `cloudfoundry-client`
API but instead of mapping onto the low-level REST API, we’re going to map
roughly onto the `cf` CLI API. We suspect that nearly all users will want
to `cloudFoundryOperations.push()` instead of the low-level alternative, so
both choices are useful. This API and implementation will only depend on
`cloudfoundry-client` allowing any implementation of that API to be used.
Finally, we’ll be bringing the build-system plugins up to date with the
systems that they are built for and ensuring that they cover a breadth of
useful functionality at build time.
This leaves the question about what will happen to V1. We have a
commitment to fixing up the bugs that have been identified in the
code-base, but we’re not going to be doing any work that involves adding
APIs. We feel that users who need those APIs are better served moving to
V2. I’ll be feeding open issues from the backlog into the V2 stream of
work to ensure that we aren’t seeing any resource starvation and you can
expect future releases out of the `1.x` branch.
I hope that this comes as welcome news to the community and look forward
to the feedback. I highly encourage users to keep an eye Pivotal
Tracker[3] to see our progress and submit requests through GitHub[4].
-Ben Hale
Cloud Foundry Java Experience
[1]:
https://docs.google.com/document/d/1Ui-67dBPYoADltErL80xXYEr_INPqdNJG9Va4gPBM-I/edit?usp=sharing
[2]: http://apidocs.cloudfoundry.org/221/
[3]: https://www.pivotaltracker.com/projects/816799
[4]: https://github.com/cloudfoundry/cf-java-client
--
Josh Long
Spring Developer Advocate, Pivotal
joshlong.com | @starbuxman
--
Thank you,
James Bayer
|
|
|
Will v1 receive support for individually addressable IPs, or will that be unique to v2? I believe that this falls under new APIs for V1 and won’t be completed. Basically, unless it’s a bug fix, I wouldn’t assume that it’ll come to V1. -Ben
|
|
|
Guillaume Berche
Thanks Ben for sharing details of this important effort with the community. In the light of the ongoing implementation for the v2 cf-java-client implementation, does the Java experience team feels that of the 300+ documented API endpoints, there is room for a consistent, systematic approach for the low level API that matches these low-level CC API endpoints ? Does the team feel that this low level API could be automatically generated from a formal REST API specification ? Could some of the effort in 100% Java coverage could be shifted in maintaining a formal REST API specification, from which the Java low-level client could be generated automatically, similar to what google is systematically doing when providing client libraries [1], in multiple languages including java [2], php, JS, Node.Js, Go, ruby, .Net for all of google REST APIs, using automatic client code generation [3]. The question of a formal CC API REST API spec was brought to the CAPI team in the context of the v3 CC API at [4], and I'd like to know if the teams generating the clients feel there is room for automation, and mutualization of effort among programming languages (in particular Java, go, Js) for the v3 version, building on learnings and experience from existing CC API clients. Thanks in advance, Guillaume. [1] https://developers.google.com/discovery/libraries?hl=en[2] https://developers.google.com/api-client-library/java/[3] https://github.com/google/apis-client-generator[4] https://github.com/cloudfoundry/cc-api-v3-style-guide/issues/46
On Thu, Oct 15, 2015 at 9:21 PM, Ben Hale <bhale(a)pivotal.io> wrote: As many of you are aware, the Cloud Foundry Java Client has been a bit
neglected lately. There are various reasons for this, but today I’m
pleased to announce that we’ve begun a V2 effort and that progress is swift.
We on the Cloud Foundry Java Experience team have been aware for some time
that the current implementation of the Java Client is less than ideal.
Among the most common complaints were the lack of separation between
interface and implementation, the subpar network performance, and the
requirement that users understand how to orchestrate common concepts like
`push` on their own. (For a more in-depth treatment of issues we
identified, please see the stellar work done by Scott Fredrick[1].) V2
aims to address all of these issues with a ground-up redesign of the client.
To address the issue of a lack of separation between interface and
implementation, we’ve broken out the API into a project containing no
implementation. This project (`cloudfoundry-client`) consists of a
collection of interfaces and immutable datatypes. There is only a single
dependency, and it isn’t Spring! The intent here was to create an API that
could be implemented with multiple strategies, but requiring the minimal
amount of code for each of those implementations. The API itself is now
reactive (the single dependency is on Reactive Streams, the precursor to
reactive support in Java 9) which we believe will more closely align with
the trends towards non-blocking network communication. We will be
providing a single implementation of this API, based on Spring
(`cloudfoundry-client-spring`) but welcome additional implementations. We
believe we’ve created a good environment for alternatives and would be
happy to hear suggestions on how to improve if that turns out not to be the
case.
In V1, the coverage of the APIs[2] was incomplete (about half, if I had to
guess). Our commitment is to deliver a complete API and implementation in
V2, including all 300+ documented APIs. We’ve observed that this API might
not actually be the right level of abstraction for many users though.
Knowing that you need to create an application, create a package, stage a
droplet, create and start a process, etc. for `push` is quite a burden on
many users of the project. So, we’re also providing a
`cloudfoundry-operations` project that builds on the `cloudfoundry-client`
API but instead of mapping onto the low-level REST API, we’re going to map
roughly onto the `cf` CLI API. We suspect that nearly all users will want
to `cloudFoundryOperations.push()` instead of the low-level alternative, so
both choices are useful. This API and implementation will only depend on
`cloudfoundry-client` allowing any implementation of that API to be used.
Finally, we’ll be bringing the build-system plugins up to date with the
systems that they are built for and ensuring that they cover a breadth of
useful functionality at build time.
This leaves the question about what will happen to V1. We have a
commitment to fixing up the bugs that have been identified in the
code-base, but we’re not going to be doing any work that involves adding
APIs. We feel that users who need those APIs are better served moving to
V2. I’ll be feeding open issues from the backlog into the V2 stream of
work to ensure that we aren’t seeing any resource starvation and you can
expect future releases out of the `1.x` branch.
I hope that this comes as welcome news to the community and look forward
to the feedback. I highly encourage users to keep an eye Pivotal
Tracker[3] to see our progress and submit requests through GitHub[4].
-Ben Hale
Cloud Foundry Java Experience
[1]:
https://docs.google.com/document/d/1Ui-67dBPYoADltErL80xXYEr_INPqdNJG9Va4gPBM-I/edit?usp=sharing
[2]: http://apidocs.cloudfoundry.org/221/
[3]: https://www.pivotaltracker.com/projects/816799
[4]: https://github.com/cloudfoundry/cf-java-client
|
|
|
