On 6 September 2011 05:44, David Karlsen <davidkarl...@gmail.com> wrote:
> I think tying to sun classes is a bad idea.
Yes, which is why the code checks to see if the class is present.
If the Java 6 method is available, then it uses that, otherwise it
checks for the Sun method.
If neither is available, then the code throws an
UnsupportedOperationException in the stripAccents() method.
> Den 6. sep. 2011 05:54 skrev "sebb" <seb...@gmail.com> følgende:
>> On 6 September 2011 04:33, Henri Yandell <flame...@gmail.com> wrote:
>>> On Sat, Sep 3, 2011 at 8:10 AM, sebb <seb...@gmail.com> wrote:
>>>> On 3 September 2011 05:37, Henri Yandell <flame...@gmail.com> wrote:
>>>>> I'm less concerned with the 115 errors, unless they're all as grievous
>>>>> as the StringUtils one - ie) the method causing trouble is not the
>>>>> only one broken.
>>>>>
>>>>> If the error happened when calling stripAccents, that would be
>>>>> workable; but having all of StringUtils unavailable is very painful.
>>>>> One option would be to move the code out of the static initializer and
>>>>> make it lazy when stripAccents is first called - leading to only
>>>>> callers of stripAccents when the JDK 6 class is unavailable to suffer
>>>>> pain.
>>>>
>>>> I thought we'd already fixed that by catching the extra Exception?
>>>>
>>>> I already suggested localising the error display to the stripAccents
> method.
>>>
>>> Sorry - not operating at 100% last week.
>>>
>>>>> I thought we could simplify things by simply making the java6Available
>>>>> flag be a real test for Java 6, but Android seems very weird there. Is
>>>>> Android going to force us to stay on the EOL Java 5, or is it Java 6
>>>>> compatible? IIUC it reports itself as 0.9, which we've declared as
>>>>> equivalent to JDK 1.5.
>>>>
>>>> Are you sure that is the issue?
>>>> Surely the Android problem is that we check for the sun class but
>>>> don't handle all possible errors?
>>>> So the class does not load; it cannot use the Java6 method even if it
> exists.
>>>
>>> I'm very confused between Android and GAE :)
>>>
>>>>> That relates to another (simple) solution - move to Java 6 :)
>>>>
>>>> Or capture Exception for both the java6 and sun tests; report the
>>>> exception(s) if neither is available when required.
>>>
>>> I like this. Capture the exception in the static initializer and then
>>> throw a new runtime exception in stripAccents that refers to said
>>> exception. Perhaps an IllegalStateException("blah", originalException)
>>> ?
>>
>> It currently throws UnsupportedOperationException; I think we should
>> keep that as it's more accurate.
>>
>> There will always be two Exceptions at that point (otherwise we must
>> have Java 6 or Sun).
>> We know we need to report the Sun Exception - is there any need to
>> report the Java 6 exception?
>> i.e. could we be running on Java 6 but still get an Exception?
>>
>> For completeness (and debugging) we should probably report both.
>>
>> Perhaps we could nest the exceptions.
>>
>>> Hen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
