January 9, 2009
If you have or plan an application with synchronous communications over an external API, it will sooner or later break. Why do we need asynchronous communications? Matt Tucker is clear about that:
Take, for example, Twitter. High Scalability recently covered the load stats on Twitter reporting that they average 200-300 connections per second with spikes that climb to 800 connections per second. Their MySQL server handles 2,400 requests per second! Recently, the [2008] Macworld keynote became the most recent culprit for causing Twitter to cut off its API, which has 10x the load of their website.
When one of my web pet projects needed a messaging backbone which extends to the browser. Whenever a resource did change on the server, all users watching the resource should get a notification without need to reload their browser. Two candidates are Javascript for ActiveMQ, which uses Comet
ActiveMQ supports Ajax which is an Asychronous Javascript And Xml mechanism for real time web applications. This means you can create highly real time web applications taking full advantage of the publish/subscribe nature of ActiveMQ.
ActiveMQ is a messaging bus, often used as an Enterprise Service bus as mentioned in my recent concurrency rant. Components can send messages to the bus and subscribe to topics.
photo credit: mudpig
The other unsuspected contender is Javascript for Jabber. Jabber with the XMPP protocol is usally used for sending chat messages. Comparing these two and my thoughts:
ActiveMQ
- Standard solution, JMS based
- Routing solutions like Camel available
- Easy access for different languages via Stomp
- Attach Jabber as a service
- Notification easily over topics
Jabber
- Free OpenFire server
- Messaging with only one user with UUID for resource which did change
- Messaging with many users, who join one chat room
- Chat rooms as topics
- Server side filtering? How to make it secure, that people only get their own messages?
In the end I decided to go with Jabber/XMPP. The main points for me have been:
- Server does scale to connections
- Chat client can be used for debugging
- Very easy to use with different programming languages
- Presence protocol to detect services
- Easy to implement additional chat solution
This worked quite well as a spike. I followed a similar mode as Adrian Sutton, who had good experiences with Jabber/XMPP too when spiking a cache solution:
We grabbed the Smack API and started playing with it and quickly discovered that sending and receiving messages was ridiculously easy. It turns out that the absolute simplest way you can minimize stale data in your caches is to simply have all the servers join a preconfigured chat room. Whenever they save a change to a resource they send a message to the room with the unique ID of that resource and whenever they receive a message from the room they assume it’s a unique ID and remove any cached versions of that resource.
Though I had some major problems accessing Jabber consistently from Javascript. With more on messaging in the backend, I would have went with ActiveMQ as a message bus. And perhaps I might move to ActiveMQ in the backend and then I’m still free to attach Jabber on top of that and keep the frontend code. Best from two worlds.
Think innovative, use technologies in a way to help you. Jabber/XMPP is more than a chat protocol.
December 22, 2008
People talk a lot about concurrency. With the rise of multi-core processors, concurrency becomes more important. It’s sad that developers don’t know much about concurrency - and most of them just parrot what they have read in other blogs. I wanted to write this post for quite some time to shed more light into concurrency.
There are mainly two different types of concurrency
- One Task, many workers: For example parallel Fibonacci Numbers
- Many Tasks, many workers: For example web requests
They have two different characteristics:
- First: Need to share data
- Second: No need to share data (or “not to share in real time”)
Most people think of the first kind, when they discuss concurrency. Although most applications are of the second kind. I wish people would not confuse those two and try to fix the second problem with their solutions, because the second problem is solved sufficiently (think FaceBook). So this post will only discuss the first type of concurrency.
The breakthrough for concurrency of the first kind came with threads and the synchronizd keyword in Java 15 years ago. Before that concurrency was an esoteric topic for niches, with Java it became a topic for every developer. Today most people recognize that threads and synchronized are too low level though and create quite some problems if you don’t know what you do. One half of the blogosphere damns Java for this and favors Erlang style concurrency: Message passing between objects, each object has an inbox (a queue) of messages which it works through and objects send messages to the inbox of other objects, where messages are immutable. The benefits are clear: No shared state, no need to regulate the access to shared state and the freedom to implement the scheduler of the objects the way it works best (not being limited to thread libraries).
This half proposing Erlang over everything usually doesn’t know what the other half does and think they still use synchronized. But this is only the most basic technique (and not even the best basic one with the advent of atomics). Surprise, enterprise Java developers don’t use threads (directly) and synchronized. I’ll tell you what they do.
There are lots of better methods for concurrency nowadays like Futures, Executor Services and especially Doug Leas Fork/Join framework in Java JSR 166y. The FJ framework splits a task into subtasks, distributes them, solves them and joins the result (in a very clever way with queues which are written on one side and read on the other and tasks which can steal work from others). The algorithm for forking and joining looks like this:
Result solve(Problem problem) {
if (problem is small)
directly solve problem
else {
split problem into independent parts
fork new subtasks to solve each part
join all subtasks
compose result from subresults
}
}
As an example to calculate Fibonacci numbers:
class Fib extends FJTask {
static final int threshold = 13;
volatile int number; // arg/result
Fib(int n) { number = n; }
int getAnswer() {
if (!isDone())
throw new IllegalStateException();
return number;
}
public void run() {
int n = number;
if (n <= threshold) // granularity ctl
number = seqFib(n);
else {
Fib f1 = new Fib(n − 1);
Fib f2 = new Fib(n − 2);
coInvoke(f1, f2);
number = f1.number + f2.number;
}
}
}
(you can use threads or a different scheduler for this to work)
A similar approach to concurrent work is MapReduce as implemented by Hadoop. It also splits work into sub tasks, does a mapping step for transforming data and then reduces the result. It works best for data crunching and reducing input data to output data.
Other techniques developers often use instead of concurrency primitives are communication abstractions, like communicating over concurrent access queues, for example java.util.concurrent.ArrayBlockingQueue (ah queues again! or call them inboxes).
Threads talk to each other by adding (hopefully immutable) messages to a queue. Sounds familiar? Those can even be distributed (also see Hazelcast for distributed queues). This is very similar to Erlang concurrency, just imagine input queues for all your workers, aka actors.
Scala has an Erlang like message passing actor concurrency implementation. When looking into the Scala code, Scala uses the Fork/Join Framework of Java, the cirlce closes. And Scala uses different schedulers for it’s implementation with one thread per actor only being one option.
We can abstract concurrency even more. Jonas writes an excellent piece about abstractions on top of actors in a piece about fault tolerant, Asynchronous concurrency but misses one crucial point:
Actors can simplify concurrent programming and reasoning immensely and I believe that Scala Actors is a key piece in the future Java concurrency puzzle. However, programming with actors and with explicit message passing and message dispatch loops can feel a bit unnatural and unnecessary verbose for Java developers that are used to regular OO method invocations and synchronous control flow.
As pointed out before, people use queues and are used to work with asynchronous flows. Java enterprise developers in particular as they use Enterprise Service Buses (ESBs). There are many implementations like ServiceMix, OpenESB, Camel, OpenMQ, ActiveMQ, Mule and others. They range from pure message buses to routing and integration solutions. Because ESBs are fault-tolerant, asynchronous concurrency, the developers who use them know about asynchronous flows. Companies like LinkedIn uses ESBs to distribute tasks in a fault tolerant and parallel way. Nothing new there. Java developers think in asynchronous messaging already.
Stand back a thousand feet and ESBs look like the Erlang model. Worker cling to the bus and wait for work. Each is listening to different messages, the waiting messages for each worker are a virtual input queue similar to Erlang. There isn’t as much difference between concurrency in different languages as people want you to believe there is!
As a final word: It’s interesting that the first and second kind of concurrency start to merge. With applications like Twitter or identi.ca, the second type is sometimes becoming the first type of concurrency because different requests need to share data with each other (hopefully you don’t use the database for this as Twitter did in the beginning). One can argue that more and more applications need to share data between sessions. You can use an actor model for this (Lift does this). You could use ESBs. Or you could go a very different way with distributed method calls and objects - Terracotta to the rescue.
Thanks for listening. Hope you’ve learned something. I did by writing this post. As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled).
Update: Actors Guild for Java looks also interesting
Update 2: If you find this post offending, go back read it again without you favorite programming language in mind which you need to defend. There is nothing to defend. You’ve chosen the programming language to the best of your knowledge, as have others (and if they haven’t but just chose the language because of some hype or others told them to, well, not a good idea). Spread your knowledge, don’t feel offended. Be happy if others find solutions to their problems. This is not some kind of football game which you win if you gain enough points against a different language. If the other one is better, use it. If not then don’t. Sounds awfully common sense, but we sometimes seem to forget this. Merry xmas.
December 18, 2008
Thanks to all of you for following. I do my best to write interesting - somtimes provoking - blog posts to keep you interested and amazed how wonderful software development is :-)
The Feedburner stats which describe your rising following:
(as people asked: The jump was on October 1st, from 481 to 674, there was no jump in the Google analytics visits for that time frame, the second jump was on October the 27, I’ve looked into it and the jump came from the time where the website was slashdotted by my 6 reasons why my startup failed story on Reddit)
May 9, 2008
From the category “Bending Java near it’s Breaking Point” or “What a stupid but interesting idea”. I like to explore ideas in Java that are inside the language spec but outside of common usage or style guides. I think Java has a lot more to give than what people did the last ten years. Before dumping Java perhaps we should reconsider some of the “common wisdoms” about how to do things in Java.
My last post on beautiful Java, and why to never use String ;-) got me flamed like I haven’t been flamed since alt.amiga.advocacy times. The idea was to provide wrappers around String like Name to achieve several things: Have better typed method signatures, have a fluent interface and to better convey meaning.
Customer customer = new Customer( name("Stephan") );
...
Customer(Name name) {
...
}
...
public Name name(String value) {
...
}
The flames were mostly about creating lots of small objects, which people claimed are unnecessary and unmaintainable.
An alternative implementation would be:
Customer customer = new Customer( name("Stephan") );
...
Customer(String name) {
...
}
...
public String name(String value) {
return value;
}
This implementation doesn’t achieve the same things as the solution before, but there is no new object necessary, only a new method.
But still the line Customer customer = new Customer( name("Stephan") ); is more readable than Customer customer = new Customer( "stephan" );. The Hotspot JIT should optimize the method calls away so there is no performance penalty.
A better idea? Or still too repulsive.
Thanks for listening.
As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled). This line is shamelessly take from Daniel Tenner, who writes a really excellent blog.
April 22, 2008
I haven’t been using the final keyword in Java for 10 years, but more and more I think it’s an excellent keyword in Java. All local variables should be declared final. Today one of the developers of my team made every local variable in a method final and I was wondering how strange that looked. But of course it was the right thing to do. Declaring all variables final will lead to less bugs (logic and typos e.g.).
public void doSomething(final input) {
final result = calc(input);
}
If you reassign a variable you most probably do something wrong. I’ll bet if you reassign a variable your method does at least two different things though every method should only do one thing. As should a class. Final also goes for method parameters, all should be final. Others think so too even for methods.
How do you deal with final attributes? When making most attributes final, just initialize them in the constructor. Immutable objects also play nicely with Tell, don’t ask.
All these final keywords around your code create noise though. It would be best to have all variables automatically be final and have a new transient keyword for reassignable variables. Or at least for my IDE - Intellij IDEA - to hide the final keyword and write the variable in a different color. Hear me IDEA developers!
Update: After some more work with Scala, var and val are a good solution.
April 4, 2008
Generating JSON and XML with the same code is difficult. One can create the semantically richer XML and convert it to JSON, but JSON notations for XML like Badgerfish look quite ugly to JSON advocates.
The problem at the core is that XML is typed whereas JSON is not. Every node in XML needs a type - it’s name - for example <item><id>123</id><item>. JSON doesn’t need such a type, { id: 123 } is fine for an item. { item: {id: 123}} looks too verbose. Especially getting to the data in Javascript: var id = item.item.id. The same goes for accessing arrays with var id = items[0].item.id; instead of var id = items[0].id;. The problem exists with other dynamic languages and data structures too, see Cobra vs. Mongoose for Ruby.
As I currently develop a REST based Jersey application in Java I needed a way to generate lean JSON and XML. Wouldn’t it be best to have one code for both? DRY. My previous solution for generation JSON worked fine. The $(...) method calls create a node tree with nodes and lists. With a JsonRenderer and the Visitor pattern I generate JSON from the node tree. The problem was that this Java code
$(
$("id", listId),
$("items",
...
)
);
creates nice JSON like { id: 123, items: [ ... ] }, but was unable to generate XML. As written above, the outer list has no type and a XmlRender therefor cannot render <shoppinglist><id>123</id>...</shoppinglist>.
The solution I thought about is to add type information to nodes which have no names.
$( type("shoppinglist"),
$("id", listId),
$("items",
...
)
);
The implementation uses a simple static method and a Type class.
public static Type type(String name) {
return new Type(name);
}
The type is attached to the node and if the node has no name but a type, the XmlRender uses the type instead of the name. The JsonRender doesn’t use the type information and renders the same JSON as before. The piece of Java code now generates XML
<shoppinglist>
<id>123</id>
<items>
<item><id>234</id><price></price><shop></shop>
<description>Apple</description></item>
<item><id>233</id><price></price><shop></shop>
<description>Banana</description></item>
</items>
</shoppinglist>
and lean JSON where neither shoppinglist nor item has a type
{ id: "123", items: [ { id: 234, price: "", shop: "", description: "Apple"}, { id: 233, price: "", shop: "", description: "Banana"} ]}
Next thing is to automatically apply the right renderer, toXml and toJson from within Jersey. The content negotiation then choses the accepted format for the client. Attributes (Meta-Information?) are not solved yet and I’m not sure if they are needed, or how to nicely add meta information to the $(...) tree. There is some discussion in the context of markup builders and attributes on James blog.
Probably the code will be released as an open source RESTkit if someone is interested.
Thanks for listening.
January 24, 2008
When browsing and reading code, I often find this:
Date currentDate = new Date();
Someone needs a current date. The line is unclear what the developer really wanted to achieve. Does he want the current date or the current time? The Date class in Java is ambiguous: “The class Date represents a specific instant in time, with millisecond precision. ” and therefore should probably be called Time with Date only representing a day (the better named Time class resides in java.sql, ugh, one of the ugly decisions in Java).
Better name your variables with more meaning. Make your intentions clearer and use Calendar, which is more useful when working with dates[1]:
Calendar today = today();
Date now = now();
The implementation looks like this (use static imports) [2]:
public static Calendar today() {
return Calendar.getInstance();
}
public static Date now() {
return new Date();
}
Please, make your code more understandable for all the developers who follow you.
[1] You probably want to use Joda Time
[2] I know, Calendar stores the time also
January 21, 2008
I’ve recently started to read the best book on object oriented programming. There are other good books that deepen your understanding of OO like “Refactoring” and “P of EAA” from Fowler, “Design Patterns” from the GoF, the McConnell books, “The Pragmatic Programmer”, the OO books from Robert C. Martin and some others. All recommended to read. But the best I’ve read on OO in the last 15 years is Domain Driven Design from Eric Evans. There are a lot of deep insights about how to build your domain model and structure your objects and classes in that book. Highly recommended.
January 9, 2008
Qi4J is the new kid on the block. Forget Scala (not although but because Bruce Eckel, the author who switches hypes faster than other people switch their underware, declares Scala to be the next big thing). Scala helps you solve CS problems nicely, but not business problems. Qi4j is about composite oriented programming. It’s designed to solve business problems. One of the brains behind Qi4J is Rickard Öberg, the brain behind JBoss. He is one of those geniuses who know that their cleverness hasn’t anything to do with the language they use. Other devlopers think that the tools they use make them into a genius (by association) and dismiss Java in favour of Ruby or Lisp or OCaml or Haskell or Lua. Some even think that Java spoils you for everything. What?
Another of those geniuses is Bob Lee, about whom I said in my Sourcekibitzer interview: “He wrote Dynaop, the best AOP for Java, Guice and now is part of the promising Web Beans project. A very friendly and extremly clever guy - swimming outside the mainstream with better ideas until all others get it too ;-) His style of coding looks aesthetically very pure to me and I like it very much.”[1] I guess the same thing could be said about Rickard.
Back to Qi4J. Why could Qi4J be the next Java? Qi4J tries to solve one of the holy grails of computer science: reuse. Their goal is to create applications by composing, not by writing code. Their solution is to decompose Java objects into fragments. This happens in two dimensions. Horizontally objects are decomposed into mixins. Vertically objects are decomposed into mixins, concerns, constraints and side effects. By splitting a Java class into much smaller fragments with specific roles they hope to increase the reuse of those fragments. So one does no longer write code but compose those fragments into bigger composites.
- Mixins: Containing state, e.g. Name, Person, Adress
- Concerns: Statelessm e.g. TransactionWrapper, Security
- Constraints: Checking parameters, e.g. NotNullConstraint
- SideEffects: Managing side effects, e.g. sending Mail
An example for a PersonComposite could look like this:
@Concerns({Security.class, Transaction.class})
@SideEffect({MailNotification.class})
public interface PersonComposite
extends Person, Name, Adress, Composite
{
}
The PersonComposite is build from a Person (handling e.g. gender), a Name (handling firstName and lastName) and Adress (handling street). The extension of Composite doesn’t look that nice, perhaps they change this in the future. A developer can now use PersonComposite and call getFirstName() and getLastName() on the composite. If he creates an Employee class he can compose it the same way and reuse Name. For storing a House he can reuse Adress.
Qi4J provides standard fragments like a PropertyMixin. With this mixin your Name only needs to look like this:
public interface Name
{
public void setName(@NoEmptyString String name);
public String getName();
}
and Qi4J will fill in the actual state-handling code.
Why is Qi4j probably the next Java? Java is an enterprise language. It solves enterprise problems best (technical, deployment and organisational/ socialogical problems). Other languages solve time-to-market-VC-funded-startup problems best. Still other languages solve computer science problems best. The next language needs to solve my enterprise problems better than Java does, which means fixing Javas holes. One hole is reuse, one is tight coupling, one is dependencies. JavaNG needs to solve those. Does Qi4J help? I might think yes. It has nice ideas and adresses some of the Java problems I have in the enterprise. If DDD takes off, Qi4J or frameworks like Qi4J will take off too.
Qi4j has lots of other goodies I’ll explore in another post.
Thanks for listening.
[1] Beautiful code doesn’t depend on the language. I like modern art. I can see beauty in modern art. Not in all, but in some. I’ve argued with a lot of people who do not see beauty in modern art. Those people believe only using oil on canvas drawing people can create beauty. The same goes for the argument that you need a special language to write beautiful code. You do not. I believe there is beautiful Cobol code around. And I wrote such beautiful programms in 68k.
December 4, 2007
I wrote about fluent interfaces for several times. A comment on my best MarkupBuilder in Java try pointed to a fluent inteface for JAXB. Excellent, thanks Hristo.
November 30, 2007
Using Groovy MarkupBuilders spoiled me for other ways to create HTML pages from code. Others think the same. But in some organizations you have to use Java and can’t use Groovy - at least when you can’t sneak it in.
So I tinkered around in Java to see what’s the best MarkupBuilder I can write with Java. Using DSLs and Fluent Interfaces (times(5).loop), I came up with a nice solution. It’s not Groovy, but it works.
Page page = page(
html(
body(
// A comment
h1("Name games"),
p("Hello ${coolName}, and hello", "id:${id}"),
ul(
new Loop("stefanie", "${name}") {
protected Element each(String item) {
return li(item);
}
}),
loop("[${number}] ", "number", 1, 2, 3),
text("..."),
box("Warning private!"),
p("Are you dynamic?"),
// Some dynamic content
new Action() {
protected String with(Context context) {
return "I'm dynamic, " + context.get("name") + ".";
}
}
)
)
);
There are some tricks to make it better than most such Markup Builders in Java. I tried to use ideas from building DSLs in Java. Those are using static imports and varargs. The body, html and other elements are static imports from a MarkupBuilder class.
public static Element body(String body) {
return new Element("body", body);
}
public static Element body(Element... elements) {
return new Element("body", elements);
}
...
The varargs helps with adding a variable number of childs to an element:
h1(
p("One"),
p("Two"),
p("Three")
);
Another problem is how to put object values into the generated markup. String concatenation leads to noisy code
"Hello " + name + "!"
so I decided to use a expression language where the Java unified expression language comes to mind. There is an open source version available called JUEL. Now I can use
"Hello ${name}!"
Attributes are also treated as expressions and seperated by commas, their names and values seperated with a colon.
p("Hello ${coolName}, and hello", "id:${id}, class:list"),
Loop and Action classes allow for dynamic content.
ul(
new Loop("stefanie", "${name}") {
protected Element each(String item) {
return li(item);
}
}),
I’ve used the template design pattern for this, again with expressions, in a way Spring provides JDBC templates. Another nice idea is with static methods it’s also easy to develop custom, semantic tags, so the developer doesn’t need to know or see the actual HTML markup which is created. For example I used a box “tag” which translates to
public static Element box(String text) {
return div(
p(text)
);
}
Closures in Java 7 will make it much easier to write a MarkupBuilder. The Action and Loop inner classes will go away and the code will be more Groovy like. When they add syntactic sugar to create maps I can drop the “name:value, name:${value}” style for attributes and move to [ "name" : value, "name": value ] instead, which doesn’t need the EL to work. With some small things to add the MarkupBuilder can be used for JSON or XML.
I’m interested and open to all techniques and ideas to improve the markup builder.
Thanks for listening.
November 23, 2007
When reading about reflection on the beautiful code website I thought about solving some problems with reflection and finding new solutions to old problems. One problem is boring code when writing a copy constructor. A copy constructor is a constructor which takes another object and copies it’s attributes. This is often useful when copying objects or moving objects to different system layers. One example would look like this:
public class Employee {
public Employee(Employee other) {
this.name = other.name;
}
}
There are some pitfalls, especially that you only create shallow copies. And there is always clone() and Serializable, which can also be used to create deep copies without such pitfalls. JBoss provides a fast implementation of this technique. But often copy constructors are quite useful if you’re careful and know what you do. I recently had a discussion on how to support domain objects in different parts of a system. One part might call an entity Employee, another part might call it Person. To make them talk together you can either create a composite, an adapter, a wrapper or use a copy constructor (or find a different solution). In such a case a shallow copy is all you want, because the new object should have the same “identity” as the first and not be a copy.
public class Employee {
public Employee(Person person) {
this.lastName = person.getLastName();
this.name= person.getFirstName();
}
}
This should be easier to implement. Copying bean attributes for large objects isn’t much fun, leads to long constructors and unmaintanable code. What about changes in Person? New attributes? So I tinkered with Java reflection and ended with this:
public Employee(Person person) {
BeanCopier copier = new BeanCopier();
copier.copy(person, this, "name:firstName", "age:");
}
I’ve written a BeanCopier which can - well you guessed it - copy beans. The syntax is easy to learn. A BeanCopier has a copy method which takes a source, a copy and the attributes which should be specially handled. By default all attributes which have the same name and type in source and copy are copied. But if they have different names, like name and firstName, you need to specify “name:firstName”. If a property shouldn’t be copied, you can specify “property:” without a target attribute.
The copy method looks like this (the generics are not needed but I was also tinkering with caching where it was quite handy):
public <T, U>void copy(U source, T destination, String... attributes) {
if (destination.getClass().getName().equals(source.getClass().getName())) {
// copy all fields
} else {
// copy all bean properties
try {
BeanInfo sourceInfo = Introspector.getBeanInfo(source.getClass());
PropertyDescriptor[] sourceDescriptors = sourceInfo.getPropertyDescriptors();
for (PropertyDescriptor descriptor : sourceDescriptors) {
String name = descriptor.getName();
if (!"class".equals(name)) {
String attribute = this.find(attributes, name);
if (attribute == null) {
copyAttribute(source, destination, name);
} else if ((attribute.indexOf(':') >= 0) && !attribute.endsWith(":")) {
int colonIndex = attribute.indexOf(':');
String sourceName = attribute.substring(0, colonIndex);
String copyName = attribute.substring(colonIndex + 1);
copyAttribute(source, destination, sourceName, copyName);
}
}
}
} catch (IntrospectionException e) {
e.printStackTrace();
}
}
}
and the copyAttribute method:
private void copyAttribute(Object source,
Object copy,
String sourceName,
String copyName) {
PropertyDescriptor writer;
PropertyDescriptor reader;
try {
writer = new PropertyDescriptor(copyName, copy.getClass());
reader = new PropertyDescriptor(sourceName, source.getClass());
Object value = reader.getReadMethod().invoke(source);
Class sourceType = reader.getPropertyType();
Class destionationType = writer.getPropertyType();
if (sourceType.getName().equals(destionationType.getName())) {
writer.getWriteMethod().invoke(copy, value);
}
}
The code is rough but works. The type test can be improved to work with super types.BeanCopier can be used outside of constructors, often a wise choice. And be careful with “copying” other objects, you might only create a shallow copy.
Of course, I could have taken a look at commons BeanUtils, but isn’t it much more fun to tinker and find a nice solution yourself sometimes?
Thanks for listening.
November 5, 2007
Lots and lots of people lament the explicit type system in Java, either they are dynamic ducks or inference intellectuals. Taken from the Boo manifesto:
“Nothing more tiresome than writing the same type name over and over just to make the compiler happy. I’m not talking against static typing in general (boo is statically typed), I’m talking against being coerced by a tyrannical compiler to say things it should already know.”
Beside the fact that my IDE does the typing with auto completion - of course the compiler knows - DUH. But the developer does not know. The developer who wrote the code does know, for about a month. When not working with the code for some time or another developer taking over - then is where the problem rises it’s head. Explicit Static Types are not for the compiler, but for the developer.
def person = Factory.getPerson()
Is person of class Person? Or perhaps Student or Employee? I’m wading through legacy code and the first thing that gets out is correct naming. What once was a person soon gets a Human. How should I know? Explicit typing is writing documentation. Not helping the compiler.
Some people claim explicit types increase lines of code. I can’t see how:
def person = new Person()
versus
Person person = new Person()
There are other things in Java that increase lines of code. Not explicit types. If I had some whishes free, I’d opt for properties and getting rid of unnecessary getter and setters, I’d like to have constructors with named parameters like in Groovy, I want syntactic sugar like [] and [:] for list and map creation, I want all attributes public unless declared private, all methods public unless declared otherwise, I want to drop the “;”, remove unneeded (cast)s where I declared the type explicitly and I wish for closures. But drop explicit types? NO!
My style of programming uses lots of interfaces. A class usually has several small ones and I try to narrow down a class to the interface I use. Narrowing down an object reduces coupling and increases reusability.
public class Person implements Nameable {
private String name;
public String getName() {
return this.name;
};
}
...
Nameable nameable = new Person();
printName( nameable );
Can I do this with type inference? What about
List persons = new ArrayList();
I guess type inference doesn’t help you here, coding against an interface and coding against more abstract entities as proposed by Robert C. Martin is out of the window. With type inference and without explicit types your code will depend on the concrete implementations, not the abstract definitions (or not depend on anything, which depends on your view ;-) Explicit typing is about reducing scope, knowledge and coupling.
Conclusion: Explicit types help the developer and create better, more understandable, more readable and more reusable code.
Sidenote to ducks: People claim that while they need 95% test coverage for dynamic code to find typo bugs, with explicit types the compiler gets the bugs for them:
“We discovered that anything shy of 95% code coverage with Rails means that type-os turn into runtime failures. We do not have any code coverage metrics for the lift code, but we have seen only 1 defect that’s been checked in in the 2 weeks since we started using lift.”
Thanks for listening.
Update: Jari wrote something about types inference, scala and IDE annotations on his blog.
November 3, 2007
Reading the post Searching Jars Redux on the “Code To Joy” blog, where Michael shows a closure Example in Java iterating through Jar content, saying ” old-style Enumeration, don’t blame me or closures!” about some ugly code using an Enumeration. It would be nice to just use for to iterate over an enumeration. This can be done easily. You can use Enumerations with the Java 5 for syntax when using a little Adapter around an Enumeration.
public static void main(String[] args) {
Vector<String> vector = new Vector<String>();
vector.add("Stephan");
for (String name : iterate(vector.elements())) {
System.out.println("Name: " + name);
}
}
public static <T> Iterable<T> iterate(Enumeration<T> enumeration) {
return new IterableEnumeration<T>(enumeration);
}
The IterableEnumeration is quite easy to write:
public class IterableEnumeration<T> implements Iterable<T>, Iterator<T> {
private Enumeration<T> enumeration;
public IterableEnumeration(Enumeration<T> enumeration) {
this.enumeration = enumeration;
}
public Iterator<T> iterator() {
return this;
}
public boolean hasNext() {
return enumeration.hasMoreElements();
}
public T next() {
return enumeration.nextElement();
}
public void remove() {
throw new UnsupportedOperationException();
}
}
Together with static imports and a static iterate method, the Java code looks much nicer.
Go for more beautiful Java.
Thanks for listening.
