Check out Phosphor. Now. Why are you still reading? This isn't a silly Wolfenstein knockoff built using Firefox's canvas element. If you're running OS X, make sure you go into the video settings and switch to OpenGL (it took me from 10 to 60 fps). Anyone up for a Deathmatch?

Gilad Bracha: The goal now is to see how much hotswapping can be done for the platform as a whole, and if we can’t (as I suspect) deliver full hotswapping, whether we can at least support full hotswapping for dynamically typed languages, where the issues are simpler. Whatever support we come up with should be a guaranteed part of the JRE, so developers can rely on it everywhere. If we can get both invokedynamic and full hotswapping for dynamically typed languages working, implementations of languages like Python or Ruby could use the JVM object model directly, and really take advantage of the great performance of JVMs. That’s the holy grail of JSR292. I certainly won’t promise we’ll get all the way. I’ve seen how hard it is to turn ideas like this into a reality for the Java community. There are technical problems, resource problems, political problems .... Still, we’re about to get started (still forming the expert group) so wish us luck.

We may get our wish after all.

AJ Mexico via SlashDot: "McAfee released an anti-virus update that contained an anomaly in the DAT file that caused many important files to be deleted from affected systems. At my company, tens of thousands of files were deleted from dozens of servers and around 2000 user machines. Affected applications included MS Office, and products from IBM (Rational), GreenHills, MS Office, Ansys, Adobe, Autocad, Hyperion, Win MPM, MS Shared, MapInfo, Macromedia, MySQL, CA, Cold Fusion, ATI, FTP Voyager, Visual Studio, PTC, ADS, FEMAP, STAT, Rational.Apparently the DAT file targeted mostly, if not exclusively, DLLs and EXE files."

Times like this I'm glad to be a Mac user. You'd think McAfee would have some degree of testing for false positives. Those are very common applications (Office!?). That's just irresponsible.

EasyMock 2.0 has gone in a new direction API wise. Instead of dealing with a control object as you did in 1.0, you interact with the framework through static methods imported from a class named EasyMock. I prefer the new DSL-like approach.

Sadly, instead of creating a new package for the incompatible API (easymock2 perhaps?), they prefixed incompatible interface names with an "I" and mixed old and new classes in the same package. Ewww.

But if you can look past the class evolution faux pas (the ugliness doesn't really impose itself on your code afterall), EasyMock has embraced JDK 1.5 generics to take static type checking for mocks to a whole new level.

First, creating a mock. They got it half right:

static <T> T createMock(Class<T> toMock)

That removes the need to cast in simple cases, but, thanks to erasure, breaks for more complex cases (T = List<String> for example). I think they really want:

static <T> T createMock(Class<? super T> toMock)

EasyMock has always had good type checking when it comes to specifying what methods you expect your code to invoke. As before, you create a mock, invoke methods you expect your code to invoke with expected parameters, swich over to replay mode, and run your test code:

Foo mockFoo = createMock(Foo.class);
mockFoo.doSomething();
replay(mockFoo);
// code you expect to invoke doSomething().
verify(mock);

Going in today, foremost on my mind was how would I tell EasyMock what to return from Foo.doSomething()? To my pleasant surprise, not only can you specify a return value, but the code is statically typed! Say for a moment that doSomething() returns an int. We can instruct EasyMock to return 5 from doSomething() like so:

Foo mockFoo = createMock(Foo.class);
expect(mockFoo.doSomething()).andReturn(5);
replay(mockFoo);
// code which expects doSomething() to return 5.
verify(mock);

To our benefit, the compiler verifies that that the types returned from doSomething() and passed to andReturn() match.

Before JDK 1.5 and generics came along, I said that no mocking framework was compelling enough for me to abandon plain Java mocking. EasyMock came close even then, but now it looks like I'll really have to change my tune. I'll test drive EasyMock in some real world tests and get back to you.

The gethuman database, instructions for getting passed automated operators at various companies.

I've been looking for the "insert" key on my Apple keyboard (as in insert vs. overwrite mode) so I can paste when logged into Linux boxen and generate methods in IntelliJ without using custom key mappings. Turns out it's labeled as "help".

Krista and I just moved. We're taking the opportunity to revisit the HD DVR landscape. We used Comcast's HD DVR in our old apartment. Pros: great price, two tuners. Cons: slow, buggy, bad UI. I'd like a more polished UI this time around (i.e. something Tivo-like) . Should I spring for DirecTV's HD Tivo or should I sit tight with Comcast until the series 3 Tivo comes out? I'm leaning toward the latter. Posts like this worry me about the future extensibility/compatibility of the DirecTV Tivo. I want to be able to take advantage of new features like Tivo to Go as they come out. Maybe I should build a MythTV backend. Seems like a lot of work though. I'd want two HD tuners. If I go the MythTV route, do I want Comcast, DirecTV, Dish, or something else? I'd go OTA, but with the new Sopranos season starting, HBO is an absolute requirement for Krista.

Ed Burnette: "With its uncluttered design, mature code base, small size, well defined semantics, dynamic language features, and JSR 274, BeanShell looks way groovier than Groovy."

My sentiments exactly. Update: My response to Graeme (originally posted in his comments):

You're kidding yourself if you think there's a fundamental difference between BeanShell and Groovy. They solve the same problems. Labeling one "scripting" and the other "dynamic" (dynamically typed?) doesn't change the fact that they really only differ in what syntax sugar they support. BeanShell supports scripting language like functions (i.e. working with files, etc.), but that's a feature, not a definition of the framework. Any other differences boil down to implementation details. I personally prefer BeanShell's conservative evolution approach to Groovy's attempt to include everything including the kitchen sink. I seriously doubt Groovy's long term viability and ability to evolve and maintain backward compatibility. The fact that you haven't provided any examples of BeanShell syntax sugar leads me to believe you don't know much about it. If I didn't know better I'd think that BeanShell was little more than a Java interpreter after reading your post.