 |
|
|
|
| A Developer's Perspective |
|
 |
Rick Ross is the founder of Javalobby. He is a frequent speaker at Java-related events and a well-known advocate for Java developer interests.. |
|
Harmony: Can Apache create a fully compatible Java?
A few days ago a proposal to create a fully compatible, open source J2SE implementation was submitted to the Apache Software Foundation. The proposal, called "Project Harmony," is broad in scope but plausible in light of other Apache achievements. Project Harmony is supported by a number of leaders with proven history of individual success and ties to organizations that may want to help Harmony succeed. It only takes a few minutes to read the entire proposal, so why not read it now and then come back to finish the rest of this column.
Of course, the initial reactions have been consistent with what you'd probably expect. Some people are saying "hooray!" others are saying "why not just support GNU Classpath and Kaffe?" and still others are decrying the need for any open source J2SE on the grounds that Sun provides all we should require. We've heard all of this before, and with respect to the thoughtfulness many have put into expressing those views, it may be time to end the debate and resolve this issue once and for all. Does the world really want an open source J2SE implementation? Let's just find out!
Javalobby will support Project Harmony, and I urge you to do the same. Harmony has stated a clear goal of full compatibility with Java standards, to be tested by the official Technology Compatibility Kit (TCK) from Sun. Compatibility at this level is the cornerstone of the Java philosophy, so I feel Harmony demonstrates appropriate intentions by committing to TCK compatibility from the outset. One of the most common fears developers have is that an open source J2SE might cause Java to fork, but it would be very hard to fork Java and successfully pass the tens of thousands of compatibility tests in the TCK. By establishing TCK compatibility as a primary goal and focus, Harmony shows that it is neither an attempt to fragment Java standards nor an attempt to divide the Java community. If Harmony ever actually passes all those TCK tests, then it will certainly be a major achievement.
The Harmony FAQ is a helpful document that may address some of your questions and issues about the project. It seems to me that the people behind Harmony are communicating from a positive and productive viewpoint. The FAQ speaks to questions about Kaffe and Classpath, intellectual property protection, architecture, compatibility and project expenses. It is concise and useful, so you may want to give it a quick read to see if it addresses questions you have. Also of interest is this blog entry from Sun's Graham Hamilton, in which Graham responds positively to the spirit of the Apache effort and even indicates that Sun will "probably participate in the project at some level." It's good news to hear someone as highly placed as Graham speaking plainly and reasonably about Sun's view of Harmony. Hopefully the project will succeed in bringing many Java leaders into a broad and successful cooperation.
One question some of you will have is "how do I get involved?" Joining the email discussion list is probably your best initial step. Just send an email to harmony-dev-subscribe@incubator.apache.org, and you'll be tuned in to the most up-to-date source of information about Harmony. As things move forward I am sure there will be many other resources available.
It would be unwise to casually speak about Harmony as if it is already a viable alternative to Sun's Java implementation. We need to view Harmony clearly for what it is today: a project proposal to the Apache Software Foundation. It is by no means a "fait accompli," nor is its outcome certain. In fact, it's not even a foregone conclusion that the Harmony proposal will be accepted by the democratic process within Apache, that's how uncertain it really is! There's a ton of work to be done before "Hello, world" could ever run successfully on a Harmony foundation, so let's not get the cart before the horse.There's not a line of code yet, nothing you can run. Be careful and temper your enthusiasm as you factor Harmony into yourplans for future Java deployments.
I'm optimistic about the role Apache's Harmony could play in establishing an independent, yet fully compatible, implementation of the full J2SE platform. The Apache Software Foundation has been a strong supporter of both Java and the Java Community Process, so I trust that they are sincere about the all-important issue of maintaining compatibility with Java standards. Moreover, Apache has been very successful at obtaining support from major corporate players who have the resources to help a project of this massive scope succeed. It's going to take a lot of manpower and money to create an independent, compatible, open source Java. Apache may well be the best-positioned organization in the world to take on this formidable challenge, and I hope you will keep an open mind about how you can help it succeed.
Until next time,
Rick Ross
rick@javalobby.org
AIM or Yahoo Messenger: RickRossJL
|
| |
|
|
|
|
|
 |
Matthew Schmidt
is the man behind the scenes at Javalobby. If you have questions
or concerns, feel free to email him at matt@javalobby.org. |
Sneak peek at JRoller Reloaded
As I mentioned last week in my column, I’ve been hard at work to bring JRoller fully into the Javalobby network. This has included a major UI redesign to bring it inline with the main Javalobby site, two new themes (in addition to Red Train that is already at JRoller), and some additions and major fixes to the core Roller code (which have mostly been contributed back for you Open Source folks out there!). I have to say, that at the beginning, I was a bit hesitant to jump into the Roller code, with all its ant tasks and XDoclet generation, but once I got the core code working properly in IDEA and a test server setup here in the office, it turned out to not be so bad. A big thank you goes out to Dave for answering my incessant questions about where this particular model was, or how this particular form was generated.
So, enough of this feel good talk, let’s talk about the actual changes we made to the JRoller code base. Our first major change was to support individual locales for blog entries. If you’ve ever been to JRoller, you’ve probably noticed that at times it can be very hard to read a good portion of the entries that flow through due to the language barrier. Now, along with your blog having a default locale (which your entries use to begin with), you can now blog in more than one language. Say for example, that on Monday you want to write in English and on Tuesday you want to write in Brazilian Portuguese. Just select your locale in the new drop-down box when editing a post and you’re entry will be properly categorized. To go with this change, by default, all entries shown at JRoller will be English language only. Now, I know some of you may think this is unfair, but we have added some clearly visible flags in the top right of the site to let you easily select to see all the entries again (as it is at JRoller currently) or select your own language (be sure to bookmark it!) In the future, we also plan on making this option be a setting in your blog so that we remember how you like to view JRoller. That will hopefully be a change that follows quickly after this new release.
The next major change is more category support for the main page of JRoller. We’ve heard complaints from some of you about how many of the posts at JRoller are not about Java, technology, or development at all. To help with this problem, the main page of JRoller will now only show a set of categories (don’t worry, not specific names) that we think give users the best overview of technology blogging at JRoller. In addition to letting us keep the frontpage clean, this also helps us have more organized information about the activity at JRoller so that we can present the information to you in more interesting ways. So, keep your entries categorized and if you happen to post a technology entry that doesn’t show up on the frontpage (in a category you think should), don’t hesitate to email us about it. We should be constantly tweaking the pattern matching for the categories, so bear with us while we get the kinks worked out.
The final major change is something that has plagued JRoller almost since its inception – search doesn’t work! It turns out that there were actually several things going wrong with the searching at JRoller, all of which were contributing to not being able to find any entries. First, it turned out that there were several entries that no longer had categories. This is a data consistency problem from past versions that should have been cleared up, but is now something that we have “fixed”. Since you probably couldn’t see those entries without categories anyway, most of you won’t even notice the correction. The other problem was that apparently, you need to re-open the Lucene reader once you add a new entry. Since we weren’t re-opening this reader, we just weren’t seeing new entries. In addition, there was never anything in the index to begin with, because it takes too long to index the comments for every entry. We’ve turned off indexing of the comments and now all the entries will be properly searchable. Hopefully, everyone will be able to find all those long lost entries now!
In addition to these major changes, there is also a smattering of other minor bugs that we’ve squashed in the hopes of making the service more manageable. Some of this improvements include getting your password if you know your username, getting your username and password if you know your email address, balancing the resources directory (your resources will be at /resources/m/mpschmid, for example), and complete preview screenshots for all the themes.
Well, now that I’ve got you guys all excited about the changes to JRoller, you’re probably wondering when in the world we’re going to push these changes live. That’s a good question to ask, and hopefully it’ll be sometime early next week if we can get the last few nagging issues out of the way. So, if you have any issues you’d like us to consider for this release or the next minor one (3.0.1), be sure to file them in the JRoller JIRA. Rick and I both hope that these new changes give JRoller the boost it needs to help carry Java blogging into the future, so be sure to create your JRoller blog if you don’t have one, and stay tuned to the site for the big change!
Until Next Time,
Matthew Schmidt
matt@javalobby.org
Yahoo IM: mattschmidtjl
|
| |
|
|
|
|
|
 |
Erik C. Thauvin maintains a blog
, as well as one of the web's first and most popular linkblogs, which he updates daily with the latest Java and technology news. |
|
|
|
|
|
 |
A recap of
some of the most popular and active Javalobby.org
discussions this week. |
|
WYSIWYG GUI builders
|
|
One of the big selling points that I've seen on the forums for NetBeans over Eclipse is its superior GUI builder. The question is, how many of us actually use a builder? And if we do/don't, then why?
|
|
Full Discussion
|
Posted By: Daniel Spiewak - (109 Replies)
|
|
Swing vs SWT... again!
|
|
It might surprise someone, but I think Swing lacks cross platform usuability compared with SWT especially for non-English speaking users.
|
|
Full Discussion
|
Posted By: Xavier Cho - (55 Replies)
|
|
Project Harmony: Open Source J2SE
|
|
On Friday, Geir Magnusson submitted a proposal to the Apache Incubator PMC for an open source J2SE 5 using the Apache software license. The proposal has support from major OS names. Can it fly?
|
|
Full Discussion
|
Posted By: Michael Urban - (48 Replies)
|
|
|
|
|
|
 |
Technical papers & research related to Java development. |
|
High-Performance Persistence For Java
|
|
Caché, the post-relational database, seamlessly combines robust object and relational technologies, eliminating the need for mapping. Every Caché class can be automatically projected as Java classes or EJB components with bean-managed persistence.
|
|
Download Full White Paper
|
Posted by: InterSystems
|
 |
Product and
service announcements for Java developers. |
|
|
|