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.