Regarding AdbaType.JAVA_OBJECT

[Douglas Surber]

Nothing in ADBA between Session.Builder.build and Session.close is mandatory. Supporting the various SessionProperties and DataSourceProperties is all optional as well. If it makes sense for a particular implementation to support a feature, it should. Better to use the standard API than create a new one. But if some ADBA feature does not make sense for a particular implementation that implementation should not support that feature. It is better for a feature not to be supported at all rather than being a mis-feature or poorly supported. App developers should be able to rely on the implementation. If something in ADBA would not work well with a particular implementation it should fail immediately. Any feature that works at all should work well.

Douglas

> On Sep 19, 2018, at 6:39 AM, Alexander Kjäll <alexander.kjall at gmail.com> wrote:
> 
> My personal opinion is that this feature isn't widely in use and is very hard or maybe impossible to implement without deserialization security holes, so the gains from dropping it outweights the loss of functionality.
> 
> Just my 0.02€
> 
> //Alex
> 
> On 17. sep. 2018 21:36, Douglas Surber wrote:
>> JAVA_OBJECT is included in AdbaType solely because it is in JDBCTypes and JDBCType. How and if it is implemented is entirely up to the database vendor and/or driver implementer. Or we can remove it.
>> 
>> Douglas
>> 
>>> On Sep 17, 2018, at 12:08 PM, Alexander Kjäll <alexander.kjall at gmail.com> wrote:
>>> 
>>> Hi
>>> 
>>> I would like to ask about how the JAVA_OBJECT type is supposed to be
>>> implemented.
>>> 
>>> One way to do it would be to use java's built in serialization, but
>>> that's impossible without creating a serialization security hole in
>>> the driver, same if I serialize it to xml/json and let arbitrary types
>>> be deserialized.
>>> 
>>> One way to maybe implement it without security holes is to let the end
>>> user register classes that are allowed, but that feels very clunky.
>>> 
>>> I'm also questioning the usefulness of this feature in regard to all
>>> the serialization security holes java are suffering from, is it really
>>> needed or can it be dropped?
>>> 
>>> best regards
>>> Alexander Kjäll
>