HandBooks Professional Java-C-Scrip-SQL part 17 pps

Dynamic Typing Java purists defend strong, static typing with the fervor of English soccer fans..  Static typing catches some types of subtle errors at compile time, like the misspell

5.4 Language Features

It's strange to be more than halfway through the characteristics of the next great programming language without even talking about the major features of that

language When you look at the history of programming languages, it makes more sense The features of a language are important characteristics for success, but only rarely are they the most important characteristics Said another way, market share and mindshare matter more than how you interpret whitespace

5.4.1 Dynamic Typing

Java purists defend strong, static typing with the fervor of English soccer fans To

be sure, static typing does have its advantages:

 Static typing enforces typing rules at compile time, when they are least expensive to fix

 Static interfaces make it easier to enforce a protocol across important

boundaries For example, systems designers may want to force certain types for C interfaces, or certain remote procedure calls

 Static typing catches some types of subtle errors at compile time, like the misspelling of a variable name

Still, as you learned in Chapter 4, there's a related cost, usually in productivity Java developers often make the comment that you can pay now or pay later That's strange, because Smalltalk and Ruby programmers rarely make lasting errors

related to incorrect typing Further, disciplined automated unit tests easily catch most type mismatch problems You've got to unit test your code whether you want

to or not, because no compiler can completely guess your intent

Most Java developers who tout the benefits of strong, static typing fail also to count the cost When you're learning or playing with a language, the cost is

excessive, because you have to declare everything, including a wrapping class, and learn a whole new level of detail Here's a "Hello, World" example in Ruby:

puts "Hello, world."

And here's the Java counterpart:

class HelloWorld {

public static void main(String[ ] args) {

System.out.println("Hello World!")

}

}

A Java program requires a rigidly typed class with a Main method The barrier to exploring in Java is simply much higher Most of the experts that I interviewed for this book recognized that static typing limits productivity for application

development dramatically, though some said they were willing to pay the cost for certain types of code, like systems code and middleware I think it's fair to assume that for applications development, productivity is important enough to warrant dynamic typing for Java's ultimate successor

5.4.2 Code Blocks and Continuations

The Java open source community now uses anonymous inner classes with greater and greater regularity When you need lightweight callback-style functionality, in Java the best way is the anonymous inner class Here's an example of JDBC-style access in Spring, with the anonymous inner class:

JdbcTemplate template = new JdbcTemplate(dataSource);

final List names = new LinkedList( );

template.query("SELECT USER.NAME FROM USER", new

RowCallbackHandler( ) {

public void processRow(ResultSet rs) throws SQLException {

names.add(rs.getString(1));

}

}

);

Here's a code block in Ruby:

dbh.select_all("SELECT name, category FROM animal") do |row|

names << row[0]

end

This code example executes the code in bold for each row in the result set, which is passed into the code block's row variable

For application programming, code blocks show up frequently Any time you need

to iterate through a collection, or a result set, or a file, code blocks come into play Keeping them simple saves you a tremendous amount of work

Continuations will also be important In Chapter 8, you will see how continuations dramatically improve productivity in web-based programming

5.4.3 Rapid Feedback Loop

Think of a feedback loop as the time between making a change and seeing the impact in running code New application development principles, like test-first development, work best with a fast feedback loop Small changes in the feedback loop can make huge differences in overall productivity, because you do it so many times every day With Java, you need to deal with at least a compile step, and you often add steps for code generation (XDoclet), byte code enhancement (JDO), and deployment (servlets and EJB) For Java, that means you must wait to see a source code change realized in executed code Developers tend to underestimate the

benefits of a small feedback loop, unless they're regularly using a dynamic

language and need to go back to a static language

Smalltalk, Lisp, Perl, Ruby, and Basic all have rapid feedback loops, and they're also incredibly productive languages C, C++, and Java don't In fact, Java might not have succeeded if its users had come from a dynamic language supporting a rapid feedback loop

5.4.4 User Interface Focus

More and more, I'm seeing experts that need to do significant user interface

development move away from Java Given the strong server-side focus of the past six years, that news should not shock any of us Still, the number of Swing experts who vehemently defend it, without trying a meaningful alternative, confuses me, like two Titanic passengers arguing over which deck is prettier as the ship sinks around them James Duncan Davidson said it best: "Friends don't let friends

Swing." User interface development demands more than Java has to give For most application developers, the framework should do much more for you

5.4.5 Dynamic Class Model

The Java successor should be much more dynamic, and reflective Java's reflection API is particularly hostile because it must deal with primitives , arrays, and classes Let's look at a Java example of reflection Here's a simple XML emitter provided

by Stuart Dabbs Halloway, courtesy of DevelopMentor:

public static void doObject(Object obj) throws Exception {

Class cls = obj.getClass( );

emitXMLHeader(cls);

Field[ ] fields = cls.getDeclaredFields( );

for (int i=0; i < fields.length; i++) {

Field field = fields[i];

field.setAccessible(true);

Object subObj = field.get(obj);

if (!Modifier.isStatic(field.getModifiers( ))) {

if ((field.getType( ).isPrimitive( )) ||

((field.getType( ).getNamxe( ) = = "java.lang.String"))) {

emitXML(field.getName( ), subObj);

} else {

doObject(subObj);

}

}

}

emitXMLFooter(cls);

}

I've omitted the code to actually emit the XML, but you get the picture Look

carefully at the lines in bold You had to deal with primitives a little differently, but I'm lucky, because for this particular problem, I can treat all primitives the same That's usually not the case I'm really not done, because I also need to deal with arrays, leading to a whole new level of complexity

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

5.4.6 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

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 encourage code that's clean and maintainable

Continuations The language should enable important higher abstractions like

continuations