Topics:
The JDK package for Window NT/95 comes in a self-extracting format (.exe). The standard installation procedure is to cd to the directory in which you want to do the installation (c:\ is the usual choice) and then type the file name (minus the ".exe"). The package will then extract and install itself.
First, if you got a .exe file from us, all you need to do is run it as a command at a DOS prompt (probably best done at c:\) -- it is a self-extracting archive and will install all the necessary files on your system.
On the other hand, if you downloaded one of our .zip files, you definitely need is another zip/unzip program -- pkunzip truncates the file names to the old 8.3 DOS file name limits, which won't work in Java. Try this version, which should correctly handle the longer file names and capitalization.
We've also heard that WinZip95 will work with long file names, and that is available from http://cwsapps.texas.net.
The "Unable to initialize threads" message most commonly arises when the Java interpreter cannot find the basic class files it needs in order to run. The Thread.class file is one of these files, and the Java interpreter looks for it in a specific place:
The simplest fix is usually to start from scratch and install a fresh copy.
I solved the problem for me. Here is what I think I did.
We've had some trouble with the PostScript generated by tools we use. The documents work for most printers, but a few have trouble with it. Unfortunately, there's no easy workaround for now (a friend's printer, perhaps?).
Two clumsy alternatives exist if you prefer not the read the whole paper by browsing our site: (1) download the complete html package for the paper, install it locally, and browse it at your leisure from your own machine; or (2) browse each section at our web site and print it out from your browser. You can get at the version of your choice from our documentation overviews page.
We're working towards providing our documentation in a more universally accessible format. We'll post more news about this on our web site as it becomes available.
The method verification error in Netscape could be caused by Netscape caching previous information about the Animator.class and trying to perform the verification with this information, rather than actually loading the Animator.class from the file. Try clearing both the disk and memory cache in the Netscape network options screen and then press the reload button while holding the Shift key on your keyboard to reload your page with the applet in it. This will insure Netscape loads a 'fresh' copy of the class from you local disk.
For more detail on the class and method verification that takes place in applet security please see: http://www.javasoft.com/sfaq/verifier.html
This message appears on stand-alone windows that an applet inside of Netscape creates. This is to flag to the user that the window does not belong to a native application and that the application has several security restrictions (Applets have security restrictions as compared to stand-alone Java applications).
Cursors can be changed in applets. The trick is to loop up from your panel with a getParent() until you encounter an instance of a Frame, and then do a setCursor() on that frame. Here is a code example:
Object frame = getParent (); while (! (frame instanceof Frame)) frame = ((Component) frame).getParent (); ((Frame) frame).setCursor (Frame.HAND_CURSOR);
#Applet exception: error: java.lang.ClassFormatError java.lang.ClassFormatError at netscape.applet.AppletClassLoader.loadClass(AppletClassLoader.java.87)What is going on here?
The ClassFormatError exception is thrown if the data in the class file is not valid. This could happen for any number of reasons:
Modal dialogs currently do not work in JDK 1.0 -- it is a known bug that is being worked on.
As a workaround, if you do not want the parent frame to receive any input while the 'modal' dialog is up, call the disable() method of the parent frame while bringing up the dialog. When the dialog is dismissed, call the parent frame's enable() method. That should effectively give you a modal dialog.
This question may be answered in two parts:
There are freeware/shareware programs to convert .wav files to .au files that can be played in applets. One such tool is SoX, which can be accessed from http://www.spies.com/Sox
Netscape appears to keep hold of the sound driver during its life.
Netscape can probably give you the complete picture but probably the reasoning behind this is that since every html page could in theory have a java applet that might use audio it makes the control of the audio port much simplier if it just takes control of it at the begining so that any error recovery that netscape has to do is located at the start and not deep inside the application.
We are working hard to fix the bugs on our Known Bugs list but we can't promise any specific dates.
All your extra class files need to be located in the same directory as the applet class file itself. (You can also put class files in subdirectories of that directory in the unusual case that your applet has its own packages, subpackages, etc.) By default, the directory for class files is taken to be the same as the one containing the html page. The CODEBASE attribute is needed only if your class files are located in a different directory from the default.
You may be using an obsolete version of Animator. The latest version (1.5) has noticeable improvements in animation performance. You can get it at:
http://www.javasoft.com/applets/applets/Animator/
Is this possible? I have tried several Layout Managers and tried using the .move(int,int) method on the Button and TextField objects with no luck. The objects seem to stay where they originally put themselves.
In the exceptional cases in which you need absolute control over a layout, you can omit the layout manager for a container and set the size and positions of all your components explicitly. Note that each Container object comes with a default layout manager (e.g., FlowLayout for Applets), so you need to explicitly set the layout to be null (see the code example below). Also, using absolute layouts is not recommended for cross-platform applications, since they can easily break (i.e., look lousy) when switching from one platform to another.
An alternative is to define your own custom LayoutManager to do your layout. A general introduction to layouts, including pointers on custom layouts, is provided in the User Interface section of our Java language tutorial.
Some sample code:
/* NullLayout -- An example applet with no layout manager. */ import java.awt.*; public class NullLayout extends java.applet.Applet { public void init() { resize(300, 300); // resize the applet setLayout(null); // don't use a layout manager Button b1 = new Button("button 1"); Button b2 = new Button("long button 2"); Button b3 = new Button("button 3"); Button b4 = new Button("b4"); add(b1); add(b2); add(b3); add(b4); /* Set button 1 and button 2 to their natural sizes. */ b1.resize(b1.preferredSize()); b2.resize(b2.preferredSize()); /* Explicitly position buttons. */ b1.move(10,10); b2.move(10,50); /* Alternatively, you can set size and position all in one go, * using Component's reshape method. */ b3.reshape(40, 110, 80, 40); b4.reshape(40, 150, 80, 40); } }
The Gamelan site carries a large catalogue of applets sorted into broad categories. This site, together with our beta applets page, offer many sample applets that might meet your needs.
javac animator.javaAnd the compiler says:
Animator.java:52: Warning: Public class animator must be defined in a file called "animator.java". ...And it do not create the animator.class. What can I do?
The Java system is case sensitive. The javac compiler will be much happier if you change your file name to
Animator.java
cd e:\www\hotjava\bin javac -classpath e:\www\html\classes junk.jav or javac -classpath e:\www\html\classes junk.javaI get the following message:
javac: can't read: junk.javaWhat am I doing wrong?
Javac uses the CLASSPATH variable to search for classes it encounters while compiling your code. However, to get started on a .java source file in the first place, it needs to find the file directly. I'd suggest you cd to the directory containing the .java file and run javac there:
MS-DOS Prompt> e: MS-DOS Prompt> cd \www\html\classes MS-DOS Prompt> javac junk.javaSimply calling javac will work if you set your path variable to include your java\bin directory (or e:\www\hotjava\bin in your case). Otherwise, you need to include the full path to the javac executable in your command line:
MS-DOS Prompt> e:\www\hotjava\bin\javac junk.java
I have noticed from documentation that Java can call OUT to code, but can we call IN?
I could re-develop existing work totally within Java, but that means re-develop and needing Java where I may not need it (or have it)
Today's Java doesn't support the notion of embedding, or otherwise running Java code within a client frame. Netscape did it in their application by including the complete Java Virtual Machine (also referred to as the Java interpreter) in their latest Navigator beta.
Note that Java is appropriate for writing machine-independent applets and applications, especially if you want to distribute them effortlessly via the Internet. The moment you mix in C or C++ code, you've lost those features. If machine independence or Internet distribution is important to you or your clients, it may well be worth the effort to rewrite existing C or C++ code in Java.
Thanks - we always welcome such suggestions and pass them on to the applet's author.
You can use MS-DOS Prompt (in Start->Programs) to run all your Java commands. MS-DOS Prompt, thank goodness, does not provide full DOS emulation :-)
Is there any support for this? Shouldn't this be built into the base AWT classes?
Missing events was a bug in our initial Beta release and should be fixed with the new event model in our Beta 2 release. A brief explanation of the model is available in our Java Developers Kit FAQ.
We haven't provided support for tabbing between TextFields in our base classes, but the new event model should make it possible for you to implement your own subclasses to handle this. I'll pass your message on as a feature suggestion.
The Animator applet depends on three class files:
You can order t-shirts and other Java merchandise through our SunWare Catalog. See http://e-web.ebay/cgi-bin/sunware_catalog.pl.
Although we can't make recommendations, here are some resources that you might find helpful. One resource independent of Sun that provides a comprehensive list of Java books is Cye Definitive HTML Book List.
Our group is working on a series of books on the Java programming language. The first group of The Java Series is due out early June. If you are interested in creating applets for web pages, you may also want to check out "Hooked on Java," written by three members of the our group.
For information about this and other questions, check out Sun Microelectronics' press release.
Currently, we do not support video in any form. Our initial focus has been on defining and implementing the 1.0 Java Applet API, with support for simple sounds and images. For the future, we are looking into supporting a richer range of multimedia capabilities.
Presently, the Java language only supports the first 256 characters of Unicode (i.e., iso-latin-1 characters). We will eventually support all Unicode characters.
Pkunzip cannot handle longer file names, so you'll need to use a different zip utility that can. For details on this and other known problems, see the "Hooked on Java" web page.
IBM's Java Info site has recent announcements about Java on OS/2, AIX and Win 3.1.
We don't have official guidelines on hardware requirements, but here are some ballpark minimums:
You can get the ".java" extension if you use a text editor that allows long file names (for instance, Notepad). In general, Java requires support for long file names, so be careful not to use any DOS-flavored programs that might truncate your file names to 8.3 limits behind your back.
To help us diagnose the problem, try starting HotJava again, using the -verbose switch:
\hotjava\bin\hotjava -verbose (for Windows NT/95) hotjava -verbose & (for Solaris)visit a local demo URL, visit a remote URL, quit HotJava, and then send me copies of your access_mode, properties, and weblog files (in your .hotjava directory). Also, please send me info on your hardware/software setup and verbatim copies of any error messages you see in the process.
We don't keep a developer/consultant list in our group, but there are some resources for Java information independent of Sun that might be helpful to you: