You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Henri Yandell (JIRA)" <ji...@apache.org> on 2006/12/25 07:36:21 UTC

[jira] Created: (LANG-305) Deprecate methods found in the JDK 1.5/1.6?

Deprecate methods found in the JDK 1.5/1.6?
-------------------------------------------

                 Key: LANG-305
                 URL: http://issues.apache.org/jira/browse/LANG-305
             Project: Commons Lang
          Issue Type: Task
    Affects Versions: 2.2
            Reporter: Henri Yandell


Not too sure on this one - but it seems to me that it would be a good time to deprecate the methods that now have replacements in the standard Java libraries.

We could also consider deprecating methods that have replacements in Joda Time. This would allow us to consider removing them in 3.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


[jira] Commented: (LANG-305) Deprecate methods found in the JDK 1.5/1.6?

Posted by "Stephen Colebourne (JIRA)" <ji...@apache.org>.
    [ http://issues.apache.org/jira/browse/LANG-305?page=comments#action_12461060 ] 
            
Stephen Colebourne commented on LANG-305:
-----------------------------------------

I am opposed to this. [lang] provides lots of stuff that is still useful despite later versions of the JDK.

StrBuilder cannot be replaced by StringBuilder as it has much more functionality. So do our enums. So do the static methods.

I don't see vast benefits in generics either in [lang]. It would help in a few places, but whether its enough to justify it is questionable.

> Deprecate methods found in the JDK 1.5/1.6?
> -------------------------------------------
>
>                 Key: LANG-305
>                 URL: http://issues.apache.org/jira/browse/LANG-305
>             Project: Commons Lang
>          Issue Type: Task
>    Affects Versions: 2.2
>            Reporter: Henri Yandell
>             Fix For: 2.3
>
>
> Not too sure on this one - but it seems to me that it would be a good time to deprecate the methods that now have replacements in the standard Java libraries.
> We could also consider deprecating methods that have replacements in Joda Time. This would allow us to consider removing them in 3.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


[jira] Commented: (LANG-305) Deprecate methods found in the JDK 1.5/1.6?

Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
    [ http://issues.apache.org/jira/browse/LANG-305?page=comments#action_12460926 ] 
            
Henri Yandell commented on LANG-305:
------------------------------------

Deprecate list:

text.StrBuilder in favour of JDK 1.6's StringBuilder.
enums.* in favour of JDK 1.5 enums.
exception.Nestable* in favour of JDK 1.4's Exception cause.
StringUtils.contains(String, String) in favour of JDK 1.5's String.contains(CharSequence)
StringUtils.replace(String, String, String) in favour of JDK 1.5's String.replace(String, String); however we have overloads.
StringUtils.split(String, *) in favour of JDK 1.4's String.split methods. Again, overloads.

Refactor:

rewrite code to use Generics and autoboxing (?) Would simplify a whole bunch of copy and pasted pattern methods we have, but speed loss in autoboxing might be bad for some of them.

StringUtils.isEmpty could delegate down to JDK 1.6's String.isEmpty; though it still adds null protection to the JDK version.



> Deprecate methods found in the JDK 1.5/1.6?
> -------------------------------------------
>
>                 Key: LANG-305
>                 URL: http://issues.apache.org/jira/browse/LANG-305
>             Project: Commons Lang
>          Issue Type: Task
>    Affects Versions: 2.2
>            Reporter: Henri Yandell
>             Fix For: 2.3
>
>
> Not too sure on this one - but it seems to me that it would be a good time to deprecate the methods that now have replacements in the standard Java libraries.
> We could also consider deprecating methods that have replacements in Joda Time. This would allow us to consider removing them in 3.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


[jira] Updated: (LANG-305) Deprecate methods found in the JDK 1.5/1.6?

Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/LANG-305?page=all ]

Henri Yandell updated LANG-305:
-------------------------------

    Fix Version/s: 2.3

> Deprecate methods found in the JDK 1.5/1.6?
> -------------------------------------------
>
>                 Key: LANG-305
>                 URL: http://issues.apache.org/jira/browse/LANG-305
>             Project: Commons Lang
>          Issue Type: Task
>    Affects Versions: 2.2
>            Reporter: Henri Yandell
>             Fix For: 2.3
>
>
> Not too sure on this one - but it seems to me that it would be a good time to deprecate the methods that now have replacements in the standard Java libraries.
> We could also consider deprecating methods that have replacements in Joda Time. This would allow us to consider removing them in 3.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


[jira] Resolved: (LANG-305) Deprecate methods found in the JDK 1.5/1.6?

Posted by "Stephen Colebourne (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/LANG-305?page=all ]

Stephen Colebourne resolved LANG-305.
-------------------------------------

    Fix Version/s:     (was: 2.3)
       Resolution: Won't Fix

> Deprecate methods found in the JDK 1.5/1.6?
> -------------------------------------------
>
>                 Key: LANG-305
>                 URL: http://issues.apache.org/jira/browse/LANG-305
>             Project: Commons Lang
>          Issue Type: Task
>    Affects Versions: 2.2
>            Reporter: Henri Yandell
>
> Not too sure on this one - but it seems to me that it would be a good time to deprecate the methods that now have replacements in the standard Java libraries.
> We could also consider deprecating methods that have replacements in Joda Time. This would allow us to consider removing them in 3.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org