Hi Sebb,

 Hmm, not sure about this. As long as we use the 1.3 Java class format Java
1.3. deployed applications can take advantage of BSF and will be able to
take advantage of improvements to BSF 2.x. The moment we change to the 1.4
class file format, this clientel gets locked out. I would assume that quite
a few deployments may be affected by this.

Well, at the moment the classfile format is not specified.
Perhaps using source 1.3 forces target 1.3, but it would be better to
be specific.

 Therefore, I would suggest to change the class file format to 1.4 (or
higher) only, if we truly take advantage of new features of those versions
of Java in the BSF framework itself.

BSF won't currently compile using Java 1.3, because it uses
java.util.regex in at least one class. Perhaps that was a mistake.
Just ran a compilation on 1.3 and there are two engines that fail (but not the BSF framework itself):

   * Jython (java.util.regex), and
   * XSLTEngine (javax.xml.transform, javax.xml.stream, org.w3c.dom.Node)

Compiles cleanly with JDK 1.4.

 BSF engines that depend on higher class file formats (or functionality
introduced with later versions of Java) should indicate this dependency
explicitly.

Should. It's often hard work finding out what Java versions are required...
Right, because of BSF, I kept different JDKs from 2000 onwards, and am therefore able to create "clean" environments for compiling Java programs from 1.1 through 6.

After all, I would not object to augment the level to 1.4.

---rony



Reply via email to