Drop Java 7 support: require Java 8 (1.8) as the minimum JDK

[ntung]

Background

The current Maven build compiles with source/target compatibility set to Java 1.7
(jsbml.build.javac.source / jsbml.build.javac.target in the root pom.xml).
However, Java 7 reached its official End of Life in April 2015 and has received
no security patches or maintenance from Oracle since then.

Proposal

Bump the minimum supported JDK from Java 7 to Java 8 (1.8) for the upcoming
JSBML 1.7 release. Concretely, this means:

• Set jsbml.build.javac.source and jsbml.build.javac.target to 1.8 in the
  root pom.xml.
• Document the change in NEWS.md.

Rationale

• Java 7 EOL: April 2015 (10+ years ago).
• Java 8 is an LTS release still under active support by all major JVM vendors
  (Oracle, Adoptium, Amazon Corretto, etc.).
• Java 8 language features (lambdas, streams, default interface methods) open the
  door to cleaner API design in future work.
• No known active JSBML users have reported a dependency on Java 7.

Question for the community

Are there any users or downstream projects still running JSBML on Java 7?
If so, please comment below so we can factor that into the timeline.

[draeger]

Thanks for this issue, @ntung! I fully approve this change. However, I suggest introducing this change right after the next stable release, as it was recently also debated in #262.

[dyrpsf]

Makes perfect sense. I'll stick to Java 7 for my current PRs to ensure everything stays compatible for the stable release.

Happy to help test the Java 8 migration once we cross that bridge!

[ntung]

Thank you both for the quick feedback and support — really appreciated!

I want to make sure we're aligned on the timeline, as I see two possible interpretations:

Option A — Drop now, ship with the next release:
We update the compiler source/target to 1.8 in the current development branch right away. The next stable release (1.7) is the first to formally require Java 8, and the release notes document the change.

Option B — Ship the next release first, then drop:
We keep Java 7 compatibility for the next stable release, then bump to 1.8 immediately after the release branch is cut — giving us the entire next development cycle to clean up any Java 7 legacy code.

@draeger: Your suggestion of "right after the next stable release" reads to me as Option B. @dyrpsf: Your note about keeping current PRs Java 7-compatible also points that way.

I'm leaning toward Option B as it avoids breaking anything mid-cycle for active contributors. Could you both confirm this is what you had in mind?

[dyrpsf]

Yes @ntung , Option B is exactly what I had in mind! Keeping the current development cycle on Java 7 ensures a smooth transition without disrupting active PRs.

[ntung]

Great, that settles it — Option B it is! I will prepare the changes on a separate branch and open a pull request once the next stable release is out. Thanks again to both of you for the quick and thoughtful input!