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 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-06 17:19 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjqduh$3m4$1@dont-email.me> |
| In reply to | #23354 |
On 4/6/2013 12:58 PM, Wanja Gayk wrote: > > Mark, I think you have read "Java concurrency in practice", you should > know better. You're right, I should. ;) > > "final" is not necessary to get a thread safe immutable object either, Well, according to Brian Goetz it is. Check the section on immutability (page 47 I think) where he lists the three requirements of immutable objects in Java. "Use final fields" (paraphrased) is the first one. > there is the "volatile" keyword to get the memory model right and there > are synchronized blocks. What are we talking about here anyway? I misspoke. There are certainly other ways to get thread-safety besides immutability or final fields. Mea culpa. > The "final" keyword is very helpful to create a thread safe and > immutable class, but it is neither necessary, nor is its usage giving > you any guarantee of immutability, period. I disagree that it is not necessary; JCIP says that it is. (I realize Brian Goetz takes that statement back in a footnote. However, considering it is a footnote and not the main text I'd like to defer that discussion until a few other folks here get final field semantics more firmly under their belts.) > And before you start arguing about the "final class XY" definition, just > remember visibility contraints and factories. This argment is getting > pretty useless. I'm not sure what that means. I think my main argument in this thread has been the use of final field semantics in creating thread safe immutable objects. Other types of immutability, other types of thread safety, and other uses of 'final' besides fields I think are tangential to that idea. Starting a new thread that is more focused might be a good idea.
[toc] | [prev] | [next] | [standalone]
| From | Wanja Gayk <brixomatic@yahoo.com> |
|---|---|
| Date | 2013-04-07 17:28 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <MPG.2bcbaef42292181b989755@202.177.16.121> |
| In reply to | #23357 |
In article <kjqduh$3m4$1@dont-email.me>, markspace
(markspace@nospam.nospam) says...
> > "final" is not necessary to get a thread safe immutable object either,
>
> Well, according to Brian Goetz it is. Check the section on immutability
> (page 47 I think) where he lists the three requirements of immutable
> objects in Java. "Use final fields" (paraphrased) is the first one.
> [..]
> (I realize Brian Goetz takes that statement back in a footnote.
Which he does because he knows what you know and what I know that this
class...
public class Foo{
private int value;
private Foo(int value){this.value=value;}
public static Foo createFoo(int value){return new Foo(value);}
public int getValue(){return value;}
}
..is both immutable, thread safe and can't be overridden either, without
having a single "final" in it. This is where your whole argument falls
apart.
Kind regards,
-Wanja-
--
..Alesi's problem was that the back of the car was jumping up and down
dangerously - and I can assure you from having been teammate to
Jean Alesi and knowing what kind of cars that he can pull up with,
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-07 09:02 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjs56q$hib$1@dont-email.me> |
| In reply to | #23362 |
On 4/7/2013 8:28 AM, Wanja Gayk wrote:
> public class Foo{
> private int value;
> private Foo(int value){this.value=value;}
> public static Foo createFoo(int value){return new Foo(value);}
> public int getValue(){return value;}
> }
>
> ..is both immutable, thread safe and can't be overridden either, without
No, he doesn't say that, and no, this class isn't thread safe. Normal
POJO classes aren't thread safe. Adding a factory method doesn't help.
In order for this class to be thread safe 'value' would have to be made
visible somehow. You need volatile, a synchronized block, or something
similar. Please read the JLS (and JCIP, again) and note section 17
Threads and Locks. The whole point of that section is that regular
writes aren't thread safe.
If you'd like to point out where you think JCIP or the JLS says that the
above class is thread safe, I'll be happy to show what sections I think
say differently. At worst, one of us will learn something. ;-)
[toc] | [prev] | [next] | [standalone]
| From | Wanja Gayk <brixomatic@yahoo.com> |
|---|---|
| Date | 2013-04-07 19:20 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <MPG.2bcbc92f4f6357aa989758@202.177.16.121> |
| In reply to | #23366 |
In article <kjs56q$hib$1@dont-email.me>, markspace
(markspace@nospam.nospam) says...
>
> On 4/7/2013 8:28 AM, Wanja Gayk wrote:
>
> > public class Foo{
> > private int value;
> > private Foo(int value){this.value=value;}
> > public static Foo createFoo(int value){return new Foo(value);}
> > public int getValue(){return value;}
> > }
> >
> > ..is both immutable, thread safe and can't be overridden either, without
>
> No, he doesn't say that, and no, this class isn't thread safe. Normal
> POJO classes aren't thread safe. Adding a factory method doesn't help.
>
> In order for this class to be thread safe 'value' would have to be made
> visible somehow. You need volatile, a synchronized block, or something
> similar. Please read the JLS (and JCIP, again) and note section 17
> Threads and Locks. The whole point of that section is that regular
> writes aren't thread safe.
You're right in that regard, in rare cases a second thread could see the
"0" default. But you know it's check mate in 1 draw, my friend.
Just watch this:
public class Foo{
private volatile int value;
private Foo(int value){this.value=value;}
public static Foo createFoo(int value){return new Foo(value);}
public int getValue(){return value;}
}
Now that's immutable and thread safe and still there is no "final" used.
Check mate!
Kind regards,
-Wanja-
--
..Alesi's problem was that the back of the car was jumping up and down
dangerously - and I can assure you from having been teammate to
Jean Alesi and knowing what kind of cars that he can pull up with,
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | Wanja Gayk <brixomatic@yahoo.com> |
|---|---|
| Date | 2013-04-07 19:24 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <MPG.2bcbca44d30572b3989759@202.177.16.121> |
| In reply to | #23367 |
In article <MPG.2bcbc92f4f6357aa989758@202.177.16.121>, Wanja Gayk (brixomatic@yahoo.com) says... > But you know it's check mate in 1 draw, my friend. Sorry for my bad engrish, of course it's "1 move". ;-) Kind regards, -Wanja- -- ..Alesi's problem was that the back of the car was jumping up and down dangerously - and I can assure you from having been teammate to Jean Alesi and knowing what kind of cars that he can pull up with, when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer] --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2013-04-03 18:41 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <f3d6284f-0ef8-4167-9fba-089c2ed351ef@googlegroups.com> |
| In reply to | #23266 |
Eric Sosman wrote:
> markspace wrote:
>> 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".
'final' can help in some superficially similar scenarios.
public class MutableImmutable extends Immutable
{
private int foo;
public MutableImmutable(int av)
{
super(av);
foo = av;
}
@Override public int getValue()
{
return foo;
}
public void setValue(int av)
{
foo =av;
}
}
Now you can have code like this:
MutableImmutable mui = new MutableImmutable(0);
Immutable immu = mui;
System.out.println("Immutable value = " + immu.getValue());
mui.setValue(-1);
System.out.println("Immutable value = " + immu.getValue());
If the "mui" and "immu" code are in different parts of the application, e.g., one is
inside a method called separately from the other, you can have mutable behavior
from an 'Immutable' reference even though the parent class is actually immutable.
Furthermore, if 'Immutable#value' were not 'private', then the overriding class can
mutate the behavior of its parent, and break immutability, which is not possible if
the parent class defines 'value' to be 'final'.
So while 'final' is not necessary for immutability, it sure does help.
--
Lew
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2013-04-03 18:31 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <d12cbccd-5c9c-4d20-84ab-ddc74df28a3b@googlegroups.com> |
| In reply to | #23256 |
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
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-03 18:46 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjiltc$6dn$1@dont-email.me> |
| In reply to | #23267 |
On 4/3/2013 6:31 PM, Lew wrote:
> 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.
>
Well, that's true. I'm clearly getting a little sloppy in my language
with all the different posts I've been making.
A final field can be immutable and public if it's a primitive or if the
object it references is immutable. I think that covers it.
> 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.
>
And because String itself is immutable.
public class NotImmutable {
public final char[] string = {'a','b','c'};
}
final, public, initialized by a constant expression, but not immutable.
This is also immutable:
public class ImmutableB {
public final String string = "abc";
}
Can't change it, so it's OK to be public. Thread safe immutable.
(See my post to Eric, what the JLS actually says in section 17.5 is
"thread safe immutable", which is rather different from just
"immutable." I've been confusing the two terms in my posts when I
really should not. What I've really been talking about I should call
"thread safe immutable" to match the JLS.)
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2013-04-03 20:09 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <015f6f5c-b325-4f61-ba8d-62359833a6a5@googlegroups.com> |
| In reply to | #23271 |
On Wednesday, April 3, 2013 6:46:35 PM UTC-7, markspace wrote:
> Lew wrote:
>> 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.
>
> And because String itself is immutable.
I said "and initialized by a constant expression", which is a stronger assertion than immutability.
It encompasses immutability, so the fact that String is immutable is covered by my comment.
> public class NotImmutable {
> public final char[] string = {'a','b','c'};
> }
>
> final, public, initialized by a constant expression, but not immutable.
It is *not* initialized by a constant expression!
I should have given the full term, a "compile-time constant expression" (JLS §15.28):
http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.28
"A compile-time constant expression is an expression denoting a value of primitive type or a String that does not complete abruptly and is composed using only the following: [list of restricted syntax] ..."
The restricted syntax allows only certain expressions involving primitives or 'String's.
An array is neither primitive nor a 'String'.
> This is also immutable:
>
> public class ImmutableB {
> public final String string = "abc";
> }
'string' is also a constant variable.
> Can't change it, so it's OK to be public. Thread safe immutable.
Furthermore, it's a constant variable, so its visibility is different that it would be without 'final'.
Also, simply referencing a static constant variable does not invoke initialization of its containing class.
http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.4.1
> (See my post to Eric, what the JLS actually says in section 17.5 is
> "thread safe immutable [sic]", which is rather different from just
> "immutable." I've been confusing the two terms in my posts when I
> really should not. What I've really been talking about I should call
> "thread safe immutable" to match the JLS.)
All "thread-safe immutable" means is immutable and not seen by another thread until after the
immutability is assured by a memory barrier.
--
Lew
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-03 20:47 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjisve$8k0$1@dont-email.me> |
| In reply to | #23276 |
On 4/3/2013 8:09 PM, Lew wrote: > I should have given the full term, a "compile-time constant > expression" (JLS §15.28): > http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.28 > > "A compile-time constant expression is an expression denoting a > value of primitive type or a String that does not complete abruptly > and is composed using only the following: [list of restricted >syntax] ..." Ah OK, a term a wasn't familiar with. Thanks for the info. > Furthermore, it's a constant variable, so its visibility is different > that it would be without 'final'. Also, simply referencing a static > constant variable does not invoke initialization of its containing > class. > http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.4.1 I think I get this. Constant variables can be initialized at compile time, and so so their visibility is compile time and later. An access to a constant variable wouldn't cause a class to initialize, whereas an access to my public final char[] would cause the whole class to initialize. > All "thread-safe immutable" means is immutable and not seen by > another thread until after the immutability is assured by a memory > barrier. > Yes, but I think it's causing confusion, as Arne and possibly Joerg are assuming that immutable means something more like the plain English meaning of that word, and they're not taking into account the special meaning applied by the JLS. I had to modify my terminology to be more clear.
[toc] | [prev] | [next] | [standalone]
| From | Leif Roar Moldskred <leifm@dimnakorr.com> |
|---|---|
| Date | 2013-04-04 00:42 -0500 |
| Subject | Re: Usefulness of "final" |
| Message-ID | <ud2dncO-I7NXj8DMnZ2dnUVZ7tudnZ2d@giganews.com> |
| In reply to | #23233 |
markspace <markspace@nospam.nospam> wrote:
>
> 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?
>
For what it's worth, they're not:
public class ThisIsImmutable {
private String cantChangeMe;
public ThisIsImmutable(String value) {
this.cantChangeMe = value;
}
public String getCantChangeMe() {
return this.cantChangeMe;
}
}
public class ThisIsNot {
private final Map<String, Integer> positionMap = new HashMap<>();
public void store(String key) {
this.positionMap.put(key, positionMap.size());
}
public Integer position(String key) {
return this.positionMap.get(key);
}
public void clear() {
this.positionMap.clear();
}
}
Now, it's certainly good practice to use "final" to help mark fields
that should not be reassigned, but "final" is neither sufficient nor
necessary to enforce immutability. (And with reflection mixed in the
bag it's not even sufficient to enforce non-reassignability, but
that's another story.)
As for the use of "final" for parameters and local variables, my
personal opinion is that the semantics of "final" are too weak to make
it worth the bother. As Java methods are pass-by-value, variable
reassignment just isn't a real source for problems so why guard
against it?
--
Leif Roar Moldskred
[toc] | [prev] | [next] | [standalone]
| From | paul.cager@gmail.com |
|---|---|
| Date | 2013-04-04 01:55 -0700 |
| Subject | Re: Usefulness of "final" |
| Message-ID | <e6ef07e6-509b-4eb0-8a6a-ebb871e78a8a@googlegroups.com> |
| In reply to | #23280 |
On Thursday, 4 April 2013 06:42:34 UTC+1, Leif Roar Moldskred wrote:
> markspace <markspace@nospam.nospam> wrote:
> >
> > ... Are you trying to tell me that final fields are
> > not involved in immutability in Java?
>
> For what it's worth, they're not:
>
> public class ThisIsImmutable {
> private String cantChangeMe;
> public ThisIsImmutable(String value) {
> this.cantChangeMe = value;
> }
> public String getCantChangeMe() {
> return this.cantChangeMe;
> }
> }
Interestingly, is "ThisIsImmutable" immutable given you can do this?
public class NowItIsnt extends ThisIsImmutable {
public String getCantChangeMe() {
return Integer.toString(new Random().nextInt());
}
}
Of course you could make ThisIsImmutable final.
[toc] | [prev] | [next] | [standalone]
| From | Joerg Meier <joergmmeier@arcor.de> |
|---|---|
| Date | 2013-04-04 14:45 +0200 |
| Subject | Re: Usefulness of "final" |
| Message-ID | <1ro4uey25a76p$.wlyitsuf5ojf.dlg@40tude.net> |
| In reply to | #23284 |
On Thu, 4 Apr 2013 01:55:43 -0700 (PDT), paul.cager@gmail.com wrote:
> Interestingly, is "ThisIsImmutable" immutable given you can do this?
> public class NowItIsnt extends ThisIsImmutable {
> public String getCantChangeMe() {
> return Integer.toString(new Random().nextInt());
> }
> }
> Of course you could make ThisIsImmutable final.
I faced the same question (whether or not to make my example final)
elsethread, but in the end, with Reflection and such, you really aren't
protected against someone trying to intentionally make something mutable.
Between cloning, deserializing, using Reflection to outright remove final
decorations, and the good old brute force method of changing the source
(and you can even override the JCL if you put things in java* packages),
there's a lot of ways to 'break' things if you wanted to.
Writing a super defensive class to protect against all that didn't seem
worth the trouble to make the point we tried to make.
Liebe Gruesse,
Joerg
--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
[toc] | [prev] | [next] | [standalone]
| From | Joerg Meier <joergmmeier@arcor.de> |
|---|---|
| Date | 2013-04-04 00:46 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <1m6qixygl0s9c$.1fv60gxfuhuyz.dlg@40tude.net> |
| In reply to | #23226 |
On Wed, 03 Apr 2013 14:15:56 -0700, markspace wrote:
> 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.
> Well, immutability is formalized in the JLS, and it's pretty important:
> "final fields also allow programmers to implement thread-safe immutable
> objects without synchronization." etc.
> <http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5>
> You might be referring to something else, but what you wrote there is
> kind of misleading, at least.
You display an honestly shocking and disturbing misunderstanding here. I
can only assume that this is some sort of temporary brain fart on your part
or bad communication between us. Making an object reference final does not
make the object immutable, and I have trouble believing you really think so
yourself.
Think about this piece of code:
final Point p = new Point(0, 0);
p.move(1, 1);
Are you really trying to say that you believe that the final keyword has
made p immutable, and that the call to p.move will fail to mut..ate ? p,
and that a subsequent call to p.getX() will return 0 ? Because if yes, then
you are simply wrong, and if no, then p is not immutable.
What the above quote means (and says) is that by USING final in the MAKING
of an object (as in writing a class), you can make an immutable object:
public class A {
final int b = 123;
}
A a = new A(); will now produce an immutable object a.
In fact it is a very popular (if not the most popular) way to deal with
synchronization to simply make as much as you can immutable, as that frees
you of a majority of synchronization concerns and issues.
But of course, again, you cannot make an mutable OBJECT immutable simply by
creating a reference to it that is decorated with final.
Basically, it's an issue about outside or inside: using final inside an
object on its fields can make that object immutable (assuming all state is
covered with finals), but just because you have a final reference to an
object does not change whether the object is modifiable or not.
Again, I'm pretty certain that you already know all of the above and we are
just having a communication breakdown.
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-03 16:10 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjicp7$jeu$1@dont-email.me> |
| In reply to | #23235 |
On 4/3/2013 3:46 PM, Joerg Meier wrote:
> final Point p = new Point(0, 0);
> p.move(1, 1);
>
> Are you really trying to say that you believe that the final keyword has
> made p immutable,
Nope, p is clearly mutable here.
> public class A {
> final int b = 123;
> }
OK, as far as it goes. But see below.
> But of course, again, you cannot make an mutable OBJECT immutable simply by
> creating a reference to it that is decorated with final.
Yup, you can. This class is also immutable:
public class Stooges {
private final ArrayList<String> stooges = new ArrayList<>(3);
{ stooges.add("Larry"); stooges.add("Curly"); stooges.add("Moe");}
public String getStooge( int stooge ) {
if( stooge < 1 || stooge > 3 ) throw new IllegalArgumentException();
return stooges.get( stooge-1 );
}
}
Now as long as I haven't made some syntax or other simple error, all
instances of Stooges are immutable under the section of the JLS I
quoted. More over, each one is thread safe in all circumstances and
does not need synchronization to make it thread safe.
You may know this yourself, but the way you wrote the bit I quoted made
is sound like final fields have no special semantics associated with
them with respect to immutable objects (like the stooges ArrayList I
used above), when in fact they do. Although not in the fashion you
implied with p above, of course.
> Again, I'm pretty certain that you already know all of the above and we are
> just having a communication breakdown.
I think so.
[toc] | [prev] | [next] | [standalone]
| From | Joerg Meier <joergmmeier@arcor.de> |
|---|---|
| Date | 2013-04-04 01:25 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <117qwc9w50mtb.1aizwvzf7bigo.dlg@40tude.net> |
| In reply to | #23238 |
On Wed, 03 Apr 2013 16:10:46 -0700, markspace wrote:
> On 4/3/2013 3:46 PM, Joerg Meier wrote:
>> But of course, again, you cannot make an mutable OBJECT immutable simply by
>> creating a reference to it that is decorated with final.
> Yup, you can. This class is also immutable:
> public class Stooges {
> private final ArrayList<String> stooges = new ArrayList<>(3);
> { stooges.add("Larry"); stooges.add("Curly"); stooges.add("Moe");}
>
> public String getStooge( int stooge ) {
> if( stooge < 1 || stooge > 3 ) throw new IllegalArgumentException();
> return stooges.get( stooge-1 );
> }
> }
But it's immutable because you don't expose mutable functionality, not
because of the final keyword. Let me make a small alteration that will make
your class mutable, without removing the final keyword:
public class Stooges {
private final ArrayList<String> stooges = new ArrayList<>(3);
{ stooges.add("Larry"); stooges.add("Curly"); stooges.add("Moe");}
public String getStooge( int stooge ) {
if( stooge < 1 || stooge > 3 ) throw new IllegalArgumentException();
return stooges.get( stooge-1 );
}
public ArrayList<String> getStooges() {
return stooges;
}
}
There, and suddenly it's mutable.
> Now as long as I haven't made some syntax or other simple error, all
> instances of Stooges are immutable under the section of the JLS I
> quoted. More over, each one is thread safe in all circumstances and
> does not need synchronization to make it thread safe.
Yours would be immutable with or without the final keyword. It's kind of a
bad example, because ArrayList itself is mutable. Should have wrapped it in
Collections.unmodifiableList at least, but of course then it could still
have mutable contents (although of course not in the example, as String is
both immutable and final).
> You may know this yourself, but the way you wrote the bit I quoted made
> is sound like final fields have no special semantics associated with
> them with respect to immutable objects (like the stooges ArrayList I
> used above), when in fact they do. Although not in the fashion you
> implied with p above, of course.
final can be used to create a class that is immutable, but so can other
Java mechanics (such as private fields with no setter). While final
certainly lends itself to design of immutable classes, there really aren't
any special semantics associated with it any more than with the private
keyword.
>> Again, I'm pretty certain that you already know all of the above and we are
>> just having a communication breakdown.
> I think so.
Yeah, I figured halfway into my post that perceived misconception on your
part was too severe for it to actually be one. Nevertheless it seems a
worthwhile topic to discuss and maybe it will help someone else reading it
understand things better.
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-03 16:44 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjieou$uii$1@dont-email.me> |
| In reply to | #23239 |
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. I'll stop there because I think this may be the whole point of misunderstanding here.
[toc] | [prev] | [next] | [standalone]
| From | Joerg Meier <joergmmeier@arcor.de> |
|---|---|
| Date | 2013-04-04 01:57 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <1rb5a1rqvwu96.4bxnq45wdqe8.dlg@40tude.net> |
| In reply to | #23242 |
On Wed, 03 Apr 2013 16:44:45 -0700, 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.
Now I'm to being confused by you. final prevents any writes other than the
initial one. That initial write is not synchronized to other threads. 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 ?
Guess what this will print out:
public class FinalTest {
public static class Test {
public final String bla;
public Test() {
new Thread(new Runnable() {
public void run() {
try {
Thread.sleep(200);
} catch (final InterruptedException e) {}
System.out.println(bla);
try {
Thread.sleep(1000);
} catch (final InterruptedException e) {}
System.out.println(bla);
}
}).start();
try {
Thread.sleep(1000);
} catch (final InterruptedException e) {}
bla = "1234";
}
}
public static void main(final String[] args) {
final Test test = new Test();
}
}
If I misunderstood, and you believe that structural changes to the
ArrayList would be visible to all threads, then you are still wrong, but
you're going to have to write this test case as I restrict myself to one
test case per post ;)
> That's why no synchronization is needed. Which is huge, conceptually.
> I'll stop there because I think this may be the whole point of
> misunderstanding here.
The mere use of final does not remove the need for synchronization. Nor
does the mere lack of it dictate a need. 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.
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-03 17:19 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjigpn$9bd$1@dont-email.me> |
| In reply to | #23246 |
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).
[toc] | [prev] | [next] | [standalone]
| From | Joerg Meier <joergmmeier@arcor.de> |
|---|---|
| Date | 2013-04-04 14:35 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <1w5kdehhtnncm$.1rh63hnqiof0q$.dlg@40tude.net> |
| In reply to | #23254 |
On Wed, 03 Apr 2013 17:19:17 -0700, markspace wrote:
> 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:
I don't read that (or anything relating to threads at all) from that part
of the JLS (other than the mention to the unrelated deref chain).
> 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.
Yes, but that is not a multi-threading concern (and in fact writes are also
made visible when the ctor exits on non-final fields).
>> 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.
So then my second example, which you just admitted is not thread-safe
above, would by your logic still need no synchronization, because it uses
final. I'm sorry, but that just makes no sense.
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.
You can't have it both ways.
>> Nor
>> does the mere lack of it dictate a need.
> No. 'final' is special here.
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.
>> 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.
That memory barrier is the ctor. It alone is enough to make the 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.
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).
> Also, go read Java Concurrency in Practice by Brian Goetz. He covers
> this in some detail (complete with Stooges example).
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.
Liebe Gruesse,
Joerg
--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
[toc] | [prev] | [next] | [standalone]
Page 5 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