MIchael Kmiec

+ Follow
since Jun 05, 2001
Merit badge: grant badges
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 MIchael Kmiec

Originally posted by Steve Dalton:

Some of our most heavily used classes are often inherited multiply as what you might call 'mix-ins'. I know that in Java you can use interfaces to achieve similar results to Multiple Inheritence (although without implementation in the interface of course) and that you could also use other alternatives such as aggregation and delegation. But in certain circumstances I just can't see anything nearly as intuitive as multiple inheritence.

Steve -
For my play on the extends/implements controversy, take a look at my somewhat coherent post:

A lot of the objects in our system provide statistics to a central controller that sits on the network monitoring the server farm. There is a central Singleton StatisticsManager object along with other objects that are used for transport of data etc. Objects provide statistics by inheriting from the StatableObject interface which contains a small amount of functions - the main one being SetStatistic. Objects call this SetStatistics method when they want to update a particular statistic. How would you implement a similar system in Java, I couldn't think of anything nearly as intuitive.

As to your example, it seems more as a look towards patterns rather than language implementation. (Forgive me, I just finished reading John Vlissides' Pattern Hatching.) By using the OBSERVER pattern (or even JV's somewhat preferred MULTICAST pattern), you could have each derived StatableObject interact with the StatisticsManager in a manner where inheritance is not an issue.
Granted, we don't live in a perfect world where we can rewrite code according to "best practices", but alternatives exist to work around inherent implementation (read that: "language") problems.
21 years ago

Originally posted by Andrew Shafer:

Parmeet, I understand how an interface works in practice, but in theory I'm a bit confused about the difference between extending an abstract class or implementing an interface.
It just seems like a way to get multiple inheritance.

Keep in mind the Java language comes from Sun, where I'm sure many developers are ex-C++ (multiple inheritance) and ex-Smalltalk (single inheritance) developers. Smalltalk won.
Seriously, from an OO standpoint, I personally love multiple inheritance, but it does present management/development problems as projects and teams grow. All it takes is one circular reference to make compilation a tedious task.
Implementing interfaces in Java does (to an extent) work around the problems of "pure" multiple inheritance, but also adds the ability for any class to implement any interface (no need for the classes to be part of the same inheritance tree).
The tradeoff is when (if) you change the interface by adding a method, any classes implementing the method will have to change to reflect the additional method. Using abstract classes can avoid this, since you can add a non-abstract method to an abstract class without harming classes that extend the abstract.
Having developed for years with C++, I used to complain - loudly - about the lack of multiple inheritance in Java. But I'm gradually coming around to the idea of the Java extend/implement scheme. Now if I could only come to grips with the language's lack of pointers...
21 years ago

Originally posted by Mohamed Yousuff:

Also always try to use column names rather than the column number. This is because when you install the application to the actual machine and create the tables, you are restricting yourself to create the fields in the same order. Also in future if you remove a field in the middle then the field order will change again. In this case, you have to change your code again.

One thing to keep in mind when referencing columns with the getXXXX( String columnName ) syntax - when you build your SQL statement (or PreparedStatement or whatever) that you reference the column names explicity. Instead of:
This actually serves two purposes: 1.) It's easier to maintain the SQL and the getXXXX() calls in parallel; and 2.) It's more efficient to perform SELECTs in this manner - the database doesn't work as hard, and why return information you may not use?

I'm afraid I don't know what you mean by "style guide". Do you mean a "best practices" approach to developing JSP? If that's the case, I recommend just following the spec. If that's too much information, just remember: logic and presentation don't play well together. Otherwise, I tend to follow the JSP syntax card as gospel:
21 years ago
SoonAnn Lim makes a good point about performance; however most (if not all) JSP implementations are optimized to handle these issues.
Besides, you only lose compile time the first time the JSP is accessed, because then (as with servlets) the classes reside in memory. Granted, you might not want to make *all* your pure HTML documents JSP, but in this case the difference would be negligible.
21 years ago
Have you tried referencing the shell script via a full path?
Instead of r1.exec("sh abc"), how about:
String script = "/usr/home/mike/myshellscript";
r1.exec( script );
...this may have something to do with the script residing somewhere the JVM can't find it. Try being explicit, since "exec() starts a new process running externally to the interpreter." (J.I.A.N., 3rd edition.)

21 years ago
Implementing this really depends on what database you are using. (I'm not a DBA, so take everything I say with a large grain of salt.)
Also, is there a particular reason you want to do this? In my (limited) experience, record-level locking makes things run a bit slower. It can be a blessing, especially if your application is multi-threaded and data is getting whacked all over the place - provided you use it on a table-by-table basis.
It really depends on what your stored procedure is doing. Based on the name, it looks like your class is attempting some sort of DML - dropping a table would be my guess.
If memory serves me correctly - it's been a while since I've developed with Oracle - Oracle Java stored procedures limit what you can do with them. Primarily, they let you SELECT and then manipulate the returned data - I even think UPDATES are restricted. Really, it makes sense, since you don't want any old user coming along, running your stored procedure and subsequently hosing your database. Security issue or big bug? You be the judge.
This was a constant source of frustration until I found a reference to the limitation on http://technet.oracle.com (sorry I don't have the exact URL, as I said, it's been a while.) All the docs on Java stored procedures are at: http://technet.oracle.com/tech/java/jsp/. It also helps if you look up the error number [POL-8035] on technet.
Good luck,