What "Open Source Java" (should) really mean
I just saw the live webcast for JavaOne's General Session on the future of Java, and I must say I'm a little saddened by it. I never thought I'd ever hear the words "Visual Basic for Java" mentioned anywhere, even less so in such an important event as it is JavaOne. In my very personal opinion, the fact that Sun is even considering letting VB programmers come near a java-based application means that Sun feels it's losing the battle against Microsoft, which I don't think is the case. I'm still in shock over the news.
Another part of the Session talked about how Sun is planing to 'Open Source' Java. They mention (of course) that most of Java is Open Source already, with big projects like Glassfish (Sun's new version of the JEE Application Server that previously was closed source) and even the next version of the jvm code (which is available through a Java Research License which, although not exactly OSS, at least it lets people contribute back to the development of Java). In fact, I would say that right now there's hardly a Java-related product from Sun that you can't find the source code under one of Sun's licenses.
So, what does the community really want when they cry 'Open Source Java'? This is a difficult question (even for Sun, it's my guess), since Java really applies to several things. We really have to divide the Java universe in its different components:
So, what does "open source Java" really means to me? Well, it's really simple, although unlikely to happen anytime soon. Open Source Java would mean opening up the Language specification improvement/maintenance process, and allowing a separate body decide where a Java trademark can be applied. Basically, establish a separate organization (let's call it "The Java Foundation") that takes control over anything Java related, and establishes a Member Board of Directors composed of the different leaders in the Java industry, not just Sun. In short, something very similar to what IBM did with Eclipse, or what AOL did with Mozilla (both very successful community projects, I might add).
Establishing a non-profit corporation that takes the ownership role of Java, ensuring that everything moves forward and that any trademark is properly licensed is, in my opinion, the best long-term solution for Java as a whole, even if it wouldn't mean anything good for Sun. As a separate entity from Sun, Java would be even more successful, since it could really focus on the community as a whole, instead of only focusing in Sun's (and Sun's shareholders) interests.
Do I see The Java Foundation created anytime soon? Not likely. Sun is still too embeded with Java to make it happen. I'm afraid that "VB for Java" isn't the last flop we'll have to endure for our beloved Java.
Another part of the Session talked about how Sun is planing to 'Open Source' Java. They mention (of course) that most of Java is Open Source already, with big projects like Glassfish (Sun's new version of the JEE Application Server that previously was closed source) and even the next version of the jvm code (which is available through a Java Research License which, although not exactly OSS, at least it lets people contribute back to the development of Java). In fact, I would say that right now there's hardly a Java-related product from Sun that you can't find the source code under one of Sun's licenses.
So, what does the community really want when they cry 'Open Source Java'? This is a difficult question (even for Sun, it's my guess), since Java really applies to several things. We really have to divide the Java universe in its different components:
- Java The Language Specification
- Java the Virtual Machine Specification
- Java the Standards (in all its incarnations, J2ME, JSE and JEE, and all the related libraries)
- Java the Products (the actual JDK/JRE applications, the Application Servers, etc)
- Java The Trademarks
So, what does "open source Java" really means to me? Well, it's really simple, although unlikely to happen anytime soon. Open Source Java would mean opening up the Language specification improvement/maintenance process, and allowing a separate body decide where a Java trademark can be applied. Basically, establish a separate organization (let's call it "The Java Foundation") that takes control over anything Java related, and establishes a Member Board of Directors composed of the different leaders in the Java industry, not just Sun. In short, something very similar to what IBM did with Eclipse, or what AOL did with Mozilla (both very successful community projects, I might add).
Establishing a non-profit corporation that takes the ownership role of Java, ensuring that everything moves forward and that any trademark is properly licensed is, in my opinion, the best long-term solution for Java as a whole, even if it wouldn't mean anything good for Sun. As a separate entity from Sun, Java would be even more successful, since it could really focus on the community as a whole, instead of only focusing in Sun's (and Sun's shareholders) interests.
Do I see The Java Foundation created anytime soon? Not likely. Sun is still too embeded with Java to make it happen. I'm afraid that "VB for Java" isn't the last flop we'll have to endure for our beloved Java.
WSAD doesn't suck so much after all
The last couple of weeks have been very interesting, as I was in the last stages of a project at work. I no longer hate WSAD (Websphere Studio Application Developer) so much. I still find a lot of missing features from the latest Eclipse releases (WSAD is based on Eclipse 2.x), but I found the integration with Websphere to be very nice, and developing EJBs is almost easy.
However, the more I use EJBs, the less I like them. After using Spring to create POJO-like services, EJBs feel too cumbersome, not to mention that we mostly do Stateless Session Beans and never even touch Entity Beans, as they impact performance too much. So, there's really not much sense in using EJBs.
One of the main things I don't like about EJBs is that they're not easy to test. With Spring, I could easilly do testing, and not only unit testing but also Integration testing, using Spring's AbstractTransactionalDataSourceSpringContextTests, which allows me to insert and update the database and rollback those changes afterwards, so the db isn't affected. With EJBs, so far I've only found Cactus, and I still feel a little vague on how to exactly use it, since EJBs are required to run inside an Appserver.
Anyway, I was able to finish the project, and WSAD helped.
However, the more I use EJBs, the less I like them. After using Spring to create POJO-like services, EJBs feel too cumbersome, not to mention that we mostly do Stateless Session Beans and never even touch Entity Beans, as they impact performance too much. So, there's really not much sense in using EJBs.
One of the main things I don't like about EJBs is that they're not easy to test. With Spring, I could easilly do testing, and not only unit testing but also Integration testing, using Spring's AbstractTransactionalDataSourceSpringContextTests, which allows me to insert and update the database and rollback those changes afterwards, so the db isn't affected. With EJBs, so far I've only found Cactus, and I still feel a little vague on how to exactly use it, since EJBs are required to run inside an Appserver.
Anyway, I was able to finish the project, and WSAD helped.
Comparing Web Frameworks: RIFE
Well, it seems that the series of articles comparing all the different frameworks using Simon's initial set of requirements is expanding. This time, Geert Bevin, the creator of RIFE, has done the same thing, using his own framework.
I've always found RIFE very interesting, but a little daunting for new users. It uses a lot of cool concepts, like web continuations, blueprints, constrained meta data, etc., but if you are starting at server-side development using Java, or if you come from a much simpler framework like Struts, then you might find all of this just a little bit too much.
Also, it seems that there are at least 3 ways to accomplish the same task for many tasks that you want to do. This says wonders about the flexibility of the framework, but if you only want to 'get it done', you will probably stall with RIFE, trying to figure out which one of the options is the best for you; and then, after selecting one, you might start thinking that the other ones might have been better.
I'm sure that the amount of work Geert has put into his framework is making RIFE very flexible. However, I would still choose Wicket over RIFE, as Wicket provides a simpler entry point, in my opinion. I guess the real issue is how does each framework handle more complex requirements, though.
I've always found RIFE very interesting, but a little daunting for new users. It uses a lot of cool concepts, like web continuations, blueprints, constrained meta data, etc., but if you are starting at server-side development using Java, or if you come from a much simpler framework like Struts, then you might find all of this just a little bit too much.
Also, it seems that there are at least 3 ways to accomplish the same task for many tasks that you want to do. This says wonders about the flexibility of the framework, but if you only want to 'get it done', you will probably stall with RIFE, trying to figure out which one of the options is the best for you; and then, after selecting one, you might start thinking that the other ones might have been better.
I'm sure that the amount of work Geert has put into his framework is making RIFE very flexible. However, I would still choose Wicket over RIFE, as Wicket provides a simpler entry point, in my opinion. I guess the real issue is how does each framework handle more complex requirements, though.
Categories : Web