What methods should go into a java.util.Objects class in JDK 7?

Joel Kamentz Joel.Kamentz at sas.com
Wed Sep 16 15:20:18 UTC 2009


It's more for I/O, not general Object, but some methods which I almost ALWAYS use in a project are null-safe canonicalization and null-safe close methods.

    static File canonical(File f) {
        if (f == null) return null;
        try { return f.getCanonicalFile(); }
        catch (IOException e) { return f.getAbsoluteFile(); }
    }

    static void close(Reader s) {
        if (s == null) return;
        try { s.close(); }
        catch (IOException e) {}
    }

    static void close(Writer s) {
        if (s == null) return;
        try { s.close(); }
        catch (IOException e) {}
    }

    static void close(InputStream s) {
        if (s == null) return;
        try { s.close(); }
        catch (IOException e) {}
    }

    ... repeat for other stream types as necessary, like ZipFile, RandomAccessFile, etc. because no common inheritance

In some projects I've changed the above to instead have the pattern of

    static IOException close(InputStream s) {
        if (s != null) {
            try { s.close(); }
            catch (IOException e) { return e; }
        }
        return null;
    }


IMO, these are quite general in use as one should always clean up and close after I/O, but if the rest of it succeeded, one rarely cares if the close method hiccups:

    InputStream s = null;
    try {
        s = new FileInputStream(...);
        ...
    } catch (IOException e) {
        // if handling instead of throwing to caller
    } finally { close(s); }



I also think join methods would be useful for strings / collections of strings or similar.


Other things I often do are:

        Attempt to convert an URL to a local file, taking into account that it might be wrappered by jar:, that File.toURL doesn't process %20 and the like, etc.

        Delete files or sub-trees, catching exceptions and instead just return success / failure.

        Copy an InputStream to an OutputStream with supplied byte buffer (or allocate one internally).  General file (or stream or ?) copying utility methods might be useful.

        Sometimes I want strings sorted case-insensitively, but without losing case (or during equals comparison).


Joel



-----Original Message-----
From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Ryan Slobojan
Sent: Friday, September 11, 2009 10:39 AM
To: core-libs-dev at openjdk.java.net
Subject: Re: What methods should go into a java.util.Objects class in JDK 7?

> Hello.
>
> For JDK 7, I think it is high-time the platform included a class like
> java.util.Objects to hold commonly-written utility methods.  For
> example, a two-argument static equals method that returned true if
> both
> arguments are null, returns false is one argument is null, and
> otherwise
> returns the result of calling arg1.equals(arg2)  (6797535 "Add shared
> two argument static equals method to the platform").
>
> A static hashCode method returning 0 for null and the value of
> arg.hashCode() has also been suggested.
>
> A set of
>
>     static int compareTo(int, int)
>     static int compareTo(long, long)
>     ....
>
> methods probably belongs somewhere in the platform too.
>
> What other utility methods would have broad enough use and
> applicability
> to go into a common java.util class?
>
> -Joe
Hi,

As a note, I've just put up an article about this on InfoQ soliciting
feedback from the wider Java community:

http://www.infoq.com/news/2009/09/jdk7-java-utils-object

Thanks,

Ryan Slobojan




More information about the core-libs-dev mailing list