commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Karlsen <davidkarl...@gmail.com>
Subject Re: [lang] Running lang under a security manager and LANG-744
Date Tue, 06 Sep 2011 04:44:04 GMT
I think tying to sun classes is a bad idea.
Den 6. sep. 2011 05:54 skrev "sebb" <sebbaz@gmail.com> følgende:
> On 6 September 2011 04:33, Henri Yandell <flamefew@gmail.com> wrote:
>> On Sat, Sep 3, 2011 at 8:10 AM, sebb <sebbaz@gmail.com> wrote:
>>> On 3 September 2011 05:37, Henri Yandell <flamefew@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message