XOM API for Processing XML with Java

[Adam Constabaris <adam.constabaris AT gmail.com>]

Elliotte,

The "obvious" approach would be to set the bootclasspath attribute on the
javac task in the ant build file:

https://ant.apache.org/manual/Tasks/javac.html

This would efffectively let you use an older compiler to build the code.

However, that's going to require having the JDK 1.7 (or earlier) rt.jar
available on any machine that's going to compile XOM.  If there's a
suitably-licensed version of that jar (perhaps from the OpenJDK
distributions), you could just stuff it into the repository (e.g. into the
lib/ dir, along with xalan etc. jars), and this would make it relatively
straightforward.

I think, however, Java projects might be at the point where forward
compatibility is going to become a more pressing issue: although I can't
find documentation that states this plainly, javac on JDK 8 already warns
that source and target = 1.6 are obsolete and will be removed.  Java 9,
already released, introduced the module system which is already causing
some issues for projects that use reflection.

On top of that, there's a new release schedule for the JDK:
https://www.infoq.com/news/2017/09/Java6Month -- in a nutshell, JDK 8 has
been retroactively tagged as a Long Term Support (LTS) release, with JDK 9
and JDK 10 being interim releases, followed by JDK 11 which will be the
next LTS.  Each release of a new non-LTS version results in the previous
non-LTS version no longer being updated, and support of the previous LTS
version ends six months after the release of a new LTS version.  That is,
JDK 9 is already on its last legs, with JDK 10 due out later this month
(March 2018).

I'm not going to editorialize on these changes, other than to suggest they
give cause to reflect on what you want to support in terms of backwards
compatibility and how much effort you're willing to put into it..  Backward
compatibility comes in at least two flavours:

1. Let users of older JDKs compile XOM
2. Let users of older JDKs use XOM jars compiled by others

I think the existing and pending changes to JDK versions and releases noted
above will make supporting (2) pretty hard.  You can probably avoid having
to follow each JDK release, but even if you stick to LTS releases it will
be challenging enough to support building on the current LTS and one back
(and IIUC you want to use continuous integration, so you'll be limited by
what CI systems support).

I think (1) is already getting a bit fussy, but here you could just move
the current build system into a legacy status to provide some support for
users on older JDKs.  If that set of users includes you, you would also
have the means to publish XOM artifacts compatible with those versions, for
those who just need the binaries.  If you're interested in Maven for that
purpose, I suggest you look into classifiers, which are extra bits of Maven
coordinates that allow publishing artifacts for different environments in
the same place.  Maven also has features to allow you to build multiple
versions at the same time (although, IIUC, that would not help with the
issue that started this thread).

best,

AC

On Feb 24, 2018 4:20 PM, "Elliotte Rusty Harold" <elharo AT ibiblio.org> wrote:

OK, likely an issue with a 1.8 VM trying to run 1.6 code:




http://www.draconianoverlord.com/2014/04/01/jdk-compatibility.html


Now I need to figure out how to configure any to avoid this.



On Sat, Feb 24, 2018 at 4:14 PM, Elliotte Rusty Harold
<elharo AT ibiblio.org> wrote:
> What's really weird is that the compiler, both ant and Eclipse, finds
> JUnit but at runtime I get this error.
>
> On Sat, Feb 24, 2018 at 4:08 PM, Elliotte Rusty Harold
> <elharo AT ibiblio.org> wrote:
>> Now that I've finally got https working, I'm trying to make some small
>> fixes that have accumulated over the last few years.
>>
>> ATM the tests are all failing though, due to some weird JUnit classpath
issue:
>>
>> Can anyone look at the git repo and see what the problem is? Maybe the
>> old bundled junit.jar is borked somehow in modern VMs?
>>
>> java.lang.NoClassDefFoundError: junit/framework/TestCase
>> at java.lang.ClassLoader.deefineClass1(Native Method)
>> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
>> at java.security.SecureClassLoader.defineClass(SecureClassLoade
r.java:142))
>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
>> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
>> at java.security.AccessController.doPrivileged(Native Method)
>>
>> at java.net.URLClassLoader.findClass(URLClassLoader.java::361)
>> at java.lang.ClassLoader.loaadClass(ClassLoader.java:424)
>>
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:4111)
>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:3331)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java::357)
>> at java.lang.ClassLoader.defineClass1(Native Method)
>> at java.lang.ClassLoaader.defineClass(ClassLoader.java:760)
>> at java.security.SecureClassLoader.defineClass(SecureClassLoade
r.java:142)
>> at java.net.URLClassLoader.defineClass(URLClassLoader..java:467)
>> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
>> at java.security.AccessController.doPrivileged(Native Method))
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:3661)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:264)
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:3881)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>> at java.lang.ClassLoader.loaadClass(ClassLoader.java:357)
>>
>>
>>
>> --
>> Elliotte Rusty Harold
>> elharo AT ibiblio.org
>
>
>
> --
> Elliotte Rusty Harold
> elharo AT ibiblio.org



--
Elliotte Rusty Harold
elharo AT ibiblio.org
_______________________________________________
XOM-interest mailing list
XOM-interest AT lists.ibiblio.org
https://lists.ibiblio.org/mailman/listinfo/xom-interest