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
