Google App Engine vs Microsoft Azure

Side Stepping on my OSGi trail, I saw a few articles on the new Azure platform for Cloud computing from Microsoft! People claiming it to be up agains Amazon EC² and Google App Engine.



Come on.. Having never used it, I cant speak for EC² but; App Engine and Azure? Where is the comparision.

By Choosing Azure, I am basically TIED to Windows all the way! Just look at the long list of Auzure SDK Requirements:

• Supported Operating Systems: Windows Server 2008 Enterprise; Windows Server 2008 Standard; Windows Vista Business; Windows Vista Business 64-bit edition; Windows Vista Home Premium; Windows Vista Home Premium 64-bit edition; Windows Vista Ultimate; Windows Vista Ultimate 64-bit edition
•  Required Software
•  Windows Vista SP1 (when installing on Windows Vista)
•  .NET Framework 3.5 SP1
•  IIS 7.0 (with ASP.NET and WCF HTTP Activation)
•  Microsoft SQL Server Express 2005 or Microsoft SQL Server Express 2008
•  Windows PowerShell (optional)

On the other hand, App engine can live on Windoze, Linux or Mac. Other requirements: Python - available in any OS. THATS it. They even have plans to get Java, Perl and other languages to be supported. The only thing we get tied to is Google BigTable DataStore.

It looks like the age old race with httpd for IIS. Déjà vu.

(NOT) yet Another Getting Started with OSGi

Last week I have been learning OSGi.

I got my first application running in OSGi. I am not going to write another getting started post with code that will show a hello world. But rather give you an idea how to start getting in the mud. And then may be show you more than a direction :)

I used Equinox 3.4 (OSGi R4) implementation. I prefered it over Felix. Why - Eqinox is simple, and a single jar download. But I guess that aint a thing to notice. You can get Equinox jar from here. If the link is broken, go here, download the equinox framework, it should be ~0.95MB.

Start equinox framework as

java -jar equinox.jar -console

You would have seen this on a lot of sites. but I did fall on two things flat on my face; missing -console and doing it wrong --console :P

As per the spec, (and by now, you know) a bundle is a jar with some special informtion in MANIFIEST.MF. A Bundle jar need not DO anything. It could just sit installed or be active (by exporting packages and services). So if you have a jar with just one interface that defines a static final variable: It can be jar-ed to a bundle too. It may not do much (other than exposing the constant). but it is a Bundle.

And then, There is a starter interface is BundleActivator. No I am not writing Hello World program. This interface can be used by

Import-Package:org.osgi.framework

manifest header. Along with that, You need to point (only one) a class that implements this interface (start() and stop()) to handle the call backs.

That gives you enormous power to do a loooot of things in OSGi. You are now literally the master of the universe (or atleast of the framework instance :P). Because with these two hooks (callback methods) you can traverse through the BundleContext. The BundleContext(, like ServletContext) exposes you to a lot of things around you. The framwork, The bundles living with you, Thier metadata, Their statuses, mechanism to programatically do stuff..

errr.. its 22:10, I gotta go to bed now.. If you want to learn more, Dont download a book. Start with the code. You can figure? Start with this one. I will see you in the next post..

Get Nerdy with VLC.

VLC media player gives a few things with less explored Extended Settings. A Webcam (in-built on lappy, prefered) together with VLC can do some pretty nerdy stuff. I cought a collegue by suprise when she walked into my cube saw her self in my laptop movin on my screen. Well.. thats only the beginning of endless uses and other things you can do. (You can even shave without a mirror- Yeah it is so good)

• Open vlc.
• Open Capture Device from the Media(older File) menu.
  
  
• Select the one for opening the webcam (V4L or DirectShow)
• For the basic use, just click play.
• At this point youu should see a vlc window playing what the webcam is capturing.
• Go full screen (there is your mirror, go ahead shave :)

This is good enough for basic nerd level. Stop here unless you want to get really nerdy :).

• Now Open Extended Settings (CTRL+E) from tools.
  
• Go to Video Tab.
• Play aroound.. Have fun

Examples:
go to Color Fun > Color Extraction > enter 00FF00 and Image modification > Motion Detect.. Coool eh?
Geometry > Rotate
Motion blur?

Best of all you can save this on to a video using transcoding feature in vlc.. nnoo.. I am not posting a video of myself heeeeere.. :) You are free to do so in comments though :)

MANIFEST.MF in Plain Java, EJB, OSGi - catching the drift

While reading about OSGi, I realised how the importance of MANIFEST.MF has grown over time. The once only-a-jar-information file has had its ups and downs. When I was in school, *chapter jar* was an "assignment" / "reference". It wasn't worth a class' time spent on it. Today a whole new technology relies on this humble text file.

Past: Long long ago, in stone age (yeah I am exaggerating), the MANIFEST.MF was auto-generated while jar-ing. More or less it was not used. Well, yeah if you are developing a java application to be distributed to end-users (the jars you used to double click, which are so replaced by jnlp a.k.a WebStart apps now). This file would give a place to specify the class path

Manifest-Version: 1.0
Created-By: 1.4.2 (Sun Microsystems Inc.)
Main-Class: com.big.long.package.MyAppMain
Class-Path: mod1.jar mod2.jar lib/lib.jar

This will be set when running

java -jar myapp.jar

which other wise would have to be something like

java -jar myapp.jar -cp all_the_jars_to_be_in_classpath

Another *advanced* usage was in Applets. For an applet developer, to include modular jars in your applets' class path. (if you have one enough to make up its own jar, and enough that it is using custom or third party library jars;I am no more into applets but, replaced by jnlp too.. I guess? Or may be done soon. Look at JavaFX)

Near Past: Then came EJBs. These *were* soo cool! (Sorry you EJB lovers, if any, still reading this.. I Love Spring Beans). EJB spec emphasised MANIFEST.MF to level 2. The WAR files and EJB jars would share common librarys by packaging them in the same EAR and referencing them in MANIFEST.MF's class path. For example, a app-dto.jar is common to both app-web.jar and app-ejb.jar the EAR would contain a app.ear, app-web.war, app-ejb.jar, and app-dto.jar, the app-ejb.jar file would have a MANIFEST.MF that looks like

Manifest-Version:1.0
Class-Path: TradeInfo.jar

(And then, you know, Spring came and EJBs lost the war, people lived happily ever after.. :P But the MANIFEST.MF din't lives on..)

Now: we have OSGi which is basically only a spec. It defines some more metadata (headers) in this MANIFEST.MF. A Typical file looks like

Manifest-Version: 1.0
Bundle-Name: HelloWorld
Bundle-Activator: HelloActivator
Bundle-SymbolicName: HelloWorld
Bundle-Version: 1.0.0
Import-Package: org.osgi.framework

So to learn OSGi, all you need to learn is these headers and what they mean. This as you can realize by now is only metadata defined by the spec. The implementations will actually use these.

Future: MANIFEST.MF is not going anywhere. It is here to stay. Look at Equinox Extension for Eclipse Plugin development. It adds more headers like Eclipse-PlatformFilter, Eclipse-LazyStart. Spring dm Server adds its own functionality on top of Equinox, to features like bundle personality, library importing etc. There may be more of these coming. But all in the The very humble MANIFEST.MF we are talking about is silently delivering a new purpose.

Mission OSGi

Finally some time for OSGi.

With release of Spring dm Server, My interest for OSGi got two-fold. Although I did have some close-encounters with OSGi (aah its just a jar called differently - bundle; and MANIFEST.MF drives it all, o I know OSGi), I haven't read into a lot of it. So now, I am diving into it.

To start I picked Neil's blog. He also has a draft of his upcoming book, OSGi in Practice. So It is a good place to start.

That gives me to start a new tag (osgi) :)

If Windoze ran the matrix!

Switch (ing) enum (s) in java

Java 1.5 enums are a life saver. There is a small gotcha in thier use especially in a switch statement(More so for a guy coming from hard core 1.4).

When creating an enum reference - you would need to Qualify with enum Type. However, The case labels while switch(ing) on an enum variable will only take enum constant of the *SAME* enum type. And ONLY the constant name. It SHOULD not be QUALIFIED.

Ex: In the following code, The second case label gives a compilation error.

public class EnumTest {

 enum WeekDays {SUN, MON, TUE, WED, THU, FRI, SAT};

 public static void main(String arg[]) {
  WeekDays r = WeekDays.SUN;
  switch (r) {
  case SUN:
   break;
  case WeekDays.MON:
   break;
  default:
   break;
  }
 }
}

There are good advantages here. For one, Refactoring doesnot involve lot of changes. Maintains Typesafety. It avoids a possibility of human error where you are comparing Fruit enums and Vegitable enums. Because they are different :)