WYSIWYG Dreamz: Jayanth.Krupanidhi@Sun.COM

Two years and a week. And my dream journey at Sun comes to an end, as all good things must come to!

I should say this journey has been pleasant for most of the time, thanks to the employee-friendly work culture and great co-workers, who'd been amazingly co-operative and supportive! These were halcyon times indeed!

I'd have made an another 100 posts to this blog, but life seems to give its sweetest surprises only when they are least expected!

Nevertheless, the dreamz would continue, but somewhere else!

Java Web Start & JNLP

One of the most exciting features that Java offers is the ability to execute Swing-based applications that reside on a remote server from a client's system using Java Web Start (JWS). Java Network Launching Protocol (JNLP) is the underlying protocol that specifies how JWS applications are launched.

A JNLP file is an XML file that includes information such as the URL codebase of the source, general information about the application, the location of all the required JAR files & other resources and the main class that serves as the entry point for the application, etc.

JNLP in openInstaller

openInstaller 0.9.4 introduces basic JNLP support for creating single-click installers. A customizable JNLP template named product-installer.jnlp can be found in the openInstaller source under “sample_product/resources”. Individual product installers could copy this template to their product metadata location, customize it by making very minimal changes & then use it to create a WebStart-version of their product installer.

Here are the steps to create a WebStart-based installer for the sample product that comes with the openInstaller source:

1. Download and extract the latest openInstaller source onto your local filesystem.

2. Build the source as per the instructions.

3. Create a JAR file called resources.jar with the entire contents of the "build/proto/install/lib/resources" directory and place it under build/proto/install/lib/resources. After creating the resources.jar file should have a structure like this.
resources.jar
|_ dependency
|_ model
|_ org
|_ templates
|_ view

4. All the JAR files under “build/proto/install/lib” and its subdirectories need to be signed before they can used by Java Web Start. This is a security requirement that prevents unauthorized access to the application. The JARs can also be signed using the 'jarsigner' utility that comes with Java SDK.

5. Host the created build directory using a Web Server. After hosting, the URL that points to the build directory is referred to as the BASE_URL of the installer.

6. Open the file “build/proto_metadata/Metadata/product-installer.jnlp” and replace all occurrences of ${BASE_URL} with the URL that points to the build directory.

7. Start the Web Server.

8. Use Java Web Start (javaws) to invoke the installer. For example, if the BASE_URL is http://somehost.com:8080/sampleproduct, then the command for invoking the installer would be
javaws http://somehost.com:8080/sampleproduct/proto_metadata/Metadata/product-installer.jnlp

Note: openInstaller makes extensive use of JAXB, which is included as part of the Java SDK only from version 1.6.0. So, the sample product installer would only work with Java Web Start version 1.6.0 or higher.

Future Enhancements to JNLP support

1. The EngineBootstrap and Orchestrator classes have code that does things differently for the WebStart mode and the normal mode. The ideal design and implementation should allow the installer to run seamlessly in both modes, without having to write mode-specific code. The use of constructs like
if (webstart) {
// do like this
} else {
// do it differently
}
would be eliminated.

2. The use of platform-independent product zip files for the sample product installer would introduce the flexibility to test the installer hosted at a particular source on any client machine.

3. Moving forward, it would be ideal to have the product and installer metadata packaged as jars. It has two advantages: a) Hosting and maintaining a single jar file is easier than having to maintain hordes of individual files. b) Enhances installer performance by eliminating latency / response gaps while navigating between pages.

4. A WebStart-based installation that uses stream-formatted packages on Solaris causes pkgadd to fail since the -r option (that is used to specify response files) doesn't work for web-based sources. This would be fixed so that stream-formatted packages are successfully installed over HTTP.

SwiXML, the open-source software used to build GUIs declaratively, now gives a foreword about openInstaller in its homepage!

The foreword reads,

"GlassFish is the open source community based implementation of Java EE 5. GlassFish has a few tools projects, one of which is openInstaller.

The openInstaller project provides the framework for developers to create cross platform installations; it is a part of the GlassFish community of projects, and now includes and uses SwiXml."

Thanks, Wolf!

Got the SCJP certification goodies - a certificate, card & a lapel pin, in a neat package today.

A long-time aspiration...
Finally got substantiated...
I'm now a Sun Certified Java Programmer!

My score ain't impressive - just a mere 66%. Yet, am fully satisfied for more than one reason. Firstly, my preparation for the exam was very minimal (hardly 10 days). Secondly, I didn't take up any mock exam prior to taking the real one. I came to know about the JavaRanch Saloon community only on the morning of the scheduled exam date.

Finally, the actual examination experience, which was smooth during the first hour, turned out to be a nightmare when the server stopped responding suddenly and an error message popped up! That's the last (and the least) one could expect while taking an exam at an authorized Prometric testing center! After so many tense moments and unsuccessful attempts by the site administrator, I was able to resume the exam, but I'd already lost a good 10 minutes of the duration. I tried my best to complete the rest of the exam and avoid a time-out, all the way continuously fighting off the fear of facing another similar interruption. However, I managed to answer only 64 out of 72 questions!

To sum it up, it was one hell of a harrowing experience and I couldn't help but rejoice within myself when I came to know that I had passed the exam!

Moral of the story: Certifications are not for the faint-hearted! Being PREPARED for everything is the key!

You call it 'laziness'. You call it 'fear of messing something up'. You call it whatever. I'd been remiss in not installing Solaris on my Toshiba Tecra laptop all these days. Had it been my personal desktop at home, I'd not have hesitated to play around with stuff like defragmenting, partitioning, installing multiple OS instances etc. But, when it came to doing the same on my laptop, I'd always reflexively backed off from experimenting!

Moinak Ghosh (no marks for guessing, it's the Belenix guy and the pride of IEC) and team must have rightly sensed that there were so many guys like me wanting to have Solaris installed on their laptops, but restrained by similar apprehensions of a 'mess-up'.

Yesterday's InstallFest event was the third in this year (yeah, due to popular demand) and their team had already installed Solaris successfully on over 150 laptops. I'd wished to register for the earlier InstallFests, but couldn't manage to do so. Nothing to regret, coz there was an added attraction this time. They were installing the Compiz 3D Desktop (a GNOME plug-in) on all laptops that had an nVIDIA graphics card.

The Himalaya conference room in IEC was abuzz, with install volunteers briskly performing pre-install, install & post-install activities on around 20 to 25 laptops of varying configurations. Minutes after I entered the room, I had a volunteer named Mayuresh tend to my laptop. First, he had my Windows XP partition shrunk to 19 GB (from 35 GB) and created a new partition using GParted LiveCD.

After installing Solaris Nevada build 64a, they installed special drivers for Yukon Ethernet card. I walked back happily to my cubicle after filling out a feedback form for the organizers and proudly displayed the 3D desktop features to my teammates.

Kudos to the entire team of volunteers and organizers of InstallFest and to Mayuresh Nirhali, Madhu K R, Moinak Ghosh, Pavan Chandrashekar & Pradhap Devarajan in particular!

Guess what? We're back with the next minor version release of openInstaller: 0.9.1! The source and binaries of version 0.9.1 is now available for download.

Try openInstaller 0.9.1 now to discover cool new features like

1. Upgrade using legacy descriptors: Just include legacy descriptors that describe older versions of your product & you can now do an upgrade to the version that comes with your installer. openInstaller engine, now, has added capabilities to detect the presence of product versions that you specify in your legacy descriptors.

2. Detection of installed JDKs: You might have bundled a version of JDK along with your product, but the user might just want to use the one that he/she already has on his/her system. The new JDK Selection page, based on Netbeans' JDK detection algorithm, displays the list of JDKs detected in the system. The user can either choose one from the list or specify a JDK path manually or just simply let the installer install the bundled JDK.

3. Add/Remove Programs entries in Windows: As part of specifying Desktop Integration information in the config (.xcs) files, you can now include additional info for making your product appear in the Add/Remove Programs section in Windows.

4. Summary page enhancements: You now get to see a crisp and concise text summary of the installation status, instead of just a link to an external summary page. Also displayed is the absolute location of the log files.

5. SIMS metapackages count reduction on Linux: Linux metapackages count for SIMS was much higher than on Solaris. This has been reduced.

Apart from the features highlighted above, a few bugs have also been fixed. The packaging of the bundles have also been worked upon to remove all impertinent information that's likely to confuse new developers.

Desktop integration is a term that collectively refers to the set of tasks that the install framework does to configure / unconfigure the install image. In the simplest of cases, it could mean the creation of a few shortcuts to the installed software's executable in the desktop and/or in the user's Start menu or Programs menu. However, in quite a few other cases, it could also mean tasks like starting / stopping a few services on system startup / shutdown and installing the application into the system tray (or notification area).

DESKTOP ENVIRONMENTS

Desktop integration depends primarily on detecting the current environment that is installed on the target system. While Windows has its own unique desktop environment, UNIX-based operating systems like Solaris and Linux come with their own different flavors of desktop environments, the most famous of which are the GNOME and the KDE desktops. Currently openInstaller supports the following features on two desktop environments.

• GNOME – creation and removal of desktop & Launch menu / Applications shortcuts.
• Windows – creation and removal of desktop shortcuts, Start menu / Programs shortcuts & Add/Remove Programs entries.

THE GNOME IMPLEMENTATION

Creation of a shortcut in GNOME involves creation of a special kind of file called the .desktop file. The location where the .desktop file is installed or placed determines where the shortcut appears (in the user's desktop or Applications menu).

Structure of a .desktop file

A .desktop file looks very similar to a properties file whose first line is always [Desktop Entry] and has values defined for a few important keys like
Name - the name that appears in the shortcut.
Type - either of Application/Link/Directory.
Icon - the image file to be used as icon for the shortcut.
Exec - the executable to be run if this shortcut is clicked.

Shown below is a sample .desktop file.
[Desktop Entry]
Name=Calculator
Comment=A tool used for mathematical calculations.
Type=Application
Icon=/usr/share/pixmaps/gnome-calc.png
Exec=gnome-calc
RunInTerminal=true

Submenus & .directory files

In order to create shortcuts under custom submenus under the Applications menu, special files called .directory files need to be created. The structure of a .directory file is pretty much the same as a .desktop file, except that the value of the Type property is always “Directory” and the filename has a .directory extension.

Standard locations for .desktop & .directory files

The .desktop file that contains the shortcut information should be placed in the appropriate directories depending on whether it is a root or a user installation. The standard locations are given below.

Vfolders and .vfolder-info files

Start menu shortcuts creation in GNOME for user installations involves much more than simply installing a .desktop file in the appropriate folder. Every submenu under the applications menu is a virtual folder and hence any new submenu that should appear under the Applications menu should first be merged with the main Applications menu.

User installations can do this merging by adding suitable entries for the .desktop and .directory files, to an important file called applications.vfolder-info, which resides under ~/.gnome2/vfolders. It's basically an XML file that conforms to the vfolder-info DTD that is specified as part of Freedesktop standards.

Note: Vfolders is a standard that is deprecated since GNOME version 2.10.

Menus and .menu files

As of GNOME version 2.10 and above, custom submenus under the Applications menu can be created and merged with the main Applications menu by means of special files called .menu files. The standard location for placing these .menu files is /etc/xdg/menus/applications-merged for root user and ~/.config/menus/applications-merged for non-root user. A .menu file is a simple XML file that conforms to the menu specification DTD that is again specified as part of Freedesktop standards.

THE WINDOWS IMPLEMENTATION

Unlike GNOME, the creation of shortcuts in Windows is pretty simple and straightforward. All that needs to be done is to create a shortcut or a link in the appropriate folder by means of executing a creation or deletion script. The parameters required to create/remove the shortcut are used to create a VB Script file (.vbs), which is then executed in the user's environment using the Windows Script Host (WSH) framework. The “cscript” command of the Windows Script Host is being used for this purpose.

Given below is an example script that creates a shortcut on all users' desktop.

Dim WSHShell, LinkFile
Set WSHShell = Wscript.CreateObject("WScript.Shell"
LinkFile = “C:\Documents and Settings\All Users\Desktop\Java Homepage.url”
Set Link = WSHShell.CreateShortcut(LinkFile)
Link.TargetPath = “http://java.sun.com”
Link.Save

I've been on broadband internet for quite some time now & had always wished for a "meter-like" kind of contraption to measure the actual bandwidth of my connection whenever my download speeds dropped below fairly acceptable levels. My ISP claims that he's providing me 256 KBPS bandwidth, but how do I know and affirm that? I could call up my ISP's customer care and say that I wasn't receiving the claimed bandwidth, but how could I corroborate my stance?

If you think you're sailing on the same boat as me and feel that you're actually being "cheated" by your ISP, here's how you check whether you're right.

1. Go to http://www.testmy.net
2. Choose the type of test you want to take - download, upload or both.
3. Wait for a few seconds while your speeds are tested.

The results of the test will appear on the page along with comparisons to speeds provided by other internet connection options like Cable, DSL, ISDN, Dialup etc. Apart from rating your connection on a 5-point scale, it also gives a diagnosis description saying how much slower or faster your connection is than the average.

I was particularly impressed by the "Convert results into an image" option for convenient storage of results. See the below image.

And the best part is that all these features are available for free!

You have PROOF now! You know your ISP's Customer care number! You know what to do next!

The source is finally out!

Following the binaries, the source code for version 0.9.0 of openInstaller is now available for download in the Downloads section.

Developing GUI applications with Java Swing can be as challenging as it is fun. Much of the challenge in it lies in the fact that every change done to Swing code requires a recompilation. Most of today's applications warrant frequent changes to the UI, thereby making the life of a Swing programmer difficult. Would it not be great if writing UI code were as simple as writing XMLs? Such a wishful thought inspired Wolf Paulus to create SwiXML, an open-source software which combines the power and robustness of Java's Swing with XML's ease-of-use.

openInstaller leverages these advantages of SwiXML completely by employing a UI model built internally using SwiXML. Complex logic like defining layouts & positioning the components / widgets inside the panels is already built into openInstaller. This enables install application developers to just focus on other important aspects of an installer without worrying too much about the UI. openInstaller provides them with an interface that is based on the Java Desktop System Configuration Manager specification. Installer developers just use this interface to define their UI pages at a high-level.

For example, to create a UI page like the one shown below,

one would have to define an XML something like what follows..

<apt:template apt:name="appserver"  xmlns:apt="http://www.sun.com/jds/apoc/2004/template"
    xmlns: xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:oor=http://openoffice.org/2001/registry>
  <apt:category apt:name="Application_Server" apt:label="ApplicationServer" >
    <apt:page apt:name="Configuration_Item" apt:label="Configuration Settings" >
      <apt:section apt:name="appserver" apt:label="Application Server" >
        <apt:property apt:name="AS_ADMIN_USER" apt:label="Administration User"
                    apt:dataPath="AppServer.AS_ADMIN_USER"
                    apt:type="xs:string" >
          <apt:visual>
            <apt:textField apt:columns="15" apt:toolTip="Application Server Administration User."/>
          </apt:visual>
        </apt:property>
        <apt:property apt:name="AS_ADMIN_PASSWORD" apt:label="Administration Password" apt:dataPath="AppServer.AS_ADMIN_PASSWORD" apt:type="xs:string" >
          <apt:visual>
            <apt:password apt:columns="15" apt:toolTip="Application Server Administration Password."/>
          </apt:visual>
        </apt:property>
        <apt:property apt:name="AS_CONFIRM_PASSWORD" apt:label="Confirm Password" apt:dataPath="AppServer.AS_CONFIRM_PASSWORD" apt:type="xs:string" >
          <apt:visual>
            <apt:password apt:columns="15" apt:toolTip="Confirm Administration Password."/>
          </apt:visual>
        </apt:property>
        <apt:property apt:name="AS_ADMIN_PORT" apt:label="Administration Port"
apt:dataPath="AppServer.AS_ADMIN_PORT" apt:type="xs:int" >
          <apt:visual>
            <apt:textField apt:columns="15" apt:toolTip="Application Server Administration Server port."/>
          </apt:visual>
        </apt:property>
        <apt:property apt:name="AS_HTTP_PORT" apt:label="HTTP Port"         apt:dataPath="AppServer.AS_HTTP_PORT" apt:type="xs:int" >
          <apt:visual>
            <apt:textField apt:columns="15" apt:toolTip="Application Server Http Server instance Port."/>
          </apt:visual>
        </apt:property>                
      </apt:section>
    </apt:page>
  </apt:category>
</apt:template>

An <apt:page> can contain multiple <apt:section> elements, each of which would visually correspond to a tab in a tabbed pane. Each <apt:property> element denotes a single configurable visual element on the page. The value of the apt:dataPath attribute represents the configuration variable name that can be used by the product configurator.

The above interface also supports user-input validation by means of built-in constraints as well as custom-validation scripts using Beanshell.

Efforts for developing NetBeans plugins that help in the creation of these UI-definition XMLs using a simple drag-and-drop mechanism are already underway, so openInstaller aficionados have a lot to look forward to in our future releases!

In my last post, I'd touched upon the theme of knowing Carnatic music, in order to appreciate it better. In this post, I'd like to explicate the math behind the theory of Carnatic music for the benefit of all those who are passionate about knowing Carnatic music.

Indian Carnatic music is a seemingly complex theory that has raaga & thaala as its cornerstones. A raaga is basically the melody(scale) and the thaala is basically the rhythm(beat). The seven basic notes (or Saptha Swaras) that comprise every raaga are Sa, Re, Ga, Ma, Pa, Dha & Ni. These could be thought of as the Carnatic music counterparts of Western music's Do, Re, Mi, Fa, So, La & Ti respectively. Henceforth, I shall use the term swara to refer to a musical note.

Whereas the swaras Sa and Pa are always fixed (meaning, they do not have sharp or flat variants), the swaras Re, Ga, Dha & Ni have three variants apiece & the swara Ma has two variants. The below illustration shows the different swaras as laid out on a musical keyboard's C-scale. Note that the swara R2 is the same as G1 & the swara R3 is the same as G2. Similarly, the swara D2 is the same as N1 & the swara D3 is the same as N2. For reasons of lack of space and easy understanding, the names of the swaras have been represented using their first letters alone.

The variants of the swaras R & G can be used to create 6 different combinations which are R1-G1, R1-G2, R1-G3, R2-G2, R2-G3 & R3-G3 respectively. Similarly, the variants of the swaras D & N can be used to create 6 different combinations, thereby resulting in 6*6=36 combinations for the 4 swaras R, G, D & N. These 36 combinations, when multiplied by the available two variants of the swara M, produces a total of 36*2=72 combinations, for all the available 5 variable swaras. These 72 combinations are referred to as the Melakartha raagas. Of them, the first 36 raagas that use the first variant of the swara M are called Shuddha-Madhyama raagas & the next (or last) 36 raagas that use the second variant of the swara M are called Prathi-Madhyama raagas.

Every raaga is a pattern of swaras and is defined by the way it flows from one swara to the other. The ascending pattern is called as aarohana & the descending pattern is called the avarohana. For the 72 Melakartha ragas, the aarohana & avarohana have the same swaras, meaning that the avarohana is just a simple reversal of the aarohana.

Though the basic Melakartha raagas are only 72 in number, Indian Carnatic music gives you the flexibility and freedom to experiment with the swaras and create as many raagas from them, by omitting one or more swaras (note that the swara S cannot be omitted). Another fine flexibility allowed is that these omissions can be done separately for the aarohana & the avarohana. i.e., any swara that is omitted in the aarohana can be included in the avarohana & vice-versa, thereby provisioning the gamut of raagas for futher extensibility.

Hmmm.. so, how do you feel? Having started to taste Carnatic music theory, feel like hogging more? Here's a goodie that I'd like to offer you to get started with practising all the theory. I've come up with a list of all the 72 Melakartha raagas along with their aarohanas & avarohanas. The best method to familiarise yourselves with these raagas would be by trying these swaras on a musical keyboard. The list of the 72 Melakartha raagas in PDF format, can be downloaded here.

In my future posts, I shall talk more about thaalas, popular composers, veterans, famous artistes, instrumental music & a lot more. As always, keep the comments & suggestions pouring in!

Thanks to Vasanth Vaidyanathan's recent blog, I now have a topic to blog about!

More than once, I'd felt quite lost trying to look out for driving instructions to a particular place in Bangalore, until I discovered Wikimapia. Just click on the city and you can search at a building-level to zero in on the exact coordinates.

Found the coordinates for a place that you think is popular? Wikimapia provides you with an option to mark that place with a name. But, going by personal experience, for a city like Bangalore, it's less likely that a popular place's coordinates is not already marked!

By the way, sorry if I had deprived the in-house cartographic talents of a chance to showcase their skills!

The URL http://openinstaller.org now redirects to the openinstaller.dev.java.net site's front page, thanks to Annie Putz, Sun's Domain Manager.

Project Purple Haze, a project aimed at providing a panacea for all installation pain-points, is all set to go open-source on 1st May, 2007.

Watch out this space for more updates from me about openInstaller.

You're also highly encouraged to join the community, provide suggestions and feedback, contribute to it & most importantly, "spread the word around"!