Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!border3.nntp.ams.giganews.com!Xl.tags.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!local2.nntp.ams.giganews.com!nntp.bt.com!news.bt.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 29 Dec 2012 09:12:12 -0600 From: "Chris Uppal" Newsgroups: comp.lang.java.programmer References: Subject: Re: Generic JList and ListCellRenderer? Date: Sat, 29 Dec 2012 15:11:55 -0000 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 X-RFC2646: Format=Flowed; Response Message-ID: Lines: 60 X-Usenet-Provider: http://www.giganews.com X-AuthenticatedUsername: NoAuthUser X-Trace: sv3-I0p3nx5I0PJ1m89jG/zQ95mHYESRsUgqYJ6MAlNRwl3hmhnE1ehiW5Fn9/MmUKg8ih1GPCknr4ziCha!VJOz5qghczqEpjjW+PV07+32upMx17zr9DVSNc1hfzFbIyfiRFTDYSqp4wzcZIrpcaoAmerDFJU= X-Complaints-To: abuse@btinternet.com X-DMCA-Complaints-To: abuse@btinternet.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 4267 Xref: csiph.com comp.lang.java.programmer:20801 Knute Johnson wrote: > I've been trying to clean up some really old code and I've hit some > snags. I've got several modified JLists and the ListCellRenderers for > them and thought it would make sense to have generic classes that could > be extended for different data types that need to be displayed. The > example below displays InetAddresses in the JList. I've got another > implementation of JList that does a lot more than what this one does but > I wanted to keep this example simple and focus on the ListCellRenderer. Without knowing what directions you intend/expect to extend the code it's a little difficult to make sensible suggestions. So, proceeding with due absence of sense... I don't see what the clazz variable (and the associated instance checks) are buying you. You could try removing them and see if that makes your code come to life. It would certainly remove some of the "kludgy" smell. If that doesn't help, then it may be that you're being bothered by the way that ListCellRenderer has (so to speak) too many responsibilities -- it's simultaneously about /how/ something is displayed and about /what/ is displayed. So (this is only my guess, of course) you're being pulled in two directions: on the one hand your /how/ is pretty much fixed and you want to use nice generic code for it whatever the types of the values, but the /what/ is not generic and will change according to each application. You are being required to do rampant subclassing of something that shouldn't /need/ subclassing. If that sounds as if it might relate to your problem, you could introduce a new kind of object who's only responsibility is to take a value, the element of the List (of type Object -- unless you want to mess with generics), and return a String which is to be the contents of the cell. It might also have a parallel method which takes the (same) List element and returns an Icon (or null). The new object would have appropriate subclasses for InetAddress etc. (which might or might not appear formally as separate classes in your source -- you could instead use anonymous classes to make the getTextFor() and getIconFor() methods "pluggable"). So then you have just one subclass of ListCellRenderer which holds an instance of [a subclass of] this new class (instead of the clazz variable), and which always blindly uses that to "fetch" the appropriate String and/or Icon for use for each cell. It's difficult to think of a good name for the new kind of object (and it's subclasses), but in this case I don't think that's the danger sign it normally would be: the reason that it's difficult to find a name is that the obvious names (some variant on "Renderer") are already taken. "TextSupplier" perhaps (or ContentSupplier, or ContentTranslator) ? It could well be that this kind of picture is over-engineered for your purposes (I can't tell). But even if it is, then the real culprit is the Swing architecture which is under-engineered (here), so something may be needed to compensate. -- chris