Open-Sourcing Java: because...

viernes julio 09, 2004 | General | Permalink | Comentarios [6]

First of all I would like to thank everybody that posted some comments to my previous questions about open-sourcing Java. Now that I have different points of view I can comment on them. Of course these are my comments, not Sun's ;-) There we go: Fast, fast, fast Some comments state that Sun is slow solving issues ("you have to wait Sun to take your submission", "Sun react too slow to big issues", etc.) Well, I don't know what slow is. I mean, that's quite a subjective question. Lots of people think Debian is slow, for instance. I disagree: Debian is released whenever Debian is ready. Nor sooner nor later. Of course if you want to deliver good quality software you need some time. I don't mean that Good Software Takes Ten Years. Get Used To it, but you need some time. Mono, for instance, has taken some years to build 1.0. And it seems they're not up yet with Microsoft .NOT stuff (well, that's a moving target, so it's difficult). Lots of open-source people get used to the "release-often" approach. I don't mean it's a bad method, it's just a way to do things. That's ok whenever your users are beta testers: you can detect bugs easily. Furthermore, most users get used to have to keep track manually of dependencies, I mean: lots of open-source projects depend on other open-source projects which are in turn released often, so whenever you want to upgrade one you have to upgrade different others, and this is a nightmare of upgrades. I wouldn't like that to happen with Java. It's a pain in the neck. I just prefer to have a new Java version whenever the version is ready. And if it has any bugs in it I'd like them to be publicly available, say in a web page or something, so I can go and see if there's a problem there. And I'd like them to be solved in the next Java release. In such a big thing as Java is (with lots of libraries there) is difficult to solve all bugs. There's no software without bugs. All I want is to be able to vote for bugs so the more important to me are solved. So people can concentrate in those bugs annoying me. And that's exactly what's happening with Java. So I don't see a reason to change it. JCP is open to open source Some other comments state that you have to belong to a Big Company to participate in the Java Community Process. I know that the Apache Foundation and JBoss, Inc. are big companies, but they are part of the Open Source Movement, so I assume the Open Source Movement is participating in the JCP. So JCP is open to open source. But it's open as well to individuals. To experts. All that is required is to do some work at the JCP. I mean, if you become an expert I assume you are supposed to do some real work, not just be there hanging around at your spare time. (And this is just my opinion: I'm not an expert at the moment, mainly because I cannot do any more real work at all ;-) ). Saving Sun's money Some of the comments state that open sourcing Java is a money-saving technique for Sun ("this will cost Sun a lot"). Now I understand the reason why IBM is pushing to open-source Java !! ( ;-) ) Now, seriously, I think Sun people is smart enough to decide on how to save money by themselves. No help from IBM needed at the moment. They could start by reducing the funds for R&D to a minimum, to the same level as other companies. But then we wouldn't have HotSpot, those nice featured, high-technology garbage collectors, not even a Real Time Java, nor a sound, secure, operating system. And that wouldn't be good for customers, nor for Java users, so it's a Bad Idea: I still want Sun to deliver free hardware and free StarOffice licenses to the Open Source and Academic Communities. I still want Sun to invest huge amounts of money to build the Best Of The World garbage collection technology I can use in my laptop. Making Sun save money is, indeed, a Bad Idea. Open-Sourcing Java will reduce the bugs in J2EE "They did a lot of work on the J2EE standard, and EJB's ended up being a big pain in everyone's butt." Well, J2EE and EJBs have nothing to do with open-sourcing Java. Both J2EE and EJBs are being worked on at the Java Community Process, which is (as far as I know) already open to everybody. Distributing the JDK with Linux Someone mentions that the JDK cannot be installed by default in a Linux distribution. Well, this is a major problem to me too. I would like it to be installed everywhere. For free. With no licensing restrictions. I also think Sun should fix that. Kaffe and GnuClasspath I have to agree that Sun should make things easiers for these groups to verify their implementations. In fact it would be great if someone at Sun could collaborate with them in their implementations. That's something Sun should consider, I think. Conclusion I still cannot see a real reason why Java should be open-sourced. In fact I think there's no real reason to open-source Java. Even reading Eric S. Raymond's Open Letter I can see no real reason at all. "But Sun has done other things that make us wonder if the vision and courage to choose the open-source path are really there.", Eric says. Well, I do think Sun has vision and courage to go through the open-source path, mainly because it is already in the open-source path. And this vision has been Sun's vision for quite a long time now. We're not new to Open Source. We've open-sourced lots of things. We're open-sourcing Solaris. We're open-sourcing Java3D. We're open-sourcing Looking Glass. We're not new to Open Source. " if you're serious about preparing Sun for the future we can all see coming in which code secrecy and proprietary lock-in will no longer be viable strategies ", Eric says. Lock-in you say? Does JDBC lock you in in any proprietary database? Does J2EE lock you in any proprietary application server? Does Java lock you in any proprietary operating system? There's a misunderstanding here somewhere. We're about open systems and open source, not the other way round. And we have always been, and, for sure, we will ever be. Jean-Christophe Collet's blog expresses it quite well: Sun is all about open-source and open-systems, Sun is an open-source ally. It's *the* open-source ally. Sun will always be an open-source friend. And that's one of the reasons why I like this company!!

Open Sourcing Java, why?

lunes julio 05, 2004 | General | Permalink | Comentarios [9]

Open Sourcing Java seems to be a hot topic nowadays. Everybody wants Java to be Open Source. Although I am not an expert on the area I would like to express my opinion. After all that's the reason why I'm blogging. One Java to rule them all Go take a look at how many different SmallTalk implementations are out there. Quite a few, right? Go take a look at how many different Scheme implementations are out there. Quite a few, right? I like Scheme a lot. It's my favourite functional programming language. Simple, efficient, straight to the point. There're lots of implementation dependencies though. Mainly with libraries (although SLIB helps a lot). Open source people have built different implementations of libraries and there're no standards for those. Building a GUI with Scheme, for instance, is different for each implementation. That's a pain in the neck for Scheme. (If you wonder, my preferred Scheme implementation is SISC, a Java based one that can be found here.). I wouldn't like to have Gnu-Java, IBM-Java, Microsoft-Java (they tried it hard, though) and the like around. It would be frustrating to generate Java code that is not portable between implementations. Filling in code with "if"'s for each implementation, going around implementation specific bugs. I don't like that. I don't think Java users want that either. Nor Sun customers. Nor IBM customers. Java should be controlled by someone. Sun has done it fairly well during this years. I can't think of a reason why they shouldn't keep on doing that. Being controlled does not mean people can't build implementations of it. It just means that implementations are controlled whenever they claim to be Java. IBM-Java JDK, for instance, is a perfectly valid Java implementation. So is Blackdown's. Kaffe has little gotchas, so I think (just think) it's not fully Java compliant. To summarize: I think it's better to have a controlled Java standard. That's good for everyone. Open Source I am not an expert on Software Licenses. I know a little bit about GPL and LGPL, and a little bit about Sun Community Source License (SCSL). With SCSL I think you can: - Download Java sources and modify them. - Send enhancements and error corrections back to Sun, so they can be taken into account in future releases Were you using GPL you'd be on the same situation, I think. With the Java Community Process you can: - Ask for new features in the Java language. - Agree with the Java community and discuss with them about these features and enhancements. So, what is the problem? Is it that the name is "Sun Community Source License" and not "Apache License"? Is it that it's Sun controlling that there're no different implementations instead of any other entity? Which entity should that be, and why? Is it that different companies have to agree with features and standards with the JCP? Who is that bad for? I try to keep being open-minded, but I just can't understand why anybody else other than Sun should keep Java implementations compatible. Sun has been fair with the open source community for quite a long time. I can export my filesystems through the network thanks to Sun, for free; I can make presentations easily in Linux with Open Office, for free; I can build Java applications on Linux easily with NetBeans, for free; I am safe using Java because it's compatible between Windows, Linux and many other OSes. I will try keeping to understand why an open source license other than SCSL is better for Java. At the moment I just can't understand it. Too limited I am, I acknowledge.

SWT, JGoodies and Synth: My preferred desktop sessions at JavaOne 2004

domingo julio 04, 2004 | Java Swing | Permalink |

I attended as many desktop-related sessions at JavaOne as I could. All of them quite interesting. The sessions I liked most are (no special order here): Steve Northover's Inside SWT was indeed good. He is a very good presenter and the whole session was just fun. I finally could understand the whole idea behind SWT: performance and native look. I still don't like SWT, though. How to Build a Cool JavaTM Foundation Classes ("J.F.C./Swing") Technology Application by Karsten Lentzsch, of JGoodies world fame. The session was just impressive, lots of fun in the audience whenever Karsten said "it sucks" :-D. Well, he's not a native english speaker (good english tough) and was suffering from jet-lag, so I assume it's quite understandable (and it was lots of fun). Examining JavaTM Foundation Classes ("J.F.C./Swing") Technology New Looks and Feels: Ocean and Synth by Scott Violet (Swing Engineer) was quite interesting too: he presented Ocean and Synth. Steve's session on SWT clearly stated what all SWT is about: performance and native look. Maintainability was not an issue for them (well, they are supporting different code for each OS, that's a huge task I think). In fact SWT achieves both goals. So no doubt: SWT has been successful in its goals. I'll blog on Swing and SWT one of these days. Karsten's session was impressive. He presented examples of JGoodies Looks and JGoodies Forms and even the validation stuff (you can find these at javadesktop.org). I once built my own Look and Feel with antialiasing rendering of fonts on Linux, but listening to Karsten I understood that building a good Look and Feel is much more complex than one may think initially. The Looks L&F takes care of screen resolution, for instance, and that's something I've never thought of while Swing-ing. I pursued some of the Netbeans people around too. Netbeans 4.0 just rocks. You can drag and drop windows around. It starts-up quite fast as well (they had a session on startup performance). I would like to start developing on top of Netbeans but documentation is still an issue. I will try to go fetch some good tutorials as soon as I have some spare time. If you know about any good starting points just let me know. Scott Violet's session on Ocean and Synth was quite clarifying too. Ocean is just an improvement of Metal, to make it look a little more modern while keeping pixel-size backwards compatibility with Metal (and performance too). So it's not that spectacular to me. Synth is much more promising: you can build L&Fs quickly by just choosing the images you use for rendering widgets or by providing a single class (SynthPainter) to centralize the painting of all widgets. That's much more flexible than Ocean and Metal, and I see that as a step forward in improving Swing. It seems there're still performance issues for Synth (such as advanced image caching), but these will be on time for the final JDK 5.0. Cool.