[MUD-Dev] Matt's java problems....
Adam
ceo at grexengine.com
Thu Aug 1 08:41:55 CEST 2002
On Fri, 26 Jul 2002, Matt Mihaly wrote:
> The bad news was that I should have listened to something
> Christopher Allen told me. He said they (Skotos) had investigated
> expanding a java client they have for more general use, but ran
> into a lot of problems with Java, and man was he right. We have
> been unable, for instance, to enable any sort of copying from the
> output window into a clipboard, and are also unable to log
> anything to the player's computer. This inability alone basically
> renders Java unsuitable for a full-featured text MUD client. (And
> while I'm not much of a programmer, if any of you clever
> programmers out there have figured out good work-arounds for this,
> I'd love to hear them.)
1. General important question: How are you running Java?
From the context, it sounds like you're running Java applets
inside a web-browser, rather than as java applications.
This difference is critical, because Sun/Javasoft went out of
their way to make applets "safe" and "secure by default" - to the
extent of being unable to:
- modify local files [ including preventing any local savefiles
!!]
- communicate with the internet [ except with the EXACT same
server the applet was downloaded from ]
- pretend to be an application [ "Warning: Applet window"
appearing at the bottom of every applet window, so that you
couldn't write an applet that looked like "Windows Login" or
similar :) ]
Fortunately, this wasn't just hacked together; Java has a
comprehensive (although I haven't used it enough to vouch for its
completeness) security-architecture, based upon being able to do
things all the time without problems. In the background, every
time a s security-questionable method call takes place, it is
checked with the SecurityManager to see if it should go ahead. If
so, fine, and the programmer probably doesn't even know it
happened. If not, an Exception is thrown - but one which the
programmer doesn't HAVE to handle, so it doesn't introduce
unnecessary extra work if you're lazy :).
SecurityManager's are mainly configured in practice by a textfile
on the users machine.
So, if there's something you can't do because of security reasons
(IIRC, any user can override the restrictions on applets) then
modifying their security settings file might solve things quickly.
From the two problems you listed in particular, both of which are
by default not-allowed for security reasons, I'm guessing this is
your current main problem.
(and aside from serious OS-imposed isssues (see 2. below), which
are outside of sun's/java's control, I've never had any problems
other than security with java clipboard operations, even having
used them extensively)
2. Clipboard problems
If that's not the case, I can only sympathise with your clipboard
problems, and fear there may be nothing you can do. If you run
into OS-clipboard problems, I think the only answer is: You're
****ed.
It was only over the last 8 months when I switched to X11/linux
for my fulltime desktop that I discovered that cut-copy-paste
still doesn't "work" under X-Windows (FYI: [although since I'm
sure several people on this list know/understand this better than
me, corrections are welcome!] there are still [at least] 3
competing standards [Old-X-Windows, KDE, Gnome? / New-X-Windows?]
for clipboard operations, and all are still extensively used by
current applications. Mostly they cannot interact at all, or (in
the case of the changes to X-Windows) they incompatibly use the
same buffers. And different (recent) versions of KDE (IIRC 3.0
compared to 2.x and >3.0) are incompatible with each other,
causing further confusing amongst application-writers.
3. Workarounds
Java Web Start has been going in the right direction to solve many
of this type of "applet security too tight/too much effort for
user to modify" - its an official Java extension/thingy,
accessible from the main java.sun.com page under the products
section.
Under win32, I've seen people "embed" java apps inside win32 apps
(IIRC using ActiveX or similar) so that the user didn't have to faff
about with installing java and / or running from the commandline.
AdamM
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list