ERIC BRUNO'S BLOG

Java: The Daily Grind.

October 2007

Google continues to hint at plans to disrupt the mobile industry in some way with talk of spectrum bid.

Google recently discussed the possibility of bidding billions of dollars for a wireless spectrum that’s going for auction in 2008. What does this mean to Google’s deals with wireless carriers? Not necessarily much, yet, according to Google’s Larry Page.

Page reiterated that there is no need for Google to get into the wireless space on its own, but he did say that Google wants to continue to improve open access to the web for all users, mobile or not. Buying a wireless spectrum while making deals with more wireless carriers gives Google a “plan B” if carriers cannot meet their demands for free and open access to information. Therefore, while the Google Phone thus far may not seem to be a disruptive technology in the hardware sense, its affect on the wireless industry’s business models will be.

All of the hype surrounding the mythical Google Phone will only help fuel demand for it, which is good for mobile Java application developers, if the phone includes Java. And while Google’s plans for free and open access to information are admirable, remember that their goal is the same as the wireless carriers out there: profits.

Posted by Eric Bruno at 06:36 AM  Permalink |

I recently spoke with Rod Johnson of Interface21, the maintainer of Spring and related software, about the future of Java EE.

What I learned about Java EE 6, and Interface21’s involvement, was very interesting. For instance, one of the largest and most welcome changes is the notion of profiles for Java EE. A profile is a subset of technology components that are targeted for a specific use, and this is also how Java ME breaks up its APIs so that applications can use only portions of it.

For instance, assume you’re deploying a web application built purely out of JSP, and maybe a standalone Servlet or two. You need a web server with a Servlet container. You can choose Tomcat, but if you’ve already invested in WebLogic, for instance, you may prefer to use that. However, WebLogic includes a whole lot more than support for a site built with JSP; it has an EJB container, a JMS provider, and everything else the Java EE specification demands. The problem is that with each deployment, you’re paying for a whole lot more than you’re using, and you have the bloat that comes along with it.

Java EE 6 profiles attempt to solve this problem. One proposed profile is a Web Profile, which is aimed at applications like this example. Other possible profiles are a Web Service Profile, an Enterprise Profile (includes EJBs), and a Real-time Profile. According to Rod, profiles truly redefine what an application server is. Be sure you’re ready for this change.

Another radical change with Java EE 6 is its extensibility. There will be deep support for users to extend the functionality of the application server in standard ways. This is one area that the Spring Framework will play a key role. Many users struggle at first with how to integrate the traditional Java EE features with the goodies that Spring offers. Changes in the next version of Java EE will not only make this decision more straightforward, but will provide standard support for it as well.

In fact, Rod mentioned that Spring itself may become part of, if not key to, a new Java EE profile all its own. I asked Rod what his goals are as a member of the JCP, and expert group for JSR 316. He stated that he wants to see the community benefit from a simpler Java EE model that gives them more choice in how the build and deploy their enterprise Java applications, regardless of whether that includes the Spring framework or not. Good answer.

The specification, and the fact that Sun is leading it, is not without controversy, however (see http://www.javalobby.org/java/forums/t99039.html). For instance, Apache took a hard-line stance and did not approve the specification, solely because they feel Sun is in violation of the Java Specification Participation Agreement (JSPA) in general – not necessarily regarding this specification. That’s a cheap shot in my opinion. I understand Apache’s view of Sun these days, but I don’t think it should translate into a vote on an unrelated JSR. That vote should be based on technical merits.

What’s your opinion on Java EE 6, the Sun / Apache situation, and the vote? Respond to this blog and let us know.

Happy coding,
EJB

Posted by Eric Bruno at 08:03 AM  Permalink |

More information trickles in about Google's rumored mobile phone and mobile platform (codenamed "Switch").

In 2005, Google acquired a company named Android, a small mobile software company co-founded by Andy Rubin of Danger., Inc (www.danger.com). Danger created the T-Mobile Sidekick, and offers the Danger Platform, which is an integrated mobile Internet solution that delivers voice, Internet, and messaging capabilities through mobile devices.

Andy now works in Mountain View, California, at Google's headquarters, and coordinates efforts with a team in Boston led by Android's other co-founder, Rich Miner. Together, these teams are rumored to be developing a mobile phone that uses wireless technology to deliver free mobile service. Additionally, Google is said to be working on a suite of mobile applications with revolutionary interfaces to rival desktop application suites offered by companies such as Microsoft.

Many in the industry are wondering how Google will fare in the world of hardware devices, which is currently not an area it competes in. Specifically, many are wondering how the Google Phone will compete with the iPhone. Indeed, it doesn't seem to be as disruptive a technology as the iPhone has been. However, look carefully at the rumors regarding the mobile suite of applications. It seems that Google is positioning the Google Phone to be more of a competitor with Microsoft than it is with Apple, Nokia, AT&T, or any other wireless device manufacturers or carriers.

I haven't heard anything definitive regarding what platform the Google Phone will be built on. However, Google's recent lobbying indicates that they intend to bring an open-platform approach to mobile computing, similar to desktop computing, free from lock-in and control by a single vendor or carrier. Therefore, I would guess that the platform would be built on Linux, with Java used for much of the mobile application suite. Currently, Java is used for some versions of Google's mobile map software. This gives Google the tools it needs to get the platform working on a wide range of devices with limited effort.

It will get interesting as facts and details begin to emerge regarding the Google Phone. See this NYTimes article for details so far. The name alone will need to be settled upon, as the moniker GPhone itself seems to be taken (see gphone.sourceforge.net and www.gphone.com).

What's your take on the Google Phone rumors? Are you ready for an open platform with free or low-cost wireless calls at the expense of possible advertisements? Respond here an let us know.

-EJB

Posted by Eric Bruno at 10:07 AM  Permalink |

For the past year, I’ve started each day with an Apple and Java. I’m not talking about breakfast - I’ve been working with Java on my MacBook.

Soon after I bought my MacBook, I downloaded and installed the Java SE 6 pre-release build, which hasn’t progressed in quite a while. In fact, I can’t seem to find it on Apple’s Developer Connection site for Java (http://developer.apple.com/java/) anymore. Although it’s in a pre-release state, it has worked for me without an issue, so I’ve been happy with it. I run Eclipse, NetBeans, Tomcat, MySQL, ServiceMix, and lots of other development tools and open-source components without issue.

However, many have criticized Apple’s lack of support for Java on the Mac; specifically, its lack of moving to Java SE 6 in release form in time for Leopard’s release. But exactly whose responsibility is it to release a Java binary for a particular platform? Some consider this to be Sun’s job.

Personally, I find the situation a bit ironic. After all, there have been many in the community who called for Sun to move Java to an open-source model for a long time. Sun did just that in 2006/2007. Now, many of the same developers are complaining that a commercial entity (Sun, Apple) hasn’t built a proprietary binary for the Mac OS X platform. Something’s not right here. After all, now that we have the open-source Java, OpenJDK (http://openjdk.java.net/), project, why hasn’t the community ported it to the Mac?

The answer, honestly, is that all of the components needed to do this haven’t been available until recently, many still aren’t, and what version is the OpenJDK exactly? Regardless, it’s rumored that Apple is actively working to port the OpenJDK project to Leopard, to be available sometime in 2008. I’m just surprised that it hasn’t been done already, as many Sun employees use Macs themselves. However, as David Herron blogged about a few months ago (http://weblogs.java.net/blog/robogeek/archive/2007/05/some_openjdk_an.html), there always seems to be complicated forces at work, such as the body of “encumbered binary code” that is only released in binary form because Sun doesn’t own the rights to the source code.

The end result is a chicken-and-egg situation: you can’t create a Mac OS X binary from the OpenJDK project because it contains binaries that aren’t OS X compatible. Hence, the time delay; Apple is more than likely working with related parties to gain the rights to build these binaries themselves without releasing the source so as to not violate license terms. The GPL alone is tricky; tack onto this the license agreements for the close-source pieces.

No matter how you look at it, my opinion is that Apple is not the bad guy here. Those that compare this situation to what Microsoft attempted to do in the ‘90s are being unfair. Microsoft was successfully sued by Sun for violating license agreements in order to serve their own purpose: splinter the Java language and the developer community and transform it into a Windows-centric language. Apple isn’t doing this. It just seems to have not had the resources to dedicate to advancing another company’s (Sun’s) intellectual property.

Now, I’ve used Windows, many distributions of Linux, Solaris, and Mac OS X, and I have to say that the Mac makes one heck of a desktop environment for Java developers. It would be nice if Sun, Apple, and the community could work together to assemble the coolest version of Java ever on what is arguably the coolest desktop OS available today: Mac OS X.

Happy coding!
EJB

Posted by Eric Bruno at 11:46 PM  Permalink |

ServiceMix, the underpinnings of Iona’s FUSE ESB/SOA offering, has been promoted to a top-level Apache project.

Iona FUSE, the software suite that was part of the LogicBlaze acquisition Iona made this year, is a complete open-source messaging and service-oriented stack of software with the backing of a commercial corporation behind it. The suite is based on multiple Apache projects:

• Apache ActiveMQ: an open-source Java Message Systems (JMS) provider
• Apache ServiceMix: an open-source enterprise service bus (ESB)
• Apache Camel: a rule-based routing and mediation engine
• Apache CXS: a services framework to build standard-based (XML/HTTP, SOAP, JAX-WS, REST, CORBA) services.

The updates to FUSE announced on September 25th include enhancements across the entire suite, including FUSE ESB, FUSE Message Broker, FUSE Services Framework and FUSE Mediation Router. The releases include significant performance and feature improvements and tighter integration between the FUSE ESB and all components of the product family.

Processes implemented on FUSE ESB can now also be managed by lightweight POJOs integrated with FUSE Mediation Router. Configuration is handled with standard developer tools based on familiar Enterprise Integration Patterns. FUSE Message Broker now includes a new model for message persistence, a new message store, and new features to optimize performance in mission critical deployments.

The model that Iona has chosen is similar to those used by other successful open-source software vendors: provide the software in open-source form free to the community, and provide support, services, and training to corporations who choose to build solutions on them. This is similar to how Interface21 works with Spring, MySQL works with its community and commercial databases, and how Sun is working to move its entire software base to the open-source world. There are slight differences in their approach, but in general this strategy seems to work well for all parties involved.

What’s your opinion on the commercial packaging and backing of open-source software?

Happy coding,
EJB

Posted by Eric Bruno at 10:03 AM  Permalink |