Rick Taylor

Hello folks,

Yesterday I downloaded a UML modeling tool from sourceforge: Hids Case UD The default language is Spanish. There is an English option, but many of the labels have not been translated. Still, most of the meanings are pretty obvious, except for this one. What does "estereotipo" mean in a Java/OOP context?

Many thanks,

Rick

From K & B, p. 596 & 583:

You cannot use wildcard notation in the object creation ... the type of the variable declaration must match the type you pass to the actual object type.

From K & B, page 542 (Exam Watch):

When using HashSet or LinkedHashSet, the objects you add to them
must override hashCode(). If they don�t override hashCode(), the default Object.hashCode() method will allow multiple objects that you might consider "meaningfully equal" to be added to your "no duplicates allowed" set.

if (c == e) System.out.println("c == e"); // true (so 'e' being unboxed)

Boxing is a function of the wrapper classes, and Object is not a wrapper. I am guessing c == e because in both cases, the reference variable is pointing to an int literal that falls within the -128 to 127 range.

I would have said that the reason you got foo instead of bar is that you cast the reference variable to be of type (Base). It seems to me that the compiler determines which variable to use based on the reference type. Try changing the object instantiation in Marc's code to read:

Base s = new Sub();

Somebody please correct me if I'm wrong (especially the part about the compiler determining which variable to use).

I get the same result (that is, 19 followed by 11). What is the source of this question? Is it possible that it came from a Java 1.4 mock exam? In other words, was it written prior to the introduction of autoboxing?

Kishore,

You can see what's happening if you add a print statement to each of your addValue() method definitions. Try adding:

System.out.println("Derived addValue method");

to the addValue() method in class Derived, and a similar statement in class Base.

It sounds like the Formatter class is not covered on the exam - except indirectly, perhaps. Here is a quote from K&B, p. 489:

Behind the scenes, the format() method uses the java.util.Formatter class to do the heavy formatting work. You can use the Formatter class directly if you choose, but for the exam all you have to know is the basic syntax of the arguments you pass to the format() method. The documentation for these formatting arguments can be found in the Formatter API.

When i is incremented to 3, the switch statement invokes the default case, which is "assert false". At that point, the assertion test fails, and the program throws a runtime AssertionError.

For what it's worth ...

I have corrected the problem of my JTable cells containing the wrong data types by instantiating a DefaultTableCellRenderer for each of the columns that will contain numbers. But floats, doubles, and integers are still left-aligned after the data is entered into the cell (although the cursor appears on the right-hand side of the cell prior to editing), and any cell whose class is Number.class is still not editable.

As an experiment, I tried creating a JTable and populating it with initial values. Again, I overrode the getColumnClass method to return Number.class, Float.class, and Integer.class for certain columns. In each case, the values are right-aligned. Also, the float and integer values can be edited, but cells of class Number are still not editable.

Does anybody know why I can't edit Numbers? Is this normal for JTables, or could it be something in my code? Thanks for your help.

Thank you for the response. I tried overriding the isCellEditable method, but that had no effect. Then I tried revising the getColumnClass method to return Integer.class or Float.class instead of Number.class and got some unexpected results. Both classes make the column cells editable, but for each of the number columns, either the display alignment or data type is off. This is what happens when I enter the number 7 in each column (see comments):

public Class getColumnClass(int columnIndex) {
switch (columnIndex) {
case(0):
return Object.class; // left-aligned 7 in Column 0
case(1):
return Object.class; // left-aligned 7 in Column 1
case(2):
return Float.class; // left-aligned 7.0 in Column 2
case(3):
return Float.class; // right-aligned 7 in Column 3
case(4):
return Float.class; // right-aligned 7 in Column 4
case(5):
return Object.class; // left-aligned 7 in Column 5
case(6):
return Object.class; // left-aligned 7 in Column 5
case(7):
return Object.class; // left-aligned 7 in Column 5
case(8):
return Float.class; // right-aligned 7 in Column 8
default:
return Object.class;
}
}

My questions are: why does the number 7 display as a float, but left-aligned, at columnIndex 2? And why do the floats at columnIndex 3, 4, and 8 display as integers? I have tried writing this method using an if/else statement and got the same results. Also, why does Number.class render the cells uneditable, but Integer.class and Float.class don't?

Thank you for your insights.
[ October 18, 2006: Message edited by: Rick Taylor ]

I am writing a cash register program that requires users to enter transaction data into a JTable. The DefaultTableModel seems to be the best option for displaying an empty table, except that I wanted to use a number renderer to render certain columns (quantity, price, etc). So I subclassed DefaultTableModel and added a getColumnClass method. The problem is, the columns that return Number.class are not editable. Am I missing something? I thought the JTable class included a default renderer for numbers ...

Thanks in advance. My code is below:

import javax.swing.table.*;

public class ItemsModel extends DefaultTableModel {

public ItemsModel() {
super();
}

public ItemsModel (Object[] columnNames, int rowCount) {
super(columnNames, rowCount);
}

public Class getColumnClass(int columnIndex) {
switch (columnIndex) {
case(2):
case(3):
case(4):
case(8):
return Number.class;
default:
return Object.class;
}
}

}