Win a copy of Murach's MySQL this week in the JDBC and Relational Databases forum!

Edwin Dalorzo

Ranch Hand
+ Follow
since Dec 31, 2004
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Edwin Dalorzo

The Java Serialization Specification clearly describes the SUIDs and the reasons for their existence. The SUID is not related to RMI, but to serialization, and it is inherently related to the concept of type evolution.

Imagine that you have a database of serialized objects in version 1.0 of your application, already owned by a bunch of your clients. Now you are working on version 2.0 of the application. Whatever modifications that you make to the classes already serialized in the client's database may prove incompatible. What is a compatible change and what is not?

What if you add a new field to the class? What if you remove a field? What if you change a field data type? or move class to another package or simply rename it?

Whatever change you do to a class will most likely prove incompatible if you do not define an explicit serial version unique identifier. This SUID field is the only way you have to tell the Java Virtual Machine that the changes that you do are compatible with previous versions of a class. This does not mean that you code will prove to be compatible, this only means that you are telling the JVM that you have taken care of the code to ensure it is compatible.

For instance, add a field to class will make a previous version of class impossible to deserialize. If you defined the SUID, however, if you keep it as it was, the JVM will deserialize the class for you, regardless of change, but the new filed will be initialized to its default value (remember that deserialization does not invoke constructors or instance initializers). This means that if your new filed is an object and if you use this field without taking care that it could be null you could could fail by a NullPointerException.

In the distributed environment, since objects are serialized over the network, you also have to take into account the strategy for distributing the classes. If you change a serializable class on the server and you do not change the class for all the clients, the object being marshalled over the network may prove impossible to deserialize in the client.

Bottom line, you must be aware of type evolution and be prepare to deal with it every time you deal with serializable classes.

Regarding Swing components being serializable, I do not know the reasons, I guess you can consider among other things the possibility to serialize components to disk and get them back later with the properties as they were, and the possibilities of having distributed GUIs. But I am not Swing guy, so I cannot be certain of how this feature is being used in real world applications.

Well, if you need a list of all the schemas in the database, you can doing by means of obtaining the DatabaseMetadata.

This code will print all the schemas in the database:

However, I am not sure if there is a way to know what is the current schema. I guess it may depend on the database. For instance, in Derby, the current schema is named as the user currently signed in. So, you could obtain the current user name from the MetaData and know that is your current schema

However, not all databases are the same, I guess you will have to explore how your driver works.
Since you intend not to use the String class (not sure why), you could use to achieve the same result.

If you want to take encoding into account, then you just need to change the code a bit:

Assuming you want to use UTF-8.
13 years ago
Fist of all, we must set clear that two different objects may have the same hash code.

The definition of hashCode() method in Javadocs clearly states that "as much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects.".

Which basically means two different objects may have the same hashCode. However, the hashCode() and equals() definition in Javadocs guarantees that if equals() returns true, than the hashCode() of the two objects being compared should be the same.

That being said, we know that StringBuilder does not override neither equals() nor hashCode(), but String does. Therefore, we know that the hashCode() for two equal Strings must be the same. Therefore, the second hashCode comparison must always be true.

We cannot tell if the first hashCode comparison will produce true or false, since it is comparing two different objects. The classical implementation of hashCode in object is to return the objects memory address. If by chance this number corresponded with the hashCode generated by String based on its containing characters, then the comparison would yield true, otherwise false.

The JLS states in section 3.10.5 String Literals (page 28) that:

Each string literal is a reference to a an instance of class String. String objects have a constant value. String literals, or more generally, strings that are the values of constant expressions are "interned" so as to share unique instances, using the method String.intern.

Thus, I can conclude that the String pool may contain the string literal "whatever". Nonetheless, the instance of the string assigned to the variable its not that on the string pool, but another instance.
Your second question is a bit simpler. The class named A3 has access to the g field because it inherited it from its parent class (named Parent), whereas the classes A1 and A2 do not inherit from Parent and therefore do not have access to it.

You could also change your static inner classes to inner classes to have access to the variables declared in the outer class. Like this.

Regarding your third example I have not comments. I think it is fairly obvious what is the right syntax for this.

Regarding your final question about enums. The JLS 8.9 about Enums, page 249 states that the optional class body of a en enum constant implicitly defines an anonymous inner class declaration. If you compile this code and review the class files generated by the compiler you will validate that this is true.

What you are doing there is equivalent to this:

How do you invoke the "go" method in y? The answer is: it is not possible.

You can, however, do somewhat like this:

Now you can invoke the go method.
For your first question, what you need to understand is the difference between a type variable (JLS 4.4. p. 49) and a type argument (JLS 4.5.1. p.52).

If you read the JLS, you will notice that it says that type variables are used on generic class and interface declarations and in generic method declarations. And this type of declarations only accept "extends" clause, and not the "super". For instance, your method could be declare as follows:

Now, type argument is a different thing and they are allowed to use wildcards. Your confusion is based on the fact that one of the wildcards is named also "extends", a clear example of Java language polymorphism. In this case, the clause is used for two different things.

As its name suggest, you can use this to declare the expected type of arguments. For instance, you can say:

Or in a method declaration.

You can combine both, like this:

Later I will try to reply to your other questions, because this takes time.
This is rather awkward. I think I would like to see the whole code. You just wrote an excerpt from it. The problem could be in the code were are not seeing. Could you post an executable example of your code?
13 years ago
Well, Patricia, even when Campbell seemed to suggest that the location of an object in memory could change over time (for instance due to the generational garbage collection placing old objects in another memory space), even so the contract for hashCode in javadoc says:

Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer,
provided no information used in equals comparisons on the object is modified.

Therefore, regardless of the implementation of garbage collection or any other mechanisms that might place the object in another memory space, this method ought to return the same integer during the execution of the JVM.

Now, that being said, you must consider that this behavior of returning the memory space of an object as a hash code is not a required implementation of the method. Other JVM might implement it differently without violating the contract. Therefore, I would suggest that you should not take this implementation-dependent details into account while dealing with hashCode implementations.

You should only consider the contract stated in javadoc.
14 years ago
Actually, you should use the @EJB annotation on instance members not on static ones. If you think it over, this totally makes sense, because the EJB injected should not be shared by multiple threads, something you cannot guarantee if you inject it into a static variable.

On the other hand, the injection can only happen on container-managed classes, like a Servlet, another Enterprise Java Bean component, even JSP or JSF, but you cannot make the automatic injection happen in helper classes. For those cases, you will need to use JNDI as in the old days.

I hope this helps!
Not sure if with your questions you are referring the the implementation of the hashCode() method of java.lang.Object and which, by inheritance, is present in all Java objects.

If you do not override it, then the hashCode will return a value generated out of converting the internal address of the object into an integer. Therefore we could expect that all objects have a different hash code (Not sure what would happen, though, if the number of active Objects surpass Integer.MAX_VALUE).

Now, if you decide to override the method yourself, then you will need to make sure that for a given class, the hashCode you generate is as unique as possible. Typically you do this using an algorithm that has as fewer collisions as possible, if any. At any rate, the Java contract for hashCode() does not require that two give objects have different hashCodes all the time. It does require that if two objects are considered equal by the equals() method that they should have the same hash code value.
14 years ago
Well, if what you need to do is pad your results to be of a specific length, that is very easy to do. You know the required length, and you know the actual length of your String, why don't you simply add the missing characters as needed?

At any rate, there are several ways to do that, but the simplest of all is to use a formatted string, like this:

This would yield

You can read all about padding a String in the Javadoc documentation for java.util.Formatter class.

Hope that helps!
14 years ago
If you do this, what do you get?

This does not generate a compiler error, just a warning, though.

This is like this because Java did not have generics until JDK1.5, and they wanted that legacy code were compatible with new generics code. Therefore, if you had libraries returning raw types or receiving raw types as parameters, the Java Programming Language should still work.

This practice though is not recommended for new code written for JDK15 or superior. What you did should have been done like this

A list like this can accept any kind of list and since it uses an unbounded wildcard it will not generate a warning, as it does your legacy code.
Sorry pal, you will need to elaborate on your question. I continue without understanding what is exactly that you would like to do. Provide some information, post some code of what you are trying to accomplish and perhaps we can help you out.
14 years ago