Java API

[dellisd]

Currently the API of this project is designed with the potential for consumption from Java projects (with the exception of geojson-dsl). The libraries will always be interoperable with Java code, as all Kotlin is, but this issue looks specifically at whether it will be worth continuing to provide a dedicated Java API to match the API provided in Kotlin.

Issues with maintaining dedicated Java API

• Some possible function implementations may require use of @JvmName to avoid compilation issues. For instance, if Feature generics are added (Feature generics #76), some functions like length() that can accept different types of geometry will need multiple overloads of the function taking a Feature<?> parameter where the different generic types would cause a platform conflict. With @JvmName this can be avoided, but complicates the Java API.
• Without a dedicated Java API, the libraries could take advantage of inline/value classes, specifically for the LngLat class. This could wrap an Array<Double>, but would be impractical to use from Java.

With the existence of Mapbox's Java port of Turf, the value of maintaining a dedicated API is questionable.

[dellisd]

Java compatibility will be maintained, but no Java-specific APIs will be provided from 0.0.4-SNAPSHOT onwards.