You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
And, even though it's a simple recompile, when it's a dependency of a dependency of a dependency, it can be harder to have it all working well together (e.g. wdtinc/mapbox-vector-tile-java#48 did not make any new release).
Thumbs up for this issue, as we are stuck in the dependency problem as well:
We are using a dependency which itself uses jts-core. Our dependency tries to stay Java 7-compatible, therefore still stays with jts-core 0.15, whereas our app supports Java 8 and we generally try to use most-recent versions of our included dependencies (to have bug fixes and other improvements included). Due to the breaking interface change in 0.17 we cannot update, though, in this case.
Any chance to get this back to binary compatible in a future version?
The change in JTS 1.17 makes it impossible to use newer version of JTS because it's not binary compatible
java.lang.NoSuchMethodError: org.locationtech.jts.geom.Polygon.getExteriorRing()Lorg/locationtech/jts/geom/LineString;
And, even though it's a simple recompile, when it's a dependency of a dependency of a dependency, it can be harder to have it all working well together (e.g. wdtinc/mapbox-vector-tile-java#48 did not make any new release).
An even simpler solution would be keeping binary compatibility. That could be achieve would a bridge method as described in https://www.morling.dev/blog/refining-return-type-java-methods-without-breaking-backwards-compatibility/
The text was updated successfully, but these errors were encountered: