clazz.newInstance() is a horrible call. For example, it breaks the
compile time guarantees about checked Exceptions. newInstance can throw
anything it likes.
Guess what happens if there doesn't happen to be a default constructor?
Oops!!
On 5/18/2010 12:23 PM, Bill Shannon wrote:
> Jason Lee wrote on 5/18/10 11:58 AM:
>
>> On 5/18/10 1:15 PM, Bill Shannon wrote:
>>
>>> I looked into adding support to ParamModel for getting these default
>>> values from the fields, but it was just too big of a change. Right
>>> now the model has all the information it needs without reference to
>>> an instance of the class, changing that started to get pretty ugly.
>>> I wasn't happy with the result, so I gave up.
>>>
>> My from the hip idea was to do something like
>>
>> instance = clazz.newInstance();
>> for each field :
>> param = field.getAnnotation(Param.class)
>> value =
>> if (param.defaultValue == null):
>> param.defaultValue = field.get(instance)
>>
>> Roughly. Seems like we could do that when building up the ParamModel
>> and not have to keep the instance around, but I've though on that only
>> fairly abstractly. However...
>>
> Creating an instance just to extract this value is pretty disgusting,
> and as you said might have side effects. Using an existing instance
> was pretty disgusting too, at least the way I was trying to do it.
>
>
>>> The simple answer is that you have to put the default value in the
>>> annotation. I know, I know, I don't like it either, but I like it
>>> better than the alternative I came up with. Maybe you can do better...
>>>
>> This is certainly the easier solution, even if it is more work up
>> front. At some point, someone is going to touch all of the Param usages
>> to add the camelCaseName attribute we decided upon last week, so it
>> would be fairly trivial to add this additional, minor change. There's a
>> good chance the REST team will get to do a lot of that, so I don't mind
>> suggesting the extra work. :)
>>
> camelCaseName attribute? Looking forward to your writeup of the issues
> and decision after our last meeting on this subject...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
>
--
Byron Nevins - Oracle Corporation
Home: 650-359-1290
Cell: 650-784-4123
Sierra: 209-295-2188