I want to show my app conveniently without the hassle of carrying a laptop or distributing an obfuscated Java app.
Is there an easy way to view my Swing app in a browser. I do not necessarily need the command buttons to work (but it would be nice if they did), I just want to see the pixels from anywhere on the internet. I have graphs built from JChart2D.
Edit: The screen updates after a configurable period and 15 seconds is typical but if the desktop updates every 15 seconds and the browser image at a much slower rate, say, 1 minute, that would be okay.
Edit: What I have is primarily a desktop app in that it being a desktop app satisfies 98% of the requirements but if I can see it or use it remotely without a re-write that would give me the extra 2% (see it 1%, use it 1%).
For that purpose, the recent Webswing may be perfect. It seems fully functional. There are some glitches and I miss the cursors. Alas, the remote applications are displayed on the server, too, whether you want it or not.
I don't think I would recommend this (because it has security implications and firewall issues) but it is possible to run a Java / Swing application using a remote X11 server.
Here are some relevant links:
Remote X Apps mini-HOWTO
X Over SSH2 - A Tutorial
but there is probably more uptodate information in your Linux documentation.
Another idea is to make a demonstration movie.
There is not many solutions for it but this easisest way is JNLP.
JNLP is an XML-based technology for launching Java executables over the Web. Just imagine that you could specify the classpath resources in your application (images, JAR files, properties, files, etc.), scattered over the Web and giving their URLs, instead of relying on the local file system as normal Java applications do. This feature would give you the capability of deploying your application automatically (that is, installing needed application files and launching them properly) just by declaring where your files are on the Web. And it is far easier than Applets which can create a lot of troubles to you because of strict permissions at browser.
An example of JNLP is here and here.
One other possibility (not necessarily a good one, but easy to implement) might be to use the java.awt.Robot class.
Using this class, you could periodically take a snapshot of the screen, using #createScreenCapture(...), and write this out to disk using javax.imageio.ImageIO.
It would then be straightforward to create an HTML page that displayed this image, and auto-refreshed periodically. A little bit complicated and circuitous, but may let you re-use existing infrastructure.
VNCj (official page, SourceForge) is an older project which provides an implementation of AWT on a VNC server. Swing runs on top of that. Unlike WebSwing, no UI appears on the server when running VNCj.
Related
Problem: I have a standalone Java app (henceforth known as "the agent") that runs as a service on internal company servers. It acts as a remote agent for some central servers. As the agent gets deployed in more places, managing them is getting more complicated. Specifically: pushing updates is painful because it's a fairly manual process, and getting access to the logs and other info about the environments where the agents are running is problematic, making debugging difficult. The servers under discussion are headless and unattended, meaning that this has to be a fully automated process with no manual intervention, hence Java Web Start isn't a viable solution.
Proposed solution: Make the agent phone home (to the central servers) periodically to provide agent status and check for updates.
I'm open to other suggested solutions to the problem, but I've already got a working prototype for the "status and self-updates" idea, which is what this question is focused on.
What I came up with is actually a separate project that acts as a wrapper for the agent. The wrapper periodically calls the central server via HTTP to check for an updated version of the agent. Upon finding an update, it downloads the new version, shuts down the running agent, and starts the new one. If that seems like an odd or roundabout solution, here are a few other considerations/constraints worth noting:
When the wrapper gets a new version of the agent, there may be new JAR dependencies, meaning class path changes, meaning I probably want to spawn a separate Java process instead of fiddling with ClassLoaders and running the risk of a permanent generation memory leak, which would require manual intervention--exactly what I'm trying to get away from. This is why I ended up with a separate, "wrapper" process to manage the agent updates in my prototype.
Some servers where the agents are deployed are resource-limited, so any solution needs to be low on CPU and memory usage. That makes me want a solution that doesn't involve spinning up a new JVM and is a stroke against having a separate wrapper process.
The agent is already deployed to both Windows and RHEL servers, so the solution must be cross-platform, though I wouldn't have a problem duplicating a reasonable amount of the process in batch and bash scripts to get things rolling.
Question: As stated, I want to know how to make a self-updating Java app. More specifically, are there any frameworks/libraries out there that would help me with this? Can someone with experience in this area give me some pointers?
If your application is OSGi based, you could let OSGi handle bundle updates for you. It is similar to the wrapper approach you suggest, in that the OSGi container itself is "the wrapper" and some of it won't be updated. Here's a discussion on this
Different solution: use (and pay for) install4j. Check out the auto-update features here
No need for wrapper (save memory) or java web start (adds more restrictions on your application), simply let a thread in you application check periodically for updates (e.g. from cloud) and download updates if available, then code these two calls in you application:
launch a shell script (.sh or .cmd) to update your artifacts and launch your application after few seconds pause in the script(to avoid having two instances of your application at the same time).
Terminate your application (first instance)
The script can overwrite needed artifacts and re-launch your application.
enjoy !
Have a look at Java Web Start.
It is technology that's been part of Java since... 1.5? maybe 1.4? and allows deployment and install of standalone Java-based apps through a web browswer. It also enables you to always run the latest app.
http://www.oracle.com/technetwork/java/javase/overview-137531.html
http://en.wikipedia.org/wiki/JNLP#Java_Network_Launching_Protocol_.28JNLP.29
also see this question: What's the best way to add a self-update feature to a Java Swing application?
It appears as though Webstart is the only built in way to do this at the moment.
What do you think are the advantages/disadvantages of a Java Web Start project against an Java Applet? We're trying to figure out what type we should use for our new application. We've already developed an Desktop App (JAR) and we're trying to make is useable from every machine, which has Java installed, without the need of installing it.
Any thoughts?
Applet/browser/JRE interaction problems. If you don't know what I mean, don't even have an inkling (from lost hair) then deploying applets will be a steep learning curve.
What does the browser bring to the deal? If the answer is JS interactivity, integration with an existing HTML based web app., or a few other related things, plenty. If not, then ask yourself what the advantage of deploying the app. wrapped in a browser window really is?
JWS Jar caching and update is more reliable (and can be taken under programmatic control, if needed).
The AppletContext provides some ability for an applet to interact with the environment, but the JNLP API goes beyond what the AC can achieve (mostly).
General usability. These may or may not be a problem for your use-case.
A free floating JWS deployed app. does not get closed when the browser gets closed, and does not suffer focus loss on tab change.
If 3 applets each with controls are embedded in 1 page with links, what gets focus? Since Sun never bothered to specify what should happen (according to them) it has been different across JREs over time. Now it is common for the JRE to grab focus for the applets. If it does, it it generally impossible to use the keyboard (alone) to get to the links and other focusable elements in the web page.
It is far easier to resize a desktop app.
A desktop app. (with splash screen, desktop shortcut with icon etc.) can look much more professional.
Of course, it should be mentioned that the lines become blurred:
Since JWS was introduced, it could launch applets
Since the Plug-In 2 architecture JRE, JWS could launch applets that remained embedded in a web page.
..we're trying to make is useable from every machine, which has Java installed, without the need of installing it.
I would sweep aside the 'without the need of installing it' requirement of that since there is always the passage of time and the need for updating plug-ins. On that note, use deployJava.js to handle JRE minimum version checking. The script will either embed an applet or write a link to a JNLP launch file after checking minimum Java is available.
See also
The Stack Overflow info. pages for tags:
Java Web Start
JNLP
Applet
Since 6u10 the significant difference is down to an applet appearing in (and being able to interact with) a web page (possibly opening windows that don't necessarily interact very well with the browser window) and WebStart applications being separate from the web browser. WebStart applications will automatically get their own process, which may be significant from a memory usage point of view, at the cost of a slower warm start. Applets have access to javax.jnlp.* since 6u10.
I think web start is what you should use. As far as I know it allows you to start full blown java applications.
JNLP can (and in some cases should) be used with applet.
Just finished integration of applet that read-write to user's file system.
Advantages of applet are obvious -- no installation on client machine.
Disadvantages:
not working in Chrome anymore;
additional configuration required -- each jar's manifest file must contain
Permission: all-permissions
line.
I'm going to deploy my Java game to show it to my friends and whatnot, but I'm having trouble deciding between Java Web Start and applets.
Under what conditions is one preferable over another and what advantages/disadvantages are there?
If your game is going to consume a lot of cpu and memory resources I recommend deploying it as Java Web Start since applets run slower.
If you have some java-javascript interaction you'd better use applets
Here you can find a table with advantages/disadvantages
Java applets have the advantage that they run instantly without the user having to click on anything. In addition, applets will automatically prompt the browser to download the Java plug-in if it's not already installed. This is important if your end users aren't very tech-savvy.
However, applets are extremely limited in terms of memory (60 - 90 MB), so if your game uses a lot of graphics you will notice a performance slowdown.
If performance is an issue, you will probably have to use Java Web Start. It suffers no performance penalty, but is a lot trickier to deploy and more difficult for end users to run.
I'd make it run as either, and then choose which to use. An applet will sit in a web page nicely. A WebStart application will look like a normal application (only with a little triangle to indicate it's from the web). From 6u10, applets can use JNLP services, and can be dragged out on to the desktop.
You can actually have both applets and web start with the same Java applet code. Web start supports launching unmodified applet .jar in a separate frame, all you need is to write JNLP file properly. You can specify the applet parameters in JNLP file, if required. The only difference is that the applet will pop out in a separate frame and not as part of the web page which may or may not be a problem. Why not to provide both applet and web start link? JNLP is not much more difficult to write than the applet tag.
I think it should not be much difference between Web start and applet performance unless applet runs in some old JRE that is part of the browser. I would not recommend this anyway - as any other software, Java evolves and gets better over time. This may explain posts talking about that Web start application is much faster, this otherwise would be very difficult to understand. If you applet supports also old JREs, I think you can simply specify the low version number in JNLP, adding + so it can also run with future versions.
Since Oracle is not making any progress in delivering a non-NPAPI java plugin, I would say that applets is an obsolete technology.
Otherwise, we would dive into a good old IE-only web. Banks are already requiring IE browsers so they would not spend tons of money to modernize their software. I feel sorry for them.
Web Start requires the client to install the Java application (and possibly the JRE) on their computers. If they don't have administrative rights to install software this is going to be a problem.
I am used to develop web applications in Java (Struts, Spring, JSP...). But now I want to develop a desktop one. I never liked to design windows in Java (AWT, Swing, SWT): too much work for an ugly interface. So I think it could be a good idea if could take advantage of my web-app skills. One option is to modify the SWT Browser and make calls to a Java function instead of HTTP requests. A very good add-on would be use of JSP. Finally, I thought that probably there is some framework or tool for this.
Do you think that what I propose is a good idea?
There is available some framework for this?
I need this for light applications. So I think that embedding an Tomcat server and using it with HTTP requests is not a good idea.
Edit: One example application could be a folder comparer: you specify two folders and the app shows you which folders and files are different. In this case, I think opening an external browser is ugly. Bloated application (with its server, MVC, etc) wouldn't be the best choice.
If you have used the JavaScript library - ExtJs - then you can use it with Adobe AIR to build good looking desktop based web app.
Building app's in Adobe AIR is also simple and elegant with the flex builder ide.
If your option goes to embed a light server, check winstone is not fully J2EE compliant but should be enough for what you need.
About the browser, I am not a big fan of swt myself, it complicates a lot cross-platform deployment, so probably worth to keep an eye on jwebpane, not quite ready yet, but probably the solution you'll need.
I wouldn't discount embedding a web server. I've done this before with a web start application embedding Jetty.
The download was pretty fast, the server starts up and you can use BrowserLauncher to immediately drive your browser to the embedded server, and hence your application. Jetty is designed to be modular and have a small footprint, so you can probably cut it down to the bare necessities.
There are several options: You can use the plugin API of Firefox and develop your app in there. You can use HTML, JavaScript, the built-in database, all the browser features and access the OS level.
Or you could try PyQt (Python and Qt) which allows to write simple applications very quickly.
[EDIT] The main problem you're facing is security: For security reasons, JavaScript apps (running in a HTML page) can't access local OS resources. So unless your browser allows you to write plugins in JavaScript (which is only true for FF AFAIK), there is no way to write an application which uses HTML as the "view" without the help of something else.
Moreover, HTML is very limited when it comes to features for applications. HTML is designed to be a "static document view" not an "application". You can do things like GMail but if you compare GMail to any real mail app (Outlook, Thunderbird, Notes), you'll see quickly that real desktop apps offer a lot more features.
We want to migrate UI rich application from delphi to java or Web Application.
Reason is that we want application to be portable on all Operating Systems.
Current Components and Modules of Application in Delphi :
In Delphi we are utilizing TWebBrowser component to display HTML content
We are playing mp3 that is extracted from FileStream on clicks in HTML.
All resources for HTML are retrieved from Embeded Database Firebird/Ms Access.
To sync some content we are doing HTTP post to PHP scripts to centralize the data on webserver.
Deployment:
- Application has to be deployed on CD and installed on Desktop computer on Mac OS, Linux, Windows.
I need your help how to approach this migration. Is better to go with Java UI or Web App that will be deployed with WAMP/XAMP and appropriate distributions on Linux and Mac's.
EDIT:
I have some specific requirements for audio functionality. Audio files are separate files distributed on CD or USB. Audio files are one solid file compiled from mp3's inside. Application will have to have ability to extract the mp3 based on offset and size of mp3 stored in index file and to play in real time... How this affects idea of Web App using this approach.
Why don't you give FreePascal a try? It uses the same language as Delphi, and can compile to a native application on Windows / Linux / Mac. Since you already have your app in Delphi, converting it shouldn't be too difficult.
Have a look at the freepascal website
If I had to deploy on a CD, I'd probably go with Adobe's AIR. It is really fulfilling the promise Java made 10 years ago in a reasonable way. It isn't perfect, but it does a pretty good job.
I've heard this internet thing is really taking off.
For all of the reasons that applications have gone online over the past 10 years, there really isn't much discussion to be had.
While Java is reliable, distributing and rolling out subsequent updates to those applications is heavy and time consuming.
I did Delphi development for over 9 years. I resisted the idea of distributing real applications over the web for quite some time. Today, I can't believe anyone would choose to continue in this way.
One nice thing, you can probably reuse some of your Delphi logic on the backend if you get creative. (I would only recommend this for the short term)
But, this answer doesn't really address your issue as you are saying that you must distribute it via CD.
The Java 6u10 release allows for distributing Java WebStart applications on media instead of from a Webserver, which might be exactly what you are looking for. You can also put the JRE installer for Windows on the CD too, if needed.
What exactly are your requirements crossplatformwise?
If most of the application is HTML-based, why not make it a full web application, using Ajax and Java?
I recommend NetBeans, and ICEFaces, which is a Java Server Faces implementation with Ajax support, including concurrent updates - if one user edits a record, all other users will see an update in their web page.
It is possible to package the whole application in a single jar file, including the servlet container (Jetty for example), so a simple java -jar myapp.jar will run the application.
NetBeans allows visual editing of the ICEFaces web pages, and even visual editing of the page relationships. The tutorials on NetBeans.org are excellent, and with tools like Maven, Hudson and others, code quality and development process can reach a very high level.
If you have some Delphi application using Datasnap : you can also re use your server made in Delphi with Datasnap in Delphi Prism and make Silverlight application.
And the same is true for DataAbstract