Clarify targeted Java version

[dbaston]

I'm not able to find anything in the POM files or project documentation that states which version of Java is targeted by JTS. (Does Maven default to Java 5?).

[dr-jts]

Would be nice, especially once #146 is resolved.

Perhaps Java 1.7? Not sure there's any point in staying with 1.5. I think TestBuilder needs 1.7 for finicky Swing API reasons.

[dsmiley]

I think the point here isn't the merits of one version over another, it's about the pom stating the version explicitly: https://github.com/locationtech/spatial4j/blob/master/pom.xml#L172 IMO every project ought to do this explicitly (and vast majority do); it's a shame Maven doesn't make you because it's presumptuous to depend on the JVM the user is using to run Maven itself.

[dr-jts]

@dsmiley Fair enough. But in order to state the version we first need to decide what the version should be.

[dr-jts]

Are there actually two issues here? Which Java to use for compiling, and which versions JTS will run on? And is there a relationship between them? I.e. if we compile with 1.7 can it still run on say 1.5 or even earlier?

[dbaston]

I don't have experience targeting an earlier Java version than what I'm compiling on, but it seems like it could complicate project development and testing (developers would need to verify that standard library methods used are in fact available in the earlier versions, and that they behave equivalently, right?)

Is JTS used on platforms that do not support Java 8? (whether the project wants to use Java 8 features being another matter)

[mprins]

FWIW you can just add the following properties to the parent pom:

<properties>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
        ....

for java 8 (or 1.7 for java 7 or...), by default maven uses 1.5 because that is what the compiler plugin is defined to do.

IMHO, since the new release will also be a change in groupId I'd say it would be a safe bet to pin to 1.7 (unless you want to use closures etc..)

[jnh5y]

Can we pick a source and target version for the 1.15.0 release?

[jnh5y]

Generally, I'd suggest one of two options:

A. Be conservative, and pick something like 1.5.
B. Note that Java 7 has been EOL'ed for over two years, and pick Java 1.8.

[snodnipper]

just for the record, we use JTS for Android apps. Java 1.8 on android is pretty sketchy - some Java 1.8 classes / methods are unsupported depending on android version etc. Conservative is good for us 👍

https://developer.android.com/studio/write/java8-support.html

[jnh5y]

@snodnipper Do you know anything we can use in a Maven build to verify/check that JTS would be compatible with Android? (It sounds like Android compatibility will not be captured entirely by the Maven/compiler language version targeting options.)

Overall, I'd like to see JTS be as useful as possible while at the same time letting the project leverage as many Java features as possible.

[snodnipper]

@jnh5y - elegantly no. Typically, one would build with the Android gradle build tools, which have all kinds of lint checks. There is the android-maven-plugin but I haven't used that for years.

Practically, 1.7 should be fine and CI building/testing with the Android build tools would give feedback without everyone having to install the Android SDK. 1.8 syntax can be ok too but clearly there are API chunks missing for many devices - where the app would terminate.

okhttp is an example of a maven project with Android artifacts.

We use CircleCI for feedback ourselves, our search repo is an (old) example.

[dr-jts]

So is the TLDR: target JTS to build on 1.7 ?

If so, that seems reasonable to me.