Beyond Java - Bruce Tate [50]
Let's take another example. Here's an example that prints method names in Java:
public static void printMethods(Object obj) throws Exception {
Class cls = obj.getClass();
Method[ ] methods = cls.getDeclaredMethods();
for (int i=0; i < methods.length; i++) {
Method method = methods[i];
System.out.println("Method name:" + method.getName());
Class parmTypes[ ] = method.getParameterTypes();
for (int j = 0; j < parmTypes.length; j++) {
System.out.print(" Parameter " + (j+1) + " type:");
System.out.println(parmTypes[j]);
}
}
}
It's not as easy as simply grabbing the method names, because Java uses overloading, so you need to know the method name and parameter types to accurately identify a method. I'm going to give a Ruby example next, so if you want to compare apples to apples, just disregard the lines in bold.
Here's how easy reflection can be in Ruby. First, create an object. What class are we dealing with?
irb(main):001:0> i=4
=> 4
irb(main):002:0> i.class
=> Fixnum
Return a list of methods supported by a given object:
irb(main):003:0> i.methods
Print a neat list of the methods that Fixnum supports:
irb(main):003:0> i.methods.each {|m| puts m}
So, Ruby is very reflective. We've done the Java example (minus the lines in bold) in a single line of code. You can similarly find the instance variables, super classes, and so on. That's only the beginning of the power at your fingertips, though. You can also change classes, at runtime, on the fly. You can change a method on an object and leave the class untouched. Also, interceptors are child's play. You can use this metaprogramming to do some amazing things. The Ruby on Rails framework, featured in Chapter 7, shows an excellent example of what you can do.
I should point out that the primitives problem goes far beyond reflection. Look at the API for java.util.Array. You've got to treat arrays as their own kind of type. Java 1.5 makes matters worse by introducing generics. You run across similar problems whenever you need to deal with things generically, whether you're comparing, cloning, reflecting, or describing an object. It's a major problem that's encountered equally by people who use and build frameworks that deal with all types of user-defined objects. As we seek to find more ways to use objects transparently, the problem will only get worse.
Sound Foundations
I'm working on pure intuition here, but I do think that Java's successor will probably be object-oriented, and will be theoretically purer than Java. A purely object-oriented language makes things so much easier, especially when you start to consider metaprogramming, simplicity, learning curves, and increasing processing power. With Java's increasing emphasis on transparency, a cleaner approach will simplify many types of frameworks:
Transparent persistence frameworks need only deal with objects and collections.
XML binding frameworks would have a cleaner API, and a much cleaner implementation.
Debugging frameworks like loggers could easily print values of any parameters.
Consistency is important, too. Languages with consistent naming and consistent behavior are far easier to learn. In general, the next language should be much more consistent, and cleaner. The characteristics in Table 5-4 would form a cleaner foundation for another 10 years of successful growth.
Table 5-4. Important language features that will help propel Java's successor
Rule
Description
Dynamic typing
Support dynamic typing for better productivity.
Rapid feedback loop
Minimize the time between making a change and seeing it execute.
User interface focus
Provide a productive, rich environment for building user interfaces.
Dynamic class model
Improve the ability to discover and change the parts of a class and runtime.
True OOP
Provide a conceptually pure implementation of OOP with no primitives and a single root for all objects.
Consistent and neat
The language should