Saturday, March 18, 2006
Friday, March 17, 2006
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.
Monday, March 13, 2006
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.
Sunday, March 12, 2006
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
int. We can instruct EasyMock to return
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
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.
Tuesday, March 07, 2006
Monday, March 06, 2006
Friday, March 03, 2006
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.