Networked version of Swing (X windows style)?

java-programmer, Networked version of Swing (X windows style)? Hello,

I was wondering if something like that exists or if someone has ever
thought about it:

Instead of Swing updating the local screen and obtaining events from
the local mouse & keyboard, it may be useful in some cases to have a
networked version of Swing, just like XWindows.

Imagine a workstation connecting to a remote JVM that starts a typical
swing application. But this JVM/Classpath/etc is configured so that all
Swing calls are serialized to the remote workstation, where all the
screen updates are made. And viceversa for the mouse and keyboard.

Probably Swing is not well designed for this kind of "pluggability"...
in any case it would be an interesting thing to have.

The key requirement here is that preexisting AWT/Swing applications can
be remotely executed without modification.

Is there any project or product that does this?
If not, any ideas on how to implement it?

Thanks,

Luis.

java-programmer >> Networked version of Swing (X windows style)? Luis wrote:
> Instead of Swing updating the local screen and obtaining events from
> the local mouse & keyboard, it may be useful in some cases to have a
> networked version of Swing, just like XWindows.

All the Unix VMs I have seen work on top of X11 - with the exception of
Apple's VM. So if you run your application on Unix, you can already
redirect the display to another machine. However, especially Swing
applications do a lot of painting by them self, so they generate a lot
of X11 protocol messages on the network. As a result, Java applications
over X11 can show some very bad response times.

Alternatively, running AWT/Swing applications over VNC, without the need
to change anything in the application or VM should work, too.

If you want to use X11 with non-Unix VMs you have some work ahead of you:

> Probably Swing is not well designed for this kind of "pluggability"...
> in any case it would be an interesting thing to have.

Actually, Java is (or better was) in general designed for this. Until
recently, "all" one had to do to get a Java GUI applications running on
something else, was to replace the AWT. More precisely, coming up with
an own implementation of the Toolkit class, if I am not mistaken. In the
past Swing was 100% implemented in Java, exclusively using the AWT for
I/O. So by replacing the AWT toolkit you could also get Swing working on
something else.

However, latest with Java 1.5 the performance of Swing has been enhanced
by using native calls. I have never investigate if, when, where and to
what extend in which VM on which platform native calls are used now.
Native calls will make it very difficult to get applications on non-Unix
systems to run over X11. I would guess you will have to provide some
native-code free PLAF implementation as a minimum, too.

> The key requirement here is that preexisting AWT/Swing applications can
> be remotely executed without modification.
>
> Is there any project or product that does this?
> If not, any ideas on how to implement it?

For a start you might want to look at the following stuff:

http://www.jcraft.com/weirdx/ - X11 server written in pure Java
http://escher.sourceforge.net/ - X11 client library (xlib) in pure Java
http://www.cs.umb.edu/~eugene/XTC/ - Another X11 protocol implementation

I know that a company did once build an AWT implementation in Swing. I
think they even donated it to Sun when the company folded. I have never
heard of it again.

/Thomas

--
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq

java-programmer >> Networked version of Swing (X windows style)? Thanks for the pointers, I will take a look at them.

Anyway the idea was to avoid having to install VNC, X11 or any other
product, as they have their own drawbacks. For example VNC transfers
bitmaps instead of GUI primitives, which makes it much slower.

The proposed approach has several advantages:
- Faster than VNC or, from what you say, than X11
- Smaller and cheaper
- Totally independent of client and server OS (that is the biggest
advantage)

The big disadvantage, of course, is that it would only be able to run
Java Swing applications.

Regards,
Luis.

java-programmer >> Networked version of Swing (X windows style)? Luis wrote:

> Thanks for the pointers, I will take a look at them.
>
> Anyway the idea was to avoid having to install VNC, X11 or any other
> product, as they have their own drawbacks. For example VNC transfers
> bitmaps instead of GUI primitives, which makes it much slower.

If you don't install X11 on a UNIX/Linux system, what graphical display do
you intend to use? Or, are you proposing to write graphics drivers for each
UNIX/Linux/graphics card? That would be fun.

>
> The proposed approach has several advantages:
> - Faster than VNC or, from what you say, than X11
> - Smaller and cheaper
> - Totally independent of client and server OS (that is the biggest
> advantage)
>
> The big disadvantage, of course, is that it would only be able to run
> Java Swing applications.

I think the big disadvantage is that you wouldn't even be able to run Swing
applications :-).

--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : email***@***.com
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555

java-programmer >> Networked version of Swing (X windows style)? > If you don't install X11 on a UNIX/Linux system, what graphical
display do
> you intend to use? Or, are you proposing to write graphics drivers
for each
> UNIX/Linux/graphics card? That would be fun.

No, no, I think I did not explain myself.
To give a simple example:

- Machine A is the one the user is sitting at. In X Windows, I think
this is the Window server.
- Machine B is the one that executes the Java Swing program which will
get displayed at machine B.

- A JVM in machine B is started. It runs a normal Swing program which
at a given moment will create a JButton (in a JPanel in a JFrame, and
other objects are involved which we don't mention for the sake of
simplicity).
But something is different in this JVM of machine B (for example the
Toolkit, as Thomas was saying). So instead of creating those elements
on the screen, a message is sent over the network.

- Machine A reads the message which says "create a JButton with such
and such properties", so it uses Swing locally to do that (this local
Swing is the normal one).

As you can see, X11 or even Unix/Linux don't even get involved in the
above explanation. As I said, it is totally independent of server and
client OS. ...Imagine it as some special kind of Java client/server
application, which interchanges GUI commands and events instead of
business requests and data.

Regards,

Luis.

java-programmer >> Networked version of Swing (X windows style)? Luis wrote:
> As you can see, X11 or even Unix/Linux don't even get involved in the
> above explanation. As I said, it is totally independent of server and
> client OS. ...Imagine it as some special kind of Java client/server
> application, which interchanges GUI commands and events instead of
> business requests and data.

Well, now you are adding another layer of problems to your task:
Designing (and implementing) an own robust, fast enough graphics network
protocol. OK. What problem do you want to add next? Encryption?
Presence? There is for sure no shortage in this area. Maybe you want to
concentrate on some fundamental things, like figuring out how AWT/Swing
do paint things at all?

/Thomas

--
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq

java-programmer >> Networked version of Swing (X windows style)? > Well, now you are adding another layer of problems to your task:
> Designing (and implementing) an own robust, fast enough graphics
network
> protocol. OK. What problem do you want to add next? Encryption?
> Presence? There is for sure no shortage in this area. Maybe you want
to
> concentrate on some fundamental things, like figuring out how
AWT/Swing
> do paint things at all?

Heh heh, I did not say it would be simple... but it would sure be fun!

About encription, Java provides good support for that.
And what do you mean by presence?

Regards,

Luis.

java-programmer >> Networked version of Swing (X windows style)? On Tue, 19 Apr 2005 08:02:41 -0700, Luis wrote:
> - Machine A reads the message which says "create a JButton with such
> and such properties", so it uses Swing locally to do that (this local
> Swing is the normal one).
>
> As you can see, X11 or even Unix/Linux don't even get involved in the
> above explanation. As I said, it is totally independent of server and
> client OS. ...Imagine it as some special kind of Java client/server
> application, which interchanges GUI commands and events instead of
> business requests and data.

There are a couple of attempts at such a thing in existence, I believe.
They typically go by terms like "ultra thin clients" or so. Not all of
these (none of them?) export the full Swing functionality, of course.
Most of these are intended to present GUIs from within browsers.

Think of what you're asking for as an RPC/RMI interface to the swing
libraries.

I think that what generally happens is that the people who want this sort
of functionality really want to produce a particular application, and find
in the end that it's simpler just to go ahead and build that, rather than
be in the business of supporting a full-featured Swing-remote platform...

In this instance: you have an application that you want the GUI to run in
one place and the "works" to run elsewhere. What is the simpler task:
provide a shim for all of Swing, as you've asked, or cleave your existing
application into GUI front end and "works" back-end, with an
application-specific communication protocol between them? I think that
the latter is most likely the easiest, highest-performance option, and is
(IMO) what the Java designers intended.

Cheers,

--
Andrew

java-programmer >> Networked version of Swing (X windows style)? Luis wrote:

>> If you don't install X11 on a UNIX/Linux system, what graphical
> display do
>> you intend to use? Or, are you proposing to write graphics drivers
> for each
>> UNIX/Linux/graphics card? That would be fun.
>
> No, no, I think I did not explain myself.
> To give a simple example:
>
> - Machine A is the one the user is sitting at. In X Windows, I think
> this is the Window server.
> - Machine B is the one that executes the Java Swing program which will
> get displayed at machine B.
>
> - A JVM in machine B is started. It runs a normal Swing program which
> at a given moment will create a JButton (in a JPanel in a JFrame, and
> other objects are involved which we don't mention for the sake of
> simplicity).
> But something is different in this JVM of machine B (for example the
> Toolkit, as Thomas was saying). So instead of creating those elements
> on the screen, a message is sent over the network.
>
> - Machine A reads the message which says "create a JButton with such
> and such properties", so it uses Swing locally to do that (this local
> Swing is the normal one).
>
> As you can see, X11 or even Unix/Linux don't even get involved in the
> above explanation. As I said, it is totally independent of server and
> client OS. ...Imagine it as some special kind of Java client/server
> application, which interchanges GUI commands and events instead of
> business requests and data.
>
> Regards,
>
> Luis.

Yes, that's all very nice, but you've missed one very, very vital step.

What, on machine A, will create the JButton, display it and handle user
interaction with it? Normally that would be X11. But you are not installing
X11 so you need to provide some replacement. This will need to be platform
indepenent in its API, but will need to be able to drive whatever graphics
hardware is installed in machine A, and react to keyboard and mouse events.

How do propose to do that?

--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : email***@***.com
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555

java-programmer >> Networked version of Swing (X windows style)? Thomas Weidenfeller <email***@***.com> wrote:

>Luis wrote:
>> As you can see, X11 or even Unix/Linux don't even get involved in the
>> above explanation. As I said, it is totally independent of server and
>> client OS. ...Imagine it as some special kind of Java client/server
>> application, which interchanges GUI commands and events instead of
>> business requests and data.
>
>Well, now you are adding another layer of problems to your task:
>Designing (and implementing) an own robust, fast enough graphics network
>protocol. OK. What problem do you want to add next? Encryption?
>Presence? There is for sure no shortage in this area. Maybe you want to
>concentrate on some fundamental things, like figuring out how AWT/Swing
>do paint things at all?
>
>/Thomas

There once was a "remote awt" at IBM alphaworks, but it has been
retired, see:
http://www.alphaworks.ibm.com/tech/remoteawtforjava

Maybe something like XTT is what you are looking for:
http://www.insitechinc.com/

java-programmer >> Networked version of Swing (X windows style)? > There once was a "remote awt" at IBM alphaworks, but it has been
> retired, see:
> http://www.alphaworks.ibm.com/璽ech/remoteawtforjava

Yes, that is exactly what I mean. As its description says:

"An implementation of AWT for Java that allows Java applications to run
unchanged in a client/server mode"
I was proposing exactly the same, only with Swing support too. The
"Remote AWT" product was posted as early as 1998!

I still see a lot of advantages compared to writing specific
client-server applications, which of course is much more complex than a
pure local client application.

java-programmer >> Networked version of Swing (X windows style)? > Yes, that's all very nice, but you've missed one very, very vital
step.

> What, on machine A, will create the JButton, display it and handle
user
> interaction with it? Normally that would be X11. But you are not
installing
> X11 so you need to provide some replacement. This will need to be
platform
> indepenent in its API, but will need to be able to drive whatever
graphics
> hardware is installed in machine A, and react to keyboard and mouse
events.

> How do propose to do that?

Well, I propose to do it exactly like X11 does it, but without X11.
So yes, it is complex, I was not thinking of 2 or 3 classes.

And about:

> but will need to be able to drive whatever graphics
> hardware is installed in machine A, and react to keyboard and mouse
events.

Well, that is exactly what Java and Swing do, isn't it? So we don't
have to care about that.

>From the questions you make, I think I still did not explain myself
clearly enough... I am just suggesting a pure Java *replacement* of X11
or Windows Terminal Server, but only for Java programs, of course. If
those products can do it at the OS level, then Java can do it at the
Java level. It's just a matter of proxying and messaging!!

Regards,

Luis.

java-programmer >> Networked version of Swing (X windows style)? "Luis" <email***@***.com> mi? 20 abr 2005 15:38:32 GMT
(news:email***@***.com)
(comp.lang.java.gui)

> I still see a lot of advantages compared to writing
> specific client-server applications, which of course is
> much more complex than a pure local client application.

What you are suggesting could indeed be useful, but it never could be a
replacemente for c/s. When using "remote terminals" (which is what you
are asking for), the whole processing load (even gui event handling!) goes
to the server. This is not reasonable with rich clients, that's what thin
clients are for. A "remote terminal" IS a thin client, but it is of no use
where c/s approach is required.

Choosing c/s is not a matter of complexity, it's an architectural decision
that favours tier separation, band-width optimization, load balancing and
perhaps security issues. A c/s approach is not necesarily more complex
than a non-c/s one, it just has different strengths and weaknesses (for the
most part far more strengths and less weaknesses than remote
terminals, but then, again, this varies with requirements :-D)

And as a first guess, I wouldn't say Swing is particularly well suited for
this. Swing is pretty high-level, whereas what's involved in remote
terminals is purely low-level (just primitive event exchange). With that
approach, I bet you are far better of "running Swing in terminal emulation"
(letting the platform -os- handle low-level events) than "squeezing terminal
emulation into Swing". Why not just coding a local single-tier app and
running it through X11, TS, etc? Java is platform independent, not a
platform replacement.

regards
zn魊t