Re: What comes after 1.12?

On Tue, Aug 20, 2019 at 7:04 PM Branko Čibej <brane_at_apache.org> wrote:

> On 20.08.2019 17:46, Julian Foad wrote:
> > Julian Foad wrote:
> >> [...] OR
> >>
> >> * Each version can add APIs but cannot remove or break existing
> >> APIs? (Like our current rules for minor releases.)
> >
> > Reading back what I've just written, it seems I'm completely missing
> > something. If we take that approach (API changes allowed), then
> > everything I wrote doesn't seem to amount to anything that would make
> > a real difference to you.
>
> I suspect that the real issue is that a consumer of JavaHL cannot
> trivially rely on compile-time version checks to decide which version of
> the API to use (and, as a consequence, which features it can expose). In
> Java, you have to do this with class loaders and other unspeakable
> horrors. So relying on the 1.8 *API* makes a kind of sense, since we do
> promise backwards compatibility on that level.
>

At the Java source code level, yes we just write to the 1.8 API and that
works fine. The problem is delivery. We have to include that JavaHL "jar"
part of the API with Subclipse and that has to match the native libraries
because of how JNI works. We cannot use the 1.8 JAR with native libraries
from a newer version. Consequently, we have to provide Eclipse plugins for
each SVN version that delivers the right java part. This is not too bad,
the problem is the user experience in Eclipse. Its UI naturally wants to
encourage the user to install the latest version and so usually the user
runs into problems, hits a forum and maybe figures out how to uninstall the
plugin and install the right version for their native libraries. The whole
thing sucks.

On Windows, we are able to provide the Java and the native due to some
hacks we are able to exploit in how DLL's are loaded and how JNI works.
There is no equivalent that works for other OS and something about the way
JNI loads libraries makes a static build not an option either. If it were
possible for us to deliver the native libraries then there would be less of
an issue. Anyway, I am several years past the point where I would have had
enough time and interest to try to make it all work again anyway if an
option were possible.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/