Plan B

Adieu, Sun

Today (Friday, the 29th) is my last working day at Sun. My decision to leave Sun is purely due to local conditions and I remain immensely proud of Sun as a corporate and an engineering company. I'll make sure I stay in touch with Sun through OpenJDK, NetBeans and OpenSolaris. And I hope to return some day to a even more strong and successful Sun. Meanwhile, I'll watch in quiet amusement from the sidelines as Sun pounds its competition with disruptive innovations. To answer the (recently) oft-repeated question - would I recommend Sun as a company? Of course I would. It is arguably the most contrarian, free-spirited and open (in every sense of the word) company in its space. Go Sun!

In closing, I'd like to thank my colleagues (and my manager) at N1 SPS who taught me what good engineering is, and made my stay at Sun truly special. 

All the best, Sun.

 
P.S: My blogging bursts continue here.

Posted at 10:02AM Jun 30, 2007 by Bharath Ravikumar in General  | 

Show me the media

Despite the rave reviews that JavaFX has received, one can't help fretting over Java's future as a "RIA" platform. Considering Java's 2D/3D graphics capabilities, JavaFX/F3 (with tool support) would no doubt leapfrog Flex/Apollo/Silverllight on that front. But what made flash the delivery platform of choice for a Youtube or a Google Video is not its technical superiority : its the support for basic/standard audio and video formats. And that's where Java (with its near-dead JMF) sorely lacks. While the download size can hurt Java on the desktop, the lack of media support is, imho, the principal crippling factor. Once that is addressed, JavaFX might just need to add constructs to leverage the JRE's media capabilities. But until such a time, there's plenty of catching up to do for Java in the Rich Internet Application space.

Update: I find it rather ironical that today's java.com feature video of JavaOne is delivered through - you guessed it - a flash player.

Posted at 10:06AM May 12, 2007 by Bharath Ravikumar in Java  | 

Fuelling innovation

Google's Marissa Mayer on what keeps Google ticking (and more importantly, attracts talent). Topics covered include 20% time for engineers, challenging engineers to think at the next (intellectual) level to solve interesting problems, how engineers take pride in working with really smart peers, absence of micromanagement, how the company learns from mistakes, assimilates ideas from various quarters etc.  Going through the video, you'll realize that nothing of what she said is Nuclear Physics and is mostly common sense. But truth be told, very few large technology companies foster such an environment or follow such practices to the T. And that explains the growing chasm between Google and the other Engineering companies. As simple as that.

All said and done, worth a watch. (The first 25 minutes are most relevant).

http://www.youtube.com/watch?v=soYKFWqVVzg

Posted at 05:40PM May 05, 2007 by Bharath Ravikumar in General  | 

More on the "unteachability" of the java language

Elliotte Rusty Harold writes about yet another fancy feature proposed for Java SE 7.  For the record, here's my comment posted there: 

I'm glad you brought up the topic of the increasing "unteachability" of Java. If you want to do the language a favor, next time, please laugh off (to put it lightly) anyone who tries to profess fancy versions of closures, a new property syntax or other such forms of geek entertainment. The Java language is not some kind of a guinea pig on which you try out various experiments and, if they fail, throw it away and just pick up a new specimen. If they want to experiment with the language, ask them to use the kitchen sink. But please let them not come up with complicated and absurd proposals just to kill time.

I'd like to reaffirm that I'm not against well thought out, beneficial features being added to the language without complicating its type system or compromising on its ease of learning. (Talk to Jonathan Schwartz if you think its unimportant to reduce barriers to entry or make it easier for new developers to pick up your language and tools.) You do not have to design for fools, but your needn't make it a playground for theorists either.

P.S: Cay Horstmann in his post makes a fleeting mention of how his students lapped up CICE immediately, but took a lot more time (and required guidance) to comprehend BGGA. Need I say more?

Posted at 11:36AM Apr 20, 2007 by Bharath Ravikumar in Sun  | 

Google adds Java powered office product

Tonic systems (some name, huh?) is the latest addition to Google's repertoire of online productivity products. What's more, its Java based. While ThinkFree was always around on the text editing front, Power Point equivalents weren't getting enough press, imo. But hey, Tonic or ThinkFree may be some of the first Java based online products, but if you consider webstarted programs, the honor of getting there first probably goes to Gosling's Huckster. :-) (Really, check it out. You won't be disappointed.)
And you thought Java as a web based rich client platform was long dead...

Posted at 07:15AM Apr 18, 2007 by Bharath Ravikumar in Java  | 

Ruby on rails bites the dust

Interesting post on how twitter has found it hard to scale its ruby on rails infrastructure. While Java EE  is often called bulky (true of EJB 2.x), clumsy(blame it on struts) and such names, ruby and its cousins are often lauded as the silver bullet for all web development problems. Though I've found ruby on rails awe inspiring (first saw it demo'd by Charles Nutter) for rapid prototyping and building lightweight applications, I've always doubted its ability to scale. Contrast twitter's case with the scale that eBay has achieved using servlets, custom connection pools etc., and you'll see why Java is leagues ahead in building large-scale server applications. And we haven't even started talking about the wide range of F/OSS middleware and tools available in the Java ecosystem.

Posted at 11:01AM Apr 17, 2007 by Bharath Ravikumar in Java  |  Comments[4]

BGGA closures and the principle of least surprise

Due to paucity of time (and that's an understatement),  I wasn't able to post an elaborate rebuttal to comments on the previous post on closures. But Prof.Cay Horstmann's post on java.net has stirred up enough interest to warrant another post. I concur with one of the comments (that of Mikael Grev) in the blog.
While we all completely agree that Closures are important, one mustn't forget that code is written and (more importantly) read by developers. Humans, that is. And for newbies (and unsurprisingly, for java old-timers too), the principle of least surprise applies. Take a small survey of university students (even those that have started with C) and ask them if (and if yes, why) they prefer Java for application programming - and they'll tell you its the easier learning curve and intuition. When you read a certain segment of Java code, you can make an intelligent guess (knowing just the very basics) as to what the developer was trying to achieve. Its not the "generality" of the language that makes it ubiquitous - can java do a good job of playing various audio formats, or detect your USB drive and launch an application in response to it in a cross platform fashion? No. I hate to admit this, but Java remains dominant on the server side (and on mobile devices perhaps). It still has a long way to go (=>there're plenty of growth opportunities, which is good) on the desktop front. Which means it isn't yet a jack of all trades. A the ease of learning it remains one of its key strengths.

Speaking of readability and intuitive languages, there're very few "gotchas" in the JLS. (As much as one is tempted to compare the BGGA spec to the JLS, the latter is a delight to read.) And you won't hear Java developers talking about how their job interview involved "tell me what this piece of code does" kind of questions or other puzzlers. The fact that after more than a decade, there's just one seminal Java puzzlers book is a tribute to the language's simplicity. While developers are still grappling with changes to the type system brought about by generics (despite the excellent non-reified approach adopted). As one commenter pointed out, there're now entire sites and books devoted to generics. At such a point, how do you explain to a newbie (and we needn't debate how important it is to get more developers to take up Java) that for the sake of completion transparency, you need a new type Unreachable that's a subtype of all types, and of which null is a subtype? And I'll let you make a judgment on which of the following two pieces of unrelated code, each having a different level of conciseness and clarity, appears closer to the existing Java syntax:

{int=>int} plus2 = {int x => x+2};

and  

new Thread(Runnable(){ foo(); }).start();

For the former, should the developer be asked to go lookup the BNF in the spec or understand how closure conversion works, to get a better understanding? On similar lines, as useful as it'd be to similarly have first class XML support or embedded SQL in Java, it brings with it clutter and code-obscurity. When you expect to read Java code, you should get to see just that - and not ruby style blocks and or contortions like the absence of semicolon in the last line of a block. Also, I disagree with the argument that only API developers need to be aware of Closures with the rest of the world blissfully using it. As Josh Bloch pointed out, if you code extensively, you're more likely than not an API designer. So there's hardly any escaping the cognitive load of syntax like that of BGGA function types. In conclusion,  and IMHO, as a user of the language - I'm no language expert - I'd prefer readability of code and preserving of the existing type system at the cost of feature-richness. It's great to have control abstraction API, expressiveness and conciseness, but it's better achieved in a way that doesn't complicate the type system. I'd rather see the the CICE with ARM blocks or the FCM proposal enhanced to address this need instead of a sledge-hammer panacea proposal. The Java community surely needs Clourses and has asked for it in several polls, but let's make no convenient assumptions about what form of closures it seeks.

P.S: If you found it painful to go through this "rich and expressive" post due to excess of hyphens, brackets, commas at unexpected points, I'd compliment myself for having highlighted the importance of readability (of prose and of code).

P.P.S: Next post : when time permits.

Update: Stefan Schulz notes that there is indeed a proposal to extend FCM to accommodate control abstraction API.

Posted at 01:33PM Apr 14, 2007 by Bharath Ravikumar in Java  |  Comments[1]

Happy Birthday, Sun!

Sun turned 25 on the 24th of Feb, 2007. For all the naysayers:  we're alive, relevant and kicking.

Posted at 12:53PM Feb 25, 2007 by Bharath Ravikumar in Sun  | 

Missing in Java SE 7: Simplicity

Posted at 08:56PM Feb 01, 2007 by Bharath Ravikumar in Java  |  Comments[4]

Programmatically looking up Java reserved words

(Warning: the solution discussed is specific to Sun's javac compiler and is not "vendor" agnostic)

Let's say during code generation, you want to make sure that you don't use java reserved words as identifiers. Trivially, you could go through the hassle of creating an Enum for yourself and manually populating it with known reserved words for that version of Java. But, why reinvent the wheel when the compiler already has that information (updated per release)? All you need to do is create an EnumSet from the Enum com.sun.tools.javac.parser.Token and look it up to know if a certain String is a java reserved word.

The only problem with this approach is that it relies upon an implementation specific class/package(com.sun.* can change without notice and do not constitute an API). But if laziness takes over, its still an option worth considering for one-off usage. Of course, I'd like to know better (implementation independent) alternatives.

Thanks to Sundar for providing pointers in the javac source.

Posted at 12:57PM Jan 21, 2007 by Bharath Ravikumar in Java  |  Comments[3]

Putting type tokens to use

I recently found the need to write a (quasi) command object that's an abstraction of a CLI command. Roughly, it looks like:

public abstract class CLICommand{

    //Some implementations go here...

    protected abstract String getCLIString();

    protected abstract Map getCmdParams();
}

Now you might ask, why not simply have an execute method as in:

public abstract class CLICommand{
    //Default implementations go here.
    public Object execute();
}

(Or, to further refine my version, why not have a Command interface and an abstract base class providing default implementations of some methods? Agreed, but that's not the point of our discussion now. Moving on...)

The primary reason for not having a conventional command object is circumstantial: in our case, the command objects themselves do not have all the information required to execute the command. In particular, they will not have the authentication information needed to (remote-)execute the command. All they can do is to provide command specific parameters, string representation and such details. Due to legacy reasons the security related information is kept in a ThreadLocal field within the command executor. (Otherwise, the security related information could be stored in a "secure" class could wrap around a bare-bones command and could remain transparent to the executor. Anyways...)

Subclass of the classic Command object might return different  types depending on the command executed. So, we'd generify  the command object as in:

public abstract class CLICommand<T>{

    //Other impl details
    public T execute(Map params, ...);
}

But, how would you apply this to the pseudo command object we're dealing with?

Enter type tokens. In Java SE 5, the class Class was generified (with additional type parameters named type tokens). For example, the type of String.class is Class<String> (Of course, Class' methods were further generified in Java SE 6)

So, here's what our neo-Command class would look like:

public abstract class CLICommand<T>{
    //Some implementations go here...
    protected abstract String getCLIString();
    protected abstract Map getCmdParams();

    protected abstract T getReturnType();
}

And how would a command executor use this?

public final class CommandExecutor{

public static <T> T executeCommand(CommandIF<T> cmd){

         //Relies on a legacy non-generic executor that declares
        //return type object, but internally returns a specific type
        Object result = oldExecutor.execute(cmd.getCmdString,
                                cmd.getParams());
        return cmd.getReturnType().cast(result);
    }
}

And voila! We're done! If you're curious to know how you'd handle a command that returns nothing, here's an implementation of such a command:

public final VoidCommand extends CLICommand<Void>{

    public Class<Void> getReturnType() {
        return Void.class;
    }
    //Other details...
}

Update: To be absolutely sure all kinds of type parameters (including parameterized types) can be returned and used, you'd want to use Neal Gafter's super type tokens.

And as if all these considerations weren't enough for the day, a related piece of code that was compiling in Java SE 5 fell apart  in 6. The reason: a rather presumptuous, short sighted cast that I had introduced:

Map<String, String> props =
                                     (Map<String, String>) propertiesObject;
It was merrily compiling in Java SE 5 thanks to this compiler bug. Sigh.

Posted at 01:49PM Jan 16, 2007 by Bharath Ravikumar in Java  | 

RMI sans the rmiregistry

Eamonn McManus recently blogged about ways of securing the RMI registry from local modifications by malicious clients. If you must use the registry, those are effective (if slightly hacky) techniques to secure the RMI registry. (On a related note, a number of RMI-newbies tend to wrongly assume that the rmiregistry is somehow responsible for routing every method invocation and must be used all the time.) But RMI separates the "discovery" of a server object from the actual invocation upon it. (Notice that I said server object and not service - with all the SOA buzz and self-proclaimed "experts" criminally equating SOA to WS-* standards, I hesitate to use the word "service" and have readers make faulty assumptions based on jargon. Anyways...) When you initialize the RMI server implementation and export it through UnicastRemoteObject.exportObject, the returned java.lang.reflect.Proxy object implements Serializable as well (The proxy mechanism became the default instead of rmic generated client stubs in Java SE 5). As a result, you're free to share it with potential clients as you please: write it to a directory server that allows RBAC, persist to a DB, serialize it over a socket, put it up for clients to download from a web/ftp server and so forth.

In fact, such flexible service discovery is one of the key features of Jini: while you're welcome to use the default lookup implementation ("Reggie"), the Jini API makes no assumption of the discovery service implementation. In fact, any host can run a Lookup service and lookup services themselves can be dynamically discovered. No, that was not a circular definition - you can use multicast to lookup a discovery service. How cool is that?

 
In summary, if you're planning to build a system using RMI, you're free to use your own lookup service if rmiregistry doesn't serve the purpose. You must, however, evaluate the merits/demerits of one approach over another before deciding upon the actual implementation.

(And by the way, wish you a peaceful, healthy and prosperous 2007 :-))

Posted at 01:38PM Jan 01, 2007 by Bharath Ravikumar in Java  |  Comments[1]

Sun's X64 servers top InfoWorld reviews

The Sun Fire X4600 series tops the list, beating HP ProLiant and Dell PowerEdge. Quite a flattering review.

(Thanks to James Dickens for the link) 

Posted at 12:02PM Dec 10, 2006 by Bharath Ravikumar in Sun  |  Comments[0]

Hello World

Hi there. I'm a developer for the N1 Service Provisioning System. I've been with Sun for a little over a year now. I'll mostly be writing about my experiences and what I learn at work, typically featuring Java, Solaris and netBeans. Stay tuned.

Posted at 02:19PM Dec 07, 2006 by Bharath Ravikumar in Sun  |  Comments[2]