Static blocks are executed by the classloader when it loads the class. It's how JVM behaves. So if the code in this block relies on some other code to be executed 1st, it needs to be moved to a separate method.
Persistence providers usually (and Toplink is doing it that way) delay actual processing of the classes in a persistence unit until the 1st call to createEntityManager() to avoid loading data that is not needed. There should be no user-visible difference whether it's loaded earlier ot at this point - before the 1st EM is created, nothing can be done anyway.
When you deleted all the tables in the database, the persistence provider didn't know about it, and tried to access them when you ran the query. There is no requirement for a JPA provider to verify table existance. That said, integration between GlassFish and a JPA provider is different in term of auto-creation of the tables in the database. TopLink integration is done in such a way that the tables are created on deployment of application, so that the data does not disappear on the server restart. All other providers do not have this kind of integration, so they might be creating new tables for you on every server restart. Whether it's good or bad depends on your point of view - unfortunately there is no generic (i.e. spec defined) way to do it.
So I'd say, yes, this is how JPA works.
Regards,
-marina
[Message sent by forum member 'mvatkina' (mvatkina)]
http://forums.java.net/jive/thread.jspa?messageID=253887