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 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | Joerg Meier <joergmmeier@arcor.de> |
|---|---|
| Date | 2013-04-05 00:39 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <1s7ucipok5t6b$.yljvibno13ki.dlg@40tude.net> |
| In reply to | #23303 |
On Thu, 04 Apr 2013 09:52:11 -0700, markspace wrote: > 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). Then we (or you and Lew) don't disagree - we were talking about different things. We were talking about the fact that the internal 'state' of String is not visible to the outside (as in to a calling class), even in multi-threading. Liebe Gruesse, Joerg -- Ich lese meine Emails nicht, replies to Email bleiben also leider ungelesen.
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2013-04-04 19:50 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <as5sqoFfl4tU1@mid.individual.net> |
| In reply to | #23279 |
On 04.04.2013 06:30, markspace wrote: > On 4/3/2013 8:45 PM, Lew wrote: >> markspace wrote: >>> Eric Sosman wrote: >> 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.) The sentence states that you will only get immutability if you use final fields correctly. That does not imply that final fields are necessary to achieve immutability. For at least one definition of "immutable" you can create classes with no setters and getters only returning immutable objects - without ever using the keyword "final". > 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.) Not at all. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2013-04-04 08:27 -0400 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjjreo$jaa$1@dont-email.me> |
| In reply to | #23274 |
On 4/3/2013 10:17 PM, markspace wrote:
> 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.
Ah, this is obviously some strange usage of the word "defined"
that I wasn't previously aware of.
Section 17.5.1 ("Semantics of final fields") contains precisely
zero occurrences of the word "immutable," zero occurrences of the
word "mutable," and zero occurrences of the sequences "immu" and
"mut." It's a pretty odd definition that doesn't point out the
term being defined.
>> 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.
Elsethread you will find demonstrations by various people
that "final" is not necessary for immutability. (Of course,
they're using their own, informal notions of "immutability,"
since the JLS doesn't define one. Perhaps the widely-held
ideas about "immutable" are not those you share.)
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-04 09:47 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjkama$2n7$1@dont-email.me> |
| In reply to | #23294 |
On 4/4/2013 5:27 AM, Eric Sosman wrote: > Perhaps the widely-held > ideas about "immutable" are not those you share.) > Well, if we're all using different definitions of a term, talking about it is pretty tough. Immutability is defined correctly in the JLS, at least for Java. I think it would be most useful to use that term.
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2013-04-04 19:44 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <as5sfoFfdqmU1@mid.individual.net> |
| In reply to | #23302 |
On 04.04.2013 18:47, markspace wrote: > On 4/4/2013 5:27 AM, Eric Sosman wrote: >> Perhaps the widely-held >> ideas about "immutable" are not those you share.) > > Well, if we're all using different definitions of a term, talking about > it is pretty tough. Immutability is defined correctly in the JLS, at > least for Java. I think it would be most useful to use that term. If it was I'd guess the terms "mutable" or "immutable" would surely show up in the index, but they don't - opposed to "final" which has several entries: http://docs.oracle.com/javase/specs/jls/se7/html/jls-0-index.html No, the JLS does not define "immutable" - it just mentions it. Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-04 11:08 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjkfen$8gc$2@dont-email.me> |
| In reply to | #23308 |
On 4/4/2013 10:44 AM, Robert Klemme wrote: > On 04.04.2013 18:47, markspace wrote: >> On 4/4/2013 5:27 AM, Eric Sosman wrote: >>> Perhaps the widely-held >>> ideas about "immutable" are not those you share.) >> >> Well, if we're all using different definitions of a term, talking about >> it is pretty tough. Immutability is defined correctly in the JLS, at >> least for Java. I think it would be most useful to use that term. > > If it was I'd guess the terms "mutable" or "immutable" would surely show > up in the index, but they don't - opposed to "final" which has several > entries: > > http://docs.oracle.com/javase/specs/jls/se7/html/jls-0-index.html > > No, the JLS does not define "immutable" - it just mentions it. OK then, so what definition would this group like to use to describe the kinds of objects the JLS talks about in Section 17.5?
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2013-04-04 22:53 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <as67i6Fi4tgU1@mid.individual.net> |
| In reply to | #23312 |
On 04.04.2013 20:08, markspace wrote: > On 4/4/2013 10:44 AM, Robert Klemme wrote: >> On 04.04.2013 18:47, markspace wrote: >>> On 4/4/2013 5:27 AM, Eric Sosman wrote: >>>> Perhaps the widely-held >>>> ideas about "immutable" are not those you share.) >>> >>> Well, if we're all using different definitions of a term, talking about >>> it is pretty tough. Immutability is defined correctly in the JLS, at >>> least for Java. I think it would be most useful to use that term. >> >> If it was I'd guess the terms "mutable" or "immutable" would surely show >> up in the index, but they don't - opposed to "final" which has several >> entries: >> >> http://docs.oracle.com/javase/specs/jls/se7/html/jls-0-index.html >> >> No, the JLS does not define "immutable" - it just mentions it. > > OK then, so what definition would this group like to use to describe the > kinds of objects the JLS talks about in Section 17.5? I'd go with the heading of that section: "final Field Semantics" - and it's not primarily about "objects" but about "final fields" or put differently: final object references. That section defines semantics of final fields and just mentions "immutable objects" as an example of a concept that may be created by (properly) using final fields. Immutability (or constness) of an object is a tricky concept. There are at least two useful and totally reasonable definitions: 1. State (as in: bit patterns in memory) of a const object never changes. 2. The user of a const object can never observe any state changes; put differently: all methods of a constant object always return the same results for the same inputs. You can also see that from the development C++ took: keyword "mutable" was introduced later to allow state changes of instances declared "const"; this helps implementing lazy initialization and caching schemes. Other than for type 1 constness compiler checks for type 2 constness are significantly more complicated - if they are possible at all: call a function in a method and all bets are off. Without access to the function's source (or at least bytecode in Java) a compiler cannot determine whether type 2 constness is observed in all circumstances. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-04 14:29 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjkr6s$57r$1@dont-email.me> |
| In reply to | #23317 |
On 4/4/2013 1:53 PM, Robert Klemme wrote: > Immutability (or constness) of an object is a tricky concept. There are > at least two useful and totally reasonable definitions: > > 1. State (as in: bit patterns in memory) of a const object never changes. > > 2. The user of a const object can never observe any state changes; put > differently: all methods of a constant object always return the same > results for the same inputs. How about #3: thread-safe immutable? That that might be the same as #2, but I wouldn't be willing to swear it is in all cases. > > You can also see that from the development C++ took: keyword "mutable" I think it's a mistake to conflate Java with other languages.
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2013-04-05 21:54 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <as8og6F4p8dU1@mid.individual.net> |
| In reply to | #23321 |
On 04/04/2013 11:29 PM, markspace wrote: > On 4/4/2013 1:53 PM, Robert Klemme wrote: >> Immutability (or constness) of an object is a tricky concept. There are >> at least two useful and totally reasonable definitions: >> >> 1. State (as in: bit patterns in memory) of a const object never changes. >> >> 2. The user of a const object can never observe any state changes; put >> differently: all methods of a constant object always return the same >> results for the same inputs. >> You can also see that from the development C++ took: keyword "mutable" > > I think it's a mistake to conflate Java with other languages. I didn't conflate anything. I used features of another language to illustrate aspects of the concept constness / immutability. Cheers robert
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-04-04 19:48 +0100 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <ocmdna_whtZwV8DMnZ2dnUVZ8lWdnZ2d@bt.com> |
| In reply to | #23308 |
On 04/04/13 18:44, Robert Klemme wrote: > On 04.04.2013 18:47, markspace wrote: >> On 4/4/2013 5:27 AM, Eric Sosman wrote: >>> Perhaps the widely-held >>> ideas about "immutable" are not those you share.) >> >> Well, if we're all using different definitions of a term, talking about >> it is pretty tough. Immutability is defined correctly in the JLS, at >> least for Java. I think it would be most useful to use that term. > > If it was I'd guess the terms "mutable" or "immutable" would surely show > up in the index, but they don't - opposed to "final" which has several > entries: > > http://docs.oracle.com/javase/specs/jls/se7/html/jls-0-index.html > > No, the JLS does not define "immutable" - it just mentions it. The JLS does not (presumably) define immutable for the same reason it does not define singleton or aardvark or any other implementation vehicle. If there were an immutable modifier in the same way that there is final modifier then it would be a feature of the language but there isn't so it's not. Mutability is an implementation concept in the same way that deque is an implementation concept. the final modifier can be useful when implementing an immutable component but final and immutable are not the same thing at all. A final *variable* is immutable but an immutable component is not necessarily final. There's a brief discussion of immutability here http://docs.oracle.com/javase/tutorial/essential/concurrency/immutable.html But I'm sure others have already pointed this out. I'll get my coat :-) lipska -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-04-03 20:05 -0400 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <515cc3b2$0$32111$14726298@news.sunsite.dk> |
| In reply to | #23245 |
On 4/3/2013 7:56 PM, Arne Vajhøj wrote: > On 4/3/2013 6:41 PM, markspace wrote: >> On 4/3/2013 3:22 PM, Arne Vajhøj wrote: >> >>> The text you quote do not define immutable neither formal nor informal. >>> >>> It refer to the concept. >>> >>> If immutable is defined formally somewhere in the JLS it must be >>> somewhere else. >>> >>> Until we have a ref, then I can't see anything misleading. >> >> >> Are you serious, Arne? > > Very. > >> Did you read the section I linked to? I didn't >> quote the whole thing, it would be immense. I just quoted one line to >> show that the section did talk about immutability, not to definitively >> establish all the ins-and-outs of immutability in the JLS. There's no >> point in me copying what you can read yourself. > > JLS referring to immutability is utterly irrelevant. > > The question is whether JLS defines it. > > Feel free to quote where it defines it. > > Or stop making claims. > >> Honestly I'm shocked at your response and I think you're missing the >> point by a wide margin. Are you trying to tell me that final fields are >> not involved in immutability in Java? > > I was just pointing out that what you quoted from JLS did not > support your claim that JLS had a formal definition of immutability. > > I find it a bit difficult to see why you think that implies > "final fields are not involved in immutability in Java". But now you raise the question, then final is only slightly involved in immutability in Java. If is neither sufficient nor necessary to make them immutable. Bloch recommends using final for immutables to: - express intention - work better with the Java memory model Arne
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-03 17:24 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjih37$b0m$1@dont-email.me> |
| In reply to | #23249 |
On 4/3/2013 5:05 PM, Arne Vajhøj wrote: > But now you raise the question, then final is only slightly > involved in immutability in Java. > > If is neither sufficient nor necessary to make them > immutable. final is necessary. It is not sufficient (you also have to not mutate the object in question after the enclosing object's ctor exits). I'm pretty sure the field must also be explicitly private. (Implicitly might not be enough to satisfy what ever escape analysis the Java compiler does.) > > Bloch recommends using final for immutables to: > - express intention > - work better with the Java memory model Read Java Concurrency in Practice. That's what I'm referring too.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-04-03 20:32 -0400 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <515cca24$0$32109$14726298@news.sunsite.dk> |
| In reply to | #23256 |
On 4/3/2013 8:24 PM, markspace wrote: > On 4/3/2013 5:05 PM, Arne Vajhøj wrote: >> But now you raise the question, then final is only slightly >> involved in immutability in Java. >> >> If is neither sufficient nor necessary to make them >> immutable. > > final is necessary. No. > It is not sufficient (you also have to not mutate > the object in question after the enclosing object's ctor exits). I'm > pretty sure the field must also be explicitly private. (Implicitly > might not be enough to satisfy what ever escape analysis the Java > compiler does.) > >> >> Bloch recommends using final for immutables to: >> - express intention >> - work better with the Java memory model > > Read Java Concurrency in Practice. That's what I'm referring too. My copy page 47 footnote 12 says: "It is technically possible to have an immutable object without all fields being final" Is that missing in your copy? Arne
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-03 18:34 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjil6h$vsm$1@dont-email.me> |
| In reply to | #23261 |
On 4/3/2013 5:32 PM, Arne Vajhøj wrote: > On 4/3/2013 8:24 PM, markspace wrote: >> On 4/3/2013 5:05 PM, Arne Vajhøj wrote: >>> But now you raise the question, then final is only slightly >>> involved in immutability in Java. >>> >>> If is neither sufficient nor necessary to make them >>> immutable. >> >> final is necessary. > > No. > >> It is not sufficient (you also have to not mutate >> the object in question after the enclosing object's ctor exits). I'm >> pretty sure the field must also be explicitly private. (Implicitly >> might not be enough to satisfy what ever escape analysis the Java >> compiler does.) >> >>> >>> Bloch recommends using final for immutables to: >>> - express intention >>> - work better with the Java memory model >> >> Read Java Concurrency in Practice. That's what I'm referring too. > > My copy page 47 footnote 12 says: > > "It is technically possible to have an immutable object without all > fields being final" > > Is that missing in your copy? Right and he goes on to say that String is an example. But String does rely on final fields -- its char array is final -- and its immutability derives directly from that. Brain Goetz also adds "don't try this at home" meaning it's difficult to actually do. He's referring to the idempotentcy [sic?] of its hash code -- but that doesn't work if the char array is not final. I'm just talking about the semantics about final here. I'm trying to not focus on other implication of having a final field. I think the subject is complicated enough with out introducing other ways to make an object thread safe immutable. If you want, I'll agree that there are exceptions, but I have to insist that final is the normal mechanic, and if one doesn't understand final fields one won't understand the bits that Brian Goetz says to "don't try this at home."
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-04-03 21:54 -0400 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <515cdd55$0$32111$14726298@news.sunsite.dk> |
| In reply to | #23268 |
On 4/3/2013 9:34 PM, markspace wrote: > On 4/3/2013 5:32 PM, Arne Vajhøj wrote: >> On 4/3/2013 8:24 PM, markspace wrote: >>> On 4/3/2013 5:05 PM, Arne Vajhøj wrote: >>>> But now you raise the question, then final is only slightly >>>> involved in immutability in Java. >>>> >>>> If is neither sufficient nor necessary to make them >>>> immutable. >>> >>> final is necessary. >> >> No. >> >>> It is not sufficient (you also have to not mutate >>> the object in question after the enclosing object's ctor exits). I'm >>> pretty sure the field must also be explicitly private. (Implicitly >>> might not be enough to satisfy what ever escape analysis the Java >>> compiler does.) >>> >>>> >>>> Bloch recommends using final for immutables to: >>>> - express intention >>>> - work better with the Java memory model >>> >>> Read Java Concurrency in Practice. That's what I'm referring too. >> >> My copy page 47 footnote 12 says: >> >> "It is technically possible to have an immutable object without all >> fields being final" >> >> Is that missing in your copy? > > Right and he goes on to say that String is an example. But String does > rely on final fields -- its char array is final -- and its immutability > derives directly from that. Brain Goetz also adds "don't try this at > home" meaning it's difficult to actually do. He's referring to the > idempotentcy [sic?] of its hash code -- but that doesn't work if the > char array is not final. > > I'm just talking about the semantics about final here. I'm trying to > not focus on other implication of having a final field. I think the > subject is complicated enough with out introducing other ways to make an > object thread safe immutable. If you want, I'll agree that there are > exceptions, but I have to insist that final is the normal mechanic, and > if one doesn't understand final fields one won't understand the bits > that Brian Goetz says to "don't try this at home." "normal mechanic" is not the same as "necessary". Arne
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2013-04-03 21:25 -0400 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjikm5$t9g$1@dont-email.me> |
| In reply to | #23256 |
On 4/3/2013 8:24 PM, markspace wrote:
> On 4/3/2013 5:05 PM, Arne Vajhøj wrote:
>> But now you raise the question, then final is only slightly
>> involved in immutability in Java.
>>
>> If is neither sufficient nor necessary to make them
>> immutable.
>
> final is necessary. [...]
public class Immutable {
private int value;
public Immutable(int value) {
this.value = value;
}
public int getValue() {
return value;
}
}
Claim: Immutable is immutable, despite the lack of "final".
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-03 18:37 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjilbi$vsm$2@dont-email.me> |
| In reply to | #23266 |
On 4/3/2013 6:25 PM, Eric Sosman wrote:
> On 4/3/2013 8:24 PM, markspace wrote:
>> final is necessary. [...]
>
> public class Immutable {
> private int value;
> public Immutable(int value) {
> this.value = value;
> }
> public int getValue() {
> return value;
> }
> }
>
> Claim: Immutable is immutable, despite the lack of "final".
>
Not in the sense of section 17.5 of the JLS, which is what I linked to
above (and also uses the term "thread safe immutable" to describe the
semantics of final fields).
And not in the sense that Brian Goetz uses in JCIP.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-04-03 21:57 -0400 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <515cde06$0$32111$14726298@news.sunsite.dk> |
| In reply to | #23269 |
On 4/3/2013 9:37 PM, markspace wrote:
> On 4/3/2013 6:25 PM, Eric Sosman wrote:
>
>> On 4/3/2013 8:24 PM, markspace wrote:
>>> final is necessary. [...]
>
>>
>> public class Immutable {
>> private int value;
>> public Immutable(int value) {
>> this.value = value;
>> }
>> public int getValue() {
>> return value;
>> }
>> }
>>
>> Claim: Immutable is immutable, despite the lack of "final".
>>
>
> Not in the sense of section 17.5 of the JLS, which is what I linked to
> above (and also uses the term "thread safe immutable" to describe the
> semantics of final fields).
The point of final for thread safeness is well known.
But using the distinct term "thread safe immutable" may
be very beneficial here to explain that this is not just
plain immutable.
Arne
[toc] | [prev] | [next] | [standalone]
| From | markspace <markspace@nospam.nospam> |
|---|---|
| Date | 2013-04-03 19:23 -0700 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <kjio2d$hdt$1@dont-email.me> |
| In reply to | #23273 |
On 4/3/2013 6:57 PM, Arne Vajhøj wrote: > > The point of final for thread safeness is well known. > > But using the distinct term "thread safe immutable" may > be very beneficial here to explain that this is not just > plain immutable. OK, if that's the issue, then mea culpa. But the JLS and Brian Goetz use "immutable" to mean "thread safe immutable." Immutable is being used in a specific, technically defined way, and it's important to keep that in mind when reading Java literature. Does the author mean "just regular immutable" or "thread safe immutable?" With Java, often it's going to be the latter, and I do mean in the sense of the JLS when I use immutable to refer to final field semantics.
[toc] | [prev] | [next] | [standalone]
| From | Wanja Gayk <brixomatic@yahoo.com> |
|---|---|
| Date | 2013-04-06 21:58 +0200 |
| Subject | Re: Usefulness of "final" (Was: Re: Inserting In a List) |
| Message-ID | <MPG.2bca9cc41ffb0f04989750@202.177.16.121> |
| In reply to | #23273 |
In article <515cde06$0$32111$14726298@news.sunsite.dk>, Arne Vajhøj
(arne@vajhoej.dk) says...
>
> On 4/3/2013 9:37 PM, markspace wrote:
> > On 4/3/2013 6:25 PM, Eric Sosman wrote:
> >
> >> On 4/3/2013 8:24 PM, markspace wrote:
> >>> final is necessary. [...]
> >
> >>
> >> public class Immutable {
> >> private int value;
> >> public Immutable(int value) {
> >> this.value = value;
> >> }
> >> public int getValue() {
> >> return value;
> >> }
> >> }
> >>
> >> Claim: Immutable is immutable, despite the lack of "final".
> >>
> >
> > Not in the sense of section 17.5 of the JLS, which is what I linked to
> > above (and also uses the term "thread safe immutable" to describe the
> > semantics of final fields).
>
> The point of final for thread safeness is well known.
Mark, I think you have read "Java concurrency in practice", you should
know better.
"final" is not necessary to get a thread safe immutable object either,
there is the "volatile" keyword to get the memory model right and there
are synchronized blocks. What are we talking about here anyway?
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.
And before you start arguing about the "final class XY" definition, just
remember visibility contraints and factories. This argment is getting
pretty useless.
Kind regadrs,
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]
Page 4 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