Discussions
Categories
- 196.9K All Categories
- 2.2K Data
- 239 Big Data Appliance
- 1.9K Data Science
- 450.3K Databases
- 221.7K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 550 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 545 SQLcl
- 4K SQL Developer Data Modeler
- 187K SQL & PL/SQL
- 21.3K SQL Developer
- 295.9K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.6K Development Tools
- 107 DevOps
- 3.1K QA/Testing
- 646K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 155 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 18 Java Essentials
- 160 Java 8 Questions
- 86K Java Programming
- 80 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 204 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 439 LiveLabs
- 38 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 171 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 232 Portuguese
Applet comprising multiple packages
Hi.
In the book "Java Card Technology for Smart Cards" by Zhiqun Chen in the 3.9 there is application developement process is described and something mentioned that got my attention:
"*If an applet comprises several packages, a CAP file and an export file are created for each package*".
Could anyone please show an example of an applet comprising several packages?
I am not sure I understand the conception. Right now in my developement I have a few packages and a couple of applets in each package, but not the other way around. How can applet comprise a package?
If there is such an example, a new question it raises: how can applet's objects from one package access its own methods from other package (unless it's in class that implements Shareable)? Would the java card firewall allow it? Because it seems to me, it shouldn't, since the other package means another context.
Please, help me out here. Thanks.
In the book "Java Card Technology for Smart Cards" by Zhiqun Chen in the 3.9 there is application developement process is described and something mentioned that got my attention:
"*If an applet comprises several packages, a CAP file and an export file are created for each package*".
Could anyone please show an example of an applet comprising several packages?
I am not sure I understand the conception. Right now in my developement I have a few packages and a couple of applets in each package, but not the other way around. How can applet comprise a package?
If there is such an example, a new question it raises: how can applet's objects from one package access its own methods from other package (unless it's in class that implements Shareable)? Would the java card firewall allow it? Because it seems to me, it shouldn't, since the other package means another context.
Please, help me out here. Thanks.
Tagged:
Best Answer
-
An applet will only ever be in one package. What they are referring to, is an applet that uses several packages. Each package is a separate CAP file. If a package does not have an applet it is a library package and is treated slightly differently (check the JCDK documentation for an explanation). Each package that is used by another package needs an EXP file to convert against. A library package is treated a little differently by the firewall. The instance data contained in it belongs to the applet context that created.
Cheers,
Shane
Answers
-
An applet will only ever be in one package. What they are referring to, is an applet that uses several packages. Each package is a separate CAP file. If a package does not have an applet it is a library package and is treated slightly differently (check the JCDK documentation for an explanation). Each package that is used by another package needs an EXP file to convert against. A library package is treated a little differently by the firewall. The instance data contained in it belongs to the applet context that created.
Cheers,
Shane -
As quoted by thread's author the phrase in the book (famous book in java card community then?), they use the verb "comprise" and normally, we understand that, an applet contains some java packages.
I'll totally agree with safarmer if we explain the phrase such as what he/she did. In the java card world, it's meaningful and logically correct.
Best regards,
BinhLH -
Hai-Binh LE wrote:It is the only useful book I have found on the topic. Granted I have not looked very hard, but this book was enough to get me started.
famous book in java card community then?
Cheers,
Shane -
Thank you very much for all your answers. It makes sense now.
One more question. If I write an applet and a library package. If I install it on the card where other applets are already installed (or will be installed), is it possible for other applets to access my library package?
So, my question is, is library package linked somehow with one applet or is it common and anyone can use it?
Thank you. -
Pyotr Petrov wrote:To load a CAP file (package) onto a card, all externally referenced packages must already be on the card. When you convert your packages, you need to have the EXP files for any libraries available so that you can link to them. The JCDK packages are (mostly) handled for you so this is why you do not see this for those packages.
One more question. If I write an applet and a library package. If I install it on the card where other applets are already installed (or will be installed), is it possible for other applets to access my library package?
So, my question is, is library package linked somehow with one applet or is it common and anyone can use it?
Any package loaded after your library could technically access the package. Just remember than any instance data is owned by the applet that created it and is not accessible across the firewall.
Cheers,
Shane
This discussion has been closed.