This discussion is archived
3 Replies Latest reply: Feb 13, 2013 9:46 AM by safarmer RSS

What Java compiler for Java Card development ?

fgrieu Newbie
Currently Being Moderated
What Java compiler and options should be used for Java Card development with the goal of generating correct, and (secondarily) small or/and fast code after conversion to Java Card bytecode using converter ?

In particular

- Is use of JDK 7 approved by Oracle for Java Card development? That would solve security problems associated with (the web components of the JRE of) some earlier JDK, including the latest JDK6. The JCDK 3.0.4 release notes states "+the commercial version of Java Development Kit (JDK software) version 6 Update 10 (JDK 6 Update 10) or later is required+, but that does not answer that question.

- Anyone had _bad_ experience (like incorrect or disastrous code) with the Java compiler bundled with Eclipse ? I have seen at least one case where org.eclipse.jdt.core_3.7.3.v20120119-1537.jar produced slightly more compact code than javac.

- Anyone had _bad_ experience with javac in jdk1.3 ? In an applet involving a "finally" clause, I've seen it generating more compact code than later javac (which in my test triplicated the code for the finally clause).
  • 1. Re: What Java compiler for Java Card development ?
    safarmer Expert
    Currently Being Moderated
    What Java compiler and options should be used for Java Card development with the goal of generating correct, and (secondarily) small or/and fast code after conversion to Java Card bytecode using converter ?
    -target -source may be required to generate compatible byte code. Depending on the CAP file converter being used debug information may also help. Remember that Java Card is a subset of the Java language (also there are short opcodes that Java doesn't have etc) so a lot of the work for optimisation is done by the converter or the JCRE. You can look at the JCA code generated to determine what works best for your applets. There are also some ways of stripping out dead code etc from JCA files (return statements after a throw etc) to reduce your code size. Most of the speed optimisations come from your code (avoiding context switches and unnecessary security/access checks).

    The compactness of your Java Card binary may not be directly related to the size of your compiled Java code. It can depend on the converter you use and any optimisaitons the JCRE might try to do when the code is loaded.
    - Is use of JDK 7 approved by Oracle for Java Card development? That would solve security problems associated with (the web components of the JRE of) some earlier JDK, including the latest JDK6.
    Java Card does not use any of the libraries from the JDK/JRE. All of the libraries are provided by the JCRE on the smartcard.
    The JCDK 3.0.4 release notes states "+the commercial version of Java Development Kit (JDK software) version 6 Update 10 (JDK 6 Update 10) or later is required+, but that does not answer that question.
    Anything above JDK6u10 is supported. If you use Java 7 you may need to add a -source and -target flag when compiling.
    - Anyone had _bad_ experience (like incorrect or disastrous code) with the Java compiler bundled with Eclipse ? I have seen at least one case where org.eclipse.jdt.core_3.7.3.v20120119-1537.jar produced slightly more compact code than javac.
    We generally use the Eclipse compiler as we find that we get more deterministic builds. When CAP files are sent for security review it is helpful to have the reviewer able to generate a CAP file that matches the one you sent to confirm the binary is what you say it is.
    - Anyone had _bad_ experience with javac in jdk1.3 ? In an applet involving a "finally" clause, I've seen it generating more compact code than later javac (which in my test triplicated the code for the finally clause).
    We do not use anything less than Java 6 for compilation.

    - Shane
  • 2. Re: What Java compiler for Java Card development ?
    fgrieu Newbie
    Currently Being Moderated
    Shane, thanks for your advice !
    Depending on the CAP file converter being used debug information may also help.
    <strike>Any example of that ? In my test, -g:none either does not change the Java Card bytecode compared to -g, or makes it slightly more compact.</strike>
    Update: Indeed! -g:none generates longer code than -g . In particular, the later allows converter to remove a few unnecessary s2b opcodes. Nice.
    Are you referring (here or in the next statement I quote) to a CAP file converter other than the ones supplied by Sun/Oracle in the public JCDKs?
    The compactness of your Java Card binary may not be directly related to the size of your compiled Java code. It can depend on the converter you use and any optimizations the JCRE might try to do when the code is loaded.
    Is it to say that, in some actual practice,the JCRE or the loading process transforms/optimizes the Java Card bytecode beyond what converter already did ?
    We do not use anything less than Java 6 for compilation.
    I understand the rationale. However when doing so, quite a few statements still in the JCVM (Classic) specification regarding the implementation of the exception mechanism seemingly no longer apply, like "The jsr instruction is used with the ret instruction in the implementation of the finally clause of the Java language". In my experience the combination of Javac from JDK 6 or newer and any converter from Sun/Oracle never generates the jsr/ret opcodes, and whatever is in a finally clause appears 3 times in the Java Card (Classic) byte code. Do I miss something, like options to be passed to Javac, or some better converter?

    Edited by: fgrieu on Jan 23, 2013 7:31 AM
  • 3. Re: What Java compiler for Java Card development ?
    safarmer Expert
    Currently Being Moderated
    Depending on the CAP file converter being used debug information may also help.
    <strike>Any example of that ? In my test, -g:none either does not change the Java Card bytecode compared to -g, or makes it slightly more compact.</strike>
    Update: Indeed! -g:none generates longer code than -g . In particular, the later allows converter to remove a few unnecessary s2b opcodes. Nice.
    Are you referring (here or in the next statement I quote) to a CAP file converter other than the ones supplied by Sun/Oracle in the public JCDKs?
    Yes. I am referring to both the Oracle/Sun converters and proprietary converters as well. Different JC vendors have different converters. While they are compliant with the standard they also produce CAP files that are different. This difference could be as simple as ordering, while others may be bytecode optimisation for their platform.
    The compactness of your Java Card binary may not be directly related to the size of your compiled Java code. It can depend on the converter you use and any optimizations the JCRE might try to do when the code is loaded.
    Is it to say that, in some actual practice,the JCRE or the loading process transforms/optimizes the Java Card bytecode beyond what converter already did ?
    Having never implemented a JCVM myself, I am going on second hand information, but there may be some optimisation of code and reorganising of data at load time. This is of course implementation dependent.

    >
    We do not use anything less than Java 6 for compilation.
    I understand the rationale. However when doing so, quite a few statements still in the JCVM (Classic) specification regarding the implementation of the exception mechanism seemingly no longer apply, like "The jsr instruction is used with the ret instruction in the implementation of the finally clause of the Java language". In my experience the combination of Javac from JDK 6 or newer and any converter from Sun/Oracle never generates the jsr/ret opcodes, and whatever is in a finally clause appears 3 times in the Java Card (Classic) byte code. Do I miss something, like options to be passed to Javac, or some better converter?
    I have not looked into this before. Luckily I don't have to target anything earlier than JC 2.2.2 any more and as such Java 5 is the oldest compiler I have to worry about.

    - Shane

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points