Cynical Monkey

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.

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.

The IOC, Dependency Injection wave is coming into shore for Java developers. The whole IOC idea certainly isn’t new, its just good design.

• Prefer Delegation to Inheritance
• Program to Interfaces
• Decoupling

It seems that something as “simple” as a framework to support these principals would have been happened a long time ago. It’s not that you can’t have good design without a framework, but a good framework should help facilitate good design, and consistency across a system.

One quick disclaimer, I’m endorsing Spring because I have used it and I have gotten results that I’m very pleased with. I’m a little concerned that PicoContainer is falling into the background. From what little I’ve seen PicoContainer seem to be the technically superior IOC container implementation. Unfortunately superior IOC doesn’t seem to be the driving force. The real killer-app of the IOC arena is J2EE simplification, and that’s Spring.

It’s hard to integrate an architecture technology like Spring into a real project with it’s own established architecture. I aimed for the target of the greatest opportunity, our DAO layer. Our application uses generated DAO’s laden with customizations, which present a number of problems.

• Customizations make them very hard to regenerate or tweak
• Profuse boilerplate code makes them very verbose and hard to read.
• Crosscutting concerns like error handling are hard to change
• The verbose boilerplate code encourages cut and paste(and associated errors)

Enter Spring, with its IOC. All the boilerplate code is isolated to one place, with callbacks for the code that really does vary. No more worrying about resources not being handled correctly because a novice was in cutting and pasting. We can still use code generation for the easy PreparedStatementCreator’s, and ResultReader’s, and we can add our own custom PreparedStatementCreator’s and not have to worry about the generator accidentally clobbering them. Transactions are now declarative and we didn’t need to worry about managing them in the application code or using Session EJB’s.

Our DAO layer just got about 10 times more manageable, and it was easy. I will be looking for more opportunities to let Spring make my life easier, and I would encourage any one else to do the same.