allen petersen wrote:
>
> you know, it would probably make a whole lot more sense to integrate the jvm
> with something like gnome or kde rather than with the operating system itself.
> that way you skip the various xdisplay problems (since you'll necessarily have
> an x environment associated with your session) and you don't have suid problems
> (since it should only be for one user). admittedly, this wouldn't help much
> for running remote clients, or with running text-based apps without an x
> environment... still, the time that most people notice slow startup times is
> when they're trying to start up gui apps in java, and it would handle that
> case.
>
> just a thought.
And an excellent one at that. The desktops have evolved into providers
of significant services... adding a Java service fits, and solves some
big problems. It will take some thought to do it well - to integrate
with the desktops' object model in the most effective and natural way -
but doing so should provide a solution to some of the other problems you
mentioned.
Nathan
>
> -allen
> [EMAIL PROTECTED]
>
> On Tue, Jan 23, 2001, 14:11, Nathan Meyers <[EMAIL PROTECTED]> wrote
> >Yavor Kolarov wrote:
> >>
> >> There are some additional problems.
> >>
> >> If we have a wrapper starting all programs it has to be able to:
> >> - open news windows and frames on a specific X terminal. ( User A running
> >> Java application on localhost:0.0 and user B on localhost:1.0)
> >> This raises the question:
> >> Is it possible to choose(under Linux) on which X terminal to draw graphics?
> >
> >This is one of the biggest problems in implementing an app server that
> >can handle arbitrary programs -- and why real app servers work in highly
> >constrained environments like servlets or EJB.
> >
> >The problem is that the connection to the X display happens when the AWT
> >native library is first loaded. It's a single connection that is used
> >through the life of the JVM. As currently structured, the AWT won't let
> >you associate different objects with different X connections. It would
> >take some work (possibly deep architectural rework) on the AWT to do
> >what you're asking.
> >
> >Nathan
> >
> >
> >>
> >> - for terminal apps it should be possible to do I/O on different ttys. This
> >> should be easier to solve since it only requires redirection of two
> streams.
> >>
> >> Yavor
> >>
> >> On Friday 19 January 2001 19:34, Yavor Kolarov wrote:
> >> > Thanks to everyone who replied!
> >> >
> >> > It is clear that JVM can't be part of the kernel. Because of three main
> >> > reasons:
> >> > 1. Java is not GPL'ed
> >> > 2. the more code in the kernel the worse. Java is too big and not so
> >> > stable.
> >> >
> >> > Here is one possible design:
> >> >
> >> > 1. At boot time a wrapper is started in the user space as root. It may be
> >> > written in Java with some native code if needed.
> >> > Running the wrapper as root raises a serious security problem [1].
> >> >
> >> > 2. When we want to start a java program we make a request to the wrapper.
> >> > It loads/reloads the class from the requested a .class file in the user's
> >> > CLASSPATH and calls its Main(String args[]) in a new thread. Here there
> are
> >> > two problems:
> >> > - if the class is loaded and then changed what we need to reload it
> [2].
> >> > - if we reload the class and what happens to another application
> which
> >> > uses an old version ov the class? [3]
> >> > - we have to solve the problem of different CLASSPATHs of different
> >> > applications.[4]
> >> >
> >> > [1] This can be solved with a good SecurityManager which checks all that
> >> > the kernel checks when running user applications: file permissions, ports
> <
> >> > 1024. The alternative is have a C wrapper which fork(), chuid() - now
> user
> >> > security applies and runs java. I have to say that I don't have
> experience
> >> > with JNI. Is there a really cheap way to start JVM from C or add a thread
> >> > to running JVM?
> >> >
> >> > [2] Maybe ClassLoader.findClass(String) or . loadClass(String) can do the
> >> > trick?
> >> >
> >> > [3] and [4] remain open questions
> >> >
> >> > Of course there are surely more problems. These were the only I see but I
> >> > don't know the internals of the JVM.
> >> >
> >> > Also thanks for pointing me to kissme(http://kissme.sourceforge.net/). It
> >> > is an VM with an interesting feature - persistence:
> >> >
> >> > "Supports an extension to the JVM allowing persistent java, which means
> >> > that the JVM allows in-memory data structures to automagically persist to
> >> > permanent storage"
> >> >
> >> > "The persistence abstraction allows the creation and manipulation of data
> >> > in a manner that is independent of its lifetime thereby integrating the
> >> > database view of information with the programming language view."
> >> >
> >> > There is also a link to another persistent Java project -
> >> > PJama(http://www.dcs.glasgow.ac.uk/pjava/)
> >> >
> >> > However I didn't see in the feature list something like JVM shared
> between
> >> > applications.
> >> >
> >> > Yavor
> >>
> >> -------------------------------------------------------
> >>
> >> ----------------------------------------------------------------------
> >> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> >> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> >
> >
> >----------------------------------------------------------------------
> >To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> >
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
