The Aladin project goal is to help to the cross identification of astronomical objects. To do that we have implemented a software displaying Schmidt plate scans on which we can superimpose catalogs and database field charts. The image scans come from the MAMA machine at CAI (Guibert 1992), and from the STScI for the DSS1 and the DSS2 (Lasker 1994). The overlays come from the Simbad database (Wenger et al. 2000), the VizieR server (Ochsenbein 2000) with its two thousand catalogs and the NED database (Madore et al. 1992).
After a first release using the X11 technology, we decided to build a Java prototype to implement the Aladin user interface as a Java applet. Two years ago, the applet concept seemed to be a good technical solution to solve two problems that we had encountered with the X11 implementation:
A Java program is compiled only once on the development machine. The executable code, called P-code, is downloadable and runnable directly by most current browsers. To run the P-code the browsers integrate a Java virtual machine, called JVM, which is able to execute the P-code. Consequently, the Java applets don't require any installation and all platforms supporting a Java enabled browser run them immediately.
These features have certainly been the reason of the Java language success. However, there are presently relatively few applets on the net. In fact, the Java softwares are very often distributed as standalone applications requiring not only their own installation but also the Java virtual machine installation.
This fact can be explained by these four typical applet user questions: Why is it so slow to start up? Why is it so slow to run? I cannot print ! I cannot use local data ! It works on Netscape but not on IExplorer ! Behind theses four reactions, there are four applet problems.
Each time a user wants to run an applet, its P-code has to be downloaded through the network. Nowadays, a software having a few megabytes is quite common, but for a Java applet, with the present internet bandwidth, it is strongly recommended to limit its size to a few hundreds of kilobytes.
It means concretely that making use of the additional packages (3D-image manager, XML parser, ...) is not recommended in an applet because such applets are generally too big to be downloaded.
A good JVM implementation is generally 2 to 5 slower than the C equivalent code. But now, another aspect of the JVM performances appears with the new 1.2 Java release: some foundation classes, which come with the Java language toolkit, can be slower in the more recent release. The main reason is that these classes offer more and more sophisticated features. But there are not always required by the application and often heavily resource consuming. We have measured that the same Java code is 10% slower between Java 1.1.4 and 1.1.8, and 34% slower between Java 1.1.8 and 1.2.2
By default, Java applets cannot access to the user machine resources. The main consequences are: no local disk access, no printer access. In addition the network access is restricted to a dialog with the applet server i.e. the machine which sent the applet code to the user machine. The new concept of ``secure applet'' allows one to remove these restrictions, but practically, it is no easy to implement this feature (Netscape and IExplorer have different standards) and only the most recent browsers support it.
Java is claimed to be always compatible... but there are two major problems:
|Release||Browsers||Packages||Aladin java current usage|
|1.02||NS2, NS3, IE3||8||8%|
|1.1.x||NS4, IE4, IE5||20||87%|
A first solution to overcome these problems is to ask to the users to update their browsers according to the java release of the applet that they want to execute. But in doing this, we loose the applet concept and, as the table shows, it seems that the users are not updating their browsers - most likely they just change their browser when they replace their computer.
The second solution is to use only the compatible Java features. It means that if a developer wants to allow 90% of Web users run its applet, he has to restrict his Java development to the 20 Java 1.1 packages. And for example, if the developer uses the Swing package, he should be aware that two years delay and perhaps more will be required to reach the majority of the web users. This fact is certainly the most unpleasant problem with the Java applets.
In spite of these applet constraints, the first release of Aladin Java has been accessible since January 1999. Presently, this applet has the following characteristics:
As we have shown, developing true Java applets that can be executed by every Web user implies difficult choices from the developer's point of view; but if he is ready to do them, he can take all the benefit of this great concept. Aladin applet has been accessible by adding just a new link in our home page (http://aladin.u-strasbg.fr/AladinJava), and now we have more that 200 queries per day (images + overlays) and only 2 user questions per month.
Bonnarel, F. et al. 1999, in ASP Conf. Ser., Vol. 172, Astronomical Data Analysis Software and Systems VIII, ed. D. M. Mehringer, R. L. Plante, & D. A. Roberts (San Francisco: ASP), 229
Fernique, P. et al 1997, AAS, 191, 1705
Guibert, J. 1992, in Proceedings of the Conference on ``Digitised Optical Sky Surveys'', eds. H. T. MacGillivray & E. B. Thomson (Kluwer Academic Publ.), 103
Lasker, B. M. 1994, in IAU Symposium 161, Astronomy from Wide-Field Imaging, eds. H. T. MacGillivray & E. B. Thomson (Kluwer Academic Publ.), 167
Madore, B, et al. 1992, in ASP Conf. Ser., Vol. 25, Astronomical Data Analysis Software and Systems I, ed. D. M. Worrall, C. Biemesderfer, & J. Barnes (San Francisco: ASP), 47
Ochsenbein, F. 2000, A&AS, to be published
Wenger, M. et al. 2000, A&AS, to be published