Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #12296 > unrolled thread
| Started by | Novice <novice@example..com> |
|---|---|
| First post | 2012-02-24 20:10 +0000 |
| Last post | 2012-02-25 00:22 +0000 |
| Articles | 20 on this page of 167 — 14 participants |
Back to article view | Back to comp.lang.java.programmer
Aspect questions? Novice <novice@example..com> - 2012-02-24 20:10 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-24 13:05 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 05:47 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-24 23:40 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 17:02 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 12:08 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 22:12 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 14:27 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 23:29 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 18:33 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 14:38 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 10:49 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 10:53 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 18:17 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 16:01 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 17:22 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 12:25 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 21:08 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 18:33 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 17:05 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 20:18 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 21:29 -0800
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-27 05:44 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-27 21:37 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-28 00:04 -0800
Re: Aspect questions? Patricia Shanahan <pats@acm.org> - 2012-02-28 01:39 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 14:54 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-28 17:24 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 04:53 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:08 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 05:12 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 21:38 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 17:27 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-27 12:22 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 22:50 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-27 17:24 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:00 +0000
Re: Aspect questions? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-29 09:14 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-29 09:55 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 21:31 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-29 23:06 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 04:33 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-03-04 23:00 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-04 17:07 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-03-05 15:33 +0000
JavaDoc linking (Was: Aspect questions?) Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-03-05 08:38 -0800
Re: JavaDoc linking (Was: Aspect questions?) Novice <novice@example..com> - 2012-03-05 17:40 +0000
Re: JavaDoc linking (Was: Aspect questions?) Patricia Shanahan <pats@acm.org> - 2012-03-05 21:25 -0800
Re: JavaDoc linking (Was: Aspect questions?) Arne Vajhøj <arne@vajhoej.dk> - 2012-03-06 17:23 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-05 23:45 -0800
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-06 06:03 -0400
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-06 21:05 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:11 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:09 -0500
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-26 23:43 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 05:20 +0000
Re: Aspect questions? Patricia Shanahan <pats@acm.org> - 2012-02-26 21:32 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 17:36 +0000
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 13:18 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 14:05 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 14:33 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 14:53 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 15:16 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 17:57 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 22:59 +0000
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-28 05:50 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:03 +0000
Re: Aspect questions? Patricia Shanahan <pats@acm.org> - 2012-02-27 13:17 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 22:55 +0000
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-27 05:58 -0400
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 18:14 +0000
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-28 00:12 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-02-28 02:04 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-27 21:22 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:11 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:14 -0500
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-28 23:09 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:25 +0000
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-01 00:22 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-03-01 01:44 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-29 23:24 -0800
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-01 21:19 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 01:52 +0000
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-03 01:39 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-03-05 15:38 +0000
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-05 22:50 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-05 23:46 -0800
Re: Aspect questions? Patricia Shanahan <pats@acm.org> - 2012-03-06 08:14 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-06 21:23 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-08 20:10 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 01:49 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-01 22:38 -0800
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-02 06:05 -0400
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 14:25 +0000
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-02 18:10 -0400
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 14:12 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-02 08:57 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-03-05 15:57 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-05 23:48 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-03-07 20:33 +0000
Re: Aspect questions? Lew <lewbloch@gmail.com> - 2012-03-07 13:09 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:20 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-02 14:28 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:16 -0500
Re: Aspect questions? markspace <-@.> - 2012-02-26 10:10 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 20:52 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 13:48 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 13:47 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 18:40 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 18:36 -0500
Re: Aspect questions? markspace <-@.> - 2012-02-26 16:04 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 19:38 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 17:09 -0800
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-26 20:08 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 19:43 -0500
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-27 22:03 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-27 21:18 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 13:43 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 01:11 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 21:49 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 18:37 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-27 12:28 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-28 00:55 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-27 17:37 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:57 +0000
Re: Aspect questions? Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-02-28 03:21 -0600
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-28 09:19 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-27 21:12 -0500
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-28 05:59 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-28 17:27 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 16:07 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:26 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 18:22 -0500
Re: Aspect questions? markspace <-@.> - 2012-02-25 20:22 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 22:20 -0800
Re: Aspect questions? markspace <-@.> - 2012-02-26 00:04 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 00:21 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 00:33 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 10:43 -0500
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-26 11:18 +0000
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-26 11:04 -0400
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-26 10:22 -0400
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 21:04 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 14:01 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 18:46 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 09:50 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 10:38 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 20:49 +0000
Re: Aspect questions? jlp <jlp@jlp.com> - 2012-02-25 09:47 +0100
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 17:03 +0000
Re: Aspect questions? jlp <jlp@jlp.com> - 2012-02-25 20:02 +0100
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-25 10:20 -0400
Re: Aspect questions? markspace <-@.> - 2012-02-25 08:18 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 12:04 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 17:17 +0000
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-25 18:40 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 18:18 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 09:21 -0500
Re: Aspect questions? Roedy Green <see_website@mindprod.com.invalid> - 2012-02-25 14:35 -0800
Re: Aspect questions? markspace <-@.> - 2012-02-24 14:30 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-24 19:47 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-24 20:52 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 09:31 -0500
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-25 11:05 -0400
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 12:20 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-24 19:00 -0500
Re: Aspect questions? Tom Anderson <twic@urchin.earth.li> - 2012-02-25 00:22 +0000
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2012-03-07 13:09 -0800 |
| Message-ID | <26456804.7036.1331154540669.JavaMail.geo-discussion-forums@pbcwi5> |
| In reply to | #12745 |
Novice wrote: > Lew wrote: >> Novice wrote: >>> Yikes! One of my great nightmares is the prospect of having to do >>> that. I can imagine you pulling it off since you do believe strongly >>> in yourself but I don't have that. The prospect of having to live by >>> sweet-talking people into buying things that they probably don't want >>> or need - and maybe can't afford - is very distasteful to me.... >> >> There you go with your assumptions again. > > > And these could be construed as insulting. I did no such thing. >> > > Sorry, no insult intended! I suppose I just projected because having to do > sales of something like vaccuum cleaners is MY nightmare..... Do you use a vacuum cleaner? Did you buy it? Should that be a nightmare for the one who sold it to you? Are you glad you have it? > I'm glad you've never been in that position. I suppose your sales job was > something like helping sell advanced technical services or software. Mortgages. Why do you continue with those assumptions? It was neither technical services nor software, nor "helping" to sell. Straight up selling, on straight commission, no base pay. > I've actually been peripherally involved in activities like that and did > fine with them. But the thought of cold-calling people to sell some general > bit of merchandise, either on the phone or door-to-door is definitely > nightmare-inducing for me. That's because you don't understand sales. I have done both door-to-door and telephone sales work, also professional-to-professional sales, and been a waiter. Sales is a service profession, not a coercive one. You make your money by helping people reduce pain and increase happiness. Why should that cause anyone to have nightmares? -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-03-02 17:20 -0500 |
| Message-ID | <4f5147b4$0$295$14726298@news.sunsite.dk> |
| In reply to | #12552 |
On 3/1/2012 2:24 AM, Lew wrote: > On 02/29/2012 05:44 PM, Novice wrote: >> always fall back on COBOL in a pinch ;-) Some of the others, even if I >> refreshed myself on them, would be of no use anywhere. I don't imagine >> CSP is used anywhere any more. Or whatever 4GL Online Express was part >> of. ;-) > > I learned SNOBOL once, at university. No practical use to it whatsoever. > I learned Prolog for the Hell of it. Never made a dime from it. Studied > a whole book on natural language processing with Prolog. Never got > f**k-all for that professionally. Learned enough LISP to know that its > fanboys are drug addicts. No one's ever offered to make that investment > pay off, not directly. > > Did I waste my time? > > Could it be that learning multiple languages, and how the hardware > works, and how to freaking build an application such that it actually > runs for someone for a change, and all those other foundational, > below-the-surface-part-of-the-iceberg skills have indeed made me the > supergenius amazing developer that I am? Could there be some gestalt > effect that polyglot programming skills elicit? > > Inquiring minds want to know. Du you know the programming language MODEST? :-) > I've been hired again and again and again for languages that I didn't > know until I started the job. > > How long does it take to learn a computer language? It took me about a > week to learn Java. Less for Python, assuming you can say that I've > learned it just because I can write effective programs in it. (I > haven't, actually.) They gave me three class sessions in college to > learn Pascal; I never showed up for the third session. Didn't need to. C > I just picked up on the job because it looked interesting. http://norvig.com/21-days.html Arne
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-03-02 14:28 -0800 |
| Message-ID | <jirhis$n44$1@news.albasani.net> |
| In reply to | #12599 |
On 03/02/2012 02:20 PM, Arne Vajhøj wrote: > On 3/1/2012 2:24 AM, Lew wrote: >> On 02/29/2012 05:44 PM, Novice wrote: >>> always fall back on COBOL in a pinch ;-) Some of the others, even if I >>> refreshed myself on them, would be of no use anywhere. I don't imagine >>> CSP is used anywhere any more. Or whatever 4GL Online Express was part >>> of. ;-) >> >> I learned SNOBOL once, at university. No practical use to it whatsoever. >> I learned Prolog for the Hell of it. Never made a dime from it. Studied >> a whole book on natural language processing with Prolog. Never got >> f**k-all for that professionally. Learned enough LISP to know that its >> fanboys are drug addicts. No one's ever offered to make that investment >> pay off, not directly. >> >> Did I waste my time? >> >> Could it be that learning multiple languages, and how the hardware >> works, and how to freaking build an application such that it actually >> runs for someone for a change, and all those other foundational, >> below-the-surface-part-of-the-iceberg skills have indeed made me the >> supergenius amazing developer that I am? Could there be some gestalt >> effect that polyglot programming skills elicit? >> >> Inquiring minds want to know. > > Du you know the programming language MODEST? > > :-) > >> I've been hired again and again and again for languages that I didn't >> know until I started the job. >> >> How long does it take to learn a computer language? It took me about a >> week to learn Java. Less for Python, assuming you can say that I've >> learned it just because I can write effective programs in it. (I >> haven't, actually.) They gave me three class sessions in college to >> learn Pascal; I never showed up for the third session. Didn't need to. C >> I just picked up on the job because it looked interesting. > > http://norvig.com/21-days.html Excellent article. As I mentioned obliquely elsewhere, my (immodest?) claims were based on my own personal sense of when I've learned a language. Also on the understanding that learning doesn't end. I programmed that project successfully in 1999 where I had a week to actually learn Java, as opposed to a year of just looking at it. I continued to learn Java throughout that project, that year, and ever since. I don't count my knowledge as complete, perfect or really, even sufficient yet. At least, not sufficient to let up on the learning. A mentor taught me years ago to devote at least an additional 20% of time above mandated work to study of the craft. "If you aren't advancing your skills that aggressively," he told me, "you're falling behind." -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-03-02 17:16 -0500 |
| Message-ID | <4f5146bc$0$286$14726298@news.sunsite.dk> |
| In reply to | #12546 |
On 2/29/2012 7:22 PM, Martin Gregorie wrote: > On Wed, 29 Feb 2012 15:25:55 +0000, Novice wrote: >> I envy you for being fluent in both C and Java (and probably others!). I >> have other languages but they're pretty much all very rusty from lack of >> use. Mind you, I have found that I can relearn things pretty quickly >> even after a long gap. I had occasion to look at a COBOL program a few >> years back and found it very familiar. Mind you, I doubt I'd say the >> same about C if I were to try that again ;-) >> > Just about all I use these days are C and Java plus a few scripting > languages (awk, PHP, bash shell scripting and Perl if you insist). In > another life I wrote much more COBOL than was good for me, so could > probably get up to speed fast with that too. There are a raft of others I > used for single projects (PL/1) or that were specific to particular > hardware (TAL, PL/9, filetab, RPG III and various assemblers). > > I'm not sure its useful to know a lot of languages: idioms often don't > transfer don't at all well and if you're not careful you can end up > writing the nasty sort of code best summarized as "a Real Programmer can > write FORTRAN in any language". If one has the intellectual integrity to not do that, then I do think learning many languages broaden ones horizon and can result in better code. Arne
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2012-02-26 10:10 -0800 |
| Message-ID | <jidsj5$k5u$1@dont-email.me> |
| In reply to | #12370 |
On 2/26/2012 9:22 AM, Novice wrote:
> If so, the next logical step would be to treat all the stuff in the
> Common project similarly. If I put all of those classes in package
> com.novice.common, then each class would have this:
>
> Logger logger = Logger.getLogger("com.novice.common");
Just as an aside, it's more common to use something like
java.util.logging.Logger.getLogger( getClass().getName() );
instead of a string constant. String constants probably won't be
refactored when a class is renamed or moved to another package. The
above needs no refactoring.
Also:
<http://commons.apache.org/logging/guide.html#Developing%20With%20JCL>
This section points out that it's more efficient to use "static" for the
logger. In desktop apps, that's what I'm used to seeing. However it
also says that "static" interacts poorly with JEE classloaders, so using
instance variables is the norm in JEE (and w/ Tomcat too).
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-26 20:52 +0000 |
| Message-ID | <XnsA005A2ACF5381jpnasty@94.75.214.39> |
| In reply to | #12373 |
markspace <-@.> wrote in news:jidsj5$k5u$1@dont-email.me:
> On 2/26/2012 9:22 AM, Novice wrote:
>> If so, the next logical step would be to treat all the stuff in the
>> Common project similarly. If I put all of those classes in package
>> com.novice.common, then each class would have this:
>>
>> Logger logger = Logger.getLogger("com.novice.common");
>
>
> Just as an aside, it's more common to use something like
>
> java.util.logging.Logger.getLogger( getClass().getName() );
>
Of course. I was already intending to substitute that once I'm clear on
what my code should be doing. I'd much rather derive the name rather than
hard-code it.
> instead of a string constant. String constants probably won't be
> refactored when a class is renamed or moved to another package. The
> above needs no refactoring.
>
> Also:
>
> <http://commons.apache.org/logging/guide.html#Developing%20With%20JCL>
>
> This section points out that it's more efficient to use "static" for
the
> logger. In desktop apps, that's what I'm used to seeing. However it
> also says that "static" interacts poorly with JEE classloaders, so
using
> instance variables is the norm in JEE (and w/ Tomcat too).
>
I'm writing more applications/Java Web Start these days than servlets so
maybe I should use 'static' and then remember NOT to use it in
servlets....
--
Novice
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-26 13:48 -0800 |
| Message-ID | <jie9b1$a01$2@news.albasani.net> |
| In reply to | #12378 |
Novice wrote: > I'm writing more applications/Java Web Start these days than servlets so > maybe I should use 'static' and then remember NOT to use it in > servlets.... "Maybe" is a key word. Usually not. Do what is right; don't fall victim to cargo-cult programming. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-26 13:47 -0800 |
| Message-ID | <jie99e$a01$1@news.albasani.net> |
| In reply to | #12373 |
On 02/26/2012 10:10 AM, markspace wrote:
> On 2/26/2012 9:22 AM, Novice wrote:
>> If so, the next logical step would be to treat all the stuff in the
>> Common project similarly. If I put all of those classes in package
>> com.novice.common, then each class would have this:
>>
>> Logger logger = Logger.getLogger("com.novice.common");
>
>
> Just as an aside, it's more common to use something like
>
> java.util.logging.Logger.getLogger( getClass().getName() );
>
> instead of a string constant. String constants probably won't be refactored
> when a class is renamed or moved to another package. The above needs no
> refactoring.
>
> Also:
>
> <http://commons.apache.org/logging/guide.html#Developing%20With%20JCL>
>
> This section points out that it's more efficient to use "static" for the
> logger. In desktop apps, that's what I'm used to seeing. However it also says
> that "static" interacts poorly with JEE classloaders, so using instance
> variables is the norm in JEE (and w/ Tomcat too).
"Efficient"? Really? Sounds like premature optimization, and it's the wrong
criterion down the line for loggers. *How* much more "efficient", and at what
cost, is the 'static' logger?
I prefer instance members for loggers. Greater flexibility and no measurable
loss in "efficiency", whatever that is. Actually, I find instance member
loggers more efficient, for the metric of efficiency that I care about.
(Robustness in the face of refactoring, per your suggestion, which wouldn't
compile if the logger were static.)
Aside: log4j lets you skip the 'getName()' call and just specify the class as
an argument, the name-by-class pattern is so widespread.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-26 18:40 -0500 |
| Message-ID | <4f4ac2d8$0$288$14726298@news.sunsite.dk> |
| In reply to | #12386 |
On 2/26/2012 4:47 PM, Lew wrote:
> On 02/26/2012 10:10 AM, markspace wrote:
>> On 2/26/2012 9:22 AM, Novice wrote:
>>> If so, the next logical step would be to treat all the stuff in the
>>> Common project similarly. If I put all of those classes in package
>>> com.novice.common, then each class would have this:
>>>
>>> Logger logger = Logger.getLogger("com.novice.common");
>>
>>
>> Just as an aside, it's more common to use something like
>>
>> java.util.logging.Logger.getLogger( getClass().getName() );
>>
>> instead of a string constant. String constants probably won't be
>> refactored
>> when a class is renamed or moved to another package. The above needs no
>> refactoring.
>>
>> Also:
>>
>> <http://commons.apache.org/logging/guide.html#Developing%20With%20JCL>
>>
>> This section points out that it's more efficient to use "static" for the
>> logger. In desktop apps, that's what I'm used to seeing. However it
>> also says
>> that "static" interacts poorly with JEE classloaders, so using instance
>> variables is the norm in JEE (and w/ Tomcat too).
>
> "Efficient"? Really? Sounds like premature optimization, and it's the
> wrong criterion down the line for loggers. *How* much more "efficient",
> and at what cost, is the 'static' logger?
Note that there is just one logger on both cases.
The difference is just whether to have multiple instance refs
to it or a single class ref.
I can not imagine the performance difference between those
being noticeable.
> I prefer instance members for loggers. Greater flexibility and no
> measurable loss in "efficiency", whatever that is. Actually, I find
> instance member loggers more efficient, for the metric of efficiency
> that I care about. (Robustness in the face of refactoring, per your
> suggestion, which wouldn't compile if the logger were static.)
getLogger(getClass()) does not compile with static but
getLogger(Xxxx.class) does and will be refactored, so that
is not a big difference either.
Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-26 18:36 -0500 |
| Message-ID | <4f4ac1ea$0$291$14726298@news.sunsite.dk> |
| In reply to | #12373 |
On 2/26/2012 1:10 PM, markspace wrote:
> On 2/26/2012 9:22 AM, Novice wrote:
>> If so, the next logical step would be to treat all the stuff in the
>> Common project similarly. If I put all of those classes in package
>> com.novice.common, then each class would have this:
>>
>> Logger logger = Logger.getLogger("com.novice.common");
>
> Just as an aside, it's more common to use something like
>
> java.util.logging.Logger.getLogger( getClass().getName() );
>
> instead of a string constant. String constants probably won't be
> refactored when a class is renamed or moved to another package. The
> above needs no refactoring.
>
> Also:
>
> <http://commons.apache.org/logging/guide.html#Developing%20With%20JCL>
>
> This section points out that it's more efficient to use "static" for the
> logger. In desktop apps, that's what I'm used to seeing. However it also
> says that "static" interacts poorly with JEE classloaders, so using
> instance variables is the norm in JEE (and w/ Tomcat too).
What does "interacts poorly with JEE classloaders" mean??
Arne
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2012-02-26 16:04 -0800 |
| Message-ID | <jieha6$f5l$1@dont-email.me> |
| In reply to | #12393 |
On 2/26/2012 3:36 PM, Arne Vajhøj wrote: > On 2/26/2012 1:10 PM, markspace wrote: >> <http://commons.apache.org/logging/guide.html#Developing%20With%20JCL> >> >> This section points out that it's more efficient to use "static" for the >> logger. In desktop apps, that's what I'm used to seeing. However it also >> says that "static" interacts poorly with JEE classloaders, so using >> instance variables is the norm in JEE (and w/ Tomcat too). > What does "interacts poorly with JEE classloaders" mean?? Did anybody read the link? "Note that for application code, declaring the log member as "static" is more efficient as one Log object is created per class, and is recommended. However this is not safe to do for a class which may be deployed via a "shared" classloader in a servlet or j2ee container or similar environment. If the class may end up invoked with different thread-context-classloader values set then the member must not be declared static. The use of "static" should therefore be avoided in code within any "library" type project. "
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-26 19:38 -0500 |
| Message-ID | <4f4ad072$0$281$14726298@news.sunsite.dk> |
| In reply to | #12397 |
On 2/26/2012 7:04 PM, markspace wrote: > On 2/26/2012 3:36 PM, Arne Vajhøj wrote: > >> On 2/26/2012 1:10 PM, markspace wrote: >>> <http://commons.apache.org/logging/guide.html#Developing%20With%20JCL> >>> >>> This section points out that it's more efficient to use "static" for the >>> logger. In desktop apps, that's what I'm used to seeing. However it also >>> says that "static" interacts poorly with JEE classloaders, so using >>> instance variables is the norm in JEE (and w/ Tomcat too). > > >> What does "interacts poorly with JEE classloaders" mean?? > > > Did anybody read the link? > > "Note that for application code, declaring the log member as "static" is > more efficient as one Log object is created per class, and is > recommended. But there is also just one Log object with a non-static ref?? > However this is not safe to do for a class which may be > deployed via a "shared" classloader in a servlet or j2ee container or > similar environment. If the class may end up invoked with different > thread-context-classloader values set then the member must not be > declared static. The use of "static" should therefore be avoided in code > within any "library" type project. " If the parent classloader of those classloaders is the one that loads log4j, then you will end up with one log object no matter what. If log4j is loaded by those classloaders, then you will end up with duplicate log objects no matter what you do. So I still don't understand what the heck they are talking about. Arne
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-26 17:09 -0800 |
| Message-ID | <jiel3t$tk3$3@news.albasani.net> |
| In reply to | #12399 |
Arne Vajhøj wrote: > markspace wrote: >> Arne Vajhøj wrote: >>> markspace wrote: >>>> <http://commons.apache.org/logging/guide.html#Developing%20With%20JCL> >>>> >>>> This section points out that it's more efficient to use "static" for the >>>> logger. In desktop apps, that's what I'm used to seeing. However it also >>>> says that "static" interacts poorly with JEE classloaders, so using >>>> instance variables is the norm in JEE (and w/ Tomcat too). >> >>> What does "interacts poorly with JEE classloaders" mean?? >> >> Did anybody read the link? How about you summarize the answer for us, as a courtesy. Please? >> "Note that for application code, declaring the log member as "static" is >> more efficient as one Log object is created per class, and is >> recommended. > > But there is also just one Log object with a non-static ref?? > >> However this is not safe to do for a class which may be >> deployed via a "shared" classloader in a servlet or j2ee container or >> similar environment. If the class may end up invoked with different >> thread-context-classloader values set then the member must not be >> declared static. The use of "static" should therefore be avoided in code >> within any "library" type project. " > > If the parent classloader of those classloaders is the > one that loads log4j, then you will end up with one > log object no matter what. > > If log4j is loaded by those classloaders, then you will > end up with duplicate log objects no matter what you do. > > So I still don't understand what the heck they are talking > about. I'm with Arne on this one. How is having only one logger object per class more efficient than having one logger object per class? And you ignored Arne's question: 'What does "interacts poorly with JEE classloaders" mean??' -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Date | 2012-02-26 20:08 -0400 |
| Message-ID | <8Qz2r.16723$xF1.14716@newsfe01.iad> |
| In reply to | #12393 |
On 12-02-26 07:36 PM, Arne Vajhøj wrote:
> On 2/26/2012 1:10 PM, markspace wrote:
>> On 2/26/2012 9:22 AM, Novice wrote:
>>> If so, the next logical step would be to treat all the stuff in the
>>> Common project similarly. If I put all of those classes in package
>>> com.novice.common, then each class would have this:
>>>
>>> Logger logger = Logger.getLogger("com.novice.common");
>>
>> Just as an aside, it's more common to use something like
>>
>> java.util.logging.Logger.getLogger( getClass().getName() );
>>
>> instead of a string constant. String constants probably won't be
>> refactored when a class is renamed or moved to another package. The
>> above needs no refactoring.
>>
>> Also:
>>
>> <http://commons.apache.org/logging/guide.html#Developing%20With%20JCL>
>>
>> This section points out that it's more efficient to use "static" for the
>> logger. In desktop apps, that's what I'm used to seeing. However it also
>> says that "static" interacts poorly with JEE classloaders, so using
>> instance variables is the norm in JEE (and w/ Tomcat too).
>
> What does "interacts poorly with JEE classloaders" mean??
>
> Arne
>
Probably this:
http://wiki.apache.org/commons/Logging/StaticLog
This is a page that's been out there for quite a few years.
As the blurb itself states, this is not a problem with your own code
that you're deploying as EARs. You can use static loggers in there all
you like. I've seen a number of long-running 24/7 J2EE/Java EE apps that
do just that, and they work fine, with perfectly independent logging,
because their own application classloaders take care of business.
AHS
--
-- Gaiety is the most outstanding feature of the Soviet Union.
Josef Stalin, November 1935
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-26 19:43 -0500 |
| Message-ID | <4f4ad1af$0$282$14726298@news.sunsite.dk> |
| In reply to | #12398 |
On 2/26/2012 7:08 PM, Arved Sandstrom wrote:
> On 12-02-26 07:36 PM, Arne Vajhøj wrote:
>> On 2/26/2012 1:10 PM, markspace wrote:
>>> On 2/26/2012 9:22 AM, Novice wrote:
>>>> If so, the next logical step would be to treat all the stuff in the
>>>> Common project similarly. If I put all of those classes in package
>>>> com.novice.common, then each class would have this:
>>>>
>>>> Logger logger = Logger.getLogger("com.novice.common");
>>>
>>> Just as an aside, it's more common to use something like
>>>
>>> java.util.logging.Logger.getLogger( getClass().getName() );
>>>
>>> instead of a string constant. String constants probably won't be
>>> refactored when a class is renamed or moved to another package. The
>>> above needs no refactoring.
>>>
>>> Also:
>>>
>>> <http://commons.apache.org/logging/guide.html#Developing%20With%20JCL>
>>>
>>> This section points out that it's more efficient to use "static" for the
>>> logger. In desktop apps, that's what I'm used to seeing. However it also
>>> says that "static" interacts poorly with JEE classloaders, so using
>>> instance variables is the norm in JEE (and w/ Tomcat too).
>>
>> What does "interacts poorly with JEE classloaders" mean??
>>
>> Arne
>>
> Probably this:
>
> http://wiki.apache.org/commons/Logging/StaticLog
>
> This is a page that's been out there for quite a few years.
>
> As the blurb itself states, this is not a problem with your own code
> that you're deploying as EARs. You can use static loggers in there all
> you like. I've seen a number of long-running 24/7 J2EE/Java EE apps that
> do just that, and they work fine, with perfectly independent logging,
> because their own application classloaders take care of business.
I don't get it.
If log4j classes are loaded by the container classloader, then
the apps should share logging no matter whether the refs are
static or not.
Sure it can be a problem sharing logging.
But I can not see what static versus non static refs has
to do with that.
Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Date | 2012-02-27 22:03 -0400 |
| Message-ID | <kCW2r.19228$HR6.11469@newsfe21.iad> |
| In reply to | #12400 |
On 12-02-26 08:43 PM, Arne Vajhøj wrote:
> On 2/26/2012 7:08 PM, Arved Sandstrom wrote:
>> On 12-02-26 07:36 PM, Arne Vajhøj wrote:
>>> On 2/26/2012 1:10 PM, markspace wrote:
>>>> On 2/26/2012 9:22 AM, Novice wrote:
>>>>> If so, the next logical step would be to treat all the stuff in the
>>>>> Common project similarly. If I put all of those classes in package
>>>>> com.novice.common, then each class would have this:
>>>>>
>>>>> Logger logger = Logger.getLogger("com.novice.common");
>>>>
>>>> Just as an aside, it's more common to use something like
>>>>
>>>> java.util.logging.Logger.getLogger( getClass().getName() );
>>>>
>>>> instead of a string constant. String constants probably won't be
>>>> refactored when a class is renamed or moved to another package. The
>>>> above needs no refactoring.
>>>>
>>>> Also:
>>>>
>>>> <http://commons.apache.org/logging/guide.html#Developing%20With%20JCL>
>>>>
>>>> This section points out that it's more efficient to use "static" for
>>>> the
>>>> logger. In desktop apps, that's what I'm used to seeing. However it
>>>> also
>>>> says that "static" interacts poorly with JEE classloaders, so using
>>>> instance variables is the norm in JEE (and w/ Tomcat too).
>>>
>>> What does "interacts poorly with JEE classloaders" mean??
>>>
>>> Arne
>>>
>> Probably this:
>>
>> http://wiki.apache.org/commons/Logging/StaticLog
>>
>> This is a page that's been out there for quite a few years.
>>
>> As the blurb itself states, this is not a problem with your own code
>> that you're deploying as EARs. You can use static loggers in there all
>> you like. I've seen a number of long-running 24/7 J2EE/Java EE apps that
>> do just that, and they work fine, with perfectly independent logging,
>> because their own application classloaders take care of business.
>
> I don't get it.
>
> If log4j classes are loaded by the container classloader, then
> the apps should share logging no matter whether the refs are
> static or not.
>
> Sure it can be a problem sharing logging.
>
> But I can not see what static versus non static refs has
> to do with that.
>
> Arne
>
I must admit, Arne, you've got a point. I'd read that commons logging
piece some years back, not too critically I see, and never thought twice
about it. Like I mentioned above, the uses of static loggers I've seen
or employed myself have not caused problems, so I figured whatever they
were talking about was something I might run across at some point, with
3rd party JARS in a shared library configuration, and recognize it if I
saw it.
I just now set up a test case using oc4j 10.1.3.5, where I created a
shared library with a JAR containing a couple of classes with log4j
loggers, one with a static Logger, one with an instance Logger.
This shared library is referenced at runtime by 2 servlets in 2 separate
web apps. Each web app has a slightly different log4j.xml, one allows
the library log statements, one is at a level that filters them out.
I tweaked the code in between various server restarts to ensure that
only the static Logger *or* the instance Logger was in use.
There was no difference between the two. We observe the expected
_undesirable_ behaviour, which is that whichever servlet is hit first,
it's the logging configuration for that web app which is used for both
web apps. *But* regardless of which Logger is in use, static or
instance, we get the same undesirable behaviour.
So I agree with you, after rigorous experimentation. :-) It's nice of
the commons logging folks to point out the hazards of shared loggers;
it's considerably less clear why they thought shared static vs. shared
instance was important.
AHS
--
-- Gaiety is the most outstanding feature of the Soviet Union.
Josef Stalin, November 1935
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-27 21:18 -0500 |
| Message-ID | <4f4c3990$0$292$14726298@news.sunsite.dk> |
| In reply to | #12468 |
On 2/27/2012 9:03 PM, Arved Sandstrom wrote:
> On 12-02-26 08:43 PM, Arne Vajhøj wrote:
>> On 2/26/2012 7:08 PM, Arved Sandstrom wrote:
>>> On 12-02-26 07:36 PM, Arne Vajhøj wrote:
>>>> On 2/26/2012 1:10 PM, markspace wrote:
>>>>> On 2/26/2012 9:22 AM, Novice wrote:
>>>>>> If so, the next logical step would be to treat all the stuff in the
>>>>>> Common project similarly. If I put all of those classes in package
>>>>>> com.novice.common, then each class would have this:
>>>>>>
>>>>>> Logger logger = Logger.getLogger("com.novice.common");
>>>>>
>>>>> Just as an aside, it's more common to use something like
>>>>>
>>>>> java.util.logging.Logger.getLogger( getClass().getName() );
>>>>>
>>>>> instead of a string constant. String constants probably won't be
>>>>> refactored when a class is renamed or moved to another package. The
>>>>> above needs no refactoring.
>>>>>
>>>>> Also:
>>>>>
>>>>> <http://commons.apache.org/logging/guide.html#Developing%20With%20JCL>
>>>>>
>>>>> This section points out that it's more efficient to use "static" for
>>>>> the
>>>>> logger. In desktop apps, that's what I'm used to seeing. However it
>>>>> also
>>>>> says that "static" interacts poorly with JEE classloaders, so using
>>>>> instance variables is the norm in JEE (and w/ Tomcat too).
>>>>
>>>> What does "interacts poorly with JEE classloaders" mean??
>>>>
>>>> Arne
>>>>
>>> Probably this:
>>>
>>> http://wiki.apache.org/commons/Logging/StaticLog
>>>
>>> This is a page that's been out there for quite a few years.
>>>
>>> As the blurb itself states, this is not a problem with your own code
>>> that you're deploying as EARs. You can use static loggers in there all
>>> you like. I've seen a number of long-running 24/7 J2EE/Java EE apps that
>>> do just that, and they work fine, with perfectly independent logging,
>>> because their own application classloaders take care of business.
>>
>> I don't get it.
>>
>> If log4j classes are loaded by the container classloader, then
>> the apps should share logging no matter whether the refs are
>> static or not.
>>
>> Sure it can be a problem sharing logging.
>>
>> But I can not see what static versus non static refs has
>> to do with that.
> I must admit, Arne, you've got a point. I'd read that commons logging
> piece some years back, not too critically I see, and never thought twice
> about it. Like I mentioned above, the uses of static loggers I've seen
> or employed myself have not caused problems, so I figured whatever they
> were talking about was something I might run across at some point, with
> 3rd party JARS in a shared library configuration, and recognize it if I
> saw it.
>
> I just now set up a test case using oc4j 10.1.3.5, where I created a
> shared library with a JAR containing a couple of classes with log4j
> loggers, one with a static Logger, one with an instance Logger.
>
> This shared library is referenced at runtime by 2 servlets in 2 separate
> web apps. Each web app has a slightly different log4j.xml, one allows
> the library log statements, one is at a level that filters them out.
>
> I tweaked the code in between various server restarts to ensure that
> only the static Logger *or* the instance Logger was in use.
>
> There was no difference between the two. We observe the expected
> _undesirable_ behaviour, which is that whichever servlet is hit first,
> it's the logging configuration for that web app which is used for both
> web apps. *But* regardless of which Logger is in use, static or
> instance, we get the same undesirable behaviour.
>
> So I agree with you, after rigorous experimentation. :-) It's nice of
> the commons logging folks to point out the hazards of shared loggers;
> it's considerably less clear why they thought shared static vs. shared
> instance was important.
I think it happens frequently. Someone claims X without investigating
too much. Because X really does not have much practical impact, then
nobody else checks the claim. Instead it get quoted by someone and
another quote that. And suddenly we have an "accepted fact" that
nobody remembers where it originally came from.
Arne
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-26 13:43 -0800 |
| Message-ID | <jie92m$9nd$1@news.albasani.net> |
| In reply to | #12370 |
On 02/26/2012 09:22 AM, Novice wrote:
> Lew wrote:
>
>> Novice wrote:
>>> Lew wrote:
>>>> You don't create multiple log files, one per class. Where did you
>>>> get that notion?
>>>>
>>> Huh? You seem to be contradicting yourself. Are you saying I should
>>> create one logging file per class or not? And why have a separate
>>> logging
>>
>> No. I never said nor implied that you should have one logging file per
>> class. That one's on you, brother.
>>
> Okay. Your phrasing was a bit confusing. I read it as "You don't create
> multiple files, (you create) one per class." Apparently that's not what
> you mean after all. Sorry.
The sentence began with "You don't...". I fail to see what can be confusing
there. An appositive phrase doesn't invert the sense of the predicate.
Which leaves the question of how we got the miscommunication in the first
place, when I never suggested such a thing.
>>> file for each class? Isn't it more logical to have all the messages
>>> that come from one program, say Foo, appear in the same log? Isn't
>>> the poor
>>
>> Yes, but why are you arguing a point not in dispute?
>>
> Because your phrasing seemed to imply that I DID want one log per class.
>
>>> Sysop going to be excessively busy if he has to check a separate log
>>> for each and every one of the - hundreds? thousands? - of classes in
>>> the system? Wouldn't it be more logical to group logs on the basis of
>>> which application is invoking the class? Therefore, if method
>>> getCurrentWeekdayName had problems while executing program Foo, the
>>> Foo log would contain the information? Wouldn't the person running
>>> Foo be the one that's notifying the SysOp that something screwy just
>>> happened while running Foo? Then the name of the application would be
>>> a huge head start in finding the problem: just look in the Foo log
>>> and all will be revealed. Or at least enough to get started.
>>
>> How you do go on.
>>
>> No one is suggesting anything like that scenario. so cool your jets,
>> Cadet!
>>
>> Wow.
>>
> Sorry. I was confused by what you seemed to imply.
"Seemed" foists the responsibility off. I didn't do the "seeming".
...
> As for the term "configuration file" I didn't realize you meant
> "logging.properties". That was my confusion there; I don't recall hearing
> that called a configuration file before and thought you were talking
> about something completely new and outside my experience.
I used the term in the exact same sense as the logging library documentation
and in computer programming generally.
>>> If this is some routine thing that professional developers do, great.
>>> I obviously need to know about it. Can you point me to a tutorial or
>>> whatever that will explain what they are and how to create them?
>>
>> GIYF, dude.
>>
> GIYF??
http://lmgtfy.com/?q=GIYF
...
> I expect that they are assuming that each project has a unique package
> name. Therefore, if my company is novice.com, then the Foo project will
Huh?
Have you read the Java tutorial?
<http://docs.oracle.com/javase/tutorial/java/package/index.html>
> presumably have a package named com.novice.foo and the Bar project will
Don't presume; design. It is very possible that the "Foo" project will not
have a package 'com.novice.foo', if it has 'com.novice.foo.qux',
'com.novice.foo.bleh' and so on.
> have a package named com.novice.bar. Then, the logging for the Foo
> project will be based on Logger.getLogger("com.novice.foo"), right? Then
> every class within the Foo project will have the line:
>
> Logger logger = Logger.getLogger("com.novice.foo");
No, it won't. First, you have completely ignored that I said "one logger per
class". How did you distort that into "one logger per package"? Second, you
don't design packages for the logger, you design loggers for the packages.
> Have I got this so far?
Not yet.
> If so, the next logical step would be to treat all the stuff in the
> Common project similarly. If I put all of those classes in package
> com.novice.common, then each class would have this:
STOP!
I don't know how you make these leaps, and I am defeated as to how to advise
you not to. You go on for paragraphs about bad ideas that were never suggested
to you.
> Logger logger = Logger.getLogger("com.novice.common");
>
> Or would it be better to get a reference to the logger within Foo and
> pass that to the classes in the Common project so that they write to the
> logger used by the instantiating class from Foo?
Once again, I repeat, and you may recall the Javadoc quotes I provided
upthread on this matter, getting a logger with a particular name gets a
reference to that same-named logger. Already. Without additional complication
on your part. It's built in. You don't need to reinvent it. It already
happens. All you have to do is give the same name. You will already have
gotten the reference. You don't have to pass it anywhere. It's already there.
Read the Javadocs. Again. And again. And again. And again. Don't read what
isn't in there - read what it says. It says that if you give the 'getLogger()'
the same name, it will return a reference to the same logger.
Aside from that, I have no idea at all what you intend to say by, "so that
they write to the logger used by the instantiating class from Foo". What
precisely do you mean there?
> Now, as it turns out, I've actually got a bunch of packages in project
> Common. I'm separating different kinds of common classes via packages.
> I'm not sure now if that is a good idea or a bad one. I've got separate
READ THE TUTORIAL!
> packages with the Common project for utilities, for classes dealing with
> preference handling, for classes that are just simple lookups (including
> Enums), classes that create generic panels for GUIs, etc. So maybe I need
> to ask first if it is a bad idea to separate my common code into
> categories or if it is better to lump it all together into a single
> package.
It is better to group types into packages.
> If keeping the separate packages is a good idea, then I need a bit of
> guidance on whether there should be a separate logger for each package or
> whether I'm better to write all messages from all Common classes to the
> same logger, e.g. com.novice.common despite their different packages.
Once again, as I stated upthread some time ago and others have reiterated, the
common practice (but by no means the only one) is one logger per class.
Loggers "inherit", so that gives some flexibility in how you do things.
> Now, if Project Foo only uses code from one other project, Common, I only
> have two logs to worry about, the one that has all the Foo stuff and the
> one that has all the Common stuff. That's not too bad. Then again, maybe
What? You should only have one log, unless they use different libraries to log.
> it would be better to use Logger.getLogger("com.novice") and write every
> message from every class I write to the very same log, regardless of
> project. What is the best practice here?
Huh? again.
What you name the logger is not connected to where it logs. Where it logs is
determined by the configuration for that logger. Usually it'll write to the
same log as its parent. The best practice here is to make sense in the first
place. You ask a question about naming a logger, but cast it in turns of where
it logs. Apples and oranges, dude. Naming a logger doesn't change where it
logs. Read the logger documentation, please. All this information is in the
documentation.
The configuration determines where the log goes. No changes to logger names
are needed, just change the configuration file and restart.
We're starting to make the same points over and over again. It's frustrating
to provide you an answer and have you come back with the same question. Please
assimilate the answers already given.
To summarize the repeated points here:
- Configuration files usually suffice to configure logging. You rarely need to
programmatically configure logging, and should resist doing so. Otherwise you
defeat the point of changing logging strategy without having to rebuild.
- The logger name determines which logger instance you get. NOT, and I repeat,
*NOT* where it logs.
- Conventionally, and usually most usefully, loggers are named for the class
in which they are used. So the logger for 'com.lewscanon.example.Foo' would
come via 'getLogger(com.lewscanon.example.Foo.class.getName())'.
and emergingly,
- Packages are to organize your program irrespective of logging strategy.
Some of this is material in the basic tutorial, particular the info about
packages, and should be mastered first before, say, learning how to code a
for-each loop.
> I feel like I'm starting to see what you have in mind but I hope you stay
> with me for just a bit longer until we've hashed the last bits out. I
> don't want to go off in the wrong direction again so I need your
> confirmation that I'm starting to get it now.
Your commitment is duly noted and quite laudable.
But "starting" is still a long way from "hash ... the last bits out". So I
hope your patience is up to the task. You lack certain Java fundamentals.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-27 01:11 +0000 |
| Message-ID | <XnsA005CE95782C5jpnasty@94.75.214.39> |
| In reply to | #12385 |
Lew <noone@lewscanon.com> wrote in news:jie92m$9nd$1@news.albasani.net:
> On 02/26/2012 09:22 AM, Novice wrote:
>> Lew wrote:
>>
>>> Novice wrote:
>>>> Lew wrote:
>>>>> You don't create multiple log files, one per class. Where did you
>>>>> get that notion?
>>>>>
>>>> Huh? You seem to be contradicting yourself. Are you saying I should
>>>> create one logging file per class or not? And why have a separate
>>>> logging
>>>
>>> No. I never said nor implied that you should have one logging file
>>> per class. That one's on you, brother.
>>>
>> Okay. Your phrasing was a bit confusing. I read it as "You don't
>> create multiple files, (you create) one per class." Apparently that's
>> not what you mean after all. Sorry.
>
> The sentence began with "You don't...". I fail to see what can be
> confusing there. An appositive phrase doesn't invert the sense of the
> predicate.
>
> Which leaves the question of how we got the miscommunication in the
> first place, when I never suggested such a thing.
>
Okay, let's not flog this to death. I just want to figure this out, not
get into a detailed post mortem about what you meant and what I thought
you meant and all of that.
I've apparently jumped to some (several?) wrong conclusions. I admit
that. I'm trying to listen and work with what you're telling me but I'm
not quite getting things yet.
>>>> file for each class? Isn't it more logical to have all the messages
>>>> that come from one program, say Foo, appear in the same log? Isn't
>>>> the poor
>>>
>>> Yes, but why are you arguing a point not in dispute?
>>>
>> Because your phrasing seemed to imply that I DID want one log per
>> class.
>>
>>>> Sysop going to be excessively busy if he has to check a separate
>>>> log for each and every one of the - hundreds? thousands? - of
>>>> classes in the system? Wouldn't it be more logical to group logs on
>>>> the basis of which application is invoking the class? Therefore, if
>>>> method getCurrentWeekdayName had problems while executing program
>>>> Foo, the Foo log would contain the information? Wouldn't the person
>>>> running Foo be the one that's notifying the SysOp that something
>>>> screwy just happened while running Foo? Then the name of the
>>>> application would be a huge head start in finding the problem: just
>>>> look in the Foo log and all will be revealed. Or at least enough to
>>>> get started.
>>>
>>> How you do go on.
>>>
>>> No one is suggesting anything like that scenario. so cool your jets,
>>> Cadet!
>>>
>>> Wow.
>>>
>> Sorry. I was confused by what you seemed to imply.
>
> "Seemed" foists the responsibility off. I didn't do the "seeming".
>
Okay, it was all me then. Everything you've said has been crystal clear
and no reasonable human being could possibly misunderstand what you were
saying or implying.
> ...
>
>> As for the term "configuration file" I didn't realize you meant
>> "logging.properties". That was my confusion there; I don't recall
>> hearing that called a configuration file before and thought you were
>> talking about something completely new and outside my experience.
>
> I used the term in the exact same sense as the logging library
> documentation and in computer programming generally.
>
Again, I've got some gaps in my education. Those are my fault, not yours.
I'm just trying to understand what you say. When I get confused, I echo
back to see if I've got things right. So far, I'm not doing too well.
>>>> If this is some routine thing that professional developers do,
>>>> great. I obviously need to know about it. Can you point me to a
>>>> tutorial or whatever that will explain what they are and how to
>>>> create them?
>>>
>>> GIYF, dude.
>>>
>> GIYF??
>
> http://lmgtfy.com/?q=GIYF
> ...
>
Fair enough.
>> I expect that they are assuming that each project has a unique
>> package name. Therefore, if my company is novice.com, then the Foo
>> project will
>
> Huh?
>
> Have you read the Java tutorial?
> <http://docs.oracle.com/javase/tutorial/java/package/index.html>
>
I have now. It doesn't help much though; I knew all of that stuff before.
Figuring out how to apply it to my situation is where I seem to be having
trouble.
>> presumably have a package named com.novice.foo and the Bar project
>> will
>
> Don't presume; design. It is very possible that the "Foo" project
> will not have a package 'com.novice.foo', if it has
> 'com.novice.foo.qux', 'com.novice.foo.bleh' and so on.
>
Sure. Foo actually contains two programs, the main one which uses a file
to drive an application and a support program which simplifies the
editing of the file that drives the main program. Those could possibly be
in different packages within the same project, com.novice.foo.bart and
com.novice.foo.homer. But to my way of thinking, they are such close
cousins that they may just as well be in the same package.
>> have a package named com.novice.bar. Then, the logging for the Foo
>> project will be based on Logger.getLogger("com.novice.foo"), right?
>> Then every class within the Foo project will have the line:
>>
>> Logger logger = Logger.getLogger("com.novice.foo");
>
> No, it won't. First, you have completely ignored that I said "one
> logger per class". How did you distort that into "one logger per
> package"? Second, you don't design packages for the logger, you design
> loggers for the packages.
>
Sorry, you're right. I muddled the two together.
>> Have I got this so far?
>
> Not yet.
>
>> If so, the next logical step would be to treat all the stuff in the
>> Common project similarly. If I put all of those classes in package
>> com.novice.common, then each class would have this:
>
> STOP!
>
> I don't know how you make these leaps, and I am defeated as to how to
> advise you not to. You go on for paragraphs about bad ideas that were
> never suggested to you.
>
Sorry, one mistake just leads to the next. Let me rephrase.
Assuming that project Foo has a single package, com.novice.foo and three
classes, hickory, dickory, and dock, class hickory's logger would be
"com.novice.foo.hickory", class dickory's logger would be
"com.novice.foo.dickory" and class dock's logger would be
"com.novice.foo.dock".
Is that right now?
>> Logger logger = Logger.getLogger("com.novice.common");
>>
>> Or would it be better to get a reference to the logger within Foo and
>> pass that to the classes in the Common project so that they write to
>> the logger used by the instantiating class from Foo?
>
> Once again, I repeat, and you may recall the Javadoc quotes I provided
> upthread on this matter, getting a logger with a particular name gets
> a reference to that same-named logger. Already. Without additional
> complication on your part. It's built in. You don't need to reinvent
> it. It already happens. All you have to do is give the same name. You
> will already have gotten the reference. You don't have to pass it
> anywhere. It's already there. Read the Javadocs. Again. And again. And
> again. And again. Don't read what isn't in there - read what it says.
> It says that if you give the 'getLogger()' the same name, it will
> return a reference to the same logger.
Yes, of course, you're absolutely right. I forgot that.
>
> Aside from that, I have no idea at all what you intend to say by, "so
> that they write to the logger used by the instantiating class from
> Foo". What precisely do you mean there?
>
It doesn't really matter. In fact it's dumb; I still had the thought in
my brain that the main program was going to pass its logger to each class
that it instantiates it but it's not. Each class is going to be getting
it's own logger with
Logger logger Logger.getLogger(getClass().getName());
>> Now, as it turns out, I've actually got a bunch of packages in
>> project Common. I'm separating different kinds of common classes via
>> packages. I'm not sure now if that is a good idea or a bad one. I've
>> got separate
>
> READ THE TUTORIAL!
>
>> packages with the Common project for utilities, for classes dealing
>> with preference handling, for classes that are just simple lookups
>> (including Enums), classes that create generic panels for GUIs, etc.
>> So maybe I need to ask first if it is a bad idea to separate my
>> common code into categories or if it is better to lump it all
>> together into a single package.
>
> It is better to group types into packages.
>
Yes, every class is already in one or another named package and has been
for a long time. I'm still struggling a bit over which classes belong in
the SAME package and which should not.
My thinking is that classes in the Common PROJECT should also be in
packages that are distinct from the packages used for Projects Foo or
Bar, which will have names like "com.novice.foo" and "com.novice.bar".
I think I want "com.novice.common" for the classes in the Common project
but I'm not sure if all classes in Common should be in the same package
or if it is better to group similar classes within the Common project
into distinct packages like "com.novice.common.lookups",
"com.novice.common.utilities", etc. etc. I'm not seeing a huge benefit to
separate packages although I'm using separate packages now so that
similar things are together. (That just feels like the right thing to do
but so far, most of my "feelings" have been wrong!)
>> If keeping the separate packages is a good idea, then I need a bit of
>> guidance on whether there should be a separate logger for each
>> package or whether I'm better to write all messages from all Common
>> classes to the same logger, e.g. com.novice.common despite their
>> different packages.
>
> Once again, as I stated upthread some time ago and others have
> reiterated, the common practice (but by no means the only one) is one
> logger per class.
>
Right. That is gradually sinking in, believe it or not! In fact, I'm just
about ready to replace all of the existing nonsense that I've been doing
with a
Logger logger = Logger.getLogger(getClass().getName());
in all my classes.
> Loggers "inherit", so that gives some flexibility in how you do
> things.
>
>> Now, if Project Foo only uses code from one other project, Common, I
>> only have two logs to worry about, the one that has all the Foo stuff
>> and the one that has all the Common stuff. That's not too bad. Then
>> again, maybe
>
> What? You should only have one log, unless they use different
> libraries to log.
>
No. I'm strictly using java.util.logging for now. Arved's got me thinking
about this new one, slf4j, but I'm not ready to go there yet.
So I want to end up with all of my classes in all of my Projects writing
to a single log?
Hmm. Yes, I suppose that makes sense. I need to review the whole
"inherit" aspect of logging but I've been thinking of one logger equating
to one log and that's not right, is it? See, the penny is dropping....
Lots of loggers but only one log.... Yes, I need to get my head around
that and think of how that works. Maybe rereading that logging overview
will make that sink in....
>> it would be better to use Logger.getLogger("com.novice") and write
>> every message from every class I write to the very same log,
>> regardless of project. What is the best practice here?
>
> Huh? again.
>
> What you name the logger is not connected to where it logs. Where it
> logs is determined by the configuration for that logger. Usually it'll
> write to the same log as its parent. The best practice here is to make
> sense in the first place. You ask a question about naming a logger,
> but cast it in turns of where it logs. Apples and oranges, dude.
> Naming a logger doesn't change where it logs. Read the logger
> documentation, please. All this information is in the documentation.
>
Yes, that's starting to become clear now.
> The configuration determines where the log goes. No changes to logger
> names are needed, just change the configuration file and restart.
>
> We're starting to make the same points over and over again. It's
> frustrating to provide you an answer and have you come back with the
> same question. Please assimilate the answers already given.
>
I'm sure it is frustrating for you and I'm sorry. But believe me, it is
massively frustrating for me too!
> To summarize the repeated points here:
>
> - Configuration files usually suffice to configure logging. You rarely
> need to programmatically configure logging, and should resist doing
> so. Otherwise you defeat the point of changing logging strategy
> without having to rebuild.
>
> - The logger name determines which logger instance you get. NOT, and I
> repeat, *NOT* where it logs.
>
> - Conventionally, and usually most usefully, loggers are named for the
> class in which they are used. So the logger for
> 'com.lewscanon.example.Foo' would come via
> 'getLogger(com.lewscanon.example.Foo.class.getName())'.
>
> and emergingly,
>
> - Packages are to organize your program irrespective of logging
> strategy.
>
> Some of this is material in the basic tutorial, particular the info
> about packages, and should be mastered first before, say, learning how
> to code a for-each loop.
>
>> I feel like I'm starting to see what you have in mind but I hope you
>> stay with me for just a bit longer until we've hashed the last bits
>> out. I don't want to go off in the wrong direction again so I need
>> your confirmation that I'm starting to get it now.
>
> Your commitment is duly noted and quite laudable.
>
> But "starting" is still a long way from "hash ... the last bits out".
> So I hope your patience is up to the task. You lack certain Java
> fundamentals.
>
I think we're a lot closer to putting this to bed now than we were a few
hours ago. In fact, I may be able to proceed on my own now.
The only thing that REALLY bugs me still is that I can't find the darned
log records containing the weekdays that I mentioned elsewhere in the
thread. They're NOT at %h/java%u.log nor at the other place suggested in
the Tracing and Logging document. And THAT is really driving me crazy. I
can't think of anywhere else to look based on anything I've seen in the
references you and others have given me. I _think_ the logging.properties
file is ensuring that a physical log file is being written but maybe it's
messed up in some way to keep it from writing at all. Or from righting
INFO level records. But I don't think that's it.
If you have any insight into that, you'd really be helping me out. It's
hard to absorb the information you are giving me when my mind keeps
obsessing on where the darned log files are.
--
Novice
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-26 21:49 -0800 |
| Message-ID | <jif5gv$ih$1@news.albasani.net> |
| In reply to | #12405 |
Novice wrote: > Assuming that project Foo has a single package, com.novice.foo and three > classes, hickory, dickory, and dock, class hickory's logger would be > "com.novice.foo.hickory", class dickory's logger would be > "com.novice.foo.dickory" and class dock's logger would be > "com.novice.foo.dock". > > Is that right now? Yes. Only do follow the naming conventions: com.novice.foo.Hickory com.novice.foo.Dickory com.novice.foo.Dock ... > ... Each class is going to be getting it's own logger with > > Logger logger Logger.getLogger(getClass().getName()); > ... > Yes, every class is already in one or another named package and has been > for a long time. I'm still struggling a bit over which classes belong in > the SAME package and which should not. As Patricia said, just make a decision and refactor later if you decide to. > My thinking is that classes in the Common PROJECT should also be in > packages that are distinct from the packages used for Projects Foo or > Bar, which will have names like "com.novice.foo" and "com.novice.bar". Usually. You have to think of the consequences and decide if they're the consequences you intend. > I'm using separate packages now so that > similar things are together. (That just feels like the right thing to do > but so far, most of my "feelings" have been wrong!) It's the right thing to do. Now find a rationale why - there is one, since it is the right thing to do. That way if pressed to explain your feeling you can. > Right. That is gradually sinking in, believe it or not! In fact, I'm just > about ready to replace all of the existing nonsense that I've been doing > with a > > Logger logger = Logger.getLogger(getClass().getName()); > > in all my classes. That's pretty much the idea I'm promoting, save for concerns of appropriate scope as discussed upthread. > So I want to end up with all of my classes in all of my Projects writing > to a single log? No. > Hmm. Yes, I suppose that makes sense. I need to review the whole > "inherit" aspect of logging but I've been thinking of one logger equating > to one log and that's not right, is it? See, the penny is dropping.... A logger is an object that writes to a log. There's no essential reason the ratio should be one to one. Au contraire, just like everything else in Java it's reasonable to expect multiple pointers to point to one thing and multiple writers to write to one output. Let me ask you this. In your favorite windowing OS, don't you have many programs each of them writing to a screen? Don't they all write to the same screen? You don't have a separate monitor for each program, do you? > Lots of loggers but only one log.... Yes, I need to get my head around > that and think of how that works. Maybe rereading that logging overview > will make that sink in.... Or thinking about many arrows hitting one target. ... > The only thing that REALLY bugs me still is that I can't find the darned > log records containing the weekdays that I mentioned elsewhere in the > thread. They're NOT at %h/java%u.log nor at the other place suggested in > the Tracing and Logging document. And THAT is really driving me crazy. I > can't think of anywhere else to look based on anything I've seen in the > references you and others have given me. I _think_ the logging.properties > file is ensuring that a physical log file is being written but maybe it's > messed up in some way to keep it from writing at all. Or from righting > INFO level records. But I don't think that's it. > > If you have any insight into that, you'd really be helping me out. It's > hard to absorb the information you are giving me when my mind keeps > obsessing on where the darned log files are. When I can't find a log file I'm searching for (it follows the rules for finding resources via a classloader, btw), I do a variant of $ find / -name foo.log 2> /dev/null Have you not tried searching your hard drive? -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web