DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to. DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued
Issue Details (XML | Word | Printable)

Key: NUCCORE-632
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Unassigned
Reporter: Hylke van der Schaaf
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.
DataNucleus Core

RDBMS SchemaTool fails if any class implements a private inner interface

Created: 22/Jan/11 05:07 PM   Updated: 09/Dec/11 03:13 PM   Resolved: 11/Nov/11 04:32 PM
Component/s: None
Affects Version/s: 2.2.1
Fix Version/s: 3.0.4

File Attachments: 1. Zip Archive (4 kB)

Environment: Linux, maven

Forum Thread URL:,6405_offset,0#33650
Datastore: MySQL
Severity: Production

 Description  « Hide
If any class in the project defines and implements a private inner interface, mvn datanucleus:schema-create fails with an exception:

Exception in thread "main" java.lang.IllegalAccessError: class com.datanucleus.test.App$HelloSayer cannot access its superinterface com.datanucleus.test.App$innerInterface
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(
at java.lang.ClassLoader.defineClass(
at org.datanucleus.util.ClassUtils$1$1.findClass(
at java.lang.ClassLoader.loadClass(
at java.lang.ClassLoader.loadClass(
at org.datanucleus.util.ClassUtils.getClassNameForFileURL(

Sort Order: Ascending order - Click to sort in descending order
Hylke van der Schaaf added a comment - 22/Jan/11 05:09 PM
Testcase for schemaTool failure on a private inner interface in a class that does nothing jdo related.

Andy Jefferson added a comment - 22/Jan/11 06:44 PM
Why would you include a non-persistable class as input to SchemaTool ? (your "test" is simply this, hence not realistic).

If defining input to SchemaTool using file URLs then that can happen since it has to somehow work out what is the fully-qualified class name stored in the particular file, and there is no obvious Java mechanism to do such - the current one creates a class loader and tries to load it, but obviously if depending on other things then that method is not complete. If you think you can do that then look at ClassUtils.getClassNameForFileURL and provide a patch.

Simple workaround is just to use persistence.xml to define the classes to be processed, since there you define the class names directly, hence no need to frig about with class name determination for a file

Hylke van der Schaaf added a comment - 22/Jan/11 07:15 PM
The test case is the absolute minimum to show the problem. All persistence happens in other classes, but since those other classes are not needed to show the problem they are not in the test case.

That's the problem. SchemaTool fails on a class that has *absolutely nothing* to do with persistence. If it can't access that private interface of that class that's totally fine, because it doesn't need to access that private interface. It doesn't even need to access the class containing the private interface. It should just catch the exception and ignore it.

The enhancer has no issues with it, so why does SchemaTool fail?

I've only just started playing with DataNucleus and I just followed the tutorial. I have no idea how to tell DN to not look at all my classes.

Andy Jefferson added a comment - 18/Apr/11 05:34 PM
I already said why SchemaTool could have a problem with determining the packagename+classname from a filename. The enhancer has things like "ASM" available to it so has other mechanisms. As previously requested, that method needs to be able to determine the classname for a file, and needs patching with something that works reliably (without imposing any dependency).

Andy Jefferson added a comment - 11/Nov/11 04:32 PM
SVN trunk works for me.