Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #23175 > unrolled thread
| Started by | subhabangalore@gmail.com |
|---|---|
| First post | 2013-04-02 03:11 -0700 |
| Last post | 2013-04-03 10:35 +0100 |
| Articles | 20 on this page of 161 — 18 participants |
Back to article view | Back to comp.lang.java.programmer
Inserting In a List subhabangalore@gmail.com - 2013-04-02 03:11 -0700
Re: Inserting In a List Roedy Green <see_website@mindprod.com.invalid> - 2013-04-02 03:59 -0700
Re: Inserting In a List Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-02 08:27 -0300
Re: Inserting In a List Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-02 08:59 -0300
Re: Inserting In a List Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-02 21:06 +0000
Re: Inserting In a List Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-02 18:22 -0400
Re: Inserting In a List Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-02 22:52 +0000
Re: Inserting In a List Joerg Meier <joergmmeier@arcor.de> - 2013-04-03 02:04 +0200
Re: Inserting In a List Arne Vajhøj <arne@vajhoej.dk> - 2013-04-02 20:20 -0400
Re: Inserting In a List Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-02 21:03 -0400
Re: Inserting In a List Arne Vajhøj <arne@vajhoej.dk> - 2013-04-02 21:26 -0400
Re: Inserting In a List Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-02 22:29 -0400
Re: Inserting In a List Arne Vajhøj <arne@vajhoej.dk> - 2013-04-03 20:16 -0400
Re: Inserting In a List Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-04-02 20:26 -0500
Re: Inserting In a List Arne Vajhøj <arne@vajhoej.dk> - 2013-04-02 21:29 -0400
Re: Inserting In a List Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 14:07 +0200
Re: Inserting In a List Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-03 05:45 -0300
Re: Inserting In a List Joerg Meier <joergmmeier@arcor.de> - 2013-04-03 15:26 +0200
Re: Inserting In a List Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-03 18:09 -0300
Re: Inserting In a List Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 00:54 +0200
Re: Inserting In a List Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-03 20:30 -0300
Re: Inserting In a List Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 01:35 +0200
Re: Inserting In a List Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-03 20:55 -0300
Re: Inserting In a List Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 02:00 +0200
Re: Inserting In a List Arne Vajhøj <arne@vajhoej.dk> - 2013-04-03 19:49 -0400
Re: Inserting In a List Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-03 22:43 +0000
Re: Inserting In a List Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 01:08 +0200
Re: Inserting In a List Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-04 00:42 +0000
Re: Inserting In a List Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 14:12 +0200
Re: Inserting In a List Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-04 21:47 +0000
Re: Inserting In a List Joerg Meier <joergmmeier@arcor.de> - 2013-04-05 00:36 +0200
Re: Inserting In a List Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-02 21:08 -0400
Re: Inserting In a List Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-03 22:37 +0000
Re: Inserting In a List Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-03 20:50 -0400
Re: Inserting In a List Joerg Meier <joergmmeier@arcor.de> - 2013-04-02 14:35 +0200
Re: Inserting In a List lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-02 15:08 +0100
Usefulness of "final" (Was: Re: Inserting In a List) Robert Klemme <shortcutter@googlemail.com> - 2013-04-02 21:06 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-02 16:41 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) Robert Klemme <shortcutter@googlemail.com> - 2013-04-03 08:09 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arne Vajhøj <arne@vajhoej.dk> - 2013-04-03 20:13 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arne Vajhøj <arne@vajhoej.dk> - 2013-04-02 20:08 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-03 11:15 +0100
Re: Usefulness of "final" (Was: Re: Inserting In a List) Robert Klemme <shortcutter@googlemail.com> - 2013-04-03 19:08 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-03 19:51 +0100
Re: Usefulness of "final" (Was: Re: Inserting In a List) Joerg Meier <joergmmeier@arcor.de> - 2013-04-03 21:01 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 14:15 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arne Vajhøj <arne@vajhoej.dk> - 2013-04-03 18:22 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 15:41 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arne Vajhøj <arne@vajhoej.dk> - 2013-04-03 19:56 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 16:58 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arne Vajhøj <arne@vajhoej.dk> - 2013-04-03 20:08 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 17:21 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arne Vajhøj <arne@vajhoej.dk> - 2013-04-03 20:27 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 17:34 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-03 21:20 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 19:17 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Lew <lewbloch@gmail.com> - 2013-04-03 20:45 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 21:30 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 14:34 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-04 09:52 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Joerg Meier <joergmmeier@arcor.de> - 2013-04-05 00:39 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) Robert Klemme <shortcutter@googlemail.com> - 2013-04-04 19:50 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-04 08:27 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-04 09:47 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Robert Klemme <shortcutter@googlemail.com> - 2013-04-04 19:44 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-04 11:08 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Robert Klemme <shortcutter@googlemail.com> - 2013-04-04 22:53 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-04 14:29 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Robert Klemme <shortcutter@googlemail.com> - 2013-04-05 21:54 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-04 19:48 +0100
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arne Vajhøj <arne@vajhoej.dk> - 2013-04-03 20:05 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 17:24 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arne Vajhøj <arne@vajhoej.dk> - 2013-04-03 20:32 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 18:34 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arne Vajhøj <arne@vajhoej.dk> - 2013-04-03 21:54 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-03 21:25 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 18:37 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arne Vajhøj <arne@vajhoej.dk> - 2013-04-03 21:57 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 19:23 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Wanja Gayk <brixomatic@yahoo.com> - 2013-04-06 21:58 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-06 17:19 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Wanja Gayk <brixomatic@yahoo.com> - 2013-04-07 17:28 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-07 09:02 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Wanja Gayk <brixomatic@yahoo.com> - 2013-04-07 19:20 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) Wanja Gayk <brixomatic@yahoo.com> - 2013-04-07 19:24 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) Lew <lewbloch@gmail.com> - 2013-04-03 18:41 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Lew <lewbloch@gmail.com> - 2013-04-03 18:31 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 18:46 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Lew <lewbloch@gmail.com> - 2013-04-03 20:09 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 20:47 -0700
Re: Usefulness of "final" Leif Roar Moldskred <leifm@dimnakorr.com> - 2013-04-04 00:42 -0500
Re: Usefulness of "final" paul.cager@gmail.com - 2013-04-04 01:55 -0700
Re: Usefulness of "final" Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 14:45 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 00:46 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 16:10 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 01:25 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 16:44 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 01:57 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 17:19 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 14:35 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-04 10:34 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Joerg Meier <joergmmeier@arcor.de> - 2013-04-05 00:43 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-04 16:22 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Lew <lewbloch@gmail.com> - 2013-04-04 16:49 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-04 18:21 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Lew <lewbloch@gmail.com> - 2013-04-04 18:49 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-05 05:30 -0300
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arne Vajhøj <arne@vajhoej.dk> - 2013-04-03 20:10 -0400
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-03 17:29 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 02:53 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) Jim Janney <jjanney@shell.xmission.com> - 2013-04-04 13:51 -0600
Re: Usefulness of "final" (Was: Re: Inserting In a List) Robert Klemme <shortcutter@googlemail.com> - 2013-04-06 13:31 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) markspace <markspace@nospam.nospam> - 2013-04-06 10:50 -0700
Re: Usefulness of "final" (Was: Re: Inserting In a List) lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-04 09:09 +0100
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-04 05:37 -0300
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-04 06:10 -0300
Re: Usefulness of "final" (Was: Re: Inserting In a List) Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-04 19:40 -0300
Re: arrays and variables Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-05 05:44 -0300
Re: arrays and variables lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-05 14:08 +0100
Re: arrays and variables Lew <lewbloch@gmail.com> - 2013-04-05 13:33 -0700
Re: arrays and variables lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-06 09:11 +0100
Re: arrays and variables Robert Klemme <shortcutter@googlemail.com> - 2013-04-06 15:20 +0200
Re: arrays and variables lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-06 16:25 +0100
Re: arrays and variables Robert Klemme <shortcutter@googlemail.com> - 2013-04-06 17:50 +0200
Re: arrays and variables lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-06 18:13 +0100
Re: arrays and variables Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-06 14:32 -0300
Re: arrays and variables Robert Klemme <shortcutter@googlemail.com> - 2013-04-06 15:02 +0200
Re: arrays and variables Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-05 22:12 -0300
Re: Usefulness of "final" (Was: Re: Inserting In a List) lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-04 10:35 +0100
Re: Usefulness of "final" (Was: Re: Inserting In a List) Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 14:02 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-04 13:41 +0100
Re: Usefulness of "final" (Was: Re: Inserting In a List) Joerg Meier <joergmmeier@arcor.de> - 2013-04-04 13:53 +0200
Re: Usefulness of "final" (Was: Re: Inserting In a List) Robert Klemme <shortcutter@googlemail.com> - 2013-04-03 23:05 +0200
Re: Inserting In a List Joerg Meier <joergmmeier@arcor.de> - 2013-04-02 22:09 +0200
Re: Inserting In a List Arne Vajhøj <arne@vajhoej.dk> - 2013-04-02 20:03 -0400
Re: Inserting In a List Wanja Gayk <brixomatic@yahoo.com> - 2013-04-06 21:39 +0200
Re: Inserting In a List Robert Klemme <shortcutter@googlemail.com> - 2013-04-07 01:08 +0200
Re: Inserting In a List Lew <lewbloch@gmail.com> - 2013-04-06 22:15 -0700
Re: Inserting In a List lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-07 08:48 +0100
Re: Inserting In a List Lew <lewbloch@gmail.com> - 2013-04-07 12:32 -0700
Re: Inserting In a List "John B. Matthews" <nospam@nospam.invalid> - 2013-04-07 21:06 -0400
Re: Inserting In a List lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-08 08:40 +0100
Re: Inserting In a List lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-07 08:55 +0100
Re: Inserting In a List Wanja Gayk <brixomatic@yahoo.com> - 2013-04-07 17:54 +0200
Re: Inserting In a List lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-07 19:53 +0100
Re: Inserting In a List Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-07 17:58 -0300
Re: Inserting In a List Robert Klemme <shortcutter@googlemail.com> - 2013-04-08 08:28 +0200
Re: Inserting In a List lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-04-08 08:54 +0100
Re: Inserting In a List Robert Klemme <shortcutter@googlemail.com> - 2013-04-08 19:13 +0200
Re: Inserting In a List Wanja Gayk <brixomatic@yahoo.com> - 2013-04-12 20:58 +0200
Re: Inserting In a List Lew <lewbloch@gmail.com> - 2013-04-12 13:17 -0700
Re: Inserting In a List Lew <lewbloch@gmail.com> - 2013-04-07 12:40 -0700
Re: Inserting In a List Wanja Gayk <brixomatic@yahoo.com> - 2013-04-12 20:47 +0200
Re: Inserting In a List Lew <lewbloch@gmail.com> - 2013-04-12 13:14 -0700
Re: Inserting In a List Steven Simpson <ss@domain.invalid> - 2013-04-02 13:53 +0100
Re: Inserting In a List Roedy Green <see_website@mindprod.com.invalid> - 2013-04-02 07:10 -0700
Re: Inserting In a List Lew <lewbloch@gmail.com> - 2013-04-02 10:46 -0700
Re: Inserting In a List markspace <markspace@nospam.nospam> - 2013-04-02 11:28 -0700
Re: Inserting In a List Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-02 16:00 -0400
Re: Inserting In a List subhabangalore@gmail.com - 2013-04-03 01:47 -0700
Re: Inserting In a List Steven Simpson <ss@domain.invalid> - 2013-04-03 10:35 +0100
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-04 10:34 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjkdfi$qib$1@dont-email.me> |
| In reply to | #23296 |
On 4/4/2013 5:35 AM, Joerg Meier wrote:
> You have to decide:
>
> a) the mere use of final does not remove the need for synchronization
> b) the mere use of final does remove the need for synchronization, and the
> class that exposes the final instance of the list is still thread-safe.
>
I thought it was obvious, but of course you also have to prevent writes
to the object. final is necessary but not sufficient. Mea culpa if
that's the cause of the misunderstanding here. I should have been more
precise in my language. Unfortunately I was just focusing on one aspect
of making an object immutable, just the final-ctor combo, and ignoring
others.
> But you can still have immutable, thread safe objects without final:
>
> public class A {
> private int i = 1;
>
> public int getI(); { return i; }
> }
>
> This class is thread safe and immutable. And completely without final.
No, this is very explicitly wrong, and I'm sure the rest of the list
would agree. (I think you're confusing this with an example using a
static (class) field.)
The JLS explicitly says that writes on one thread are not visible
immediately to another thread. If thread A constructs this object, then
thread B calls getI, it's liable to see the previous value of i (0)
rather than the write by thread A which is still sitting in A's CPU cache.
You have to do something to flush that write out to main memory. In a
nutshell, that's what visibility means in the JLS. Two threads on two
CPUs won't see the same values unless force those writes to flush out to
main memory.
>
> That memory barrier is the ctor. It alone is enough to make the writes
> visible.
No, memory barriers are pretty expensive and the Java compiler doesn't
force them when not needed. Regular ol' POJO objects don't have a
memory barrier at the end of their ctor. That's the whole point of
section 17 in the JLS, Threads and Locks. It tells you how to use your
normally not-thread-safe objects safely.
> I would like to see an example to back up this claim that it's poissible to
> see a partially constructed object merely by it having non-final fields,
> without giving out a reference to the partially constructed object (like I
> did in my example).
There are several good examples in the JLS, which I'm going to refer you
too, so I don't louse-up an example again. There's example 17.4-1 in
the section on the Java memory model:
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4>
There also another example 17.4.5-1 in the section on happens-before
consistency
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.5>
Both of those examples involve two writes, but that doesn't matter. The
accompanying text makes it clear that any write, even one single write,
can be re-ordered by the system.
Also take a look at section 17.4.1 where it talks about shared variables
and heap memory.
<docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.1>
Instance fields are explicitly included, and your class A has an
instance field i that needs to be synchronized somehow. It's not thread
safe on its own.
> Luckily someone else already quoted the point I'm trying to make that you
> disagree with: you can have immutable objects without everything being
> final just fine, as long as you don't let that lack of finality escape out
> into the wild.
That example was really different than what you presented in your
example with the class A above. It's one reason why Arne's example from
JCIP also says "don't try this at home." ;-) It's really tough to
reason about these things and easy to get wrong; really really easy. I
urge you to study this because I'm concerned that you've missed a couple
of not-too-subtle points about concurrency in Java.
[toc] | [prev] | [next] | [standalone]
| From | Joerg Meier <joergmmeier@arcor.de> |
|---|---|
| Date | 2013-04-05 00:43 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <1g6egitgbvtbz.4k1lknlpi9th$.dlg@40tude.net> |
| In reply to | #23306 |
On Thu, 04 Apr 2013 10:34:59 -0700, markspace wrote: I deleted the rest of your post, as it comes down to this: > On 4/4/2013 5:35 AM, Joerg Meier wrote: >> That memory barrier is the ctor. It alone is enough to make the writes >> visible. > No, memory barriers are pretty expensive and the Java compiler doesn't > force them when not needed. Regular ol' POJO objects don't have a > memory barrier at the end of their ctor. That's the whole point of > section 17 in the JLS, Threads and Locks. It tells you how to use your > normally not-thread-safe objects safely. I was under the impression that, well, what I said above was correct. If it's not, the rest of my argument collapses like a house of cards. I'm going to have to put in some more research as I'm not just going to take your word for it, but for now it seems I was wrong. Thanks for the links, I will peruse them at a more civilized hour. It's been a long time since i read jcip, so maybe I should dig that up again as well - has that been updated any in the past years, or can I make due with my old copy ? Liebe Gruesse, Joerg -- Ich lese meine Emails nicht, replies to Email bleiben also leider ungelesen.
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-04 16:22 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjl1r6$g79$1@dont-email.me> |
| In reply to | #23329 |
On 4/4/2013 3:43 PM, Joerg Meier wrote: > On Thu, 04 Apr 2013 10:34:59 -0700, markspace wrote: > > I deleted the rest of your post, as it comes down to this: > >> On 4/4/2013 5:35 AM, Joerg Meier wrote: >>> That memory barrier is the ctor. It alone is enough to make the writes >>> visible. >> No, memory barriers are pretty expensive and the Java compiler doesn't >> force them when not needed. Regular ol' POJO objects don't have a >> memory barrier at the end of their ctor. That's the whole point of >> section 17 in the JLS, Threads and Locks. It tells you how to use your >> normally not-thread-safe objects safely. > > I was under the impression that, well, what I said above was correct. If > it's not, the rest of my argument collapses like a house of cards. Yes, and obviously the same for my argument. I don't think JCIP has changed or been updated. I don't think you have to review the whole thing either, just the section where he talks about making objects immutable. Page 47 is the crux of the matter, I believe.
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2013-04-04 16:49 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <b029593b-574a-4cb6-9246-73292154e995@googlegroups.com> |
| In reply to | #23329 |
Joerg Meier wrote: > markspace wrote: > I deleted the rest of your post, as it comes down to this: >> Joerg Meier wrote: >>> That memory barrier is the ctor. It alone is enough to make the writes >>> visible. > >> No, memory barriers are pretty expensive and the Java compiler doesn't >> force them when not needed. Regular ol' POJO objects don't have a >> memory barrier at the end of their ctor. That's the whole point of >> section 17 in the JLS, Threads and Locks. It tells you how to use your >> normally not-thread-safe objects safely. > > I was under the impression that, well, what I said above was correct. If > it's not, the rest of my argument collapses like a house of cards. I'm > going to have to put in some more research as I'm not just going to take > your word for it, but for now it seems I was wrong. > > Thanks for the links, I will peruse them at a more civilized hour. It's > been a long time since i read jcip, so maybe I should dig that up again as > well - has that been updated any in the past years, or can I make due with > my old copy ? http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.5 "Two actions can be ordered by a happens-before relationship. If one action happens-before another, then the first is visible to and ordered before the second." The only mention of constructors is: "There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (§12.6) for that object." The trick is to do what you need to do before spawning the additional thread(s): "If x and y are actions of the same thread and x comes before y in program order, then hb(x, y)." "A call to start() on a thread happens-before any actions in the started thread." So don't start threads from within a constructor. This follows from the advice not to do anything but construction within a constructor. -- Lew All rules should be broken occasionally, including this one. No rules should ever be broken, except this one.
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-04 18:21 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjl8qp$ll1$1@dont-email.me> |
| In reply to | #23331 |
On 4/4/2013 4:49 PM, Lew wrote: > Joerg Meier wrote: >> markspace wrote: >> I deleted the rest of your post, as it comes down to this: >>> Joerg Meier wrote: >>>> That memory barrier is the ctor. It alone is enough to make the writes >>>> visible. >> >>> No, memory barriers are pretty expensive and the Java compiler doesn't >>> force them when not needed. Regular ol' POJO objects don't have a >>> memory barrier at the end of their ctor. That's the whole point of >>> section 17 in the JLS, Threads and Locks. It tells you how to use your >>> normally not-thread-safe objects safely. >> >> I was under the impression that, well, what I said above was correct. If >> it's not, the rest of my argument collapses like a house of cards. I'm >> going to have to put in some more research as I'm not just going to take >> your word for it, but for now it seems I was wrong. >> >> Thanks for the links, I will peruse them at a more civilized hour. It's >> been a long time since i read jcip, so maybe I should dig that up again as >> well - has that been updated any in the past years, or can I make due with >> my old copy ? > > http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.5 > "Two actions can be ordered by a happens-before relationship. If one action > happens-before another, then the first is visible to and ordered before the second." > > The only mention of constructors is: > "There is a happens-before edge from the end of a constructor of an object to the > start of a finalizer (§12.6) for that object." There's also several mentions in 17.5.1 final Field Semantics: "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." And a few other mentions following that. The "freeze action" is later in that section explained to work like a happens-before relation. "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.) " It's a wee bit complicated to suss out, but I do believe it is saying that final fields are special in that they create happens-before relationships that don't exist for fields that are non-final. That goes for private fields, public fields, etc. Only final fields get this freeze action with the happens-before relationship.
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2013-04-04 18:49 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <c2f41101-1f4e-41c8-99fb-a58b02b2341f@googlegroups.com> |
| In reply to | #23332 |
markspace wrote: > There's also several mentions in 17.5.1 final Field Semantics: > > "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." And a few other mentions following > that. > > The "freeze action" is later in that section explained to work like a > happens-before relation. > > "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.) " > > It's a wee bit complicated to suss out, but I do believe it is saying > that final fields are special in that they create happens-before > relationships that don't exist for fields that are non-final. That goes > for private fields, public fields, etc. Only final fields get this > freeze action with the happens-before relationship. For the purposes of this thread, this is pretty much the capper on the usefulness of 'final' for thread safety. It confirms that 'final' is not just window dressing, and that its semantics are tightly tied to creating thread-safe code. It also confirms that the JLS is incredibly important to correct Java programming. Thanks for citing that. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-04-05 05:30 -0300 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <DYv7t.143445$m21.127300@newsfe02.iad> |
| In reply to | #23334 |
On 04/04/2013 10:49 PM, Lew wrote: > markspace wrote: >> There's also several mentions in 17.5.1 final Field Semantics: >> >> "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." And a few other mentions following >> that. >> >> The "freeze action" is later in that section explained to work like a >> happens-before relation. >> >> "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.) " >> >> It's a wee bit complicated to suss out, but I do believe it is saying >> that final fields are special in that they create happens-before >> relationships that don't exist for fields that are non-final. That goes >> for private fields, public fields, etc. Only final fields get this >> freeze action with the happens-before relationship. > > For the purposes of this thread, this is pretty much the capper on the > usefulness of 'final' for thread safety. > > It confirms that 'final' is not just window dressing, and that its semantics > are tightly tied to creating thread-safe code. > > It also confirms that the JLS is incredibly important to correct Java programming. > > Thanks for citing that. > This thread, and material like the above, also confirms that 99 percent of us, yours truly included, would do best to (1) have a copy of JCIP and regularly read it, and (2) be intimately familiar with the high-level concurrency classes and use those in preference to low-level stuff. I have followed both of these recommendations for years now. I simply do not have the time anymore - have not had it for many years - to stay on top of low-level Java concurrency at an expert level. And my personal belief is that with concurrency you can't just be OK, you need to be very proficient with the tools you choose to use. JCIP and the high-level classes give that large majority of us the ability to master concurrency programming in Java. AHS
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-04-03 20:10 -0400 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <515cc4ef$0$32111$14726298@news.sunsite.dk> |
| In reply to | #23242 |
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
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-03 17:29 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjihd0$cd0$1@dont-email.me> |
| In reply to | #23251 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Joerg Meier <joergmmeier@arcor.de> |
|---|---|
| Date | 2013-04-04 02:53 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <1ofs4l2xcplb1$.16yzf1e13sne1$.dlg@40tude.net> |
| In reply to | #23258 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Jim Janney <jjanney@shell.xmission.com> |
|---|---|
| Date | 2013-04-04 13:51 -0600 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <ydn62025b2g.fsf@shell.xmission.com> |
| In reply to | #23258 |
markspace <markspace@nospam.nospam> writes: > 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. Immutable objects don't need to be defensively copied. This can be useful even in situations where thread safety doesn't apply. -- Jim Janney
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2013-04-06 13:31 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <asafclFg2sjU1@mid.individual.net> |
| In reply to | #23258 |
On 04.04.2013 02:29, 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 think there's too much mixed here. "Thread safety" and
"(im)mutability" are two different concepts. They are orthogonal -
albeit related because the latter can help to achieve the former.
Mutability itself is complex as I have tried to show elsewhere in this
thread. Then again thread safety is a much more complex concept.
First of all, objects which are mutable can be thread safe - it depends
on their implementation. (Jörg pointed that out already).
Then: you wrote "Objects that aren't thread safe aren't immutable". Now
this depends on what we mean by "thread safe". An immutable object's
state is guaranteed to be seen by all threads identical (given proper
coding, which might include the use of "final" fields and creation of an
instance before other threads are started OR handing it over to them in
a thread safe manner w.g. with a blocking queue which memory barriers
through its synchronization).
But: that does not necessarily constitute thread safety. An immutable
object can still be implemented in a thread unsafe manner. For example:
public final class KeyValuePairPrinter {
private final PrintStream out;
public KeyValuePairPrinter(PrintStream out) {
this.out = out;
}
/**
* Print a single line with key "=" value.
* @param key key to print before equals sign
* @param value value to print after equals sign
*/
public void print(Object key, Object value) {
out.print(key);
out.print("=");
out.println(value);
}
}
Now, this class is immutable - but is it thread safe? I'd say no,
because there is no guarantee that key, "=" and value are printed on the
same line in a multithreaded environment.
> 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.
"final" is neither required nor sufficient for immutability AND thread
safety. For example, as long as you ensure there is a memory barrier
between construction and use of an instance final fields are not needed
to ensure other threads see the proper state. Thread safety usually
cannot be ensured by a single class. The typical example is
Collection.synchronizedMap(): if you use the typical pattern "test if a
key is present and if not add it to the Map" without explicit
synchronization the code is not thread safe even though the Map ensures
it's never modified at the same time by two threads and all threads see
all updates from other threads. There are many more examples like that.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-06 10:50 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjpn3l$erv$1@dont-email.me> |
| In reply to | #23345 |
On 4/6/2013 4:31 AM, Robert Klemme wrote:
>
> I think there's too much mixed here. "Thread safety" and
> "(im)mutability" are two different concepts. They are orthogonal -
That's fair. I definitely over-sold the case between thread-safety in
general and immutability in that post you quoted. There's other ways of
achieving thread-safety than immutability. I was going fast and not
thinking thoroughly about what I typed.
But thread-safety and immutability are not orthogonal. Immutable
objects are all thread-safe. I urge you to re-read the section in JCIP
starting on page 46 that talks about immutability. Brain Goetz says
explicitly that immutability in Java requires final fields.
(He then makes an exception to that in a footnote, but I think we're all
quibbling too much over basic terms and understanding final fields to go
looking for sneaky ways around final fields.)
Later, after everybody's on the same page with respect to final fields,
we might talk about ways we don't need them. But I think we have to get
final field semantics down first or the discussion will be a mess.
> First of all, objects which are mutable can be thread safe - it depends
> on their implementation. (Jörg pointed that out already).
Yup, I missed that concept when I made my statement above. Mea culpa.
> But: that does not necessarily constitute thread safety. An immutable
> object can still be implemented in a thread unsafe manner. For example:
Well, there's safety and then there's other concepts related to
concurrency. I think it's best not to lump all concurrency related
discussion under the term "safety". What you showed was more a matter
of atomicity and mutex. So it might be better to use more specific
terms when describing it.
Here's another:
>
> public final class OopsPrinter {
> private final PrintStream out;
> public KeyValuePairPrinter(PrintStream out) {
> this.out = out;
> }
>
> /**
> * Prints to a special PrintStream
> */
> public void print(Object key, Object value) {
PrintStream save = System.out;
System.setOut( this.out );
System.out.printf( "blah blah etc." );
System.setOut( save );
> }
> }
I'd call this "global interference." Any thread calling this method
will set a global variable that affects all threads in the entire
system. It's safe because the JVM handles writes to System.out
specially so they are thread safe, but any other thread using System.out
at the same time as this method is executing will get a surprise. Brian
Goetz calls this "thread hostile."
("Interference" is a technical word used in a lot of literature on
concurrency, which I've run across before. It basically means a race
condition of some sort.)
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-04-04 09:09 +0100 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <aIWdnXVtlZy3qMDMnZ2dnUVZ8judnZ2d@bt.com> |
| In reply to | #23223 |
On 03/04/13 20:01, Joerg Meier wrote:
> On Wed, 03 Apr 2013 19:51:05 +0100, lipska the kat wrote:
>
>> [...] When I see the
>> modifier final it says something to me, it says, this value is not
>> modifiable ('scuse the pun).
>
> Then you need to read a Java beginner tutorial ;)
I read everything I can about Java, beginner or otherwise :)
There's a lot that's been added to this thread since I retired to my bed
last night and I haven't read it all so please excuse me if I'm
repeating what others have said.
one primitive and one reference variable
//x can be assigned once and once only
final int x = 0;
x++;
//ILLEGAL, x cannot be modified as it's final
//list can be assigned once and once only
final List<String> list = new ArrayList<String>();
//OK, the instance is not immutable
list.add("foo");
list = new ArrayList<String>();
//ILLEGAL, list cannot be modified as it's final
This is what I mean by not modifiable, the variables x and list are
not modifiable after assignment however what list points to, sorry
refers to is a mutable instance of ArrayList<String>, this is quite
different.
> "final" makes a variable or field impossible to reassign. It says
> absolutely nothing at all about whether or not that variables is
> modifiable.
I'm not sure I understand
> What you are thinking of is immutability, something that is not
> formalized in Java. In Java, having final mutable fields is perfectly
> legitimate.
Can you give an example?
thanks
lipska
--
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-04-04 05:37 -0300 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <%Ya7t.205181$Nl5.140602@newsfe07.iad> |
| In reply to | #23282 |
On 04/04/2013 05:09 AM, lipska the kat wrote: > On 03/04/13 20:01, Joerg Meier wrote: >> On Wed, 03 Apr 2013 19:51:05 +0100, lipska the kat wrote: [ SNIP ] > >> What you are thinking of is immutability, something that is not >> formalized in Java. In Java, having final mutable fields is perfectly >> legitimate. > > Can you give an example? This is more a matter of incorrect English. An *object* is mutable or immutable, not a field. For variables or fields I'd never use the terms mutable/immutable; I'd prefer simply "final" or "not final" or something similar. What Joerg meant is that if the final field is of a reference type then it is perfectly possible that the object assigned to it is mutable. AHS
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-04-04 06:10 -0300 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <wsb7t.4$yV1.0@newsfe29.iad> |
| In reply to | #23283 |
On 04/04/2013 05:59 AM, Stefan Ram wrote: > Arved Sandstrom <asandstrom2@eastlink.ca> writes: >> This is more a matter of incorrect English. An *object* is mutable or >> immutable, not a field. For variables or fields I'd never use the terms >> mutable/immutable; I'd prefer simply "final" or "not final" or something >> similar. > > JLS7 10.9 gives us: > > »A String object is immutable, that is, its contents > never change, while an array of char has mutable elements.« > > »That is, its contents never change« seems to be a > definition of »immutable«, at least for objects. > > »While an array of char has mutable elements« applies the > term to variables of type char (here, anonymous variables), > so it does not apply to objects only. > > (Obviously, »immutable« is »not mutable«, so that »mutable« > and »immutable« are connected by a negation. Thus, a > definition of one also doubles as a definition of the other.) > I'd call that unfortunate terminology myself, as per the array of char, and I wish the author(s) hadn't done it. An array element *is* the item at a given position in the array, and that may or may not be mutable depending on the type of array. How is a primitive char mutable? I would say that the *array* of char is mutable. AHS
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-04-04 19:40 -0300 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <cjn7t.238400$I12.120290@newsfe16.iad> |
| In reply to | #23286 |
On 04/04/2013 06:20 AM, Stefan Ram wrote: > Arved Sandstrom <asandstrom2@eastlink.ca> writes: >> I would say that the *array* of char is mutable. > > An array of chars is not an array of char values, > but of char variables, each of which is mutable. > That doesn't follow, not for me. We say that something, like an object, is mutable when the contents of it can be changed. Each one of those elements - char variables as per the JLS - points to an immutable thing: how are they mutable? It is the container object - in this case the array - which is mutable. I still stand by my opinion that variables are not what you consider to be mutable or immutable. It's what they point to. AHS
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-04-05 05:44 -0300 |
| Subject | Re: arrays and variables |
| Message-ID | <eaw7t.93$751.11@newsfe01.iad> |
| In reply to | #23328 |
On 04/05/2013 03:09 AM, Stefan Ram wrote: > Arved Sandstrom <asandstrom2@eastlink.ca> writes: >> Each one of those elements - char variables as per the JLS - >> points to an immutable thing > > We do not use »point« for variables of primitve types like > »char«. A variable »has« a value. Who is "we"? And don't get all hung up on my use of the English word "point", I am not implying an equivalence with C pointers here. In fact I am making use of the very meaning that you trot out below, that a variable is a storage location. >> : how are they mutable? > > By an assignment, like »a[ 5 ]= 8«. > You are entirely missing my argument. I know there's an English word "mutable", and I know what it means. My argument is that it would be seriously helpful if it were not used for *changing the value* of a variable. >> It is the container object - in this case the array - which >> is mutable. > > JLS7: »An array object contains a number of variables.«, > »A variable is a storage location«. > Right. Now step back from trotting out JLS quotes and interpret them, and also *hear* what I am trying to say. Anyone can quote anything, doesn't mean they are understanding anything. AHS
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-04-05 14:08 +0100 |
| Subject | Re: arrays and variables |
| Message-ID | <1uednTu2Z5ByUcPMnZ2dnUVZ8i-dnZ2d@bt.com> |
| In reply to | #23337 |
On 05/04/13 09:56, Stefan Ram wrote: > Arved Sandstrom <asandstrom2@eastlink.ca> writes: >> On 04/05/2013 03:09 AM, Stefan Ram wrote: >>> Arved Sandstrom <asandstrom2@eastlink.ca> writes: [snip] > What is C? We have pointers in Java, see the JLS. Do we? I never knew that a pointer in C int x int *iptr; iptr = &x; iptr++; //stupid but not illegal How would I do that in Java using pointers (note the *pointer arithmatic*). You learn something new every day. lipska -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2013-04-05 13:33 -0700 |
| Subject | Re: arrays and variables |
| Message-ID | <78a7719f-3519-48a5-b36d-d8b7ddcafe7c@googlegroups.com> |
| In reply to | #23339 |
lipska the kat wrote: > Stefan Ram wrote: >> Arved Sandstrom writes: >>> Stefan Ram wrote: >>>> Arved Sandstrom writes: > > [snip] > >> What is C? We have pointers in Java, see the JLS. > > Do we? I never knew that It's in the JLS, 4.3.1. "An object is a class instance or an array. "The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object." > a pointer in C > > int x > int *iptr; > iptr = &x; > iptr++; //stupid but not illegal > > How would I do that in Java using pointers (note the *pointer arithmatic*). Java does not have pointer arithmetic. It only has pointers for reference types, so the nearest equivalents are: int x; Integer iptr; iptr = Integer.valueOf(x); // no pointer arithmetic > You learn something new every day. Hopefully. -- Lew
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web