Feature: Generated POJOs with setAdditionalProperty should implement a common HasAdditionalProperties interface, and the interface should be generated/copied to output directory

[tobiaswx]

Feature Request: Common Interface for Additional Properties Setter

Summary

When jsonschema2pojo generates a class that includes a setAdditionalProperty method (for handling additionalProperties in JSON Schema), it should also implement a common interface (e.g., HasAdditionalProperties). This interface should define the setAdditionalProperty(String name, Object value) method, making it easier for downstream code to work generically with all such POJOs.

Motivation

Currently, each generated class with additionalProperties defines its own setAdditionalProperty method, but there is no common contract/interface unifying these. This makes it more difficult for library users to write utilities or frameworks that operate generically on all such POJOs.

Proposed Solution

• Add a new interface, HasAdditionalProperties, with the following signature:

  public interface HasAdditionalProperties {
      void setAdditionalProperty(String name, Object value);
  }

• Update the code generation logic (in AdditionalPropertiesRule) so that any generated class containing setAdditionalProperty also implements HasAdditionalProperties.

• Ensure that the generated setAdditionalProperty method matches the interface signature.

• Update or add integration tests to verify the interface is implemented where expected.

• The interface HasAdditionalProperties should also be generated or copied into the same output directory as the generated POJOs. This ensures that user projects do not need to depend on jsonschema2pojo-core at runtime or compile time. The generator should ensure that the interface is only generated/copied once per output directory, to avoid duplicate class errors.

Benefits

• Enables easier generic programming and utility code for jsonschema2pojo users.
• Encourages consistent method signatures for additional properties handling.
• Reduces custom boilerplate for consumers who want to interact with additional properties.
• Eliminates the need for user projects to add jsonschema2pojo-core as a dependency just for this interface.

Notes

• The interface should NOT be generic; the value parameter should be Object, just like the current behavior for additionalProperties by default.
• If a generated POJO narrows the property type (e.g., via a schema), the interface signature should still use Object for compatibility.
• If none of the generated classes implement the method or the feature is deactivated, the interface itself should not be added to the generated code.

Related files

• jsonschema2pojo-core/src/main/java/org/jsonschema2pojo/rules/AdditionalPropertiesRule.java
• jsonschema2pojo-core/src/main/java/org/jsonschema2pojo/HasAdditionalProperties.java (template location for copy)

---

Thank you for considering this feature!

---

This issue was drafted with GitHub Copilot.

[tobiaswx]

Alternative Solution: a property i can set like "parentType" or "parentInterface"

<parentType>my.package.HasAdditionalProperties</parentType>

[unkish]

Hi

Alternative Solution: a property i can set like "parentType" or "parentInterface"

There's already javaInterfaces property to define which interfaces will be implemented by generated type

[tobiaswx]

Hi

There's already javaInterfaces property to define which interfaces will be implemented by generated type

Thanks, I have tried it. It works if we were managing the schema and if it was fairly stable, but the schemas we work with are constantly evolving and being integrated into our project as a git submodule. So yes, we could always edit the schemas and add that property to each object, but that's a lot of work to do over and over again.

I thought it would be easier to introduce a global variable in addition.

Is it possible to estimate how much additional work would be required to introduce this? I think many others would also benefit from this and it would make the reusability of code much easier.

Edit: In addition, I would clarify that I mean that a global option to implement interfaces (as an alternative to the json property) would be beneficial for everyone. Regardless of the above requirement regarding the additional properties (which would be inherently fulfilled, since we could simply configure the above-mentioned interface in our project).

[unkish]

Safety harbor: expressing personal opinion

It works if we were managing the schema and if it was fairly stable, but the schemas we work with are constantly evolving and being integrated into our project as a git submodule. So yes, we could always edit the schemas and add that property to each object, but that's a lot of work to do over and over again.

You're free to create custom rulefactory and extend rules as is desired.
It should even be possible to piggy-back on AbstractAnnotator, a build.gradle example:

import org.jsonschema2pojo.AbstractAnnotator
import org.jsonschema2pojo.GenerationConfig

import com.sun.codemodel.JDefinedClass
import com.sun.codemodel.JFieldVar

class CustomAnnotator extends AbstractAnnotator {

    CustomAnnotator(GenerationConfig generationConfig) {
        super(generationConfig)
    }

    @Override
    void additionalPropertiesField(JFieldVar field, JDefinedClass clazz, String propertyName) {
        clazz._implements(clazz.owner().directClass("fully.qualified.name.of.existing.AdditionalPropertiesMarkerInterface"))
    }
}

plugins {
    id 'java'
    id 'org.jsonschema2pojo' version('1.2.2')
}

group 'org.example'
version '1.0-SNAPSHOT'

repositories {
    mavenCentral()
}

jsonSchema2Pojo {
    setSource(files("$projectDir/src/main/resources/json"))
    formatDateTimes = false
    customAnnotator = CustomAnnotator
}

dependencies {
    implementation 'com.fasterxml.jackson.core:jackson-databind:2.14.2'
    implementation 'org.jsonschema2pojo:jsonschema2pojo-core:1.2.2'
}

I thought it would be easier to introduce a global variable in addition.

Is it possible to estimate how much additional work would be required to introduce this?

Whilst adding a configuration property doesn't take much time IMHO it's the maintenance burden / keeping in mind how do all configuration properties play together / keeping core logic simple to allow future changes/developments what matters more.

I think many others would also benefit from this and it would make the reusability of code much easier.

It's really hard to say if that is true as there is no evidence/facts.