Enum-generation: differences between Windows and Linux

[TheTrueDentist]

In our team, we have some members working with Windows, other with Linux and have realized differences in the output of the plugins for maven and gradle. We receive our schema files from external partners, who are working with enums. The enums are defined in separate schema files placed next to the main file. They follow different naming conventions:

• main-file is camelcase, like DomainSchema.v1.0.schema.json
• separated files are lower case, like company.v1.schema.json

From the main-file, we refer to the separate files like this:

"$ref": "company.v1.schema.json"

We then configure the plugins so that they get the directory with the schema files as source and provide a package as output. Both plugins find all the schema files and process them, yet the way the output is done, differs between Windows and Linux. On Windows, enums are generated as separated enum classes under the output package. You would then import them as:

import outputpackage.Company;

And then use them like Company.APPLE and so forth. However, under Linux, the enums are embedded within the pojos corresponding to the enclosing structure. So, you would need to import them as follows:

import outputpackage.Product;

And then work with them like Product.Company.APPLE. The reason seems to be that the schema files are sorted differently, when you rename the camelcase files to lower case, things work the same on both systems.

There shouldn't be a difference when handling enums between Windows and Linux, though we don't really mind which apporach is taken. However, there is this issue already proposed: #1002. It seems that the code to generate enums in separated classes is already there, therefor it shouldn't be dropped. Instead, there should be a switch for how enums should be handled.

[unkish]

Hi

There shouldn't be a difference when handling enums between Windows and Linux

I don't think that there is a difference when handling enums, however there's a difference between filesystems.

At present when input is given as a folder, files seem to get sorted using File::compareTo which states:

The ordering defined by this method depends upon the underlying system. On UNIX systems, alphabetic case is significant in comparing pathnames; on Microsoft Windows systems it is not.

Would be nice to have a SSCCE though to validate that

[winterkid]

I had the same issue. Especially when there are multiple references to the same enum definition in one JSON schema - e.g. enum 'unit' is used thrice in properties 'length', 'height', and 'width'. Then 'unit' gets generated as Length.Unit (inner enum of 'length' class) and classes Height and Width had to import Length.Unit instead of just Unit. Seems a bit odd.

[joelittlejohn]

I think probably the best way to influence this right now is using javaType in the enum.

[TheTrueDentist]

I wish I would have the time to provide an example...

However, I'd like to add two things: 1) The schema file in question is not in my hands and therefore it is not feasable to edit it manually each time my partners provide a new version. 2) In no way should there be a difference in the output of the plugin between two os. It is javas promise to be plattform Independent and a plugin should not break it. If the comparator is the problem, please swap it. A simple alphabetical comparator based on the filename should be easy to write.

Also, it is obvious that the code to generate enums in both ways is already there in the plugin. All we need is a switch and in my eyes it would blend nicely with the feature of providing a type explicitly to deal with special cases. The plugin would provide a full feature set.

[unkish]

In no way should there be a difference in the output of the plugin between two os

I would tend to agree that it'd be a rather undesired behavior.

It is javas promise to be plattform Independent and a plugin should not break it

It feels like substitution of concepts: java's platform independence is in terms of compiled bytecode.

Also, it is obvious that the code to generate enums in both ways is already there in the plugin

On the contrary - it's not obvious as #1002 states/implies that enums are generated as inner classes unless javaType is provided, which is not true. It looks like at present whether or not an enum defined in a standalone schema and referenced by other schema files will be generated as a nested "class" in one of the "referrals" or not depends on the order it's schema file is encountered when folder as an input is being processed (granted that javaType is not specified).

\ "Fixing" comparator might be considered a breaking change as for some of the users the output might not be the same anymore.

[unkish]

@joelittlejohn what do you think about following:

• leave SourceSortOrder.OS as is
• add another SourceSortOrder option eg. SourceSortOrder.PATH/SourceSortOrder.PATH_CASE_SENSITIVE/... and set it as default sourceSortOrder
• either fix SourceSortOrder.FILES_FIRST and SourceSortOrder.SUBDIRS_FIRST by:
  • removing/replacing "Case sensitive sort" from javadoc, as in the end both have "OS" dependent comparison: fileA.compareTo(fileB)
  • replacing "OS" dependent comparison part fileA.compareTo(fileB) with path comparison eg. return fileA.getPath().compareTo(fileB.getPath());

That would leave the "door open" for users that wish to have OS dependent sort order.

[TheTrueDentist]

Sounds fair to me.

[mrodal]

was this fixed? we are having the same issue

[unkish]

was this fixed? we are having the same issue

No. Issue status is Open