I am working on a project related to java card applet development. My project consists of 4 java classes which are used to store date of created objects, and a java card applet which contains method that enables me to de some kind of actions on the created objects, such as create a new object of a specified class or edited it and son on.

Now I have 2 classes done ; first one is called Odemeler which contains variables of type byte and the second one is called SadakatUygulamalar which contains variables.

Inside the class I have defined 2 arrays, one of type Odemeler and the other of type SadakatUygulamalar and I set their size to be 200. I have tried to create 100 object of kind Odemeler and to store them in the arraybut the applet is able to store up to 92 object, at the other hand after creating those objects and storing them I am not able to store objects of type SadakatUygulamalar.Is this problem related to the applet size or what ?? any help please

You should refer to Javacard 2.2 Virtual Machine (or 2.1 if you are using that version),
some of limitations are as follows:

Package References: A package can reference at most 128 other packages.

Package Name: The fully qualified name of a package may contain a maximum of 255 characters. The package name size is further limited if it contains one or more characters which, when represented in UTF-8 format, requires multiple bytes.

Classes in a Package: A package can contain at most 255 classes and interfaces.

Interfaces: A class can implement at most 15 interfaces, including interfaces implemented by superclasses. An interface can inherit from at most 14 superinterfaces.

Static Fields: A class in an applet package can have at most 256 public or protected static non-final fields. A class in a library package can have at most 255 public or protected static non-final fields. There is no limit on the number of static final fields (constants) declared in a class.

Static Methods: A class in an applet package can have at most 256 public or protected static methods. A class in a library package can have at most 255 public or protected static methods.

Methods: A class can implement a maximum of 128 public or protected instance methods, and a maximum of 128 instance methods with package visibility. These limits include inherited methods.

Class Instances: Class instances can contain a maximum of 255 fields, where an int data type is counted as occupying two fields.

Your problem is most likely related to the fact that you are calling byte[] foo = new byte[size] a lot in your code. There is no garbage collector so you are probably running out of space on your card.

You need to allocate your memory up front in your applet constructor. This way you will find out at install time if you have enough space to store everything. You will also not have to worry about resources at runtime then.

Shane,
in most cases, we don't know how much files will be created.in this case, if we allocate all memory in the constructor function,we should allocate a huge memory,but it may be a big waste.so sometimes we still need to dynamic allocate memory even if it is at the risk of run out memroy.anyway,it is not easy to choose.

Although that might not be the direct cause of the problem observed, this code is an extreme example of overly repetitive coding. That coding style is passable on a computer where its cost will not blatantly show, and is actually encouraged by usual productivity metrics. It is not good in a resource-constrained environment like a Smart Card.

For example:
The 15 counters in odemeCreateProfile are clear candidates for arrays and an overall loop.
The constructor for Odeme should be re-factored to accept most of its parameters concatenated in a single array (perhaps as concatenation of TLV).
The at least 13 getTarih..getKazanilanpuan methods should be just one, returning the concatenation of the desired fields (all of them, or perhaps a selection given in parameters, e.g. as a bitmap).

My advice is to generalize what the code does until the nature of the data items manipulated (Tarih..Kazanilanpuan) never appear in a method or variable name, except as the name of a final static variable (that is, as a constant).

When that's done, I guess the number of methods, variables and objects will have been be reduced by nearly a decimal ordrer of magnitude, and the code size also reduced. It will be much easier to determine which limit of the runtime platform is exceeded, should there remain any, and correct that.

As an aside, one Java Card runtime I have been exposed to happened to have undocumented limits on the number of local variables a method can have, and at least odemeCreateProfile exceeds that (BTW, non-imbricated loops can use the same loop variable, and I there's a javac/converter/settings combo that manage to overlay different variables to the same stack location when that's possible, I want to know).

Also, defensive Java Card coding requires to allocate all objects at applet installation, for multiple reasons including because that's the only sure way to avoid out-of-memory conditions later, under the assumption that another applet either gets installed, or does not follow that convention. There is currently no consideration for that in the code.

I agree with you,,
But because I am a newbie to java card subject I did not find any way to seperate between variables when sending them to the applet, for example inside the Odeme class I have 14 variables, and I do not know how to seperate between them
so the solution I have found is to add a special character such as comma after each variable to distinguish between them.

But here you are talking about TLV, I have serched alot over the internet about this subject but I do not find any thing related to it, So could you please explain to me how to create a new object using TLV instead of using 14 counters in the code above ?

TLV stands for Tag (or Type) Length Value. Simplifying just a bit, the idea is to have a single byte[] array holding several data elements, each starting with a tag byte stating its type, a length byte stating its data length, and its data. It is then possible to manipulate (read, write..) an element designated by its tag, using the same code, accepting the tag as a parameter.

Some pack tag and length in the same byte. There is at least one standard allowing tag and length to have a variable number of bytes. There is even built-in support for that in modern Java Card Classic, see
JCDK3.0.4_ClassicEdition/docs/api/javacardx/framework/tlv/BERTLV.html
Caveat: it might not be available on a given card (euphemism). But it is not too hard to write a small library or class to do this.

Thank you fgrieu for your clear explanation but really I am not able to rewrite the code using the BERTLV class. The issue is that when I send the command APDU through android activity I take date from user and then but thoıse date in arrays and send them to the applet,
When I did it, I did not have any other ideas related to this, otherwise I will not be able to retreive the correct data.

Again, could you rewrite the createOdemeProfie() method code using TLV ??

Again, could you rewrite the createOdemeProfie() method code using TLV ??

I guess you are referring to<tt> odemeCreateProfile </tt>in the original applet.

I could* rewrite it in a cleaner way. But
- Why should I* do that?
- You did not give the spec of the applet and its APDU, and I'd hate to write code without specs, instead having to rely on the assumption that the original code is valid, which is dubious. For a tiny example, how could one guess if<tt> short lc = (short) buffer[ISO7816.OFFSET_LC]; </tt>is correct, or if rather the canonical<tt> short lc = (short)(buffer[ISO7816.OFFSET_LC]&0xFF); </tt>is required (that is, if the incoming data can exceed 127 bytes)?
- the original sin lies in the design of new<tt> Odeme(_id, tarih, saat, firma, kategori, tutar, birim, ulke, sehir, ilce, aid, banka, taksit, _puan) </tt>needing so many explicit parameters.

Without fixing the very definition of<tt> Odeme </tt>, the code will remain ugly. One possible design would be to have a method to set a field designated by its tag, and another to get the value of a field designated by its tag. Another design would be a method to set any number of fields passed as an array of bytes containing a concatenation of TLVs, and another to get any number of fields designated by an array of tag bytes, as an array of bytes containing a concatenation of the TLVs.

Again, you* want to generalize what the code does until the nature of the data items manipulated never appear in a method or variable name, except as the name of a finalstatic variable (that is, as a constant), at least in utility methods like<tt> odemeCreateProfile </tt>, and in the constructor and accessors of <tt> Odeme </tt>. Think of it a building a tiny database engine, then using it. Of course when performing actual computation as opposed to mere data storage, it helps to name the variables, e.g. when adding a traveled distance to an odometer, or computing a cost from this or that per some formula (but beware that in Java Card, especially on platforms without<tt> int </tt>, straight formulas are seldom the right way to perform any but the simplest computations required in a real application).