Generated Keys.java static class too large.

[john landers]

When running the generated on a large schema the
Keys.java files is too large to compile

The code for the static initializer is exceeding the 65535 bytes limit

Keys.java
UniqueKeys count 919
ForeignKeys count 1953

I solved the problem by manually copying all the ForeignKeys
to a new Class ForeignKeys.java and fixing up all the references in
all the table classes.

[Lukas Eder]

Hi John,

> When running the generated on a large schema the
> Keys.java files is too large to compile
>
> The code for the static initializer is exceeding the 65535 bytes limit

I see, I hadn't thought of the method bytecode size limitation in Java.

> Keys.java
> UniqueKeys count 919
> ForeignKeys count 1953
>
> I solved the problem by manually copying all the ForeignKeys
> to a new Class ForeignKeys.java and fixing up all the references in
> all the table classes.

2000 foreign keys is not an exceptionally big number, so one can
assume that separating the key types into various files will only
postpone the problem until the database schema sufficiently
increases...

The best way to thoroughly solve this is probably to put foreign key
declarations in table classes, directly. I'll fix this as issue #1459:
https://sourceforge.net/apps/trac/jooq/ticket/1459

Did you run into similar issues with the generated Tables.java class,
which references all tables in a schema?

Cheers
Lukas

[Lukas Eder]

> The best way to thoroughly solve this is probably to put foreign key
> declarations in table classes, directly. I'll fix this as issue #1459:
> https://sourceforge.net/apps/trac/jooq/ticket/1459

Unfortunately, this is not going to work easily. The Keys.java class
simplifies static initialisation of jOOQ-generated artefacts. It is
always the last artefact to be loaded by the ClassLoader (when all
tables / records, etc. have already been loaded). Also, unique keys
are loaded before foreign keys (which reference them). Changing that
will open pandora's box on static initialisation.

I'll have to think about some other solution...

Cheers
Lukas

[john landers]

The Tables.java was ok. Not problems with it.
Just the Keys.java.
Splitting worked for now for me but if things grow
I am sure we will run into the issue again.

[Lukas Eder]

> The Tables.java was ok. Not problems with it.
> Just the Keys.java.
> Splitting worked for now for me but if things grow
> I am sure we will run into the issue again.

I guess, with a certain amount of keys, the generated code should look
like this:

-----------------------------------------------------------------
public static XXX KEY1;
public static XXX KEY2;
public static XXX KEY3;
...
public static XXX KEY2000;

static {
initialise1To1000();
initialise1001To2000();
}

private static void initialise1To1000() {
KEY1 = ...
KEY2 = ...
KEY3 = ...
...
}

private static void initialise1001To2000() {
...
KEY2000 = ...
}
-----------------------------------------------------------------

This kind of solution wouldn't allow for static final variables,
though. Let's consider Stack Overflow for other ideas:
http://stackoverflow.com/questions/10841732/how-to-circumvent-the-size-limit-of-a-static-initialiser-in-java-when-initialisi

Cheers
Lukas

[Lukas Eder]

The definitive solution will involve a relatively large static
initialiser in Keys.java with static final members being initialised
to values of members of nested classes. Each nested class is limited
to a maximum of 500 members, staying on the safe side of static
initialisation block sizes. An example can be seen attached to this
e-mail (with blocks of a max of 10 members).

This is committed on GitHub and will be included in the next
2.4.0-SNAPSHOT. Early testing is very welcome

Cheers
Lukas

2012/5/31 Lukas Eder <lukas...@gmail.com>:

[Lukas Eder]

Hi,

>> Did you run into similar issues with the generated Tables.java class,
>> which references all tables in a schema?
>

> I'm getting the "code size too large" error on the generated SchemaImpl
> class using JOOQ 2.6.2. My schema has more than 15,000 tables.

Hmm, it had to happen at some point. Thanks for reporting this. I have
registered #2212 for this issue:
https://github.com/jOOQ/jOOQ/issues/2212

I guess, similar measurements have to be taken to solve this problem,
as was done before for the Keys class