🚀 go-pugleaf

I guess I wasn't real clear.  What I'm trying to do is to read a file with an
applet, not write it, as it is being appended to.  The server implementation is in
ColdFusion and has nothing to do with Java.

Wanting to get an actual file size doesn't seem that outlandish (I know this a
Java/JVM deal, and not JBuilder) -- getting an acurate file size hosted on a server
shouldn't represent a violation of the security model.

The workaround I have found is to periodically close and reopen the file, seek to
the last position read and try to get any additional available bytes -- the number
still exceeds the number of characters available, but I can allocate an array and
then get the actual bytes read when I read. (Wish "read" was spelled differently in
past and present tense!)

Good enough, I guess...

On the Applet versus Application issue:

A recurring theme on JBuilder newsgroups is that applets are not worth the trouble.
Assuming I have an on-line audience that is not predefined (i.e. I do not have any
way to distribute a virtual machines or an application before a page is accessed) ,
how do I distribute java applications to users when they access my page?

I don't buy the arguement that because Netscape and Microsoft have done a crappy job
implementing JDK 1.1 that the CONCEPT of an applet is useless (although, as a
result, applets ARE almost useless).  Applications such as on-line commerce, which
require rudimentary screen and server I/O, portability and some basic logic, are
beyond the scope of scripts but seem well within a applet's PROPOSED capability.
The compelling case for Java use to make on-line applications is that nothing else
exists to accomplish such tasks on a client (I don't count ActiveX).

If Java's future lies solely in the realm of the Intranet or on the Server, then
there isn't much additional benefit over well-managed C++ code, especially given the
Java performance hit and the haphazard state of JVM's.  Whether I have to re-link
for each platform (C++) or put in kludge code for non-compliant JVM's (Java) - it's
still pain.

Thanks for listening,
Jason