Jobs: "Nobody uses Java anymore"

I've been going through few weeks worth of the Apple's java-dev mailing list posts, and noticed one that referenced a David Pogue column in NYT from two and a half weeks ago that itself quotes an interview with Steve Jobs centered on iPhone. When Jobs is asked about Java support on iPhone, he says:

"Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain."

This is worrisome. Jobs didn't explicitly reduce the scope of his statement to iPhone and/or mobile phones in general, although since the interview itself was about iPhone, one can give him the benefit of the doubt and assume the "Nobody uses Java anymore" doesn't apply to the computing world outside the mobile devices and won't affect availability of JDK on Mac OS X in the future. (Which, by the way I do find a bit lacking - JDK/JRE on Mac OS X is still stuck at 1.4.2_09 and 1.5.0_06, while the Linux/Solaris/Windows crowd has long since moved on to much higher service releases.)

Actually, as far as mobile devices are considered, I can agree with Jobs that on them Java is indeed "heavyweight ball and chain". John Carmack writes on his blog about difficulties writing DoomRPG and Orcs&Elves for mobile devices using Java here and here, preferring to use BREW as its alternate development platform, with most memorable sentence being:

... it isn't that BREW is inherently brilliant, it just avoids the deep sucking nature of java for resource constrained platforms...

and:

The biggest problem is that Java is really slow. On a pure cpu / memory / display / communications level, most modern cell phones should be considerably better gaming platforms than a Game Boy Advanced. With Java, on most phones you are left with about the CPU power of an original 4.77 mhz IBM PC, and lousy control over everything.

So yes, Java on mobile devices is a frustration. I still wished Jobs didn't make an overly generic statement...

Intel announces 45nm transistor technology

The New York Times reports that Intel has announced new technology for building microprocessors that replaces the "silicon gate electrode on a silicon dioxide insulator" design. The new technology uses a metal gate electrode on a hafnium insulator, eliminating much of the current leak that was the major obstacle in going below the 65nm technology. The new technology promises faster, more energy efficient processors, keeping up the Moore's Law. Intel plans to begin making microprocessors with the new technology as soon as the second half of this year.

To quote the NYT article:

Company researchers said the advance represented the most significant change in the materials used to manufacture silicon chips since Intel pioneered the modern integrated-circuit transistor more than four decades ago.

Also:

“This is evolutionary as opposed to revolutionary, but it will generate a big sigh of relief,” said Vivek Subramanian, associate professor of electrical engineering and computer sciences at the University of California, Berkeley.

I wonder whether this'll break the industrial trend of introducing ever more cores in a single CPU chip. My bet is that it won't, but it might allow software developers to get away with writing concurrency-unaware applications for a bit longer (not that I welcome that) if Intel can now indeed again make advances in CPU speeds.

"Clean coal" technologies being researched, says EU Energy Commisioner

Andris Piebalgs, EU's Energy Commisioner said in a speech at the eBio General Assembly yesterday:

From the point of view of security of supply, coal is a wonderful source of energy. Europe has plenty of coal; outside Europe, reserves are spread widely. But the greenhouse gas performance of coal is worse than that of any other fuel.
"Clean coal" technologies are being developed to solve this problem. We will accelerate research into these technologies, and take other steps to create a market for them. But there is no chance of their making a significant contribution by 2020.

That's interesting. EU is under a rather heavy pressure to lessen its energy dependency on oil and gas from Russia, and living in a country that got some collateral damage from the last muscle flexing of russian energy monopoly I can completely understand that. But going back to coal burning, hoping that its ecologically disastrous side effects can be eliminated by some not-yet-existing, but presumably researched "clean coal" technologies is a bit worrisome. I mean, as far as I know, you just can't burn coil without getting CO2, since "burning" by definition is "oxydating". At best, those "clean coal" technologies might try to somehow further process that CO2, instead of emitting it into the environment. I'm admittedly a bit skeptical about it, but I definitely welcome any sufficiently rigorous scientific research into the issue.

Java puzzler: field hide-and-seek

Someone recently asked me to explain the rules for field access in Java, and it sparked the little test program you see below. Can you guess the number sequence it prints?

class Class1 {
   String data;
    
    Class1(String data) {
        this.data = data;
    }

   String getData() {
        return this.data;
    }
}

class Class2 extends Class1 {
    String data;

    Class2(String data, String superData) {
        super(superData);
        this.data = data;
    }
}

public class Test {
    public static void main(String[] args) {
        Class1 obj1 = new Class1("1");
        Class2 obj2 = new Class2("2", "3");

        System.out.println(obj1.data);
        System.out.println(obj2.data);
        System.out.println((false ? obj1 : obj2).data);

        System.out.println(obj1.getData());
        System.out.println(obj2.getData());
        System.out.println((false ? obj1 : obj2).getData());
    }
}

It goes to show three interesting things (which are perfectly logical, we just don't think about them often):

• compile-time type of the ?: expression is the most specific common supertype of the compile-time types of its two target subexpressions,
  
• selection of target type for field access happens at compile time (no "virtual fields" in Java),
  
• compile-time type of "this" expression is the class that declares the method,

Remember folks, avoid both field hiding and direct access to fields in the first place, so your code doesn't become a puzzler :-)

What did D'Anna see?

(Listening to the BSG Season 2 soundtrack CD as I write this, of course. Package from Amazon arrived yesterday, woot).

Might as well dedicate another post to BSG... I'll admit it feels a bit strange to discuss a plot of a television series here (actually, it feels strange for me to be this enthusiastic about any TV show) but the thing is that this particular damn show actually provokes thoughts, touching with very good sense upon questions ranging from politics to religion to ability of nonhuman beings (I'm avoiding the term "artificial intelligence") to have what unsettingly resembles human minds - sentient, free willed, emotional, even religious.

Anyway, if you didn't see the last BSG episode, "Rapture", you might as well stop reading now, because it won't make any sense to you then.

In the last episode, D'Anna supposedly saw the faces of the last five cylon models in the temple of the Jupiter during the supernova breakout before she died her current body terminally malfunctioned. But did she really see them?

I have a suspicion that as much as it seems so on the surface of it, she actually didn't. If you remember, the Leoben instance that Adama encountered at the weapon storage station in the series pilot mentioned that his nervous system is negatively affected by the electromagnetic activity in the cloud that surrounds the station. I can only imagine how can an ongoing supernova breakout affect the nervous system of a humanoid cylon exposed to it standing on the surface of a nearby planet. So, yes, it might as well be that D'Anna hallucinated as a mental malfunction (and later physical too) caused by the supernova burst and just saw what her subconscious (assuming they have an analogous layer in their psyche) wanted her to see.

Further supporting this claim is that the other cylons don't think much about D'Anna's messiastic fixation and pragmatically only see it as a danger to their common goals. Also, thinking outside of the story, I see that the series writers don't stack unsolved mystery upon unsolved mystery as a means of driving the plot forward (fortunately, unlike Lost's writers, who pretty much seem to be lost in the plot, and definitely lost me as a viewer - pun fully intended), and in accordance to this, nothing else even hints that her mystical beliefs could be true. Well, except that the location where she saw the last five in her vision was the same location Baltar saw in his vision on Kobol at the end of season one. This could be explained if the location is something buried in minds of all cylons, and either Baltar is a cylon himself or the Six in his head is more than just a hallucination that suppresses his sense of guilt. Neither of these assumptions are provable based on currently available information though, but I believe latter is vastly much more probable than the former.

Oh, and there's some wonderful yin-yang contrast in how it's Cavil, the only atheist model among cylons who informs the religious, messisatically predisposed D'Anna that the rest of the community has sentenced her to being boxed in cold storage. I also don't have a moment's doubt that in the future of the series, Baltar will somehow get in a situation where he can restore her from cold storage into a body, and won't hesitate for a moment, as he believes she has the answer to his burning identity-crisis question.

Microsoft to the rescue of the mankind

(click on the link to see the original flash animated ad). It's not a fake - this ad was indeed published by Microsoft and for a while appeared on Battlestar Galactica's official homepage on Sci-Fi channel.

Related fun fact: Did you know no TV channel carries Battlestar Galactica in Hungary? One of the commercial chanells bought the rights for the first season few years ago, but they stopped broadcasting it after only (I think) six episodes, citing poor viewer ratings. Morons. (Someone was a moron. Either the TV channel producers, or the company measuring the viewership ratings, or, err..., the local TV audience.) If it weren't for BitTorrent, I wouldn't be able to watch it at all. (And I also wouldn't have any motivation to buy the mini series + the first two seasons on DVD + all the soundtrack CDs from Amazon either, which I did recently. So much for studios' fairytale of "lost revenue due to copyright infringement by file-sharing".)

Graz for geeks

Wife and me spent the few days around New Year in Graz, Austria. I've taken 245 pictures in total, and now published 13 of them on my Flickr page. I published only those though that have some geek appeal. Among the stuff is Graz's new palace of arts, a building resembling an alien spaceship complete with a "Resistance is futile" neon sign and pulsating lights, a snowman sculpture similar to Calvin's snowman art, half a millenium old clockwork, sculpture carrying the first Austrian cosmonaut's message encoded in waltz steps (no kidding) and more.

Java garbage collection analyzer

IBM Pattern Modeling and Analysis Tool for Java Garbage Collector is "a tool that parses verbose GC trace, analyzes Java heap usage, and recommends key configurations based on pattern modeling of Java heap usage".

I remember I heard about a similar tool for HP JVM on HP-UX (I think Kirk Pepperdine told me about it on the train from Aarhus to Copenhagen this October when we were travelling home from JAOO) - it'd collect GC statistics and then provide you with a GUI where you could play with sliders for various memory settings, and it'd calculate how would have the GC behaved if the program was run with those settings.

On a somewhat related note, as someone who had to do some ammount of GC tuning in the past, I'll be curious about experiences people have with Java 6's GC that is said to behave optimally in most situations without any manual tuning... It sounds enthusiastic, but I'm too often reminded that in reality there is no silver bullet in automatic memory management.