Here, I fixed that for you. And this one is NOT a myth: http://en.wikipedia.org/wiki/AARD_code, http://www.ddj.com/windows/184409070?pgno=4

...from TFA: "That documentation must be kept "in confidence" and "under non-disclosure" by PFIF and Samba. "

Not what I'd consider openness yet; not by a LONG shot.

Some drivers to make Linux work better inside MS's Windows Server Hyper-V virtualization platform? How altruistic...

I'll be more impressed when MS, for example, helps with the SAMBA project. Or at least, doesn't actively screw up with such interop projects from the FOSS community. No GPL code required, just give people decent, up-to-date, open specs; and no patents bullshit.

Or at very least, when MS stops enforcing such patents (see TomTom / FAT32, or again SMB in MS/Novell "agreement").

Check this, 240 languages and counting: http://www.is-research.de/info/vmlanguages/. Now just die of shame.

Of course not all these "languages" are highly relevant. There are abandoned or not well maintained projects, academic stuff, and several extremely niche languages/tools. But I suppose this can be said at least for a few of the .NET entries as well.

Wikipedia's articles have very different quality. You'd think that the articles used some criteria like only including languages which are current / well maintained, but the JVM article it misses such entries like JESS and Drools, both very "alive" and popular for logic/IA and rule-based programming.

Because of the big "if" in my comment. Notice that even when emulating a PC on a PC you don't always get identical ISAs; you may be emulating code compiled for 80386 inside a Core2 Quad CPU, so this recompilation may even improve the code because it's possible to use 64 bit-opcodes, SSE, prefetching, etc. (This is not theoretical; modern JVMs like HotSpot are well known to exploit the very latest ISA features.)

The second reason is that the original code may not be safe, but the emulated/recompiled code is. Any kind of emulation has a side effect of sandboxing. So, JPC allows you to run arbitrary x86 code inside a browser's applet without any stability or security risk.

I don' think Applet deployment is the target for that project; if they are offering this option it's certainly just for quick demo sake. Notice also that the applet would need some serious time to download because (1) the emulator itself is reasonably big, (2) you need a virtual disk image containing the whole OS and apps; even a small FreeDOS distro with a couple of tiny DOS games will weight in a few hundred Kb, although the problem is mostly for first run as the Java PlugIn can cache everything.

As I see it, JPC's main goal is showing off some amazing virtualization technology that they have developed - the emulated x86 code is JIT-compiled by JPC's engine into Java bytecodes, which are in turn JIT-compiled by the JVM to native code, so the net result is full native-to-native translation. (If both steps are sufficiently efficient and the host platform is also x86, the compiled code may even be very similar to the original code.) This remembers of similar systems like Transmeta's Crusoe.

As a secondary goal,. JPC is becoming a pretty nice general-purpose PC emulator, so it's potentially just as useful as other PC emulators like Bochs. If JPC reaches sufficiently close to native performance (I tested it ~1yr ago and it's slashdotted now), and includes sufficient hardware compatibility, it's obviously an advantage to be a Java program, fully portable including UI.

...that insists pushing bigger clock speeds. I fully expect IBM to promote liquid Nitrogen cooling in another couple years.

..but I am also old enough so have seen it in the big screen, back in 1982. And I'm not trekkie enough (read, fanatic) so have seen it again and again so I'd remember such trivia.

Look at Sun's new JavaFX Script language. It makes String a value type, not-nullable - you can try to assign null to a Sring variable but the runtime automagically replaces it with "".

The reason why the Linux crowd swallows IBM's posing of a great FOSS champion is that IBM's contributions are focused on the Linux kernel and Apache projects. Linux zealots are not standing behind IBM's policies with licenses, community or anything; they are just rewarding IBM for "being in their side", i.e. helping to promote Linux and developing stuff that's useful to Linux distros. The same zealots know very well that Sun's FOSS contributions and positioning dwarf IBM's, but Sun is seen as a competitor (Solaris) and doesn't use a license that allows Linux to get cool stuff like a decent filesystem for free.

That's all, the rest is hypocrisy.

If you read Jonathan's blog (http://blogs.sun.com/jonathan/), there's nothing new in this article. Either Jonathan has perfect memory to repeat entire paragraphs, or the journalist (or some Sun PR folk) just copy&pasted large chuncks of text from recent blog posts.

Java applets are certainly not popular in recent years, although I wouldn't say dead, and recent improvements (from JDK 6u10+ to JavaFX) stand reasonable chance to resurrect applets (only time will tell). But this whole debate doesn't matter, because if you never visit any page that needs the JRE, you can just not install the JRE - simple, isn't it? And if you ever hit a single site that's interesting to you and uses a Java applet for some useful purpose, then they ain't dead.

The JDK installer has a option to not install the "public JRE" (public = integrated to Windows / browsers), just turn that off. It's recommended for server boxes where you don't want unnecessary browser plugins of any kind (I won't install even the Acrobat Reader in a server that's exposed to the internet). The installed JDK will still have an embedded jre directory with everything you need to run server-side and even standard client apps like Java IDEs, etc.

Well, many installed software does that - pushing the user to the vendor's page. Even the browser itself does it... including addons; every week Firefox tells me that there's a new version of FlashGot or some other addon, and after I say Yes to download, update and restart, Firefox opens a new tab pushing me to the updated addon's page. Perhaps you think that opening a simple Release Notes page is okay, but opening a Registration page is not. That would be BS for me.

The true number is MUCH smaller. First, Sun moved from 6u7 to 6u10 (skipping versions 8/9) because 6u10 was a major feature update. Second, not all such versions are pushed through the auto-update channel; I don't know exactly what is Sun's criteria but it seems that only one out of each two or three minor versions are pushed. So, the net number of JRE updates that Sun forces through users with the auto-updater active is pretty small, perhaps 2-3 per year.

[P.S. I'm the poster of the msg you replied to; just for the record as I never post as AC except by accident.]

"The biggest thing Sun did with ZFS is they were good with PR and marketing." - Sour grapes? Not very elegant to say the least.

"Hey, I usually do my presentation slides in PowerPoint." - Now, that revelation should be sufficient reason to keep the Free (as in RMS/FSS) versus OSS schism for another 20 years. ;-)

"It turns out the best way to interface with it is with Java." - From my memory it's the first positive thing that Linus says of Java, ever. Perhaps now that OpenJDK offers 100% open source Java, Linux is willing to be kinder on it.

"I thought KDE 4.0 was such a disaster I switched to GNOME." - A couple years ago Linus says GNOME sucks; now, Linus says KDE sucks. We can summarize that as: Linus recognizes that Linux sucks in the desktop - period. The best one can do is moving away from the worst to the second-worst desktop at any given year... In a related note, 2009 is not going to be "year of the Linux desktop".

I hated the new GUI stuff in WinXP and always configured it to pure Classic mode (Win2K UI). With Vista I liked Aero enough that I left it on - partially because the Vista Basic UI was so terrible, I admit - but I kept other settings like the Start Menu and Taskbar as much Classic as I could. But with Win7, I finally liked everything and I'm running it happily with minimal changes from the default settings. The new Taskbar, for one thing, is great. On top of that, even at this beta stage app/HW compatibility looks excellent, memory usage is lower and laptop battery usage better, compared to Vista.

At some point you've got to abandon old cruft, like the Classic UI, to cut the bloat and maintenance and security nightmare that is keeping 10+ year old crap in the system. The tight time to do that is when the new features are overwhelmingly better than the old ones, so few people who've actually tried the new stuff will want to go back. I'm not a Microsoft fanboy (just google me) but credit where it's due: Kudos to you guys for Windows 7... if you don't screw it up in the next months (e.g. no new Vista Capable-like fiasco), you've got a smashing winner in your hands.

JVMs don't have intelligence to rearrange objects in the heap in a layout that favors cache locality. This happens in a limited extent:

1) GC continually compacts the heap, avoiding free space fragmentation. This results in denser cache lines, which means better cache usage.
2) Because a garbage-collected heap allows linear allocation - i.e., Java's "new " is basically as simple as "return (freePos += requestedSize)" - objects that are allocated together are typically grouped in one contiguous chunk of memory, while in C/C++ they could be scattered all over the heap.

The second factor can produce significant gains for Java, but only for very large and complex apps, with large heaps containing tons of objects (not the case of microbenchmarks that allocate everything at startup and on a clean heap). And even in this situation, modern C/C++ runtimes have significantly better heap managers than the naive, 50-line freelist malloc() algorithm used in the 70's. And when this fails, optimized C/C++ apps will resort to custom allocators.

The #1 reason that many microbenchmarks show Java beating C is that the top JIT compilers are extremely aggressive with three complimentary tactics:

1) Profile-driven compilation. This is trivial to implement in a dynamic compiler, but for static compilers it's cumbersome enough (requires extensive, up-to-date coverage tests for all performance-sensitive code), that 99% of all native programs don't use that feature even if the compiler supports it.
2) Deoptimization. The JIT can make heavy bets, e.g. "in this virtual call for a method of the Number type, the actual receiver is always a Double", and generate faster code. If this bet eventually goes bad (e.g. after a gazillion calls of the optimized code with Double arguments, it's called with a Integer), the JVM is able to efficiently trap this, fix the compiled code ("deoptimize" the now-invalid code), and go ahead.
3) Machine-specific optimization. A JVM will fine-tune all generated code for your specific system configuration, down to CPU stepping and precise cache hierarchy. Static-compiled code must typically be compatible with some reasonable configuration, e.g. "any Pentium or better". Even a fanatic Gentoo user that compiles everything for each machine is behind a JVM because the C/C++ compilers simply don't have sufficient -arch options to match JVMs.

The last item is another situation that may deliver cache-related benefits, but this is because JVMs are known to generate extremely cache-friendly code (reordering, prefetching instructions for arrays, etc.).