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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-04-02 20:08 -0400 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <515b7308$0$32104$14726298@news.sunsite.dk> |
| In reply to | #23188 |
On 4/2/2013 3:06 PM, Robert Klemme wrote: > On 04/02/2013 04:08 PM, lipska the kat wrote: >> Just as a matter of interest what's with all the finals >> >> particularly >> >> for (final File name : folder.listFiles()) >> >> Despite initial appearances this is indeed legal as the >> assignment is made multiple times but from the same statement. >> >> Given that the final keyword is, aside from a flag to the compiler for >> possible optimization, largely documentary, what is the point of making >> name final. > > It helps avoid accidental reassignment. And it helps distinguish > unchanged from changed variables. That is a nice theory. I am a bit skeptic about the real world benefits. In the example provided it would simply never happen. Arne
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-04-03 11:15 +0100 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <XuCdnUHfKZPInMHMnZ2dnUVZ7oudnZ2d@bt.com> |
| In reply to | #23188 |
On 02/04/13 20:06, Robert Klemme wrote:
> On 04/02/2013 04:08 PM, lipska the kat wrote:
>
>> Just as a matter of interest what's with all the finals
>>
>> particularly
>>
>> for (final File name : folder.listFiles())
[snip]
> I believe in using "final" pretty often as it will immediately indicate
> which local variables are constant for a method call and which are
> modified all the time. Plus, with "final" you can easier catch errors
> in control flow:
>
> final String x;
>
> if ( someCondition() ) {
> x = y.toString();
> }
> else {
> if ( someOtherCondition() ) {
> x = "foo";
> }
> // forgot the else branch here
> x = "bar";
> }
>
> System.out.println("We got " + x);
>
> Generally I find "finally" quite useful - apparently significantly more
> useful than you do. :-)
Well I'm not sure that using a storage class to help you write a
conditional statement is 'good programming style' but hey ho, different
strokes for different folks :-)
I know you mean final of course.
finally is the last recourse of the desperate :-)
Anyway, the usability of final depends on your point of view I suppose.
If for some reason I find myself using 'final' all over the place then I
would have to ask myself if my abstraction was coherent. If one has
something, or in fact a number of somethings that need 'protecting' in
this way then surely it is better to wrap them up in a component and
control access by virtue of the public interface of that component.
It's more OO, makes for cleaner code and of course provides opportunity
for the holy grail of OO 're-usability'
lipska
--
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2013-04-03 19:08 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <as360lFri5bU1@mid.individual.net> |
| In reply to | #23216 |
On 03.04.2013 12:15, lipska the kat wrote:
> On 02/04/13 20:06, Robert Klemme wrote:
>> On 04/02/2013 04:08 PM, lipska the kat wrote:
>>
>>> Just as a matter of interest what's with all the finals
>>>
>>> particularly
>>>
>>> for (final File name : folder.listFiles())
>
> [snip]
>
>> I believe in using "final" pretty often as it will immediately indicate
>> which local variables are constant for a method call and which are
>> modified all the time. Plus, with "final" you can easier catch errors
>> in control flow:
>>
>> final String x;
>>
>> if ( someCondition() ) {
>> x = y.toString();
>> }
>> else {
>> if ( someOtherCondition() ) {
>> x = "foo";
>> }
>> // forgot the else branch here
>> x = "bar";
>> }
>>
>> System.out.println("We got " + x);
>>
>> Generally I find "finally" quite useful - apparently significantly more
>> useful than you do. :-)
>
> Well I'm not sure that using a storage class to help you write a
> conditional statement is 'good programming style' but hey ho, different
> strokes for different folks :-)
I am not sure what you mean by that. Can you elaborate? Where's the
storage class in the example above?
> Anyway, the usability of final depends on your point of view I suppose.
We can certainly agree on *that*.
> If for some reason I find myself using 'final' all over the place then I
> would have to ask myself if my abstraction was coherent. If one has
> something, or in fact a number of somethings that need 'protecting' in
> this way then surely it is better to wrap them up in a component and
> control access by virtue of the public interface of that component.
It probably depends. Sometimes you want to hold on to something because
obtaining it is expensive or the accessor might return a changed version
during subsequent calls but you want to be sure to retain a specific
status. In those cases I would not think that wrapping it up
necessarily helps because the data may actually have been wrapped
already. It feels a bit over the top introducing another layer just to
avoid a local variable with "final".
> It's more OO, makes for cleaner code and of course provides opportunity
> for the holy grail of OO 're-usability'
Maybe I could better see (and agree) if you provide a specific example
of what you mean here.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-04-03 19:51 +0100 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <qM6dnfaBydqB58HMnZ2dnUVZ8mmdnZ2d@bt.com> |
| In reply to | #23221 |
On 03/04/13 18:08, Robert Klemme wrote:
> On 03.04.2013 12:15, lipska the kat wrote:
>> On 02/04/13 20:06, Robert Klemme wrote:
>>> On 04/02/2013 04:08 PM, lipska the kat wrote:
>>>
>>>> Just as a matter of interest what's with all the finals
>>>>
>>>> particularly
>>>>
>>>> for (final File name : folder.listFiles())
>>
>> [snip]
>>
>>> I believe in using "final" pretty often as it will immediately indicate
>>> which local variables are constant for a method call and which are
>>> modified all the time. Plus, with "final" you can easier catch errors
>>> in control flow:
>>>
>>> final String x;
>>>
>>> if ( someCondition() ) {
>>> x = y.toString();
>>> }
>>> else {
>>> if ( someOtherCondition() ) {
>>> x = "foo";
>>> }
>>> // forgot the else branch here
>>> x = "bar";
>>> }
>>>
>>> System.out.println("We got " + x);
>>>
>>> Generally I find "finally" quite useful - apparently significantly more
>>> useful than you do. :-)
>>
>> Well I'm not sure that using a storage class to help you write a
>> conditional statement is 'good programming style' but hey ho, different
>> strokes for different folks :-)
> I am not sure what you mean by that. Can you elaborate? Where's the
> storage class in the example above?
final, although it's not is it, at least it's not Java terminology,
apologies, I should have said 'modifier'. I'll restate.
Well I'm not sure that using a modifier to help you write a
conditional statement is 'good programming style'. When I see the
modifier final it says something to me, it says, this value is not
modifiable ('scuse the pun). Is it improving the clarity of your code to
use final for it's side effect, that is the side effect of causing the
compiler to barf because a final variable may already have been
initialized. I'm not sure about that.
>> Anyway, the usability of final depends on your point of view I suppose.
>
> We can certainly agree on *that*.
>
>> If for some reason I find myself using 'final' all over the place then I
>> would have to ask myself if my abstraction was coherent. If one has
>> something, or in fact a number of somethings that need 'protecting' in
>> this way then surely it is better to wrap them up in a component and
>> control access by virtue of the public interface of that component.
>
> It probably depends. Sometimes you want to hold on to something because
> obtaining it is expensive or the accessor might return a changed version
> during subsequent calls but you want to be sure to retain a specific
> status. In those cases I would not think that wrapping it up
> necessarily helps because the data may actually have been wrapped
> already. It feels a bit over the top introducing another layer just to
> avoid a local variable with "final".
For a single local variable I'd probably agree, in fact in general I
would agree but that wasn't my initial point really, in the code that
kicked off this sub thread there was more than one final variable, in
fact there were several in close proximity, I was initially questioning
the clarity of this for a new user. However then I opened my mouth and
put my foot in it and said ...
>> It's more OO, makes for cleaner code and of course provides opportunity
>> for the holy grail of OO 're-usability'
>
> Maybe I could better see (and agree) if you provide a specific example
> of what you mean here.
I think you probably know what I mean and any off the cuff example will
be contrived to the point irrelevance, so, leave it with me and I'll see
if I can come up with a simple self contained example.
lipska
--
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Joerg Meier <joergmmeier@arcor.de> |
|---|---|
| Date | 2013-04-03 21:01 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <m5js4x39je49.wr0biu59drh4.dlg@40tude.net> |
| In reply to | #23222 |
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 ;)
"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. In Java, having final mutable fields is perfectly
legitimate.
I know you know that, of course, I'm just saying, that's not really a
sensible way to look at final imo.
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 14:15 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kji61t$7u6$1@dont-email.me> |
| In reply to | #23223 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-04-03 18:22 -0400 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <515cabb2$0$32111$14726298@news.sunsite.dk> |
| In reply to | #23226 |
On 4/3/2013 5:15 PM, 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. ???? The text you quote do not define immutable neither formal nor informal. It refer to the concept. If immutable is defined formally somewhere in the JLS it must be somewhere else. Until we have a ref, then I can't see anything misleading. Arne
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-03 15:41 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjib26$914$1@dont-email.me> |
| In reply to | #23229 |
On 4/3/2013 3:22 PM, Arne Vajhøj wrote: > The text you quote do not define immutable neither formal nor informal. > > It refer to the concept. > > If immutable is defined formally somewhere in the JLS it must be > somewhere else. > > Until we have a ref, then I can't see anything misleading. Are you serious, Arne? Did you read the section I linked to? I didn't quote the whole thing, it would be immense. I just quoted one line to show that the section did talk about immutability, not to definitively establish all the ins-and-outs of immutability in the JLS. There's no point in me copying what you can read yourself. 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?
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-04-03 19:56 -0400 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <515cc192$0$32109$14726298@news.sunsite.dk> |
| In reply to | #23233 |
On 4/3/2013 6:41 PM, markspace wrote: > On 4/3/2013 3:22 PM, Arne Vajhøj wrote: > >> The text you quote do not define immutable neither formal nor informal. >> >> It refer to the concept. >> >> If immutable is defined formally somewhere in the JLS it must be >> somewhere else. >> >> Until we have a ref, then I can't see anything misleading. > > > Are you serious, Arne? Very. > Did you read the section I linked to? I didn't > quote the whole thing, it would be immense. I just quoted one line to > show that the section did talk about immutability, not to definitively > establish all the ins-and-outs of immutability in the JLS. There's no > point in me copying what you can read yourself. JLS referring to immutability is utterly irrelevant. The question is whether JLS defines it. Feel free to quote where it defines it. Or stop making claims. > Honestly I'm shocked at your response and I think you're missing the > point by a wide margin. Are you trying to tell me that final fields are > not involved in immutability in Java? I was just pointing out that what you quoted from JLS did not support your claim that JLS had a formal definition of immutability. I find it a bit difficult to see why you think that implies "final fields are not involved in immutability in Java". Arne
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-03 16:58 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjifih$2c4$1@dont-email.me> |
| In reply to | #23245 |
On 4/3/2013 4:56 PM, Arne Vajhøj wrote: > > I was just pointing out that what you quoted from JLS did not > support your claim that JLS had a formal definition of immutability. > But I don't care if you believe. The link is for your sake. > I find it a bit difficult to see why you think that implies > "final fields are not involved in immutability in Java". Er, I'm saying the opposite.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-04-03 20:08 -0400 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <515cc46b$0$32111$14726298@news.sunsite.dk> |
| In reply to | #23247 |
On 4/3/2013 7:58 PM, markspace wrote: > On 4/3/2013 4:56 PM, Arne Vajhøj wrote: >> I was just pointing out that what you quoted from JLS did not >> support your claim that JLS had a formal definition of immutability. > > But I don't care if you believe. The link is for your sake. So it is there but you just don't want to provide the quote yourself. Do you think that sounds credible? >> I find it a bit difficult to see why you think that implies >> "final fields are not involved in immutability in Java". > > Er, I'm saying the opposite. Yes. But you you seemed to imply that I meant it based on the JLS thing. Arne
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-03 17:21 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjigtg$9bd$2@dont-email.me> |
| In reply to | #23250 |
On 4/3/2013 5:08 PM, Arne Vajhøj wrote: > Yes. But you you seemed to imply that I meant it based > on the JLS thing. No, I was replying to Joerg.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-04-03 20:27 -0400 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <515cc8e5$0$32109$14726298@news.sunsite.dk> |
| In reply to | #23255 |
On 4/3/2013 8:21 PM, markspace wrote: > On 4/3/2013 5:08 PM, Arne Vajhøj wrote: > >> Yes. But you you seemed to imply that I meant it based >> on the JLS thing. > > No, I was replying to Joerg. Hmm. You replied to a post by me and only quoted me. A bit difficult to guess that you were actually replying to Joerg. Arne
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-03 17:34 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjihmr$e2n$1@dont-email.me> |
| In reply to | #23257 |
On 4/3/2013 5:27 PM, Arne Vajhøj wrote: > On 4/3/2013 8:21 PM, markspace wrote: >> On 4/3/2013 5:08 PM, Arne Vajhøj wrote: >> >>> Yes. But you you seemed to imply that I meant it based >>> on the JLS thing. >> >> No, I was replying to Joerg. > > Hmm. > > You replied to a post by me and only quoted me. The first post I made was to Joerg: On 4/3/2013 12:01 PM, Joerg Meier wrote: > "final" makes a variable or field impossible to reassign. It says > absolutely nothing at all about whether or not that variables is > modifiable. What you are thinking of is immutability, something that is not > formalized in Java. Then you replied to me, saying that the section of the JLS I linked to "17.5 Final Field Semantics" doesn't define immutability in Java formally or informally. Which is wrong, if you just scan that section for uses of the word "immutable." So that's where I kind of lost it.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2013-04-03 21:20 -0400 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjikcd$rqd$1@dont-email.me> |
| In reply to | #23259 |
On 4/3/2013 8:34 PM, markspace wrote:
> On 4/3/2013 5:27 PM, Arne Vajhøj wrote:
>> On 4/3/2013 8:21 PM, markspace wrote:
>>> On 4/3/2013 5:08 PM, Arne Vajhøj wrote:
>>>
>>>> Yes. But you you seemed to imply that I meant it based
>>>> on the JLS thing.
>>>
>>> No, I was replying to Joerg.
>>
>> Hmm.
>>
>> You replied to a post by me and only quoted me.
>
> The first post I made was to Joerg:
>
> On 4/3/2013 12:01 PM, Joerg Meier wrote:
>
> > "final" makes a variable or field impossible to reassign. It says
> > absolutely nothing at all about whether or not that variables is
> > modifiable. What you are thinking of is immutability, something that
> is not
> > formalized in Java.
>
>
> Then you replied to me, saying that the section of the JLS I linked to
> "17.5 Final Field Semantics" doesn't define immutability in Java
> formally or informally. Which is wrong, if you just scan that section
> for uses of the word "immutable." So that's where I kind of lost it.
I'm with Arne. The cited section uses the word "immutable"
and "immutability" without defining either. All it says is that
"final" can be an aid to implementing immutable objects -- but it
never says what "immutable" is. It doesn't even say that "final"
confers immutability; on the contrary, it says "final fields must
be *used correctly* [emphasis mine] to provide a guarantee of
immutability."
Toward the end of the section, we're told that String is
"perceived as truly immutable." So now there are two more notions:
"truly immutable" as opposed to merely "immutable," and "perceived
as truly immutable" as opposed to "actually truly immutable, not
dependent on somebody's perception." Where does the JLS define how
these three different kinds of immutability differ? Where does it
*define* even one of them?
Thought experiment: Using the JLS' definition of immutability,
support or refute "java.lang.String is mutable, because it computes
its hashCode() lazily and caches it in a non-final field, thereby
changing the String object's state at the first hashCode() call."
Thought experiment: Using the JLS' definition of immutability,
support or refute "All Java objects are mutable, because all have a
monitor whose state changes every time a synchronized block is
entered or exited. The monitor's state affects the behavior of
all threads attempting to synchronize on the object, so the change
of state is not strictly internal but is visible to all observers."
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-03 19:17 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjino8$frr$1@dont-email.me> |
| In reply to | #23265 |
On 4/3/2013 6:20 PM, Eric Sosman wrote: > I'm with Arne. The cited section uses the word "immutable" > and "immutability" without defining either. All it says is that > "final" can be an aid to implementing immutable objects -- but it > never says what "immutable" is. Well, it does. Section 17.5 has several subsections, and it's defined in section 17.5.1. I feel one really should read all of 17.5 to understand final fields however. > It doesn't even say that "final" > confers immutability; on the contrary, it says "final fields must > be *used correctly* [emphasis mine] to provide a guarantee of > immutability." OK, that might be part of the problem. final is necessary but not sufficient. I'll concede that, no problem. I misspoke if I implied otherwise. > > Toward the end of the section, we're told that String is > "perceived as truly immutable." So now there are two more notions: > "truly immutable" as opposed to merely "immutable," and "perceived > as truly immutable" as opposed to "actually truly immutable, not > dependent on somebody's perception." Where does the JLS define how > these three different kinds of immutability differ? Where does it > *define* even one of them? That's a bit of an issue. I think they're just using 'perceived' to mean visible. There's a happens-before relationship between the end of the ctor and all other threads in the system. So String is perceived as immutable by all threads because its fields are visible. I think immutable is defined in section 17.5.1, with their "hb(w, f), hb(f, a), mc(a, r1), and dereferences(r1, r2)" stuff. That section is as I say clear as mud, and I'm relying on Brian Goetz in JCIP to interpret that mess correctly for me. > > Thought experiment: Using the JLS' definition of immutability, > support or refute "java.lang.String is mutable, because it computes > its hashCode() lazily and caches it in a non-final field, thereby > changing the String object's state at the first hashCode() call." But all threads will see the String's internal char[] to have the same values, because it's safely published through a final field. So all threads will calculate the same hash code. This isn't really "thread safe," except that it is because being idempotent counts. Threads can never seen any value for the internally stored hash code except 0 or the correctly computed value. > > Thought experiment: Using the JLS' definition of immutability, > support or refute "All Java objects are mutable, because all have a > monitor whose state changes every time a synchronized block is > entered or exited. The monitor's state affects the behavior of > all threads attempting to synchronize on the object, so the change > of state is not strictly internal but is visible to all observers." > Refutation: Only objects with proper final field semantics are immutable under the JLS's definition. Only those objects are thread safe even without accessing/invoking their monitor; this latter condition was specified in that short sentence I quoted at the start of this whole discussion. "final fields also allow programmers to implement thread-safe immutable objects without synchronization." "Without synchronization" is the whole point of the way Java defines immutability.
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2013-04-03 20:45 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <7fdeb9cc-d961-44b1-abfd-5ffb03715058@googlegroups.com> |
| In reply to | #23274 |
markspace wrote:
> Eric Sosman wrote:
>> I'm with Arne. The cited section uses the word "immutable"
>> and "immutability" without defining either. All it says is that
>> "final" can be an aid to implementing immutable objects -- but it
>> never says what "immutable" is.
>
> Well, it does. Section 17.5 has several subsections, and it's defined
> in section 17.5.1. I feel one really should read all of 17.5 to
> understand final fields however.
Section 17.5.1 never mentions the word "immutable" at all.
http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5.1
Section 17.5, however, does define "thread-safe immutable":
" A thread-safe immutable object is seen as immutable by all threads, even if a data race is used to pass references to the immutable object between threads."
The word "immutable" is apparently to be understood in its common computer-science meaning.
[snip]
> I think immutable is defined in section 17.5.1, with their "hb(w, f),
> hb(f, a), mc(a, r1), and dereferences(r1, r2)" stuff. That section is
> as I say clear as mud, and I'm relying on Brian Goetz in JCIP to
> interpret that mess correctly for me.
That section does not address immutability, but finality.
It says that the value of a reference will not be seen to change if the conditions pertain,
but says nothing about the state of the object referenced.
>> Thought experiment: Using the JLS' definition of immutability,
There isn't one.
>> support or refute "java.lang.String is mutable, because it computes
>> its hashCode() lazily and caches it in a non-final field, thereby
>> changing the String object's state at the first hashCode() call."
Clearly they use "immutable" to refer to observable ("perceived") state.
Any two calls to a fully-constructed 'String' instance's 'hashCode()' will be perceived
to have the same value, and thus is immutable to conventional observation.
> But all threads will see the String's internal char[] to have the same
> values, because it's safely published through a final field. So all
> threads will calculate the same hash code. This isn't really "thread
> safe," except that it is because being idempotent counts. Threads can
Yes, it is really thread safe, assuming you wait for the ctor to complete.
> never seen any value for the internally stored hash code except 0 or the
> correctly computed value.
And if you follow the rules of thread-safe immutability, and I don't know how you would
dodge them for 'String', threads will never see 0.
--
Lew
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-03 21:30 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjivg9$jod$1@dont-email.me> |
| In reply to | #23277 |
On 4/3/2013 8:45 PM, Lew wrote: > markspace wrote: >> Eric Sosman wrote: >>> I'm with Arne. The cited section uses the word "immutable" and >>> "immutability" without defining either. All it says is that >>> "final" can be an aid to implementing immutable objects -- but >>> it never says what "immutable" is. >> >> Well, it does. Section 17.5 has several subsections, and it's >> defined in section 17.5.1. I feel one really should read all of >> 17.5 to understand final fields however. > > Section 17.5.1 never mentions the word "immutable" at all. > http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5.1 Huh, so it doesn't. OK, it just defines the semantics of final fields then. > > Section 17.5, however, does define "thread-safe immutable": ... > The word "immutable" is apparently to be understood in its common > computer-science meaning. Section 17.5 says this in its second paragraph: "final fields must be used correctly to provide a guarantee of immutability." That's the last sentence. To me that's ascribing special semantics to just the word 'immutable.' If it's saying "final fields must be used" then it's special for final fields. I realize there a qualifier on that, but the qualifier is "correctly" and they're just pointing out it's a little tricky. final fields must be used is the key point. (Used incorrectly, of course, they won't guarantee immutability.) I see how you might read that differently, but without final fields the number of useful immutable classes is pretty small. (I'm ignoring stateless objects here.) > > And if you follow the rules of thread-safe immutability, and I don't > know how you would dodge them for 'String', threads will never see > 0. ??? The first thread to calculate a hash code will always see 0. That's what triggers the hash code calculation, rather than just returning the value stored in the hash code field.
[toc] | [prev] | [next] | [standalone]
| From | Joerg Meier <joergmmeier@arcor.de> |
|---|---|
| Date | 2013-04-04 14:34 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <1aowbgw7nmsgh.mo85f0tfnrxc.dlg@40tude.net> |
| In reply to | #23279 |
On Wed, 03 Apr 2013 21:30:16 -0700, markspace wrote: > On 4/3/2013 8:45 PM, Lew wrote: >> The word "immutable" is apparently to be understood in its common >> computer-science meaning. > Section 17.5 says this in its second paragraph: > "final fields must be used correctly to provide a guarantee of > immutability." I would argue that to mean "If you use final incorrectly, you might still not have an immutable object" and not "You can only make immutable objects with use of final". >> And if you follow the rules of thread-safe immutability, and I don't >> know how you would dodge them for 'String', threads will never see >> 0. > ??? The first thread to calculate a hash code will always see 0. > That's what triggers the hash code calculation, rather than just > returning the value stored in the hash code field. How would that thread see 0 ? When I use String.hashCode for the first time, I get the hashCode, not 0. The 0 is only ever used internally. Nobody gets to see it. That's why String is considered immutable. 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 09:52 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjkava$6ul$1@dont-email.me> |
| In reply to | #23295 |
On 4/4/2013 5:34 AM, Joerg Meier wrote: > How would that thread see 0 ? When I use String.hashCode for the first > time, I get the hashCode, not 0. The 0 is only ever used internally. That's what I mean though. Internally, your thread sees 0, and then calculates the value and caches it. There's nothing magic about crossing a method boundary. It's all just a stream of machine instructions to your thread. Visibility of fields (as section 17.4 of the JLS uses that term) isn't affect by methods or objects unless you do something explicitly (like use the synchronized keyword).
[toc] | [prev] | [next] | [standalone]
Page 3 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