techno.blog("Dion")

By now you have probably read about the critical Java vulnerability and how easy it is to take over a machine from a web page via a Java applet.

Apparently, Sun fixed it fairly quickly, but even then some people say their fix was too specific and thus there are still problems. Apple on the other hand, were not diligent and are still yet to provide a fix. Ouch.

Painful news as JavaOne approaches and Sun tries to push JavaFX. I was trying to think of a Java applet that I have used (knowingly) in the recent past, and I think the only candidate is the Facebook photo uploader.

I have been watching some research for a talk on JavaFX and I am really torn. In theory, the Java platform is phenomenal and should be a great choice for doing this kind of development. The scene graph work in JavaFX is very nicely done, but the implementation seems to be a touch off in much of what I have seen. Scrolling causing the applet to go blank? Browser crashes? Ouch. But, JavaFX is new, and has a chance to get better. Their problem is that they are squeezed from both sides. The browser platform itself is accelerating quickly, and it has the advantage of being native. Once you go to plugin land you are competing with Flash with its large share and proven ability.

Getting webby

I find myself wanting to get more and more webby. This is why I was excited to work with the Jetpack project that we just launched today at Mozilla Labs. Being able to extend the browser using Web technology itself is going to open the door for more playing. People have created 7000 addons for Firefox alone, but as someone who has done a touch of XUL, I am happy to stay in my familiar territory of HTML, CSS, JS. Jetpack has just been born, and is incredibly early stage, but I can’t wait to see it grow and get the APIs that people want in a secure extensible model.

You will see a lot of Bespin in there too. Below is a screencast where I create a Jetpack feature on the fly (no reloads!) using Bespin, and once you install Jetpack it embeds the puppy into the tutorial and the developer area too. Much more than can be done though!

There has been a recent shift in thought, where people believe that we are in a phase in which the consumer space is pushing innovation into the Enterprise space. The general thought process is that the Web has made things very easy and inexpensive to play, and has taken the lead in productivity which we now see pushing the behind the firewall types.

We can look back a little and see how J2EE was pushing the Java stack forward not too long ago, even if the EJB of then may not have been the right road to go down. Ignoring EJB, there were a ton of other great technologies that did actually simplify the life of the Enterprise. Some of these folks were trying to deal with CORBA. Others were used to integrating through messaging and may not have had quite the same pain. EJB was “simple” compared to the myriad of CORBA specs and half implementations though.

Jump forward a few years and we see EJB 3 having the main message as “simplicity”, and many other Java specs were doing the same. The worm had turned a little.

Of course, if you look back at history you see a ton of other stories. If we think back to how IBM was progressing the computer world from the Enterprise inwards, compared to something like the Sinclair Spectrum.

There is always innovation on both ends, and hopefully the “good stuff” that happens to transcends the needs of the consumer or the enterprise pops out to the other side.

A hot topic right now is “Enterprise Mashups”. A lot of large shops have seen how simple it is for the Web 2.0 folk to mash together Web systems to create a new system that meets their unique needs. As they watch this, they look at the massive integration projects they have going on, and how painful and expensive they are. Here we see the constant battle between the IT group and the business groups that want to just get stuff done. Access was so popular as people in the business units could hack on it just enough to get something done, without having to go to the IT department to get an app developed that would take forever. Internal mashups have the promise to do the same.

Of course, it isn’t that easy. A little Google Map + Data mashup is one thing. But, behind the firewall you have to deal with auditing, authorization, authentication, and all of that Enterprise stuff. There can be a reason why there is complexity.

Why am I blabbing on about this? I had some people talking to me about my recent Sun posting (you know, where they bleed a little) and a common thread was “should Sun stick to the Enterprise?” The thinking here is that Sun makes its money (at list I think so) from large Enterprise customers. The big consumer ra-ra around JavaFX as a Flash/Silverlight competitor makes Sun look like a company that it is not.

If you believe that the route to winning is “do consumer well, and then let it bleed to Enterprise” then you could see why Sun is so desperate to get this working. If you believe that there is room in focusing on the Enterprise customers, and giving them what they need, then you may see JavaFX as a waste.

I don’t quite see it as a waste myself. Chris Oliver just posted Why JavaFX? where he states:

Our goal with JavaFX is to deliver a “media” stack for the Java platform. What does that mean? Well, in simple terms, 5 things: Audio, Video, 2D Graphics, 3D Graphics, Animation

There is value there. If you partake in some of Ben’s vision, then Enterprise software doesn’t have to be grey and boring. In fact, it could even resemble a video game in some situations. So, having this stack is very useful indeed. The problem has been in the details. It has been sold at JavaOne as The Saviour. The big thing that Sun is working on. The thing you should be excited about with Java. In fact, it is some nice features that will enable us to do better things in all software.

As I outlined in my last post, I would just prefer to see a more balanced outlook, and one that showed a focus on other things, especially productivity. Blend this all together to show how the league of Java developers can productively produce compelling, usable software for their end users. There are legions of developers in the Enterprise trenches, at companies with large wallets, that would love to be more productive.

I talked about how I thought Sun was drowning back when Chet Haase left Sun and joined the Flex team at Adobe. It wasn’t that without Chet Sun was screwed, but rather it was a sign of how things were going. The client team lost big players like Scott Violet, and then Chet.

Well, more heavy hitting engineers are leaving. When the CTO of the client division moves on (to Adobe again, no less), we yet again have a reason to wonder what is happening at Sun.

It is ironic that the exodus of talent has happened at the same time as Sun promotes JavaFX at JavaOne. As I asked people “How is JavaOne going for you?” at the end of last week I got a common response “Cool to see everyone, but I don’t get JavaFX.” JavaFX is a mistake in my book. I haven’t met anyone who was truly excited about it, and who didn’t think that Sun could be putting their engineers on better tasks.

When talking about the symbolic “Why <> instead of !=” in JavaFX Script, I was told “JavaFX Script isn’t meant for you, it is meant for designers.” Fair enough, but:

1. What a gratuitous change. Designers somehow feel closer to <> ??
2. Do you realise that you have THOUSAND OF JAVA ENGINEERS at JavaOne that you are talking too? I may have seen one designer.

Shouting about JavaFX is like shooting fish in a barrel, and it is easy for us to sit on the sideline and quarterback Suns demise, but what I find so frustrating is that Sun has a ton of assets. It doesn’t actually HAVE to go this way. Although there isn’t a Steve Jobs to come back and save the day, like Apple did (even if Steve didn’t do it all), Sun could change course.

I personally think it is time for Sun to be humble. Re-engage the Java developers. There are more Java developers than any other platform …. still. The army at JavaOne filters into the keynote ready to be inspired. They don’t want to feel ignored thanks to JavaFX.

Along with your Java army, you also have a fantastic platform that is deployed all over the world. The JVM is phenominal, and could be the platform for much more than Java the language. JRuby is doing great. Scale is promising. Jython. Awesome work, but lets put more into it and take it to the next level. Make the JVM the best platform for dynamic languages as well as static. Don’t through every dynamic feature into the Java language as they will split the community. Instead, keep Java Java, and dynamic folks can jump into JRuby, Groovy, and the myriad of other choices on the JVM.

Although people weren’t head over heals with JavaFX (and its non announcement), I did talk to people who were actually excited about the Java Plugin. Ken Russell is doing a great job, and imagine what they could do if they pushed there. The Web has won. Java could be a great way to push the Web forward. Instead of thinking about the applet as a way to draw rectangles, think of it as an extension mechanism. Using it for our Wii demos was simple. There is much exciting work that could be done here. My old “Ruby in the browser” work is not a lot cleaner with JNLP support, and JRuby builds out a JNLP package ready to rock and roll.

Use your power in the Enterprise. Instead of the current Java EE focus, how about also making a productivity play. Make Java the most productive way to build phenomenal applications. Come out kicking and screaming at next JavaOne saying:

• No CEOs of Sony Ericsson this year
• No Neil Young
• This keynote is about YOU, our developers, and everything we show in the next two hours ships TODAY
• In the next two hours we will show you how excited we are about how you can deliver world class applications on the Java platform.

Get people off their seats. Inspire them. Cull the bleeding and move on. The assets are in place, now it is time for the momentum to change.

NOTE: I talked about some of these issues in the JavaOne Roundup Podcast with @cote of Redmonk.

JavaFXOne kicked off yesterday, and I captured pieces of the keynote which are seen below as separate videos in the custom player. Someone nailed the keynote pretty well when they said “Shouldn’t this have been last years keynote?” Nothing was actually announced here. The only “you can get this today” code drop was for Update 10 which has been out for months!

Update 10 has some cool features though, and the updates to the Java Plugin are key. If Sun spent a tenth of their time on that versus JavaFX they could do great things. Use it as an extension point instead of a paint mechanism!

Well, now off to polish the presentation that Ben and I give at 4pm today. A sneak peak: If you fancy watching a demo that involves the Wii, show up for a bit of fun!

I was excited to see that Apple have released a new version of Java that gives you Java 6 support. This is great timing, since JavaOne is next week.

You may be thinking “great timing”, but for poor fellows like myself, it is a double edged sword. If I install it, will it somehow mess up my demos and cause a good blue screen while on stage? What a tease.

In fact, for one of our demos, Ben and I need to use Windows (had fun with that today :/) because we are using some of the new Update 10 work. The demo next week should be a lot of fun if we can pull it off. It is a little out there!

I look forward to installing the new Apple update, right after our JavaOne talk ;)

I was talking to a friend that does a lot of work in the realm of Open Source Java. He is someone who talks to people high up in the chain, and discussed how a lot of the CIO folks are getting a bit confused with the offerings. They had gotten used to JBoss. And, now they get Spring. But, they keep getting bombarded with more things. Next they had Mule, and Groovy.

Get some of these guys in a discussion about Mule vs. ServiceMix and they froth. Spring did something smart via Spring Integration, but maybe it is time for some consolidation? SpringSource + MuleSource + G2One? SpringyMule?

Even since Ben and I looked at the notes for the first version of Mozilla that supported XMLHttpRequest, which suddenly took the technology from “Some ActiveX for IE” to “Ajax”, I have been interested in hidden technologies that maybe never made it. In those notes for that release we saw no mention of XMLHttpRelease, but technology such as FIXptr was prominently mentioned.

Also, something interesting about Ajax is exactly the fact that the technology was available since 1997, but didn’t make it big until many more Dilbert calendars later.

This points to the fact that there may be some hidden gems in the past that could also be resurrected in the now! As I look back in time, I thought I would talk about any that interest me in some way. Hence, the Web Archeology set of postings. If there is a technology that I am missing, please let me know!

Today I am going to talk about the Java Pluglet API. This technology is part of the Blackwood project at Mozilla, where it was created in 1999 by Igor Kushnirskiy & Akhil Arora.

Let’s walk back to 1999 for a second. Imagine working on Mozilla in a world where you had to futz with a lot of XPCOM and C++ to build things. XUL came about a way to reach out via more Web-y technology to get work done (XML, JavaScript, CSS, etc). In 1999, Java was a sexy language, and everyone was getting ready for fantastic server side Java with great technology like EJB ;)

What if the Java developers could get in on the browser action and develop rich plugins for Mozilla? This is where the Java Pluglet API comes in. It allows you to do just that, mimicking the C++ side of the house:

It was a conscious design decision to have the Pluglet API resemble its C++ counterpart as much as possible, while being able to reflect all of its functionality to Java, so that Plug-in writers will not have to learn yet another API. This concern, in our opinion, outweighed other alternatives which offered a cleaner, more Java-like look. Support for other Plug-in APIs can be easily added by contributing adaptors.

How you register the pluglet is via mime types. You could create application/wicked-cool and when that comes back from the server, Mozilla will say “hmm, I don’t understand this mime type, Pluglet Engine do you?”

At a high level the idea of writing extensions in Java makes total sense to me. It is obviously cross platform, but still low level enough, with a huge library set to get a lot done.

Isn’t this dead?

Probably? Ed Burns did step up to the plate though and reenergized the project recently. As part of the resurrection you can now interface directly between the Java side and JavaScript itself.

If you squint a little, you see an interesting plugin path for the browser. I often say that I would love for Gears to be made using Java instead of C++!

I have seen a number of threads, over the last couple of years, where people claim that “Java is dead” in some fashion or another. You could argue forever on what that actually means. Java the language? Java the platform? You mean EJB? Do you realize how many people are writing Java code?

What I find more interesting, is thinking about how the enterprise folks were sexy for awhile and crossed over to the consumer side.

The cool kids these days are talking about things such as:

• Erlang
• Django
• Neo RIA
• Microformats and DSLs
• iPhone SDKs
• Social APIs

Not so long ago, the same people were hacking away using Java. And not just Java, but enterprise Java! J2EE folk who may have written an EJB or two. Back in the day this was sexy. How the hell did that even happen? It just doesn’t seem right :)

Talking with code is powerful. Miguel posted screenshots of Mono running on the iPhone whereas Sun talked about Java running on it.

I always feel like I would like a reason to get into Mono, but never find one.

Paul Krill reported that Sun has looked at the iPhone SDK and thinks that it can port Java to the iPhone. It will be placed up on AppStore as an application, so I wonder what the user experience will be for apps that actually run Java, especially for the first time on a phone that doesn’t have it installed.

Don’t get me wrong, I want Java on the phone, just like I want full RubyCocoa, PyCocoa, CocoaJS, and any other language that you fancy.

Background Processes

So, the iPhone doesn’t allow background processes:

Only one iPhone application can run at a time, and third-party applications never run in the background. This means that when users switch to another application, answer the phone, or check their email, the application they were using quits.

This makes me worry about Java too. Startup has never been a good point of the JVM. If I flip to a Java app am I going to have to wait for the bugger to startup? Is there going to be a way to load one VM and keep it loaded (doesn’t seem like it).

It seems like this is just a guideline and not a firm issue:

I’m a programmer and I just tried it [using the iPhone SDK] and you can keep your app running in the background in the normal way ApolloIM and iFob do it. I.e. overriding applicationSuspend.

Even more worrying though is this part of the developer agreement:

3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).

Although it has been suggested that this is to stop non AppStore code, it seems to go a lot further than that.

Open source and the iPhone

Also, Mark Pilgrim has written up thoughts on whether iPhone apps can be GPL:

Since all iPhone apps must be distributed through a third-party (Apple’s “App Store”), that would make Apple the “distributor.” Which would mean that Apple — acting as the distributor of GPL-licensed object code — must provide source code or a written offer to provide source code. It’s analogous to a Linux distribution — they distribute binaries of upstream GPL programs, so they need to host the source code as well.