Read part two.
Last year, there was a lot about the enterprise. This year has been more focused on the consumer, or I guess we should say, people. But when we look at the consumer technologies, you need to have enterprise things on the backend that are supporting all of these applications. We do have the announcement on the preview of Open ESB, which we are going to be rolling into our JavaCAPS offering in the next nine to 12 months. There's enterprise work going on with the GlassFish Community and GlassFish v3, making it much more modular. With the core GlassFish kernel you can deploy things, whether it's EJBs or JRuby or Web applications. Some people perceive an application server being this behemoth, but this much more modular architecture provides what you need, and you don't have to incur overhead by having the entire container deployed. Regarding Java SE, what we're hearing from some people is they like it so much, it might be better for SOA development than Java EE. As you're adding this functionality to Java SE, are you considering that Java SE might be a better fit for SOA?
With what we've done with Java SE and even what I've just described with GlassFish, making pieces of EE optional, it's modular so if you don't need to use modules, they don't have to be there. It's entirely possible that you would do Ruby development so you have a GlassFish core with JRuby. You're not using Java EE. If that's what developers are looking to do, there's a place for doing that. Java EE has a very significant place and will continue to be used, but we fully recognized that Java EE isn't the solution to every problem. So we're doing things with our products to reflect that. If Java EE becomes modularized, is it still something that we think of as a unified enterprise platform? Or have we taken a step where we're talking about various pieces of functionality, and whether it's technically EE or SE or GlassFish is largely immaterial?
It's somewhat immaterial. Really what it comes down to is what enterprises are doing is changing. They're looking at deploying familiar technologies in different ways. So being adaptable to that is something that's needed. There are plenty of people out there using JBoss and other app servers, how do you continue to do the cool things you do with GlassFish and NetBeans yet not box out people who didn't make those choices for their app server and IDE?
That's a fair question. One aspect of it is that everything we do, we attempt to do with standards. We may be providing an implementation of a standard that can be implemented and supported by any number of tools, servers, etc. We see that there's adoption of things like Java EE 5. There are other app server vendors that are adopting the Web services stack that we built as part of our Project Tango with Microsoft. The other thing is that we have support for JBoss in our tooling. We support Tomcat as well in our tooling. So with our server-side technology as well as our tooling, we certainly are open.
With JavaFX Script, some of the work that been done there actually has Eclipse plug-ins. Are we going to provide Eclipse plug-ins for everything we do? Probably not. But we will if it's something that provides value because it allows us to get to developers who are working with Eclipse. Plus we believe NetBeans itself has progressed significantly. We think it's competitive in some places, superior in others. There's still work left to do. But I think the competition is good. You can look at some things like the Matisse GUI Builder, which was built as part of NetBeans, and there's some folks who have ported that to Eclipse. I think there's some bi-directional work going on there and it's ultimately for the benefit of the developer.
I can speak to that a little. I haven't been directly involved with the latest activity, but I think one of the primary things JavaFX does is in the past you could say you could build any kind of GUI with Java and that was correct. But the issue was the ease with which you could do it, and the expertise needed. What JavaFX Script does is greatly simplify going about building rich GUI applications. It makes the development of rich GUI applications significantly easier. Certainly there are alternatives, and I don't think the alternatives are going to go away. But there are advantages to using and leveraging the Java platform. Part of the larger JavaFX story is that this is something you will be able to use for development on any kind of device. It's not something where you're going to use Adobe for desktops and a different code base for mobile devices. Because Java is portable?
You've probably heard people talk about Moore's Law. There's greater and greater power with the mobile devices. We can effectively be running Java on these mobile devices, so JavaFX Script provides the way to truly do the write-once-run-anywhere development, which I think is a significant advantage over some of the other technologies.
In part two of this interview tomorrow, Schmidt talks about the continuing progress with integrating the former SeeBeyond technology into JavaCAPS, the future of Java Business Integration (JBI), the continuing response to criticism of Java EE 5 and work being done on the nascent Java EE 6.