Pete Lyons

In that situation x would need to be final because it is a method local variable that normally would be cleaned up from the stack as the method returns. Your inner class has a reference to it, and basically (although I don't really understand the details), the final allows the compiler to give you a copy of the value that your class can use. For object references, the compiler needs to know that the object your reference refers to will not be changed.

Yes, your package.html files go in your source tree, and javadoc will see them there and incorporate them into your javadoc files. I don't think there's a limit on the file size. I would imagine 1-2 MB would be the most you would need if you used many many screenshots in your documentation. Mine was 691 KB, FYI.

My results took about that long. After 4 weeks I emailed them to see what the status was, and they posted results within a few days.

I just had one interface that threw RemoteException in addition to any other exceptions, and documented the fact that these would never be thrown by a local implementation. I was not really happy with this design, but it was expedient, so I did it, and it seemed to be tolerated by the assesor.

You can't call methods on any primitives in Java (int, short, long, boolean, double, float , and so on). You must use the appropriate wrapper class (java.lang.Double) if you need compareTo, or use the primitive comparison operators as demonstrated above.

The Serialization Tutorial explains some of how serialization works. If you're curious, detailed explainations of the binary format can be found on the web, or just open the file up in a text editor. Basically, you should not need to worry about the implementation details, which is why it's easy to serialize objects in some languages. Of course, the source code to ObjectOutputStream is always there for the real truth. You also might be curious about java.beans.XMLDecoder to see an alternate file format for the stored object graph.

for an int you can use code such as:
if (myAge == theirAge) { return 0; } else if (myAge < theirAge ) { return -1; } else { return 1; }
or you can wrap the int into an Integer and call compareTo on that.
As to the wildcards, do the simplest thing that meets the needs of your users. Do your users really care enough about wildcard matching to use '?' instead of '*'? For most users, even '*' is too tricky, and you just always do a case-insensitive startsWith type search.

Use java.util.Date for most of your normal programming needs. java.sql.Date is part of JDBC and involved with databases, etc.

Some of us added a rudimentary integrity check to our startup code that would prevent this from happening if you opened up other files by mistake. There's another thread that discusses it, but I couldn't find it. Anyway, the code is like this:
RandomAccessFile formatCheck = new RandomAccessFile(dbFile, "r"); int headerLen = formatCheck.readInt(); int nFields = formatCheck.readInt(); int recordCount = formatCheck.readInt(); if(headerLen < 0 || nFields != 9 || recordCount < 1) { throw new IOException("Database file at path '" +dbFile.getPath() + "' is not a proper db.db file"); }

Just add public accessor methods for each property such as public String getName() { return name; }
and then use these in your search. Wildcard support will be trickier, you can use a Regular Expression if you are on JDK 1.4 or you can do a more limited version in code, such as only allowing the wildcard character at the end and using String.startsWith() to do the match.

I guess it's possible that Sun would take off a few points because you don't adhere to standard HCI conventions, which dictate that an application's main window should be resizable. What you could do is implement a minimum size in your frame (which I think is possible, but I'm not sure). If you're main data section is a JTable in a JScrollPane (as it likely should be), what is so hard about laying out the other widgets in a scalable way? I also used the BoxLayout a few times, and my layout expanded fine, shrunk fine vertically, and when you made it unreasonably narrow, stuff started disappearing.

The Jakarta Commons Collections Project has many additional collections classes under an open source license. I didn't see a Binary Tree, but there is a Binary Heap, which may do the trick or at least provide some good sample code for implementing a real binary tree.

The code would be different (simpler) if you knew for sure each line would contain the same number of words. Is that the case? What you might do is read the file line by line and token by token, and push each word into a List of Lists (a 2-dimensional ArrayList), and then you would have random access to any arbitrary word of any arbitrary line. You'd basically have 2 nested while loops, 1 for the BufferedReader.readLine(), and one for StringTokenizer.hasMoreTakens().

Michael,
Multi-threading is far too complicated to be explained in a discussion group post. You should find a good article or book that introduces threading and read that. Basically, you create a subclass of Thread (or a class that implements Runnable, which you pass into a Thread's constructor), and then call start(). Java Threads by Scott Oaks and Henry Wong (O'Reilly) is pretty good.

All of the Jakarta projects are quite interesting. Latka (automating acceptance testing for web apps) is a newer one that could use some help. I've recently taken an interest in Prevayler, which is a brilliant open source project for robust, persistent business objects without a relational database.