Joe Walker - java tag

Big Question for Sun

Mon, 19 May 2008 12:35:45 GMT

It looks from the outside as though every spare resource that Sun has is going into JavaFX. JavaFX may or may not win against Flash/Flex/Air/Silverlight/Android/Ajax, but while Sun is concentrating on FX, it doesn't appear to be giving the Java language the updates it badly needs.

Maybe Sun sees Java as 'done'. OK, but the Java language has one of the largest developer communities in the world, and they'd like some direction. Where do Sun recommend they go for their server-side development needs in 5 years time?

Maybe Sun think we should change to JRuby, Scala or Groovy. Maybe there are updates to Java that I don't know about. If none of the above are the case, the community will eventually disappear into mish-mash of languages that doesn't have the strength of numbers.

3:19pm Update: tweaked last paragraph to make the point clearer.

App Engine and Java

Wed, 09 Apr 2008 19:49:56 GMT

The world is now split into Python programmers, making funny 'Goo' noises over App Engine, and everyone else who are wondering when/if this will be available in their language or if they are going to have to change their spots.

Of all the languages to support, I guess Java must be one of the hardest because of the heavyweight runtime and the difficulty in separating code. But it also makes sense because supporting Java might give you quick access to Ruby/JavaScript/etc.

I have no knowledge of if Google are going to support Java in App Engine, however there are some tea-leaves that can be stretched and rearranged to form a vague picture.

Some time ago Google hired Greg Czajkowski the lead of Project Barcelona from Sun. Project Barcelona was where Isolates (JSR-121) came from and the Resource Consumption API (JSR 284), both of which would help you do this sort of thing. And both of which are now in Final Draft stage.

I have no idea if this does mean that Google are working on App Engine for Java, but if they do I'm going to claim bragging rights for having blogged about this 18 months ago.

Comparing the Evolution of Java and JavaScript

Mon, 17 Dec 2007 13:19:28 GMT

Java:

Java is the most used language in the known universe. It is also a very simple* language. Some people believe that there is some scope in enabling Java to accommodate more programming styles (e.g. functional programming via closures). Others believe that being lightweight is a virtue.

JavaScript:

JavaScript is the most deployed language in the known universe. It is also a very simple* language. Some people believe that there is some scope in enabling JavaScript to accommodate more programming styles (e.g. by adding classical inheritance not just prototypal inheritance, and an optional type system). Others believe that being lightweight is a virtue.

Features:

It's interesting that the current simple version of JavaScript already has the features (i.e. closures) that people want to keep out of Java otherwise it will become too complex, and that Java already has some of the features (i.e. classical inheritance) that people want to keep out of JavaScript, otherwise it will become to complex.

Crossroads:

The Java language is challenged by languages such as Ruby, Groovy and even Scala, all of which support closures. The majority of people that have spent serious time with these languages prefer them over Java for at least some set of problems.

The JavaScript language is challenged by Silverlight. Microsoft try to avoid saying things like "death to Ajax", but secretly (or not so secretly depending on who you talk to) they would love to control the platform once more, and Silverlight is the latest attempt at regaining control.

Features vs. Complexity:

Joel noticed that there is a big difference between good developers and bad developers. Google noticed it with it's picky hiring process. On many projects there are a few developers that do all the real work, while others just slow things down.

But much of the "keep complexity out of the language" debate is aimed at helping the people that write less code anyway.

Nail-guns and angle grinders are dangerous tools, but the building trade accepts the danger in the name of greater productivity. In software development where the difference between good and bad developers is that much greater, and where developers don't actually get physically maimed, the argument for power over simplicity is that much stronger.

In summary, extra power helps smarter developers work more quickly, but makes life harder for less smart developers. Since a small number of smarter developers generally do better work than a large number of no so smart developers, we should tend slightly toward giving developers more powerful tools.

Java:

In Java, BGGA closures enable higher-order programming. It's hard to say that the addition of closures in and of itself would cause a complexity implosion, after all, Java is virtually the only modern day programming language without them. It could be argued that the Java language can't be evolved to accommodate them, but I'm leaning towards there being a net gain by including them.

Interestingly, Google Android contains a clean room re-implementation of Java. If Sun (or the JCP) accepts closures, and if (as seems likely) Google votes against them, what will happen to Android? Will it follow how Google votes, or how Java evolves?

JavaScript:

With JavaScript, people see a neat, compact language and fear it turning into Java. The good news is that it won't fully turn into Java because JavaScript already has closures and no one thinks they should be taken out ;-) The danger of the "features over complexity" argument, is that it can be applied indiscriminately, creating a monster, and the fear is that JavaScript will become a monster.

I'm gradually coming round to the opinion that many of the changes proposed to JavaScript actually reduce complexity. There are nearly as many frameworks that add classical inheritance to JavaScript as there are Ajax frameworks. Having one solution that we can all agree on can't be a bad thing even if you prefer prototypal inheritance.

*: For some value of simple. The exact definitions of simple used in these 2 paragraphs are not necessarily the same.

JVM Usage Stats

Mon, 16 Jul 2007 09:14:53 GMT

Often when you open an XML config file in a DTD/Schema aware editor, and you're connected to the internet, the editor will reach out over the net to fetch the DTD/XSD, which gives webmasters some interesting usage stats.

I've commented before on how you can use this technique to look at the big growth in DWR usage, but I noticed that you could also use it to suss out some JVM usage stats because when Eclipse etc come read the DTD they use the Java version number as their User Agent.

Anyway, the numbers:

Caveat - there are about a million reasons why this is un-scientific. It may be interesting to some though.

Aside: I wonder if Java should adopt the 'standard' formatting for the User Agent string that is employed by all major browsers?

Java 7 Idea: Extensible Strings

Tue, 10 Apr 2007 11:34:51 GMT

In some ways it's a shame that java.lang.String is marked 'final' in Java. If it wasn't final, you could inherit from java.lang.String to create strings that had some extra features, or you could extend with a marker interface to declare that a String has some property, for example it would be neat to be able to track if a String had been:

Checked for dangerous characters from the web
Internationalized
Processed by some system

Allowing marker interfaces like this could lead to some nice extra type-checking:

public SafeString checkForUnsafeCharacters(String s) {
  // do some checking and throw or create a SafeString
}

public void process(SafeString s) {
  // do something knowing that the developer can't forget
  // to check the string before it is passed in
}

Marker interfaces on strings can be a handy way to declare that this string has some properly that normal strings don't.

However there are at least 2 good reasons why java.lang.String is final:

Security: the system can hand out sensitive bits of read-only information without worrying that they will be altered
Performance: immutable data is very useful in making thing thread-safe.

So is it possible to have the best of both worlds - to allow marker interfaces and additional properties without breaking assumptions about the immutability of the string itself. And, is this possible without breaking backwards compatibility?

In Javas 1 to 6, java.lang.String is defined like this:

public final class String {
  public int length() ...
  ... // other methods and properties
}

I think we might be able to safely change this to:

public class String {
  public final int length() ...
  ... // everything made final
}

I don't think this breaks backwards compatibility anywhere because it mostly legalizes something that would previously have been a compile error, and the immutability of the core String is as unbroken as it was in Javas 1-6, although obviously the same guarantees could not be made about all extensions.

Declaring finality in this way allows marker interfaces, which might in some cases allow developers to create APIs that enforce some properties on strings that might previously have been forgotten.

Can anyone think of anything that I've overlooked?