Mogens Nidding

Thanks for your reply - it was very clear.

Hi Kirill,

Can you give a bit of introductory explanation about the relationship between Visual Studio Team System and TeamCity? I haven't dug into either product yet, but as far I hear, Team System is targeted at much larger teams and includes requirements and configuration management and more (and is correspondingly more expensive) than TeamCity.

Does Team System make TeamCity unnecessary, or does it make sense to use the two products together? If it does, are there any plans to support Team Foundation Configuration Management in TeamCity?

Finally, can you offer a guideline as to the size of teams TeamCity works best for?

I know it isn't of much help, but this might be the closest you get to an official answer: The Mysterious 44/80 Locking score

Gytis: why can't we use just <T extends Comparable<T>>

<T extends Comparable<T>> almost, but not entirely does the job. It is best explained with an example, such as GregorianCalendar from before. If you insert GregorianCalendar instead of T, you get

<GregorianCalendar extends Comparable<GregorianCalendar>>

which is not true! Therefore, a list of GregorianCalendars could not be used as input to doit if we just used <T extends Comparable<T>>.
GregorianCalendar does implement Comparable<Calendar>,
but it does not implement Comparable<GregorianCalendar>!
I admit this is not very intuitive, but it's the way generics work in general, and it is the reason wildcards were introduced.

I have an idea of how to extend the language so that we won't necessarily have to write <T extends Comparable<? super T>> every single time, but that's another I discussion I may post somewhere else if I suddenly have oodles of time.

Gytis: your solution is restricted to Comparable types only, but some operations like EQUALS or IS_NULL does not need Comparable arguments at all

True, and I didn't even think about that. It just makes your question even better . I'm not sure there is any super elegant solution to this problem. If your client does this...

Operation myOp = askUserForOperation(); Number[] myNumbers = getSomeNumbers(); myOp.doit(myNumbers);

then the original code you posted (with the cast) will throw a ClassCastException if myOp == MORE because Number does not implement Comparable! This is exactly the reason the compiler emits an unchecked warning with JDK1.5: In some situations, the code will fail.

If you know for sure that no client is going to do something like that, and you just want to cast without triggering a warning (perhaps this is what you asked for from the very beginning?), I am going to have to owe you a reply, since I didn't dig into it any deeper and don't have too much time right now. Try searching for @SuppressWarnings("unchecked"), it might give you a solution, although not the elegant one you were hoping for. I think (hope) there is be a better solution.

Please let me know if you make any more experiences in this matter, as I find it very interesting: Perhaps generics didn't entirely get rid of the need for casting anyway! I will also look into it some more later, but for the moment, my lunch break is over :-)

Hi, Gytis!

Good question. After reading your question, I downloaded JDK 1.5.0 to try out your example and generics for the first time. By peeking a bit at chapter 9 of Gilid Bracha's excellent Generics tutorial, I found this to be the "correct" way to get rid of the unchecked warning:

public enum Operation { MORE { public <T extends Comparable<? super T>> int doit(T... args) { return (args[0].compareTo(args[1])); }; }; public abstract <T extends Comparable<? super T>> int doit(T... args); }

Now, doit takes a list of objects of type T. T can be any type that is comparable to any supertype of T (including T itself). For instance (this is admittedly a bit far fetched, but it has to be), T could be GregorianCalender, which is comparable to Calendars in general.

I must say the generified solution is a little verbose when compared to a single cast in this case.

Hope it makes sense. Good luck in your future generic adventures :-)

As far as I know, there is no way to do what you want directly - no type parameters are present at runtime.

If you need to check, your best bet is to take a class literal as argument, for example to the constructor. As a trick, use T as type parameter for the class, like this:

class AClass<T> { Class<T> t; public <T> AClass(Class<T> t) { this.t = t; // t is the concrete class represented by T } public void aMethod(Object arg) { if (arg == null || t.isInstance(arg)); } }

Hope this helps!

Is there a technical explanation as to why Throwable.initCause is synchronized when Throwable.getCause and the constructor Throwable.Throwable(Throwable cause) aren't? I am considering the memory model for java 1.4.

I mean, what use is it that initCause is synchronized when getCause isn't? Even though one thread calls initCause, and the cause field is flushed to shared memory because of synchronization, there is no guarantee that another thread calling getCause will read anything meaningful.

Please tell me that I'm getting this right!

Chris Harris: Do you think I will lose marks if I add another constructor that takes a Throwable cause?

Philippe Maquet: No, IMO. I interpret the instructions as this : the zero argument constructor and the one that takes a String must be there as a minimum.

How about if I made the zero argument and String constructors private?

Jiju: My database contains a delete flag (2 byte) and a booked field(owner - empty if not booked). Question is do we need to include deleted and booked in search resultset. Obviously both are not available to book.

My two cents: The purpose of searching might not always be to book a record. A plausible scenario is that a customer calls in and asks a sales representative to confirm that the customer already has a booking. Also with respect to future expansions, many more operations (such as unbooking) can be expected to become available. Therefore, you should not filter out booked records in my opinion.

As regards the deleted flag, I agree with you in that I cannot see a purpose with showing deleted records either - the fact that they (temporarily) keep existing physically in the database file even though they are deleted is purely an implementation detail that makes it easier (and faster) to code the delete operation. Compare it to the file system on your hard drive: Even though you delete a file (and empty the recycle bin), the actual file contents will keep existing physically on the hard disk for a long time, but you certainly don't want to see it except in really rare circumstances where you want to recover the file - and if you do want to see it, you have to use a special undelete tool.
[ October 20, 2004: Message edited by: Nicky Bodentien ]

Nicky: The requirements state that the zero-argument and String argument constructors must exist, but would I, by making them private, risk automatic failure? If I don't make them private, I lose the type safety benefits (unless I do some really awkward stuff).

Inuka: I basically did the same thing with RNF exception as well.

My concern here is in particular the private zero-arg and String-arg constuctors. Are you recommending that they should be public?

Inuka: The way I build my program I assume an IOException means a unrecoverable faliure(beccause in my cause the normal opperation of the program cannot cause IOExceptions) and just carry along the information.

If I understand you correctly, you subclass e.g. DuplicateKeyException and, for example, throw new DuplicateKeyIOException(caughtIOException) when an I/O error occurs in Data. Then, somewhere in your client or GUI, you catch DuplicateKeyIOException, and when you do, you treat it like a generic (although fatal) Exception? Is this right? It is a workable solution I think, but in my case, I would like to avoid it, because I have a slightly higher-level interface than DBMain where I don't declare DuplicateKeyException (duplicate keys can never occur in my implementation).

Jared: for the sake of consistency, I have decided to jump on the runtime exception bandwagon.

Yes, you point out good arguments for the runtime exception approach, and I may choose to jump the same bandwagon. But my concerns are about unwrapping the IOException in a typesafe way, and I find the most elegant way to do it is by restricting the constructors of the DuplicateKeyIOException (or whatever) such that the "cause" exception is absolutely guaranteed to be an IOException. But this puts me in a worry about the "exceptions must have zero-arg and string-arg constructor" requirement. This issue is the same whether you use checked or unchecked exceptions.

Inuka: What do you think?

Runtime exceptions are fine in this context, and as you point out, other topics address the issue in much detail. If I were to sum up the topics, all approaches are evils in this context, and it a matter of taste which we consider the lesser evil:

Throwing RecordNotFoundException/DuplicateKeyException because of an I/O problem is misleading, no matter whether you do subclassing, chaining, or both. The advantage, however, is clients are forced to deal with these checked exceptions, and even in the worst case scenario where a client treats an I/O problem as if a duplicate key were created, the consequences will likely be limited to a graceful abort of the operation and a (possibly misleading) error dialog shown to the user. For a worst case scenario, this is very good.

Throwing an unchecked exception because of an I/O problem has the potential to crash the client. The advantage, however, is that it is not misleading.

No matter if you go checked or unchecked (or use special error return values such as null or negative numbers), your client will have to read your documentation to achieve the best error handling possible.

And (as is the case for you), if one of your methods don't throw any checked exceptions, then checked exceptions are naturally not a consistently applicable option.

These are very interesting topics, but since they are addressed in so much detail, my primary concern in this topic is the typesafe (or not) unwrapping of the nested IOException.
[ October 20, 2004: Message edited by: Nicky Bodentien ]

I would like to throw IOException from the data class
by wrapping it in a special exception such that it can be
caught and the IOException extracted in a typesafe manner.
What do you think of this attempt:

/** * Wraps an IOException. The wrapped IOException from * can be extracted in a typesafe * manner, and the wrapping DuplicateKeyIOException can * then be discarded without loss of any significant detail. */ class DuplicateKeyIOException extends DuplicateKeyException { private DuplicateKeyIOException() {assert false;} private DuplicateKeyIOException(String msg) {assert false;} DuplicateKeyIOException(IOException wrapped) { super(wrapped); } IOException getIOException() { return (IOException) getCause(); } }

The requirements state that the zero-argument and String argument constructors must exist, but would I, by making them private, risk automatic failure? If I don't make them private, I lose the type safety benefits (unless I do some really awkward stuff).

The idea is that a client can then (at least in my opinion) rather elegantly convert the DuplicateKeyIOException into an ordinary IOException:

public void foo() throws DuplicateKeyException, IOException { // ... try { myData.create(fieldValues) } catch (DuplicateKeyIOException e) { throw e.getIOException(); }

The same thing could be done by suclassing RuntimeException.

I think it's is a matter of taste. Nonetheless, I would recommend 0-based for two reasons:

0-based will make your arithmetics simpler (you'll avoid something like recordPos = recordLength * (recordNumber - 1) + offset)

I think 0-based is "most" standard since it is used for arrays and the list/vector classes, which are used everywhere by everyone

[ October 14, 2004: Message edited by: Nicky Bodentien ]

Congratulations!

About the 44 in locking, I'll quote Mark Spritzler from The Mysterious 44/80 Locking score:

Here is an anonymous unofficial answer I have received at JavaOne, by someone really really close to the certification and knows about grading.

Basically if you get 44/80 means that the locking does not work in all cases. That there is a scenario that the examiners have run that shows the locking schema that you use does not fully lock in all concurrent scenarios.

[ October 13, 2004: Message edited by: Nicky Bodentien ]

The reason I am asking is that I have this in my requirements:

The JAR file must have the following layout and contents in its root:

The a directory called docs, containing the following items at the top level:

... A subdirectory called javadoc, containing HTML/Javadoc documentation for all classes and interfaces you are submitting

Now, if I have a private inner class somewhere, this would force me to generate documentation right down to the private level, which I certainly not something I wish to do.

Does anyone know if this is a problem?
If it is, I guess I'll just make the class package private.

By the way, about the Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file statement, I think we can be a bit bold and read it as this: When a method throws a RecordNotFoundException, it should be because the specified record does not exist or is marked as deleted, but not necessarily another way around. I think it's a grey zone.