Hi -

We are trying to persist about 450 classes with the new 2.1rc1 hibernate and are running into the following error when trying to start up a new SessionFactory:

-------------------------

net.sf.hibernate.HibernateException: CGLIB Enhancement failed

at net.sf.hibernate.proxy.CGLIBLazyInitializer.getProxyFactory(CGLIBLazyInitializer.java:60)

at net.sf.hibernate.persister.AbstractEntityPersister.<init>(AbstractEntityPersister.java:793)

at net.sf.hibernate.persister.EntityPersister.<init>(EntityPersister.java:741)

at net.sf.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:41)

at net.sf.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:136)

at net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:720)

.
.
.

Caused by: java.lang.ClassFormatError: Code of a method longer than 65535 bytes

at java.lang.ClassLoader.defineClass0(Native Method)

at java.lang.ClassLoader.defineClass(ClassLoader.java:537)

at java.lang.ClassLoader.defineClass(ClassLoader.java:382)

---------------------------

Our classes share a common base class and are thus in one pretty large mapping file (auto-generated), which may be part of the problem.

If we reduce our number of classes to about 100 we no longer see this error.

Previous versions don't have this issue, with the old cglib, but we are running into problems with the old version that seem to be fixed in rc1.

It looks like the new cglib assembles one big method somewhere that is over the jvm maximum allowed method size.

This is both to let you know about the problem and ask for advice on getting around this... Thanks!

Dan

The code in the generated proxies should not grow with the number of classes. For the most part they are proportional to the number of methods in the class. I am guessing that there are one or two classes that have more methods than the others, or perhaps methods with longer signatures, and when you reduce the number of classes you are removing the problematic ones.


It would be helpful to know exactly which class it is failing for. If you could determine that somehow and get me the .class file I'm sure we can find a workaround. I'd post a bug to JIRA and attach the class file. If it is easy for you to rebuild Hibernate then you could just modify the log message in CGLIBLazyInitializer to include the name of the class it is attempting to proxy. Otherwise you may have to be creative, e.g. add classes one by one until it fails or something. In the worst case I can probably build you a special hibernate.jar to test with.

Thanks,
Chris

It can be caused by "switch" generated in FastClass/MethodProxy, but It handles class file format limitations, doe's not it ?

No it doesn't. Some way to split up the code is needed. It may also be the static initializers in the enhanced class, or something else. Need to see the actual class to know for sure...

Thanks for the responses. I will look into it more this weekend, determine which class(es) are causing the problem and send them in, hopefully also with a little more info attached after getting more familiar with cglib.

Dan

Try to set system property:
System.setProperty (DebuggingClassWriter.DEBUG_LOCATION_PROPERTY,"/tmp/cglib-debug");

It will dump generated code to class format files and to ASM style text files.

BTW It is possible to split code, but class size is limited any way, there is
limit for code size, method and number of subclases limit. Most of JVM implementations code dump or throw "StackOverflowError" with "large" classes before limits.
I have the same problem with some generated code, it works on SUNs 1.3.1 JVM only. It must be better to use Maps for this kind of data structures than to generate hundrends of classes.