Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Inserting In a List

Reply
Thread Tools

Inserting In a List

 
 
markspace
Guest
Posts: n/a
 
      04-04-2013
On 4/3/2013 5:10 PM, Arne Vajh?j wrote:
>
> It can be very important in multithreaded context.
>
> But it is not what makes a class immutable.


OK, that's true. The section I linked to refers to such objects as
"thread safe immutable." It's both concepts in one package. Objects
that aren't thread safe aren't immutable, and objects that aren't
immutable aren't thread safe. I guess that's why the two go together.

final is required, but you also have to actually prevent any
modification to the object's state after it is constructed. It is a two
part process, that is true.

 
Reply With Quote
 
 
 
 
Arne Vajh?j
Guest
Posts: n/a
 
      04-04-2013
On 4/3/2013 8:24 PM, markspace wrote:
> On 4/3/2013 5:05 PM, Arne Vajh?j wrote:
>> But now you raise the question, then final is only slightly
>> involved in immutability in Java.
>>
>> If is neither sufficient nor necessary to make them
>> immutable.

>
> final is necessary.


No.

> It is not sufficient (you also have to not mutate
> the object in question after the enclosing object's ctor exits). I'm
> pretty sure the field must also be explicitly private. (Implicitly
> might not be enough to satisfy what ever escape analysis the Java
> compiler does.)
>
>>
>> Bloch recommends using final for immutables to:
>> - express intention
>> - work better with the Java memory model

>
> Read Java Concurrency in Practice. That's what I'm referring too.


My copy page 47 footnote 12 says:

"It is technically possible to have an immutable object without all
fields being final"

Is that missing in your copy?

Arne


 
Reply With Quote
 
 
 
 
markspace
Guest
Posts: n/a
 
      04-04-2013
On 4/3/2013 5:27 PM, Arne Vajh?j wrote:
> On 4/3/2013 8:21 PM, markspace wrote:
>> On 4/3/2013 5:08 PM, Arne Vajh?j wrote:
>>
>>> Yes. But you you seemed to imply that I meant it based
>>> on the JLS thing.

>>
>> No, I was replying to Joerg.

>
> Hmm.
>
> You replied to a post by me and only quoted me.


The first post I made was to Joerg:

On 4/3/2013 12:01 PM, Joerg Meier wrote:

> "final" makes a variable or field impossible to reassign. It says
> absolutely nothing at all about whether or not that variables is
> modifiable. What you are thinking of is immutability, something that

is not
> formalized in Java.



Then you replied to me, saying that the section of the JLS I linked to
"17.5 Final Field Semantics" doesn't define immutability in Java
formally or informally. Which is wrong, if you just scan that section
for uses of the word "immutable." So that's where I kind of lost it.

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      04-04-2013
On 4/3/2013 6:37 PM, Martin Gregorie wrote:
> On Tue, 02 Apr 2013 21:08:26 -0400, Eric Sosman wrote:
>
>> On 4/2/2013 6:52 PM, Martin Gregorie wrote:
>>>[...]
>>> I use it a lot, both for that and because accessing stored objects by
>>> key from a TreeMap is almost certainly faster than scanning an ArrayMap
>>> unless it contains very few objects indeed.

>>
>> Sorry: "ArrayMap"?
>>

> I meant ArrayList - my bad.


Okay, I still don't understand: How does "accessing stored
objects by key" pertain to an ArrayList, or to any List? You
can hunt through a List to find an element equal to a search
object (or having some specified relation to it), but "by key?"
There's nothing in the List abstraction to distinguish "key"
from "value" from "haddocks' eyes:" Something's in the List or
it ain't, and that's all.

For my part, I think that if you want to list a directory's
content in some sorted order, the preferred approach is to form
a List of the contents, paying no attention to order, and then
sort it at the end. Spending extra time and memory computing
intermediate results that you won't use seems pointless. YMMV.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
Joerg Meier
Guest
Posts: n/a
 
      04-04-2013
On Wed, 03 Apr 2013 17:29:35 -0700, markspace wrote:

> On 4/3/2013 5:10 PM, Arne Vajh?j wrote:
>> It can be very important in multithreaded context.


>> But it is not what makes a class immutable.

> OK, that's true. The section I linked to refers to such objects as
> "thread safe immutable." It's both concepts in one package. Objects
> that aren't thread safe aren't immutable, and objects that aren't
> immutable aren't thread safe. I guess that's why the two go together.


I don't have time to answer your other, longer post before I have to leave,
but this one I wanted to interject on before I alt-f4 for the day: while
immutable objects are of course thread safe (due to there not being
anything that can be done to them that needs synchronization), of course
you can make thread safe objects that are mutable.

I don't even know what you were thinking when you wrote that. What do you
think locks and the synchronized keyword are for ? Immutable objects don't
need them.

> final is required, but you also have to actually prevent any
> modification to the object's state after it is constructed. It is a two
> part process, that is true.


Again: you can make immutable objects without final perfectly fine. It is
absolutely not required.

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      04-04-2013
On 4/3/2013 8:34 PM, markspace wrote:
> On 4/3/2013 5:27 PM, Arne Vajh?j wrote:
>> On 4/3/2013 8:21 PM, markspace wrote:
>>> On 4/3/2013 5:08 PM, Arne Vajh?j wrote:
>>>
>>>> Yes. But you you seemed to imply that I meant it based
>>>> on the JLS thing.
>>>
>>> No, I was replying to Joerg.

>>
>> Hmm.
>>
>> You replied to a post by me and only quoted me.

>
> The first post I made was to Joerg:
>
> On 4/3/2013 12:01 PM, Joerg Meier wrote:
>
> > "final" makes a variable or field impossible to reassign. It says
> > absolutely nothing at all about whether or not that variables is
> > modifiable. What you are thinking of is immutability, something that

> is not
> > formalized in Java.

>
>
> Then you replied to me, saying that the section of the JLS I linked to
> "17.5 Final Field Semantics" doesn't define immutability in Java
> formally or informally. Which is wrong, if you just scan that section
> for uses of the word "immutable." So that's where I kind of lost it.


I'm with Arne. The cited section uses the word "immutable"
and "immutability" without defining either. All it says is that
"final" can be an aid to implementing immutable objects -- but it
never says what "immutable" is. It doesn't even say that "final"
confers immutability; on the contrary, it says "final fields must
be *used correctly* [emphasis mine] to provide a guarantee of
immutability."

Toward the end of the section, we're told that String is
"perceived as truly immutable." So now there are two more notions:
"truly immutable" as opposed to merely "immutable," and "perceived
as truly immutable" as opposed to "actually truly immutable, not
dependent on somebody's perception." Where does the JLS define how
these three different kinds of immutability differ? Where does it
*define* even one of them?

Thought experiment: Using the JLS' definition of immutability,
support or refute "java.lang.String is mutable, because it computes
its hashCode() lazily and caches it in a non-final field, thereby
changing the String object's state at the first hashCode() call."

Thought experiment: Using the JLS' definition of immutability,
support or refute "All Java objects are mutable, because all have a
monitor whose state changes every time a synchronized block is
entered or exited. The monitor's state affects the behavior of
all threads attempting to synchronize on the object, so the change
of state is not strictly internal but is visible to all observers."

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      04-04-2013
On 4/3/2013 8:24 PM, markspace wrote:
> On 4/3/2013 5:05 PM, Arne Vajh?j wrote:
>> But now you raise the question, then final is only slightly
>> involved in immutability in Java.
>>
>> If is neither sufficient nor necessary to make them
>> immutable.

>
> final is necessary. [...]


public class Immutable {
private int value;
public Immutable(int value) {
this.value = value;
}
public int getValue() {
return value;
}
}

Claim: Immutable is immutable, despite the lack of "final".

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      04-04-2013
markspace wrote:
> final is necessary. It is not sufficient (you also have to not mutate
> the object in question after the enclosing object's ctor exits). I'm
> pretty sure the field must also be explicitly private. (Implicitly


Nope.

You can have immutable public fields.

> might not be enough to satisfy what ever escape analysis the Java
> compiler does.)


'final' is essential to the definition of constant variables, which do have special
initialization semantics.

'final' is an essential piece in locking down an immutable reference variable of a type; call
this type 'ImmutableA'.

The object referenced by the member is immutable by dint of its implementation, which
we'll postulate to be correct.

public class ImmutableA
{
private String ident = "Immutable instance";
}

While the object referenced by 'ident' is immutable, this is not enough to make instances
of 'ImmutableA' immutable. For that you must have 'final'.

public class ImmutableA
{
private final String ident = "Immutable instance";
}

Now 'ImmutableA' instances are immutable. Not only that, but in this case, because
'ident' is 'final' and initialized by a constant expression, it is now a constant variable.

So 'final' is most assuredly involved in creating immutability, and is more reliable in the
face of refactoring and other maintenance to preserve it than immutability idioms that
do not use 'final'.

--
Lew
 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      04-04-2013
On 4/3/2013 5:32 PM, Arne Vajh?j wrote:
> On 4/3/2013 8:24 PM, markspace wrote:
>> On 4/3/2013 5:05 PM, Arne Vajh?j wrote:
>>> But now you raise the question, then final is only slightly
>>> involved in immutability in Java.
>>>
>>> If is neither sufficient nor necessary to make them
>>> immutable.

>>
>> final is necessary.

>
> No.
>
>> It is not sufficient (you also have to not mutate
>> the object in question after the enclosing object's ctor exits). I'm
>> pretty sure the field must also be explicitly private. (Implicitly
>> might not be enough to satisfy what ever escape analysis the Java
>> compiler does.)
>>
>>>
>>> Bloch recommends using final for immutables to:
>>> - express intention
>>> - work better with the Java memory model

>>
>> Read Java Concurrency in Practice. That's what I'm referring too.

>
> My copy page 47 footnote 12 says:
>
> "It is technically possible to have an immutable object without all
> fields being final"
>
> Is that missing in your copy?


Right and he goes on to say that String is an example. But String does
rely on final fields -- its char array is final -- and its immutability
derives directly from that. Brain Goetz also adds "don't try this at
home" meaning it's difficult to actually do. He's referring to the
idempotentcy [sic?] of its hash code -- but that doesn't work if the
char array is not final.

I'm just talking about the semantics about final here. I'm trying to
not focus on other implication of having a final field. I think the
subject is complicated enough with out introducing other ways to make an
object thread safe immutable. If you want, I'll agree that there are
exceptions, but I have to insist that final is the normal mechanic, and
if one doesn't understand final fields one won't understand the bits
that Brian Goetz says to "don't try this at home."



 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      04-04-2013
On 4/3/2013 6:25 PM, Eric Sosman wrote:

> On 4/3/2013 8:24 PM, markspace wrote:
>> final is necessary. [...]


>
> public class Immutable {
> private int value;
> public Immutable(int value) {
> this.value = value;
> }
> public int getValue() {
> return value;
> }
> }
>
> Claim: Immutable is immutable, despite the lack of "final".
>


Not in the sense of section 17.5 of the JLS, which is what I linked to
above (and also uses the term "thread safe immutable" to describe the
semantics of final fields).

And not in the sense that Brian Goetz uses in JCIP.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Inserting into DB table with date from Generic List =?Utf-8?B?U3Jpbmk=?= ASP .Net 0 11-07-2006 04:33 AM
inserting into a list John Salerno Python 15 03-08-2006 06:02 AM
Linked list inserting items from two different funcion Kay C++ 1 09-03-2004 03:48 PM
Urgent:Inserting records from datagrid through drop down list Muhammad Usman ASP .Net 1 10-16-2003 01:39 PM
Inserting an empty element in a list (STL) Massimiliano Alberti C++ 3 09-24-2003 05:48 PM



Advertisments