1 Reply Latest reply on Feb 13, 2013 5:49 PM by safarmer

    LEGAL enabling of @Override when restricting to JC Classic APIs?

      I like to precisely control the classpath used by javac, in order to catch at compilation time any accidental reference to a class that is not built into the Java Card (Classic) API of a particular target.

      Something on the tune of
      <tt> javac -bootclasspath C:\JCDK3.0.4_ClassicEdition\lib\api_classic.jar </tt>
      does that for an hypothetical Java Card Classic 3.0.4 platform, with one problem: annotations such as<tt> @Override </tt>no longer work, and cause a syntax error.

      I had hopped
      <tt>javac -bootclasspath C:\JCDK3.0.4_ClassicEdition\lib\api_classic.jar;C:\JCDK3.0.4_ClassicEdition\lib\api_classic_annotations.jar</tt>
      would fix it; but not: my guess is that at least<tt> java.lang.Override </tt>was forgotten in the build of<tt> api_classic_annotations.jar</tt>

      The following allows<tt> @Override</tt>
      <tt>javac -bootclasspath C:\JCDK3.0.4_ClassicEdition\lib\api_classic.jar;C:\JCDK3.0.4_ClassicEdition\lib\api_classic_annotations.jar;C:\JCDK3.0.4_ClassicEdition\lib\api_connected.jar</tt>
      but then an accidental use of some connected API is not caught. It is also possible to add in the bootclasspath a<tt> rt.jar </tt>from a JRE/JDK, but that similarly adds a lot of classes not actually usable in a Java Card Classic context.

      It would be technically feasible to extract from<tt> api_connected.jar </tt>or<tt> rt.jar </tt>the bare minimum needed to restore annotation functionality; but that seems to be a violation of the licensing terms, which do not allow any modification of the licensed software, with no exemption for the deletion of unwanted sections from packaged jar files. Is there a legal solution?

      Does that also apply to the similar problem that
      <tt>javac -bootclasspath C:\java_card_kit-2_2_1\lib\api.jar</tt>
      is not usable, although it would be potentially useful for Java Card platforms still very much used in the field? (Note: my guess is that at least<tt> java.lang.Error </tt>was forgotten in the build of<tt> api.jar</tt>, and that one was fixed in<tt> api_classic.jar </tt>of the JCDK3).