Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #14871

Re: Proposed new Java feature

From Robert Klemme <shortcutter@googlemail.com>
Newsgroups comp.lang.java.programmer
Subject Re: Proposed new Java feature
Date 2012-05-28 22:58 +0200
Message-ID <a2i77nFik2U1@mid.individual.net> (permalink)
References (8 earlier) <jpu9aj$t3p$1@dont-email.me> <a2h1djFoq2U2@mid.individual.net> <jq05ij$kt9$1@dont-email.me> <a2hqv5F695U1@mid.individual.net> <jq0iuo$cq6$1@dont-email.me>

Show all headers | View raw


On 28.05.2012 21:16, markspace wrote:
> On 5/28/2012 10:29 AM, Robert Klemme wrote:
>
>> However I think about it: the idea of simply clearing ThreadLocal
>> references still does not become a good idea. The creator of a
>> ThreadLocal needs to consider how it is used and how cleanup is done.
>> Everything else introduces dangerous side effects which lead to bugs
>> which are at least as hard to find as those memory leaks.
>
> Naw, I just disagree. Saying that the creator is responsible for cleanup
> is like saying that because some objects need an explicit "close," we
> should force those semantics onto all objects.

The cleanup method does not need to be overridden - that's why I did not 
make it abstract.  There is no semantic forced on all objects.

Also, I don't see the implication: If clearing references is sufficient 
then that's perfectly OK.  But, as you noticed, there are objects which 
require some explicit cleanup.  Only the author of the code which 
creates a ThreadLocal can know how it must be cleaned up.  With the 
global reference nulling you are actually forcing semantics on all 
because then there is just this one way.  Since 
ThreadLocal.initialValue() is there for custom initialization, it's as 
reasonable to provide a hook for resource deallocation code. (Btw., 
that's the same pattern callback interfaces for object pools employ.)

If one does not want the cleanup hook for all ThreadLocals, one can 
place the cleanup functionality in a sub class of ThreadLocal thus not 
affecting existing code at all.

> If you have a thread local that requires special semantics, go ahead and
> provide the special code for those objects. The rest of the code can use
> a common cleanup up mechanism that MOST objects require: just GC them.

The point is that with the global reference cleanup the specific code 
does not have a chance to run because it does not know when.  The proper 
point in time is just before or during remove().

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-26 16:11 -0700
  Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-27 13:32 +0200
    Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 11:14 -0700
      Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 12:13 +0200
      Re: Proposed new Java feature v_borchert@despammed.com (Volker Borchert) - 2012-06-04 20:16 +0000
  Re: Proposed new Java feature markspace <-@.> - 2012-05-27 09:28 -0700
    Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 11:00 -0700
      Re: Proposed new Java feature Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-27 11:46 -0700
        Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 12:04 -0700
          Re: Proposed new Java feature Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-27 15:30 -0400
            Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 12:59 -0700
              Re: Proposed new Java feature Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-05-27 17:51 -0400
                Re: Proposed new Java feature markspace <-@.> - 2012-05-27 15:20 -0700
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 12:13 +0200
                Re: Proposed new Java feature markspace <-@.> - 2012-05-28 08:28 -0700
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 19:29 +0200
                Re: Proposed new Java feature markspace <-@.> - 2012-05-28 12:16 -0700
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 22:58 +0200
                Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-28 21:40 -0700
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-29 22:52 +0200
                Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-29 18:53 -0700
                Re: Proposed new Java feature Tom Anderson <twic@urchin.earth.li> - 2012-05-27 23:27 +0100
                Re: Proposed new Java feature Robert Klemme <shortcutter@googlemail.com> - 2012-05-28 12:22 +0200
                Re: Proposed new Java feature "Mike Schilling" <mscottschilling@hotmail.com> - 2012-05-27 21:43 -0700
                Re: Proposed new Java feature Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-05-29 14:32 +0000
  Re: Proposed new Java feature Tom Anderson <twic@urchin.earth.li> - 2012-05-27 18:43 +0100
  Re: Proposed new Java feature Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-06-02 12:41 -0700
    Re: Proposed new Java feature markspace <-@.> - 2012-06-02 15:55 -0700

csiph-web