Handling Null Values in ConcurrentHashMap

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Handling Null Values in ConcurrentHashMap

Tutika Chakravarthy
Hi ,
I would like to replace some Hashmaps in our
application, which are prone to multi threading issues
with ConCurrentHashMap.

Currently we keep null key and values in hashmap
without any issues as HashMap allows them.

But ConcurrentHashMap does not allow any null key and
values .

I would like to know whether anybody is following any
general practice to tackle this issue .

It is very difficult to check for null keys and values
in my entire application .


I thought of writing a wrapper around
ConcurrentHashMap which will mask and unmask key and
values with some other object, when null values are
getting inserted .

But the issue is that in certain bulk operations like
keySet() , values() etc, it is very difficult unmask
them.

If anybody has ideas in resolving this kind of issue,
Please let me know.
It would be helpful to us .

Tutika

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Handling Null Values in ConcurrentHashMap

Holger Hoffstätte-2
Tutika Chakravarthy wrote:
> I would like to replace some Hashmaps in our
> application, which are prone to multi threading issues
> with ConCurrentHashMap.

You must understand upfront that this may or may not give you the desired
results, though it will 'likely' 'work' in your case. The
ConcurrentModificationExceptions that you probably see are just a symptom
of a deeper root cause; it is a good idea to fix that instead of taping up
the symptom, simply because it is very likely that you will simply see
other concurrency bugs after this visible problem has been 'fixed'.

The problem with concurrency is not the bugs that you see (like CME); be
thankful for those.

> Currently we keep null key and values in hashmap
> without any issues as HashMap allows them.

Yes, this is a terrible error in the Java Map classes.

> But ConcurrentHashMap does not allow any null key and
> values .
> I would like to know whether anybody is following any
> general practice to tackle this issue .

Make it caller's policy to check for both key and value to be not null.
Include tests for this policy in your unit tests (if you have any).

> It is very difficult to check for null keys and values
> in my entire application .

This is just the price to pay for using the broken HashMap behaviour in
the first place. The "standard" Java libraries are full of these hidden
long-term cost factors. :-(

> I thought of writing a wrapper around
> ConcurrentHashMap which will mask and unmask key and
> values with some other object, when null values are
> getting inserted .
>
> But the issue is that in certain bulk operations like
> keySet() , values() etc, it is very difficult unmask
> them.

Right. Even then you'd still have the problem that you need to find all
callers of the existing Map constructors and fix them up; this may or may
not be possible, e.g. if you get the Map from somewhere else.

> If anybody has ideas in resolving this kind of issue,
> Please let me know.

You have several options.

1) accept that you have a concurrency problem and fix the root cause, not
just the symptoms by trying to "fix" the Map behaviour; it is just an
indicator that something else is wrong. This may mean a full, partial or
subsystem-limited concurrency analysis of either the whole application or
the affected subsystem (if there are any). This also means that you have
to come up with a stringent definition of what it means for your
application (or the relevant part) to be concurrent. This will expose the
critical sections that you can then address, _for example_ by simply using
a Collections.synchronizedMap() around the original, or by using a
ConcurrentHashMap.

2) invert the above approach and 'invade' all offending code parts with
AOP; this would enable you to fix existing JARs as well. I have attached a
simple AspectJ MapCheck aspect with example that you can weave into your
application. Currently this will throw IllegalArgumentExceptions, but of
course you could modify this by skipping the put operation or using
default values. Please think VERY hard whether this works for your case,
because you may end up replacing values with the default key because a
caller erroneously passed a null key, or vice versa. The existing aspect
was meant to expose the null key/value problems as early as possible.
Skipping the operation may or may not be a viable option in your case.

There is no easy solution/quick fix to your problem.

Holger


package mapcheck;

import java.util.Map;

public aspect MapNullCheck
{

        pointcut methodsToCheck(Object key, Object value):
            call(public Object Map.put(Object, Object))
            && args(key, value)
            && within(MapAccess);

        Object around(Object key, Object value): methodsToCheck(key, value)
        {
                if (key != null)
                {
                        if (value != null)
                        {
                                return proceed(key, value);
                        }
                        else
                        {
                                throw new IllegalArgumentException("no null values!");
                        }
                }
                else
                {
                        throw new IllegalArgumentException("no null keys!");
                }
        }

}


package mapcheck;

import java.util.HashMap;
import java.util.Map;

import org.apache.log4j.Logger;

public class MapAccess
{
    private static Logger log = Logger.getLogger(MapAccess.class);

    public static void main(String[] args)
    {
        Map<String, String> m = new HashMap<String, String>();
        m.put("foo", "bar");
        m.put("keyForNullValue", null);
        m.put(null, "valueForNullKey");
        log.info("map with nulls: " + m);
    }

}

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Handling Null Values in ConcurrentHashMap

Doug Lea
In reply to this post by Tutika Chakravarthy
Tutika Chakravarthy wrote:

> Hi ,
> I would like to replace some Hashmaps in our
> application, which are prone to multi threading issues
> with ConCurrentHashMap.
>
> Currently we keep null key and values in hashmap
> without any issues as HashMap allows them.
>
> But ConcurrentHashMap does not allow any null key and
> values .
>

Try to take Holger's advice. As mostly an aside though...

The main reason that nulls aren't allowed in ConcurrentMaps
(ConcurrentHashMaps, ConcurrentSkipListMaps) is that
ambiguities that may be just barely tolerable in non-concurrent
maps can't be accommodated. The main one is that if
map.get(key) returns null, you can't detect whether the
key explicitly maps to null vs the key isn't mapped.
In a non-concurrent map, you can check this via map.contains(key),
but in a concurrent one, the map might have changed between calls.

Further digressing: I personally think that allowing
nulls in Maps (also Sets) is an open invitation for programs
to contain errors that remain undetected until
they break at just the wrong time. (Whether to allow nulls even
in non-concurrent Maps/Sets is one of the few design issues surrounding
Collections that Josh Bloch and I have long disagreed about.)

>
> It is very difficult to check for null keys and values
> in my entire application .
>

Would it be easier to declare somewhere
   static final Object NULL = new Object();
and replace all use of nulls in uses of maps with NULL?

-Doug
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Handling Null Values in ConcurrentHashMap

Joshua Bloch-2
Doug,

On 5/12/06, Doug Lea <[hidden email]> wrote:

> Further digressing: I personally think that allowing
> nulls in Maps (also Sets) is an open invitation for programs
> to contain errors that remain undetected until
> they break at just the wrong time. (Whether to allow nulls even
> in non-concurrent Maps/Sets is one of the few design issues surrounding
> Collections that Josh Bloch and I have long disagreed about.)

I have moved towards your position over the years.  It was probably a
mistake to allow null keys in Maps and null elements in Sets.  I'm
still not sure about Map values and List elements.

In other words, Doug hates null more than I do, but over the years
I've come to see it as quite troublesome.

       Josh

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Handling Null Values in ConcurrentHashMap

Bob Lee-8
In reply to this post by Doug Lea
On 5/12/06, Doug Lea <[hidden email]> wrote:
> Would it be easier to declare somewhere
>    static final Object NULL = new Object();
> and replace all use of nulls in uses of maps with NULL?

Enums also work great here:
http://crazybob.org/2005/12/null-placeholders-in-jdk-15.html

Bob

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Handling Null Values in ConcurrentHashMap

tpeierls
On 5/12/06, Bob Lee <[hidden email]> wrote:
On 5/12/06, Doug Lea <[hidden email]> wrote:
> Would it be easier to declare somewhere
>    static final Object NULL = new Object();
> and replace all use of nulls in uses of maps with NULL?

Enums also work great here:
http://crazybob.org/2005/12/null-placeholders-in-jdk-15.html

And for getting around in a generics-enabled world:

public class Null<T> {
    private static final Object NULL = new Object();
    public static T null() { return (T) NULL; }
    public static boolean isNull(T x) { return x == NULL; }
    private Null() {}
}

Get a null value for type Foo with Null.<Foo>null(). Test it with Null.isNull(foo) or get CCEs in the same way that you would get NPE if you were using primitive null.

--tim

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Handling Null Values in ConcurrentHashMap

Bob Lee-8
The nice part about using an enum is that everything works even after
you serialize and deserialize your object.

Bob

On 5/12/06, Tim Peierls <[hidden email]> wrote:

> On 5/12/06, Bob Lee <[hidden email]> wrote:
>
> > On 5/12/06, Doug Lea <[hidden email]> wrote:
> > > Would it be easier to declare somewhere
> > >    static final Object NULL = new Object();
> > > and replace all use of nulls in uses of maps with NULL?
> >
> > Enums also work great here:
> >
> http://crazybob.org/2005/12/null-placeholders-in-jdk-15.html
>
>
> And for getting around in a generics-enabled world:
>
> public class Null<T> {
>     private static final Object NULL = new Object();
>     public static T null() { return (T) NULL; }
>     public static boolean isNull(T x) { return x == NULL; }
>     private Null() {}
> }
>
> Get a null value for type Foo with Null.<Foo>null(). Test it with
> Null.isNull(foo) or get CCEs in the same way that you would get NPE if you
> were using primitive null.
>
> --tim

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Handling Null Values in ConcurrentHashMap

tpeierls
So how about something like this?

public enum Null {
    VALUE
;
    public static T null() { return (T) VALUE; }
    public static boolean isNull(T x) { return x == VALUE; }
}

--tim

On 5/12/06, Bob Lee <[hidden email]> wrote:
The nice part about using an enum is that everything works even after
you serialize and deserialize your object.

Bob

On 5/12/06, Tim Peierls <[hidden email]> wrote:

> On 5/12/06, Bob Lee <[hidden email]> wrote:
>
> > On 5/12/06, Doug Lea <[hidden email]> wrote:
> > > Would it be easier to declare somewhere
> > >    static final Object NULL = new Object();
> > > and replace all use of nulls in uses of maps with NULL?
> >
> > Enums also work great here:
> >
> http://crazybob.org/2005/12/null-placeholders-in-jdk-15.html
>
>
> And for getting around in a generics-enabled world:
>
> public class Null<T> {
>     private static final Object NULL = new Object();
>     public static T null() { return (T) NULL; }
>     public static boolean isNull(T x) { return x == NULL; }
>     private Null() {}
> }
>
> Get a null value for type Foo with Null.<Foo>null(). Test it with
> Null.isNull(foo) or get CCEs in the same way that you would get NPE if you
> were using primitive null.
>
> --tim


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Handling Null Values in ConcurrentHashMap

tpeierls
In reply to this post by Bob Lee-8
So how about something like this?

public enum Null {
    VALUE
;
    public static T value() { return (T) VALUE; }
    public static boolean isNull(T value) { return value == VALUE; }
}

Use Null.<Foo>value() in Set<Foo>, but don't forget to check Null.isNull(foo).

--tim

On 5/12/06, Bob Lee <[hidden email]> wrote:
The nice part about using an enum is that everything works even after
you serialize and deserialize your object.

Bob

On 5/12/06, Tim Peierls <[hidden email]> wrote:
> On 5/12/06, Bob Lee <[hidden email]> wrote:
>
> > On 5/12/06, Doug Lea <[hidden email]> wrote:
> > > Would it be easier to declare somewhere

> > >    static final Object NULL = new Object();
> > > and replace all use of nulls in uses of maps with NULL?
> >
> > Enums also work great here:
> >
> http://crazybob.org/2005/12/null-placeholders-in-jdk-15.html
>
>
> And for getting around in a generics-enabled world:
>
> public class Null<T> {
>     private static final Object NULL = new Object();
>     public static T null() { return (T) NULL; }
>     public static boolean isNull(T x) { return x == NULL; }
>     private Null() {}
> }
>
> Get a null value for type Foo with Null.<Foo>null(). Test it with
> Null.isNull(foo) or get CCEs in the same way that you would get NPE if you
> were using primitive null.
>
> --tim


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Handling Null Values in ConcurrentHashMap

Joshua Bloch-2
Tim and Bob,

These are interesting/cool patterns, but they're a bit scary, as they
cast something that isn't a T to (T).  You have to be very careful
what you do with the the pseudo-null.  I can see using this inside a
library, but I would think more than twice before putting it in the
JDK.

       Josh

On 5/12/06, Tim Peierls <[hidden email]> wrote:

> So how about something like this?
>
>
> public enum Null {
>     VALUE;
>     public static T value() { return (T) VALUE; }
>     public static boolean isNull(T value) { return value == VALUE; }
> }
>
> Use Null.<Foo>value() in Set<Foo>, but don't forget to check
> Null.isNull(foo).
>
> --tim
>
>
> --tim
>
>
> On 5/12/06, Bob Lee <[hidden email]> wrote:
> > The nice part about using an enum is that everything works even after
> > you serialize and deserialize your object.
> >
> > Bob
> >
> > On 5/12/06, Tim Peierls <[hidden email]> wrote:
> > > On 5/12/06, Bob Lee <[hidden email]> wrote:
> > >
> > > > On 5/12/06, Doug Lea <[hidden email]> wrote:
> > > > > Would it be easier to declare somewhere
> > > > >    static final Object NULL = new Object();
> > > > > and replace all use of nulls in uses of maps with NULL?
> > > >
> > > > Enums also work great here:
> > > >
> > >
> http://crazybob.org/2005/12/null-placeholders-in-jdk-15.html
> > >
> > >
> > > And for getting around in a generics-enabled world:
> > >
> > > public class Null<T> {
> > >     private static final Object NULL = new Object();
> > >     public static T null() { return (T) NULL; }
> > >     public static boolean isNull(T x) { return x == NULL; }
> > >     private Null() {}
> > > }
> > >
> > > Get a null value for type Foo with Null.<Foo>null(). Test it with
> > > Null.isNull(foo) or get CCEs in the same way that you would get NPE if
> you
> > > were using primitive null.
> > >
> > > --tim
> >
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Handling Null Values in ConcurrentHashMap

Bob Lee-8
Hey! I didn't recommend that. ;)

In the blog I linked to, I said:

"Things can still get a little hairy when you mix null placeholders
with generic types. Your placeholder can implement the same type as
the value, or you can resort to casting hacks."

OK, I said, "you can," but I wouldn't do it myself.

The nice thing about the enum null placeholder is that it's so short
and sweet you don't have to refactor it out into a common place and
risk infecting others with bad ideas. ;)

Bob

On 5/12/06, Joshua Bloch <[hidden email]> wrote:

> Tim and Bob,
>
> These are interesting/cool patterns, but they're a bit scary, as they
> cast something that isn't a T to (T).  You have to be very careful
> what you do with the the pseudo-null.  I can see using this inside a
> library, but I would think more than twice before putting it in the
> JDK.
>
>        Josh
>
> On 5/12/06, Tim Peierls <[hidden email]> wrote:
> > So how about something like this?
> >
> >
> > public enum Null {
> >     VALUE;
> >     public static T value() { return (T) VALUE; }
> >     public static boolean isNull(T value) { return value == VALUE; }
> > }
> >
> > Use Null.<Foo>value() in Set<Foo>, but don't forget to check
> > Null.isNull(foo).
> >
> > --tim
> >
> >
> > --tim
> >
> >
> > On 5/12/06, Bob Lee <[hidden email]> wrote:
> > > The nice part about using an enum is that everything works even after
> > > you serialize and deserialize your object.
> > >
> > > Bob
> > >
> > > On 5/12/06, Tim Peierls <[hidden email]> wrote:
> > > > On 5/12/06, Bob Lee <[hidden email]> wrote:
> > > >
> > > > > On 5/12/06, Doug Lea <[hidden email]> wrote:
> > > > > > Would it be easier to declare somewhere
> > > > > >    static final Object NULL = new Object();
> > > > > > and replace all use of nulls in uses of maps with NULL?
> > > > >
> > > > > Enums also work great here:
> > > > >
> > > >
> > http://crazybob.org/2005/12/null-placeholders-in-jdk-15.html
> > > >
> > > >
> > > > And for getting around in a generics-enabled world:
> > > >
> > > > public class Null<T> {
> > > >     private static final Object NULL = new Object();
> > > >     public static T null() { return (T) NULL; }
> > > >     public static boolean isNull(T x) { return x == NULL; }
> > > >     private Null() {}
> > > > }
> > > >
> > > > Get a null value for type Foo with Null.<Foo>null(). Test it with
> > > > Null.isNull(foo) or get CCEs in the same way that you would get NPE if
> > you
> > > > were using primitive null.
> > > >
> > > > --tim
> > >
> >
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > [hidden email]
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> >
> >
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Handling Null Values in ConcurrentHashMap

tpeierls
And I would certainly recommend avoiding null in the first place over any of this. This was all in the context of Doug's reaction to an expressed need to deal with null values in collections.

--tim

On 5/12/06, Bob Lee <[hidden email]> wrote:
Hey! I didn't recommend that. ;)

In the blog I linked to, I said:

"Things can still get a little hairy when you mix null placeholders
with generic types. Your placeholder can implement the same type as
the value, or you can resort to casting hacks."

OK, I said, "you can," but I wouldn't do it myself.

The nice thing about the enum null placeholder is that it's so short
and sweet you don't have to refactor it out into a common place and
risk infecting others with bad ideas. ;)

Bob

On 5/12/06, Joshua Bloch <[hidden email]> wrote:

> Tim and Bob,
>
> These are interesting/cool patterns, but they're a bit scary, as they
> cast something that isn't a T to (T).  You have to be very careful
> what you do with the the pseudo-null.  I can see using this inside a
> library, but I would think more than twice before putting it in the
> JDK.
>
>        Josh
>
> On 5/12/06, Tim Peierls <[hidden email]> wrote:
> > So how about something like this?
> >
> >
> > public enum Null {
> >     VALUE;
> >     public static T value() { return (T) VALUE; }
> >     public static boolean isNull(T value) { return value == VALUE; }
> > }
> >
> > Use Null.<Foo>value() in Set<Foo>, but don't forget to check
> > Null.isNull(foo).
> >
> > --tim
> >
> >
> > --tim
> >
> >
> > On 5/12/06, Bob Lee <[hidden email]> wrote:

> > > The nice part about using an enum is that everything works even after
> > > you serialize and deserialize your object.
> > >
> > > Bob
> > >
> > > On 5/12/06, Tim Peierls <[hidden email]> wrote:
> > > > On 5/12/06, Bob Lee <[hidden email]> wrote:
> > > >
> > > > > On 5/12/06, Doug Lea <[hidden email]> wrote:
> > > > > > Would it be easier to declare somewhere
> > > > > >    static final Object NULL = new Object();
> > > > > > and replace all use of nulls in uses of maps with NULL?
> > > > >
> > > > > Enums also work great here:
> > > > >
> > > >
> > http://crazybob.org/2005/12/null-placeholders-in-jdk-15.html
> > > >
> > > >
> > > > And for getting around in a generics-enabled world:
> > > >
> > > > public class Null<T> {
> > > >     private static final Object NULL = new Object();
> > > >     public static T null() { return (T) NULL; }
> > > >     public static boolean isNull(T x) { return x == NULL; }
> > > >     private Null() {}
> > > > }
> > > >
> > > > Get a null value for type Foo with Null.<Foo>null(). Test it with
> > > > Null.isNull(foo) or get CCEs in the same way that you would get NPE if
> > you
> > > > were using primitive null.
> > > >
> > > > --tim
> > >
> >
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > [hidden email]
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> >
> >
>


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Handling Null Values in ConcurrentHashMap

tpeierls
David Holmes says that a retraction is in order. He points out that the code I posted not only doesn't compile, it doesn't even work if you fix the code! You may be able to insert Null-ish values into collections of other types, but when you iterate over the collection, you'll get a ClassCastException.

So I take back the suggestion. Generics are tricky. Stick to non-null values (and keys!) in collections and maps. Try to rewrite code that depends on sticking nulls in collections to use the Null *pattern* instead -- that's the one where you provide a special implementation of your interface that can be tested for nullity. It preserves type-safety and is strongly recommended over using the primitive null value.

Next time I'll write a test program before mouthing off. :-(

--tim

On 5/12/06, Tim Peierls <[hidden email]> wrote:
And I would certainly recommend avoiding null in the first place over any of this. This was all in the context of Doug's reaction to an expressed need to deal with null values in collections.


--tim

On 5/12/06, Bob Lee <[hidden email]> wrote:
Hey! I didn't recommend that. ;)

In the blog I linked to, I said:

"Things can still get a little hairy when you mix null placeholders
with generic types. Your placeholder can implement the same type as
the value, or you can resort to casting hacks."

OK, I said, "you can," but I wouldn't do it myself.

The nice thing about the enum null placeholder is that it's so short
and sweet you don't have to refactor it out into a common place and
risk infecting others with bad ideas. ;)

Bob

On 5/12/06, Joshua Bloch <[hidden email]> wrote:

> Tim and Bob,
>
> These are interesting/cool patterns, but they're a bit scary, as they
> cast something that isn't a T to (T).  You have to be very careful
> what you do with the the pseudo-null.  I can see using this inside a
> library, but I would think more than twice before putting it in the
> JDK.
>
>        Josh
>
> On 5/12/06, Tim Peierls <[hidden email]> wrote:
> > So how about something like this?
> >
> >
> > public enum Null {
> >     VALUE;
> >     public static T value() { return (T) VALUE; }
> >     public static boolean isNull(T value) { return value == VALUE; }
> > }
> >
> > Use Null.<Foo>value() in Set<Foo>, but don't forget to check
> > Null.isNull(foo).
> >
> > --tim
> >
> >
> > --tim
> >
> >
> > On 5/12/06, Bob Lee <[hidden email]> wrote:

> > > The nice part about using an enum is that everything works even after
> > > you serialize and deserialize your object.
> > >
> > > Bob
> > >
> > > On 5/12/06, Tim Peierls <[hidden email]> wrote:
> > > > On 5/12/06, Bob Lee <[hidden email]> wrote:
> > > >
> > > > > On 5/12/06, Doug Lea <[hidden email]> wrote:
> > > > > > Would it be easier to declare somewhere
> > > > > >    static final Object NULL = new Object();
> > > > > > and replace all use of nulls in uses of maps with NULL?
> > > > >
> > > > > Enums also work great here:
> > > > >
> > > >
> > <a href="http://crazybob.org/2005/12/null-placeholders-in-jdk-15.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://crazybob.org/2005/12/null-placeholders-in-jdk-15.html
> > > >
> > > >
> > > > And for getting around in a generics-enabled world:
> > > >
> > > > public class Null<T> {
> > > >     private static final Object NULL = new Object();
> > > >     public static T null() { return (T) NULL; }
> > > >     public static boolean isNull(T x) { return x == NULL; }
> > > >     private Null() {}
> > > > }
> > > >
> > > > Get a null value for type Foo with Null.<Foo>null(). Test it with
> > > > Null.isNull(foo) or get CCEs in the same way that you would get NPE if
> > you
> > > > were using primitive null.
> > > >
> > > > --tim
> > >
> >
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > [hidden email]
> > <a href="http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> >
> >
>



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest