I need some advice on how to load a big applet.
I need to make an instance of JWord text editor to work as an applet, but the editor is about 4 mb.
I'm aware of the java web start solution, but my boss doesn't like it, so I'm stuck with the applet solution.
What I would like to ask you is on how to reduce the user waiting time.
JWord needs about 10 external libraries, so the question here is:
-pack up all in a single big jar?
-make the jars load singularly?
I'm putting this in a jsp page, but the last time I developed an applet the tag "applet" was not deprecated. Now I saw that it's been substituted with "object" tag, can someone help me with that? Point the similarities/differences?
And finally, since this is a big applet, I would like to know if there's the possibility to remove the grey box in the waiting, maybe putting a loading bar in replacement? If so please provide examples! Never done that before..
Thank you
In deference to Thorbjørn Ravn Andersen, I think 4meg is a huge download for an applet. Perhaps that is just me talking from the perspective of my very slow wireless connection. Some people have gone (significantly) further in applet size on LANs with high bandwidth.
Decrease the size of the download.
Use Pack200
& obfuscation (one of the few end purposes for which obfuscation is well suited).
Provide information to the user as applet loads.
Before the applet loads
See Special Attributes of Applets - image.
image The image attribute allows you to replace the default animation with a custom graphic.
Use an animated GIF like the one below, to indicate that something is happening.
(Image courtesy of http://www.ajaxload.info/)
After a tiny 'splash' applet loads
Trusted? Loader applet using URLClassLoader for the bulk of the download. Pop a
JProgressBar for the downloads after the initial 'splash applet'.
JWS versus standard deployment
You seem to be assuming a 'JWS solution' will result in a free-floating app. That is not the case since the Plug-In 2 JRE (Sun's 1.6.0_10+). As mentioned in the info. page on the applet tag - visit that page and chase the links for more details.
To use the JWS abilities you might have:
One jar for compatibility applet (used by a pre Plug-In 2 JRE). This results in one single HTTP request & a slightly smaller1 final Jar. (1) Smaller than the total size of a number of Jars.
Multiple Jars for JWS/Plug-In 2 JRE. Lazy loading of dependent Jars by the JRE as needed, or programmatically using the DownloadService classes.
See also the JWS info. page for more information on JWS generally.
Deploying the applet- applet vs. object.
Don't hard-code HTML for it, use the deployJava.js script referred to in both info. pages linked above.
There is nothing wrong with having a large applet, and the dependent jar referred to from the invocation snippet in HTML.
See the applet trail in the Java tutorial - http://docs.oracle.com/javase/tutorial/deployment/applet/deployingApplet.html
Note that there is a limit to the memory available to an applet, and - especially for older Java deployments - this may be too small for your application. In that case the easiest way is most likely the Java WebStart (which for Java 6 supports Applets too) where you can specify your memory needs.
You can shrink your program with the Free and Open Source program proguard. It takes big jars, and removes every class which isn't used.
Related
This might sound like a ridiculous question, but I have to ask it because I have a working product which is doing this.
I have an applet running inside a browser. This applet is just not just any applet, but a fairly complex package application for CRM/ERP. I was told by a vendor company that they are able to monitor what a user does inside the applet, by replacing applet's main class at runtime before launch with their own. The term used was "endorsing".
I am a bit clueless now. How can you look inside an applet and listen on user clicks and keyboard events, even if you could somehow hack into it? I can tell you that this is a true story, because I have seen this vendor company's applicaiton and it just sits in the background and records all the contextual information (for instance, user filled which textbox in the applet, the name of the textbox and etc).
Are they any hacks at classloading level (I feel stupid asking this), or something else that I have not come across in java that would let you do something 'urban legendary' like this?
Java Applets are loaded using a HTML tags like this:
<applet archive="ApplicationSP1.jar,Application.jar" code="Main.class" name="myApp" width="800" height="600"></applet>
As you can see, the "archive" attribute supports several .jar files.
You could use this technique to load your own versions of the Java Classes of the application by putting them in the ApplicationSP1.jar file. They will be loaded before those classes stored in the second Application.jar.
Obviously, you would need to do some reverse engineering to understand which classes from the original application to override or wrap. Then you have to create new ones named exactly (same package and class name) as those you want to override.
Other option would be developing Aspects to capture events in the application and load these aspects using same technique of multiple .jar in the archive attribute of the HTML applet tag.
The solution for capturing Swing/AWT event can be found in
Want javax.swing hook that tells me WHICH component in the hierarchy is executing an action
It is difficult for overwriting Swing/AWT class used by applet which launching from browser.
They have to breaking the protection of Java security manager and get writing permission of JRE endorsed library folder.
For this case, Java Endorsed Standards Override Mechanism is hard to implement without manually operation of end user.
I asked a question on here once before and got some great help and advice from a lot of knowledgeable people so I thought I'd try this again with another programming issue I'm having.
Here is the basic problem. I've created a small Java applet that takes four images and combines them into one large image. To be more specific, I combine four images into one large image that will fold up to be a greeting card when printed out. Everything works just fine, but I'm going to be embedding the applet on my website and so I'll have users select the four images they want from a list of images on my website, and then with their selections I'll create the large image.
Now here's the trouble... when I create the large image I want the user to be able to download it. Is it necessary to create a signed applet? And if so, how do I go about signing my applet? Or is it somehow possible for the applet to just display the image in such a way so the user can just right-click the image and save it to their file system. Any advice/suggestions would be much appreciated!!
There is no need to sign the applet if the image is loaded from the same location that the applet class itself is downloaded. There would be a problem however, saving the image locally from an unsigned applet. For that functionality, you would need to sign the applet.
Alternatively, for applets running in a web browser, the image could be displayed in a separate browser frame using:
applet.getAppletContext().showDocument(imageURL, frameTarget);
From this page/frame, the image could then be saved locally using Javascript.
Depending on Java and browser version, I see 3 options:
Digitally sign the Jar and encourage the end user to trust the digitally signed code.
Jar the app., deploy it using Java Web Start and use the JNLP API services to save the resulting image. This can be done with a free floating applet since Java 1.2, or an embedded applet since 1.6.0_10+. Here is a demo. of the file services. GIFanim also offers an embedded applet that uses the services for saving animated GIFs.
Encode the image as a Base64 URL to display it direct in a web page. This requires a more recent browser, older browsers put a 32Kb limit on the image size. J2SE only had a method added recently, that could do the conversion for us. See DatatypeConverter.printBase64Binary(byte[])
To write files to a file system, signing an applet is necessary.
However it is quite easy to self sign applets and unless your users are extremely cautious, self signing would work.
Follow these intructions to sign an applet. P.S these instructions are for a linux setup. You might need to set up environment variables in windows.
Jar signing link
I have developed a command-line (read: no GUI) Java application which crunches through numbers based on a given dataset and a series of parameters; and spits out a series of HTML files as resultant reports. These reports hold a large amount of data in tables, so in order to give the users a easy and quick overview of the results, I utilized the JUNG2 library and created a nice graph.
Here's where it gets interesting; since I would like the graph to be interactive it should be deployed after the application has run and files are generated, whenever the user wants to view the reports. I decided to go with an applet based deployment, however I am not too happy with the current setup due to the following reasons:
I want to make the software as simple to use as possible (my users won't be tech-savvy, and even tech-intimidated in most cases). I would really like to distribute one JAR only, which forced me to put the applet with everything else it needs in a package in the same JAR as the main application.
The applet and the main application need to communicate the results, so I create a xML-based report which is used to hold information. As long as the files are on a local machine and are not moved around it all works fine. Unfortunately I also need the files to be moved around. A user should be able to take the "results" folder to a USB stick, go anywhere plug the stick to another computer and be able to use the report as he/she likes.
For the time being the applets are implemented with the following html code:
<applet code="package.myapp.visualization.GraphApplet.class"
codebase="file:/home/user/myApp"
archive="myApp-0.2.6-r28.jar"
width="750" height="750">
<param name=input value="results/test_name/results.fxml">
</applet>
As you can see this applet will not work if the parent folder is moved to another location.
As far as I know I have a couple of alternatives:
a) Change codebase to point to an URL on our webserver where I could put the jar file. This however creates the problem with permissions, as the applet will not be able to read the results file. Alternative is to upload the results file to the server when the user wants to visualize the graph, although I am not sure if that's a good option due to server security and also if it could be made so that upload happens automatically without bothering the user.
b) I can use a relative path on the codebase attribute, but then the whole folder hierarchy needs to be intact upon copy. This could be a last resort, if I cant come up with a better way to do it.
c) change the deployment method (would like to avoid this alternative to not spend more time on the development phase)
Any ideas? Am I missing something? How could I tackle this problem?
Thanks,
I'm not sure I entirely understand your use-case, but from what I do understand, I would suggest this:
Dump the applet for an application launched using Java Web Start. Have the JNLP file declare a file association for the fxml file type. When the user double clicks an fxml file, it will be passed as an argument to the main(String[]) of the JWS application.
A sand-boxed JWS application can gain access to resources on the local file system using the JNLP API. Here is my demo. of the JNLP API file services.
I have a Java Applet application ( achart) on my php Webpage ... Problem here is the Java Applet takes more time to load ... I am thinking of replacing these applets with some similar technology but fast ... I am counting on Ajax... what are my other options ... ?
Java applets load slowly. shrug Its the nature of the beast....
If you have multiple jars, you should check the order of the classpath you provide to your applet. Note that each jar is only downloaded "on demand" whenever a class needs to be loaded. It looks in the first jar, if it can't find the class it looks in the second and so on... You can reduce your startup time by ensuring that all of your classes required for starting up the app are in the first jar(s) listed.
Also, if you are attempting to load a class or resource which is not in your classpath, it must search through all the jars before returning AND hit the server codebase to look there. It can potentially greatly reduce your startup time.
Turn on applet tracing in the java control panel and you should get a better idea of how classes are being loaded out of the jars.
If the size of the applet's JAR library takes to long to download, you can shrink the size with the ProGuard tool. Here is a comparison of the compression ratio for some Java libraries.
Have you packed your jars.....
Have you tried Java deployment toolkit (http://blogs.oracle.com/vaibhav/entry/java_deployment_toolkit_6u10)
with jdk 1.6.10+.....
If its simple charts you want, have a look at:
http://code.google.com/apis/chart/
Yahoo has some nice charting components for actionscript 3 (flash) http://developer.yahoo.com/flash/astra-flash/charts/
Google has a service that will generate charts as images as Tim already pointed out.
Alternatively you could try to speed up the delivery of the applets that you are using - check if they have an Expires header so they only get downloaded once in a while instead of for every page (this won't help on the first view, but will speed up those after that)
Edit: if you only target specific browsers you could try and create the charts using javascript and the Canvas element, but that is definitely not supported by internet explorer. https://developer.mozilla.org/en/Canvas_tutorial
I know this answer is a bit late but, it could be that you are just being very inefficent with java or your machine is slow, I have a java program that has quite alot of code as well as accessing an SQLite DataBase and it runs quite quickly, loading within five seconds. If you have anything you don't use in your program then remove it, also try jaring and signing it(not sure if last two things would help.)
I need assistance finding a delivery method that best fulfills the following requirements:
We wish to deliver a single file to my clients.
Clients should be able to launch this file from the operating system shell - much like running an '.exe' on Windows.
After being launched, the program/script should be able to display a window with HTML content. this may be done using a stand alone program, a runtime or by running within a browser.
We need the ability to embed a resource within the delivered file, such as an mp3 file, which i can later extract programmatically.
Optimally, the solution should run on Windows, Mac and Linux machines. Less than perfect cross-platform interoperability is acceptable, but we want as broad a penetration as possible.
Clients should not need to pre-install anything (unless it is done transparently), pre-configure anything, or approve any thing for this to happen.
For example:
We could use a regular executable file, written in C++ to do this, but it will not be cross-platform.
We could use a sliverlight XAP file, an adobe Flex file or a Java JAR, but internet explorer warns users when local content is launched. In addition these approaches mean that we have less than perfect penetration, even though it is acceptable in these cases.
We could use a python (or equivalent) script, but the installed-base (penetration) of the python interpreter is not good enough.
Using a standard HTML is not enough because of the difficulty of embedding resources in it. Embedding Silverlight XAML or uuencoded content in HTML causes IE to display a warning.
Using something along the lines of a jpeg as a delivery method is not rich enough since we need to display HTML.
..but internet explorer warns users when local content is launched..
I don't get it, what's the problem with IE saying "Hey this app is trying to run your files!"
I don't mean you don't have a good reason for this, it is just, I don't get it.
IE will only warn the user if the app has not been downloaded and try to access local resources, for instance if running from an applet or a JNLP like this one:(click on the first orange button you see )
But if the users download the jar and run it from the computer ( double click on it ) the app is local and can run without problems.
The jar file is a zip file after all, so you can attach your mp3 file with it. Double click is supported in the desired platform, and the HTML content could be either a local file ( un-packed along with the mp3 file ) or an internet web page.
Java is preinstalled on those OS already.
"internet explorer warns users when local content is launched"
There's a reason for this. How can they distinguish your excellent, well-behaved, polite application from a virus?
Since the line between your app and a virus is very, very blurry, go with any of Silverlight XAP file, an adobe Flex file or a Java JAR.
The IE business is a good thing, not a bad thing.
You could try using the 'Jetty' application server.
This supposes there is a working java environment on the target machine.
Jetty is java servlet container but it is possible to configure
everything (web server, html templates, applications, etc.) in a
single executable jar, which launches the web server and opens a default page.
Exactly how the jar file is launched will vary from platform to platform
but otherwise the user interface will be identicle, and, as its a java application
you can do pretty much anything one it has started.
Sounds like MIME HTML does exactly what you want - unfortunately, it is not supported by many browsers other than IE.
I'd investigate Adobe AIR. It can display both HTML and Flex content in a desktop application without using a web browser. However this will require installation of the AIR runtime, also I'm not sure if the Linux version is out of the beta stage.
http://www.adobe.com/products/air/
You can also use a binary for each platform.
As per your description the app is very simple, and porting from one platf to another sounds like just matter of re-compile and offer binary based on the dist.
Is this an option?