Support common java types in @BatchProperty injection about batch HOT 9 CLOSED

I agree on the take around adding a converter abstraction. I'd think that the spec would keep it very bare bones with implementations being allowed to provide more as they see fit. I do think that the list as provided is probably too broad (Logger?).

from batch.

We should probably break this apart and use this current issue for a relative few types. If we wanted to add a converter abstraction that could be done later/separately (or just left to impls).

What about starting from the list of JSF converters: https://docs.oracle.com/javaee/7/tutorial/jsf-page-core001.htm

BigDecimalConverter | javax.faces.BigDecimal
BigIntegerConverter | javax.faces.BigInteger
BooleanConverter | javax.faces.Boolean
ByteConverter | javax.faces.Byte
CharacterConverter | javax.faces.Character
DateTimeConverter | javax.faces.DateTime
DoubleConverter | javax.faces.Double
EnumConverter | javax.faces.Enum
FloatConverter | javax.faces.Float
IntegerConverter | javax.faces.Integer
LongConverter | javax.faces.Long
NumberConverter | javax.faces.Number
ShortConverter | javax.faces.Short

The JSF package would not be visible in the batch API in any way... it's just a useful set of primitive/almost-primitive types.

from batch.

Reading the comments we have had, the majority opinion seems to err on the side of specifying less rather than more (and leaving it up to the implementation).

So I'll propose we specify support for the java.lang types: (Boolean, Byte, Character, Double, Float, Integer, Long, Short) and the corresponding primitives, using the constructors w/ String parms.

I'm also going to raise the issue in the Config spec going forward.

from batch.

For reference, noting JBeret's function implemented here: https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/creation/ValueConverter.java

from batch.

using the constructors w/ String parms

Why not parseXXX as preferred since several versions?

otherwise +1

from batch.

Why not parseXXX as preferred since several versions?

I was looking at the Java 8 doc and didn't realize that so agree, when these are deprecated in newer versions we should use better ones like valueOf, parseXXX, etc.

from batch.

I removed Byte and Character since I didn't want to have to think about conversion to/from String.

from batch.

Hmm, Byte has valueOf no? And Character is mainly string.charAt(0) or fail. No need of the to conversion which is a toString btw ;).
But agree it is not a big deal to not handle it.

from batch.

Though it'd be trivial to come up with a sensible scheme... to take the time to research whatever precedent there is around these tiny details is just not worth it given that you can easily use another type.

from batch.