Prevent using both, TargetType and FieldSetMapper, during compilation

[patbaumgartner]

Having a custom DSL (builder) for FlatFileItemReaderBuilder to prevent using targetType() and fieldSetMapper() at the same time. This should provide compile-time feedback for this breaking change.

To make things more consistent, one should also adjust the JdbcBatchItemWriterBuilder. This would affect collumnMapped() and beanMapped().

Expected Behavior

The following code snippet should not compile.

new FlatFileItemReaderBuilder<Foo>().name("fooReader")
			.resource(getResource("1;2;3"))
			.lineTokenizer(line -> new DefaultFieldSet(line.split(";")))
			.targetType(Foo.class)
			.fieldSetMapper(fieldSet -> new Foo());

Current Behavior

Currently, an IllegalStateException is thrown at runtime.

[HyunSangHan]

I believe it is a very good point.

Regarding the issue with FlatFileItemReaderBuilder, I’d like to ask for your thoughts on a possible direction.

Currently, targetType() and fieldSetMapper() can both be called on the same builder instance, which may lead to runtime errors. To prevent this, I’m considering using a step builder pattern where:

• After calling targetType(), fieldSetMapper() becomes inaccessible (and vice versa).
• This would be achieved by defining separate interfaces to represent different builder states.
• Deprecation period would be needed for targetType() and fieldSetMapper() of FlatFileItemReaderBuilder.

Would this direction make sense?

[snowykte0426]

Hi! I've created PR #4929 to address this issue using a stage-based DSL
pattern that prevents using targetType() and fieldSetMapper()
simultaneously.