Pat throws down the proverbial gauntlet with Java People Must Be Stupid. It is a couple of bodily fluid references away from being a Hani post. In short, he discounts the need for strong typing in Ruby:

How do I make Ruby safer? It’s a topic that people bring up on the mailing list every once in a while. People shouldn’t be able to open my classes. They need compile time type checking so the app doesn’t blow up. Extending system libraries is bad.

Seriously, browse through ruby-lang for threads where the starter needs Ruby to be more “safe.” A ruby hacker will cheekily ask, “Why do you need static type checking? Are you going to try to regexp match an Animal?” “Well, no, not ME of course, but somebody else might.” I don’t even know who “somebody else” is most of the time. Is it someone on your team? Is it someone from another department? Is it some random guy who downloaded your library?

Concerns like these all seem to boil down to one major theme: The people I work with are stupid.

[snip]

The more serious issue is when “someone else” refers to someone whose welfare you actually are interested in, or, god forbid, responsible for. If you need to protect someone on your team from code, there are two scenarios in play:

1. The person is stupid
2. The person is naive

Neither issue is really that difficult to handle. The first one has a very simple solution - fire them. You heard me. If you’ve determined that this person truly has no chance of learning how to judiciously use some piece of code, there’s zero chance they’ll had value to your project. Programming is a vigorous intellectual exercise, and I’ve never seen incompetence actually benefit such endeavors.

[snip]

Ruby doesn’t need to be more safe. It certainly doesn’t need static type checking. What we need is to kick the idiots out, and educate those with less understanding. Doing so improves those individuals, ourselves, and our craft as a whole. It doesn’t take much more effort than trying to keep people from shooting themselves in the foot and performing damage control when they find workarounds. The benefits are obviously way better. So what’s stopping you?

Now. Let me be clear here. Static typing isn’t an end-all-be-all of making your language safe, and certainly not foolproof. But there are some important things to consider here.

1. If you are creating an API for other people to use, typed arguments and returns make your code (closer to) self-documenting.

One of the things that kills me about the Ruby people is more than a few times when someone asks about the types going into and out of API type methods, the answer is “Write a test case.” This strikes me as the apex of lazy on the part of the API developers. You didn’t document it, and the language doesn’t give me good hints, so it is my problem to figure out how the method works by writing tests. Like I want to test someone elses code. Frankly, this kind of thing pervades Ruby as a problem. The JRuby guys are constantly bumping up against the fact that Ruby has no language spec (though the Wikified spec process has recently begun) which means they have to test and replicate every edge-case behavior in the language. You carry this forward into APIs and, idiot or not, you are making more work for other people.

Now, I am a fan of duck-typing. Indeed, support for duck-type adapters in Java is one of the reasons I have wanted Java to have Dynamic Proxy support for concrete objects for so long. I hope that language level property accessors will open up this possibility as the entire front-side of an object will be definable in interface form. However, feed( Duck ) is still easier to figure out than feed( Object ). In a dynamic language, you don’t even have to enforce it, but having it simply expressed — as you can see in ActionScript — helps a lot for people using your code.

2. Extending core classes is a security problem.

One of the powers of dynamic languages is that you can runtime alter objects. (As an aside The Crockford Lectures at Yahoo on JavaScript are great) This is powerful, and in the scope of the kind of work being done in Ruby, or even the still basic AJAX stuff in JavaScript, it is all well and good. There is a reason, however, that String and Integer are final classes in Java: because in the C++ world, the ability to replace the String implementation in a library was one of the most common vectors for Trojan/Malware code to extract things from a secure system.

When you work in a large enterprise with many teams working on many internal applications and internal APIs that those applications use with a mix of security modes for each of them, opacity is sometimes important. More important, however, is making sure you can’t inject a String that, say, emails passwords to some account, or at runtime clobber the behavior of a policy-managed class. In this case, having ENFORCED typing is actually important. While there are certainly large Ruby apps roaming around out there, I haven’t seen any discussion of multi-team/multi-project groups in an Enterprise dealing with these issues yet. Isolation via WS-* calls is an option there, but sometimes that is less than practical.

3. Static Typing makes large-scale automated refactoring possible.

As a GWT fan, one of the things that people keep looking at Java for is the tooling. While Tor seems to be making great strides in the Ruby support, automated refactoring in untyped languages is hit and miss at best, completely impossible at worst. For my money, good refactoring tools in the hands of the average developer has been one of the great leaps forward in development over the last decade, and it is a big encouragement to have better APIs and internal code. Loss of this is not something I would like to see on a large scale. When you are talking about multi-project-multi team, losing the obvious checks against code that gets a new version of an API is a problem, even if the refactoring works as advertised in the API project. Again, you are back to writing test cases against someone else’s API to see if there are obvious breakages.

All these points aside, I won’t dispute that there are a lot of bad developers out there. I am certainly not going to call Ruby people stupid, but I think there is a mismatch here. I like Ruby, and it obviously has big advantages in certain scopes, but those advantages cost it in other areas. Seeing people advertise it as the end-all-be-all language without admitting the places where it is worse than what we have in other language is a staggering level of arrogance.

Dear Bruce,

First up, thanks for the book. Yes I’m saying thank-you about 8 years too late. ‘Thinking in Java‘ is what got me going in the language and in my mind is one of the best Java books written (sorry Tim). Giving it away free only cemented your reputation as the Bono of the Java world. OK, Bono without the Guitar, the Stetson and with a couple of overloaded constructors thrown in, but a man of stature nonetheless.

Secondly, I’ll forgive your flirtations with Python, on the basis that I’ve been having an affair myself with JRuby. I now understand the pain that you’ve been having at home, the endless repetitive arguments to get simple things done, and the temptation of a newer, younger, more flexible model.

So , I think you’re onto something here in your blogpost. I can feel the pain, the need to deliver Rich clients to users over the web. I think that Ruby / Google Web Toolkit / Struts 2 / Name your web toolkit has further to go than you may think , but eventually these ‘heroic efforts‘ (nice quote) will run out of steam. On the basis of your recommendation alone I’m willing to look at Adobe Flex, but I’m not sure if this is going to solve all the problems.

Now , a lot of us Java guys don’t like change (and as if you needed proof, just look at the comments on this O’Reilly blogpost on the Google API’s). All the same , we have a problem that gets worse every passing year. 6 Years ago we could have been sure that 90% of web sites were running Internet Explorer 4. Now we’ve got IE, Firefox, Safari (in all their different versions) as well as an explosion of mobile devices. The Windows Vista launch is only going to fragment things further with yet another platform to support.

No one web solution is going to display the same in all of these browsers. We’re not going to get a single solution from Microsoft / Sun / Adobe that everybody from a developer to my Granny is going to install. So we’re going to have to take the ‘least bad’ route - something that looks great, but degrades gracefully to standard HTML on less capable devices. Excuse my ignorance, but I don’t know (yet) if Flex does this.

Yes Hybridizing open source Java is the starting point for the solution. Unfortunately we’ve a long way to go yet, and Flex is perhaps only inspiration along the way.

Yours sincerely

Paul, Technology in Plain English

Update 1 just to be clear, I do have a lot of respect for Bruce and this blog post should be read in that light.

Update 2 The Adobe Apollo project appears to be a continuation of flex. While it has more power, I don’t know if it solves the degrade gracefully problem.

. Maybe we’ll actually use the MVC design pattern to build more than one interface - a rich client (choose your technology) and a basic one , for use by mobile and older devices.

This is one of those blogs where I’m trying to take off my editor’s hat and speak with my own voice. Usually, I do that when I plan on offending someone, so that it isn’t mistaken as being “official”.

Probably the first design pattern that every software developer learns is Singleton and lazy loading of Singleton classes.

The usual example, goes something like this:

public class Singleton {

 static Singleton instance;

  public static synchronized Singleton getInstance() {
    if (instance == null)
      instance = new Singleton();
    return instance;
  }

}

The problem with this solution is that synchronized method getInstance() is called every time, while synchronization is actually needed only for the first call of the method (which introduces performance overhead in your application). There were attempts to tackle this problem by using Double-checked locking pattern, which although great in theory didn’t work in practice.

Today, thanks to Bob Lee, I found out that there is a solution to this problem that is both simple and fast: Initialization on Demand Holder (IODH) idiom. The appropriate example follows:

public class Singleton {

  static class SingletonHolder {
    static Singleton instance = new Singleton();
  }

  public static Singleton getInstance() {
    return SingletonHolder.instance;
  }

}

Basicaly, Java Language Specification (JLS) guarantees that instance would not be initialized until someone calls getInstance() method (more information could be found in articles that I’ve linked to before). Elegant and fast, just as it should be.

Recently one or two people disagreed with what I had to say about the impact that the Google (and other) API’s will have on Java. Considering the ratio of positive to negative comments (about 3 for and 30 violently against), I obviously need to express myself in a clearer way. The link to the original post is at the end of this article, read on before you consider flaming me.

So , deep breath , here goes.

Compare the the way you develop now , with the way you built software 10 years ago. Do you remember having to manage your own memory? Or the pain of trying to deploy your software on different machines without a JVM? Or the hassle of trying to write distributed software using Corba? Or using a text editor instead of the fine IDE’s (Eclipse, Netbeans or JDeveloper - take your choice) that we have today? Would you consider building your software without a tool like Ant or Maven?

(Shudder). Things have moved on ,and I am very glad they have. Likewise, the way we develop 10 years into the future will be very different. I don’t know what the future will look like, but here’s a simple guess.

The biggest trend today is the move from software running on your computer , to software being delivered over the web. I’m not talking about the buzzwords being thrown about regarding ‘Service Orientated Architecture’ or ‘Enterprise Service Bus’. I’m talking about simple API’s that are available for use over the web today. Like the API’s and products from Google - including their Documents and Spreadsheets, and their Authentication service.

‘Everything should be made as simple as possible, but not one bit simpler’ - Albert Einstein

‘You Ain’t Gonna Need it’ - Anon, XP Mantra

As a good Agile Developer you’d probably agree with these quotes. But what if the most simple way of doing things was not to develop in Java at all? Most people don’t build their own operating system - they use Linux, Windows or OS X instead. Most people don’t write their own Java Server - they use Tomcat, JBoss or your server of choice. The pattern is the same. A small, dedicated core of developers builds the product, and the rest of us say ‘thank you very much’ and use it to get things done.

This range of ‘off the shelf’ solutions is increasing all the time , even before the online services arrived on the scene. As a Java developer , you’ve said ‘thank you’ , downloaded the latest version and integrated it into your solution. The time you save means you deliver other cool features instead. Java is very good at this ‘download and integrate’ process - not only is it a key benefit of Object Orientated Software, but Java has the widest range of solutions available (if you don’t believe me , just check out Sourceforge).

Java can also let us build our solutions (either partly or fully) around the online API’s. Java has great networking and XML handling ability already. In time this will become as normal as the idea of using a JVM. Great - we use these API’s pretty much like we do libraries today, and we can continue developing pretty much as before, right?

Wrong.

Remember, what is the most simple way of doing things? What if the most simple way of doing things was not to use Java but to use a more simple language (like Ruby or PHP) instead? Until now there were a couple of advantages that Java had over these ’simple’ (and that’s a compliment) languages. When using online API’s these advantages disappear, or worse, become a liability.

• Scalability and Robustness. Enterprise Java is massively scalable (it’s one of the reasons for it’s complexity). But can even you outscale Google?
• Security. Enterprises haven’t (yet) learned to trust the security of online applications. This trust will be hard earned over time. But already you can make the argument that your data is safer with Google / Amazon / other service provider than on your average virus-ridden home PC.
• Language Ties. To use the Java libraries you needed a JVM somewhere in your solution. Once you had a JVM , you might as well write your own solution in Java. But when the product you are extending is hosted elsewhere, you are free to code in the (most simple) language of your choice.
• Always on. As long as you have a connection to the web, your programs can use the API’s. Scripting languages like Ruby and Python can claim to be even more portable. Not only can they run natively in most environments, they can also be deployed via a JVM if that is your choice (under the guise of JRuby and Jython)
• Features. Need a feature that you don’t have in your scripting language? Just borrow it from Java by running in the JVM. How can Java win a ‘features arms race’ against that?

So do we face a form of developer apartheid, where a ‘hard core’ of Java Experts develop web API’s that the rest of us use via scripts? Let me know what you think. Like the original blogpost said, it may not be the end of Java, but perhaps the end of Java as we know it.

More in Technology in Plain English

Jeff Whatcott, Macromedia vice president of product management, is convinced a switch to a tiered licensing model will bring new developers into the Flex fold, a number that’s currently below 10,000.

“We’re very serious about getting a million developers using Flex to build RIAs on the Flash platform in the next three to five years,” he said.

Source - http://www.internetnews.com/dev-news/article.php/3554196. This statement was made back in October 2005. Similar statements have been made by Adobe in many more times in many more places.

Many would have read or heard this before.

Today we have between 3 and 4 million Java developers and we assume that this number grows to 5 to 6 million within the next three to five years. (Which itself is very optimistic, though Sun thinks they can grow the number to 10 million).

Now as per current estimates the number of Flex developers are still in thousands. Assuming that half of the 1 million developers that they claim they will have come from the set that are with Flash, ColdFusion, PHP or any other skill set, we still have half a million coming from the set of Java developers. Considering that the server side for Flex is Java, this even sounds logical. This implies that 1 in every 10 or at worst 1 in every 12 Java developers is learning Flex or already knows Flex today. What do you folks have to say about this?

There is one thing certainly real about Google Spreadsheets and that is “hype” !

Recently, a fellow blogger claimed the end of server side java was possible with the emergence of Google spreadsheets. Do Google Spreadsheets mean the end of Java?. Praises of Google Spreadsheets like everything else Google is commonplace, but this took me by surprise and makes me ask a more fundamental question - Is Google Spreadsheets even a spreadsheet that an enterprise could use? MS Excel, the most widely adopted of Spreadsheets in the enterprise today, not only provides the nifty functions and data management features (sorting and filtering type of capabilities) - some of which Google has replicated - but also provides a rich VB Macro based programming possibility and an easy integration with all the other MS Office applications. Excel spreadsheets can be easily dropped into the Outlook mail client and embedded into MS Word. Business users love MS Excel, not only because of its built-in features but the fact that plug-ins exist for functionality ranging from budgeting to exchange connectivity to software life cycle management to rules definition. Even if Google Spreadsheets API was so simple that it took a developer a couple of days to build a useful plug-in - its still a few years before it reaches anywhere close to what is available with MS Excel. How about Google letting us import the spreadsheets into Gmail for starters?

Is Google Spreadsheets an online collaboration extension to spreadsheets like MS Excel or is it anything more? (Microsoft already has an initiative to bring the spreadsheet to the web).

Remember, that I like Google and I am a Java evangelist but should that make me blind?

A couple days late, but I just wanted to wrap up the Sun Tech Days notes.

Really, the Tech Days presentations seemed to suffer from the same problems that the NetBeans Day presentations did: they seemed dated.

The perfect example was a session titled “Java SE Today and Tomorrow.” The thing is, the “Today” was a rehash of all the features in Tiger that most of us have already familiarized ourselves with months — if not over a year — ago. “Tomorrow” was Mustang which is, ahh, in general release. No talk of language level property accessors, XML support, the FindBugs derived annotations.

The presentation on JPA was actually not bad, but it was, again, old news. The group of people I was with were very nearly praying for death by the time it ended. While there was “that guy” in the audience who seemed to just want to get help with his code, I think most of the people there would have appreciated a much more detailed presentation on a narrower scope. The WSIT presentation by Arun Gupta was great — again. Mostly it was nice to see progress in this effort, but with WCF and .NET 3.0 being GA now it makes me wonder how much of the remaining work will be JAX-WS working around stupid Microsoft stuff rather than both groups “doing it right”.

As an aside, I have found myself frustrated with the JAX-WS RI and moving back to using XFire for a lot of things because of a mixture of annoyances in the JAX-WS clients (using JAXBElement when an element is xsd:string nillable=true minoccurs=0 for instance. Yes I understand why, but it is still annoying since most SOAP servers treat nil and absent as the same thing) and incompatibilities with NON-.NET clients in the server (Using the same element name in different namespaces for no reason makes Flash angry, and the inability to get the schema inline with the WSDL angers Pear:SOAP an others). Add to that, the fact that our external clients on the day-job can’t even get to SOAP 1.2 support, all the swankiness of the WSIT suite of WS-* specs isn’t even going to be on the table for us for a while.

Aerith showed up again in the general session. I didn’t go to the Pimp my Swing session, but I was informed it was pretty much the same thing from Java One.

The end of the day was a “NetBeans/Eclipse Shootout”. It was kind of interesting, but mostly it was just showing off the features we all know are there in the two IDEs. Personally, I wished it had been more along the lines of “Here is a couple thousand line Open Source project that people know, and here is a list of tasks to accomplish” kind of challenge. It was interesting to note that though STDs (an unfortunate acronym) was in Atlanta, the only JBoss employee to be found was on the “Eclipse” side of the shootout. What happened to making Fleury wear the goofy shirt around?

While the big features of NB are great, that day to day, hour to hour stuff is the annoying bit. Field encapsulation is a 1-keystroke operation in Eclipse, while it is a (minimum) 5 mouse click operation in NB. In a lot of ways, I find my relationship with NetBeans now is like that with an old friend: I can easily tell you everything about it that annoys me constantly, but coming up with the reasons I originally befriended it is a little harder. And yet, I “like” it better than the alternatives.

All in all, it wasn’t a really thrilling day. The “dip your toes in it” level of the presentations seemed far below the level of the room. A majority of Java Enterprise developers have been working with some, if not all, of these technologies for a while now and could really have used a bit more depth, or even just doing some free-form “ask the expert” sessions would have been good. Honestly, if I needed an “intro to technology X” session, I would rather go to an AJUG meeting. On the plus side, though, there was plenty of swag. :)

Google is looking at Java based online office suite despite of having Docs & Spreadsheets!

Computerworld reviewed online office suites Ajax13, Google Docs & Spreadsheets, ThinkFree Office Online and Zoho Office Suite . The winner is ThinkFree and the runner is Zoho, same as I mentioned in my previous blog Google is not the leader in Ajax applications.

The reason to pick ThinkFree was:

It looks more like a full application: menus, a rich toolbar, a ruler bar and even a drawing toolbar similar to Word’s for inserting elements such as AutoShapes, text boxes, clip art, and pictures.
In fact, ThinkFree’s Power Edit menu reveals a startling number of word processing features, from columns and drop caps to AutoCorrect and table manipulation, such as merging cells, distributing cells evenly across the page, repeating header rows.
ThinkFree hides your browser’s menu bar, so when you use familiar keyboard shortcuts (such as Alt+F, O for File/Open), you are operating within the ThinkFree interface, not your browser. Other similarities to Microsoft Office are downright eerie — the charting wizard in ThinkFree Calc looks just like Excel’s and supports all of Excel’s chart types.

Think free offers their word processor in two flavors: Quick Edit and Power Edit. Quick edit is Ajax version of the editor which offers a minimal interface — a few toolbar buttons for simple editing and some other features. All above features(listed in block quote) are only available in Power mode which is Java(applet) based. They used Java for more complex functions and for deeper Microsoft compatibility. However, initially the Power Edit takes time to load as it has to download the applet.
So the question is, why can’t they support all Power Edit(Java) features in Quick Edit(Ajax)? According to ThinkFree CEO TJ Kang:

Currently the best way to offer advanced Web Office functionality is to utilize Java. Ajax doesn’t cut it when it comes to advanced functionality. Although in theory you can build it in Ajax, the resulting code will be so big that it will take ages to download stuff and slow the system considerably. So Java is, much more efficient than Ajax when it comes to implementing Microsoft Office-like functionality.

Since they have both Ajax and Java versions, I don’t think his comments are biased towards Java. At the same time don’t forget that initial download time of an Applet is significant and browser needs a Java plugin.

In other prospective, Google is not in the top 2 list of the online office products, because:

High-end documents don’t render properly because Google Docs isn’t 100% Word-compatible, nor does it claim to be.
Google Spreadsheets has a few compatibility issues with Excel (array formulas aren’t supported, for example), and its lack of charting support is a disappointment.
However, even Google Inc. may be ready to admit that its office applications aren’t ready to take on Microsoft.

For Google, its clear that it cannot compete with the Microsoft with its Docs & Spreadsheets. Unless they support all MS office features, it’s difficult for Google to win the race. Perhaps, it’s difficult for them to support all the functionality and MS office compatibility with their current approach(Ajax). So here are the options for Google to win the race:
1. Support all the functionality with Ajax even though the resultant code is going to be big and ages to download
2. Despite of initial download time, rewrite online office suite utilizing Java .
3. Buy ThinkFree

Guys, what you think? Based on Google’s recent acquisitions, do you think that their option will be 3? You are right, they are already in talks with ThinkFree.

Google is reportedly in talks with a South Korean software company and its US subsidiary ThinkFree, which makes browser-based office productivity software compatible with Microsoft file formats.
ThinkFree is a subsidiary of Haansoft, which is based in Seoul. Haansoft’s CEO, Baek Jong-jin, said he met twice this month with Google’s corporate development team responsible for the $1.65 billion acquisition of YouTube, the English-language newspaper Korea Times reported on Sunday.

I think definitely this move is adding fuel to the ThinkFree’s Java approach. But I believe both have advantages & disadvantages and it depends on what functionality you are trying to achieve it. For example, Java makes life easier to do image handling and animations. On the other hand, ajax is much faster and no plugin is needed. So if your web app is going to have much advanced features such as image handling etc. definitely Java is more efficient than Ajax.

What do you think? Do you agree with ThinkFree CEO TJ Kang? Do you think Google realized that they cannot achieve the advanced functionality with Ajax? Or do you think they are talking with ThinkFree as a part of their acquisition strategy? If you know any Java apps that are powerful than Ajax apps, please add in comments.

Update 1: Fellow blogger Paul Browne wrote ‘Do Google Spreadsheets mean the end of Java?‘. Please do remember that he is talking about the server side Java and I am talking about the client side Java(Applets).
Update 2: Trimmed the title as per Tim’s suggestion. Thank you Tim.

Find the CodeMash Conference coverage on Inside Open Source.

It’s not just for Java, but blended development that includes Java, Ruby (on Rails), PHP, .NET, etc.

Most programmers follow a similar development path. Introductory material leads to more advanced material, a new programmer might start with learning types and conditional statements, then move on to data structures and algorithms. Eventually most programmers are confronted with Design Patterns, the promise - the promise that “everything is a pattern”. And, while Patterns are important, they are not a panacea. In fact, when I sense that people are trying to over apply patterns it reminds of my 15-month old daughter learning shapes. She picks up a square peg and tries to jam it into a round hole, when this doesn’t work she gets a little frustrated, and when that doesn’t work she redoubles her effort until her attention drifts to something else (like Curious George).

Design Patterns: Powerful, Essential, (and Dangerous)

“We use patterns” is not a shibboleth for success. When a new programmer starts to get interested in patterns, I tend to have a mixed reaction. On the one hand, patterns are an important part of engineering any large system. If you are implementing anything with more than a few thousand lines of code, a working knowledge of patterns is a prerequisite; it is convenient to tell someone that this particular system uses an AbstractFactory or the Command pattern. Alternatively, I’ve also seen a number of systems that either overapplied or abused patterns by applying them when they were not appropriate, confusing one pattern with another, or just getting a pattern wrong. (…umm..someone must have read the book backwards because this is definitely not MVC.)

In my own experience, I ran for design patterns at the same time I was infatuated by UML. In 1999, patterns supplied the language I needed to take that next step to understanding larger systems, and my office walls were plastered with man-sized static structure UML diagrams. Patterns + UML made it easy to visualize and communicate, but I found that approaching problems with patterns in mind tended to affect the solution. Subconciously, I would think of some way to apply a “pattern” to the problem. (And, then, all of a sudden everything was an AbstractFactory…) Patterns appeal to the idea that one can escape the day to day frustrations of programming by capturing abstract structures which can be universally applied. All the books about patterns appeal to this ideal, and they tend to play upon Patterns as a pancea or Patterns as a common language. (Patterns as Esperanto.)

Read more…

Or to be more accurate ‘Do Google Spreadsheets mean the end of Java as we know it’?

Update: There is a reply to the (many) comments on this blogpost here: Java and those pesky Google API’s

Think about this. Who pays your wages Mr Java-Developer-who-has-just-had-a-couple-of-years-at-the-top-of-the-pile? Clients, or if you’re in a larger organisation , the business folks (i.e.’internal’ clients). Do you think any of them care about Java? Do any of them know what Java is? All they want is to get things done, quickly , and with as few mistakes as possible.

These business people would be happy to run their organisations on Spreadsheets. Do you remember the cartoon where Dilbert convinced the pointy haired boss that he could fly the plane using Excel? There’s more than a element of truth to this. I know of at least one US Fortune 100 company that (until recently) conducted most of it’s operations on little more than Microsoft Office and duct-tape. It worked, not very well, but it worked.

Until now , the next line would be ‘Excel (or any other type of Spreadsheet) is not secure / scalable / sharable / not web friendly’. That was until Google launched their Docs and Speadsheets. It’s an online version of Office with some spreadsheet functionality. Play with it a bit and you’ll see that there’s plenty missing. But this being Google , I’m willing to put good money on

• (a) new features rolled out (think steamroller) and
• (b) These Spreadsheets being massivly scalable / secure / sharable.

This being Google, there is also an API (developer page here). It’s got massive holes in it (e.g. you can’t yet use it to create a new spreadsheet). But when Microsoft bring out their version of online spreadsheets (and they will) not only will they clone the Google API (to get market share), they’ll need to go one further and introduce new features / remove the usage restrictions in order to compete.

So, secure, scalable, sharble online spreadsheets are here to stay. So lets take a look at Mr. (or Ms.) Pointy haired boss thinking about their new project:

1. Hmm, I think we need to be able to gather which health plans our employees are enrolled in.
2. OK, I’ll throw together a spreadsheet to show people what I want
3. Before I’ll give to our friendly Java developer and let him ‘do’ a website from it.
   Soon I’ll just share this on Google.
4. Great , Loads of people are now using it, I’ll just the (Ruby / PHP / Insert other language here) guy to add one or two extra features.
5. Most Excellent. Why don’t we spin this off as a Web 2 company and sell it to EBay??

There you have it, Massively scalable , Highly secure websites (see Google Authentication API), without needing to know anything about EJB, JMX , JBoss, JDBC or any of the hard won knowledge that us Enterprise Java Developers have built up over the last 7-8 years. I’m exaggerating, but not much.

What do you think? Is Enterprise Java dead, or is Web 2 just another boost and a slightly different way of doing things for us Java people?

Other Java Posts from Technology in Plain English

Some other notes:

• Java is read once , run almost anywhere. The ‘Almost’ is because (for various technical reasons) the difficulty in getting reasonably priced web hosting. Have your tried getting some recently - impossible to find , or at least impossible to find at the prices PHP and Ruby guys can get theirs?
• Tim O’Reilly with was right with the notion of Web 2.0 and the network as a computer. We’ve also written about the notion of online software being at a tipping point.

Here’s a potential media application. Can Flash or one of the Java media libraries handle it?

I’ve been covering Java on the Mac for a little more than ten years now. Fortunately, I have other beats. If this were my only focus then I’d be really worried by a Steve Jobs quote on David Pogue’s blog.

The CodeMash Conference is dedicated to educate developers on current practices, methodologies and technology trends in variety of platforms and development languages such as Java, .NET, Ruby and PHP. It starts Thu Jan 18, 2007 and concludes Fri Jan 19, 2007, and is being held at the Kalahari resort in Sandusky, OH.

Sun Microsystems, Inc. came out as the #1 contributor to open source in Europe. As reported by Sun’s Simon Phipps and Kevin Roebuck in their blogs, the European Commission just released their report on the Economic Impact of Open Source and the impact in ICT in the European Union.

So, Sun Tech Days is blowing through the dirty south. Today was “NetBeans Day” (with a parallel Open Solaris event).

Boy it was unimpressive. The opening was actually kind of funny. The speakers were pretty obviously preaching to a hall of the converted already, so the kind of “Yay us!” marketing opening seemed almost funny. Things really got hilarious when people started asking Tim Cramer and co. actual technical questions at the end of a “look at our market growth!” speech. Honestly, I felt the questioners’ pain. Given the nature of the people in the room, I think there was much more of a desire for a heads down technical session than it turned out to be.

All in all, the content seemed dry. It was the identical pitches given at the last NetBeans World Tour and at J1 last year, which kind of stunned me. Given the cool stuff we have seen coming from Tor and Charles on JRuby, the whole Groovy 1.0 events and the revamped editor framework, I was really hoping to see a lot of “Look at the awesomeness that will be 6.” In stead we got a rehash of stuff that is kind of old news. Yeah, the JEE support is cool. Yes, the UML tool is free and round trips (in spite of the fact that graphically it is ugly and it is impossible to get the lifeline titles lined up right in a state diagram). This all would have led to a somewhat disappointing day… then came the last few presenters.

Here’s a tip: get an engineer to do these. They might not be the most charismatic speakers, but at least they will likely know how to use the product. Watching people with less knowledge of NetBeans than I have fumble through a presentation was almost painful.

OH, and Note to Sun: Making a JSF page that submits a form to another page that renders a prepopulated Google Maps component is *not* making an AJAX application. Please stop giving this demo as an example of “AJAX” development. I have seen it three times now and it makes me want to womp someone on the head every time I see it.

Tomorrow is the “big” event day. They have another Pimp my Swing session, I assume it will be the same one as J1. There is something else on Tango scheduled. I was really hoping NB Day would be a place where I could get some real questions answered, and I would love to pound someone from Sun with questions about Tango and JAX-WS. At this point, I am actually thinking about going into the Solaris sessions though. I figure I might actually walk away with new knowledge that way.

Update: Solution presented in this post is integrated in XStream 1.2.2 and you are advised to use the official (and maintained) release. See this post for more information.

It seems that JSON vs. XML debate was one of the hot topics for this winter. Again, I think that “vs.” part is sufficient and that both XML and JSON should have their place in overall technology landscape. One of the obvious JSON advantages is that it can be directly evaluated in JavaScript. And for the Ajax-world we live in, it is not a small thing.

For one project, I started looking for a library that would enable me easy transformations between Java and JSON data. JSON in Java looks nice, but what I really want is a more automated and configurable library like those we have for XML processing. My first thought was XStream since I like its simple API, extensible architecture, powerful converters and support for annotations. After first check I found that from version 1.2 on there is a partial support for JSON (which was logical thing to expect). So, currently you can serialize your Java objects to JSON format.

How many people out there have the following problem (as summarized in the following statement)?

“My application isn’t performing well in production because of some heap settings, and there are some configuration changes I need to make in production, but my operations group won’t give me access to the systems I need access to. I’ll talk about JNDI configuration of the DataSource, the heap size parameters, how to start the JMX console, but it is like my words are hitting a brick wall. Our platform is Java, but our system administrators don’t know the inner workings of the JVM heap or the significance of a stack trace. Every time something happens to a JVM, they escalate it to management as an unacceptable bug, but more than often is was a misconfiguration problem. To compound the problem, I haven’t been able to find Java programmers who are aware of the concerns of our operations group, and they’ve reached a very inefficient equilibrium. The administrators are always pointing at a stack trace and blaming the developers and the developers are always blaming the administrators. Every week there is another political blame festival, and I’m getting tired of the conflict.”

read more…

If you’ve read my previous posts, you’ll know that I’m on an unending quest for the right Java web framework. While Faces shows some promise, I’ve got this conviction that the future of the web-layer isn’t going to come from Sun. Call me pessimistic, I don’t care, i’m just not excited by the technology. …..so I thought I start another food fight by communicating some positive and negative first impressions about another Java framework - Wicket. Read more…

We all know of “cafebabe”, the magic number that identifies java executable file formats, and the discussions around its very existence which has shown up time and again on various groups including on comp.lang.java. However, what we don’t know is if this was indeed the reason for the very name “Java”? (Java was supposed to be “Oak” till the lawyers feared that there was a possible conflict). Were the baristas really so charming that they inspired the developers to name their very language in their honor? Or is it that 0xCAFEBABE sounded more decent than “oxAFABCAFE”, “oxCAFEFACE” or “oxABADCAFE” or cooler than “oxCoFFEE”. (Assuming that they were trying to get a 32 bit combination that sounded like a sensible word or phrase!). Also, Mac (thus Mac OSX in Apple) has the magic word “cafebabe” too. Does this mean that baristas have a much deeper impact on software development than we know of :)

BTW, what do you think will happen if a Mac fat file was given to a JVM to execute? Will it get confused because of the “oxCAFEBABE” ?

Since Josh asked:

1. I agree with Hani on the whole 5 things meme.

2. I once wrote a templating system called Rectal Gloves, featuring the Rectal Gloves Encapsulation Language, or Rectal-GEL. It became a running theme.

3. I am a complete flaming liberal, and I think nuclear power is a good idea. I think the reactionary hippies make me ill, and given suspension and pebble bed reactor technology, I think the fact that people are still so violently opposed to nuclear power is heinously short sighted. And the people around Yucca Mountain can just deal with it.

4. In one of those classic southern ways, I am related to nearly everyone in Trigg County Kentucky.

5. I don’t forward meatloaf. Ever.

Java needs to start over with a modern media library to stay relevant in multimedia, and possibly in desktop applications as a whole. But what’s needed and who’s going to pay for it? This is Part III.

Here are my top ten predictions for Java in 2007…

Java Server Faces (JSF) has been the right product at the wrong time for a while now. What will be its fate in 2007? Will it possibly be a leader and a technology of choice for client side development?

JSF came at a time when JSP and similar technologies were popular among web application developers. JSF tried to bring the learnings from desktop client UI development to the web. It initiated the possibility of creation of reusable widgets and controls. It provided a sophisticated event model and provided effective management of the round-trip request response cycle.

However, JSF for a while was merely a framework. As implementations and interpretations emerged, the world had moved miles ahead and AJAX had conquered the web2.0 client UI space. Then came the paradigm that AJAX with JSF was not only possible but also a best practice and a way to get the best of both worlds - AJAX and Java together. While many Java developers adopted this paradigm and the followers are growing, its current form with AJAX does appear like a strategy in hindsight and an afterthought.

Some frameworks like JBoss Seam and Apache Shale have provided the missing pieces in the JSF puzzle and commercial vendors have come up with multiple implementations and IDE support. However, the Java camp still looks a little confused about the future of the UI technology. I am positive many people would comment aggressively against this remark and many may even try and justify the contrary, but please remember that this is only my opinion and I am an ardent Java fan and I do believe what I am saying here. I would be happy to hear convincing arguments that disprove me.

So far whatever I have said it pretty much the past, but what about the future. What would JSF be like in 2007 or will there be a new J* UI technology that would replace it or will Java Applets reincarnates flourish or will we keep guessing about it all year long?

Happy New Year!