That’s absolutely solid feedback and if you’re doing only a handful of field mappings, I’d agree that this pattern could be used. However, as mappings grow, you tent to end up with a whole bunch of constants, something that can be hard to maintain, or you simply have an overeager developer who thinks it’s a good idea to refactor the code into static final int TWO = 2, which of course leads you right back to the original problem.

When grouping the constants together, you make it more clear how these constants tie into your domain model and you make it easier for maintainers to read and extend the code.

Personally I wouldn’t call an enum boilerplate, since it is quite small and efficient, and I’d rather take that over Constants.java with a group of constants I cannot easily understand.

Yes, for mapping a fixed offset you would probably go with a parser or DTO with strong validation logic.

You can absolutely use ordinals, especially when mapping every field in the split, but my recommendation then would be to add a comment after each constant in the enum, to indicate the number of the ordinal. This will help when mapping the constants to numbers and vice versa, making it easier to follow code flows.

The explicit mapping is there to reduce the cognitive load and also because this mapping only deal with four of the fields.

Not written, but it has been used to edit the original article to reduce length and make it more concise.

This code would parse pipe-separated data such as:

"foo|bar|id2|foo|bar|foo|bar|2026-06-03|23:59:00|random reason"