Migrate to Kotlin

[gesellix]

After the underlying libs (docker-filesocket and docker-compose-v3) have already been migrated, the time has come to convert the main repository.

My philosophy behind this Docker client is to keep the Docker engine facing side as flexible as possible (to keep our code as stable as possible for different engine api versions). Types might be less convenient, so I have no idea whether Kotlin is counter productive.

My main motivation to introduce Kotlin is the library's client facing side. A strongly typed api certainly helps to use a library given a capable IDE. That way, the lack of documentation might be compensated to a certain degree.

Things to keep in mind:

There's no static modifier in Kotlin. static someMethod(){} could be converted to @JvmStatic fun someMethod(), but it would also be valid to simply remove the static modifier and make someMethod() an instance method.
We should focus on the production code first. Test code can also be converted to Kotlin, but with low priority. I'm a fan of the Groovy Spock framework and there's no equivalent in Kotlin, yet (I didn't find any). Spek seems to be the most similar alternative as of today.
See docker-client/docker-filesocket@620cc55 for a first try at converting from Groovy to Kotlin.

[tobad357]

Would this involve making the response objects typed?
If they were then it would be a lot easier to use the API to check responses from docker

[gesellix]

Please also read this note on the same topic: docker-client/docker-compose-v3#1 (comment)

My idea is to increase convenience for library users like you, while also keeping flexibility on the Docker api facing side. Since there will be some kind of middle ground between convenience (more types) and flexibility (less types) I'll have to decide where to make a cut. Historically, I prefer flexibility. There are several reasons: one would be to stay as compatible across Docker versions as possible, another one would be that there is another Docker Java client available with a strongly typed model.

My actual plan goes like this: I already moved the low level classes handling the boring technical stuff into its own library at https://github.com/docker-client/docker-engine. Then I'd like to implement a convenient layer on top of the current docker-client with the typical use cases like docker run, docker pull, and such. Most of them should simply delegate to the existing classes and methods. That layer should become strongly typed, and I hope that the new layer will be quite agnostic to actual Docker api versions. That layer should be written in Kotlin (maybe Java 9 also suffices).

Regarding your question about response objects: yes, I'm aiming at providing the typically useful response objects or properties in a typed manner. Yet, I suppose that there are edge cases where the effort to maintain the mapping from the HTTP api to Java types might be too much. That's where I'm thinking of some kind of "detailed" response, which is exactly the same like today.

Maybe an example might help. Consider the response of docker create ..., where you are typically interested in the container id:

class ContainerCreateResponse {
    String containerId
    EngineReponse details
}

Here containerId is the more or less typed value, while details contain the more or less plain response for debugging purposes or to give experts all possibilities.

[gesellix]

WIP: #149

[gesellix]

A strongly typed docker-client is now used internally, and we're going to work on the following aspects:

• fix the attach/interactive apis (container start, exec start), which have been somewhat unreliable/broken for quite a while
• introduce a convenient api layer
• allow "plain" calls to the Docker engine

[huehnerlady]

Hi,

is this issue still worked on?
We are currently migrating to groovy 4 and run into the problem that this lib still uses groovy 3.
Is there a plan to upgrade groovy at all or is this dismissed in favour of this issue?

[gesellix]

@huehnerlady would you mind creating a separate issue to support Groovy 4.x? I think it should be quite easy to upgrade the Docker Client to Groovy 4. Upgrading the whole concept like described above has proven to be very slow and with baby steps due to lack of time.

Are you using the docker-client directly or via gradle-docker-plugin? I would have to ensure that Gradle supports Groovy 4 in a plugin runtime context.

[huehnerlady]

@huehnerlady would you mind creating a separate issue to support Groovy 4.x? I think it should be quite easy to upgrade the Docker Client to Groovy 4. Upgrading the whole concept like described above has proven to be very slow and with baby steps due to lack of time.

Are you using the docker-client directly or via gradle-docker-plugin? I would have to ensure that Gradle supports Groovy 4 in a plugin runtime context.

we are using it directly in one lib
I am happy to create a new issue, just wanted to check first if it makes sense or not