Re: [jgit-dev] Java NIO Options

[Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>]

----- Ursprungligt meddelande -----
> Från: "Roberto Tyley" <roberto.tyley@xxxxxxxxx>
> Till: jgit-dev@xxxxxxxxxxx
> Skickat: torsdag, 29 maj 2014 10:05:30
> Ämne: [jgit-dev]  Java NIO Options
> 
> 
> 
> On Wednesday, 28 May 2014, Shawn Pearce < spearce@xxxxxxxxxxx > wrote:
> > 
> > Right, we are (still!) targeting Java 5 and Java 6 platforms. So we
> > can't go crazy and use Java 7 NIO features throughout the core part of
> > the JGit library. But we can do it through some minimal sections that
> > are important and easily isolated, like symbolic link support.
> > 
> > There has been talk about dropping Java 5, but not 6 compatibility.
> > Unfortunately there is no plan of action to actually do that.
> 
> 
> For those curious (like me) about what might have a bearing on the decision
> to drop Java 5 compatibility, here's are the factors that I know of (being a
> bit of an outsider to the process):
> 
> 
> 
> 
> EGit (which apparently aims to support at least the latest two Eclipse
> releases) still targets Java 1.5:
> 
> http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg01953.html
> https://github.com/eclipse/egit/search?q=Bundle-RequiredExecutionEnvironment
> 
> ...and Java 1.6 requirements are only just starting to percolate into Eclipse
> itself. Eclipse Luna (not yet released) has some Java 1.6 reqs, but core
> components (org.eclipse.core.filesystem, etc) still have a minimum execution
> environment of 1.5 - so not much pressure/invitation to upgrade there:
> 
> http://www.eclipse.org/projects/project-plan.php?planurl=eclipse/development/plans/eclipse_project_plan_4_4.xml

I think the common required platform should be our reference, i.e. if some components of Eclipse
requires 1.6 (or 1.7 or whatever) then we can do the same. The latest EGit/JGit should work in
the two latest releases, which means we will have to wait one release.

> Platforms where Java 6 is not available: For example, on OpenVMS at one
> point, JGit was the only working Git client - there was no port of the C
> client available, and OpenVMS only had Java 5 available. Not sure if this is
> still the case, and I see some indication that Java 6 is available for at
> least some versions of OpenVMS.

To me, despite VMS being the best engineered OS of all times, it's obsolete.
If you want to keep JGit up-to-date on that platform, better keep Java up-to-date
too, and we can add some tweaks to support some of its idiosyncrasies.

> Android: There's never been an exact correlation between Android's class
> library and a specific Java version, but the closest approximation is Java 6
> (some Java 6 classes like java.util.Deque weren't added until Android API
> version 9). Personally, as the author of Agit, I'd now be happy to develop
> to Ice Cream Sandwich (Android API version 15) as a minimum. Unfortunately
> many Java 7 classes (like the whole of java.nio.file.*, including 'Path')
> aren't available even in the latest version of Android.

We won't break JGit on Android just so we can use the shiniest API's, but Dalvik
isn't on the official list of supported platforms. You'd better be vigilant and
follow the patches in Gerrit and the nightly builds to block accidental breakage.
We don't even have anyone that watches Windows compatibility it seems, though JGit 
is certainly used by a lot of Windows people.

I'm curious: Does the Java 7 add-on load on Android and then break at run-time?
The only intentional check now is whether the VM can load a class by a certain
name. If it loads we assume it will work, but it uses the Path API a lot.

Essentially, what I wanted from Java 7, is neatly managed as an add-on. There
are a couple of small things that other people want that can go into the Java7
add-on too. (And some that don't).

-- robin