Free Together Designer From Borland
Borland released a free Together Designer Community Edition. I downloaded the 60 MB bundle, obtained the registration key and started it up. It have the familiar Together ControlCenter look and is very responsive.
It supports the drawing of seven kinds of UML 2.0 and UML 1.4 diagrams:
- Class
- Use Case
- Sequence (UML 1.4)
- Collaboration (UML 1.4)
- Statechart
- Activity
- Component
- Deployment
- Composite Structure (UML 2.0)
It supports imports from MDL and XMI formats. It saves in a proprietary XML format. Diagrams can also be exported to GIF, SVG, and WMF format graphics files.
There are no support for code generations or round trip engineering.
This makes it possible for every member of the project team to work on key UML diagrams. Prior to this, most of the projects I was on has one copy of (a very expensive UML tool), forcing the architect to save the diagrams as graphics files or paste them into Word documents to share the design with the team.
Jython Inventor To Join Microsoft
Jon Udell of InfoWorld is reporting in his blog:
... The talk concluded with two announcements. First, IronPython 0.6 is available now under the same Common Public License used by Eclipse. That drew applause. Second, Hugunin starts work at Microsoft on Monday. His charter: to work towards a production-ready IronPython, and more broadly to improve the state-of-the-art of dynamic languages on the CLR.
Jim Hugunin was the original developer of what is now Jython. (The link is mysteriously refusing my connections right now.)
Java Generics Question
In my quest to develop a generic singleton class, I encountered this problem:
[weiqi@gao] $ cat Singleton.java
public class Singleton<T> {
private static T instance;
public static T getInstance() {
if (instance == null) {
instance = new T();
}
return instance;
}
}
[weiqi@gao] $ javac Singleton.java
Singleton.java:2: non-static class T cannot be referenced from a static context
private static T instance;
^
Singleton.java:3: non-static class T cannot be referenced from a static context
public static T getInstance() {
^
Singleton.java:5: non-static class T cannot be referenced from a static context
instance = new T();
^
3 errors
Why? (Both C++ and C# allow similar constructs.)
IntelliJ IDEA 4.5: New Logo
Well, first things first. The first thing that catches my eyes with IntelliJ IDEA 4.5 is it's new logo:
It's Really Quiet Here
OCI is expanding!
We (Kevin, Jonathan and me) moved to the brand new cubicles in the expanded OCI office space this afternoon.
It's really quiet here. We can hear the sound of our keyboard clicking, and the sound of our hard drive spinning.
It's great!
Test-First This!
Cedric Beust posted a few tricky interview questions in FUN WITH BITS
There are three categories of bit-shifting questions that I usually pick from, in increasing order of difficulty:
- How can you determine if a number is a power of two?
- How can you clear the rightmost bit?
- How can you count the number of 1 bits?
Answers were given in the blog. However they were derived at logically. In this day and age of the test-first hype, I would like to challenge its adherents to solve the problems in a test-first fashion.
Any takers?
Great Ideas: Popularize? Trivialize?
Ideas are usually trivialized as they are popularized. Great ideas retain their essence as they go through the process. Others become empty slogans that hinder true understanding and progress.
Take, for example, the idea of the singleton pattern.
Have you written code like this:
public class Registry {
private static Registry instance;
private Registry() {
}
public synchronized static Registry getInstance() {
if (instance == null) {
instance = new Registry();
}
return instance;
}
// ...
}
How many times have you written code like this? If you answered "Every time I implement a singleton class," you are not alone.
But aren't you writing a lot of duplicated code? Whatever happened to object-orientation and code reuse?
"But, but, bu---the code it so simple. And my IDE can write it for me."
Is the above code a faithful translation of the C++ code in The Book? Are you sure?
Well, not quite. For one thing, the constructor is protected in the GoF code. And the book spent almost two pages out of the seven dedicated to the pattern talking about subclassing a singleton class.
As the singleton pattern is popularized, it is also trivialized. In this case the essence of the pattern is retained.
As an example of over trivialization, I'll cite the "partial extreme programming" phenomenon I alluded to thirty days ago, whereby the three inter-leaning principles of XP:
- Do not write code without a failing test
- Write the simplest code to make the tests pass
- Refactor relentlessly to improve the design of the code
Is reduced to:
- Write the simplest code that will work
Thus opening the gate to all sorts of irresponsible coding practices.
Today's homework: In the ACE C++ Framework, there is a template class called ACE_Singleton that adapts an ordinary class into a singleton class.
With the help of generics in J2SE 5.0, we should be able to write something similar to decouple the business logic of a class from its singleton-ness.
Doing this can save everyone from having to write the boilerplate singleton code again and again. It may also help reduce the complaint that singleton classes are hard to test.
JCP Bad For Groovy?
Ted Leung: since the announcement of the JSR, I feel that there are more people pushing for Groovy to be more like Java, which (at least in my mind) defeats the purpose of having Groovy in the first place.
Mark Volkmann expressed similar opinions recently. Basically Mark liked Groovy as of the time he wrote the JNB article, roughly the same time Groovy started the JSR process. But he might not like it any more when it's through with the JCP process.
I've been advocating for Rhino and Jython for a long time. I think groovy is in the same league. While joining the JCP process might have broken new grounds in terms of officially opening up the JVM to scripting languages, the resulting language might be less than ideal if James compromises on his vision too much just to please the Expert Group.
One Year of Blogging
The coming Tuesday (July 20) will be the one year anniversary of this weblog. Time to look back and reflect.
It all started when, on the way back from an OCI Java lunch one day, Eric Burke asked me if I knew anything about blog aggregators. Of course I did not, but with Google I learned all about it pretty quickly. I used nntp://rss for a while. Then I found out about Simon Brown's Pebble while researching my JBoss talk at the St. Louis JUG. I dropped the war file into my JBoss server, configured it in a few minutes, tweaked the stylesheet a bit, and started blogging.
During the year, I wrote 176 entries, totaling 353K bytes and 44K words, as reported by wc(1). I spent an estimated 100 hours composing those entries.
Most of the hits come from Google, and JavaBlogs, which I joined in January. There are 124K page views recorded. The most popular entries are:
- Subversion: Two Weeks Later (1020)
- NetBeans 3.6: Still Annoying (1015)
- JDK 1.5 Beta 2 Tidbits (877)
- JARPATH (828)
- Subversion: First Impression (684)
- IDEA 4.0, J2SDK 1.5.0 Beta 1, Generify, ... (674)
- The Desire to Make the Light Green (609)
- Fedora Core 2, nVidia GeForce 4 MX, Windows 2000 Dual Boot, ... (595)
- nXML is Fantastic (582)
In the early months of blogging, I constantly worried about things like "What am I going to blog today?" Brad Shuler helped me by constantly point out "There's your blog!" during conversations.
The referrers pages and the web server logs has been a source of amusement. I learned quite a few new country codes while reading these log files. The Google search words that lead people to my pages sometimes is just unbelievable. ("Did I write about that?")
All in all, my experience with blogging has been a really positive one. My thanks go to everybody who bothered to subscribe to my feed. I guess I'll just keep on blogging.
BTW, my aggregator of choice now is Bloglines.
Subversion Java Bindings on OS X, Linux
Brian Coyner: Building Subversion on Mac OS X is not hard. Building the Java bindings for Subversion is challenging until you know what to do.
The steps outlined in Brian's weblog can be, with minor (and obvious) modifications, used to build the "javahl" Java bindings for Subversion on Linux systems, too.
With the svn-javahl.jar (and libsvnjavahl-1.so.0.0.0) in place, I was able to install the IDEA plugin for Subversion.
"JBoss Application Server gets J2EE-certified"
Passing The Link Along (GridBagLayout Fun)
This short flash movie is making the rounds in blogland. I'm just passing this link along.
Enjoy!
Subversion Comes To Cygwin
I'm updating my Cygwin installation this morning, as I tend to do from time to time, and just noticed that Subversion 1.0.5 is available now.
1.03 - .42 = 0.6100000000000001? No Way!
For some reason, I can't seem to let this one go. I've read the comments on this blog (thanks Dan for all the information). I've talked with a few other people.
I have verified that Java and C++ represents the numbers 1.03, 0.42, and the result of 1.03 - 0.42 the same way by using
- java.lang.Double.doubleToLongBits(double)
- java.lang.Long.toHexString(long)
in Java and
- double d, *p = &d;
- long long l = *(reinterpret_cast<long long*>(p))
in C++.
So the differences are in the way doubles are printed.
Jeff Brown mentioned to me at the St. Louis JUG meeting Thursday that there might be other floating point numbers that Java prints right and other languages print wrong.
But a little experiment (a very superficial one, I admit) indicates that Java is wrong more times than C++:
[weiqi@gao] $ cat Foo.java
public class Foo {
public static void main(String[] args) {
double ds[] = {0.1, 0.2, 0.3, 0.4};
for (int i = 0; i < 4; i++) {
for (int j = i + 1; j < 4; j++) {
System.out.println("" + ds[j] + "-" + ds[i] +
"=" + (ds[j] - ds[i]));
}
}
}
}
[weiqi@gao] $ javac Foo.java
[weiqi@gao] $ java Foo
0.2-0.1=0.1
0.3-0.1=0.19999999999999998
0.4-0.1=0.30000000000000004
0.3-0.2=0.09999999999999998
0.4-0.2=0.2
0.4-0.3=0.10000000000000003
[weiqi@gao] $ cat foo.cc
#include <iostream>
int main() {
double ds[] = {0.1, 0.2, 0.3, 0.4};
for (int i = 0; i < 4; i++) {
for (int j = i + 1; j < 4; j++) {
std::cout << ds[j] << "-" << ds[i] << "="
<< (ds[j] - ds[i]) << std::endl;
}
}
}
[weiqi@gao] $ make foo
g++ foo.cc -o foo
[weiqi@gao] $ ./foo
0.2-0.1=0.1
0.3-0.1=0.2
0.4-0.1=0.3
0.3-0.2=0.1
0.4-0.2=0.2
0.4-0.3=0.1
Then Jeff Grigg interjected with the sarcastic "Java is right and everything else is wrong."
Somehow, I don't feel so confident.
The Javadoc for java.lang.Double.toString(double) details how Java prints a double. It specifically mentioned this:
How many digits must be printed for the fractional part of m or a? There must be at least one digit to represent the fractional part, and beyond that as many, but only as many, more digits as are needed to uniquely distinguish the argument value from adjacent values of type double.
This might be the root of the problem. What if two adjacent doubles have decimal representations that differ only in insignificant digits? By the above rule, insignificant digits will be printed just so that the two numbers can be distinguished.
Does such pairs of adjacent doubles exist? I don't know. My suspicion is that they do exist, and 1.03 - .42 belongs to such a pair. Of course, it could also be something more complicated that I don't understand.
1.03 - .42 = ?
Item 31 of Joshua Bloch's Effective Java reads:
Avoid float and double if exact answers are required
And as an example, he used the following example:
System.out.println(1.03 - .42);
which prints
0.6100000000000001
I understand the reasoning behind the advice. No problem there.
Out of curiosity, I tried similar expressions in several different languages that's available on my Fedora Core 2 box. And the result is fascinating:
| Language | Expression | Result |
|---|---|---|
| C# | Console.WriteLine(1.03 - .42); | 0.61 |
| C++ | std::cout << 1.03 - 0.42 << std::endl; | 0.61 |
| Perl | print(1.03 - .42); | 0.61 |
| Python | print(1.03 - .42) | 0.61 |
| Ruby | print(1.03 - 0.42) | 0.61 |
| Guile | (display (- 1.03 .42)) | 0.61 |
What is going on here?
Autoboxing This
People who read Javablogs have already seen this. For people who don't, here's an interesting puzzle/trivia/surprise about Java 5.0 autoboxing from Eugene Kuleshov.
Enjoy your Java!
ComboBoxes for Entering U.S. States Are Lame
I live in St. Louis, MO. And I'm tired of filling out online forms where I have to deal with combo boxes like this:
This is usually part of an address form where I can pretty much fill out everything by typing in the information and then tab to the next field.
The combo box breaks that flow, forces me to pick up the mouse and click on the down arrow, scroll down so that my state is visible and then select the state.
I know the combo box can be operated with the keyboard. But to get to Missouri, I have to type "M" seven times.
All the while, the task could have been accomplished with two key strokes: by typing "MO".
Someone may argue that the combo box prevents people from entering a two letter combination that's not a state. This argument simply doesn't hold water. Why is it then I'm trusted to type in my street name and city name? Aren't they worried that the city name is non-existent?
The whole thing is silly, a misguided design propagated by ignorant programmers. You've just turned a two key strokes worth of work into three mouse gestures or seven key strokes (eight for Montanans and North Dakotans).
Make it a validated text field!