🚀 go-pugleaf

Jason:

Pop over to http://www.got.net/~rwilkman.  Under Applet Basics is a
copy of the talk I did on "why you shouldn't write applets".  At
least, that was the sub-title some folks thought of.

There are a lot of issues surrounding applets that make them the
absolute wrong choice to solve a problem.  Much of the garbage folks
stick in applets on their web pages could be better handled by CGI,
DHTML or some other task specific tool.  The Applet concept certainly
isn't new and when used "properly" isn't too demanding on the client.

In the rough form that I think I understand what you are trying to do,
why not write a servlet.  With a servlet you could handle all the file
stuff that the Applet security model won't let you do.  The servlet
could then talk to the applet, which is what your clients would see.

While you can't place all the blame at NS and MS, the fact of the
matter  remains that if any of your clients connect with a modem you
should stick to the last generation of Java.  No JFC, etc. because
that's a lot of stuff to shove down the pipe every time the applet is
run.  In that instance the responsibility falls on the Applet
developer to choose the component set they want to use and weigh the
costs to the end user.

-Rich

Jason Terando wrote:
> 
> 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

-- 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rich Wilkman
Senior Quality Assurance Engineer
Borland JBuilder Team

If you see something that looks like an opinion up there,
it's mine and mine alone.

Mail sent to me from the newsgroups won't bounce but will
be ignored.  If I have time, I'll respond, but you  have
a better chance if you confine your posts to the newsgroups
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=