[rfc][icedtea-web] immutbale transaltor

[Jiri Vanek]

On 09/18/2014 03:55 PM, Omair Majid wrote:
> * Jiri Vanek <jvanek at redhat.com> [2014-09-18 06:44]:
>> ok. I thought the answer will be like that:)
>>
>> Note - I do not insist on this patch. But I would really like to know
>> why is which approach better.  They both have advantages and
>> disadvantages.  From my point of view, the "my" approach is little bit
>> better.
>
> As you said, both have advantages and disadvantages. One of the
> advantages of the current approach is that it forces the JVM to deal
> with all the issues of correctness/initialization even in the presence
> of multi-threading and serialization. It's basically bullet-proof - a
> programmer can do whatever he (or she) wants but the JVM will not allow
> creating another instance.
>
> Your approach is obviously better for testing since someone can create a
> fake instance of the class and use it, and still allow a single global
> instance to be used.
>
>> On 09/17/2014 09:57 PM, Omair Majid wrote:
>>> Wait, what. How does this follow from the above?
>>
>> Testability?
>
> Okay, sure, then call the patch that, please. Saying that the patch is
> making the class immutable when immutability does not require your other
> changes is slightly misleading. Saying that the ability to test is
> driving this change is more accurate, I think.
>
>>>> Personally,  why people use enums for singletons?!?!?!
>>>
>>> Please see Effective Java for an explanation. There's a summary on
>>> StackOverflow [0] too.
>>
>> I read both. The approaches seems to me equal.  And whether use enum
>> or "my" depends on actual needs.
>
> I am not disagreeing, btw :) A variant of "your" approach is sort-of the
> recommended approach to enable testing in Working Effectively With
> Legacy Code.
>
>>  From definition of singleton is clear that it have to have max 1 isntance in
>> app. But nowhere is written, that you are forbid to create testing
>> instances.
>
> I see your point. And I agree that for better testing, we should be able
> to create sub-instances of it. That said, I am pretty sure the goal of a
> singleton is to have exactly one instance - including the instance in
> tests. It's not often considered an anti-pattern for no reason :)
>
>> Any ideas how to
>>   - keep enum, made it immutbale, and test it?
>> or
>>   - made it immutbale, testable and eget rid of those constructors?
>>     - here I have idea - to made the properties actually protected final. And
>> to hide all contructors in Transaltor itself, but create special constructor
>> in TestableTrasnslator?
>>
>
> Let's split out the immutable problem. I am pretty sure it can be made
> immutable using the current approach too (enums can have constructors).
> So the issue is how to make it testable.
>
> Can you define your goal for 'being testable'? Do you want to test the
> class itself, or are you more interested in testing other code that uses
> this class?
>

I wont to keep it testable in similar way Jie did in original changeset - as is the test now.
== on fake data.

Also I wont to allow tests of real singleton (well thats easy)

And  change properties to be final and so get rid of the terrible laodProperties method.


Is it clarified? Sorry for confusion.


J