"JFC and AFC debate creates confusion, demands choices" by Barry Bowen
I am confused. When did you write this? AFC will only run on Microsoft's VM! This is not cross platform. There is no confusion. Either it is pure Java and runs on Sun's reference platform or it is not Java. It is something that was written in a syntax that is similar to a language called Java and it runs on a platform that will sometimes run pure Java programs (Microsoft's VM). There is no confusion. It's rather simple, really.
You also stated:
The bad news is that the goal of "write once, run anywhere" continues to take it on the chin -- not due to the failure of the technology, but rather due to the inability of Sun and Microsoft to bury the hatchet anywhere but squarely in the back of their antagonist.
"Bury the hatchet?" You make it seem like Sun has been unreasonable with Microsoft. Wrong. It is Sun's technology; Microsoft jumped onto Sun's bandwagon following the abject failure of ActiveX and is now unable to meet its obligations. Understand, I am not bashing Microsoft. Indeed, I do not care what its motivations are. In the case of adhering to the Java standard as defined by Sun, Microsoft is simply wrong.
You downplay the significance of models and views in Sun's JFC and say that Microsoft's model is "based on Visual C++." What does this mean, apps and views? Are we to write MDI Java apps? Models and views are essential for integrating a user interface with a properly designed object oriented back-end. There is really no other way to do it.
Finally, you proceed from a false assumption: classes with fewer methods in public interfaces [are] easier to use. It is true that there is a heuristic in object-oriented programming that ties maintainable and reusable class libraries to minimal public interfaces. The appropriate complexity of these interfaces cannot, however, be identified by simply enumerating the exported methods.
The question must come down to how easily a class perform its designed behavior and how such behavior fit into the needs of the enterprise. These are not simple measures to calculate. Indeed, we ought to be very suspicious of overly simple interfaces.
This article was well researched and well written. But you're well out of your league. Object-oriented frameworks are very hard to analyze and require a detailed understanding of object-oriented programming goals, design, and development. Without this perspective, the resulting conclusions are ill formed and may be harmful to the industry as a whole.
Carmine, The short answer to your letter is, everyone is entitled to his opinion. The longer version is that, while I may share some of your observations, I was not writing an editorial. To address your points in order:
- I noted that without creative tweaking AFCs only run on Microsoft's VM.
- You place blame squarely on Microsoft. Several development managers who agree with you say that's not the point. Correctly pinning the blame for attempts to fragment Java does no good.
- Regarding the superiority of Sun's JFC model and whether AFCs are easier to use or are merely simplistic: I think the point was made that a simpler model makes it easier to do simple things quickly, while JFC's more elaborate model enables development of more sophisticated applications.
- And finally, as to how my "well researched and well written" article can be "harmful to the industry," I say, Thanks! Thanks for the compliment and for considering my opinion so influential. I personally think the software industry is perfectly safe.
"JDBC and Java database programming books: A comparative review" by Laurence Vanhelsuwé
From one who knows...
Your review of available JDBC books was excellent. This line was the creme de la creme: "Maybe a better title for this book would be 'Teach Yourself Detective Skills.'"
This statement was not only funny, but truly on the mark. I totally agree that most of the JDBC books on the market are a sin. Thanks for pointing out the two decent ones. I'll be sure to look for them.
Keep up the excellent writing.
Web App Developer
Not so compelling anymore
Outstanding job on your JDBC books review! I wish I had read the article before I plonked down my money on three of the books mentioned in your article.
By the way, the three-tier example in the Taylor book [JDBC Developer's Resource: Database Programming on the Internet by Art Taylor (Prentice-Hall)] does not work with the current JDK and JDBC implementations, so the one compelling feature of the book isn't there! (It doesn't even compile; I'm still tinkering with it, trying to make it work.)
Thomson Technology Labs
Don't miss Laurence's other insightful reviews (plus reviews from other JavaWorld contributers) at http://jw.wpi.com/javaworld/common/jw-ti-bookreviews.html Ed.
Java Tip 39: "The trick to using a basic Java 1.1 network and file class loader" by Jack Harich
Your article, "The trick to using a basic Java 1.1 network and file class loader" is most interesting.
I am puzzled, though, by the fact that you cannot cast a newly brought class to its original type.
I would like to develop an application that loads its classes from both the local file system and the 'Net. (This allows for automatic updating of classes, as with applets). If the only allowed casting is to an interface (or class) known to the primordial class loader, how can I get an instance of a class that can be referenced properly?
MyLoader loader = new MyLoader(root); Class cl = loader.loadClass("MyManager"); // create an instance and do some casting here // call a unique method of MyManager
The only solution I can think of is to create an interface for each class that is known to the primordial class loader and cast to it:
MyManagerInterface manager = (MyManagerInterface)cl.newInstance();
MyManagerInterface contains all the methods of
The main drawback of this solution is that it is hard to maintain. Every change in the methods of
MyManager (and all other classes) should be done also in
What do you think -- is there a better solution?
Oded, Once a class is loaded, its class loader is used to load any classes it refers to, with exceptions such as Java classes and classes already loaded that it has a reference to. You really shouldn't have any problems. After all, browsers are based on a custom complex class loader. Perhaps the bootstrap casting mechanism is confusing you.... Jack Harich
Java Step by Step: "Networking our whiteboard with servlets" by Michael Shoffner
RMI support on the horizon?
I have been using servlets for over six months now. The only drawback with them is that servlets which use RMI are only supported by Java Web Server from Sun.
Do you have any information about when Netscape or Microsoft will support RMI in their Web servers?
Do you know of any workarounds to allow RMI to work on these servers?
Bob, I haven't heard much news on RMI support for either the Microsoft or Netscape Web servers. There may be some information on JavaSoft's RMI-USERS list, archived at http://chatsubo.javasoft.com/email/rmi-users/. Netscape's developers' zine (http://developer.netscape.com/news/viewsource/kadel_servlet.html) claims that JDK 1.1 is supported in Enterprise Server 3.0. You would have to test it to find out. As far as workarounds go, it seems like you would have to use the pre-1.1 RMI release toolkit, which retrofitted 1.0.2 to use RMI. Then again, that might not work as there were some differences between that and the RMI in 1.1. You might try sending mail to Netscape. Microsoft is supposedly not going to support RMI. Michael Shoffner
Java Tips Q&A with John D. Mitchell
Slipping through the firewall...
I really hope you can help me because no one else can: I am trying to open a URL connection to a password-protected site outside a firewall through proxy. I have no idea how to let the Web server know what my username and password are. I've tried
setRequestProperty("WWW-authenticate",...), as well as
setRequestProperty("Authorization",...) -- neither work. Do you know where I can find a code example?
Luba, Check out: http://www.javaworld.com/javaworld/javatips/jw-javatip42.html and http://www.javaworld.com/javaworld/javatips/jw-javatip41.html for complete coverage of the information you seek. John D. Mitchell
Generating an image, saving it on disk
Can Java make a .gif or .jpg file from an applet and save it on disk? If so, can you send me an example?
Sharon, I don't understand what you mean by your question. Do you want to be able to create an image of an applet and save that, or do you want to have your applet generate an image (any image) and save that image to a file? I don't know of any way to do the former programmatically from inside the applet itself. All I can think of is to use a screen capture program to make screen shots. In the latter case, do you want to save to the local client machine or to the server machine? To learn how to have an applet generate an image, you'll need a good Java graphics book. To save that image to the client's machine, you'll need to learn about signed applets and the new security models (check out the JavaSoft Web page documentation). To learn how to save that image to the server's machine, see Java Tips 34 and 41 on POSTing from an applet. Hope this helps,
John D. Mitchell
I have a question regarding "Java Tip 41: POSTing via Java revisited."
How does the Java applet Happy.java indicate that it's calling the servlet
PosterServlet.java? Looking at the code, the closest I could see is
url = new URL ("http://" + ((getCodeBase()).getHost()).toString() + "/poster");
I can't see how it could call
PosterServlet.java. Or am I looking at the wrong section of the code?
John replies: The URL being built in the applet ends up being something like "http://www.javaworld.com/poster". Now, in setting up the server to provide
PosterServlet as a servlet, you have to follow the directions appropriate for each particular Java-based Web server to install and configure the servlet so that it's called for the "/poster" URL. The basic steps for installing the servlet into Sun's JavaWebServer is given at the top of the PosterServlet.java source file. John D. Mitchell
Under the Hood by Bill Venners
Class loader objects
I am doing an in-depth reading on the Java Security Model and the insides of the JVM. For this I have been referring to your Under the Hood column published in JavaWorld and also reading the beta version of your online book Inside the Java Virtual Machine.
I have a doubt regarding the working of class loader objects. You have mentioned that class loader objects are a part of your application and that you can create your own class loader by extending the java.lang.ClassLoader and overriding the
I want to know what happens when I write an application but do not have my implementation of the class loader (which is usually what happens in most cases). From where is the default class loader object that will load the classes of my application created, and what is this default class loader object?
To load an applet, you say, the Web browser fires off a Java application that installs a class loader object -- usually called an applet class loader, which in turn fetches the applet class from across the network and loads it. How does this similar functionality work in case of Java applications?
Also, I read somewhere that each application has an instance of JVM associated with it. This means that if I have three Java applications running on my machine there will be three instances of JVM running on my machine. If I have my own implementation of class loader objects loading the classes of my application, will it be possible to have more than one class loader object in a single instance of the JVM? If so, how is this possible?
Piyush, Page eight of my book, still warm from the publisher, says:
A Java application can use two types of class loaders: a "primordial" class loader and class loader objects. The primordial class loader (there is only one of them) is a part of the JVM implementation. For example, if a JVM is implemented as a C program on top of an existing operating system, then the primordial class loader will be part of that C program. The primordial class loader loads trusted classes, including the classes of the Java API, usually from the local disk. At runtime, a Java application can install class loader objects that load classes in custom ways, such as by downloading class files across a network.
The difference between class loader objects and the primordial class loader is important. The primordial class loader (the "default class loader object" as you call it) is not an object at all. It doesn't have a class that descends from