Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Inserting In a List

 
 
Joerg Meier
Guest
Posts: n/a
 
      04-04-2013
On Wed, 03 Apr 2013 20:55:40 -0300, Arved Sandstrom wrote:

> On 04/03/2013 08:35 PM, Joerg Meier wrote:
>> On Wed, 03 Apr 2013 20:30:53 -0300, Arved Sandstrom wrote:
>>> As for the questions, what are Java primitives if not value types? And I

>> val data types != value types, a val type is a variable type that can be
>> used like:


>> for (val file : fileList) { ... // val is of type File here }


>> Basically an inferred type.

> OK, I misconstrued your use of the term "val". Sure, like "var" and
> "val" in various languages. Yes, we don't have that in Java.


Actually, we do - if you count third party libraries

> So truthfully I'd have to say that Java has neither, not by my usage.


Then we just use the term differently. I'm alright with that.

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
 
Reply With Quote
 
 
 
 
Arne Vajh?j
Guest
Posts: n/a
 
      04-04-2013
On 4/3/2013 7:56 PM, Arne Vajh?j wrote:
> On 4/3/2013 6:41 PM, markspace wrote:
>> On 4/3/2013 3:22 PM, Arne Vajh?j wrote:
>>
>>> The text you quote do not define immutable neither formal nor informal.
>>>
>>> It refer to the concept.
>>>
>>> If immutable is defined formally somewhere in the JLS it must be
>>> somewhere else.
>>>
>>> Until we have a ref, then I can't see anything misleading.

>>
>>
>> Are you serious, Arne?

>
> Very.
>
>> Did you read the section I linked to? I didn't
>> quote the whole thing, it would be immense. I just quoted one line to
>> show that the section did talk about immutability, not to definitively
>> establish all the ins-and-outs of immutability in the JLS. There's no
>> point in me copying what you can read yourself.

>
> JLS referring to immutability is utterly irrelevant.
>
> The question is whether JLS defines it.
>
> Feel free to quote where it defines it.
>
> Or stop making claims.
>
>> Honestly I'm shocked at your response and I think you're missing the
>> point by a wide margin. Are you trying to tell me that final fields are
>> not involved in immutability in Java?

>
> I was just pointing out that what you quoted from JLS did not
> support your claim that JLS had a formal definition of immutability.
>
> I find it a bit difficult to see why you think that implies
> "final fields are not involved in immutability in Java".


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.

Bloch recommends using final for immutables to:
- express intention
- work better with the Java memory model

Arne

 
Reply With Quote
 
 
 
 
Arne Vajh?j
Guest
Posts: n/a
 
      04-04-2013
On 4/3/2013 7:58 PM, markspace wrote:
> On 4/3/2013 4:56 PM, Arne Vajh?j wrote:
>> I was just pointing out that what you quoted from JLS did not
>> support your claim that JLS had a formal definition of immutability.

>
> But I don't care if you believe. The link is for your sake.


So it is there but you just don't want to provide the quote yourself.

Do you think that sounds credible?

>> I find it a bit difficult to see why you think that implies
>> "final fields are not involved in immutability in Java".

>
> Er, I'm saying the opposite.


Yes. But you you seemed to imply that I meant it based
on the JLS thing.

Arne


 
Reply With Quote
 
Arne Vajh?j
Guest
Posts: n/a
 
      04-04-2013
On 4/3/2013 7:44 PM, markspace wrote:
> On 4/3/2013 4:25 PM, Joerg Meier wrote:
>
>> Yours would be immutable with or without the final keyword.

>
> No no no. This is my point. The final keyword has special semantics
> associated with it in that particular case. It works a bit like the
> volatile keyword: all writes to that point are made visible. In the
> case of a private final field, the writes are made visible to ALL
> THREADS in the system. THAT is what makes instances of the class
> Stooges immutable.
>
> That's why no synchronization is needed. Which is huge, conceptually.


It can be very important in multithreaded context.

But it is not what makes a class immutable.

Arne


 
Reply With Quote
 
Arne Vajh?j
Guest
Posts: n/a
 
      04-04-2013
On 4/3/2013 2:09 AM, Robert Klemme wrote:
> On 02.04.2013 22:41, Eric Sosman wrote:
>> On 4/2/2013 3:06 PM, Robert Klemme wrote:
>>> [...]
>>> I believe in using "final" pretty often as it will immediately indicate
>>> which local variables are constant for a method call and which are
>>> modified all the time. [...]

>>
>> De gustibus non disputandum est, but I think "final" should
>> be reserved for things that *mustn't* change, and shouldn't just
>> be pasted on to anything that happens to remain constant in the
>> code's current incarnation. When considering a change to some
>> code I might see
>>
>> Thing thing = getThing();
>> // ... code that doesn't happen to change `thing'

>
> I am so used to using "final" that this immediately makes me wonder why
> it's not final - did the author intend to not change it, forget to
> change it or forgot the "final"?


Many years ago the fathers of Java designed it so that default was
var and the final modifier could change that.

They could have decide to make val default and have a nonfinal
modifier that could change that.

You are trying to code as if they had picked the second.

Arne


 
Reply With Quote
 
Arne Vajh?j
Guest
Posts: n/a
 
      04-04-2013
On 4/2/2013 10:29 PM, Eric Sosman wrote:
> On 4/2/2013 9:26 PM, Arne Vajh?j wrote:
>> On 4/2/2013 9:03 PM, Eric Sosman wrote:
>>> On 4/2/2013 8:20 PM, Arne Vajh?j wrote:
>>>> On 4/2/2013 8:04 PM, Joerg Meier wrote:
>>>>> On Tue, 2 Apr 2013 22:52:20 +0000 (UTC), Martin Gregorie wrote:
>>>>>
>>>>>> On Tue, 02 Apr 2013 18:22:55 -0400, Eric Sosman wrote:
>>>>>>> On 4/2/2013 5:06 PM, Martin Gregorie wrote:
>>>>>>>> [...]
>>>>>>>> Its also not clear to me whether the OP is expecting some form of
>>>>>>>> sorted list of filenames. If he is expecting that, it would be
>>>>>>>> best to
>>>>>>>> use a TreeMap<String> rather than an ArrayList<String> to store the
>>>>>>>> filenames.
>>>>>>> Is there a reason to prefer TreeMap (or other SortedMap) over
>>>>>>> accumulate-disordered-and-sort-afterward?
>>>>>> I think so, yes, because none of File's list() and listFiles()
>>>>>> methods
>>>>>> guarantee the order of the returned files. By using TreeMap or
>>>>>> equivalent
>>>>>> the OP gets the sort for free, should it be required.
>>>>>
>>>>> For free ? The cost is just distributed amongst the insert calls,
>>>>> and is
>>>>> likely considerably higher than with an unsorted list that has a
>>>>> single
>>>>> sort call once it is filled.
>>>>
>>>> It is not that obvious to me that:
>>>>
>>>> n O(1) + 1 O(nlogn) is that much faster than n log(n)
>>>
>>> By design, O() obscures all the coefficients. If you were
>>> to say that n*log(n) and 9999999999999999999999999999*n*log(n)
>>> are both O(n*log(n)) you would be right -- but if you were to
>>> claim the former was not "that much faster" than the latter you
>>> would be wrong by a factor of 9999999999999999999999999999.

>>
>> Yes.
>>
>> But given same big-O I would expect some solid reasons for a
>> big difference in coefficients before I assume a big difference
>> in performance.
>>
>>> ... and that's the gist of my question: It seems to me likely
>>> that the actual time to sort an ArrayList of large-ish N size will
>>> be less than the time to build a TreeMap (BTW, Martin probably
>>> meant TreeSet) of the same N items. Argument: The TreeSet expends
>>> effort in keeping itself always sorted all the time, while the
>>> ArrayList has the freedom to be disordered up until the end, and
>>> then to impose an ordering just once. The ArrayList is asked to
>>> present one sorted version of N items, while the TreeSet must
>>> offer sorted versions of 1,2,3,...,N items. If the intermediate
>>> orderings are not required, I don't see much reason to compute them.

>>
>> I can follow you so far that TreeSort is likely a bit slower
>> than the ArrayList sort.
>>
>> But I can not see any reason to expect a big difference.
>>
>> It is fundamentally the same divide and conquer principle
>> applied.

>
> The original assertion is "it would be *best* [emphasis mine]
> to use a TreeMap<String> [sic] rather than an ArrayList<String>".
> I'm not claiming that the difference is "big," nor even that the
> difference is "important" -- for reasonably-sized directories, at
> any rate. What I'm questioning is "best."


But I did not comment on Martin's "best".

I commented on Joerg's "likely considerably higher".

Arne

 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      04-04-2013
On 4/3/2013 4:57 PM, Joerg Meier wrote:

> That initial write is not synchronized to other threads.


Yes it is! (Not immediately synchronized, at the end of the ctor.)
Read the JLS, besides the part I quoted above:

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5.1>

"Let o be an object, and c be a constructor for o in which a final field
f is written. A freeze action on final field f of o takes place when c
exits, either normally or abruptly....

Given a write w, a freeze f, an action a (that is not a read of a final
field), a read r1 of the final field frozen by f, and a read r2 such
that hb(w, f), hb(f, a), mc(a, r1), and dereferences(r1, r2), then when
determining which values can be seen by r2, we consider hb(w, r2). (This
happens-before ordering does not transitively close with other
happens-before orderings.) "

That's as clear as mud, but what it means is that objects referenced by
final fields, and all writes to those objects, are made visible at the
end of the object's ctor.

> If
> you let an object instance get out that isn't fully constructed, then you
> will get the usual synchornization issues, final or not. Don't believe me ?


This is true. If the final field object escapes from the enclosing
class, or any writes are made after the object is constructed, then both
immutability and thread-safety are broken.

> If I misunderstood, and you believe that structural changes to the
> ArrayList would be visible to all threads, then you are still wrong,


In the second example you gave where the reference to 'stooges' leaves
the enclosing class, it is definitely neither immutable nor thread-safe.

> The mere use of final does not remove the need for synchronization.


Yes it does! That was explicitly stated in the very short bit I quoted
at the beginning of this whole mess.

> Nor
> does the mere lack of it dictate a need.


No. 'final' is special here.

> The reason synchronization is not
> needed with proper immutability is an effect from what final does - because
> it can only be assigned once, once it is you can then let everyone play
> with it, because you dont NEED to worry about writes - there will be none.


No, you still need to, at a low level, insert a memory barrier to make
those writes visible. You'd need to use synchronization or a volatile
variable or some other synchronization in Java, or you could see a
partially constructed object. Just like any regular object that doesn't
use final or volatile fields.

Also, go read Java Concurrency in Practice by Brian Goetz. He covers
this in some detail (complete with Stooges example).

 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      04-04-2013
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.


 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      04-04-2013
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. 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.

 
Reply With Quote
 
Arne Vajh?j
Guest
Posts: n/a
 
      04-04-2013
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.

A bit difficult to guess that you were actually replying to Joerg.

Arne


 
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