In this class diagram you can see the abstract base class doesn't have (nor requires) any of it's own attributes. The FieldManager class could have been an interface apart from the fact that:

• we wanted all classes in this hierarchy to be stored in a single database table
• we plan to add some stats attributes later and these would definitely go into this base class

In DN 5.1.6 we get the following exception:

I found the code that's adding the dnProvideFields methods during BCE:

org.datanucleus.enhancer.methods.ProvideFields.java

The execute method is doing the comparison with null here:

 

    public void execute()

    {

        visitor.visitCode();

 

        Label l0 = new Label();

        visitor.visitLabel(l0);

        visitor.visitVarInsn(Opcodes.ALOAD, 1);

        Label l1 = new Label();

        visitor.visitJumpInsn(Opcodes.IFNONNULL, l1);

        visitor.visitTypeInsn(Opcodes.NEW, "java/lang/IllegalArgumentException");

        visitor.visitInsn(Opcodes.DUP);

        visitor.visitLdcInsn("argment is null");

        visitor.visitMethodInsn(Opcodes.INVOKESPECIAL, "java/lang/IllegalArgumentException",

            "<init>", "(Ljava/lang/String;)V");

        visitor.visitInsn(Opcodes.ATHROW);

It's all in Java VM machine language (obviously much more efficient than performing a compile phase during enhancement) which makes for interesting reading ;)

I'm wondering if it's better to just change StateManagerImpl so that it passes an empty Array into dnProvideFields rather than changing the enhancer...

Passing an empty fieldNumbers native array does prevent the dnProvideFields method from throwing an IllegalArgumentException 

I can raise a pull request for a fix like this if you think it's reasonable:

StateManagementImpl.java lines 2507-2517 
            }

It is probably a simpler fix than changing the generated dnProvideFields method but making the change there might be more "correct" - and it might even reduce the size of the generated method, possibly speeding up enhancement of large persistent models (but maybe not significantly)

The StateManager and enhancement contract are not the place to change anything.
You need to prevent calling dnProvideFields with crap. i.e checkForSchemaUpdatesForFieldsOfObject (i.e where you have interfaces and some discovered implementations).
This is only of relevance there.

This issue is independent of previous interface issues that we recently discussed.

In this scenario the base class implements Serializable but I removed that "implements" relationship as a test and the problem remains - i.e. simple 3 class hierarchy with no references to other classes or interfaces.

I'll look up checkForSchemaUpdatesForFieldsOfObject and see if I can attack the issue from in there.

I have attached a very simple, two class, test case which reproduces the issue of having no attributes in the base class.

A simple one class scenario with no attributes in the base class also reproduces the problem but that's a bit of a pointless model.