Peter Williams

Stephen O’Grady and Tim Bray have been having an interesting conversation about how the Java, and the JVM, relates to the LAMP stack, and dynamic languages in general. Dynamic languages are a subject close to my heart so I want to toss in my two cents.

On the ubiquity issue I am with Mr. O’Grady here, except, perhaps, that I will go a little further. I think that the JVM is in a lot fewer places than most Java advocates do. It is true that you can get JVM for just about any platform, but it is also true that you can get a Ruby or Python interpreter for just about any platform. Ubiquity is a function of how many people use a technology not the other way around and PHP, Perl and Python are just as ubiquitous as Java, if not more so.I really wish I could say this about Ruby, but I just can’t. Yet.

I have only used Jython a little bit but I recognize the frustration Mr. Sequira describes. I found it quite disconcerting to be working in an environment that was, at the same time, both, and neither, Java and Python. Particularly for the conceptual types that both languages support. For example, if you call a method that returns a string having to figure out whether it is a Python strong for Java string is just annoying.

The threading issue is the one that interests me the most. I think that Mr. Bray is right that hardware threading is quickly becoming an important issue. In the near future most machines will support significant levels of true, hardware level, concurrency. But I think the shared memory native threading model that Java has is completely untenable.

Even vm (green) threads, which are well understood and have nice uniform semantics are difficult to use correctly. Once you throw in the vagaries of native threads you have morass of complexity that is practically unbearable. Worst of all, the usefulness of most of the techniques we have to help manage software quality, like automated unit tests and continuous integration, are inversely proportional to the number of threads in the application.

The most important thing to keep in mind here is that, in the long run, it is always better (read: cheaper) to use extra computing resources to make problems more tractable for the humans in the system. For example, we have garbage collectors because it is cheaper to buy a slightly more powerful computer than to have you developer waste time managing their own memory. I am not sure what the best solution to highly concurrent hardwareThe Cincom Smalltalk guys think that green threads and multiple processes are the best solution and they might be correct. I have my doubts but I do think it works better than Java’s native threads approach. is but I am quite positive it is not Java style threading. My gut tells me that none of the approaches I know for apparent concurrency are going to work well for a highly concurrent application on highly concurrent hardware. If that is the case we will see something new and differentI am guessing new and different will not from from Java-land because it Sun is looking very risk averse with regards to the Java spec right now. For example, they appear to have gutted Java generics with erasure, just to maintain backwards compatibility as soon as the cool hardware gets into circulation.

It does feel broken that there are so many bits of code written in different languages that do the same thing. However, the JVM is not the One True Platform on which to solve that problem, if, indeed, it even is a real problem. The JVM appears, from a my layman’s point of view, not to be well suited to dynamic languages. Even if it were technically well suited the culture around Java and the JVM is far too static to support the experimentation need to find new and better ways to deal with the complexities of highly concurrent environments. I think, for the most part, dynamic languages need to stay off the JVM.