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]

Reply via email to