And Another Thing...

Size is the enemy

I was reading Steve Yegge post about size being the enemy of code and totally agree. There is a section where he talks about Design Patterns adding a huge amount of bloat to a code base, I don't totally agree with that but it did get me thinking about use of Design Patterns in Java APIs.

Something went wrong with the Java community in the late 90s when Design Pattern "inspired" APIs came out in droves. All good ideas can be misused - but Design Patterns have to be the top of the heap.

The APIs before that were really nice and simple to use. It was great in Java 1.0 to be able to say

vector.remove( item )

and not the C++ STL version of

invalid = remove( vector.begin(), vector.end(), item );
vector.erase( invalid, vector.end );

Somewhere around Java 1.2 coming out a whole batch of really bad APIs came out, and everyone from then on modelled after the bad APIs. As an example I'm going to use JavaTV. What do you think the API to change a channel using JavaTV would be?

tuner.changeChannel( newChannel ) ?

Of course not, that would be too easy and not employ enough Design Patterns. What you actually have to do is:

ServiceContext sc = ServiceContextFactory.getInstance().getServiceContext( xletContext );
Locator channelLocator = LocatorFactory.createLocator( "ocap://0x213+0x110" );
Service channel = SIManager.createInstance().getService( channelLocator );
sc.select( channel );

Thats 1 FactoryMethod, 2 AbstractFactories and 2 Singletons - that's an impressive set of Design Pattern use. If you think that's an isolated case think again. Just look at the XML APIs, Security APIs, Java Media Framework, etc, etc.

So, in short Steve is right, but it doesn't have to be that way. Java doesn't need to spend 10 lines saying what other languages can say in 1. It just needs more care spent with API design.

Computer Terminology is Everywhere

 

Thanks to Diana for pointing out that it only contained 8 peanuts ;-)

Zra

Todays blog was brought to you by the character \u183f MONGOLIAN LETTER ZRA

Three Things I Learned About Software in College

From a post by Dare Obasanjo. Here are the 3 things I learned about software in college

1. College doesn't teach you to program (it teaches you to get code to compile in a given language)
   
2. Visual Basic makes people create UIs with "big purple buttons"
3. Write the algorithm first then figure out what data is required to implement the algorithm (from an article by Jim Blinn)
   

Mapping Windows Code Pages to Java Charsets

In a follow-up to yesterdays post, I found this useful resource which shows the mapping between windows code pages and Java character encodings.

Also if you type "chcp" at a command prompt in Windows it will tell you what code page is currently in effect.

Pound sign

John Thomson pointed me to a question about a problem displaying the pound sign in a console application written in Java.

So what's happening?

Well it all has to do with characters, bytes and code pages.
The pound sign has unicode code point \u00A3, so if you write

System.out.println( "\u00A3" );

why does it not display correctly when run from the command line?
System.out is a PrintStream which will convert the Unicode code point to a series of bytes based on the character encoding being used. It tries to pick the default corresponding to the locale the application is running in. That presents a problem for Windows as there are usually 2 code pages in use, one for GUI apps, the other for console apps. Java uses the one for GUI apps.

For example, if the GUI code page is windows-1252 (Latin-1) then the Unicode code point (0x00a3) will be converted to the byte value (0xa3) which is the pound sign. But if you run the application on the command line, it just sees the value 0xa3 and uses it's code page to display the corresponding character. If the console is using code page OEM 850 (Multilingual Latin 1) then code point 0xa3 maps to Unicode character 0x00fa LATIN SMALL LETTER U WITH ACUTE

so thats what will show up on the command line.

The way to fix this is to explicitly set the character encoding to be used:

OutputStreamWriter w = new OutputStreamWriter( System.out, "IBM852" );
w.write( "\u00a3" );

That way the code will output the byte value 0x9C which is the pound sign in that code page.
This works OK in this case, but for a great many Unicode code points there will be no corresponding character in the console code page.

It's also worth pointing out that you should always use the Unicode escape, rather then the explicit character. i.e. don't write System.out( "£" );
If you do, you need to worry about what encoding is being used to save your source file, and what encoding the compiler is reading it with!

There is no such thing as plain text. It's always a sequence of bytes encoded with some character set. If you don't know the character set to use to convert the bytes back to characters you won't get the correct characters back.

The usefulness of Unicode in all this, is to assign a unique code point to each character, so there is no dispute over whether the pound sign should be 0xA3 or 0x9C.

Some really good information for this is at the W3C.

AA

Todays blog was brought to you by the character \u0D06 MALAYALAM LETTER AA

Fancy GUIs

So Microsoft has jumped into the rich client market with Sliverlight, which is basically aimed square at Flash and Apollo. There are some interesting demos, but nothing ground breaking. Although I just found this post about it which points out that it has a lot of pretty major shortcomings.

When I saw it the big questions for me were "why can't Java compete in this space", or even "why is Java not already the dominant player in this space"?

Java 1.2 was released in Dec 1998 and was cross platform and network downloadable, supported a UI toolkit, 2D graphics, video and audio, and by 1999 3D graphics. So basically functionality greater than or equal to what is available today with these other tools but with an 8 year head start!

So what went wrong?
In summary:

• Availability
• Performance
• Integration

Availability
Java 1.2 was not widely installed and the download to get it installed was big and slow. This is still the case. Java WebStart and the Java plug-in don't really seem to have made this a better user experience.

Performance
This has been successfully addressed with both startup time and memory footprint improved greatly, but at the time Swing had a big problem even redrawing a menu quickly.

Integration
From a programming point of view this is probably the biggest issue - Swing doesn't work with JMF, which doesn't work with JOGL. The JMF APIs suck and don't really support the media types that most people deal with. Java2D was never really integrated into Swing, you have to know that the Graphics you are passed in paint can be cast to a Graphics2D, you can't pass a GradientPaint to the fill the background of a component, etc

What to do about it?
F3 shows real promise in providing a Java based option for Rich Clients, but they really need to work on the browser integration  and  startup experience. 
They also need decent tool support which Adobe has in spades and Microsoft is getting into.

Big Yus

Todays blog was brought to you by the character \u2c29 GLAGOLITIC CAPITAL LETTER IOTATED BIG YUS

Building Bridges

Glenn Vanderburg has a great piece about the constant comparison of "software engineering" to "real engineering". There is also a link at the bottom to the classic Jack Reeves essay "What is software design?"