I have a basic question regarding portability of Hibernate and how to get it to run correctly on a PDA client system.

I have a fully functional system utilizing Hibernate on the server side with tomcat5.5 and a java client. I can get all the queries back no problem with one slight hang up...without the hibernate3.jar in the classpath of the client I cannot open the resulting Hibernate query objects that are returned in the list. This handicaps my client that is designed to run on a PDA as it can only support java 1.1 libraries and the current hibernate3.jar is (I assume) compiled to 1.4-1.5. So how do I get a hibernate3.jar file that is compiled to 1.1 or if it is not available is it possible to compile the source files myself to 1.1?

Another question which is really the heart of my problem: is it possible to seperate hibernate from my java client/server relationship? It doesn't make much sense that the client should need any visibility into hibernate at all. That complexity should be handled only by the server. The problem is that the list that is returned is populated by hibernate generated objects and without the correct libraries it cannot be openned. There is obviously the work around of copying data from the objects into new objects and sending that list but that is EXTREMELY time consuming and is clearly the wrong way to go.

Any help here would be great.

You may want to provide more information about what the specific problem is and how you're passing the objects, but it sounds like you may need to initialize your objects on the server side. If that's the problem, you should read the documentation on lazy initialization, fetching strategies, and Hibernate.initialize().

I am getting the following error:

org.hibernate.collection.PersistentSet class java.lang.ClassNotFound.Exception

Again, this is remedied by placing hibernate3.jar in the class path on the client side. To be more specific as u suggest, i use the Query.list() method to get the results on the server side of my application. The server then passes the list to a servlet that passes it to a java PDA client where the error is generated unless the classpath is updated as already stated. I know that this is the problem because I can run the PDA code on a desktop and it runs fine after I fix the classpath. So, any suggestions on either how to get a hibernate3.jar file that works with the PDA client or how to seperate hibernate completeley from everything other than the server side program? I really would like to lean towards the latter if possible becuase it makes a lot more sense.

I understand your problem now. We had a very similar problem using Java's XMLEncoder - since Hibernate was extending collections classes with PersistentSet etc and entity classes with CGLib, the output of writing an object tree to XML was unusable - it contained references to Hibernate classes that the consumer of the XML wouldn't know about. We did not find a solution better than manually mapping the objects retrieved from Hibernate to new transient objects, which is less than ideal. You may have to do the same since you obviously can't use the Hibernate jar in Java 1.1.

Yes, this was one of my work arounds that I tested and confirmed that it worked however, as you state it is far from Ideal due to time and efficiency concerns in queries with results consisting of several large objects.

I am doing this as a portion of my M.S. thesis and will simply have to conclude that Hibernate fails to meet the bill in this instance. I have used the build file to attempt to recompile to the correct JDK version but still was unable to get a working setup though the build file will generate a .jar file. So, if no one corrects me here I will have to assume that Hibernate will not work for my case. Thank you for your assistance.

I think the problem is with your architecture. You have the client interacting directly with the specific persistence implementation, so you introduce dependencies on the persistence layer in the client. If you examine some of the standard design patterns, such as Data Transfer Object (DTO), Data Access Object (DAO), Adapter, etc., you will see that decoupling the two is considered a "best practice". In a J2EE architecture, a client may interact with a Stateless SessionBean, which then delegates to another layer that handles the specifics of the persistence layer. The interface of the SessionBean would be defined in a way that was convenient for the client to use, including returning query results using standard java classes. There would be a translation from the result set returned by the persistence layer, regardless of whether it was a Hibernate result set, or a JDBC results set, an EntityBean, or JDO classes.

Your statement "copying data from the objects into new objects and sending that list but that is EXTREMELY time consuming and is clearly the wrong way to go." is at odds with recommended architectural guideliness for sophisticated J2EE applications. I can't comment on how appropriate it is for your specific application.

When you say "I will have to assume that Hibernate will not work for my case", you should also consider that if the client is tied to JDK 1.1, there are actually very few choices that you will have for your persistence layer if you are making the client directly dependent upon it.

I don't think my architecture is flawed. Here is what I have:

postgreSQL DB <->Hibernate <-> DBManager<->Servlet<->Java Client

the DBManager is the only class that should have to have any insight into Hibernate at all as all it does is pass the HQL query to Hibernate via the Query.list() class/method inherent in Hibernate and recieve a List according to the Hibernate API of objects (that I defined in my architecture) that match the query. I can verify all this by simple System.out statements and look in my Tomcat logs that it is working and that the list does indeed make it all the way to the client and then the client cannot open those objects because it is missing the Hibernate3.jar file. This is all well and good as long as it is a Desktop application or one that is capable of running JDK 1.4 however as I stated in a previous post this was initially designed to run on a PDA as a Java application and it will not support 1.4. So, I am still without a solution and as you suggest I dont think that my application is dealing directly with my persistence layer.

lslawren, that's right - even if you have an architecture which decouples the client from the persistence implementation (which it sounds like you do), the modification by Hibernate (using CGLib and extensions of the Collections classes) of your objects prevents you from serializing them for use by a client that knows nothing about Hibernate.

Thanks Kluethold,

I think I am effectively concluding that it is not possible to truely decouple the persistence layer from the application unless I create transient objects (effectively deep copying all the resulting objects into newly created ones via the java reflexive API). Thanks again for your reply.