David Peterson

+ Follow
since Oct 14, 2001
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by David Peterson

Is there any way to avoid the compiler warning: "Type safety: Unchecked cast from AbstractBuilder<T> to T"? (Other than suppressing it.)

16 years ago
Take a look at the iBATIS Data Mapper. I've found it very easy to use. One of the things it can do is return results as a list of Map objects (field-names mapped to values), so you don't have to create specialised beans for each type of result.
I'm using Microsoft SQL Server, but this is a general question about calling stored procs via JDBC.

I want to manage transactions within my stored proc (i.e. by placing BEGIN TRAN and COMMIT TRAN around relevant pieces). But whenever I call a stored proc through JDBC it always seems to be wrapped in a transaction - either implicitly with the 'auto-commit' setting turned on, or explicitly using commit().

Is there some way I can call SQL without having it wrapped in a transaction?


To answer your original question, to run the code with assertions use the -ea (or -enableassertions) switch when you run java.

19 years ago
By the way, it's generally not a good idea to use assertions for checking the preconditions of public methods or constructors. You should throw an IllegalArgumentException (run-time exception) instead, so that the public contract is enforced whether assertions are turned on or not.

Use assertions for checking the preconditions of non-public methods, or for checking internal consistency and post-conditions.
19 years ago
I don't think I explained well enough.

I am compiling with Ant. I have turned on 'deprecation warnings' because if any of my code is using deprecated methods then I want to be aware of that fact.

My issue is that I am never calling the deprecated methods in PreparedStatement, but I am still getting warnings just for implementing them. This seems crazy.

My IDE (Eclipse) is more sensible and stops reporting the warning if I put @deprecated as a javadoc tag before the implementation of the method, but the "javac" Ant task continues to report them.

Any bright ideas how to stop Ant reporting these false deprecation warnings, without turning them off completely?
[ August 20, 2004: Message edited by: David Peterson ]
19 years ago
I'm using JDK1.3.1.

I've written a class that implements the PreparedStatement interface, but the compiler complains that the setUnicodeStream() method is deprecated.

I'm not using the method, but I have to include it in order to implement the interface. I tried marking the method as /** @deprecated */ but this had no effect.

Does anyone know of a way to stop the warnings for this class only? (I don't want to turn off the warnings completely).
19 years ago
It will help you a lot to understand the code if you format it neatly with proper indentation...

You can now see that the throws clause is part of the method declaration, whereas the throw statement is part of the method body.

The throws clause tells you what exceptions the method may throw. The person calling the method must either handle these exceptions (with a try..catch) or declare them in its own throws clause (which will pass the exception up the call-stack until something handles it, or the application crashes).
The throw statement actually throws an exception.
[ May 09, 2004: Message edited by: David Peterson ]
20 years ago
A StringBuffer is not a String, nor vice versa. However, if you want to compare the contents of the StringBuffer, with a String you can do that...
Erm... yes and no.
Interfaces don't come under the class inheritance tree, but they can form their own interface inheritance tree.
i.e. an interface cannot extend a class, but interfaces can extend other interfaces.
You can read line-by-line with a BufferedReader.
20 years ago
There are no side-effects per se, but some potential drawbacks of anonymous classes are:
  • Difficult to reuse;
  • Difficult to test;
  • Can make methods hard to understand (especially if the code is badly formatted).

  • The advantages are:
  • A bit less typing;
  • No other methods can use the class (so, you can muck around with it as much as you like and it won't affect anything else);
  • Fewer classes (less clutter).

  • 20 years ago
    Two solutions:
    1. Give your constructor a throws clause.

    2. Do not call populateList() in the constructor.
    Personally, I would recommend the latter. It is usually "not the done thing" for constructors to throw exceptions.
    Rather than calling populateList() in your constructor you could either get the caller to call it specifically after constructing your object, or call it behind-the-scenes the first time your object's getter method is called. This is called lazy construction (lazy, in this case = good).
    You might also want to make the filename a class-level property rather than hard-coding it in your populateList() method. Perhaps your constructor could accept a String or File parameter for the filename.
    20 years ago

    If index = 80 and size = 100 then the condition will not evaluate to true, so the exception will not occur. So... perhaps index is not really 80 (e.g. maybe it's -80) or size is not really 100 (e.g. maybe it's 10) or your JVM has been hit by a stray cosmic ray.
    Or are you using it in a multi-threaded application? The methods in ArrayList are not synchronized, so it is possible (though you'd have to be reasonably unfortunate) that another thread updates the list at the same time as you're getting its contents. If this is the case, either synchronize or use a Vector instead.
    20 years ago