Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: How do you update the view space of a JTable? Date: Tue, 31 Oct 2017 17:13:47 -0400 Organization: A noiseless patient Spider Lines: 80 Message-ID: References: <8a75cc49-c369-41bb-8e5e-254977d4e410@googlegroups.com> <0a028d23-313f-4c8f-8516-80a5111e406a@googlegroups.com> <5037e6b0-3509-4ffd-a8f2-ad659c5b4d4b@googlegroups.com> <66fc1800-d494-43a1-963d-a1a54a99f631@googlegroups.com> <28c95541-33f4-4502-af4e-31d82c672841@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 31 Oct 2017 21:13:49 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="6cbb3930c884631b073b0fc9e7411336"; logging-data="31644"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ach1GsvMeCjjP7evXSnwo" User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 In-Reply-To: <28c95541-33f4-4502-af4e-31d82c672841@googlegroups.com> Content-Language: en-US Cancel-Lock: sha1:0Ty78/C5nIaAe0+oVjnQ5UpeEn0= Xref: csiph.com comp.lang.java.programmer:37632 On 10/31/2017 9:13 AM, Eric Douglas wrote: > On Tuesday, October 31, 2017 at 8:33:09 AM UTC-4, Eric Sosman wrote: >>> >>> https://pastebin.com/zrUESqc4 >> >> Ah, yes, how silly of me: I should have looked in a completely >> different thread to find your link. Pray accept my apologies for >> being so lax. >> > > That is what I said, check the other thread, so far no one responded there. I can move that conversation here if it'll help. A brief look at the code reveals one serious error (of the kind you'll "usually" get away with), one serious error that no Java programmer should ever commit, a few venial sins, and some opportunities for stylistic improvement. What it doesn't reveal is the code's purpose nor how it fails to fulfill that purpose, which makes it a little hard to diagnose ... Herewith, the problems apparent to my brief inspection: - Serious: Swing is not thread-safe, and almost all Swingstuff must be done on the event dispatching thread (EDT). Your code constructs and launches a JFrame and all its contents from whatever thread executes main(). You'll "usually" get away with this, because Murphy waits until the Big Demo for the Big Boss. See https://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html - Serious: `catch (Exception e)'? Are you KIDDING? - Venial: Various constructors call potentially overridable methods, which could be a problem if any of your classes are someday extended. You could cure this by making the involved classes final, or by making the methods final, or (since you probably don't need to override some of them) by explicitly calling the superclass' method, as in `super.getContentPane()' instead of just `getContentPane()'. Or, you could just hope no one will ever extend the class and find some reason to override setAutoResizeMode() or whatever. - Venial: Various constructors leak the `this' reference before `this' is fully constructed. The transgression would ordinarily be worse than venial, but adding event listeners "should probably be" safe since they're unlikely to be called until a good deal later. IMHO this is an infelicity in the architecture of Swing/AWT: You would *like* a constructor to deliver a fully-functional ready-to- rumble instance of a JFrame or whatever, but if you're really not supposed to register event listeners in a constructor ... The squeaky-clean approach, I guess, is to have a post-construction init() method, which strikes me as Ugly. Or ignore it and hope. - Venial: The `MyTable' class is package-private, yet some `public' methods either return it or use it as a parameter. Either make the class `public' or make the methods package-private: Pay attention to your access levels. - Style: Sleekness could be improved with a lambda expression instead of an anonymous inner subclass of AdjustmentListener. - Style: Use `intValue' instead of `new Integer(intValue)' and let auto-boxing take care of wrapping it. (May produce a tiny gain in efficiency, too.) - Style: Instead of calling System.exit() on a window-close event, you could just `setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE)'. - Style: The types of some fields are unnecessarily specific: `AbstractTableModel' instead of `TableModel', that sort of thing. It is usually "better form" to use the least specific declaration that's suitable -- often, an interface rather than a particular implementation of that interface. That way, you retain flexibility to change the implementation later with little or no upheaval. I sincerely doubt that fixing any of the above will help you in the least with whatever problem you're having in the pursuit of whatever goal you're after, but "Cleanliness is next to Godliness, also next to impossible." -- esosman@comcast-dot-net.invalid Eleven hundred seventy-seven days to go.