Cynical Monkey

I just got back from the 2004 OOPSLA conference in Vancouver. This was my first OOPSLA ever so I am approaching this without the perspective of a longtime OOPSLA veteran. Overall it was a great experience the really got the head-gears turning.

From the keynote “The Future of Programming,” Richard Rashid makes it clear that the future of programming is M$ visual studio 2005. Rashid shamelessly made an OOPSLA exclusive product announcement midway through his keynote and invited an assistant to give a protracted demonstration of the new and improved modeling tool in the latest version of Visual Studio. Many people walked out of the room.

Notes on Notes on Postmodern Programming with James Noble, Robert Biddle was an interesting commentary on the state of modern software development practices. Their point being that all of our “failures” in software development are really a symptom of our modern view of development and maybe we should just take a different view of the current state of things and approach the practice of our craft with more love and creativity, instead of building the same systems over and over again on grander and grander scales.

Alan Kay’s Turing lecture was a refreshing and wonderful talk that challenges the frontiers of imaginable Human computer interaction. His point being that we are simply creating marginal improvements on the great ideas of thirty year ago. His inspired outlook and challenge to transcend modern human computer interaction gives me hope for the future of the profession, and the great advancements still waiting to be made.

Steve McConnell’s talk was great but very economically oriented. One might call him the “Too Pragmatic Programmer,” but his message was very clear and very true. We should really make an effort to follow our current practices and methodologies with exactness and discipline before we throw them away chasing the next big thing.

There were also many other great talks and presentations but I will leave my discussion at the big talks that really made an impression on my current views.

My intuition would tell me that String.equalsIgnoreCase() would be a more expensive operation than String.equals(). If you think about it you have a lot more combinations that you have to test. This is where reality diverges from intuition.

The first things that both String.equalsIgnoreCase() and String.equals() check is length, and I’m willing to bet that most strings aren’t the same length, so you’re done. The reality is that String.equalsIgnoreCase() may be faster in a lot of instances because its parameter is a String so it doesn’t need to check instance and cast before the length comparison like String.equals() who’s parameter is Object.

So don’t handicap your string comparison just because you’re worried about performance. With String.equalsIgnoreCase() you can be fast and flexible.

While reading an inner classes article I discovered some Java syntax totally new to me..
Say you write a public inner class like so.

public class Foo {
  public class Bar {}
}

If I wanted to create a new instance of Bar I would have to do it like so..

Foo foo = new Foo( );
Foo.Bar bar = foo.new Bar();

The foo.new is something that I have never seen before but it is refreshing to see something new like this in a language that you know so well. I suppose it fits with my understanding of the language since all constructors are compiled into static <init>() methods, and Bar’s constructor is in Foo’s namespace. After all new Bar() is just syntactic sugar for the static Bar.<init>() method in compiled code.

I attended an interesting speaking session last night at the Madison JUG. The talk was on Jython given by John Carnell.

My overall impression was favorable. I liked the functionality in Jython for executing scripts dynamically in Java code, the application that he suggested was business rules that change. You extract the rule logic out to a Jython script and then you can modify the application with out redeploy/restart/recompile. Another cool thing that John didn’t mention was that Websphere server administration tasks can be scripted in Jython which open possibilities for automated server configuration at deployment time, and easily managing your server configuration alongside your code.

I’m still left wondering what Jython adds to the mix that isn’t already addressed in Groovy. I know squat about python, but I though that Groovy (being modeled on Ruby) would have a few more tricks in it’s bag.

Long and short Jython looks cool and I’m planning on downloading it for a little playing around. John thanks for coming to the MadJUG. Ohh and check out John Carnell’s new publisher aPress John was raving about them and it looks like they have some gook books up-and-coming.

A Hindu Mondo
Once, a yogi meditating on the bank of the Ganges who noticed a scorpion fall into the water. The yogi scooped it out, and for his kindness was bitten. Soon the scorpion fell again into the river. Once more the yogi scooped it out. Once more the scorpion bit him. When the sequence was repeated twice more, a bystander demanded, “Why do you keep rescuing that scorpion when its only gratitude is to bite you?”

“It is the nature of scorpions to bite.”, replied the yogi. “And it is the nature of yogis to help others when they can.”

Retold
Once, a developer was working on a large software system and noticed an improvement that could be made to the UI. The developer tweaked the UI, and for lack of strict adherence to the requirements was bitten. Soon the usability of the system could be improved again. Once more the developer made a correction. Once more the clients bit him. When the sequence was repeated twice more, a bystander demanded, “Why do you keep fixing issues when the clients only gratitude is to bite you?”

“It is the nature of clients to bite.”, replied the developer. “And it is the nature of developers to produce quality software whenever they can.”

I’m no expert on the Java internals, nor do I do any kind of language design. I do find some of the lower level internals of the Java language runtime very interesting. Take a simple class with implementation and visibility modifiers omitted.


public class Foo {
static int j = 0;
Foo()
Foo(Foo aFoo)
int getI()
void setI(int i)
static void somethingStatic()
}


When this class is compiled to byte code it becomes semantically closer to this.


public class Foo {
<clinit>()
LFoo <init>()
LFoo <init>(LFoo)
I getI(LFoo)
V setI(LFoo, I)
V somethingStatic()
}


There are two new method names here that we didn’t specify <clinit> and <init> there are initialization methods that are written into the class by the compiler. <init> is a method that returns a new instance of the object AKA. constructor. <clinit> is the static initializer, it sets j to 0, and would perform any other static initialization logic.

A few other quick notes:

• L in LFoo means that we are dealing in language references.
• I means primitive integer.
• V is void return type.

You will also notice that any distinction between instance and static invocation had disappeared. Really isn’t expressed declarative at the byte code level. All instance methods assume that their first parameter will be the reference to their instance, whereas static methods are invoked without a parameter reference to their instance. Note, the instance reference is not an actual part of the method descriptor as I indicated above, it is simply implied. All distinction between static and nonstatic is at invocation, by using the appropriate bytecode instruction:

• invokeinterface - Invoke interface method
• invokespecial - Invoke instance method; special handling for superclass, private, and instance initialization method invocations
• invokestatic - Invoke a class (static) method
• invokevirtual - Invoke instance method; dispatch based on class

The beauty at the byte code level is its simplicity. There is no magic, to me it just makes sense, and if you didn’t know before now you know what it means when you see a <clinit> or a <init> in a stack trace..

Last month I attended a No Fluff Just Stuff Conference in my home state of Wisconsin. I wanted to say a small piece about it. After all, they did work hard at planting the “Blog about the Conference” Meme in my head.

The conference was great. I can’t say enough how much of a value it is to come and see these speakers in person. The speakers at this conference are top notch. I always walk away with a wow factor.
I have to say my personal favorite speaker is Stuart Halloway. Stuart always has the sessions that look a little deeper into the platform and bring the more enigmatic and powerful features of the Java Platform to the surface. That and he’s just a very charismatic guy.

So now my gripes.

• One of the conference’s main tenants is that doesn’t try to sell anything, I totally agree with that ideal, and so I say they should try selling conference a little less. I don’t think Jay Zimmerman(organizer) ever stopped praising up the conference to the attendees.
• Last year they branched out and did some lessons learned from other OO languages (Objective-C, Ruby). I was hoping for that breadth again this year. Ohh yeah, and what about mobile Java, Java for Games?
• They did cover Test Driven development. Out of 50 sessions nine were TDD related. It was so bad that some of the buzzword zombies started asking TDD questions during a Java Reflection session.
• Finally, I know some consulting groups in the area wanted to help sponsor the event, but were turned down because, “they don’t accept sponsors.” Except that our conference packets contained blatant advertisements for one consulting firm along with skill matrixes. I thought that was very hypocritical.

All in all besides my gripes it was an excellent conference that I would recommend to anyone. I am a little biased because it’s the only professional conference that I have ever attended. I am planning on going to OOPLSA this year and would be very interested in feedback from people who have attended this conference in the past.

Java is a language that doesn’t have any cutting edge syntax, it’s basically C++. Java didn’t really invent or improve upon any existing paradigms or semantic structures, its OO is less Object Oriented than Smalltalk, and it doesn’t even match C++ in utility (although it kicks C++ in the pants for simplicity). So what does Java have that makes it so formidable? It has a very dynamic platform.

• Automatic memory management - Garbage Collection
• Dynamic runtime - Byte Code is interpreted, JIT.
• Dynamic loadtime - Classloaders, and load time linking

Java developers should focus on the strengths of the platform, and avoid getting caught up defending Java the Language. As a language Java is going to keep morphing and becoming new things to new people. As a platform Java is sound it makes an excellent for new languages including JSR 241: Groovy. The future of Java is in the platform and not in the platform’s namesake language.

That said Java is a pretty decent language, with simple but verbose syntax. Java is my language of choice, but not because I have any special attachment. I love Java because I love the platform, Java the language is going to keep evolving along with its platform no matter what your stance on Generics, or Static imports (I hate them). As long as the platform grows and improves I’m happy at the end of the day.

I really feel that a basic understanding of the Java byte code is a staple that has been missing from most Java developer’s Java diet for too long. One of Java’s biggest assets is it’s dynamic nature, and much of that comes from having the byte code as an intermediate language. Byte code is the language of the Java platform. Until you understand the fundamentals of the byte code and the JVM, JSR 241: Groovy, sounds like a juicy hack retrofitted to the JVM. Once you understand the byte code you will realize that Java is just a juicy hack too.

I guarantee that once you understand the byte code and the basics of the JVM spec you will never look at or write your code the same again. Check out this JDC Tech Tips to get started. Then get it right from the horse’s mouth, JVM spec.

I would take a pay-cut if I were allowed to use CVS or subversion. It’s not the Lock-Modify-Unlock vs. the Copy-Modify-Merge workflow. Although I do prefer the latter there are ways to work around the locked files. I think that my biggest problems are..

• file based branching.
• no easy way to update.
• lack of automatic merging.
• no good support for deletes

Where I work we run concurrent projects for the same system so we do our development in branches, and merge in fixes from the trunk. It’s a pain because whenever we work on a file that not been branched we need to specifically branch it. That means we need file by file knowledge of each files repository status.

There is also no easy way to update. First we have to do a get against the HEAD/Trunk representing the current release, and then try the same get against the label on our branch. Most often resulting in an error but we have not found a better way to automate this task.

There is no automatic merging. So if a project affects 100 files and there were no changes in HEAD/Trunk since they were branched, I still have to manually merge changes into 100 files. I don’t understand why since there are no conflicts. So I actually developed a hack work around out checking out the HEAD/Trunk revision of all the files that have my branch label on them then I do a get on the branch label overwriting all the files and then check all of the files back into HEAD/Trunk. I hate this though because if I don’t do my homework correctly and there were changes to HEAD/Trunk since the files were branched I will just clobber all of the changes, not good form.

Finally there is no way to delete a file without removing all revisions of it everywhere in the repository. So I move a Java class to a new package, it results in a delete, and a create in a new location. Not that I like losing the revision history in tools like CVS, but PVCS won’t even let me remove the file with out removing all traces of it everywhere in the repository(actually you can later restore the file later but you don’t know it went missing). So if I need to delete a file from my development branch nobody better try to rebuild the production release. I’ve resorted to keeping a list of files I would like to delete but I’m not really sure if I will ever be ready to commit to following through knowing the consequences.

All in all PVCS is a huge headache. Somedays it consumes more of my precious time and mental energy than coding. I hope that if anyone out there is considering using PVCS they reconsider.