Wayne L Johnson

Ranch Hand
+ Follow
since Sep 03, 2003
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Wayne L Johnson

Java has eight primitive classes (boolean, byte, short, int, long, char, float, double) which traditionally have been treated differently than all other object instances. For example, if you have a collection (List, Map, etc) you can store any type of object instance, but you can't store primitives. [NOTE: I'll get to auto-boxing in a minute].

The solution is to use wrapper classes, which are in the "java.lang" package and, in general, have the same name as the primitive. Thus you have classes named Boolean, Byte, Short, Integer, Long, Character, Float and Double. These classes "wrap" -- i.e., contain -- a primitive. Traditionally if you wanted to store an "int" value into an ArrayList, you have to do something like (assume a list named "MyList"):


With newer versions of Java (JDK 1.5/5.0 and later), a feature called "autoboxing" has been added, which does this automatically for you. In other words, you can add a primitive to a collection directly, and the JVM will automatically stick it into the appropriate wrapper class for you.

Look in the JDK 1.5 documentation, in the "new feature" section, and you can read all about it.
You can use the "new String(byte[])" constructor:
14 years ago
I'm afraid not: you're stuck with doing a nested "for" loop.

Why are you so concerned with this? A nested "for" loop only adds a few extra lines to your code.
14 years ago
It's most likely a classpath issue. It looks like you're not putting these classes in a package, so it should be as simple as making sure that the current directory (".") is part of the class path. Then you do the compile (javac) and execute (java) commands in the directory where the source is located.

You can add "." to the classpath as part of the environment, or you can explicitly specify it using the "-cp" or "-classpath" flags.

There are thousands of web sites where you can get details on how to set up the classpath, and I'm sure there is a link here at JavaRanch that describes it as well. I'll see if I can find a good one and add it to this post.

ADDED: Try this ... How to set the ClassPath
[ May 24, 2004: Message edited by: Wayne L Johnson ]
14 years ago
You are doing it correctly: it doesn't matter if the database is local or remote, all you need is the IP address or domain name (and any other optional database parameters).

The java classes (JDBC libraries for the database) are talking either directly to the database, or through some sort of proxy. But it's not using RMI.
Any class can access a datasource. You can create a Java bean that encapsulates your business logic, and then the servlet (or JSP) can access that bean.

In fact, I believe that the preferred architecture is to use JSPs mainly for doing UI stuff, with either no or minimal Java logic. The servlet then acts as a traffic cop, creating the appropriate beans based on the request, and calling the appropriate JSP for displaying the results.
If you only expect a single result back, you can use this syntax as well.

[ May 21, 2004: Message edited by: Wayne L Johnson ]
You need to create a class with one instance variable for each value you want to return (7 in your case). Create the form and add "Accept" and "Cancel" buttons. When the user chooses "Accept", then transfer the values from the form (JTextField, JComboBox) to the instance variables and shut down the dialog form. When the user chooses "Cancel", then set the instance variables to null and shut down the dialog form. Make sure you have a "getter" method for each of the instance variables.

The calling class will instantiate and show the dialog [make sure it is modal]. Then simply call the seven "getter" methods to get the values from the dialog.

Here's a very simple class that returns a single value.

The constructor forces the dialog to be modal, meaning that the calling frame will be blocked until the user chooses ACCEPT or CANCEL, which is what you want. I like to leave out the "setVisible(true)" method call so the calling object can decide when to show the dialog.

The calling method would include these lines:

If the return value is "null", then you know the user selected "Cancel"; otherwise you'll get back the value they entered.

There are other ways of doing this, but this should help get you started.
14 years ago
You have shown us all of the pieces except for one: where the "jdbc/BooksDB" resource is defined. With TOMCAT you need to have a "<Context...> ... </Context>" tag for your web application. Within that tag you must define the "<Resource ...>" and "<ResourceParams ...>" tags for the datasource. [Alternately they could be in the "<GlobalNamingResources>" tag, but that's usually a bad idea for most situations.]

If it's not defined correctly, then the lookup will fail. Could you show us how that's defined?
[ May 20, 2004: Message edited by: Wayne L Johnson ]
The feature you refer to is part of Java 1.5 (aka. Tiger) and is known as "generics". You will be able to declare a collection of a specific type, and only objects of that type will be allowed in, and casting won't be necessary.

However even with this feature, if you want to store objects of multiple types you may still have to use a regular collection and cast the objects when you take them out. If they share the same super class or parent interface you could use that as the type of the collection and you wouldn't have to cast the objects as you take them out, assuming you only need to call methods that are common across the parent class or interface.

But you'll have to wait for Java 1.5. You can download it and start playing with it to get an idea of what it will do for you.
[ May 18, 2004: Message edited by: Wayne L Johnson ]
14 years ago
To add a little to the previous response, when dealing with a Statement, there are three types of execute methods:

1) "executeQuery()" is used for doing a SELECT statement, and will return a ResultSet.

2) "executeUpdate()" is used for doing a DELETE, UPDATE or INSERT statement, and will return an int (number of rows affected).

3) "execute()" is used for multiple operations, or when the query type is unknown, and will return a boolean (read the doc as to the meaning since it's too complicated to explain here).

Some databases will let you get away with calling "executeQuery()" with a DELETE, UPDATE or INSERT, and others are more strict. But it's good to get in the habit of calling the appropriate method.

While it's true that you can't execute a ResultSet, with the JDBDC 2.0 specification you can udpate the database via the ResultSet. The methods are all "void", so don't return anything.

Cheers ...
[ May 20, 2004: Message edited by: Wayne L Johnson ]
There may be third party classes which do this, but I don't think you can get the "lastAccessed" time via the "java.io.File" class. Sorry ...
14 years ago
I can't point you at the proper location in the Java language specification document w/out doing some digging, but I think I can answer the question.
By using the keyword "final" in declaring the int variable, the compiler knows it can't change. Therefore it can never be anything other than 100. And since that is in the range of a "byte", the compiler essentially adds the cast for you. It's like saying "byte b = 100".
However w/out the "final" keyword, since it's not the compiler's task to try and execute the code for you, the assignment w/out an explicit cast isn't safe, and so it prevents you from doing it.
Notice that if you change your program to "final int i = 200;", you'll also get a compile error. Even though "i" is final, the value of 200 is out of the range of a "byte", so the compiler will flag it as an error.
Make sense?
14 years ago
In fact, you might want to use "equalsIgnoreCase()" instead. That way you don't have to worry whether the user types "astra" or "Astra" or "ASTRA". It simply does a case-insensitive comparison. You could also call "trim()" on the input string in case they added trailing spaces.
14 years ago
Let me take a stab at it. There are basically two types of exceptions you'll run into, "java.lang.Exception" and "java.lang.RuntimeException".
They function the same way in most respects. You can create your own exception classes that extend either one of them, and if you throw them in a method you have to include it in the "throws ..." clause in the method header.
The major difference is that if you call a method that throws something that subclasses "java.lang.Exception", it MUST be referenced inside of a try/catch block. If you call a method that throws something that subclasses "java.lang.RuntimeException," you do not have to catch it.
Look in the Java API documentation staring at java.lang.Throwable and from there you can navigate to "Exception" and "RuntimeException" to read more about it.
14 years ago