ADBA Add type safe newFactory method

Douglas Surber douglas.surber at oracle.com
Fri Jul 13 17:48:19 UTC 2018


The internal consensus is to change the spec exactly as you suggest and require the explicit cast if that’s what the user wants. I still would like to hear what others think.

  public static DataSourceFactory newFactory(String name) { … }

  DataSourceFactory factory = DataSourceFactory.newFactory(“my.adba.MyFactory”);

or 

  MyFactory factory = (MyFactory) DataSourceFactory.newFactory(“my.adba.MyFactory”);

Douglas



> On Jul 13, 2018, at 9:46 AM, Douglas Surber <douglas.surber at oracle.com> wrote:
> 
> This is a good question. I defined it the way I did specifically to avoid the explicit cast. I have no strong opinion on which is better. I’ll ask for opinions internally and I hope other members of this list give their thoughts.
> 
> Douglas
> 
>> On Jul 13, 2018, at 8:26 AM, Mark Rotteveel <mark at lawinegevaar.nl> wrote:
>> 
>> The existing DataSourceFactory.newFactory(String name) has an unchecked cast using a (possibly inferred) type parameter.
>> 
>> Would it make sense to add an alternative with the signature:
>> 
>> public static <T extends DataSourceFactory> T newFactory(Class<T> clazz)
>> 
>> When you use this, you are tied to an ADBA implementation at compile time, but it will make this more type-safe.
>> 
>> And maybe the unchecked cast (and type parameter) should be removed from the variant taking a name only.
>> 
>> That is, change the method to
>> 
>> public static DataSourceFactory newFactory(String name) {
>>   if (name == null) throw new IllegalArgumentException("DataSourceFactory name is null");
>>   return ServiceLoader
>>           .load(DataSourceFactory.class)
>>           .stream()
>>           .filter(p -> p.type().getName().equals(name))
>>           .findFirst()
>>           .map(Provider::get)
>>           .orElse(null);
>> }
>> 
>> Any casts would then be the explicit responsibility of the developer, instead of accidental due to type inference.
>> 
>> Mark
>> -- 
>> Mark Rotteveel
> 



More information about the jdbc-spec-discuss mailing list