Jerry Pulley

Ok, I'll redefine the problem. I need to subclass JSplitPane to produce this behavior: When the divider is moved, only the left component should change size. The right component should keep its existing size, and the split pane itself should change size by the same amount the divider was moved.

Now, I see the difficulties with that. Philosophically, at least, the size of a component is usually controlled by the layout manager of its parent component. I'm also investigating that approach, looking for the appropriate layout manager to use in the top containing JViewport.

Ideas?

Jerry

If you've ever seen the Finder in the Mac UI, that's an example of the approach I want to use. My component accepts a TreeModel, and displays all children of the root in the leftmost JList. When the user selects an item in the list, a JList is added to the right of the first, containing the selection's children, and so on.

The implementation starts with a single JSplitPane with the first-order-children in a JList as its left component. The first selection creates a new JSplitPane with the appropriate second-order-children in a JList as its left component, and makes that new split pane the right component of the first one, and so on.

I've implemented this special purpose split pane as a subclass of JSplitPane. (SplitTreeSplitPane, STSP for short). So a STSP always has a JList in a scroll pane as its left component, and either a very thin spacer panel or another (nested) STSP as its right component. STSP implements ListSelectionListener, Scrollable, and PropertyChangeListener.

The dynamic addition and removal of nested STSP's works well; I'm making the whole thing resize appropriately and scroll to make the newly added list visible at the right times. The problems begin when the user moves any divider - I can't seem to make it resize when the dividers are dragged. Moving a divider just a little (less than the width of that rightmost spacer) works fine; the space gained in the JList to the left of the divider is lost by the spacer. Move it any more and the JLists to the right start shrinking. Move it so much that all the JLists to the right are down to minimum size, and you can't move it any more.

I'm listening to property change events for the divider location property, calculating the amount moved, and resizing up the chain. Or rather, attempting to - all attempts to set the size in the property change handler are in vain. The timing of the property change event seems to be the stumbling block. The logic that works with list selection events doesn't work there.

I really want to stick with JSplitPane and not roll my own out of JPanels, so I can get the one-touch behavior, good LAF support, etc.

Ideas?

Jerry

Before I launch into a detailed explaination of my quandary, let me ask: Has anybody here ever built a UI with dynamically nested JSplitPanes? I'm using this approach to display a TreeModel of data in JLists. Or at least I'm trying to. It's working acceptably, but there seem to be a lot of hurdles on the way to that last little bit of perfection.

If you've done this, TIA for the assistance I'll be requesting. (If not, go figure it out so I can ask. J/K.)

Jerry

We have a few calls to mark( int ) in a rather large app; they worked fine under 1.2 but reset() started failing when we switched to 1.3.1. The problem was the argument - it needs to be one greater than the maximum number of bytes you expect to read before resetting.
Read the fine Javadoc (carefully). It states "The readlimit arguments tells this input stream to allow that many bytes to be read before the mark position gets invalidated." The implication is that if you call mark( 10 ) then the mark may be discarded anytime after the 10th character is read.
How many bytes may actually be read before reset() starts failing seems to vary with the situation; all that mark()'s contract guarantees is that you can read at least (readlimit - 1) bytes and still reset() the stream. The stream must allow (readlimit - 1); it may allow more. In 1.2, the reset buffer size seemed to be a power of 2, at least for small readlimit. In 1.3.1 and up, the implementations seem more aggressive in sizing the buffer - still, I doubt that
is.mark( 1 ); //read 1 byte is.reset();
will ever fail. But you can't rely on it.
ok,
jp
[ July 12, 2002: Message edited by: Jerry Pulley ]

I've got an app that runs many (1K+) simultaneous HttpURLConnections, each in a separate thread. It's up for refactoring and I'd like to change this approach to use a selector. I would like, however, to keep the existing architecture, so I'd rather not go straight to the sockets.
The only thing I can think of is to open a channel on each HttpURLConnection.getInputStream() (and maybe getOutputStream() ?). Has anybody done anything similar? I haven't used java.nio yet; is this approach rational?
thnx,
jp

Puneet,
The array access expression is evaluated before the assignment of 9 to i.
Jerry

Venkataraman,
You've got two choices; it depends on whether you want the unique per-client identifier held on the client or server side. (It's got to go somewhere; those are the only choices.)
If your remote clients all receive the same remote reference to your server class (that is, if you don't create any 1-per-client server-side objects), then you'll want to give each client instance a unique identifier that they pass to the server as a parameter in every remote method call. java.rmi.server.UID works well for this approach. You'll have to generate the UID on the server when the client first connects. You shouldn't generate it on the client for two reasons: 1) security, and 2) UID is only guaranteed unique with respect to the host its generated on.
If your server design uses a per-client proxy class, then identifying unique clients is easy. You use the proxy object itself as the identifier.
Jerry

Hi, Rahul.
When you throw the RemoteException, use the constructor that takes a String message and a Throwable to wrap. You can wrap the original exception in the RemoteException.
Jerry

Kamarthi,
You need to run the activation system daemon, rmid. For info, follow the links on this page.
Jerry

chamapk,
If you'd like to keep posting on JavaRanch, you'll first have to register a first and last name (you can read the naming policy at http://www.javaranch.com/name.jsp). You'll also have to refrain from making juvenile remarks. If you don't have anything to contribute, keep silent.
Jerry

Adrian,
My requirements mentioned a client program that exposed all the public methods of the Data class, i.e. lock, unlock, modify, etc. I took this to mean that the server should provide a thread-safe and remote means to access those methods in Data, and that the client interface should use them to query and manipulate the server. In other words, I'd put the lock-read-modify-unlock sequence on the client.
Jerry

Sai,
Ok, here's one: Design and construct a simple database (use Access, mySQL, or InstantDB) representing some schema that interests you, like your book collection. Build a Java class that exposes methods to query and update the database. This class will use JDBC to communicate with the database, and it should be thread-safe. There will only be one instance of it, but it will handle requests from multiple clients.
Create an interface that extends Remote. The methods in that interface will be called by clients to access your database server. Create a class to implement the methods of this interface; the methods of this class will call those of the DB class. This is your server-side client proxy class; there will be one instance of it per client.
Finally, create an interface and implementing class that starts the DB class and has a factory method to create instances of the client proxy. This class will register itself with the RMI registry, so clients can find it.
Your server is done. Now build a client application (or applet, but an application is easier) that looks up the main server class in the registry and gets a remote reference to a server-side client proxy, and provides an interface (doesn't have to be a GUI, text-based is fine) to the server methods.
Turn in your work next Friday. Just kidding, this is a large project. If you're serious about completing something like this, you might as well go for Sun's Developer certification, although it doesn't include the JDBC part.
Enjoy,
Jerry

Sachin,
Please register a first and last name. You can read the JavaRanch policy on user names at http://www.javaranch.com/name.jsp.
CS graduates aren't expected to know every current technology; it's more important to know the fundamentals of programming and software engineering. However, distributed computing is so central to modern software systems that I'd at least pay some attention to RMI. It'll serve as a good base for other Java technologies.
Thanks,
Jerry

Michael,
Because it's not in a method body, constructor body, or initializer block. Looks like that statement and the remaining lines of the class belong in a constructor.
Jerry

[This message has been edited by Jerry Pulley (edited February 06, 2001).]

Wasim,
Of the list of things you cited, only notify/notifyAll doesn't directly affect the execution of the current thread. These methods move another thread from the wait set of the current thread's monitor object.
Jerry