In my coverage of all the new features that are part of Java SE 6, there is a new gem added that makes the user experience very clean and concise when you bring up a web-start or applet or desktop based Java application. Namely, the splash screen.

When you load up a native application, it’s very traditional to display a “splash screen” with the company logo and branding of the particular product. In the past, you had to write your own loader class that did this. But now Java has added support for it. Class - java.awt.SplashScreen does the job for you.

The splash screen is displayed as an undecorated window containing an image. You can use GIF, JPEG, and PNG files for the image. Animation (for GIF) and transparency (for GIF, PNG) are supported. The window is positioned at the center of the screen (the position on multi-monitor systems is not specified - it is platform and implementation dependent). The window is closed automatically as soon as the first window is displayed by Swing/AWT

- excerpt from the Java SplashScreen API

There are two ways to invoke the splash screen:

java -splash:filename.png MyApplication

or add it within your manifest.mf file like this

Manifest-Version: 1.0
Main-Class: Test
SplashScreen-Image: filename.png

Now you have a common, concise way to display the splash screen. And if your application does anything like reloading classes or has a built in feature to restart certain parts of the application. You can even get the latest from a remote URL. Since it exposes, the following API [ setImageURL(URL imageURL) ], you can programatically invoke a URL like this on the server-side:

http://www.myapplication.com/getVersion.jsp?ver=1.2.3

And this can return a binary stream of “content-type: image/png”. But on the back-end you can tally the number of folks using version 1.2.3, etc.

Cheers.

If you find this article useful, consider signing up for my RSS feed or Email Newsletter. See links on the right side.

What is it? With Java 6 there is a new addition (package: javax.script) that allows you to work with scripting languages like Javascript (using Rhino) and Groovy. Although there is built in support for adding scripting engines like Groovy, PHP, Perl, etc - what’s bundled in this release is Mozilla’s Rhino Javascript Engine.

Why embed a scripting language? Most scripting languages out there are dynamically typed. Meaning, your code does not need to know what type of value you will be storing in a particular field at compile time. So for example, using JavaScript as a scripting language, you can store “John” [var name = “John”;] or the numerical value of five (5) [var name = 5;] in a var. And since the variables are loosely typed, the language takes care of storing the data by guessing at what’s being stored in that variable. Well why does this benefit us? Well, these technologies help us in prototyping quick, build applications faster, and for situations where you can execute commands repeatedly as well as in tying different technologies together. Developers usually agree that for processing\parsing, Perl has always had an upper hand. So imaging using the perl scripting engine to develop an application that can parse a file efficiently. The other situation where embedding a scripting language comes in handy is - when you are developing a Java FX or Java Swing based application. Now you can develop libraries that can work seamlessly whether they are deployed on a FireFox browser or on a custom Java application on your smart-phone. The third arena where this makes sense is in server-side processing. Imaging a back-end application that needs to perform some text manipulation. You can tie a perl or sed or awk script engine on the back-end via a command shell like bash or ksh to perform the operations right within the Java application and all along work with variables right in the Java memory space.

Simple Example: Let’s take a look at an example, where we print the string “Hello World” onto the System.out.

ScriptEngineManager mgr = new ScriptEngineManager();
ScriptEngine jsEngine = mgr.getEngineByExtension("js");
try {
jsEngine.eval("print('Hello, world!')");
} catch (ScriptException ex) {
ex.printStackTrace();
}

Well, your first thought will be that I could have done this in one Java line [ System.out.println(“Hello World”); ] but the point here to see the profound impact that this option can bring to the Java language.

Now let’s look at a way to access a variable in the Java space:

String name = "John";
ScriptEngineManager mgr = new ScriptEngineManager();
ScriptEngine jsEngine = mgr.getEngineByExtension("js");
try {
jsEngine.put("jsname", name);
jsEngine.eval("print('My name is ' + jsname)");
} catch (ScriptException ex) {
ex.printStackTrace();
}

Well you can learn to use this technology with relevant examples here. Interested in learning more about this technology and how it impacts Java, then look at JSR 223. Now almost every web developer using Java has at one point of time explored Groovy. In the past, you would run your Groovy code using an interpreter available when you download Groovy. But now using this technology, you can embed Groovy into the JVM such that you have access to data and variables in both namespaces. To cover the basis for using Groovy natively is beyond today’s blog but you can see the possibilities of what you can do here.

Here is a list of available Scripting Engines that you can drop into Java including support for Awk, Freemarker, Groovy, Javascript (using Rhino), Python, Ruby, Tcl, PHP, Smalltalk, etc. As I’m writing this blog, the jsr223-engines.zip contains the following scripting languages:

browserjs, ejs, freemarker, groovy, jacl, jaskell, java, javascript, jawk, jelly, jep, jexl, jruby, jst, judo, juel, jython, ognl, pnuts, scheme, velocity, xpath, xslt.

So if you need to prototype fast and don’t want to run an separate instance of Apache server with mod_php or mod_python to develop using these scripting languages. Now you can do this all within Tomcat or in native Java with a few simple drop-in JAR’s.

Happy Scripting!!!

If you find this article useful, consider signing up for my RSS feed or Email Newsletter. See links on the right side.

Today we are going to look at a new feature available in Java 5 and above that can speed up your load time of your jar’s within your applets and web start (provided you have a web server that’s hosting the jar that’s HTTP/1.1 compatible server).

Let’s first take a look at what happens on the back-end:

In a typical applet (same applies to a web-start application), you have a src/source tag that points to a JAR file like this:

<applet CODE = "com.MyApplet.class" ARCHIVE = "/archive/MyAppletArchive.jar">
</applet>

Here your browser requests a JAR containing the needed class files under “/archive/”. If the web server finds the JAR, it sends it back to the requesting code.

Well in Java 5 and above, they have a new compression scheme called “Pack200” - see (java.util.jar.Pack200) that allows you to send an alternative file that has it’s content compressed further using Pack200 format. The file’s can usually be reduced by 1/8th the original deflated jar file.

So when the browser requests the server for that JAR file, in the request header it will send all the formats that it can accept, namely -

Accept-Encoding=pack200-gzip, gzip

This tells the server that if you have a pack200-gzip then send that but in the case you do not, then send me the gzip-ed version of the JAR file.

So the next step in making this magic trick work is to modify the ARCHIVE tag to a servlet instead of a resource request. So now your ARCHIVE tag looks like this:

ARCHIVE = "/archive/MyJARServlet.do?file=MyAppletArchive.jar"

And in your MyJARServlet, you can scan on the file-system first for a”MyAppletArchive.pack.jar.gz” file and send it and in the case that the request does not have a Accept_Encoding of “pack200-gzip” then your code can default to sending in the plain-old “gzip” JAR file.
To see a sample of how this work, see the following URL:

http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html
Now the next question one would ask is “How do I pack it using Pack200 format?”
Simple, within the JRE/bin or JDK/bin directory of Java 5 or later, you will find a utility called “pack200.exe” (windows). You can take an existing JAR file and pack it into that format by using the following command:
JRE/bin>pack200 myjarfile.jar
By using this strategy, you can decrease the time it takes to send that file. Smaller file = less time to send and less bandwidth that’s used.  If you plan on implementing this, bear in mind that there is a little bit of overhead to unpacking a Pack200 or compressed-gzip file as opposed to a JAR-ed non-compressed file. So you decide which approach makes sense.
Cheers.
If you find this article useful, consider signing up for my RSS feed or Email Newsletter. See links on the right side.