[cft-dev] CFT moving to Java 8 and adopting CF Java client v2

[Nieraj Singh <nsingh@xxxxxxxxxx>]

We are planning on moving to Java 8 as the minimum execution
environment for CFT for the next releases of CFT, both Neon.2 and by
Oxygen M4.

Release schedules for CFT Neon.2 and Oxygen milestones can be found here:
https://projects.eclipse.org/projects/ecd.cft

The reason for this upgrade is to adopt the Cloud Foundry Java client
v2, which requires Java 8,  for certain cases described below that
require doppler log streaming.

On certain newer Cloud Foundry, older loggregator is no longer
supported and log streaming with the old v1 client currently used by
CFT is no longer possible. An example of this is Pivotal Web Services.

See Bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=504183

Information on the Cloud Foundry Java client v2 is here:
https://github.com/cloudfoundry/cf-java-client

We will not be completely replacing the v1 client in CFT from the
start, but rather have a hybrid model, where both v1 and v2 co-exist
in CFT, and are used based on which CF target the tools are connecting
too.

V1 will still be used for the vast majority of Cloud operations,
regardless of which CF target is being connected to, like pushing and
scaling applications, as well as creating and binding/unbinding
services, and v2 will be used only for log streaming on Cloud Foundry
targets versions 242 or higher (CC API version 2.62.0 or higher) that
offer doppler endpoints. Older CF targets will still be using v1
entirely when CFT connects to them, including log streaming via
loggregator.

Therefore the changes to adopt v2 are not going to require a vast
amount of changes to the existing CFT code base initially, and
adoption of v2 will be gradual, only where absolutely needed.
Initially, v2 will only be used for doppler log streaming only on
certain newer CF targets, as described above. Nothing else will change
with CFT.

None of the public CFT API or existing extension points will be
affected by this adoption.

Also, switching between v1 and v1/v2 hybrid is also not expected to
require changes on any products extending CFT, as this switch is an
internal CFT framework implementation, and will be automatic and
performed by the framework when the tools are connecting to CF
targets.

In addition, because CFT will bundle both v1 and v2 clients, and all
the dependencies that are not available from Orbit repository, the CFT
installation size is expected to grow by 14MB.

For any questions and concerns about CFT moving to Java 8, and
adopting CF Java client v2, please raise them here.