Java class size in PermGen space

Question

There are lots of Q&A's about the size of a Java object, which is quite straightforward to understand. But I'm wondering about the size of a Java class in the PermGen space.

The reason I wonder about this is because I'm writing a code generator, generating a lot of classes. Essentially, I'm generating two classes for every table/view in a database. Now I also want to model foreign key relationships. Instead of maintaining a complex, serialisable object-structure (think about a table having a unique key being referenced by several foreign keys belonging to other tables having other foreign keys, etc), I'd prefer to generate one class per UNIQUE KEY and one class per FOREIGN KEY.

Here are my questions:

How much overhead on the classloader and the PermGen space will I create with this?
Is there a difference between public classes, static classes and private member classes?
Do you see a better way to generate foreign key information in source code?

Sounds like a recipe for getting OutOfMemoryErrors when perm space fills up. — duffymo, May 02 '11 at 18:26
Thanks duffymo. That's why I ask. I'm curious about concrete figures, though — Lukas Eder, May 02 '11 at 18:27
Don't have any, since I don't know anything about what you're generating. I'm curious - why do you think this is necessary when there are so many persistence solutions already available to you (straight JDBC, Hibernate, iBatis, TopLink, JPA, etc.)? What's your solution buying you that these don't? — duffymo, May 02 '11 at 18:30
Re: 3. Do you see a better way to generate foreign key information in source code?, Hibernate does this via annotations or XML configuration data on the specific FK/PK columns. But I'm with duffymo, what you're doing sounds very similar to already established ORM solutions - unless you're trying to come up with domain objects automatically from a raw database schema. — BobG, May 02 '11 at 18:31
@duffymo: I'm developing http://www.jooq.org. I don't think there is a similar solution out there yet. All of the solutions you mentioned have something that the other ones don't. Check out the manual for the details. — Lukas Eder, May 02 '11 at 18:33
@BobG, good idea! I could actually use the JPA annotations for that. Why not putting that as an answer... — Lukas Eder, May 02 '11 at 18:34
@BobG, on second thought, the JPA annotations don't seem to model unique keys, and multi-field foreign key relationships very simply... — Lukas Eder, May 02 '11 at 18:45

score 2 · Accepted Answer · answered May 03 '11 at 06:05

I found a different solution, not wasting as much memory as generating one class per KEY. I generate a single class that roughly looks like this:

public class References {

    // First, initialise all unique keys
    public static final UniqueKey<TAuthorRecord> SysPk_14655 = 
        createUniqueKey(TAuthor.T_AUTHOR, TAuthor.ID);


    // Then initialise all foreign keys
    public static final Reference<TBookRecord, TAuthorRecord> SysFk_14666 = 
        createReference(SysPk_14655, TBook.T_BOOK, TBook.AUTHOR_ID);
    public static final Reference<TBookRecord, TAuthorRecord> SysFk_14667 = 
        createReference(SysPk_14655, TBook.T_BOOK, TBook.CO_AUTHOR_ID);


    // Factory method for unique keys
    protected static <R extends Record> UniqueKey<R> 
    createUniqueKey(Table<R> table, TableField<R, ?>... fields) {

    // Factory method for foreign keys referencing unique keys
    protected static <R extends Record, U extends Record> Reference<R, U> 
    createReference(UniqueKey<U> key, Table<R> table, TableField<R, ?>... fields) {

}

The actual tables from the generated table classes can then reference and use the above keys. I looked into JPA annotations as suggested by BobG in one of his comments. But I didn't find them very useful to describe:

Multi-field keys (@IdClass needs a type as parameter, and I want to avoid that type)
Multi-field references (how to do it?)
Multiple references from one table to another table using different keys
Unique keys, which share many properties with the primary key.

Some of the comments mentioned why I should create such a generator, because there are lots of established frameworks. I'm doing this for http://www.jooq.org. And I feel jOOQ is filling a gap in today's database abstraction possibilities.

I'll admit that at my day job (Spring/Hibernate project) I evaluate Hibernate weekly as to whether it is really saving me any time or not. (I'm certainly more comfortable with SQL than with Hibernate.) I usually end up concluding that Hibernate saves me about 20% of time time I would otherwise be spending on the DAO layer. However, for complex queries - things like reporting - I revert to straight SQL and bypass most of Hibernate. — BobG, May 03 '11 at 18:55
@BobG, then you should give jOOQ a shot. It will save you around the same amount of time on the DAO layer or even more, *and* you can use it for complex queries too... — Lukas Eder, May 03 '11 at 19:31

Java class size in PermGen space

1 Answers1