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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-29 23:06 -0800 |
| Message-ID | <jin75c$8ci$1@news.albasani.net> |
| In reply to | #12543 |
Novice wrote: > Lew wrote: >> So taking lists as the example: >> >> List<String> options = new ArrayList<>(); >> >> I declared the 'options' variable as a 'List<String>', not as an >> 'ArrayList<String>'. If I discover that the array-backed list wasn't >> giving me the performance or other implementation-specific behavior I >> need, but a linked list does, I can refactor more easily: >> >> List<String> options = new LinkedList<>(); >> >> The rest of the program, depending only on the "list"ness and not the >> "array"ness, is unharmed. >> >> (What performance differences are there? Excellent question! Pop quiz >> - please answer this post with your answer - where would you find out >> about performance characteristics of 'ArrayList<E>' and >> 'LinkedList<E>'?) I meant where specifically. You didn't show me where. You talked a lot about how you'd go about finding where, but you didn't actually follow your own advice. >> Summary: >> Interface: what to do >> Class: how to do it > > I need to understand what you've said a bit better before I try the pop > quiz ;-) > > It makes perfect sense to me to figure out what a program needs to do > before you worry about how it gets done. You've got to design a house - how > many bedrooms, how many bathrooms, what style of house (ranch or bungalow > or apartment building), etc. etc. - before you choose the exact fixtures. > > But when you talked about designing interfaces, I assumed you meant NEW interfaces. No. I wasn't talking about designing interfaces. I was talking about writing a program. > Your examples seem to be about selecting which of the existing > interfaces - which kind of lists - you wanted. But those kinds already Yes. There's a reason for that. It's because I was talking about selecting which existing interfaces you want to use. > exist so you're really just choosing them, not inventing new ones to do new Right. Precisely. Just so. > things. It would be helpful to me if you also talked about new interfaces > and how those come about at design time. Give me an example of some unit of functionality you'd like to design, in broad terms, and I'll do just that. > By the way, I completely see your point in the examples. I have already > benefited from the same by using Collections. I use more Sets than Lists Why do you use more sets than lists? > and I will often start with a HashSet but if I start using it and find it > doesn't have things in the order I wanted, it's a trivial thing to change > it to another ordering by choosing a TreeSet or LinkedHashSet. That is > REALLY convenient. > > Now that I think about it, I suppose I know enough to tackle the pop quiz > after all. > > I have the feeling that I'm supposed to answer with something like "the > API" or maybe based on something you said in one of your posts. Well, I'm "You're supposed to answer"? What _is_ the answer? "The API" or "something you said" isn't an answer. That's like saying, "Where in the city will I find the post office" and you say, "There's a map somewhere". I am still left unable to mail a letter. > going to "over-answer" the question and say this: Sorry, that's actually under-answering. > I know that the API or the various Java Tutorials (like the one on > Collections) often gives clues about performance and tells you explicitly, What clues? Where? Show me. I asked a specific question about specific classes. > for example, that a HashSet normally performs best and a TreeSet worst with > a LinkedHashSet typically performing almost as well as a HashSet. So that's > obviously a good place to start. "normally"? "performs"? "best"? You described some useful strategies, but let's see what happens when you apply them to 'ArrayList<E>' and 'LinkedList<E>'. And since you brought them up, the three 'Set' implementations you mention. The questions above are to stimulate thought. The questions that follow are for you to answer here. Without asking anyone else, but by research (which you should cite): What are the performance differences (if any! - question every assumption in a question) between: - 'ArrayList<E>' and 'LinkedList<E>'? - 'HashSet<E>', 'TreeSet<E>' and 'LinkedHashSet<E>'? What are the differences between: - 'List<E>' and 'Set<E>'? For your claim that "HashSet normally performs best", define: - "normally" - "performs" - "best" Since you get to define these terms, there might not be exactly a right answer. Instead, justify your definitions to whatever extent you feel they need it. Be careful - justifications like "the standard definition" do require citation of which standard. Have fun. -- 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-03-02 04:33 +0000 |
| Message-ID | <XnsA009F0ADD6694jpnasty@94.75.214.39> |
| In reply to | #12551 |
[snip] > Since you get to define these terms, there might not be exactly a > right answer. Instead, justify your definitions to whatever extent you > feel they need it. Be careful - justifications like "the standard > definition" do require citation of which standard. > > Have fun. > I read this a few hours ago but it will take time to formulate an answer so I'll try to get back to it tomorrow. Sorry for the delay. I've been trying to get a better understanding of error handling today, as well as doing some non-programming stuff. I see more questions in the near future ;-) -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-03-04 23:00 +0000 |
| Message-ID | <XnsA00CB84AA9E0jpnasty@94.75.214.39> |
| In reply to | #12551 |
Lew <noone@lewscanon.com> wrote in news:jin75c$8ci$1@news.albasani.net: > Novice wrote: >> Lew wrote: >>> So taking lists as the example: >>> >>> List<String> options = new ArrayList<>(); >>> >>> I declared the 'options' variable as a 'List<String>', not as an >>> 'ArrayList<String>'. If I discover that the array-backed list wasn't >>> giving me the performance or other implementation-specific behavior >>> I need, but a linked list does, I can refactor more easily: >>> >>> List<String> options = new LinkedList<>(); >>> >>> The rest of the program, depending only on the "list"ness and not >>> the "array"ness, is unharmed. >>> >>> (What performance differences are there? Excellent question! Pop >>> quiz - please answer this post with your answer - where would you >>> find out about performance characteristics of 'ArrayList<E>' and >>> 'LinkedList<E>'?) > > I meant where specifically. You didn't show me where. You talked a lot > about how you'd go about finding where, but you didn't actually follow > your own advice. > I'm finally back! Sorry for the longer-than-expected delay. I had thought your questions were hypothetical, of the "how would you determine such-and-such if you needed to" variety. I didn't realize you literally meant for me to answer :-) Well, let's get on with concrete answers. The ArrayList article in the Java (1.7) API is at this URL: http://docs.oracle.com/javase/7/docs/api/index.html. From there, scroll down in the lower left index window to find ArrayList and click on it; the article appears in the main pane of the browser. With regards to performance, we get various clues in the introduction to the article (the part about the Field Summary), including: "The size, isEmpty, get, set, iterator, and listIterator operations run in constant time. The add operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking). The constant factor is low compared to that for the LinkedList implementation. "Each ArrayList instance has a capacity. The capacity is the size of the array used to store the elements in the list. It is always at least as large as the list size. As elements are added to an ArrayList, its capacity grows automatically. The details of the growth policy are not specified beyond the fact that adding an element has constant amortized time cost. "An application can increase the capacity of an ArrayList instance before adding a large number of elements using the ensureCapacity operation. This may reduce the amount of incremental reallocation." Doing the same thing for LinkedList we find: "All of the operations perform as could be expected for a doubly-linked list. Operations that index into the list will traverse the list from the beginning or the end, whichever is closer to the specified index." That first sentence is a bit evasive if you have no idea how a linked list would perform but that's what it says.... >>> Summary: >>> Interface: what to do >>> Class: how to do it >> >> I need to understand what you've said a bit better before I try the >> pop quiz ;-) >> >> It makes perfect sense to me to figure out what a program needs to do >> before you worry about how it gets done. You've got to design a house >> - how many bedrooms, how many bathrooms, what style of house (ranch >> or bungalow or apartment building), etc. etc. - before you choose the >> exact fixtures. >> >> But when you talked about designing interfaces, I assumed you meant >> NEW interfaces. > > No. I wasn't talking about designing interfaces. I was talking about > writing a program. > Maybe I should have said that that's where I _thought_ you were going because we were in the part of the note where we talked about interfaces and I thought you had more to say on that ;-) >> Your examples seem to be about selecting which of the existing >> interfaces - which kind of lists - you wanted. But those kinds >> already > > Yes. There's a reason for that. It's because I was talking about > selecting which existing interfaces you want to use. > Fair enough. >> exist so you're really just choosing them, not inventing new ones to >> do new > > Right. Precisely. Just so. > >> things. It would be helpful to me if you also talked about new >> interfaces and how those come about at design time. > > Give me an example of some unit of functionality you'd like to design, > in broad terms, and I'll do just that. > I think that would be an interesting exercise. Let's do one that I've already done myself and that you (probably) haven't. I'm sure I'll learn some things by seeing how you approach it. I have a project (that regularly undergoes polishing) to produce resumes. More specifically, it creates various formats of my own resume (and only my own resume.) Each of the resumes I generate contains the exact same information obtained from a single file but I generate it in several formats: an HTML version, a Java applet, an ASCII text version, a PDF version (using iText), and a Word version. I also generate supporting files, including a CSS file for the HTML version of the resume, and a short PDF containing contact information for references. The program that generates the resumes and supporting files is written in Java. The data file that is parsed to create each format of the resume is a Java ResourceBundle of the "list" type. NOw, I'm only producing the resumes in English so I should mention that I am open to the possibility of creating the resume in additional languages - I have a working knowledge of two other (human) languages - so I chose to use a Resource Bundle so that I could easily generate resumes in additional languages. Otherwise, I'd have probably just used a standard text file or more likely a properties file. Given the fact that several resumes containing the same data are being generated there would seem to be obvious opportunities for refactoring and probably at least one interface. This code has gone through various permutations but I've used a single interface with a single method in my existing code. The code works but I'm not at all sure it is designed well. I'd be very curious to get your take on it. I expect that the design has major flaws and I'd like to clean those up once I find out what they are. Does that sound reasonable to you? I'm basically asking you to talk me through the way you would design it knowing what I've told you. Naturally, you're free to ask as many questions as you like to understand what I'm trying to do. >> By the way, I completely see your point in the examples. I have >> already benefited from the same by using Collections. I use more Sets >> than Lists > > Why do you use more sets than lists? > Most of the things I put in collections should not have duplicates so I enforce that via Sets. Naturally, if duplicates are appropriate, I'll use a list. >> and I will often start with a HashSet but if I start using it and >> find it doesn't have things in the order I wanted, it's a trivial >> thing to change it to another ordering by choosing a TreeSet or >> LinkedHashSet. That is REALLY convenient. >> >> Now that I think about it, I suppose I know enough to tackle the pop >> quiz after all. >> >> I have the feeling that I'm supposed to answer with something like >> "the API" or maybe based on something you said in one of your posts. >> Well, I'm > > "You're supposed to answer"? What _is_ the answer? "The API" or > "something you said" isn't an answer. That's like saying, "Where in > the city will I find the post office" and you say, "There's a map > somewhere". I am still left unable to mail a letter. > >> going to "over-answer" the question and say this: > > Sorry, that's actually under-answering. > Yeah, I get that now. >> I know that the API or the various Java Tutorials (like the one on >> Collections) often gives clues about performance and tells you >> explicitly, > > What clues? Where? Show me. I asked a specific question about specific > classes. > Answered above for ArrayList and LinkedList. >> for example, that a HashSet normally performs best and a TreeSet >> worst with a LinkedHashSet typically performing almost as well as a >> HashSet. So that's obviously a good place to start. > > "normally"? "performs"? "best"? > Just a generalization I saw in the tutorial for the Java Collection Classes. Let me get you a reference.... Assuming you're already in the Java 1.7 API, the articles on ArrayList and LinkedList both have this line: "This call is a member of the Java Collections Framework". If I click that, then Tutorial, then Interfaces, then Set Interface, I come to this paragraph which was the basis for my generalization: "The Java platform contains three general-purpose Set implementations: HashSet, TreeSet, and LinkedHashSet. HashSet, which stores its elements in a hash table, is the best-performing implementation; however it makes no guarantees concerning the order of iteration. TreeSet, which stores its elements in a red-black tree, orders its elements based on their values; it is substantially slower than HashSet. LinkedHashSet, which is implemented as a hash table with a linked list running through it, orders its elements based on the order in which they were inserted into the set (insertion- order). LinkedHashSet spares its clients from the unspecified, generally chaotic ordering provided by HashSet at a cost that is only slightly higher." > You described some useful strategies, but let's see what happens when > you apply them to 'ArrayList<E>' and 'LinkedList<E>'. > Answered above (toward the top of this reply). > And since you brought them up, the three 'Set' implementations you > mention. > > The questions above are to stimulate thought. The questions that > follow are for you to answer here. > > Without asking anyone else, but by research (which you should cite): > As above. > What are the performance differences (if any! - question every > assumption in a question) between: > - 'ArrayList<E>' and 'LinkedList<E>'? I've cited the API on this already. Would you like me to paraphrase to show that I understand what they're saying? > - 'HashSet<E>', 'TreeSet<E>' and 'LinkedHashSet<E>'? I've cited the Tutorial on this already. Would you like me to paraphrase to show that I understand what they're saying? > > What are the differences between: > - 'List<E>' and 'Set<E>'? > Functionally, the big difference is the tolerance for duplicates: Sets don't permit duplicates but Lists do. As a guy with a relational database background, I tend to put primary keys on every data structure I conceive which is why I do more Sets than Lists. > For your claim that "HashSet normally performs best", define: > - "normally" > - "performs" > - "best" > That whole claim was basically a paraphrase of the passage from the Collections tutorial cited above. Bloch (I assume he's the one that wrote this tutorial), states clearly that HashSet is the best-performing implementation of the three (HashSet, TreeSet and LinkedHashSet). Since HashSet doesn't guarantee the order of iteration, it is presumably cheaper to build and maintain. Given that people often want data to be in a predictable order, TreeSet is provided but he warns that it is substantially slower, presumably since it has to keep things in order as it constructs the set and that takes more time/effort. LinkedHashSet ends up being sort of a hybrid of the other two by the sounds of it. It is based on a hash table like HashSet but has a linked-list running through it to ensure that elements are kept in the desired order (insertion-order) but, through the miracle of clever programming, apparently only costs slightly more than HashSet, rather than being substantially slower like TreeSet. The paraphrase was a bit sloppy. I shouldn't have said "normally" since it implies that sometimes what I've said in the preceding paragraph isn't true. In fact, I assume that paragraph is ALWAYS true. Basically, if you don't care about the order of the elements of the Set, you'll find HashSet fastest. If you care about the order, LinkedHashSet will be faster than TreeSet. There's nothing to suggest any other factors, such as the size of the entry, has any effect on the performance of the Set implementation. > Since you get to define these terms, there might not be exactly a > right answer. Instead, justify your definitions to whatever extent you > feel they need it. Be careful - justifications like "the standard > definition" do require citation of which standard. > > Have fun. > I await your opinion of my answers. I hope I'm closer to the spirit of what you had in mind this time. Naturally, the other approaches I mentioned are still available but I expect most people would stop with the API and/or tutorial unless they had an especially challenging issue that they were handling. -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-03-04 17:07 -0800 |
| Message-ID | <jj13jl$qre$1@news.albasani.net> |
| In reply to | #12678 |
Novice wrote: > Lew wrote: >> ... > The ArrayList article in the Java (1.7) API is at this URL: > http://docs.oracle.com/javase/7/docs/api/index.html. From there, scroll > down in the lower left index window to find ArrayList and click on it; the > article appears in the main pane of the browser. With regards to > performance, we get various clues in the introduction to the article (the > part about the Field Summary), including: 'ArrayList' has its own URL, also, but yes. > "The size, isEmpty, get, set, iterator, and listIterator operations run in I'd've been satisfied with just the URL. But your answers are exactly right. > That first sentence is a bit evasive if you have no idea how a linked list > would perform but that's what it says.... How does a linked list perform? >>>> Summary: >>>> Interface: what to do >>>> Class: how to do it ... >> Give me an example of some unit of functionality you'd like to design, >> in broad terms, and I'll do just that. >> > I think that would be an interesting exercise. Let's do one that I've > already done myself and that you (probably) haven't. I'm sure I'll learn > some things by seeing how you approach it. > > I have a project (that regularly undergoes polishing) to produce resumes. > More specifically, it creates various formats of my own resume (and only my > own resume.) Each of the resumes I generate contains the exact same > information obtained from a single file but I generate it in several > formats: an HTML version, a Java applet, an ASCII text version, a PDF > version (using iText), and a Word version. I also generate supporting > files, including a CSS file for the HTML version of the resume, and a short > PDF containing contact information for references. What are the overall modules? For example: "Obtain resume from single file", "Export to format X", "Generate references document", ... > The program that generates the resumes and supporting files is written in > Java. The data file that is parsed to create each format of the resume is a > Java ResourceBundle of the "list" type. NOw, I'm only producing the resumes Sorry, "list" type? > in English so I should mention that I am open to the possibility of > creating the resume in additional languages - I have a working knowledge of > two other (human) languages - so I chose to use a Resource Bundle so that I > could easily generate resumes in additional languages. Otherwise, I'd have > probably just used a standard text file or more likely a properties file. > > Given the fact that several resumes containing the same data are being > generated there would seem to be obvious opportunities for refactoring and > probably at least one interface. This code has gone through various > permutations but I've used a single interface with a single method in my > existing code. The code works but I'm not at all sure it is designed well. What interface? What method? > I'd be very curious to get your take on it. I expect that the design has > major flaws and I'd like to clean those up once I find out what they are. > > Does that sound reasonable to you? I'm basically asking you to talk me > through the way you would design it knowing what I've told you. Naturally, > you're free to ask as many questions as you like to understand what I'm > trying to do. We'll go step by step. >> Why do you use more sets than lists? >> > Most of the things I put in collections should not have duplicates so I > enforce that via Sets. Naturally, if duplicates are appropriate, I'll use a > list. Exactly right. ... >>> for example, that a HashSet normally performs best and a TreeSet >>> worst with a LinkedHashSet typically performing almost as well as a >>> HashSet. So that's obviously a good place to start. >> >> "normally"? "performs"? "best"? >> > Just a generalization I saw in the tutorial for the Java Collection > Classes. Let me get you a reference.... > > Assuming you're already in the Java 1.7 API, the articles on ArrayList and > LinkedList both have this line: "This call is a member of the Java > Collections Framework". If I click that, then Tutorial, then Interfaces, > then Set Interface, I come to this paragraph which was the basis for my > generalization: > > "The Java platform contains three general-purpose Set implementations: > HashSet, TreeSet, and LinkedHashSet. HashSet, which stores its elements in > a hash table, is the best-performing implementation; however it makes no > guarantees concerning the order of iteration. TreeSet, which stores its > elements in a red-black tree, orders its elements based on their values; it > is substantially slower than HashSet. LinkedHashSet, which is implemented > as a hash table with a linked list running through it, orders its elements > based on the order in which they were inserted into the set (insertion- > order). LinkedHashSet spares its clients from the unspecified, generally > chaotic ordering provided by HashSet at a cost that is only slightly > higher." ... >> The questions above are to stimulate thought. The questions that >> follow are for you to answer here. You did it in the opposite order, answering above and thinking below. That's fine. >> What are the performance differences (if any! - question every >> assumption in a question) between: >> - 'ArrayList<E>' and 'LinkedList<E>'? > > I've cited the API on this already. Would you like me to paraphrase to show > that I understand what they're saying? No, I wanted you to answer down here in the first place. >> - 'HashSet<E>', 'TreeSet<E>' and 'LinkedHashSet<E>'? > > I've cited the Tutorial on this already. Would you like me to paraphrase to > show that I understand what they're saying? Unnecessary. Just answer the questions below. And I am not so sure you do, completely, yet. >> For your claim that "HashSet normally performs best", define: >> - "normally" >> - "performs" >> - "best" >> ... > Basically, if you don't care about the order of the elements of the Set, > you'll find HashSet fastest. If you care about the order, LinkedHashSet > will be faster than TreeSet. Did you notice that "the order" is different between 'LinkedHashSet' and 'TreeSet'? > There's nothing to suggest any other factors, such as the size of the > entry, has any effect on the performance of the Set implementation. On what basis should you choose which of these three 'Set' implementations to use at any given point? -- 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-03-05 15:33 +0000 |
| Message-ID | <XnsA00D6C86E4162jpnasty@94.75.214.39> |
| In reply to | #12679 |
Lew <noone@lewscanon.com> wrote in news:jj13jl$qre$1@news.albasani.net: > Novice wrote: >> Lew wrote: >>> ... > >> The ArrayList article in the Java (1.7) API is at this URL: >> http://docs.oracle.com/javase/7/docs/api/index.html. From there, >> scroll down in the lower left index window to find ArrayList and >> click on it; the article appears in the main pane of the browser. >> With regards to performance, we get various clues in the introduction >> to the article (the part about the Field Summary), including: > > 'ArrayList' has its own URL, also, but yes. > >> "The size, isEmpty, get, set, iterator, and listIterator operations >> run in > > I'd've been satisfied with just the URL. But your answers are exactly > right. > I intended to just give the direct URL but the URL in the browser doesn't change when I click on things in the API; it just says "http://docs.oracle.com/javase/7/docs/api/index.html" no matter what I click on. The same thing happens in Chrome so I know it's not just a Firefox issue. Apparently, the folks at Oracle don't want us to know the direct URLs to specific pages. >> That first sentence is a bit evasive if you have no idea how a linked >> list would perform but that's what it says.... > > How does a linked list perform? > Given the additional infrastructure beyond what is in a regular hash set, I have to assume it's slower than a HashSet. How much slower, I don't know. If I were writing code that involved very large sets - probably at least thousands of entries - I could research that during the design phase and try to come up with a calculation to see if the difference might be appreciable. Or I could wait until volume testing revealed an issue, then possibly rethink the linked list in favor of a hash set if the iteration sequence was not terribly important to the customer. >>>>> Summary: >>>>> Interface: what to do >>>>> Class: how to do it > ... >>> Give me an example of some unit of functionality you'd like to >>> design, in broad terms, and I'll do just that. >>> >> I think that would be an interesting exercise. Let's do one that I've >> already done myself and that you (probably) haven't. I'm sure I'll >> learn some things by seeing how you approach it. >> >> I have a project (that regularly undergoes polishing) to produce >> resumes. More specifically, it creates various formats of my own >> resume (and only my own resume.) Each of the resumes I generate >> contains the exact same information obtained from a single file but I >> generate it in several formats: an HTML version, a Java applet, an >> ASCII text version, a PDF version (using iText), and a Word version. >> I also generate supporting files, including a CSS file for the HTML >> version of the resume, and a short PDF containing contact information >> for references. > > What are the overall modules? For example: "Obtain resume from single > file", "Export to format X", "Generate references document", ... > At the moment, I have a main program that simply generates each document in turn. It's called ResumeFileGenerator. Its constructor gets the resource bundle that drives the creation of the resumes. Each resume format is generated by a separate class and is passed an object that represents the data needed in the resume and the path and file name to be generated by that class. Then, the supporting documents are each generated by their own separate classes. They too are told the path and file name that should be generated but are not passed the resume object since they don't need it. >> The program that generates the resumes and supporting files is >> written in Java. The data file that is parsed to create each format >> of the resume is a Java ResourceBundle of the "list" type. NOw, I'm >> only producing the resumes > > Sorry, "list" type? > Sorry, that was sloppy shorthanding on my part. I meant the ResourceBundles that are based on ListResourceBundles, as shown at http://docs.oracle.com/javase/tutorial/i18n/resbundle/list.html, versus the "text" and "message" types which are basically properties files. Some of my data consists of arrays like the list of editors I've used and the list of word processing programs I'm familiar with so the simpler property file type resource bundles don't work well for that. >> in English so I should mention that I am open to the possibility of >> creating the resume in additional languages - I have a working >> knowledge of two other (human) languages - so I chose to use a >> Resource Bundle so that I could easily generate resumes in additional >> languages. Otherwise, I'd have probably just used a standard text >> file or more likely a properties file. >> >> Given the fact that several resumes containing the same data are >> being generated there would seem to be obvious opportunities for >> refactoring and probably at least one interface. This code has gone >> through various permutations but I've used a single interface with a >> single method in my existing code. The code works but I'm not at all >> sure it is designed well. > > What interface? What method? > It's an interface I created as opposed to one that is in the API. It is called ResumeFileWriter and has one empty method in it called writeResume. It has two parameters, a String that identifies the path and name of the file to be written and a Resume object that refers to the data contained in the Resource Bundle. Each of the classes that writes an actual resume (as opposed to a supporting file) implements it. It's entirely likely that this interface should do a lot more than it currently does. That's why I'm very curious to get your take on this. I've also got an abstract class called ResumeFileCreator. It has four concrete methods: deleteFile, openOutputFile, closeOutputFile and getGeneratedBy (which simply generates a string containing the name of a class and the current date and time which I use to create comments in each of the files that are written). Each of the classes that writes a resume or supporting file subclasses ResumeFileCreator. >> I'd be very curious to get your take on it. I expect that the design >> has major flaws and I'd like to clean those up once I find out what >> they are. >> >> Does that sound reasonable to you? I'm basically asking you to talk >> me through the way you would design it knowing what I've told you. >> Naturally, you're free to ask as many questions as you like to >> understand what I'm trying to do. > > We'll go step by step. > Works for me :-) >>> Why do you use more sets than lists? >>> >> Most of the things I put in collections should not have duplicates so >> I enforce that via Sets. Naturally, if duplicates are appropriate, >> I'll use a list. > > Exactly right. > > ... >>>> for example, that a HashSet normally performs best and a TreeSet >>>> worst with a LinkedHashSet typically performing almost as well as a >>>> HashSet. So that's obviously a good place to start. >>> >>> "normally"? "performs"? "best"? >>> >> Just a generalization I saw in the tutorial for the Java Collection >> Classes. Let me get you a reference.... >> >> Assuming you're already in the Java 1.7 API, the articles on >> ArrayList and LinkedList both have this line: "This call is a member >> of the Java Collections Framework". If I click that, then Tutorial, >> then Interfaces, then Set Interface, I come to this paragraph which >> was the basis for my generalization: >> >> "The Java platform contains three general-purpose Set >> implementations: HashSet, TreeSet, and LinkedHashSet. HashSet, which >> stores its elements in a hash table, is the best-performing >> implementation; however it makes no guarantees concerning the order >> of iteration. TreeSet, which stores its elements in a red-black tree, >> orders its elements based on their values; it is substantially slower >> than HashSet. LinkedHashSet, which is implemented as a hash table >> with a linked list running through it, orders its elements based on >> the order in which they were inserted into the set (insertion- >> order). LinkedHashSet spares its clients from the unspecified, >> generally chaotic ordering provided by HashSet at a cost that is only >> slightly higher." > ... > >>> The questions above are to stimulate thought. The questions that >>> follow are for you to answer here. > > You did it in the opposite order, answering above and thinking below. > That's fine. > >>> What are the performance differences (if any! - question every >>> assumption in a question) between: >>> - 'ArrayList<E>' and 'LinkedList<E>'? >> >> I've cited the API on this already. Would you like me to paraphrase >> to show that I understand what they're saying? > > No, I wanted you to answer down here in the first place. > Sorry about that. >>> - 'HashSet<E>', 'TreeSet<E>' and 'LinkedHashSet<E>'? >> >> I've cited the Tutorial on this already. Would you like me to >> paraphrase to show that I understand what they're saying? > > Unnecessary. Just answer the questions below. And I am not so sure you > do, completely, yet. > >>> For your claim that "HashSet normally performs best", define: >>> - "normally" >>> - "performs" >>> - "best" >>> ... > >> Basically, if you don't care about the order of the elements of the >> Set, you'll find HashSet fastest. If you care about the order, >> LinkedHashSet will be faster than TreeSet. > > Did you notice that "the order" is different between 'LinkedHashSet' > and 'TreeSet'? > >> There's nothing to suggest any other factors, such as the size of the >> entry, has any effect on the performance of the Set implementation. > > On what basis should you choose which of these three 'Set' > implementations to use at any given point? > Good point. I should have mentioned that TreeSet puts the entries in order by their values (what I'd call primary key sequence in database terms) while LinkedHashSet stores them in insertion order. Obviously, that is going to be a major factor in which you choose. I tend to use TreeSets because I may not be getting the entries in order by value but I usually want them in order by their value, not by the insertion sequence. But if insertion sequence is important to me, then I'll look seriously at LinkedHashSet. I'm not typically dealing with large sets of thousands or millions of entries so I tend not to care much about the performance of the set. I know that performance is going to be a bigger issue with large sets. -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2012-03-05 08:38 -0800 |
| Subject | JavaDoc linking (Was: Aspect questions?) |
| Message-ID | <PZ55r.26404$2q1.19251@newsfe06.iad> |
| In reply to | #12709 |
On 3/5/12 7:33 AM, Novice wrote: > Lew<noone@lewscanon.com> wrote in news:jj13jl$qre$1@news.albasani.net: >> 'ArrayList' has its own URL, also, but yes. > I intended to just give the direct URL but the URL in the browser doesn't > change when I click on things in the API; it just says > "http://docs.oracle.com/javase/7/docs/api/index.html" no matter what I > click on. Hint. Click on No Frames first. That leads to <http://docs.oracle.com/javase/7/docs/api/java/util/ArrayList.html> You can then click on Frames again, which leads to: <http://docs.oracle.com/javase/7/docs/api/index.html?java/util/ArrayList.html> Which will load the main page, but redirect the main frame to the ArrayList.html. Generally when pointing out JavaDocs, either form is appropriate, however you can't use "#" to point to a specific section when using the Frames version. For example, if I wanted to point you to "contains" in ArrayList, I could use <http://docs.oracle.com/javase/7/docs/api/java/util/ArrayList.html#contains%28java.lang.Object%29> However, I have never been able to construct a "Frames" url that does the right thing. Hopefully this helps you and others in the future.
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-03-05 17:40 +0000 |
| Subject | Re: JavaDoc linking (Was: Aspect questions?) |
| Message-ID | <XnsA00D820BB8F8Ejpnasty@94.75.214.39> |
| In reply to | #12714 |
Daniel Pitts <newsgroup.nospam@virtualinfinity.net> wrote in news:PZ55r.26404$2q1.19251@newsfe06.iad: > On 3/5/12 7:33 AM, Novice wrote: >> Lew<noone@lewscanon.com> wrote in >> news:jj13jl$qre$1@news.albasani.net: >>> 'ArrayList' has its own URL, also, but yes. >> I intended to just give the direct URL but the URL in the browser >> doesn't change when I click on things in the API; it just says >> "http://docs.oracle.com/javase/7/docs/api/index.html" no matter what >> I click on. > Hint. Click on No Frames first. > > That leads to > <http://docs.oracle.com/javase/7/docs/api/java/util/ArrayList.html> > > You can then click on Frames again, which leads to: > > <http://docs.oracle.com/javase/7/docs/api/index.html?java/util/ArrayLis > t.html> > > Which will load the main page, but redirect the main frame to the > ArrayList.html. Generally when pointing out JavaDocs, either form is > appropriate, however you can't use "#" to point to a specific section > when using the Frames version. For example, if I wanted to point you > to "contains" in ArrayList, I could use > > <http://docs.oracle.com/javase/7/docs/api/java/util/ArrayList.html#cont > ains%28java.lang.Object%29> > > However, I have never been able to construct a "Frames" url that does > the right thing. > > Hopefully this helps you and others in the future. > Thanks, Daniel. It's a bit awkward - and not very intuitive - but that's not your fault :-) It gets me where I want to be ;-) -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2012-03-05 21:25 -0800 |
| Subject | Re: JavaDoc linking (Was: Aspect questions?) |
| Message-ID | <vZKdnXK7otRaAsjSnZ2dnUVZ_qadnZ2d@earthlink.com> |
| In reply to | #12714 |
On 3/5/2012 8:38 AM, Daniel Pitts wrote: > On 3/5/12 7:33 AM, Novice wrote: >> Lew<noone@lewscanon.com> wrote in news:jj13jl$qre$1@news.albasani.net: >>> 'ArrayList' has its own URL, also, but yes. >> I intended to just give the direct URL but the URL in the browser doesn't >> change when I click on things in the API; it just says >> "http://docs.oracle.com/javase/7/docs/api/index.html" no matter what I >> click on. > Hint. Click on No Frames first. > > That leads to > <http://docs.oracle.com/javase/7/docs/api/java/util/ArrayList.html> > > You can then click on Frames again, which leads to: > > <http://docs.oracle.com/javase/7/docs/api/index.html?java/util/ArrayList.html> ... An alternative, at least on Firefox and I assume on other browsers, is to right click in the main frame and select "This frame" then "Open frame in new tab" or "new window". The new tab or window can be used to construct links and then closed. I find it more convenient than switching my working tab in and out of frames, but YMMV. Patricia
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-03-06 17:23 -0500 |
| Subject | Re: JavaDoc linking (Was: Aspect questions?) |
| Message-ID | <4f568e60$0$295$14726298@news.sunsite.dk> |
| In reply to | #12727 |
On 3/6/2012 12:25 AM, Patricia Shanahan wrote: > On 3/5/2012 8:38 AM, Daniel Pitts wrote: >> On 3/5/12 7:33 AM, Novice wrote: >>> Lew<noone@lewscanon.com> wrote in news:jj13jl$qre$1@news.albasani.net: >>>> 'ArrayList' has its own URL, also, but yes. >>> I intended to just give the direct URL but the URL in the browser >>> doesn't >>> change when I click on things in the API; it just says >>> "http://docs.oracle.com/javase/7/docs/api/index.html" no matter what I >>> click on. >> Hint. Click on No Frames first. >> >> That leads to >> <http://docs.oracle.com/javase/7/docs/api/java/util/ArrayList.html> >> >> You can then click on Frames again, which leads to: >> >> <http://docs.oracle.com/javase/7/docs/api/index.html?java/util/ArrayList.html> >> > ... > > An alternative, at least on Firefox and I assume on other browsers, is > to right click in the main frame and select "This frame" then "Open > frame in new tab" or "new window". The new tab or window can be used to > construct links and then closed. > > I find it more convenient than switching my working tab in and out of > frames, but YMMV. I do that all the time as well. Arne
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-03-05 23:45 -0800 |
| Message-ID | <jj4faj$c37$1@news.albasani.net> |
| In reply to | #12709 |
Novice wrote: > I intended to just give the direct URL but the URL in the browser doesn't > change when I click on things in the API; it just says > "http://docs.oracle.com/javase/7/docs/api/index.html" no matter what I context-click (right-click for right-handers) on the link. It raises a menu which includes an option to copy the URL into the clipboard, thus: <http://docs.oracle.com/javase/7/docs/api/java/util/List.html> That's with frames on. I like the frames. > click on. The same thing happens in Chrome so I know it's not just a > Firefox issue. Apparently, the folks at Oracle don't want us to know the > direct URLs to specific pages. It's not anyone's issue. -- 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-03-06 06:03 -0400 |
| Message-ID | <rhl5r.25383$Ai4.18163@newsfe18.iad> |
| In reply to | #12728 |
On 12-03-06 03:45 AM, Lew wrote: > Novice wrote: >> I intended to just give the direct URL but the URL in the browser doesn't >> change when I click on things in the API; it just says >> "http://docs.oracle.com/javase/7/docs/api/index.html" no matter what I > > context-click (right-click for right-handers) on the link. It raises a > menu which includes an option to copy the URL into the clipboard, thus: > <http://docs.oracle.com/javase/7/docs/api/java/util/List.html> > > That's with frames on. I like the frames. > >> click on. The same thing happens in Chrome so I know it's not just a >> Firefox issue. Apparently, the folks at Oracle don't want us to know the >> direct URLs to specific pages. > > It's not anyone's issue. > Not with a choice between frames and no frames it's not an issue, no. I can't remember for the life of me whether Javadoc has provided the frames/no-frames option since Day One, but I suspect it has...in which case no problem. AHS -- -- Gaiety is the most outstanding feature of the Soviet Union. Josef Stalin, November 1935
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-03-06 21:05 -0800 |
| Message-ID | <jj6qbg$s4k$1@news.albasani.net> |
| In reply to | #12732 |
Arved Sandstrom wrote: > Lew wrote: >> Novice wrote: >>> I intended to just give the direct URL but the URL in the browser doesn't >>> change when I click on things in the API; it just says >>> "http://docs.oracle.com/javase/7/docs/api/index.html" no matter what I >> >> context-click (right-click for right-handers) on the link. It raises a >> menu which includes an option to copy the URL into the clipboard, thus: >> <http://docs.oracle.com/javase/7/docs/api/java/util/List.html> >> >> That's with frames on. I like the frames. >> >>> click on. The same thing happens in Chrome so I know it's not just a >>> Firefox issue. Apparently, the folks at Oracle don't want us to know the >>> direct URLs to specific pages. >> >> It's not anyone's issue. >> > Not with a choice between frames and no frames it's not an issue, no. I > can't remember for the life of me whether Javadoc has provided the > frames/no-frames option since Day One, but I suspect it has...in which > case no problem. In the specific question at hand of copying the link's URL to the clipboard, the presence or absence of frames is immaterial. You can copy the link either way. -- 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:11 -0500 |
| Message-ID | <4f51459e$0$286$14726298@news.sunsite.dk> |
| In reply to | #12436 |
On 2/27/2012 12:27 PM, Novice wrote: > Lew<noone@lewscanon.com> wrote in news:jif4sl$uon$1@news.albasani.net: > >> Novice wrote: >>> I actually split my Common project the other day into two parts. I >>> left only the code that I consider polished and (more or less) >>> correct in Common and moved all the stuff that is still crude and >>> needs improving to a new project called Common Candidate. The latter >>> is far bigger! >>> >>> But Common itself contains 9 classes in package com.novice.common, 8 >>> classes in package com.novice.common.lookups, 3 classes in >>> com.novice.common.menus, 2 classes in com.novice.common.prefs, and 18 >>> classes in com.novice.common.utilities. >> >> The number isn't what's important. It's how related the types (not >> just classes - you had better gosh-darned well have some interfaces in >> there!) It's the relatedness of the types. Types in the same package >> are closely related to each other. Those in different packages aren't. >> It's how related the types should be that determines the designer's >> choice of which package holds them. >> > Then I'm definitely bundling things incorrectly. The classes in my > package are not typically closely related. For utility style classes the relationship is more that they share characteristics of being utility style classes. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-03-02 17:09 -0500 |
| Message-ID | <4f51452c$0$286$14726298@news.sunsite.dk> |
| In reply to | #12416 |
On 2/27/2012 12:12 AM, Novice wrote: > Arne Vajhøj<arne@vajhoej.dk> wrote in news:4f4ac151$0$291$14726298 > @news.sunsite.dk: > > [snip] > > I forgot to answer this part of your post in my other reply. > >>> >>> I'm currently grouping mine on a more-or-less functional basis. If > the >>> class is essentially just a table lookup or enum, then it goes in the >>> com.novice.common.lookups package. If it is a utility, it goes into >>> com.novice.common.utilities. And so forth. >> >> That is general question not specific to logging or AOP. >> > You're absolutely right. This is a bit of a sidetrack. I think I need to > be sure I've structured my packages correctly in order to do a good job > with this. > >> You need a good structure of your classes and source code. >> > Agreed. I'm trying to figure out the best approach. > >> A key factor in the decision between com.novice.common and >> com.novice.common.xxxx must be the number of classes. >> >> Do you have so many classes that it makes sense to split up? >> > I'm not sure what "so many" means in this case ;-) > > I actually split my Common project the other day into two parts. I left > only the code that I consider polished and (more or less) correct in > Common and moved all the stuff that is still crude and needs improving to > a new project called Common Candidate. The latter is far bigger! > > But Common itself contains 9 classes in package com.novice.common, 8 > classes in package com.novice.common.lookups, 3 classes in > com.novice.common.menus, 2 classes in com.novice.common.prefs, and 18 > classes in com.novice.common.utilities. > > The resource bundles for each package are in separate packages that have > Resources as the last qualifier, e.g. > com.novice.common.utilities.Resources. I have the impression, perhaps > mistaken, that resource bundles are supposed to be in different packages > than the classes they support.I don't remember where I got that; I think > it was a newsgroup post a few years ago but it could have been in one of > the online magazines.... > > I have no idea if this is a reasonable approach. Maybe this should all be > simplified so that all of those common classes and enums and resource > bundles are in one package together. Or just two, one for classes and > enums and the other for resource bundles. > > Everything in the Common project is something I use regularly in various > projects or that I expect to use regularly. > > The Commons Candidate project has quite a bit more code than the Common > project and is organized the same way with the same package names (and > maybe an additional package or two where none of the members are ready > for the Common project.) Some of the members of that project don't belong > there because they are just snippets that I've downloaded for learning > purposes or simple sandbox code where I'm trying something out. It needs > to be moved elsewhere but that's not a priority for me right now. But the > bulk of it has the potential to go to the Common project as something I'd > use regularly. > > I'd like to start the process of doing things correctly with my current > project and Common so anything you can tell me about organizing things > would be appreciated. No alarm bells ringing here. Arne
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2012-02-26 23:43 +0000 |
| Message-ID | <jieg2n$beo$1@localhost.localdomain> |
| In reply to | #12381 |
On Sun, 26 Feb 2012 21:08:49 +0000, Novice wrote: > So, with respect to my common classes, should they all be in one big > package, like com.novice.common? Or is it better to group them on some > basis so that different types of common modules are in their own > packages? If grouping them is a good idea, what's the best way to group > them? > I'd say generally yes, unless you see a definite reason to put another (set of) class(es) in a separate package. Example: My common set forms the org.gregorie.environ package because I regard these as setting an environment for the stuff I write. However, I also do a bit of image manipulation and found I was writing repetitive common code in this area, so that got refactored as classes in the org.gregorie.image package. And so forth.... Any time you find this approach puts a class where you don't expect to find it, consider changing your package structure. Its helpful if your 'common' package only contains classes that are likely to be useful for any program you write (e.g logging and command line parsing) and that your other packages contain classes that are often used together. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-27 05:20 +0000 |
| Message-ID | <XnsA0064B71D1BBjpnasty@94.75.214.39> |
| In reply to | #12395 |
Martin Gregorie <martin@address-in-sig.invalid> wrote in news:jieg2n$beo$1@localhost.localdomain: > On Sun, 26 Feb 2012 21:08:49 +0000, Novice wrote: > >> So, with respect to my common classes, should they all be in one big >> package, like com.novice.common? Or is it better to group them on >> some basis so that different types of common modules are in their own >> packages? If grouping them is a good idea, what's the best way to >> group them? >> > I'd say generally yes, unless you see a definite reason to put another > (set of) class(es) in a separate package. Example: > > My common set forms the org.gregorie.environ package because I regard > these as setting an environment for the stuff I write. However, I also > do a bit of image manipulation and found I was writing repetitive > common code in this area, so that got refactored as classes in the > org.gregorie.image package. And so forth.... > > Any time you find this approach puts a class where you don't expect to > find it, consider changing your package structure. Its helpful if your > 'common' package only contains classes that are likely to be useful > for any program you write (e.g logging and command line parsing) and > that your other packages contain classes that are often used together. > I've really struggled with this. I have things set up a certain way now but I'm constantly second-guessing myself and wondering if its the best way to do things. For instance, I've got some utilities classes and I put them altogether in a single package. But they are a mix of very different kinds of utilities. Some deal with String manipulation, some with dates, some with databases, etc. etc. Sometimes I wonder if I should take utilities that deal with dates and group them with lookup classes that deal with dates rather than group them on the basis of them being a utility or lookup. After all "utility" is not something I could easily define in a satisfying way and "lookup" is similarly unsatisfying. Thanks for sharing your views on this, Martin! -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2012-02-26 21:32 -0800 |
| Message-ID | <zfadnTejHuD1iNbSnZ2dnUVZ_qGdnZ2d@earthlink.com> |
| In reply to | #12417 |
Novice wrote: ... > I've really struggled with this. I have things set up a certain way now > but I'm constantly second-guessing myself and wondering if its the best > way to do things. Are you designing an interface that will be expensive to change later? If not, my advice is to not second-guess yourself. If there is something seriously wrong with how you have the code organized now, it will become obvious during program maintenance. Refactor then. Especially if you have perfectionist tendencies, it is very easy to spend far more time and energy thinking about decisions than they are worth. I am very, very familiar with that problem. :-) Patricia
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-27 17:36 +0000 |
| Message-ID | <XnsA006816047F7Fjpnasty@94.75.214.39> |
| In reply to | #12420 |
Patricia Shanahan <pats@acm.org> wrote in news:zfadnTejHuD1iNbSnZ2dnUVZ_qGdnZ2d@earthlink.com: > Novice wrote: > ... >> I've really struggled with this. I have things set up a certain way now >> but I'm constantly second-guessing myself and wondering if its the best >> way to do things. > > Are you designing an interface that will be expensive to change later? > No. I'm just trying to figure out the best way to group the code in my Common project, the stuff that gets used by many of the other projects. > If not, my advice is to not second-guess yourself. If there is something > seriously wrong with how you have the code organized now, it will become > obvious during program maintenance. Refactor then. > I am chronic about second-guessing myself. I suppose I've never had a lot of encouragement of the "you're brilliant" kind along the way ;-) > Especially if you have perfectionist tendencies, it is very easy to > spend far more time and energy thinking about decisions than they are > worth. I am very, very familiar with that problem. :-) > At least you know what you're doing! I have perfectionist tendencies without really being sure what I'm doing; try finding perfection when you don't really have a clear picture of what it is! :-) I don't really see packages as that big a deal though. Whether I import one or five to twenty-five in a given class doesn't seem that important though. More packages probably makes the Javadocs more impressive looking at first glance but if the underlying code doesn't make sense, then it's all nonsense anyways.... -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2012-02-27 13:18 -0500 |
| Message-ID | <jighd0$jgl$1@dont-email.me> |
| In reply to | #12437 |
On 02/27/2012 12:36 PM, Novice wrote: > At least you know what you're doing! I have perfectionist tendencies > without really being sure what I'm doing; try finding perfection when you > don't really have a clear picture of what it is! :-) Look at other projects, lots of them. > I don't really see packages as that big a deal though. Whether I import > one or five to twenty-five in a given class doesn't seem that important > though. More packages probably makes the Javadocs more impressive looking > at first glance but if the underlying code doesn't make sense, then it's > all nonsense anyways.... > You need to develop your own sense of order and beauty, no one here can give you one.
[toc] | [prev] | [next] | [standalone]
| From | Jeff Higgins <jeff@invalid.invalid> |
|---|---|
| Date | 2012-02-27 14:05 -0500 |
| Message-ID | <jigk6b$5h4$1@dont-email.me> |
| In reply to | #12439 |
On 02/27/2012 01:18 PM, Jeff Higgins wrote: > On 02/27/2012 12:36 PM, Novice wrote: >> At least you know what you're doing! I have perfectionist tendencies >> without really being sure what I'm doing; try finding perfection when you >> don't really have a clear picture of what it is! :-) > > Look at other projects, lots of them. > >> I don't really see packages as that big a deal though. Whether I import >> one or five to twenty-five in a given class doesn't seem that important >> though. More packages probably makes the Javadocs more impressive looking >> at first glance but if the underlying code doesn't make sense, then it's >> all nonsense anyways.... >> > You need to develop your own sense of order and beauty, no one here can > give you one. > > Look at the Eclipse API Specification: <http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/api/overview-summary.html> Do you find it orderly and beauteous? Why? Why not? An exercise: Write a package description and specification for each of the packages in your project. Use the Eclipse API Specification as a template. Package org.eclipse.core.commands Description Application programming interfaces for commands and handlers. Package Specification This package provides API and implementation classes to define abstract pieces of functionality. These pieces of functionality are intended to provide a common way for plug-ins and the user interface to communicate potential behaviour. This package is designed so that its elements can be public and dynamic. That is, elements in this package can appear and disappear over the life of the application. Package org.eclipse.core.commands.common Description Application programming interfaces for common base classes. Package Specification This package provides some common base classes and exceptions that are used in one or more packages elsewhere. Nothing in this package is intended to be directly subclassed, or used. The code here only supports code in other packages. Package org.eclipse.core.commands.contexts Description Application programming interfaces for contexts. Package Specification This package provides API and implementation classes to define abstract representations of application state. These representations of application state can be used as an abstraction of the event-listener model -- where different sections of code do not (or cannot) refer to each directly. This package is designed so that its elements can be public and dynamic. That is, elements in this package can appear and disappear over the life of the application. Package org.eclipse.core.commands.operations Description Classes for the creation of undoable operations which can be added to an operations history and later be undone and redone. Package Specification An undoable operation is a unit of work that can be executed, undone, and redone. Operations can be added to an operation history so that they can later be undone and redone according to the undo model for an application. Operations may be assigned one or more undo contexts which can be used to filter the available operations for undo or redo in the operation history. Clients may choose to provide undo and redo function for all operations in a history, or only for a particular undo context in that history. Operation histories may be configured with an operation approver so that applications can enforce any desired undo model, such as strict linear (LIFO) undo. This package provides the definition and a basic implementation for operations, undo contexts, histories, and operation approvers.
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web