Rich Wardwell

Wow... I went exactly the same route - almost to the T. Started with Flight objects and a very similar interface to the one you had to provide access to them, then when I started to think about the added complexities, threw it out and switched over to just holding the data and accessing through the AbstractTableModel interface.
I'm still torn whether not providing accessors that return Flight objects isn't more appropriate, but it certainly muddies things. Simple or flexible / complex. Also, creating a ton of flight objects seems somewhat ineffecient, although that wasn't a motivating factor in me switching.

Originally posted by Peter den Haan:

This implies that <code>Data instanceof Remote</code>, even though it is not a remote object at all. This breaks the <code>Remote</code> contract. IMHO, better strip the <code>Remote</code> out of <code>DBInterface</code>, and add a <code>DBRemoteInterface extends DBInterface, Remote</code>.
- Peter

Ok... so you can extend two Interfaces. What's going to implement DBRemoteInterface? Data? I assume you're going to have to create a whole new delegate class that implements DBRemoteInterface but just calls Data. Of course, I guess you would have to do that anyway.
If DBInterface *STILL* has to throw RemoteExceptions, then what did this buy you? Data implements DBInterface and doesn't throw RemoteExceptions. Wasn't this the original reason you suggested this in the first place? Doesn't this imply that Data is an instanceof Remote? Maybe not in official "type" but at least in interface? I guess that in and of itself might be more appropriate, so I think I can see your point.

[This message has been edited by Rich Wardwell (edited June 21, 2001).]

But you can. See the JLS, 9.1.2.
- Peter

Well how about that... learn something new everyday! :-)

[This message has been edited by Rich Wardwell (edited June 21, 2001).]

Originally posted by Peter den Haan:

This implies that <code>Data instanceof Remote</code>, even though it is not a remote object at all. This breaks the <code>Remote</code> contract. IMHO, better strip the <code>Remote</code> out of <code>DBInterface</code>, and add a <code>DBRemoteInterface extends DBInterface, Remote</code>.
- Peter

That would be a good solution if you could extend two interfaces.
Alternatively, you could create a class that implements both interfaces and then delegate all of your calls to Data class, but that doesn't seem very appropriate either.

The reason you get a nullpointer is because the instance variable a has not been instantiated when you attempt to call it's innerMeth(). You must call aMethod() on Testmine first (or instantiate a by some other means) prior to calling an instance method on that object.
Also, just to note - using the public keyword in the interface declaration is redundant and usually frowned upon in most coding style guidelines.

Consider that SAX is a low level parsing method where you have to do all the work whereas DOM is fairly high level and creates an object tree for you. DOM also can be used to output XML where SAX inherently does not.
Generally, most DOM parsers are written using a SAX parser. Download JAXP from Sun and try them both out.

I particulary like Ivor Horton's Beginning Java book(s). The Java 2 version cut out a couple chapters I liked from the 1.1 book, but it is still an excellent read. And don't let the "beginning" fool you. He's very thorough and digs deeply into each topic.

Use the java.text.SimpleDateFormat class.
The API documents have an example using this API to do exactly what you wish to do. Go to http://java.sun.com/products/jdk/1.2/docs/api/index.html and look for the SimpleDateFormat class.

UML is a process independent language to discuss and communicate the design, etc. of a system - in other words, UML can be useful for any process and can be applied as need be for each. UML Distilled by Martin Fowler is an excellent first read on UML. It also mentions how processes can use UML (usually referring to the RUP process).

Well, all these answers about using database locking aren't quite accurate if you need a more real time solution (such as an event / listener mechanism for instance). This is becoming quite necessary in larger and more robust business applications. In these cases, application level "locking" is necessary - database level locking just won't do.
In essence, the type of locking you need is definitely based on the type of application that is being built.

I've been at two shops that use PVCS. I hate it - it's slow, clumsy, and difficult to manage. That said, I have been able to configure it to do most of what I wanted it to do (after spending hours hacking away at a command line interface and a very poorly written manual).
I really would like to investigate CVS and one of the Java front ends but haven't had the time as of yet.

My experiences with TogetherJ have been lukewarm at best - crashes often and extremely slow on a P3-600 w/128mb RAM. I haven't used Rose directly, but an architect on our team does - his impression is that it is quite a bit more robust than TJ, both in features and stability.
Personally, I've been testing a new tool that I'm falling in love with called JaVISION from Object Insight. It certainly doesn't have the feature sets of TJ or Rose - it is primarily a class diagramming tool that has both forward and reverse engineering (no sequence diagrams). It's fast, easy to use, prints beautiful diagrams, and is what I now use when I'm starting my designing. It can automatically keep the model updated as you modify your code and has some other neat diagramming capabilities (integration with JavaDoc). Highly recommended.

I like the "Old Moose Saloon" over "Mangy Moose" as well.
Although the new moose is kinda funny the first few times, it's now becoming kind of sad and depressing...
Maybe if you could show the one-eyed moose only in certain places or occassions but use the old one every where else, or only show the one-eyed moose every 1 out of 10 hits or something similar

JBuilder 3.5 is now out in a plethora of versions, including a "free" one. Everyone has their IDE or editor of choice, and mine happens to be JBuilder - so, if your looking for something new, give it a try.

I'm torn... I like the old happy (?) moose with both eyes. But the new moose is quite funny. The fly is definitely a wonderful touch.