> By the way - if you would use a Linux-Server, you could use a 100% pure Java- XServer applet if you really want to have it the way you described above.
I did some searching and found a java rdp client: http://properjavardp.sourceforge.net/
They also have an applet, which would make this a nice java solution for now.
I've developed such a project - but its currently nothing more than a technology preview, a prototype to show wether its possible at all.
The framework is almost complete, but the components are missing.
Its not a 1:1 swing:web interface, but instead it has components which are like their Swing counterparts as far as possible.I even have an adopted version of GroupLayout and Netbeans, so you can create UIs with netbeans :)
The great thing is that development is 2 tier, and you don't have to care what happens on the server. For time-cirtical components you can even include your own classes - but in fact you should be able to write a 1mio lines app and the client still is < 100kb.
It supports lazy loading for images and table-data, and event-handling is like it is with swing, simply register your listeners.
Everything you see in the demo is 100% server-side (layout, values, ...) - and each user-action leads to max 1 server query of needed, 0 if the server can also be notified later (eg. for bounds changes).
Furthermore my framework is extremly scalable - I did tests with a large generated UI - and its no problem to serve 10.000 users at the same time. Because there are no "fat" swing-objects on the server the sessions are really tiny :)
I plan to realize my next large project with it, sometimes in 2009.
The not-so-good thing is the demo which looks like crap and does not reflect the capabilities of the framework and that many components are not fully implemented or missing.
However, what you propose, a direct 1:1 mapping is not possible. A lot of client-server communication would be needed to make this work, which would make it extremly under-performing.
I also experimented with server-side rendering like you did, but it lead to suboptimal results.
By the way - if you would use a Linux-Server, you could use a 100% pure Java-XServer applet if you really want to have it the way you described above.
Message was edited by: linuxhippy
thanks for the response, and very impressive your project! I do think for large acceptance of this the conversion from Swing components to your UComponents will be a bottleneck though.
"However, what you propose, a direct 1:1 mapping is not possible. A lot of client-server communication would be needed to make this work, which would make it extremly under-performing."
Are you sure about this? I mean, Citrix uses the same approach and I know from quite some customers of us that they use it in environments where small bandwidths and many users are involved and they have got good results. For our environment we use remote desktop which is also very responsive, though I have to admit we only use it for a small user group. Not sure how they do it, but I can imagine that you can optimize image screen updates and I don't expect sending over mouse and keyboard events would be too much data to be processed?
"I also experimented with server-side rendering like you did, but it lead to suboptimal results."
I don't suppose you got a trial environment for this as well? I'm curious to see it;-)
"if you would use a Linux-Server"
Our application is quite Windows minded, so this is not an option, but thanks for the suggestion anyway.
1.) Yes I know - JUIBrowser is not a simple drop-in solution, you need to develop for it in order to be able to use it. I would call it as the more noble approach, however you have to invest time in learning the new API's as well as UComponent-ify your existing swing widgets.
I'll use it for converting an old, appet based 3-tier client (~950kb applet size / 55000sloc) maybe next year and I am quite curious about the outcome :)
2.) About your proposal ... I thought about this some years ago. In theory it should work well at least in some enviroments (low latency).
It could be done even more efficiently as Citrix does it, because you could foreward Graphics2D commands directly over network, not beeing forced to grab&analyze the image the whole time.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.