<Since, Matthew, I know you're on the list,
I'll just address this response there...>
Matthew Pocock wrote:
> This would be helped greatly by being able to launch an application with a
>command like:
>java -jar http://javasource.somewhere.com/application.jar
>I think at the moment that the -jar command only works for local files but I
>would love to be proved wrong...
I think you're right, but there is a jar-reader application 'JarRunner'
that does what you want. It is described and built in the Tutorial
on 'Using Jar-relared API's in J1.2' Usage is:
>java JarRunner url [args]
You need to add a line in the jar manifest file to identify the 'main' class.
I'm not sure what you have in mind here.
A J3D player loaded this way would be about the same size
as the j3D install exe - that's 3.67MB, which would be
a long download for the average user just to see some content.
Also, it looks to be a big security risk since there is no bar on
the application launched from binding to native system code and then,
if someone spoofed the J3DPlayer with a bogus application, it might
come in and erase your disk. This is one of the nice thing about applets,
ie. they are (by default) prevented from doing evil things...
It's the same reason the J3D classes, for example (since they include
native code), cannot simply be referenced as an network 'Archive' tag,
or referenced by the 'Class-Path' tag in the manifest file for the applet jar.
This is why, if I understand what Don is outlining below, the J3D classes,
and others, could not just be pulled in by a 'super' ClassLoader, that
is, could not by applets under stringent security safeguarding. In the
case below, the super 'JRE" as described below would have to contain
all the native classes, including much of J3D. It would be interesting to
know the size of the standard extensions that use native code. This
is the part that must be installed as an application or Browser plug-in.
The rest of the classes could live elsewhere. However, in support of an
applet they would have to live on the same server which hosted the
applet - this would kill the idea of a few big mirrors holding the 'support'
jars.
If there are clever ways to go forward I would really like to hear them.
It seems to me either there has to be a plug-in or application
download somewhere - unless, as someone else mentioned, the jdk1.2
and the media extensions are loaded on the machine by the PC vendors.
That's a great idea if they will do it - but, I don't think I'm being cynical
by suggesting that the Evil Empire would strongly discourage the vendors
from doing that. Also, I'm not sure there has been a groundswell of
support for the idea...
Mark
Mark Rudolph
[EMAIL PROTECTED]
Lucid Actual
Montreal
>Matthew
"Casteel, Don" wrote:
> I agree completely. Java is extremely difficult to set-up, keep in mind that
> for web based content we should be invisible to the user. At the very least
> need installations that children or novice computer users can deal with.
>
> I'm sure this is way over simplified, and I certainly don't have enough
> background or experience to even be making these comments. But it's
> something I've been thinking about and thought may stir up some helpful
> conversation.
>
> Anyway, here goes........ (please be kind in responding)
>
> One thing that has come to mind lately is setting up all of the Java classes
> on distributed mass servers, eliminating plug-ins and individual setups on a
> users computer.
>
> It seems to me that Java was designed and built to work with the web,
> integrated to the web, however in and of itself Java doesn't seem to take
> advantage of it's own strongest capabilities.
>
> With a few limited HTML commands and local applets which reference a URL
> based Java implementation the rest of Java should utilize it's own inherent
> capabilities. This way we don't have to rely on the browsers to catch up to
> Java. Everything could remain current much more easily with just a few
> mirrored server sites containing the implementation classes. The classes
> once set-up correctly would control their own inter-communication etc...
>
> The only thing which could not be done this way is the JRE engine itself
> which would easily be an auto-download/update plug-in.
>
> Now I do of course realize this is somewhat of a pipe dream, some classes
> are much to large to access across the web when needed, traffic is a
> problem, and security could become a nightmare. But bandwidths are improving
> and these ideas could be built on without changing much of anything, if
> anything at all, with current implementations.
>
> I guess what I'm trying to say is Java has a lot more potential to become
> invisible if we utilize some of it's own existing strengths.
>
> <snip/>
> > =====================================================================
> > To subscribe/unsubscribe, send mail to [EMAIL PROTECTED]
> > Java 3D Home Page: http://java.sun.com/products/java-media/3D/
> =====================================================================
> To subscribe/unsubscribe, send mail to [EMAIL PROTECTED]
> Java 3D Home Page: http://java.sun.com/products/java-media/3D/
=====================================================================
To subscribe/unsubscribe, send mail to [EMAIL PROTECTED]
Java 3D Home Page: http://java.sun.com/products/java-media/3D/
