I'm working on a fix now. Have a look when it is committed to see if
it can be improved.
On 6 September 2011 15:48, Paul Benedict <pbened...@apache.org> wrote:
> Make the sun class be loaded dynamically -- not statically -- and if
> it is not present, just throw an UnsupportedOperationException? I
> think that would solve Android's problem.
>
> On Tue, Sep 6, 2011 at 8:36 AM, sebb <seb...@gmail.com> wrote:
>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
