Oliver Kamps

Hi Raga,

code is much easier to read if you put it into code tags (see the buttons below the edit box).

You could have saved some time by providing the error message in your question. My compiler says:

"search cannot be resolved"

You have not declared the variable "search" anywhere in your code.

Hope this helps,
Oliver

Hi,

it would be interesting to know why the output is wrong, i.e. what causes these errors. It seems to difficult to provide a meaningful answer to your question in the abstract.

Cheers,
Oliver

I agree with Mark that there are no right or wrong answers. Nonetheless, I'd like to offer some additional thoughts:

I tend to work with reasonably large domain object models (dozens of persistent classes; and I tend to work with JDO, but that's a different story...) When initially writing the code I'm often happy to use the default mapping provided by the persistence provider. As I progress, I start to influence the mapping manually, e.g. deciding on an inheritance mapping strategy, table and column names, details on column types and sizes.

On many projects a database specialist will have a say in the design of the database schema. If you have the luxury of working with an open-minded database specialist, this specialist may be willing to make required changes to the mapping information directly--this is feasible when you define these in XML, but less so if you define these in annotations.

(I understand that I can use XML to override the annotation settings, but I would advise against mixing XML and annotations for a specific piece of metadata.)

Also, my mileage with respect to the coupling of Java code to database mapping varies from Mark's; I find I can change my database schema quite a bit without having to change code.

Cheers,
Oliver

Hi,

you can certainly access variable "out" outside the loop--and the compiler is not complaining about that.

"out" is a local variable and therefore not initialized when you define it. You only assign a value to "out" inside the loop. If the code inside the loop is not executed, the variable remains uninitialized. The compiler does not evaluate the loop-condition, so for all it knows, variable "out" may be uninitialized. And that is exactly what this error is about.

Cheers,
Oliver

Hi,

if you have control over your files you might want to look at Java ResourceBundle and the corresponding properties files--resource bundles are intended to handle internationalization issues similar to what you describe.

JAXB is pretty convenient for parsing XML; it allows you to access your XML data through generated Java classes--constructing the HashMap from these classes is pretty straightforward.

Cheers,
Oliver

Hi,

much of the annotation discussion boils down to personal preferences. Annotations can certainly help you to get up an running quickly but you might find XML less cumbersome when getting closer to production/operations.

Personally, I use annotations only for things that are really close to the code, e.g. marking an annotation as one-to-many. I prefer to use XML to define the mapping itself, e.g. specifying table or column names etc.

The reason for that is that these mapping decisions are somewhat independent of the code and should be able to change (within reason) without having to change the code.

Much of this reasoning holds for annotations related to other technologies, too.

Cheers,
Oliver

Hi,

I haven't used glassfish, so the following might be off the mark.

I assume that you are running to run your code as stand-alone clients of that EJB.

Looking at the exceptions, I'm not convinced that the JNDI name is the problem: it seems to me that JNDI doesn't know what initial context factory to use. Check out this GlassFish FAQ for more details.

Cheers,
Oliver

Hi,

since you have to handle 168 bits try java.math.BigInteger.BigInteger(String, int).

Cheers,
Oliver

Nicholas, what does heap have to do with it? A static method is one that is not invoked with respect to a specific object. So Joseph was right, Thread.sleep(3000); would have done the trick.

Cheers,
Oliver

Hi,

the JPA specification itself does not specify how a boolean field is mapped to / represented in the database. You will have to look at your JPA implementation's documentation for vendor-specific extensions.

Having had the, err, opportunity to use TopLink (pre-JPA) in a previous life, I'd be surprised if TopLink didn't allow you to customize the mapping.

Cheers,
Oliver

Hi,

static members relate to the class, non-static members relate to the instance.

For fields, this means that a static field is shared by all instances of the class while a non-static field is specific to an instance.

Non-static methods are called on an instance and have access to non-static fields of that instance (and, of course, static fields of the class). Static methods can be called without having an instance; static methods only have access to static fields.

Forget about the heap in this discussion ;-)

Check the Java Tutorial for details.

Cheers,
Oliver

Hi,

you already show the date and time of the last post on the forum overview pages. It would be nice to also include the name of the laster poster here. You already do this in the saloon itself.

Cheers,
Oliver

Hi,

this mapping can be very useful when you have to work with an existing database schema.

Whether or not this mapping is poor design depends on the situation at hand and is generally in the eye of the beholder. If you have a number of concrete classes in a hierarchy with a large number of objects per class (read: a large number of rows in each table) *and* you only rarely need polymorphic access in your queries, then this mapping might actually be pretty good design.

Cheers,
Oliver

Hi,

it depends, mostly on what your tables actually look like.

Assuming you have a column on t2 linking the row to the 'parent' row in t1, you should be able to delete the t2 row. You'll want to consider any other ongoing activities / transactions on the database, of course.

When working with object persistence technologies, you'll typically want to modify your persistent objects through the application (and, therefore, your persistence technology) rather than directly through the database. In this case, you'd probably want to talk about deleting or removing an object rather than deleting a row in the database.

Cheers,
Oliver

Hi,

in short: no, it doesn't mean that.

A little longer: First, polymorphic behavior does not depend on a class having an interface; a class hierarchy without any interface can exhibit polymorphic behavior.

Providing an interface allows you to separate the implementation of an abstraction (i.e. the class) from its interface (i.e. the interface itself). You can exchange or modify the implementation without affecting code programmed against your interface.

You would typically only provide an interface for a class when the benefits outweigh the cost. It is good practice to provide (Java) interfaces for the public/published interfaces of components or subsystems.

Cheers,
Oliver