Re: svn commit: r586925 [1/2] - in /ofbiz/trunk: applications/accounting/src/org/ofbiz/accounting/finaccount/ applications/accounting/src/org/ofbiz/accounting/invoice/ applications/accounting/src/org/ofbiz/accounting/payment/ applications/content/src

[Andrew Zeneski <an...@hotwaxmedia.com>]

I agree. I do not want to see this becoming a pain. However, the  
changes I put into UtilMisc to seem to have solved this problem (at  
least for the entity sync code). Not saying its the best fix, but for  
me UtilMisc.<String, Object>toMap() is just not an option.

Andrew

On Oct 22, 2007, at 4:00 AM:

> From: David E Jones <jo...@hotwaxmedia.com>
> Date: October 21, 2007 4:38:14 PM EDT
> To: dev@ofbiz.apache.org
> Subject: Re: svn commit: r586925 [1/2] - in /ofbiz/trunk:  
> applications/accounting/src/org/ofbiz/accounting/finaccount/  
> applications/accounting/src/org/ofbiz/accounting/invoice/  
> applications/accounting/src/org/ofbiz/accounting/payment/  
> applications/content/src
>
>
>
> On Oct 21, 2007, at 1:04 PM, Adam Heath wrote:
>
>> Scott Gray wrote:
>>> That looks like a PITA, do we have to include <String, Object> on  
>>> all toMap
>>> calls now?
>>
>> No.
>>
>> ==
>> Map context = UtilMisc.toMap(....);
>> dispatcher.runSync(serviceName, context);
>> ==
>>
>> It's only when you have it inline that it is a problem.  javac is not
>> currently smart enough when it comes to type-inference; I've  
>> discussed
>> this with the openjdk people, and they confirmed it.
>>
>> If any part of the line uses generics, then javac attempts to make  
>> all
>> parts use it.  It javac applied type-erasure to the return of toMap,
>> *and* to the call to runSync, then it would be able to find a  
>> matching
>> method to call.
>
> I'm interested in hearing other opinions, but I think this is a  
> good reason to delay our use of generics for certain things,  
> especially for things that should be minimally cumbersome, like  
> dispatcher calls with UtilMisc.toMap inline, which is really the  
> primary use scenario for the toMap method...
>
> Hopefully this new feature in Java will mature more in the near  
> future, but in the mean time we shouldn't be too aggressive in  
> adopting and using it. I know the intentions are good, but the  
> result is what is important. I'm all for progress, but from a  
> pragmatic perspective only.
>
> -David
>