* "There are three big fallacies. First, believing that J2EE is complex; second, believing that Java EE 5 is easy, and third, believing that distributed programming could be simpler."

* “The best advice I know is: ‘Don't distribute’.”

* “Large-scale IT projects are inherently inefficient. It’s a misconception to even talk about a large-scale project.”

* "Most of the Javadoc comments in projects are worthless. They
redundantly describe information that can be easily obtained from the method's signature."

See what you think as this QA has caused a bit of a buzz over on theserverside.com

* The TIOBE Programming Community index which gives an indication of the popularity of programming languages, ranks Ruby 10th in popularity with 2.66% of programmers.

* As is well known, much of Ruby’s recent growth is tied to the popularity of the open source Ruby on
Rails framework, known as “Rails,” which is used for database-backed web applications based on the Model-View-Control pattern. Rails empowers web site construction by analyzing database structures, comprehending table relationships, and automatically creating object-relational mapping code. Rails fits the new Web 2.0 framework nicely and is popular among younger developers.

* Sun is making Ruby and Rails faster and enhancing functionality through JRuby which allows Ruby to enter enterprises where Ruby and/or Rails have never entered as Ruby developers gain access to the Java APIs and the Java community.

* Support from NetBeans, Solaris, GlassFish and more makes for a complete develop and deploy environment.

* Finally, as other applications and languages evolve, Sun is very open to enhancing their value through the flexibility, interoperability, and sheer power of the Java platform.

Here's the basic story: There appears to be a huge market for massive multiplayer online games (MMOGs) that scale to thousands of users, but the technical and economic challenges have been -- until now -- enormous. They require expertise in multi-threaded programming, distributed computing, and transactional processes, along with deep pockets to sustain back-end processing resources.

Kesselman claims that the open-source release of Sun Labs Project Darkstar -- which offers Java technology–based infrastructure software designed for MMOGs -- has the potential to change the industry and eliminate the risks of dupe bugs, rollbacks, disasters and more. Of equal importance, developers should be able to create more dynamic, fun and interesting games.

Heinz makes interesting points:

* The java.util.Arrays class is a good example of bad code.

* The biggest misconception about Java concurrency he calls “The Law of Greek Driving.” Like driving in Greece, the Java Memory Model rules are not always enforced or obeyed by the JVMs. So concurrent code may seem correct and may test out on all available JVMs and hardware but might still be incorrect.

* Developers make a major mistake when they fail to unit test.

* His reaction to open sourcing the platform: The greatest "Huh?" of his professional life.

I'd love to hear what you think...

Finalization allows you to perform postmortem cleanup on objects that the garbage collector has found to be unreachable. It's normally used to reclaim native resources associated with an object. Tony describes how finalization is implemented in a JVM; he identifies problems where memory can be unnecessarily
retained by finalizable objects, and offers solutions, plus advice on when and when not to use finalization.

If the topic intrigues you, check it out.

Some brief points:

Now that software communities are easy to create and showing up everywhere, for most software projects open collaboration is more fruitful than closed. The economic model has changed so that support and training are key. Open source developing involves leveraging the value of the community and allowing your own skills to be leveraged in return in order to prevent "regression test hell".

Btw, the article has created a small buzz on JavaLobby where Simon himself clarifies some issues.

If anyone has information that needs to go in either direction, pleaselet Tom know.

Tom has interesting things to say about the latest OpenJDK hacking, benchmarking, copyright law, and tae kwon do (he's a black belt candidate).

The 2007 JavaOne Conference is over. As always it’s a bit
of a blur, but buried within the blur are nuggets of knowledge, or at
least, moments of clarification where things fall into place. Since
my focus was mostly on open source this time around that’s where
I learned some things.

From Simon Phipps (TS-7498 Liberating Java) Sun’s chief Open
Source officer (look for an article shortly after JavaOne
Conference) I got a better grasp of the motivations and processes
that drive open source.

* Open source developing is not so much about altruism or using
free software so much as creating a work that brings value to the
developer and sustaining it by leveraging the network of other
developers in the community. It’s about avoiding regression testing
hell.

* End users love open-source software because it gives them
control.

* The Apache Software Foundation told Phipps that they looked at
their 10-year history and have not seen a single example of
someone forking an Apache code base and continuing the fork
without contributing code back in the end. Everyone either gives
up or gives back -- there is no third way.

Open Source Developers

The essence of open source software says Phipps: “Open source is
not about using software you have got for free; it is about creating
a work that brings value to you and sustaining it by leveraging the
network of other developers in the community. You are not
abusing them; you are simply collaborating with them in co-
maintaining and co-developing software you are working on. It’s
about avoiding regression testing hell.”

According to Phipps, software always starts with a creative
individual who will be creating a piece of software that will be
meeting a particular need perhaps for a client or for their own
business. They use that software to create a free source commons.

Then someone else looks at that software and realizes it’s a perfect
starting point for their project. They modify it, fix a few bugs and
solve their business problem. The new guy realizes that every
change he makes has a life of its own and will need sustaining. As
changes flow through from the commons each change he has made
will need regression testing; as the code commons builds, every
change he has made will need refactoring and maintaining within
the context of a larger body of code.

As the code commons changes, new skills are required and he
realizes he needs all of the skills in the community in order to
maintain the improvements he’s made against the open source
code commons. He realizes that that is a recipe for bankruptcy:
forking a code commons leads to regression test hell. So instead of
keeping these changes to himself, he is going to contribute them
back not because he is an altruist or a philanthropist, but because
he realizes the best way to produce great software is to contribute
back. This is the key dynamic in the open source community. Open
source is not about using software you have got for free; it is about
creating a work that brings value to you and sustaining it by
leveraging the network of other developers in the community. You
are not abusing them; you are simply collaborating with them in
co-maintaining and co-developing software you are working on.

Why End Users Love Open Source -- Control

End users love open source software, not because they love to have
6 million lines of extra source code – they love it is because they
don’t have to buy a bundle any more. They don’t have to buy the
glossy box with all the stuff in it. They don’t have to buy a
software license and are told it comes with indemnity and
installability and documentation and training and support. Then
when they make a claim on any of those things, they find that
many are illusory and require payment further down on the value
chain. OS software lets end users decide what they are going to
pay for. There will be some things that are critical to the business
and are beyond the skills of the staff for which you will need to
buy a service from a vendor. There are other things that are woven
in the scope of the skilled staff you hire. You hire in to have the
work done. There are some things of no value anyway and if the
problem arises you will buy what you need. You can choose to
take a risk on those expenses

Why Open Source Won’t Fork the Java Platform

The Apache Software Foundation told Phipps that they looked at
their 10 year history and have not seen a single example of
someone forking an Apache code base and keeping going with the
fork without contributing code back in the end. Everyone either
gives up or gives back; there is no third way. And so the process
continues with more and more people deploying and improving,
developing the software, fixing bugs in it, and ultimately
contributing to the community, not because they want to give away
stuff, but because contributing back reduces their costs and allows
them to leverage the network effects of the community.

This helps me understand why James Gosling and other Java
luminaries say that they do not worry about open source leading to
forks in the Java platform. And why Ray Gans, Manager of the
OpenJDK Community for Java SE__ tells me that there is a
consensus among the developers he knows that other developers
do not want the platform to fork.

Question: Will – and Should – Open Source Developers be Paid by
Sun?

Jonathan Schwartz and Rich Green addressed this at the
CommunityOne keynote.

First Schwartz: “The folks who write the New York Times are their
employees, but on the Web the market for user-generated content
is growing. YouTube doesn’t employ any of the people who create
the content that they distribute across the world. So there is a
dichotomy between those who employ everyone who create their
content, and those who employ no one. We look at that and say
that it cannot be sustainable… At Sun we’ve gone from employing
all the people who create the content that Sun delivers to the
marketplace to a situation where open source developers make
contributions. We can’t expect everyone to always do this from the
benevolence of their hearts.”

Rich Green: “A lot of people are creating innovation that other
organizations are benefiting from. I think this is unfair and
unsustainable. It’s Robin Hood backwards. We are stealing from
the poor and making other people rich and this seems very bad.
Humans will not do this, nor should they have to. We have to look
closely at working with those who contribute to the open source
but whose contributions generate revenue for Sun and share that
wealth. I’m sure we are going to do that.”

So if Sun financially incentivizes open source developers, how will
that affect the community? We are in new territory. Sun is now the
biggest open source company in the world. What happens next?...

Upbeat Stats

Let me close with some more upbeat stats not included in previous
blogs:

2,100,000,000 Total Java enabled Handsets ; new shipments: 976
M by end of CY07
(Ovum, March 2007)

By the end of CY 2007, About 85% of all handsets shipping will
be shipping Java
(Ovum, March 2007)

2,500,000,000 total shipments of Java Cards

180 operators deploying Java-based content/services

4 Million Total Java-enabled Blu Ray devices

436,000,000 JRE downloads

8,750,000 Total Java SDK downloads (SE, EE, ME)

6,300,000 Java SE JDK downloads

720,000 Java SE JDK downloads/month

7,270,000 Million downloads of Java EE from July 04 - May 07

2,500,000 GlassFish downloads (includes RI/GlassFish)

This year we’ll have a .org pavilion with a host of community representatives from OpenJDK, GlassFish, Codehaus, Hyperic, Betavine, OpenLaszlo, Greenfoot, Woodstock, PostgreSQL, JavaDB, Apache Software Foundation, Free Software Foundation, Zimbra, Funambol and more scheduled to share code and ideas.

And the first CommunityOne conference takes place the day before JavaOne with NetBeans software, OpenSolaris, GlassFish, OpenJDK, the Mobile & Embedded communities and all manner of startups and others present.

I sense an atmosphere of expectation, hope, and tentative adjustment as people reconfigure their roles and as Sun tries to get it right. Developers are concerned about licensing issues, the availability of implementations, and other matters. I’m somewhat surprised at how few people seem concerned about forking; there appears to be consensus among developers that most folks want one Java platform.

I’m told that Sun engineers who once worked exclusively with their teams are now encouraged to work with people outside of Sun and to actively listen to their ideas. Some people are learning to communicate more effectively and manage their time so that they can work with the community and still work on their code and
assignments. It's a real cultural change and like everything technology-wise, it's happening so fast!

I’ll be covering CommunityOne, parts of which are more of an unconference than a conference, plus introducing this year’s Java Rock Stars and blogging all over the place about sessions and events on the floor.

I’ll close with a few fun stats that tell a story about how far we’ve come. Here goes:

6 Million Java Developers Worldwide

6.5 Million Lines of Java SE code open sourced under GPL v2

5,000,000,000 Total Java enabled Devices; 1.83 billion installed CY 2007 to date

800 Million Total Java Desktops

7 Million Total Java enabled set-top boxes….

I could go on a lot longer and spend the rest of the day trying to comprehend the realities that these stats represent. More info is on the way, so stay tuned!

Peter has a lot to say:

-- Learning to use the Java Compiler API (JSR 199) "will provide a lot of
indirect benefits" to Java developers. Danny Coward commented: “For those
of you deafened by your screaming inner geek, roll up your sleeves and give
it a try."

-- Regarding generics: "Rather than trying to provide
reified types for all instances, why not simply accept that some
instances do not have reified type information, because they are
compiled with a 1.4.2 compiler, or for other reasons? This turns reification
into a best-effort problem: if you use a raw type, then no type information
is reified, but if you avoid raw types, you can take advantage of the additional
reified type information."

-- His proposal for an alternative to type inference for local variables
involves having the compiler provide the static factories.

Hope this triggers some interest.