Oracle and Sun: Cui Bono?

Well, here’s a hint: it’s not Oracle, “Sun,” Java, or MySQL in the long run.

I’m thinking the Ruby, Python, and PostgreSQL worlds just got a shot in the arm, as this is minor calamity (at least) for Java, and a major one for MySQL. Ironic, since Java maturing like a fine wine and recovering from early-decade blunders; MySQL was already in trouble thanks to Sun.

As for benefits, it’s also not Google, who relies heavily on Java but could eventually find itself in an adversarial relationship with Oracle as enterprise computing moves to the cloud. Google does have enough sheer wo/manpower to exploit the OSS licensing on Java to take it in its own direction if necessary … but is that really a desirable way to go? or one the investors can live with?

I don’t think Microsoft minds this one bit either … since there was nothing that that Java, Oracle, and their communities (and users) couldn’t do before that they can now, while a number of scenarios (Java and open source databases/appservers in the enterprise) suddenly become just a bit murkier.

(Semi) Portable Comet Framework

I meant to reblog this at the time of the announcement: Sun has released a first alpha of their atmosphere project. The project was about extracting useful comet-y bits from Grizzly and making a standalone pluggable kit for comet.

It is its own small framework, and autodetects where you drop it.

Here’s a nice article. It looks to be Jean-Francois Arcand’s project – follow his blog and the project’s twitter.

Stax Brings more Standard App Models to the Cloud, Marginalizes Custom Platform Further

Stax, which recently launched in private beta, is a cloud hosting/deployment/ops platform based on Java appservers. The coolest thing about Stax is that it offers many flavors of JavaEE-deployable applications, including Python apps (via Jython) and Rails (via JRuby) with ready-to-roll built-in templates.

Stax has a very AppEngine-y feel, not just on the website, but in terms of the SDK interactions, local development, etc.

This is good news for all of the popular platforms ... and bad news for those rattling around the corners with non-standard APIs. As the app-hosting industry continues to mature, the emphasis will clearly be on established players like Rails, ASP.Net, JavaEE, Pylons, et al. at the expense of guys like AppJet.

It's not about the language (JavaScript) but the about learning a set of APIs, patterns/practices, and sustaining a community ... based on a roll-your-own platform.

It is true that some of these built-for-the-cloud platforms were designed from the start to default to hash-style or big-table style storage -- popular for content-oriented cloud apps because of its easy horizontal scaling -- where the "traditional" platforms focus on relational stores and have a variety of bolt-on APIs for cloud DBs.

But now that there are so many standard alternatives, it is unlikely developers will pay any custom-platform-tax no matter how elegant that platform might be.

How is Google Native Client Faster Than -- Or As Safe As -- JVM or x86 VM?

When I saw Google's proposed native-code execution plug-in earlier this week, my initial reaction was: "Don't we already have those, and they're called exploits?"

I decided to mull it over a bit, and I still don't like it. While the idea of sandboxed native x86 execution based on real-time analysis of instruction sequences makes for a great Ph.D. thesis or 20%-time project, it sounds like an awfully large attack surface for questionable benefit.

Here's what I'd like to know from a practical nuts and bolts point-of-view: how many "compute-intensive" scenarios could not be implemented effectively using either (1) the Java VM or (2) a plug-in based on widely-available open-source machine virtualization, running a tiny Linux snapshot.

While the JVM falls short of native code in some places, it can be as fast -- or even faster -- in other cases (faster because the runtime behavior provides opportunities for on-the-fly optimization beyond what is known at compile time). Yes, there are issue with clients not all having the latest Java version -- but that seems a small issue compared with the operational issue of deploying a brand-new plug-in or browser (Chrome).

Another approach is to use a plug-in that runs a virtual machine, which in turn runs a small Linux (started from a static snapshot). User-mode code should run at approximately native speed in the VM, which should cover the pure computation cases. In a rare situation where someone wants to run an OLTP file-based db (which would behave badly in a VM environment) or get access to hardware-accelerated OpenGL facililties, specific well-defined services could be created on the host, which code could access via driver "ports" installed in the VM image.

These approaches to the security boundary -- Java VM and x86 VM -- are well-known, long-tested and based essentially on a white-list approach to allowing access to the physical host. While Google's idea is intriguing, it sounds as though it's based on black-listing (albeit with dynamic discovery rather than a static list) of code. I'm not yet convinced it's necessary or safe.

Maybe a Reason to Learn some Scheme, not a Reason to Avoid Anonymous Functions

A team member with one of my consulting projects sent an email yesterday, describing his counterintuitive run-in with the this keyword in an ActionScript 3 anonymous function. He found a fellow traveler looking at the same issue here... and concluded this might by 'yet another reason to avoid anonymous functions.'

I have a different view, which I thought might be worth reproducing here:

I'm not sure this is a reason to avoid anonymous functions. Looking at the issue and the blog post, the following points may be helpful for the newbies to ActionScript. AS3, and the Flex/Eclipse (FlexBuilder) environment especially, make ActionScript seem like a strange flavor of Java (or C#). But it's not.
ActionScript 3 is an implementation of EcmaScript 4. It has much more to do with JavaScript than with Java, although Adobe intentionally created an environment that would be familiar and comfy for Java devs.

EcmaScript (aka JavaScript) is a Lisp/Scheme family language not a C/C++/Java family language.

Unfortunately, for historical reasons, it shares some syntax constructs with the C-derivative languages, and ES4/AS3/JS2 adds more of those -- but many of them have different meanings, as the aforementioned blogger discovers the hard way.

If you're interested in how this came about, and how to think about it, I can't say enough to praise Douglas Crockford's lectures on "The JavaScript Programming Language", which you can watch from YUI theater. Brendan Eich takes issue with some of the "politics" stories in Crockford's account. But confirms that engineers were recruited to Netscape with the promise of implementing [some flavor of] Scheme in the browser.

If you expect to spend any amount of time in the future doing JS or AS, a couple hours watching Doug Crockford speak are unbelievably worth it. JavaScript (and AS) are extremely powerful languages and can work really well ... only they definitely don't work like they appear they should, if you see the syntax and come from a C/Java background...

Once we realize that we're basically running Scheme in the browser (Brendan says Self), lambda -- anonymous functions and their closures -- become first-class objects as fundamental to us as stack vars in a C language.

As a bonus, if you're new to this and have some time, MIT has published one of the classic textbooks, "Structure and Interpretation of Computer Programs" online for free under a Creative Commons License, along with instructors' manual, exercises, etc.

Actually, I'm gonna go out on a limb here and say if your company or team has a C/stack/register kind of background (Assembly/C/C++/C#/Java/Pascal/Delphi/VB.net/etc) and you're looking at getting involved in JavaScript/ActionScript/Ruby projects, make a team workshop out of doing as much of the Abelson/Sussman book as you can get away with. As a practical side effect, it'll also make your SQL code easier (core SQL is more like Scheme than C) and give you another way to look at problems.

Alternate Reality: Java and .Net Both Went Open Source 8 Years Ago

The later-phase, heading-to-market end of application model innovation is screaming along.

Sun and Microsoft have announced their intent to get into cloud models that improve scalability and manageability. We don't know for sure how pleasant the programming will be, but it seems reasonable to assume it's at least as good as ASP.net 3.5 or J5EE. Microsoft seems to be aiming center-of-the-road with stuff like ASP.net, the MVC flavor,  and "dynamic data" pieces, while Sun is putting a big chunk of its chips on the Java side, and another big piece on JRuby/whatever-is-next-that-they-can-get-to-run-in-Glassfish.

Amazon is offering persistent disks for EC2, acknowledging that the RDBMS-backed app is not immediately going to disappear in favor of a S3 or SimpleDB layer. 'Cause syncing RDB stores usefully on S3 is a hassle (see slides 10-14 here).

Or, you can also buy all the missing pieces of the Amazon stack from RightScale.

Then there's Passenger (mod_rails) for Apache, and a Glassfish gem, which both aim to improve Rails deployability and incrementally bump performance.

But all this got me thinking about an alternate universe, one of those hindsight 20/20 things, that's interesting to imagine:

For Sun and Microsoft, I believe the missed-opportunity-of-the-decade was not open sourcing the JVM and CLR respectively (and their core libraries and infrastructure), from around 2000.

In the late 90s, Java was a beautiful thing, and aside from a few anti-OO diehards, it was clear that if the perf issues and minor hassles could be overcome, virtualized apps in an elegant environment (Smalltalk, oh wait, did I say that out loud?) were the future.

By 2000, Java legitimized VMs for server apps. As for GUI apps, graphics, printing, language neutral JIT, all manner of easy native interop, module loading, and the other parts Sun didn't get to ... Microsoft had those problems licked even if CLR was still in beta.

If all this IP had gone open at that time, a few major projects -- maybe 2 or 3 -- would probably have come out of it, and these projects would be the de facto runtimes for everything we want to run today. These few projects would spawn native bindings for all manner of OSes according to the existing APIs, so it would be even easier to really write apps that run on all kinds of devices, or in a cloud facility, or in on local elastic virtual infrastructure.

With the languages separate from the VMs, but with well known interfaces, a lot of debates (JavaScript 2 for example) would be less necessary. Meanwhile, Apple could have contributed whatever changes were necessary to get keep Cocoa APIs in sync, instead of going halfway down the Java road and then getting stuck, which would vastly improve the reach of that platform (their mission being more about user experience than about Objective C).

Performance, security, deployability, management -- these problems wouldn't magically go away, but with a more modest universe of options, they become infinitely more tractable.

In hindsight it seems that keeping these technologies proprietary (Sun's moving along; you can see Microsoft's code now, but you can't change it and re-release your own variant) was about fear and ego and control, defensive maneuvering.

I find it hard to see how either of these players would have made a dime less money in the scenario here; actually they would probably have made more money and have even more mindshare than they do now.

Sprint Keeps Fighting the Good Fight with 'Titan' Mobile Platform

Sprint has long been the most developer-friendly of the major carriers, and they're raising the Java bar with their new Titan platform.

Titan is a significant improvement over J2ME, and Sprint is doing the smart thing by making sure all Titan-capable devices run the same implementation (something Sprint actually started doing a few years back with their J2ME VM, in an attempt to ameliorate the write-once debug-everywhere problem).

But sadly, Sprint's leap forward (and Sun's, if they succeed in getting their SavaJe-derivative JavaFX mobile platform shipped) is just more trouble for the mobile application industry: it's yet another incompatible platform that must be supported, but which doesn't replace any existing platform.

No one wants to build or fund a company (or application project) that can only reach a subset of Sprint subscribers (those with the Titan handsets). It's a non-starter. While the iPhone has enough sex appeal to drum up an entire investment fund just for its own apps, Titan has no hope of accomplishing the same thing.

So a "great new mobile app" can only choose to support the legacy platforms and ignore Titan, or support the legacy platforms and also support Titan. Anyone else see the problem here?

Application Models, Part 2

A little while back I described the idea of an "application model."

The application model is a key concept that keeps getting muddled and confused with partially overlapping concepts like languages (e.g., Paul Graham's discussions of "languages for smart people" vs. "languages for the masses") and platforms (a legacy platform vs. a "great new" platform, etc.)

So besides being a useful term for which I'm not sure there is an equivalent, what is the role of application models?

First, application models -- not languages or platforms or vendors -- argue, persuade, and sometimes win.

Whether it's Visual Basic (the original), or C++ and OpenGL, or Rails, the question is "How well does the application model solve the world's (ok, domain's) problems for the folks who actually do the solving?"

And the cool thing is that application models are very malleable in a way that languages and platforms aren't -- because the they include (well, really their complements or negations include) all kinds of APIs and libs that people cook up.

Huh? Like this: the application model for JSP/Servlet apps (including "model 2") stunk. So folks created all sorts of libs (Struts, Tapestry, etc.) and templating engines (FreeMarker, Velocity, etc.) in order to create a better-shaped "hole" -- a better application model for what were still fundamentally Java Servlet apps. Still a hassle. Nice underpinnings, great performance, needs some work. We got IoC containers and the application model became friendlier. For small, quick apps, Rails had a lot of appeal, so we got Groovy and Grails as options. In the .Net world, we have C# adopting elements of Ruby (yes, they're really Smalltalk or Lisp elements) and ASP.Net offering the "MVC Framework" which -- with LINQ -- creates a flavor of Rails.

There is no intellectual property violation going on here. Platforms and languages are adapting around good application models. Some of this adaptation is vendor driven, some is community driven, some involves new languages, some involves new tools, and some involves APIs. But the common thread is a desire to alter an application model in a particular direction.

Application models are what get mindshare and what make provide for the continuity of commercial application development patterns over time. More on this point later.

Before I get there, it's worth pointing out that the application model also bears heavily on the aspects of application development apart from core feature development. When we get into these aspects, non-functional requirements, or orthogonal (really non-collinear) concerns, the application model determines (or at least posits an optimal or easiest path for) integration. How the UI attaches, how app-level security is managed, how different services are integrated -- these all fall under the sway of the app model, and if we want to make these things better, the app model is what we should be talking about.

Over time, the adaptation of application models (by the all of the parties mentioned above) is the story of the evolution of commercial software. Commercial software evolution is often described as a sequence of machines, or OSes, or platforms, or languages. It most definitely is not these things, any more than it is a story of vendors fighting and dying and rising. The thread of continuity, and the real underlying story, is about people adapting application models, piece by piece, over the years.

It's About the API

Ok, at the risk of being almost timely, Zed's Rails Rant has inspired me to finish a point I've been wanting to make for a while now: Platforms (and languages too) are about the developer experience (API). Not the community, although that can help. Not the implementation -- that can be changed, redone, ported, etc.

What is nice about Ruby and Rails is that they're "fun" or "pleasant." In general, when programmers say this, what they mean is

1. Working with the language / API does not go against the grain of how their mind works. Since programmers have varied ways of thinking, simply avoiding an "against-the-grain" experience across a set of non-trivial cases is a real accomplishment. Ruby does this in spades, Rails almost as much once you get used to a particular "Rails way" of doing something.
2. It's at the right level of abstraction most of the time, when used in the kind of work for which it was intended. RoR is fabulous at this. It does the "super-high-level-language" thing when it reads your data schema, does :has_and_belongs_to_many, and makes a very sensible attempt to match URLs, actions, and views by default. It goes low-level by working with clean, trivial HTML, which is easy to write and debug by hand, while ignoring the temptation to autogen all sorts of decorated HTML/CSS/JS.
3. When you need to read the core sources or other people's code, it's not a terrifically painful experience that leaves you sitting there saying,"You've got to be kidding" over and over again.

Now, apart perhaps from a bit of #3, these are descriptions of a programmer's experience interacting with the language/platform/framework/tools.

They are API issues, not implementation issues. If the implementation is bad enough, the API experience will be overshadowed. But the developer experience sells the platform.

So... what about the MRI, and the Rails core team, and Mongrel and horrific perf issues, and all that?

The current state of affairs needs to be seen as a reference implementation. It shows off the specs under discussion, proves they can be implemented, provides all the right output to the definitive test suite, etc. Sun releases new Java APIs with a reference implementation. Some of those RIs have been good enough to use in production, some haven't. Sun hoped that third parties would create commercial implementations -- in some cases, this happened. Where an API was popular and important, a "real" version -- or several -- became available, based on market demand.

There are already a bunch of alternative implementations of Ruby either finished, or in the works. Rails has yet to see an alternative implementation, so far as I know, but it seems plausible that both open source (e.g., modify or redo the Rails code to provide multithreading support, etc. and run on top of JRuby) and proprietary (Rails as a set of ASP.Net assemblies) implementations will emerge.

When Java offered a great developer experience compared to the alternatives, it picked up adherents even when the adequate performance (heck, even existence) of various APIs was shaky. When .Net offered a great developer experience, it brought more shops into the Microsoft fold than 20 years of, shall we say, other approaches to gaining market share.

Some failed platforms suffered because of business issues (e.g., Delphi and C++ Builder), but most fail just because they don't do #1-3 above as well as the next guy on the block. My point is that Zed's rant is a bit beside the point, even if it's all true. Ruby and Rails have already accomplished the end of influencing industry thought and behavior in a broad kind of way. We'll need to be a little more patient (or make some serious contributions) before we get the followup implementations.

Sun CTO: JavaFX Mobile Stack Aims to Clean up J2ME Disaster^H^H^H^H^H^H^H^H Issues

It's only mild hyperbole to call J2ME a disaster. If you've depended on ME to make a profit, it might not be hyperbole at all.

But good news may be somewhere in the pipeline. This morning I heard Sun CTO Robert Brewin speak at AJAXWorld. His talk largely concerned enterprise services, but when he mentioned that one argument in favor of Java is its ubiquity, and that Java runs on about two billion phones, I couldn't help but stand up and ask for the mic.

Since Robert was ready to acknowledge the existing hassles, my question was: does Sun plan to fix it -- e.g., by becoming more stringent about how devices are certified as Java-capable?

In his response, he punted on the J2ME aspect, suggesting developer could put pressure on device manufacturers to standardize their Java behavior. Since cellphone carriers are players in the equation, I'm awfully skeptical about that. But the cool part was that Mr. Brewin said that the place where Sun plans to really make an impact here is with JavaFX Mobile.

Since JavaFX Mobile, adapted from the Savaje Java-based OS acquired by Sun, is a full kernel-to-app stack, it should provide much better -- perhaps even 100% -- compatibility between devices.

Now let's keep our fingers crossed for full J2SE support on it.

The Google Phone Should (Will?) Run Your Regular Java SE Apps

Om's rundown of supposed Google-phone details was picked up today by engadget mobile. If the rumors are on target, and the phone is really based on a Java-on-Linux OS, with a Java API for apps, then I have one thing to say. And hopefully all those PhDs at Google thought of this a year ago.

Wanna make be a real disrupter in the smartphone world, not just a me-too? Java SE.

Here's why it makes so much sense that Google's probably already done it:

• Sun bought SavaJe in April
• Sun's JavaFX mobile is based on the SavaJe tech
• Google can get help from Sun on this Java-based OS (similar to what RIM built on their own)
• But, being Google, they're in a position to ask for full J2SE support...
• ...which exists, performs well, and which Sun can now provide, because SavaJe built and owns it! (even though they later focused more on a J2ME++++ approach)

Google and Sun can ship the device with a J2ME environment layer (similar to the J2ME-in-an-applet environments that exist online), and probably the JavaFX mobile layer too. But allowing anyone to crank up plain old Java code (of which Google already has quite a lot) on the phone would be a game-changing move.

When Building a Smartphone App, Resist the Siren Song of J2ME

I'm tempted to comment a bunch on the Yahoo! Go smartphone app with its secret J2ME porting layer. But I just don't have enough of the business context around the project to draw solid conclusions. So I'll spare you the half-bakery and instead share something that you can use.

If you're building a mobile productivity app, think realistically about who your principal user personas are. If your user is on a Windows Mobile phone, a Blackberry, or a Symbian-based smartphone, don't even think about writing a J2ME app. Just don't. If you haven't been down this road, you're probably thinking, "Of course I wouldn't do that.. why do think I would?"

Here's why, sooner or later, you're going to be tempted to do it. And if you're not, another project stakeholder will, and you're going to have to talk him or her out of it. The argument is going to go like this:

1. The J2ME / MIDP platform offers a lot of functionality (graphics, networking, threading, PIM integration)
2. The vast majority of phones support J2ME, even ones that also offer an OS-level API, like Symbian or Windows Mobile
3. Therefore, if an app is built on J2ME/MIDP, it will have an enormously larger potential market size in terms of device compatibility. Like an order of magnitude (or more) larger. And, heck, it's easier to write one app than a whole pile of them, right?

The problem is not that you're going to be have to do a lot of adaptation, since no two J2ME implementations do the same thing. Although it's something to keep in mind.

The real problem is that if your customer is a smartphone user, the J2ME app is going to stink. It will be clunky, trouble-prone, and will not match the level of user experience that the user is accustomed to on their device. Compared to the native apps on the device, yours will be the "weird" one that somehow just doesn't work quite right. (Incidentally, this is exactly how Yahoo! Go looks next to the couple dozen native Windows apps on my Blackjack.) So just when you think you've got a killer app figured out for mobile, you're guaranteeing it won't be.

And you're not really going to attract those hundreds of millions of J2ME-capable feature-phone-users because they weren't your target in the first place. Not to mention, those users generally don't understand how to install apps on their devices, don't have unlimited data plans, and don't understand how incremental data charges work on their plan, so they are terrified of the cost of using networked apps.

Bottom line: it sounds cliche, but know your market and build what they want to use.  Build a Blackberry app for your Blackberry users and a Windows app for your Windows users. It's easier than building hacked-up J2ME apps. It's enormously easier to test and support, because those operating system APIs you're using are actually tested and supported (unlike J2ME). And if you're secretly nervous that there aren't enough customers on these platforms to support your business plan, admit it now and make some adjustments before you write a line of code.

Now You Can Start Porting All Your Killer J2ME Apps to .Net CF

Yes, that's a joke.

After discovering the J2ME implementation shipped with Yahoo! Go's Windows Smartphone implementation, I felt compelled to take one more little step and make sure that you could actually build and deploy your own (or someone else's) MIDlets on the framework.

So I grabbed ye olde Hello World MIDlet which -- at one point anyway -- was part of a Sun tutorial on MIDP 1.0 programming, and wanted to see if I could get it to run on the javaxnet10 layer. Purely for research purposes, of course, because deploying other apps against the Y!Go runtime is likely against the EULA/license.

This exercise turned out to be pretty trivial, and it goes like this:

1. Create a new C# Smartphone project in Visual Studio (VS). Using J# would obviate a lot of small C#/Java syntax changes, but by default J# isn't supported for "smart device" projects. In theory it should be fairly easy to flip compiler switches and get it working (it's all IL, after all), but the fastest route for me to try this out was with C#.
   
2. Make a lib folder and bring in the javaxnet10.dll, platfom.dll, and interop.dll libs from a Windows Mobile distro of Y!Go. As of today, all of the available Windows Mobile devices are ARM-based (as is the MS Smartphone emulator), so you'll have an ARM interop.dll, which is fine.
   
3. In VS, add references to javaxnet10.dll and platform.dll. Add interop.dll as an "existing item" and mark it to be copied through into the output directory for your app.
   
4. Delete the Program class that VS generates (which has the Smartphone app entry point) and the Form1 class (MIDP handles the display; you won't be using System.Windows.Forms directly).
   
5. Add in the Hello World (or other) MIDlet class, and perform C#-ification. (C# is explicit about virtual/override, string and bool vs. String and boolean, etc.)
   
6. Add a .Net-suitable entry point. I used the following code, which is taken from the decompiled Main entry point in Yahoo! Go:
   
   private static void Main()
   {
              MIDlet midlet = new HelloWorld();
              MIDlet.Start(midlet);
   }
   
   
7. Click "debug" to do a build-deploy-run. If this is the first .Net CF app you're debugging on this emulator image, be patient -- it takes a little while for VS to deploy the compact framework to the device. My HelloWorld C# MIDlet source produces this output:
   
   

   

 

Ok... so we have the ability to import MIDlet code and run it in on the .Net compact framework runtime. Pretty cool.

If we wanted to try this with a real J2ME codebase, we'd almost certainly want to build it with the jsc, the Visual J# compiler, or else run it through a Java-C# syntax conversion tool, so as to avoid creating a entire C# variant of the code.

I'm still curious where this J2ME implementation came from (I'm about to shoot an email off to Jeremy Zawodny with Yahoo's developer group / dev relations to ask) ... If it's not an in-house creation, my best guess would be the mobile game industry, since that's the one area where MIDP apps have been successful enough that it would be worth the investment to be able to sell them on Windows phones.

And I still plan to comment on what this all means in terms of an architecture choice for Yahoo! Go ... (and no, the last post about NIH and crackpots was not the promised commentary about it).

Reverse Engineering: Finding the (Not So) Secrets of javaxnet10.dll

When I was restoring my Blackjack from backup last week, I noticed a file with an interesting name in the Yahoo! Go application folder: javaxnet10.dll

Eh? ... some kind of Java library? or a JVM? or maybe just a Microsoft runtime DLL for using J# with the .Net Compact Framework? Running J2ME apps on .Net CF would be a kind of cool... Ok, off to Google. A Google search for "javaxnet10" (over the web and newsgroup archive) produces several links to this single discussion thread where someone speculates on this exact question.

So I did some research. I'll save my conclusions and speculation for my next post; here, I'll tell you how I did my 10-minute analysis of this app. Old news to Win32 developers, but I think there may be a few .net/mobile/Web2.0 devs out there that might find this useful.

First, I used ActiveSync to pull all the DLLs and EXE for Y!Go off of my phone and onto my desktop. Then I right-clicked on the files to see if there was any metadata I could view that way. There was nothing -- either because it wasn't published, or it was removed at some point.

So I opened up a Visual Studio command prompt and cranked up dumpbin.exe. Dumpbin is a command-line PE format file processor. Since Windows Mobile is built on Windows CE and uses PE format for binaries, dumpbin doesn't care that these files are for a phone with an ARM processor rather than a desktop with an x86. Dumpbin will tell you which libraries a file loads, what it exports for other files to use, and all kinds of other fun stuff, including disassembly and -- get this -- it will disassemble an ARM binary into ARM assembly (the register names are the giveaway). I wonder how many instruction sets it understands?

But that's not relevant here because javaxnet10.dll is not a native code library at all.

It's a .Net assembly. How do I know? It reports a single import of mscoree.dll. mscoree.dll, short for "Microsoft component object runtime execution engine" is the .Net virtual machine. Or, as Don Box more poetically put it, "mscoree is the last COM DLL." He meant that metaphorically, not literally, of course. "mscorlib," he continued, "is the first .Net DLL," since that's the base library that mscoree loads to do anything useful.

Ok, let's look at all the files from Y!Go and see how they break down: javaxnet10.dll is .net, platform.dll is .net, ygonet.exe is .net, interop.dll is native (it imports a handful of OS binaries, and not the .net runtime -- try dumpbin /dependents to see).

So this is looking like a .Net CF app, with a native interop helper library for things that are hard or impossible to do with .Net CF. But we still haven't answered the question of what javaxnet10.dll is about.

Since it's a .Net assembly, we can bring in the magical MRI machine of dot-net, Lutz Roeder's .NET Reflector. This tool is an amazing free application that allows you to fully explore the insides of a .Net assembly, from the class-and-namespace level down to full decompilation. And, since .Net IL is much richer in metadata than native assembly, the decompilation produces intelligible code in the .Net language of your choice!

Point the .NET Reflector at javaxnet10.dll, and the mystery is revealed: it's an implementation of most (maybe all) of the J2ME and MIDP APIs. It does not run Java bytecode (it's not a JVM, interpreter, or cross compiler). Instead, it implements Java platform interfaces the way WINE implements Windows APIs. Here's a screenshot... the namespaces read like a tour of the MIDP API.

Just to confirm our understanding, we can basically browse the source of the whole application, and see the use of Java types and patterns everywhere. For example, StringBuffer is the classic Java equivalent of .Net's System.Text.StringBuilder. Although the waters have been muddied with the recent introduction of a Java class called StringBuilder, J2ME/MIDP predates that API by years. Which is to say, if the app were being written in a .Net CF style, we would see StringBuilder in high-level functions even if Java libraries were leveraged down below. In a Java mobile style, we'd see StringBuffer. The fact the we see StringBuffer (and many similar cases) argues that, in fact, this is basically a Java app. Heck, com.yahoo.go.app.YGo extends javax.microedition.midlet.MIDlet.

'Nuff said. Next time, we'll talk about the significance or usefulness of our discoveries, and where javaxnet10.dll might have come from.