JavaCardTODOs

This is the list of todos for NetBeans 6.8 and beyond, in order of priority.

Items in boldface need further info from the Java Card team to be translated into specific action items.

Items in italics are ones which either may be unimplementable, or not implementable within the 6.8 time frame.

NOTE: See the Java Card Libraries page for important issues in need of feedback specific to correctly implementing library support for Java Card projects.

DO NOT ADD ITEMS TO THIS PAGE. These issues are now tracked in Issuezilla umbrella issue 170636. For an overview of progress, see that issue's dependency tree. If you need to add items to this list, create a corresponding issue (FEATURE or ENHANCEMENT), and set it to block issue 170636, rather than modifying this page.

P1

Debugger Integration

  1. populating all dependent jar/war/ear/ and adding to proxy classpath
  2. If cjcre.exe is running and not remote, need to offer to stop it and restart it in debug mode
    1. Debug mode is project specific, and must be passed a classpath containing all classes that can be debugged
    2. Either Ant task or NetBeans action (ideally both) need to
      1. Collect the entire dependency tree of all dependent projects and deploy them in dependency order
  3. Phase 1 will only collect dependency tree of the current project (will be built into generated build-impl.xml)
  4. Phase 2 will try to collect full dependency tree of all dependent projects and pass that in
    1. This may not be possible at all
    2. This may only be possible when running in the IDE, and broken from command-line Ant
    3. How does this relate to .exp files for raw JAR files
    4. Cyclic dependencies are not allowed
    5. Given Dependencies A -> B -> C ->D and also B -> D and A -> E, will there be any problems linking A -> D? Need algorithm for collapsing the dependency tree into a deployment order list .There will be no issues linking A->D as long as D is the first one that is deployed.
  5. Need info on how .exp files are passed in, vis-a-vis how dependent projects are handled.
    1. Are there ordering issues here - i.e. if a project depends on
      1. FooProject (build will run deploy target for fooproject)
      2. Bar.jar w/ .exp file

do we need to handle this in dependency order?

      1. This will determine how we store external jar metadata

Changing the folder tree structure - to sync with J2EE web apps

Project dependency

  1. Compile time only (Simple thing)
    1. Need to relativize paths to dependent JARs/projects
  2. Run will deploy all dependent library projects first in the dependency order (a bit complicated)
    1. Cannot use existing library support for Java projects due to special requirements for Java Card Projects:
      1. Dependent projects must be deployed in dependency order
      2. Dependent projects must deploy their dependencies in dependency order
    2. Need to include project dependencies in project.xml
    3. Need to regenerate build-impl.xml for project when dependencies change
    4. Need separate handling for vanilla JAR files on classpath
    5. Need option for each library to determine if it should be deployed, or if the project should expect it to simply already be on the device
  3. Option x deploy dependent libraries first
    1. If turned off, deploy only the project itself
  4. Option to start the device automatically or not when a Project is run. This lets us to run our cjcre for debugging puposes.
    1. Needs to be stored in project properties and added to the general Run customizer
  5. Need to update the project updater so that new format project.xml will be generated and build-impl.xml based on it generated
    1. Testing of this will be very time consuming and must be exhaustive to make sure we are not breaking anybody's existing projects - once opened in the updated Java Card modules, the project will no longer be usable in earlier versions

P2

Popup Menu things

  1. "Generate Proxys" menu for Classic applets and classic libraries. Proxies simply wrap existing shared interface objects to add synchronization, because Java Card 3 is multi-threaded, but pre 3.0 is not
    1. No choice about generating sources, it's part of the spec (would be preferable to bytecode patch all methods on shared interface objects to be synchronized - which is the purpose of this - but too late for that wrt the Java Card spec)
    2. Use a generated sources dir or generate into real sources dir?
    3. Who generates the proxy code, and what does it look like? .Java Card tools (Converter) generates the proxy code. It generates .java files first and then compiles them into classes. By default this happens transparently while creating bundle. There is a special option to converter to say that keep the java files and use them instead of re-generating. The proxy classes are more like a delegate class, delegating all interface call to actual implementation calls.
      1. Keep MD5 hash of generated sources to detect user modification?
      2. Or make proxies non-editable via guarded blocks?
  2. This is a bit complicated, but VERY nice to have. Needs to discuss.
  3. Remove "Run" for Library projects

Customizer Things

  1. "Run" customizer is empty for extended applets.
    1. Believe this was fixed before integrating into NetBeans hg repository, needs verification
  1. Enhance Security Customizer
    1. keystore file
      1. Need to read keystore file and ask which certificate to use if multiple certificates
    2. alias
      1. Unclear what this means in this context .This is just a String identifying some thing in the keystore. Mostly that something is a private key stored. Think that this keystore is a Hashtable, the alias is the key for an entry.
    3. password
      1. This is a security risk. Options:
        1. Store it in the clear in project.properties
        2. Store it in the clear in private.properties (a user checking out from version control will need to get the password from someone)
        3. Do either of the above with minimal obfuscation (as Mozilla stores passwords base64 encoded)
    4. Need password for keystore itself
      1. Same security issues as above
    5. Also need password for specific certificate within keystore
      1. Any way to detect when there is no password/passphrase for a certificate? This is a relatively common case during development. .No need to. There will always be a password. If we don't give a password there will be a default password by the keytool.
  1. Classic projects need a flag to say "Use Proxies" in "Build" customizer
    1. So when do the proxies get generated?
      1. At build time? .By default at build time. But with the popupmenu (in previous section) developer can generate on-demand, and would want to use the source code that was generated. This is mostly for the advanced users who knows what they are doing. Assume that this popup action is to generate a skeleton for the first time. Just a helping option from the tools. After that developer may want to modify it and use it. This option "Use Proxies" will tell the tool that "DO NOT generate the proxies, instead, use the sources for proxies"
      2. At development time? .Explained above.
      3. User visible or not? .Explained above.
  2. Projects: When a library (jar) is added as dependency, we need to ask for "Export Path" of the associated export (.exp) file.
    1. What is this file? .JavaCard2 is a split VM. The class files are converted into CAP, which is kind of Execution In Place format. There will be no more linking required for a CAp file. Each method and filed is replaced by some Token numbers, which are fixed. For example Applet.process(0 method may have Token numbers for package, class and method 10, 20, 30 respectively and it cannot be changed. The export file contains this information for each class. Think it as symbol table. Each package must have an export file. for example javacard.framework will have an export file called frameword.exp. The .exp file must be placed under the package tree in a subfolder called javacard. For example framework.exp file should be under javacard/framword/javacard folder. The export path is wherever the javacard folder is starting. almost same as classpath, except that it has it's own package hierarchy. If there is a sub package javacard.framework.services, then there will be an export file javacard/frameword/services/javacard/services.exp. The last token of the package name is used as the file name with extension .exp.
    2. How is it created?
      1. Converter tool creates and puts them in appropriate places.
    3. Who creates it? .Build step automatically creates these for classic-type projects.
    4. What do we do if it doesn't exist? .For the project itself, it doesn't matter. But is there is another classic project which depends on this one, the dependent project will fail to build.
      1. Unbundle the jar's classes and bundle them into the jar we deploy? .NO. There will be other issues with this approach. What if that jar needs some other classes which are not available for us? In real scenario, these jars will have the empty classes just for compilation. There will be no implementation in them.
        1. This will not work for classic projects which can only have a single package.
      2. Don't allow use of the JAR .Not a good choice. Typically the SIM application developers depends on SIM jar file. If we don;t support then SIM application developers are unable to use the tools. We need to have this support.
      3. Something else? .No other option. Build fails. This is a must thing. In JavaCard2 (or JavaCard3 classic) world, if you are using a third party library, you must have corresponding .exp file. Otherwise that library is not usable.
  1. "Run" choosing different Servlet/page seems to be not saved.
    1. Will file bug and note here
  2. Platform-Device customizer- Unable to change the settings (for ex RAM size) once the device is created.
    1. Tim: Double check this with current builds - I know I fixed this once
  3. Servlet wizard has NPE problem (Make sure all wizards working)
    1. Need stack trace from current dev build, existing stack trace shows exception on empty line

java.lang.NullPointerException at org.netbeans.modules.javacard.templates.ServletDeploymentWizardPanel$1.run(ServletDeploymentWizardPanel.java:78) at org.openide.util.Mutex.readAccess(Mutex.java:362) at org.netbeans.modules.javacard.templates.ServletDeploymentWizardPanel.<init>(ServletDeploymentWizardPanel.java:72) at org.netbeans.modules.javacard.templates.ServletWizardIterator.getPanels(ServletWizardIterator.java:109) at org.netbeans.modules.javacard.templates.ServletWizardIterator.current(ServletWizardIterator.java:212) at org.openide.loaders.TemplateWizard$InstantiatingIteratorBridge.current(TemplateWizard.java:980) at org.openide.loaders.TemplateWizardIterImpl.current(TemplateWizardIterImpl.java:140) at org.openide.loaders.TemplateWizardIteratorWrapper.current(TemplateWizardIteratorWrapper.java:89) at org.openide.WizardDescriptor.updateStateOpen(WizardDescriptor.java:863) at org.openide.WizardDescriptor.updateState(WizardDescriptor.java:837) at org.openide.loaders.TemplateWizard.updateState(TemplateWizard.java:731) at org.netbeans.modules.project.ui.NewFileWizard.updateState(NewFileWizard.java:118)

  1. Ability to chose between relative (or) absolute path while choosing jar dependencies. Very useful if we commit the project into workspace.
    1. SharabilityQuery handles this fairly well and is the standard for handling this in NetBeans projects. Should be easy to implement. Currently it seems the default in NB projects has been changed to relative paths if they are on the same volume - this is probably a better default. Should be fairly trivial.

Classic Project types (applet and Library)

  1. New Class/Package into a different package for classic app/lib should not be allowed. Only one package is allowed for classic type apps. And
  2. Another package which is subpackage of the original package with the name "proxy".
    1. Ex: a.b and a.b.proxy are allowed.
    2. a.b and a.b.c is not allowed.
    3. a.b and a.b.proxy.c is not allowed.
    4. It is probably impossible to prevent creation of new folders/packages under the source root of a JavaCard project without API changes in NetBeans infrastructure:
      1. Filesystems API - ability to veto creation of a new folder under a certain folder (including paste operations
      2. The Loaders API (some hook to block createFromTemplate() under certain folder)
      3. The New Package template UI
      4. The New Folder template UI
      5. Refactoring API - to determine if a brief appearance of multiple packages should be blocked or not and use that when deciding whether or not to veto package creation
    5. This is probably unimplementable for a number of reasons:
      1. Requires high-risk API changes from code belonging to other teams
      2. Many operations legitimately create folders in the short term:
        1. Refactoring a package means there will briefly two packages in a Classic app project - the new package is created, the files are moved, then the old one is deleted.
    6. The package is generated at build time? .Depends on how the developer wants it.
      1. Should it even be user-visible? .If auto-generated, then not visible to the user. But if uses chooses "Generate Proxy" and "Use my proxy" options, then that means the project has this package at the src.
      2. See questions above about who generates the code

Cleanup templates -- all templates should have complete comments and the default code.

  1. Anki will be doing this work

For classic applets -- javacard.xml needs to be read only and everytime build happens the file gets updated with the new generated javacard.xml. But the file is not for the developer to edit.

  1. Anki to modify Ant task to generate this file
  2. Can use magic editor comments to make the file editable, and add warning comment that it is regenerated on the fly

Ability to run/debug clients running on remote host

  1. Add to device customizer boolean option indicating device is remote and IDE should not try to start cjcre.exe
  2. Project action changes to handle this situation correctly

P3

  1. Services Tree view. Query the server for all loaded instances and show in the tree view of each device.
    1. Initial implementation will use short timeout
    2. Longer term, need to identify failure modes and notify accordingly
  1. Solidify API and get it working with
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo