I am researching possible ways to deploy an existing Java Swing application in a browser such that the client would not need to have a Java runtime installed (and "plugged into" the browser).
The application including the UI would need to run on a server, but the GUI should then "somehow" be rendered in a plain vanilla (of course JavaScript-enabled) browser. Performance and scalability are for once not an issue here...
The challenge is to get away with minimal changes or wrappers of the original Swing application.
I am aware of Eclipse RAP that allows something like that and using the SWT_AWT bridge it should then be possible to embed the Swing UI inside an SWT wrapper and render that on a browser.
I wonder, whether there are any other alternatives or approaches that come to mind?
Cheers,
Michael
AjaxSwing (formerly known as WebCream)seems to promise to do exactly that. I have no experience using it myself however.
Slightly related, but probably no direct help: someone has done the same to the GTK 3 UI Toolkit.
Related
I'm making a database for my project (wirtual clinic) which will be a web application, but here is a thing.. I want in order that my app will based on a JavaFX (MVC pattern, where in View segment I could use .fxml files edited in SceneBuilder) is this solution possible?
If you need a web application running in a browser with a backend in a container, then you cannot use JavaFX. But you might try Vaadin. There you can use either Java code or HTML to build your application. They also sell a designer application.
The http://javafx-samples.com/ mentioned in the other answer shows a JavaFX application running as a server process and mirrored thru the network using JavaScript. This is technically admirable and might work reasonably well for your use case but you should keep that in mind when comparing it to client side JavaScript solutions.
It will not work well for flaky internet connections and extending it will have limits since it would require both Java server side code and JavaScript side code.
Such architectures have been used extensively in the past (e.g. Echo2, AjaxSwing etc.) and they all never gained serious traction even when compared to similar architectures such as GWT.
There are now several client side JavaScript based VM's including TeaVM which are pretty amazing and can produce pretty good results entirely on the client e.g. we used this VM in a recent demo.
Of course it is possible, but with the plugin and updates problems.
Some solutions are in progress. You can check this site:
http://javafx-samples.com/
It is promising I think because you don't need plugin.
can I create Gui in html5/JS for the desktop java application. If yes, what tools I need and how would I connect GUI with java code?
Possible - but not entirely sure why you'd want to do that.
Your main options would be:
Have the Java application act as a local web server and connect to it with a browser. Would be a wierd design but fairly easy to make it work. It's essentially the same as you would do if you had a remote Java web server so the components are pretty standard - you could use a toolkit like Vaadin for example.
Run JavaScript within a Java hosted environment / embedded browser. Should be possible with Rhino - though I must admit I haven't ever seen this approach used to build a desktop GUI
The first option in particular might make sense if you were considering using the application remotely at some point in the future.
Overall though, I'm still not sure if this is a good idea. The JavaScript web frameworks still aren't IMHO as good as the native Java ones (SWT, Swing or JavaFX) for building local desktop application GUIs.
Thanks for your answers to my previous question about GUI in java. I now wonder what are the solutions chosen by professionals to get a nice GUI, for "real" applications. Do you use swing and JComponents and just change the "look and feel" ? Do you prefer awt or another library ?
Sorry if that question sounds weird, I'm a student and I don't really know how java is used in the real world...
In our company we use Swing, as that is supported by the JVM out of the box, but we do use color coded background colors for some panels and buttons.
If we'd use something different, like SWT or Jambi we'd also have to roll out those frameworks for all platforms, and test those frameworks for all OSses and (supported) java versions. Not nice at all.
It is however fairly tricky to create a nice responsive application with Swing; so you really need to use SwingWorker and the like. With a bit of experience however you can create a nice application that way.
And even if it isn't the fastest framework to develop in, development time is really small compared to defining the functional requirements of the user interface, and testing and support when the version is released.
That said, our target is desktops. If you target mobile devices or also need a web frontend your choices may vary.
I don't believe anyone prefers AWT anymore. Swing supplanted it entirely eleven years ago, building on top of it to correct flaws in the AWT 1.0 design.
Swing isn't the only way that professionals make Java UIs. That works for desktops, but there's also JavaFX now. For the web, UIs are built using HTML, CSS, JavaScript, and JSPs.
My experience is that most organizations that want to create rich GUIs still use Swing, and manually go through all the annoyances of layout managers, etc.
The use of SWT is fairly limited to organizations that are using the Eclipse RCP as their platform. I'm not sure why it hasn't caught on outside this platform.
It's sad to admit, but Java Swing GUIs don't generally look good unless you spend a lot of time creating a more native feel for them. Even then, they often lose out on aesthetics to equivalent programs written specifically for Windows and which use Window APIs like WinForms.
The most decent Apps I saw in the last years were build using Eclipse Rich Client Platform
Eclipse uses the Standard Widget Toolkit
and provides Graphical Editing Framework (GEF)
We typically use Swing becuse it's supported in standard JREs out of the box. Normally we do the initial form design and event hookup in Netbeans and then export it to whatever we wish, Eclipse, for example.
Netbeans spits out pure Java using standard libraries (plus a jar or two you have to include) so it's no big deal designing the form in Netbeans and later moving on to something else.
Some people suggested doing form layout by hand using a layout manager. I see that as an option only if you are doing something big and very well budgeted that has to be maintained ad infinitum. Otherwise it's just too time consuming to be worth it.
We rely on SWT for our Java GUIs. Yes, you have to include an external native library, but the look and feel is native, more responsive (although Swing has become much faster in the past few years) and seamless with other apps on the target platform.
Macintosh OS X creates their own Java runtime. They give Swing components the same look and feel as native applications.
I use strictly Swing. I distribute "real" desktop applications via Web Start for both Mac and Windows that interface with the user's smart card reader.
The NetBeans IDE gives you a WYSIWYG way to create your forms. I've tried it out, and it's pretty neat, but we still use Eclipse as our IDE and design the forms in code.
I need to create a GUI application in Java. I just realized that I have different optional ways to go (SWT and Swing are among them).
I have already found out that there is a lot of discussions about what way is better and I do not want to go to deep into these discussions (I am a newbie).
I do not care about all aspects of the dilemma. I just have a few main requirements listed bellow:
It should be easy to use (easy to create what I want).
In the end I would like to have just one file which can be easily executed (without any additional tricks, settings and installations) like a standalone application.
It should be platform independent. Or more specifically, the application should work fine on Microsoft-Windows and Ubuntu (Linux).
Based on your requirements, I would say Swing. SWT has a more platform-specific look about it but Java ships with Swing built-in, there's no messing about with external libraries as with SWT although the use of Eclipse may make that much easier (I still develop quite a bit of my stuff from the command line unfortunately).
They're both easy in terms of use (well, easy once you get used to layout managers) and will work fine under both your desired platforms but since the only differentiator you seem to care about is the "without any additional tricks, settings and installations", I would stick with Swing.
That's my advice. Feel free to accept or ignore or even call me an old coot. I won't take offence :-)
I just completed a two year project creating a buisiness application, so my focus was clearly on usability and speed.
My decision in the end clearly led to SWT, for the following reasons:
Buisiness users tend to use Terminal Servers and RDP for their apps. Every Swing app is very slow over RDP, because the app has to render every pixel again and again. Try using Photoshop or Gimp over RDP and start scrolling in an image. That is the performance you have with Swing in tables.
Some very good gui components are only available as COM objects. I wanted to be able to use those, and since 100% of all buisiness customers are Windows users, they accept the fact that your software only runs on Windows. (We have linux clients, too, but only for machine input terminals, that don't need the full blown Windows GUIs)
We use SWTDesigner as a GUI designer, which is as good as SwingDesigner für Swing (which both are the best GUI designers at all). They are worth the price tag if you have to create a few hundred masks.
Our GUI looks 100% native, honors the large fonts they use on their desktops, and feels fast.
We are very satisfied with SWT, but it has some downsides:
Native Java components are a bit rare. There is more on the Swing side of life.
I would suggest that you use Java's Swing libraries if you are not familiar with Java GUI development. They are very well documented, and there are lots of tutorials on-line, including on Sun's Java website (here).
GUI development in Java is not very straightforward, but the tools available are getting better all the time. I would suggest you try out the NetBeans IDE that has a nice visual designer for GUI components. I have not used the Eclipse IDE's GUI designer, but I gather its good as well. You will need to get your head around the MVC pattern, but it should be a good learning experience.
In short, my vote goes for using Swing/JFC, especially if you are new to Java GUI development.
EDIT - You can control the look and feel of a Java APP very easily. If you use the platform independent (Metal) look and feel, your GUI will look pretty much identical on Windows and on Linux. Of course, a Java app will run just fine on Windows of *nux as long as there is a supported JVM installed.
I cannot add comment yet because I'm new here (please mod me up so I can comment) but choosing Swing or SWT depends on the IDE you're using.
If you're using Eclipse, then both are fine.
If you're using the free IntelliJ IDEA community edition, you'll prefer to use Swing because the IDE's GUI editor is "Swing only".
I take it you're using Eclipse?
Based on your requirements, I recommend using Swing:
SWT requires additional native libraries (violates item #2),
You are likely to find more instructional material on Swing (since you are a newbie),
Both solutions are somewhat platform independent and supported on both platform you mentioned but SWT is not equally supported on all platforms,
There are more WYSIWYG tools supporting Swing which may help with the learning curve.
Note that the APIs are similar and sometimes identical so learning one gives you a head start on the other.
I find Netbeans' drag and drop visual editor and pre-wired Swing Desktop Application template much easier to use that what comes bundled with Eclipse, so I'd suggest that.
It'll automatically create an executable jar, and let you create a Java Web Start launcher if you wish as well. And being Java, it's OS-independent.
Here's a link to the quickstart tutorials.
Swing,
SWT works on Ubuntu but not nearly as well as on Windows, that's at least my experience. The main reason to choose SWT is if you want to build your application on the Eclipse RCP framework( where you get a dockable views/editors, plugin mechanism, automatic updates, user roles. help browser, preference mechanism etc) or if you want your application to have that polished native look.
From my experience, if you want easy to develop Swing is the way to go. If you need good performance, then SWT is a better bet.
NOTE: The last time I did GUI development in Java was 4 years ago.
I've looked breifly into GWT and like the idea that I can develop in Java and have the application compile down to HTML and JavaScript. Is the concept behind GWT and AWT and Swing the same or different?
It is programmed very similarly(patterned after Swing) and the code is 100% java (compiles with a standard Java compiler without errors), but the way it works is very different. Instead of compiling into a Java app, it compiles into Javascript that is sent to your browser.
This ability to program good active Javascript without actually coding Javascript and HTML is pretty nice.
Also, since it programs much like swing, you can do stuff like adding listeners that effect other controls pretty easily.
GWT is very much similar to Swing in its usage of Widgets, Panels and the EventListeners it provides. A different way to look at GWT is to think of Javascript and HTML as Assembly language and GWT as a sort of High level language which generates Javascript and HTML. With GWT its easy to develop desktop-like apps for the web using the same tools you would use for building a desktop app
Define concept.
AWT/Swing are used for desktop Java apps or applets. They both require JVM to run.
GWT is used to translate Java code to Javascript. This only runs on Javascript engines, i.e. browser.
The API design, as stated above, is similar to Swing. You get the same Panels, Buttons and other Component classes as in Swing.
AWT and Swing are for programming stand-alone applications (and to a lesser extent, applets). GWT is supposed to make programming web applications similar to stand-alone apps. I wouldn't program a non-web app using GWT.
GWT is conceptually similar to Swing, but is more a replacement for JSPs than anything else.
GWT is a javascript toolkit that allows you to write the javascript in Java. The only real similarities to Swing and AWT are that they are toolkits for creating user interfaces and they use Java. The end product is different and the real purpose for using them is different. GWT gives you the ability to generate a ajax user interface for a web browser while the other 2 give you a console (or applet) java app. In my mind the real reason for using GWT is to get a quick ajax interface up for prototyping purposes. But I dont think its really production ready- ie I dont thing Google uses it in their own webapps. A better choice for more robust ajax webapps is http://developer.yahoo.com/yui/ or http://script.aculo.us/.
disclamer: While I do work at IT Mill, this is just for information to the original poster. This isn't marketing spam.
If you like the idea of being able to write Java and get a webpage out of that, you might be interested in IT Mill Toolkit. It's a toolkit for making RIA software on top of a J2EE stack, and it uses GWT heavily.
One of the basic ideas are that the code generated by GWT is just as prone to client-side forging attacks as any other JS/Ajax-traffic. IT Mill Toolkit makes sure that the data is validated server-side too.
The toolkit is also designed in such a way that if you are familiar to Swing, you should have no problems picking it up.