Hot Tools PopUp Maker code generator, CodeLifter page-code ripper, Scrollbar Styler, more... tons of *free* JavaScript! Click Here! |
|
|
|
Help:
Java: Troubleshooting! |
|
|
- Java
.class files MUST go to the
server in BINARY - never in
ASCII
This
is number one on the hit list of
common errors. If you send
the .class file up in ASCII, the
browser basically can't read the
file, since it's looking for a
binary Java executable.
Variously, the browser status bar
might report a number of errors,
often "class file not
found" - or it may just sit
there dumb as a bag of dead flies.
(This depends on the browser and
version.) If in doubt, send
the class file up again.
- When
first setting up, place ALL
files related to the applet in
the same directory, and make
sure you sent ALL of them up
This
eliminates guessing games about
your pathing, where things
actually are, etc. If you
must use codebase= (we discourage
this with good reason), don't
start pathing things around until
you have the applet running!
Make sure your code is written
accordingly.
Another
extremely common error is omitting
to send all necessary files - like
image files associated with an
applet. Depending on the
applet, that may well stop it dead
or throw it into an error
condition, so always double-check
that everything needed is on the
server, and that it is where it should be.
- Watch
your file names and extensions
on the server
Some
servers - and this isn't that
uncommon - have been known to
change the case (usually
lower-case to upper-case, but
sometimes vice versa) of file
extensions and - rarely - the file
names. The most common
instance of this is an image file
that you sent up as image.jpg, but
somehow arrives on the server as
image.JPG. Bang - the applet
can't find it. The easiest
way to deal with this is just give
in, and rename the files on your
end to what
the server wants.
Even
more common, FTP
Clients (uploaders, that is) can
also cause problems if you
don't watch your settings.
One of the best (we think) and
most common out there, IPSWITCH's
WS_FTP, will give you headaches if
you don't uncheck the "force
to lowercase" setting in the
options. Other FTP clients
often have similar settings.
So, if you see all your files
going up lowercase, you know what
to do! Go hunt down the
options list in your FTP client and fix that setting
to allow uppercase!
(Just
as a technical side note, JAVA
applet file names are indeed case
sensitive and can NOT be changed.
The name of a JAVA applet is part
of its internal identity,
hard-coded right into the guts of
the .class file. Change the
filename of a JAVA applet in any
way, even its case, and the applet
will belligerantly refuse to
function.)
=O=
|
Yes,
yes, we know you hate to do it,
but you gotta. Fully 95% (we
track this) of all of the e-mail
we get about applet problems is
the result of one simple thing:
The code wasn't checked! So
when you get all done checking it
for the twelfth time? GO
CHECK IT AGAIN.
Java
applet tags are not like most HTML,
where you can get away with
bloody murder and still have the
page work. Leave out a
single quotation mark, miss a
right carrot - anything, however
minor, can blow up a Java applet.
The fool things are dead literal,
and they forgive absolutely
nothing in the way of coding
errors in the <APPLET> or
<PARAM> tags.
Most
applets require some external
files to run, frequently image
files. Make absolutely sure
that you have the names right.
These file names are also CASE
SENSITIVE. That means if an
image is named
GeorGe.GiF
and you decide to tell the applet
it's george.gif
- instant
problem, the applet can't find it.
Also
be wary of just where your files
are. If you use an editor or
an environment, especially MS
FrontPage, things might very well
just not be where you think they
are! This is especially true
when you start moving things
around, since most editors and
environments tend to try to
correct the pathing to reflect the
changes in file locations - and
then screw it up dismally for you!
For
the most part, we really recommend
using plain old NOTEPAD for
setting up applets. Even
with all the work we do with
applets, that's what we
use.
Whenever
you're setting up an applet for
the first time, do it from a clean
slate. Start with an empty
HTML page, nothing on it but the
applet. Get the applet
running exactly the way you want
it to - and then and only then
move it into the page where you
want to use it. Again, this is
based on experience across years.
The clutter of a busy page, even
for experienced coders, can cause
you to miss things that would jump
right out at you on a clear,
simple page in NOTEPAD.
We
also strongly recommend that you
start with ALL the files required
by the applet in ONE PLACE.
You can get fancy later with
pathing and codebase= if you wish
- but get the applet running
before you confuse matters with
that added complication.
Although
applets readily accept referential
paths in their parameters for
their own resources (image files,
etc.), most applets will not
cooperate with you if you try to
set link parameters that way.
In most cases, an applet is going
to want to see a full, explicit
path in the standard format, thus:
http://www.sitename.com/page.html
(note that the
page.html part is optional, but the URL is
not).
It's
obvious from that, of course, that
the links must be live to work...
and that means you usually can
only fully test out an applet
after you've loaded it to the
server.
=O=
.
|
.
This
is one of the areas that
constantly drives newcomers real
close to crazy. You changed
an image for the applet - you
absolutely know you did - but
you open the browser and... the
old image is still there!
This
can happen with other applet
resources, too, but it's most
common with image files.
Regardless of whether you use
Netscape or Microsoft browsers,
you're going to run into it, so
pay attention to this one.
The
browsers do NOT properly inventory
graphical resources (and sometimes
others) that are used with
applets. This applies both
to when you're live to the 'Net,
and when you're working off your
hard drive.
The
work-around, fortunately, is
simple. When you run into
this problem, do the following:
- Close
all running programs if you're
using MS Internet Explorer...
even having Outlook Express
running may disallow proper
cache clearing. (You don't
need to close everything with
Netscape browsers - but it's
not a bad idea.)
- Go
to a neutral site. By
that, we mean any site but
your own. (If you try to
clear the cache on the page
where your applet resides, it
may or may not clear.)
- Clear
your browser cache thoroughly.
In MSIE, make sure you clear
the offline content as well.
In Netscape, be sure to clear
both the disk and the memory
cache.
Normally,
that will get everything cleared
so your latest changes will work
properly. In some few cases,
though,
you
may, however, have to actually
reboot (notably on unkempt, improperly
updated versions of Windows95).
A
side issue related to this that you should
keep in mind is, whenever you
change the set-up of an applet on
an active page on your site, you
should probably change the name of
that page. Otherwise, the
potential exists for frequent
visitors who have not cleared
their caches to see old material, rather than your latest revisions.
Changing the page name forces the
browser to see the page as
completely new, uncached material,
and eliminates this problem.
=O=
.
|
|
  |
|
|