JSR-352: improve deserialization of batch parameters/properties

Description

1st issue: We have no concept of error handling when deserializing:

  • if someone puts "t" or "1" in a boolean property, we'll interpret it as false (since we use Boolean.parseBoolean). We should probably rather throw an exception, but then it'd be a pain to have the error handling code replicated everywhere we use a boolean property in the codebase.

  • if someone puts "foo" in an integer property, we'll throw a NumberFormatException (I think), and this exception won't include detailed context (in particular, the name of the property will be missing).

2nd issue: We don't validate parameters when starting the job, but only when we use them. So worst case, we may have a job that starts perfectly well, but fails right after the purge due to a wrong parameter.

3rd issue: we end up parsing strings in the hot path of the mass indexing code, for instance org.hibernate.search.jsr352.massindexing.impl.steps.lucene.CheckpointAlgorithm.isReadyToCheckpoint() or org.hibernate.search.jsr352.massindexing.impl.steps.lucene.EntityReader.buildScrollUsingCriteria(StatelessSession, PartitionBound, Object, JobContextData). This may not impact performance a lot, but still, it's not nice.

Environment

None

Status

Assignee

Mincong Huang

Reporter

Yoann Rodière

Labels

None

Suitable for new contributors

None

Feedback Requested

None

Components

Priority

Major