Skip to main content

Java is getting open. What about Java quality?

Posted by cos on May 20, 2006 at 12:13 AM PDT

Hello there!

Last week happened to be quite busy for many Java developers,
activists, and supporters. JavaOne 2006 conference had a lot of
interesting pods, booths, talks and other kinds of presentations. A
leading development companies were bringing their innovations to share
the knowledge and expertise in the field.

I won't reiterate the same things you perhaps heard already: you can
find them here
or href="http://blogs.sun.com/roller/page/vmrobot?entry=javaone_2006_%D0%B4%D0%B5%D0%BD%D1%8C_1">custom
one from our SPB team (in Russian)

Among other great href="http://www.tmcnet.com/usubmit/2006/05/18/1655749.htm">things
there was one which firstly hit a crowd of attendees of href="http://www.eweek.com/article2/0,1759,1962100,00.asp?kc=EWRSS03119TX1K0000594">Netbeans
conference (there were a few very interesting talks, especially on
my lately favorite topic - Java ME development and tools; I'll talk
about this more next time) and then it'd been brought to the wider
audience of JavaOne Day One's keynotes. Right, I'm talking about
bringing Java to href="http://www.vnunet.com/vnunet/news/2156205/sun-promises-open-source-java">open source. I think, that has been expected for a long time and I
guess that this will bring some new blood into Java platform around
the world.

Ok, it's all hunky dory and rosy then. But also it brings some
concerns. Java platform is big and complicated application. It has
core things, like VM, libraries, a platform depending code, backward
compatibility promises, etc. Besides, Java community has to make sure,
that the quality of the platform won't suffer from this move.


I'm a strong believer of the following approach: if a standardized
technology is getting available for a community, then the testing
methodology has to accompany it as well. The only requirement ought to
be attached: test suites should pass. This will help to keep proper
level of compatibility, avoid unnecessary branching, and let
participants to keep better grip over the development process. Doesn't
sound too open to you? Great, share your thoughts with us.


However, any testing methodology assumes some frameworks to execute
the tests. E.g. Junit is required for unit tests; JCK suite has to be
passed under JavaTest for a JDK's certification, etc. So, the same is
true in our case: we need to supply the testing frameworks.

It sounds like Sun has to bring some chunks of the quality
infrastructure along. Does anyone get surprised, that I'm talking
about href="http://weblogs.java.net/blog/cos/archive/2005/09/java_quality_me.html">Java
quality again :-)? Back href="http://weblogs.java.net/blog/cos/archive/2005/10/java_qualitys_o.html">then
I'd mentioned some choices of the testing tools. David Herron'd added
more details on href="http://weblogs.java.net/blog/robogeek/archive/2005/11/the_quality_tea.html">that
topic. As the major contributor
to the DTF for the last few years, I want to see the project moving
ahead and not getting accidently abandoned. This scheduling framework
can save a lot of valuable engineering time (thus money) for any java
development/testing team.

Another great tool, which will be nicely going along with DTF is our
internal test harness called Tonga. DTF and Tonga are getting together
very well. In fact, they were designed and implemented with quite an
awareness of each other. This couple makes a great yet very flexible
and efficient testing infrastructure.

Obviously, we have a lot of other interesting in-house solutions,
which, I'm sure, would be a real value-add for the community. For
instance, our Java coverage framework, creatively called jcov, test
results processing and reporting tools, et cetera.

I'm not a lawyer or any of the high-flying Java execs, so don't take
my word to a court :-) However, I'd be pushing for this tools open
sourcing approach enthusiastically and will keep you posted on the
progress.

Take care,

Cos

Related Topics >>