I find this error a little funny but java gurus might have a good explanation.
I have a 2-dimensional table consisting of a total of 9900 entries of the "short"
data type. I declare this table within an interface.
Therefore the number of total bytes this table takes up should be 19800. Correct?
I'm getting an error that says "The code for the static initializer is exceeding the 65535 bytes limit"
What am I not understanding here?
I'm using IBM Websphere Studio Site Developer for Java 5.1
Thanks.
cjard
August 7th, 2004, 07:45 AM
post the erroneous interface, please
engineer2004
August 9th, 2004, 11:12 AM
Here is the interface.
dlorde
August 9th, 2004, 11:52 AM
It may the actual method code size that's causing the problem. Have you tried reading it from a file instead of hard-coding it?
Incidentally, this is the relevant JVM restriction specification: JVM Limitations (http://java.sun.com/docs/books/vmspec/html/ClassFile.doc.html#6253)
640K [of main memory] ought to be enough for anybody...
W. Gates
engineer2004
August 9th, 2004, 12:36 PM
Dlorde, I'm not quite sure I understand, "method code size", could you explain?
The reason why I don't want to read it from a file is because this matrix is going to be used very frequently. I'd like the program to perform as optimally as possible.
My other solution would be to split the table into two smaller tables. However, doing so is going to be a complete pain.
Thanks!
cjard
August 9th, 2004, 02:14 PM
In java, you may not have a method that is more than a certain size when compiled. Your interface exceeds this size. I dont think youre making correct use of an interface here anyway.. Interfaces are typically used to prove to the java compiler that a class you have written, meets a certain set of criteria.. you appear to be using it to share a bit of code to avoid repeating it; this is not correct. Instead, if you wish to make one matrix for use in your program, you should isntead write a matrix factory class, that generates a array of short from a given input.
As dlorde has already noted, you cannot hardcode it in, because it would result in a class that is too large for the JVM to handle.. it hence achieves the opposite of what youre trying to achieve; it's inefficient to have to upsize buffers, just to force some badly written code in. when dlorde said write the data into file, and read it into the array, he probably meant this:
//all lines into the arraylist now
br.close();
br = null;
//make the first dimension of the table equal to the lenght of the arraylist
table = new short[ al.size() ][];
//now assign each of the contents of the arraylist into the second dimension
for(i = 0; i<table.length; i++){
//get element from AL at position i, convert to short array, assign to table
table[i] = (short[])(al.get(i));
}
I can confirm that my code correctly reads the given values into the byte array, but you will see this for yourself if you run it
then, if you do not wish this code to be instantiated, you merely make the class abstract, or better.. give it a private constructor.
Remember that interfaces allow an object to pretend it is something else..
class BookToken implements PaymentMethod
class Vegetable implements Stewable, Steamable
hence when you make something implement an interface, it becomes that interface. For you to write a class, then say "MySomeClass implements MyTable" jsut as a dirty way of copying that short[][] into the MySomeClass isnt right..
MySomeClass IS NOT A MyTable.. it might HAVE A table of shorts, but it IS NOT A table of shorts..
can you see the logic of this?
Now suppose your class wants to make use of a table of shorts.. you can add to my code i made here, so that the code becomes a repository of the table[][], and serves it up on request.
Another of your classes can say:
short[][] thisTable = MyTable.giveMeTheTable();
(you need to write a method called giveMeTheTable() that returns a short[][])
and it has access to the matrix.
this is far more efficient than your supposed method of shoving it into an interface.. remember that interfaces are for proving what a class IS, not what a class HAS
dlorde
August 9th, 2004, 02:27 PM
Thanks cjard, for filling all the finer details that I so cavalierly left out!
The weather here in south UK is currently 'Tropical Rainforest' flavour...
engineer2004
August 9th, 2004, 04:11 PM
CJard,
Mucho Thanks!!!!! Very clear and good answer. I understand now.
Appreciate the help.
Alright I do have another question.
How do we handle global constants in a java program?
Instead of putting these constants in an interface should they be put in a class instead?
Thanks.
cjard
August 9th, 2004, 08:26 PM
i'd be tempted to put them in a class like this:
class Preferences{
public static final int NUMBER_OF_PEOPLE = 10;
public static final int USER_CHOSE_COLOR = Color.BLUE;
}
in practice, there will be very few "global" variables, because this couples your classes up to there being one main class in existence. if possible, classes should independently read information from somewhere on disk, or be told at startup time, all that they need to know
imagine you have a program with 35 classes, and they all use the Preferences above..
now imagine having 34 brothers/sisters, and they all rely on your mum as a source of information.. all you siblings will never be able to exist anywhere other than your house.. as soon as youre out of touch with your mum, youre useless (and your mum cant follow you everywhere)
instead, what reallu happens in this life, is that we are told everything we need to know, then we go and do a job.. in java, an objects birth arrives with the use of "new", its teaching arrives in the form of the constructor, and at the end of the constructor, the object is ready for independent work.. just like you, at 16, educated etc, are ready to earn some money.. :)
dlorde
August 10th, 2004, 08:47 AM
Instead of putting these constants in an interface should they be put in a class instead?
For truly global constants, I prefer using abstract classes, although this is more a stylistic preference than a requirement. In practice, you can use either a class or an interface.
Interfaces allow constants to be declared primarily so that subclasses that implement the interface can use them without using a name prefix. The implication is that the constants declared in an interface are directly related to the purpose of the interface rather than being global. If a variety of global constants were declared in an interface and the interface was implemented by classes requiring one or more of the constants, you could easily end up with classes having unnecessary access to constants unrelated to their needs (with the possibility of name clashes with class-local variables).
Using abstract classes for constants, it is easy to partition them appropriately by domain (e.g. IOConstants, TypeConstants, NumericConstants, etc) and when they are used, the class name prefix provides an explicit indication of their domain and prevents name clashes with local variables.
It's a matter of personal preference, YMMV.
Whichever idiom you decide on, be consistent...
engineer2004
August 10th, 2004, 10:37 AM
Excellent, Thanks everyone for your help.
codeguru.com
Copyright WebMediaBrands Inc., All Rights Reserved.