Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #7405 > unrolled thread
| Started by | Eric Sosman <esosman@ieee-dot-org.invalid> |
|---|---|
| First post | 2011-08-26 20:56 -0400 |
| Last post | 2011-08-31 00:31 +0200 |
| Articles | 20 on this page of 182 — 33 participants |
Back to article view | Back to comp.lang.java.programmer
Style Police (a rant) Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-08-26 20:56 -0400
Re: Style Police (a rant) Robert Klemme <shortcutter@googlemail.com> - 2011-08-27 09:58 +0200
Re: Style Police (a rant) Rajiv Gupta <rajiv@invalid.com> - 2011-08-27 18:02 +1000
Re: Style Police (a rant) v_borchert@despammed.com (Volker Borchert) - 2011-08-27 08:40 +0000
Re: Style Police (a rant) Jan Burse <janburse@fastmail.fm> - 2011-08-27 13:27 +0200
Re: Style Police (a rant) Jan Burse <janburse@fastmail.fm> - 2011-08-27 13:33 +0200
Re: Style Police (a rant) Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-08-27 11:08 -0400
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-08-27 08:34 -0700
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-08-27 08:37 -0700
Re: Style Police (a rant) Jan Burse <janburse@fastmail.fm> - 2011-08-27 17:59 +0200
Re: Style Police (a rant) Jan Burse <janburse@fastmail.fm> - 2011-08-27 18:06 +0200
Re: Style Police (a rant) Jan Burse <janburse@fastmail.fm> - 2011-08-27 18:08 +0200
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-08-27 09:50 -0700
Re: Style Police (a rant) Jan Burse <janburse@fastmail.fm> - 2011-08-27 19:15 +0200
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-08-27 13:09 -0700
Re: Style Police (a rant) Jan Burse <janburse@fastmail.fm> - 2011-08-27 23:18 +0200
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-08-27 16:10 -0700
Re: Style Police (a rant) Jan Burse <janburse@fastmail.fm> - 2011-08-28 01:59 +0200
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-08-27 18:59 -0700
Re: Style Police (a rant) Jan Burse <janburse@fastmail.fm> - 2011-08-28 15:32 +0200
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-08-28 13:09 -0700
Re: Style Police (a rant) Jan Burse <janburse@fastmail.fm> - 2011-08-29 04:02 +0200
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-08-28 19:20 -0700
Re: Style Police (a rant) Jan Burse <janburse@fastmail.fm> - 2011-08-29 09:44 +0200
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-08-29 08:30 -0700
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-29 16:37 +0000
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-08-29 12:10 -0700
Re: Style Police (a rant) Robert Klemme <shortcutter@googlemail.com> - 2011-08-29 18:21 +0200
Re: Style Police (a rant) Jan Burse <janburse@fastmail.fm> - 2011-08-29 04:06 +0200
Re: Style Police (a rant) Wanja Gayk <brixomatic@yahoo.com> - 2011-09-10 06:45 +0200
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-10 11:40 +0000
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-09-10 14:06 -0700
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-11 14:07 +0000
Re: Style Police (a rant) Arne Vajhøj <arne@vajhoej.dk> - 2011-09-11 10:55 -0400
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-11 23:34 +0000
Re: Style Police (a rant) Arne Vajhøj <arne@vajhoej.dk> - 2011-09-11 10:58 -0400
Re: Style Police (a rant) Patricia Shanahan <pats@acm.org> - 2011-09-11 10:12 -0700
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-14 12:22 +0000
Re: Style Police (a rant) Bent C Dalager <bcd@pvv.ntnu.no> - 2011-09-14 15:04 +0000
Re: Style Police (a rant) Paul Cager <paul.cager@googlemail.com> - 2011-09-14 09:36 -0700
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-09-11 09:47 -0700
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-11 23:32 +0000
Re: Style Police (a rant) Wanja Gayk <brixomatic@yahoo.com> - 2011-09-17 00:57 +0200
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-17 19:56 +0000
Re: Style Police (a rant) Wanja Gayk <brixomatic@yahoo.com> - 2011-09-11 21:20 +0200
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-09-11 17:11 -0400
Re: Style Police (a rant) Wanja Gayk <brixomatic@yahoo.com> - 2011-09-12 01:22 +0200
Re: Style Police (a rant) Arne Vajhøj <arne@vajhoej.dk> - 2011-09-11 21:13 -0400
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-09-11 16:54 -0700
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-09-11 23:42 -0400
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-09-12 21:54 -0700
Re: Style Police (a rant) "Cthun" <cthun_117@qmail.net.au> - 2011-09-13 07:18 -0400
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-09-13 10:07 -0400
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-09-13 08:15 -0700
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-09-13 12:00 -0400
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-09-13 10:10 -0400
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-09-13 09:55 -0700
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-09-15 10:37 -0400
Re: Style Police (a rant) "Cthun" <cthun_9112011@qmail.net.au> - 2011-09-15 22:58 -0400
Murphy = Troll [DO NOT FEED] thoolen <th00len@th0lenbot.thorium> - 2011-09-16 00:23 -0400
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-09-16 03:26 -0700
Re: Style Police (a rant) un-Bent <dob@dib.dib.null> - 2011-09-16 13:02 +0000
Murphy = Troll [DO NOT FEED] thoolen <th00len@th0lenbot.thorium> - 2011-09-16 22:40 -0400
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-09-17 19:36 -0400
Re: Style Police (a rant) "kaffel'latte" <jiggingjava@qmail.net> - 2011-09-19 08:58 -0400
Re: Style Police (a rant) thoolen <th00len@th0lenbot.thorium> - 2011-09-19 11:56 -0400
Re: Style Police (a rant) "kaffel'latte" <jiggingjava@qmail.net> - 2011-09-19 17:05 -0400
Re: Style Police (a rant) thoolen <th00len@th0lenbot.thorium> - 2011-09-19 19:13 -0400
Re: Style Police (a rant) k00k Derbyshire spins freely "kaffel'latte" <jiggingjava@qmail.net> - 2011-09-19 20:45 -0400
Re: Style Police (a rant) k00k Derbyshire spins freely thoolen <th00len@th0lenbot.thorium> - 2011-09-21 18:37 -0400
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-09-26 15:13 -0700
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-09-26 19:34 -0400
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-10-01 06:49 -0700
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-10-01 09:21 -0700
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-10-01 14:17 -0400
Re: Style Police (a rant) Wanja Gayk <brixomatic@yahoo.com> - 2011-10-01 20:53 +0200
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-10-01 21:12 -0400
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-10-05 06:17 -0700
Re: Style Police (a rant) "Cthun" <cthun_117@qmail.net.au> - 2011-09-12 04:56 -0400
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-09-12 05:12 -0400
Re: Style Police (a rant) "Cthun" <cthun_117@qmail.net.au> - 2011-09-12 04:59 -0400
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-09-12 05:13 -0400
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-11 23:17 +0000
Re: Style Police (a rant) Arne Vajhøj <arne@vajhoej.dk> - 2011-09-11 21:12 -0400
Re: Style Police (a rant) Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-09-12 07:36 -0300
Re: Style Police (a rant) "Cthun" <cthun_117@qmail.net.au> - 2011-09-12 04:58 -0400
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-09-12 05:12 -0400
Re: Style Police (a rant) Wanja Gayk <brixomatic@yahoo.com> - 2011-09-11 15:33 +0200
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-09-11 09:42 -0700
Re: Style Police (a rant) Lars Enderin <lars.enderin@telia.com> - 2011-09-11 20:35 +0200
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-09-11 16:55 -0700
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-09-11 20:36 -0700
Re: Style Police (a rant) Lars Enderin <lars.enderin@telia.com> - 2011-09-12 10:05 +0200
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-09-12 15:35 -0700
Re: Style Police (a rant) Lars Enderin <lars.enderin@telia.com> - 2011-09-13 10:35 +0200
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-09-13 09:48 -0700
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-09-13 12:18 -0700
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-09-13 17:30 -0700
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-09-12 21:59 -0700
Re: Style Police (a rant) Joe Attardi <jattardi@gmail.com> - 2011-09-23 10:54 -0700
Re: Style Police (a rant) thoolen <th00len@th0lenbot.thorium> - 2011-09-24 01:54 -0400
Re: Style Police (a rant) "tholen@antispam.ham" <tholen@ifa.hawaii.edu> - 2011-09-24 02:58 -0700
Re: Style Police (a rant) thoolen <th00len@th0lenbot.thorium> - 2011-09-24 11:35 -0400
Re: Style Police (a rant) Joe Attardi <jattardi@gmail.com> - 2011-09-26 13:50 -0700
Re: Style Police (a rant) Jane Doe <jdoe@love.in.d.jungle.invalid> - 2011-09-26 21:14 +0000
Re: Style Police (a rant) thoolen <th00len@th0lenbot.thorium> - 2011-09-26 17:50 -0400
Re: Style Police (a rant) "tholen@antispam.ham" <tholen@ifa.hawaii.edu> - 2011-11-04 15:56 -0700
Re: Style Police (a rant) thoolen <th00len@th0lenbot.thorium> - 2011-11-07 12:04 -0500
Re: Style Police (a rant) "tholen@antispam.ham" <tholen@ifa.hawaii.edu> - 2011-11-10 15:22 -0800
Re: Style Police (a rant) thoolen <th00len@th0lenbot.thorium> - 2011-09-26 17:47 -0400
Re: Style Police (a rant) "tholen@antispam.ham" <tholen@ifa.hawaii.edu> - 2011-11-04 15:48 -0700
Re: Style Police (a rant) dizzy <dizzy@nospam.invalid> - 2011-11-05 07:58 -0500
Re: Style Police (a rant) "tholen@antispam.ham" <tholen@ifa.hawaii.edu> - 2011-11-10 15:17 -0800
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-09-26 15:17 -0700
Re: Style Police (a rant) Jane Doe <jdoe@love.in.d.jungle.invalid> - 2011-09-27 00:50 +0000
Re: Style Police (a rant) tisue@cs.nwu.edu (Seth Tisue) - 2011-09-27 08:55 -0600
Re: Style Police (a rant) thoolen <th00len@th0lenbot.thorium> - 2011-09-27 14:14 -0400
Re: Style Police (a rant) thoolen <th00len@th0lenbot.thorium> - 2011-09-27 14:11 -0400
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-10-01 07:31 -0700
Re: Style Police (a rant) thoolen <th00len@th0lenbot.thorium> - 2011-09-26 22:24 -0400
Re: Style Police (a rant) Jane Doe <jdoe@love.in.d.jungle.invalid> - 2011-09-27 09:30 +0000
Re: Style Police (a rant) tisue@cs.nwu.edu (Seth Tisue) - 2011-09-27 08:57 -0600
Re: Style Police (a rant) thoolen <th00len@th0lenbot.thorium> - 2011-09-27 14:38 -0400
Re: Style Police (a rant) thoolen <th00len@th0lenbot.thorium> - 2011-09-27 14:36 -0400
Re: Style Police (a rant) Kaz Kylheku <kaz@kylheku.com> - 2011-09-30 15:58 +0000
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-10-01 07:32 -0700
Re: Style Police (a rant) Arne Vajhøj <arne@vajhoej.dk> - 2011-09-30 21:26 -0400
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-10-01 07:34 -0700
Re: Style Police (a rant) Arne Vajhøj <arne@vajhoej.dk> - 2011-10-01 15:51 -0400
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-10-05 06:18 -0700
Re: Style Police (a rant) "Cthun" <cthun_117@qmail.net.au> - 2011-10-01 16:26 -0400
Re: Style Police (a rant) thoolen <th00len@th0lenbot.thorium> - 2011-10-01 21:25 -0400
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-10-05 06:23 -0700
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-10-05 10:01 -0400
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-10-07 08:29 -0700
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-10-07 17:34 -0400
Re: Style Police (a rant) Retahiv Oopsiscame <roopsisc@gmail.com> - 2011-09-12 21:58 -0700
Re: Style Police (a rant) "Cthun" <cthun_117@qmail.net.au> - 2011-09-12 04:52 -0400
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-09-12 05:14 -0400
Re: Style Police (a rant) "Cthun" <cthun_117@qmail.net.au> - 2011-09-12 06:42 -0400
Re: Style Police (a rant) Cthun <cthun_117@qmail.net.au> - 2011-09-12 07:20 -0400
Re: Style Police (a rant) "Cthun" <cthun_117@qmail.net.au> - 2011-09-12 08:46 -0400
Re: Style Police (a rant) thoolen <th00len@th0lenbot.thorium> - 2011-09-12 21:03 -0400
Re: Style Police (a rant) Tom Anderson <twic@urchin.earth.li> - 2011-09-12 20:18 +0100
Re: Style Police (a rant) Wanja Gayk <brixomatic@yahoo.com> - 2011-09-11 21:20 +0200
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-09-11 13:52 -0700
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-12 00:17 +0000
Re: Style Police (a rant) Arne Vajhøj <arne@vajhoej.dk> - 2011-09-10 21:32 -0400
Re: Style Police (a rant) Wanja Gayk <brixomatic@yahoo.com> - 2011-09-11 13:27 +0200
Re: Style Police (a rant) Arne Vajhøj <arne@vajhoej.dk> - 2011-09-11 11:05 -0400
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-11 13:23 +0000
Re: Style Police (a rant) Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-11 10:04 -0400
Re: Style Police (a rant) Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-09-11 12:45 -0300
Re: Style Police (a rant) Arne Vajhøj <arne@vajhoej.dk> - 2011-09-11 16:53 -0400
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-14 12:30 +0000
Re: Style Police (a rant) Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-14 20:47 -0400
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-09-14 18:06 -0700
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-15 10:06 +0000
Re: Style Police (a rant) blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-09-20 11:28 +0000
Re: Style Police (a rant) Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-20 07:36 -0400
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-20 13:04 +0000
Re: Style Police (a rant) Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-09-20 20:34 -0300
Re: Style Police (a rant) Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-09-14 22:33 -0300
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-15 13:46 +0000
Re: Style Police (a rant) Arne Vajhøj <arne@vajhoej.dk> - 2011-09-14 21:40 -0400
Re: Style Police (a rant) Arne Vajhøj <arne@vajhoej.dk> - 2011-09-11 10:59 -0400
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-11 21:25 +0000
Re: Style Police (a rant) Tom Anderson <twic@urchin.earth.li> - 2011-08-27 14:00 +0100
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-08-27 08:42 -0700
Re: Style Police (a rant) Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-08-27 11:58 -0400
Re: Style Police (a rant) "John B. Matthews" <nospam@nospam.invalid> - 2011-08-28 08:21 -0400
Re: Style Police (a rant) Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-08-28 18:07 -0300
Re: Style Police (a rant) Roedy Green <see_website@mindprod.com.invalid> - 2011-08-29 04:20 -0700
Re: Style Police (a rant) Tim Slattery <Slattery_T@bls.gov> - 2011-08-29 09:11 -0400
Re: Style Police (a rant) Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-08-29 20:50 -0400
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-30 11:27 +0000
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-08-30 09:36 -0700
Re: Style Police (a rant) Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-30 17:51 +0000
Re: Style Police (a rant) Tim Slattery <Slattery_T@bls.gov> - 2011-08-30 08:51 -0400
Re: Style Police (a rant) Patricia Shanahan <pats@acm.org> - 2011-08-30 09:04 -0700
Re: Style Police (a rant) Lew <lewbloch@gmail.com> - 2011-08-30 09:43 -0700
Re: Style Police (a rant) Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-08-31 00:31 +0200
Page 1 of 10 [1] 2 3 … 10 Next page →
| From | Eric Sosman <esosman@ieee-dot-org.invalid> |
|---|---|
| Date | 2011-08-26 20:56 -0400 |
| Subject | Style Police (a rant) |
| Message-ID | <j39fdc$1hi$1@dont-email.me> |
In recent days I've encountered a tool called "Checkstyle," that
parses Java code and flags various departures from its baked-in rules.
Some of these are worthwhile: It will whine if you override equals()
without overriding hashCode(), it will shriek if a method's Javadoc
omits a @param or @throws, it will moan if a static final field isn't
ALL_CAPS, and so on. Some are less so: It insists that all method
parameters should be final, it forbids the ?: operator, it tut-tuts
at `x << 8' for using a "magic number."
But the subject of this rant is its complaint that a class is "not
designed for extension." You write a perfectly ordinary class with
methods foo() and bar(), and Checkstyle throws up its hands and gibbers
that your class is "not designed for extension." Say, what?
Well, it turns out that "not designed for extension" means that
your class has one or more methods that are not either final, abstract,
or empty. That's it, that's The Rule.
You can "design for extension" by having final methods, methods
that a subclass cannot override even if it needs to.
You can "design for extension" by having abstract methods, methods
with no implementation that a subclass must implement on its own.
Or you can "design for extension" by having methods that do
nothing at all. (A peculiar measure of productivity, it seems to me.)
BUT if you have a concrete non-final method that actually *does*
something, you have not "designed for extension." It's all in aid of
somebody's theory about programming style: You're all right as long as
you freeze your methods against overriding or ensure they're impotent.
I wonder what this Checkstyle tool would think of the concrete,
non-final, non-empty equals(), hashCode(), clone(), toString(), and
finalize() methods of ... java.lang.Object, the one class *no* Java
program can avoid extending. If java.lang.Object is "not designed for
extension," is there any hope left for the language?
Enforcing good style is difficult. I wish the purveyors of the
enforcement tools would realize it's beyond their powers to do it well.
--
Eric Sosman
esosman@ieee-dot-org.invalid
[toc] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2011-08-27 09:58 +0200 |
| Message-ID | <9brmdkFqsmU1@mid.individual.net> |
| In reply to | #7405 |
On 08/27/2011 02:56 AM, Eric Sosman wrote: > > In recent days I've encountered a tool called "Checkstyle," that > parses Java code and flags various departures from its baked-in rules. > Some of these are worthwhile: It will whine if you override equals() > without overriding hashCode(), it will shriek if a method's Javadoc > omits a @param or @throws, it will moan if a static final field isn't > ALL_CAPS, and so on. Some are less so: It insists that all method > parameters should be final, it forbids the ?: operator, it tut-tuts > at `x << 8' for using a "magic number." > > But the subject of this rant is its complaint that a class is "not > designed for extension." You write a perfectly ordinary class with > methods foo() and bar(), and Checkstyle throws up its hands and gibbers > that your class is "not designed for extension." Say, what? > > Well, it turns out that "not designed for extension" means that > your class has one or more methods that are not either final, abstract, > or empty. That's it, that's The Rule. ... > Enforcing good style is difficult. I wish the purveyors of the > enforcement tools would realize it's beyond their powers to do it well. I couldn't agree more, especially since I have suffered badly from the "method parameters must be final" style police of this tool (which has issues of its own) when a company bought my company and tried to introduce the checkstyle police on a ton of existing code. Luckily I could avoid being forced to convert _all_ method parameters in the code to the "new style" - and eventually working for the company altogether. And it's not only the authors of such tools. There are managers for whom it seems to be easier to enforce rules with tools like these than to judge the quality of their workforce themselves. I can accept that these programs are imperfect (and e.g. use them to deliver helpful hints), but people making these programs a bible are worse. Kind regards robert
[toc] | [prev] | [next] | [standalone]
| From | Rajiv Gupta <rajiv@invalid.com> |
|---|---|
| Date | 2011-08-27 18:02 +1000 |
| Message-ID | <j3a8a7$7h5$1@speranza.aioe.org> |
| In reply to | #7405 |
On 2011-08-27 10:56:40 +1000, Eric Sosman said: > > I wonder what this Checkstyle tool would think of the concrete, > non-final, non-empty equals(), hashCode(), clone(), toString(), and > finalize() methods of ... java.lang.Object, the one class *no* Java > program can avoid extending. If java.lang.Object is "not designed for > extension," is there any hope left for the language? > > Enforcing good style is difficult. I wish the purveyors of the > enforcement tools would realize it's beyond their powers to do it well. You are not forced to use the tool. These tool are often written by the pedants and those who don't have much real world experience. The correctness checking inbuilt into modern IDEs is sufficient anyway.
[toc] | [prev] | [next] | [standalone]
| From | v_borchert@despammed.com (Volker Borchert) |
|---|---|
| Date | 2011-08-27 08:40 +0000 |
| Message-ID | <j3aahk$d7b$1@Gaia.teknon.de> |
| In reply to | #7409 |
Rajiv Gupta wrote: > On 2011-08-27 10:56:40 +1000, Eric Sosman said: > > > > I wonder what this Checkstyle tool would think of the concrete, > > non-final, non-empty equals(), hashCode(), clone(), toString(), and > > finalize() methods of ... java.lang.Object, the one class *no* Java > > program can avoid extending. If java.lang.Object is "not designed for > > extension," is there any hope left for the language? > > > > Enforcing good style is difficult. I wish the purveyors of the > > enforcement tools would realize it's beyond their powers to do it well. > > You are not forced to use the tool. These tool are often written by > the pedants and those who don't have much real world experience. The > correctness checking inbuilt into modern IDEs is sufficient anyway. <advocacy> I like findbugs. It integrates neatly into Eclipse, detectors can be enabled or disabled one by one, and you could even add your own. </advocacy> -- "I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed> "I'm a mechanic, not a doctor." Volker Borchert <v_borchert@despammed.com>
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2011-08-27 13:27 +0200 |
| Message-ID | <j3akb0$61g$1@news.albasani.net> |
| In reply to | #7405 |
Eric Sosman schrieb: > BUT if you have a concrete non-final method that actually *does* > something, you have not "designed for extension." It's all in aid of > somebody's theory about programming style: You're all right as long as I have noticed that final methods sometimes execute faster than non-final methods. The final modifier gives a hint to the optimizers. So I usually develop for a while without bothering about final, then I run some of the style checks of the IDA, that also spot missing final keywords. And I put the final keywords. Bye
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2011-08-27 13:33 +0200 |
| Message-ID | <j3akn1$6tu$1@news.albasani.net> |
| In reply to | #7412 |
Jan Burse schrieb: > Eric Sosman schrieb: >> BUT if you have a concrete non-final method that actually *does* >> something, you have not "designed for extension." It's all in aid of >> somebody's theory about programming style: You're all right as long as > > I have noticed that final methods sometimes execute faster > than non-final methods. The final modifier gives a hint to > the optimizers. > > So I usually develop for a while without bothering about final, > then I run some of the style checks of the IDA, that also spot > missing final keywords. And I put the final keywords. > > Bye The final keywords is found more then ten time (>10) on the following page: http://www.javaperformancetuning.com/tips/rawtips.shtml Bye
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@ieee-dot-org.invalid> |
|---|---|
| Date | 2011-08-27 11:08 -0400 |
| Message-ID | <j3b1bc$13k$1@dont-email.me> |
| In reply to | #7413 |
On 8/27/2011 7:33 AM, Jan Burse wrote:
> Jan Burse schrieb:
>> Eric Sosman schrieb:
>>> BUT if you have a concrete non-final method that actually *does*
>>> something, you have not "designed for extension." It's all in aid of
>>> somebody's theory about programming style: You're all right as long as
>>
>> I have noticed that final methods sometimes execute faster
>> than non-final methods. The final modifier gives a hint to
>> the optimizers.
>>
>> So I usually develop for a while without bothering about final,
>> then I run some of the style checks of the IDA, that also spot
>> missing final keywords. And I put the final keywords.
>>
>> Bye
>
> The final keywords is found more then ten time (>10) on
> the following page:
> http://www.javaperformancetuning.com/tips/rawtips.shtml
The page looks like a simple list of one-sentence "tips," just
collected without evaluation. "Collected" in the past tense, by
the way, meaning a decade or more ago. If you're tuning your 2011
Java code to get maximum performance from a 1998 JVM, I respecfully
submit you're probably making the wrong optimizations.
Besides, that's not my complaint. This Checkstyle tool wants
me to ensure that no actual executable code is ever overridden; it
is happy only if an overridable method is empty or abstract. On
that criterion, java.lang.Object is "not designed for extension,"
an assessment that strikes me as fundamentally fatuous.
--
Eric Sosman
esosman@ieee-dot-org.invalid
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2011-08-27 08:34 -0700 |
| Message-ID | <d906c374-1751-4b85-b844-fd82569ea9ac@glegroupsg2000goo.googlegroups.com> |
| In reply to | #7413 |
Jan Burse wrote: >> I have noticed that final methods sometimes execute faster >> than non-final methods. The final modifier gives a hint to >> the optimizers. How did you "notice" that - by what measurements under what conditions? >> So I usually develop for a while without bothering about final, >> then I run some of the style checks of the IDA, that also spot >> missing final keywords. And I put the final keywords. > > The final keywords is found more then ten time (>10) on > the following page: > http://www.javaperformancetuning.com/tips/rawtips.shtml Really? You're citing performance optimization tips from 1999-2991? You do realize that virtually no performance "tips" from that era apply any more, right? Even in 2002 the use of 'final' to help optimize was recognized as urban legend: http://www.ibm.com/developerworks/java/library/j-jtp1029/index.html "Like many myths about Java performance, the erroneous belief that declaring classes or methods as final results in better performance is widely held but rarely examined. The argument goes that declaring a method or class as final means that the compiler can inline method calls more aggressively, because it knows that at run time this is definitely the version of the method that's going to be called. But this is simply not true. Just because class X is compiled against final class Y doesn't mean that the same version of class Y will be loaded at run time. So the compiler cannot inline such cross-class method calls safely, final or not. Only if a method is private can the compiler inline it freely, and in that case, the final keyword would be redundant. "On the other hand, the run-time environment and JIT compiler have more information about what classes are actually loaded, and can make much better optimization decisions than the compiler can. If the run-time environment knows that no classes are loaded that extend Y, then it can safely inline calls to methods of Y, regardless of whether Y is final (as long as it can invalidate such JIT-compiled code if a subclass of Y is later loaded). So the reality is that while final might be a useful hint to a dumb run-time optimizer that doesn't perform any global dependency analysis, its use doesn't actually enable very many compile-time optimizations, and is not needed by a smart JIT to perform run-time optimizations." -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2011-08-27 08:37 -0700 |
| Message-ID | <7e96cecb-a23d-42d5-8917-d47eb5056482@glegroupsg2000goo.googlegroups.com> |
| In reply to | #7416 |
Lew wrote: > Jan Burse wrote: >> The final keywords is found more then ten time (>10) on >> the following page: >> http://www.javaperformancetuning.com/tips/rawtips.shtml > > Really? You're citing performance optimization tips from 1999-2991? > Oops, fat-fingered that one: "1999-2001" -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2011-08-27 17:59 +0200 |
| Message-ID | <j3b49j$8u6$1@news.albasani.net> |
| In reply to | #7416 |
Lew schrieb: > Jan Burse wrote: >>> I have noticed that final methods sometimes execute faster >>> than non-final methods. The final modifier gives a hint to >>> the optimizers. > > How did you "notice" that - by what measurements under what conditions? > It is around 1% - 10% in a crucial spot in my application. Without the final keyword a JIT potentially needs to reoptimize code, when classes are later loaded. Since although an analysis might yield that a class method is actually not overridden, it might still get overridden at run time. It might get overridden by Class.forName or even more massive by URLClassLoader.addURL. May application makes use of the former, therefore I am always doing the final where I can. Bye
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2011-08-27 18:06 +0200 |
| Message-ID | <j3b4mn$a2e$1@news.albasani.net> |
| In reply to | #7420 |
Jan Burse schrieb: > Without the final keyword a JIT potentially needs to reoptimize > code, when classes are later loaded. Since although an analysis > might yield that a class method is actually not overridden, > it might still get overridden at run time. Of course the problem is not so much there for JITs that do call site specific PICs. So a method that is not overridden will also have not multiple entries in the PICs. But with the final keyword we can put a closure mark on the PICs we don't need to bother of extending them at runtime in case a new method implementation pops up at the call site. And this could change the realization of the PICs. So I guess this is not an urban legend. Unfortunately I did document so much my findings that final has an impact. It occurs to me once a while. But also I am switching the JDK a couples of time, i.e. migrating form 32-bit to 64-bit. With the 64-bit I noticed I different sensitivity profile. Things that made the 32-bit JDK stumble don't have any impact at all for the 64-bit. For example the garbage collection runs very smooth with much less effort. So not an urban legend but maybe yes a moving target. Bye
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2011-08-27 18:08 +0200 |
| Message-ID | <j3b4pl$a2e$2@news.albasani.net> |
| In reply to | #7421 |
Jan Burse schrieb: > Of course the problem is not so much there for JITs that do > call site specific PICs. So a method that is not overridden > will also have not multiple entries in the PICs. Definition of PICs: See here: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.36.6379&rep=rep1&type=pdf
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2011-08-27 09:50 -0700 |
| Message-ID | <36f4953c-f085-4850-85eb-bb248a8cf1bb@glegroupsg2000goo.googlegroups.com> |
| In reply to | #7421 |
Jan Burse wrote: >> Without the final keyword a JIT potentially needs to reoptimize >> code, when classes are later loaded. Since although an analysis >> might yield that a class method is actually not overridden, >> it might still get overridden at run time. > > Of course the problem is not so much there for JITs that do > call site specific PICs. So a method that is not overridden > will also have not multiple entries in the PICs. > > But with the final keyword we can put a closure mark on the > PICs we don't need to bother of extending them at runtime > in case a new method implementation pops up at the call site. > And this could change the realization of the PICs. > > So I guess this is not an urban legend. Unfortunately I did > document so much my findings that final has an impact. It > occurs to me once a while. But also I am switching the JDK > a couples of time, i.e. migrating form 32-bit to 64-bit. > > With the 64-bit I noticed I different sensitivity profile. > Things that made the 32-bit JDK stumble don't have any impact > at all for the 64-bit. For example the garbage collection runs > very smooth with much less effort. > > So not an urban legend but maybe yes a moving target. Thanks for the information. Except in performance-critical hot spots in code, such as yours presumably was, the movability of the target militates against such strategies. More importantly, use of 'final' on classes and methods is a semantic restriction; you have to be responsible for the consequences to program logic. Fortunately for your use case, it's frequently the right thing to do. As usual, the rule is to do the right thing for the logic first and foremost. The problem with your post on the optimization aspect is that it reads like a general rule when in fact it was a particular case for a particular environment with a (presumably) important effect on (presumably) critical performance. By your post cited here, it isn't even a durable effect. Again, the downside is mitigated by the likely semantic benefit of using 'final' in that context, but that seems more coincidental in this case than deliberate. I notice that you didn't describe your performance-test methodology. HotSpot compilation has some interesting variation in its effects depending on run-time considerations like whether you've heated up the analyzer (run through the code x thousand times), other things in the JVM, changes in the underlying platform, brand of JVM (strictly speaking only Oracle's has "HotSpot"), and so on. In your case I'll presume your methodology was rigorous enough, although "Unfortunately I did document so much my findings that final has an impact" should make anyone nervous about that. But that does not mean that one should recommend 'final' as a way to encourage inlining as a general technique, particularly in the face of the many expert warnings against that very practice. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2011-08-27 19:15 +0200 |
| Message-ID | <j3b8n4$iv3$1@news.albasani.net> |
| In reply to | #7423 |
Lew schrieb: > I'll presume your methodology was rigorous enough, although "Unfortunately > I did document so much my findings that final has an impact" > should make anyone nervous Well there was a typo in my post, it should read: I did NOT document
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2011-08-27 13:09 -0700 |
| Message-ID | <252cd91f-0695-4cda-8ba0-70cfbc5fbd7a@glegroupsg2000goo.googlegroups.com> |
| In reply to | #7424 |
Jan Burse wrote: > Lew schrieb: >> I'll presume your methodology was rigorous enough, although "Unfortunately >> I did document so much my findings that final has an impact" >> should make anyone nervous > Well there was a typo in my post, it should read: I did NOT document Oh - I actually read it wrong and thought you had said, "... did not document ...", and not documenting was what frightened. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2011-08-27 23:18 +0200 |
| Message-ID | <j3bmum$hoa$1@news.albasani.net> |
| In reply to | #7425 |
Lew schrieb: > Oh - I actually read it wrong and thought you had said, "... did not document ...", > and not documenting was what frightened. > Well it would be frightening if life would depend on it, but since the keyword final either does nothing or does increase the speed only a little, I focused on other stuff.
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2011-08-27 16:10 -0700 |
| Message-ID | <78817664-363f-4e73-99e5-ef3c0a3566af@glegroupsg2000goo.googlegroups.com> |
| In reply to | #7426 |
Jan Burse wrote: > Lew schrieb: > > Oh - I actually read it wrong and thought you had said, "... did not document ...", > > and not documenting was what frightened. > > > > Well it would be frightening if life would depend on it, > but since the keyword final either does nothing or > does increase the speed only a little, I focused on > other stuff. Fair enough, but I thought your thesis was that the 'final' keyword was a good thing for performance. I apologize for misunderstanding. While the 'final' keyword "either does nothing or does increase the speed only a little" from a performance standpoint, as you say, the OP's rant related to the semantic impact. In that domain the 'final' keyword does a great deal. Whether that impact is good or bad depends on how rigorous you are when you write classes. Josh Bloch's advice and the default enforcement by Checkstyle are grounded in a rigorous style of class design where you account for all corner cases and don't leave much, if anything, to chance for future users of the API. This is the style that, for example, favors checked exceptions. Some folks on the receiving side of such decisions get a little peeved - they feel put upon to catch exceptions, "Favor composition over inheritance" or "Design and document for inheritance or else prohibit it" [op cit.]. Well, that's why they're paid the big bucks. Such restrictions increase the safety and predictability of the code and systems built with it, which is their rationale. Rigor comes at a cost, that is true. Intelligent design requires that you consider the tradeoffs, bearing in mind that you yourself might or might not directly suffer the consequences of your choices. Checkstyle errs on the side of rigor in its defaults. -- Lew The journeyman knows the rules. The virtuoso knows when to break the rules. The master creates new rules.
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2011-08-28 01:59 +0200 |
| Message-ID | <j3c0dp$3jm$1@news.albasani.net> |
| In reply to | #7427 |
Lew schrieb:
> [... snip ...]
Looks like you are preaching to the convert.
Anyway, here is some fun:
class A {
A() {
init();
}
init() {
}
}
class B {
foo = 3;
init() {
super.init();
System.out.println("foo="+foo);
}
}
What value for foo will be printed when I do
new B()?
Would it make sense to put a final on init()?
Bye
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2011-08-27 18:59 -0700 |
| Message-ID | <f7ddd7ef-dde6-4b5f-97e4-6b00f04c12a1@glegroupsg2000goo.googlegroups.com> |
| In reply to | #7429 |
On Saturday, August 27, 2011 4:59:53 PM UTC-7, Jan Burse wrote:
> Lew schrieb:
> > [... snip ...]
>
> Looks like you are preaching to the convert.
> Anyway, here is some fun:
>
> class A {
>
> A() {
> init();
> }
>
> init() {
> }
>
> }
>
>
> class B {
> foo = 3;
>
> init() {
> super.init();
> System.out.println("foo="+foo);
> }
>
> }
>
> What value for foo will be printed when I do
> new B()?
>
> Would it make sense to put a final on init()?
Given that calling non-final methods from a constructor is a very well-known antipattern, it's a bit like asking, "Should I drive on the wrong side of the road?" You can get away with it for a while, perhaps, but sooner or later you're going to run into trouble.
This is an aspect of the rules I've been repeatedly citing in this thread: "Item 17: Design and document for inheritance or else prohibit it", "use of 'final' on classes and methods is a semantic restriction ... frequently the right thing to do", "[s]uch restrictions increase the safety and predictability of the code and systems built with it", "you have to be responsible for the consequences to program logic". Thanks for illustrating the points.
--
Lew
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2011-08-28 15:32 +0200 |
| Message-ID | <j3dg1l$i8e$1@news.albasani.net> |
| In reply to | #7430 |
Lew schrieb: > Given that calling non-final methods from a constructor is a > very well-known antipattern, it's a bit like asking, ... I didn't know that this is an anti pattern. A solution could be also to make the method private. Bye
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web