Fish and Rice

This is s test post

First of all a big congratulations to the Apache team for dreaming up one of the most fantastic pieces of cinematic ideas ever imagined.

The Apache team is going on a journey “Where no one has ever gone before” and aims to create a “Compatible, independent implementation of J2SE 5 under the Apache License v2”.

WOW! This is George Lucas and Gene Roddenberry rolled into one huge block buster. I can't wait for Christmas or Durga Pujo for that matter.

It is not that people have not tried to re invent the JVM/JDK wheel. The open source landscape is strewn with failures such as GCJ and Classpath, which are currently being used by all but a large group of 3 students in the University of Timbuktu!

How many more commercially irrelevant JVMs do you want?

IMO it will be almost impossible to re create or re write a vast and quite complicated API like Java. You see the JDK is just not java.util.* and java.lang.*, but contains a whole lot of stuff like Swing, AWT, Naming, Java 2D, JDBC and of course a state of the art Garbage Collection mechanism in it's JVM.

I suggest an alternate to the Apache team.

1. Do not re-write the entire JDK. If you want, you could for instance just re-write the java.io.* package, bundle it in a jar archive and let people drop this into their lib/endorsed directory. This would ensure that users get a better implementation if IO, but do not have to deal with a crappy implementation of Swing. All JVMs support this modular architecture as of today, where by if I wanted to replace a JVM supplied class with my own implementation (same package name), I can just drop into an endorsed directory and JVM class loaders would pick this up.
   


2. Give users the option of native compilation instead of the currently prevailing Just In Time native compilation, if that is what they require. The Excelisor JET JVM with its Ahead of Time compilation could be a good guide towards that end.
   

In fact, if I were running the Apache Foundation today, I would rather have the best people within the group build the next generation Rich Internet Web Application architecture and a new Apache Web Server to support this architecture. In other words do exactly what Microsoft is doing Smart Clients and Macromedia(Oops Adomedia) is doing with Flex. To hell with the JDK really!

If you ever have to build a non trivial portal, composed of things like Charts, Tree Table views, Sortable tables etc, would you choose a JSR-168 Portlet implementation like Liferay, Stringbeans or Exo as your basic platform?

I have put my problems with the JSR-168 specification here, and I thought, it would be nice if I could take a second opinion. So this poll.....

If asked to build a Portal, would you choose any of the Java Portlet Specification-JSR168 implementations?
	Yes, a JSR -168 implementation would be an ideal candidate.
	No ways, I would actually choose PHP based portal solutions like drupal.
	No, I would roll out my own Meta Data Driven UI Framework.
	No, I would simply deliver a JSP,JSP Taglibs, Servlet, JDBC based solution.
	No, I would roll out my own Meta Data Driven UI Framework, which also incorporates JSF, Tapestry, Spring , Hibernate and other best of the breed components
Free polls from Pollhost.com

The problem

Normally when you save a web page, this creates a .Html file and a single or more folder containing all the images used in the web page. This is really inconvenient if you want to move the .Html file to different folders, drives etc. Generally people cut paste the .Html but forget to move the ancillary images folder, or worse still they do copy the images folder, but mess up relative locations by changing the directory levels.
The solution to this problem is clear a mechanism that allows us to save a web page as a single file, and not a group of files and folders. Such a single file can be moved around easily without loosing the images or styled texts within the web page.

The solution

Internet Explorer has this really nifty feature that allows you to save a web page as a single document. In order to use this option, open a web page that you want to save, go to the "File" menu and choose "Save As". In the "Save Web Page" dialog, focus on the "Save as type" drop down. Choose the "Web Archive,single file(*.mht)" opton, provide a file name and click "Save.

This creates a single .mhtml file. The way Internet Explorer handles it, is by serializing(writing) all images and css in the same html file where the content originally resides.

Sadly this feature was missing in Firefox.

The Firefox solution

MAF extension is a plugin that allows us to save a web page in a number of formats including .mhtml. Click here to download this plugin. To install just, drag and drop the downloaded .xpi file to your "Tools>Extensions" dialog window, and then restart Firefox.

I found their collection of clean and free software pretty interesting. A really nice collection of free to use software, minus any spyware.

Yes, Firefox is listed :)

This is really a neat trick to suppress unwanted println on which I don't have any control.

Java Server Faces, in case you were living in some cave all this while long, is a new web application development paradigm being touted by Sun. JSF tries do exactly what Swing has done for desktop development years ago.
It is built on a solid MVC foundation, with the VIEW becoming a set of res-usable components each firing their own events. The controller, which listens and responds to these events, is flexible enough to allow for page flow to be defined in a file called faces-config.xml. So the familiar SWING concept of event based programming rather than the currently used request-response web based programming model, is introduced.

You can read all about JSF from this excellent book on the same subject.

JSF has also got competition in the form of Macromedia’s Flex, Microsoft’s Win Forms or even Lazlo.

However, the basic mistake that all of them are making, is that they use the ubiquitous web browser as their delivery medium. In other words these applications run within the web browser. Such an exercise IMHO is like trying to fit a Dodge Viper’s v10 engine on to Rover Mini’s chassis.

Is that doable? Yes of course, but why would someone in heaven’s name do that? Why can’t there be a Rich Internet Client Platform, where one can deploy and run Rich Internet Applications. Why target the poor old browser. The web browser was created just to browse a set of hyper-linked documents. That’s it. Later on, somebody wanted the browser to host data entry forms, and so we added Java Script to allow for client side validations. When the e-commerce boom happed, the browser was now asked to participate in transactions. Thousands of web developers were now, inventing solutions to alleviate the “back button problem”, “the double submit problem” and so on. You see the web-browser was never designed to participate in transactions, which lead to these classic problems. And finally, now as if we have not made enough mistakes, this Rich Internet clients wave, is again targeting the web browser to manage something, which it was never designed for.

The browser is dead, html is dead, we have got to move onto something that is similar to Eclipse’s Rich Client Platform, although Eclipse’s RCP is still not the right thing.
In my view the best RCP would be something that provides me with the following

1.A set of communication API’s
2.A robust and flexible GUI toolkit
3.An application development framework.
4.Tools to quickly create rich, compelling and interactive web applications.

No more sorting on the serve-side period.