Andy's Blog

JavaOne: TS-7208: JXTA Technology Beyond File Sharing

P2P makes sense now

• more people (and machines) connected, more data at the edge
• more bandwidth
• more computing power

Limitations of Today's Internet

• physical addressing model (URLs, IPs)
• centralized DNS
• no QoS for message delivery
• optimized for point-to-point (limitations on multicast/anycast)
• topology controlled by network admin, not applications
• no search/scoping at network level
• binary security (intranet or internet)

What is JXTA?

• highly decentralized and reliable
• network protocol for creating decentralized virtual P2P network
• set of XML protocols, bindings for any os/language
• overlay network, decentralized DHT routing protocol
• mechanisms, not policies
• open source (want it to become core internet tech, wide adoption)
• www.jxta.org

What is different?

• JXTA addresses dynamically mapped to physical IP
• decentralized and distributed services (ID, DNS, directory, multicast, etc)
• easy to create ad hoc virtual networks (domain)

What JXTA does

• Brings devices, services, and networks together
• enables interactions among highly dynamic resources

Sample applications

• storage backup (321 Inc.'s LeanOnMe)
• Brevient Connect web conferencing
• grid computing - Codefarm's Galapagos
• SNS - social network application (most used P2P app in China)
• Verizon IOBI (trying to lower the cost of delivering content over the Internet)

Tangent: how do china's network filtering/blocking devices work with P2P apps? It seems like China has been doing two things -- trying to censor information coming in from outside of China, and trying to block Chinese-to-Chinese communications, when those communications don't toe the party line. While I won't say that it is impossible to filter/shutdown P2P, it seems like a hard problem.

JXTA status

• JXTA-Java SE (June 15th release 2.3.4)
  • APIs and functionality frozen
  • Quarterly release schedule
  • full implementation of JXTA protocols
• JXTA-C/C++ (2.1.1)
  • standard peer
  • extended discovery
  • linux, solaris, windows
  • rendezvous support
• JXTA-Java ME (2.0)
  • edge peer only
  • CDC 1.1 compliant
• community: C#, JPython

Looking ahead

• enhance ease of use and simplify network deployment
• enhance performance, scalability, security
• standardize specification further through public organization

Summary: I am totally in love with the idea of peer-to-peer, and JXTA has been on my list of things to check out for awhile now. I need to see how I can preach this at EDS.

JavaOne: TS-7318: Beyond Blogging: Feed Syndication and Publishing with Java

Starts with overview of RSS, including uses for RSS, news readers, etc. Then moves into some more technical details of an RSS feed. Shortcomings of feeds:

• Users need one-click subscribe (no standards yet) - Safari RSS doing a good job
• 10% of all Feeds not well-formed XML
• Feeds can be lossy (don't poll often enough, will miss stuff)
• RFC 3229 (FeedDiff) can be used to address this
• Polling based -- traffic waste; HTTP conditional get and caching ease pain

FeedParser (SAX based) and ROME (DOM based) -- two Java libraries for parsing feeds. Atom is the future of feeds? Atom is becoming an IETF standard, which leads credence to this theory. It is a comprehensive and rigorous specification. RSS 1.0 uses RDF (ick), RSS 2.0 has most of the same functionality, but tosses the complexity of RDF. How to serve feeds:

• ROME serialization
• XML DOM serialization
• Template langauge: Velocity, JSP specification
• Plop it on a web server that supports conditional HTTP GET, etags, etc.

Publishing Protocols:

• OLD: XML-RPC based, ad hoc, simple: Blogger, MetaWeblog (most popular), Movable Type, WikiRPCInterface
• New: The REST based Atom Publishing Protocol
• Why not SOAP?

Atom publishing

• Supports features of existing protocols
• plus administrative features (add/remove users, etc)
• spec still under development, will be finished soon

Atom collections

• resources exist in collections
• examples: entries, uploaded files, categories, templates, users

What is ROME?

• Java library
• RSS/ATOM feed parsers and generators
• built on top of JDom
• Provides beans as API

Why ROME?

• existing solutions were incomplete, stale, had unfriendly un-Java API

Pros:

• simple to use, well documented
• single java representation of feeds
• pluggable
• widely used, got momentum

Cons:

• Loss of information at SyndFeed level (abstract all feeds, lose special features of specific feed types)
• DOM overhead

JavaOne: TS-7722: The Apache Harmony Project

Harmony is a new project from the Apache Foundation, to do an Open Source J2SE implementation.

Why now?

• Lot of interest from community, companies
• J2SE 5 is first version where JCP license permits doing OSS implementation of JVM
• Sun cautiously supportive

Platform includes both VM and runtime (libraries) -- both critical to have J2SE implementation. Want freedom of license for components, flexibility of reuse (want to write your own JIT? Do that part, and reuse the Harmony runtime in order to get a complete system). Requires deep work (VM and JIT -- lot of hardcore CS stuff going on) and broad work (libraries -- just lots of code). They also want to build platform that is 100% compatible, and reasonably as fast. Goals: build community, build architecture, then get it finished and certified. The result will be to push Java into places where it isn't now, and where it cannot go.

Motivations:

• Not going to fork Java
• Not going to add new and incompatible technologies
• too hard, OSS can't do it -- wrong, OSS is just license & community, says nothing about technology
• license of VM is a major deal to some people
• What about Mustang? Not Open Source.
• Enable widespread adoption of Java, without re-engineering
• Provide open and free platform for Linux and BSD communities
• Java is 2nd-class citizen on Linux, Mono making big inroads...
• Get at developing economies (like Brazil), that can't afford commercial licenses, or have government directive to embrace Open Source

Design will emphasize portability, so it can run on many platforms.

State of OSS Java:

• Kaffe VM - borg of VMs (absorbs everything), focus on portability, but performance lags. Harmony is going to work with them
• GNU Classpath - Java class library; long-running; work with them, but licensing issues
• Jikes RVM - research VM; VM written in Java (little C and ASM for bootstrap); good performance characteristics
• ORP C/C++ research VM (Intel research); under Intel license
• GCJ - compile Java to native binary; lot Harmony can learn from them
• KVM - run Java bytecode on Mono (fast); not Harmony approach, but learn from them
• JavaL(?) - brazilian effort similar to Harmony

In summary, I think that Harmony is a great project. Java is going to need a truly open source implementation if in order for it to remain relevant and popular for the next 10 years. However, this is going to be a very hard project, on the implementation side. So, while the though of having an OSS JVM is exciting, I have to temper this with the fact that I think it is going to take Harmony a long time to produce a working JVM.

JavaOne: General Session: Java Technology Contributions and Futurist Panel

I got to James Gosling's general session over a half hour late this morning (the balance I had to strike between Caltrain's schedule and my sleep schedule). Here are some highlights:

NetBeans has a new set of tools for developing code for mobile phones. Visual app. builder, can also deploy code to phone from NetBeans. Even cooler, if the phone supports the correct JSR, you can do debugging of the app. while it is running on the phone. Single step, breakpoints, etc. -- all over Bluetooth!

They did a demo of an UAV that is powered by real-time Java. The conclusions:

• RTSJ determinism critical for navigational control
• RTSJ JVM enabled significant productiivity gains over C++ (don't need to worry about low-level stuff like endianess, etc.)
• Continue to perform research on newer RTSJ implementations

The summary for me is that I would like to check out real-time Java. Yet another thing on my list of "things to surf".

Sun is putting out multimedia versions of all of the JavaOne sessions onto the Internet, free for all (including slides, audio, etc.). Allowing Open Source contributions of translated audio tracks? It seems like people can watch in English, and record their own track, in a different language.

---

Shifting gears, the second half of the general session is a panel, about the future of Java. On the panel: James Gosling, Bill Joy, Paul Saffo, Guy Steele, and Danny Hillis (Applied Minds, Inc.). This was just a general talk on a bunch of futuristic mumbo-jumbo -- I wasn't really engaged to the point that I extracted anything interesting.

Sun hardware: UltraSparc and V20z

I spent some time vendor pavilion at JavaOne today. One of the vendors that I spent some time pick on was Sun. In particular, I had hardware on the brain toady, and I managed to track down like, the one person at Sun's booth, who could speak about the present and future of the UltraSparc line. In addition, this fellow was there to talk about the V20z, so I asked him a few questions about that as well.

Regarding the UltraSparc, both the UltraSparc IV and UltraSparc IIIi are currently shipping. The UltraSparc IV has both CMT (Chip Multi-Threading, sort of like Intel's Hyperthreading, but better according to Sun) and multiple cores per CPU. It sounds pretty hot. Unfortunately, it seems like it is only going to appear in Sun's higher-end servers (5U and up), in high densities. The Sun person that I spoke to wasn't sure if it would ever materialize in a workstation, but was doubtful.

The UltraSparc IV is going after highly-parallelized workloads, as is the rest of the industry. However, my group at EDS is working with some applications that are stuck on Sparc, and aren't highly parallel. So, it seems like we're going to be using the UltraSparc III series for awhile. The good news is that the UltraSparc III is up to 1.6Ghz in speed now, which is not too shabby (for a RISC CPU).

Moving on to the V20z, I cut right to the chase on this one. i knew that the only reason to buy an X86-based server from Sun would be for the management features. Luckily, I was not disappointed. The V20z has two Ethernet interfaces for the purposes of management. Even better, once you configure an IP on the Ethernet, you can SSH to it, and get full access to the serial console (OS), or the internal management console! That sold me right there. In addition, the management Ethernet ports can act as a hub, which means that you can daisy chain a rack of servers together, and only take up one switch port for management. That is really, really cool. One thing is that you have to use crossover cables, because the management ports don't support auto MDI-X (while the main GigE interfaces do).

I don't really keep up with the state-of-the-art for PC servers, but I don't think that you can do SSH management of them. Sun is definitely kicking ass here.

-Andy.

JavaOne: TS-3340: Architecting Complex JFC/Swing Applications

Where is the Pain?

• GUI creation and maintenance
• Threading issues
• Widget <-> model binding (n-tier application)
• Input validation

Reaching Nirvana

• All about frameworks -- buying, building, or using them
• OSS frameworks are ideal (great to have source code)
• building should be last resort

No uber framework

• Ideally, one framework would solve problem
• doesn't exist
• Two wannabees: NetBeans platform and Spring Rich Client Platform (RCP)
• Vibrant space (new projects popping up all the time)

NetBeans

• Doesn't address pain points for big apps
• lack of documentation (yeah, I agree)

Spring RCP

• Inspired by Eclipse RCP and JGoodies
• Not released yet, lot of code in CVS
• not ready yet, but keep an eye on it

No comprehensive framework, some smaller focused ones

• JGoodies Swing suite ($$$) - has been released, some free parts
• SwingLabs - Sun's OSS collection of helper frameworks. Also not out yet.

Solving the Pain

• DRY - don't repeat yourself. Do something twice --> build framework
• Think Ruby-on-Rails (interesting web framework)
• Ruby-on-Rails was built this way, so it was a framework that was built in an interactive manner, only for functionality that was actually needed.

Reuse hard in Swing apps, because no strong conventions, GUI layout code can be everywhere.

Solutions

• GUI builders, but with restrictions
• Use GUI builder to generate binary artifact (like XUL), user-modifiable code sits outside
• Load generated GUI at runtime, and manipulate it
• Provide standard contract for screen creation
• Introduce form abstraction (smaller than screen, larger than a widget)
• Both practices increase opportunities for reuse

Framework examples

• JFace has Window and ApplicationWindow classes
• Spring RCP defines Page and View abstraction that aligns nicely with Screen/Form concept

Threading Issues

• Swing components are not thread safe -- only supposed to be accessed by AWT event thread.
• SwingWorker (new in Java 6, being back-ported to Java 5) and Foxtrot?
• Comega - experimental programming language from MS, used as a sandbox
• Concurrency is hard -- Servlet API is admired, because it is simple and single threaded, yet it scales up
• Because there is a container that does heavy-lifting of thread issues
• Container-managed Swing (Inversion of Control)
  • Have container control object, and provide services for object
  • Load and initialize screens on background thread
  • Handle asynchronous population and action execution

Tools

• JFormDesigner - excellent GUI builder tool
• Matisse - next version of NetBeans
• FormLayout - 3rd party layout manager that kicks GridBagLayout in the you-know-where
• IntelliJ IDEA - IDE

Summary: This was a pretty good talk. The take-aways are to go and keep tabs on some of these frameworks (they may need another year), and to look into some GUI builders and 3rd party layout managers.

What sucks about JavaOne

Two things that suck about JavaOne: it is nearly impossible to find power outlets for my PowerBook, and not all of the rooms have WiFi. OSCON puts JavaOne to shame -- nearly every room has a giant block of power strips, for the geeks to plug their laptops in. It is deplorable that JavaOne doesn't have this.

As for the lack of WiFi, I'm finding myself a bit surprised by this one. I'm finding that since I am blogging the conference this year, having the web available is necessary in order for me to sprinkle links into my posts.

-Andy.

JavaOne: TS-7302: Technologies for Remote, Real-Time, Collaborative Software Development

Collaboration Technologies

• occurs within conversations, unlimited # of participants
• all messages to all participants
• conversations include multiple channels (conduit for information)
• collablets provide interface to channel

Collablets

• software component for specific type of collaboration
• stateful within scope of conversation
• only know about their own channel
• uses XMPP (Jabber)

MOXC

• message oriented XML collaboration
• web services approach to collaboration
• simple, just send XML messages using SOAP
• send messages over any transport
• can describe collablet API via WSDL, open to any web services client

All of these technologies allow for integrating collaboration into IDE. Jabber chat is one example, but can also send java code back and forth. Messaging system understands code -- code that you paste in IM is syntax colored, in the right font, same features of IDE (code completion). Can also send XML, HTML, formatted text, etc.

Can go further, and share whole files or projects. In shared file, can have shared editing, sortof like SubEthaEdit. It will lock the portion of the file, make change, when lock times out, will propagate change to other users. Remote users can compile shared project, which will actually happen on source machine (to snag all dependencies).

It seems like the point of the above technologies is to make it easy to implement your own collablets, so you can build custom collaboration modules that suit your particular project or work environment. Very cool.

What about screen sharing (code walkthrough, remote peer programming)? I didn't see the speaker demo this, but it should be possible to make a collablet that does it.

Links:

• Developer collaboration is going open source at: collab.netbeans.org
• Public collaboration service: share.java.net
• Blog about remote developer issues: http://www.toddfast.com

Also thinking about sharing debugging environment as well.

Downside: need some sort of server to do it on Intranet, with Java Server Enterprise. Close to getting it working over any vanilla Jabber server (sweet!).

JavaOne: TS-5471: Jini and JavaSpaces Technologies on Wall Street

Jini is a tool for building SOA's. The Master/Worker pattern is a common one in Jini systems.

Generic Virtual Data Access Layer (SOA)

• Distributed data, bring together (left joins?)
• Data is federated (many masters)
• Expose common Grid-like API for clients (JAR), or WebServices, or even JDBC
• Needs virtual data dictionary, metadata to describe data, to glue together
• Decompose data access into generic workers -- break down request/response into many sub-tasks
• Decouple SQL query generation from execution
• Distribute workers, get parallelism

Scalable Real-time Transaction Processing

• Parallelize transaction w/o losing FIFO ordering, and still getting 100% reliability
• Clustered JavaSpaces -- make several instances. Make reliable by replicating data in these instances.
• Build smart proxy that handles JavaSpace client requests, and distributes work into JavaSpaces cluster
• Automate deployment and restart of JavaSpace instances, using dynamic service-grid architecture -- gets you dynamic scalablity (apache httpd forking style)

Why now?

• memory was expensive -- not anymore
• Bandwidth was a bottleneck -- not anymore (GigE, 10Gig)
• Commodity HW finally enterprise grade

Building a Distributed Compute Grid Framework

• design grid applications incrementally with Jini and JavaSpaces
• from programmers perspective:
  1. how design application?
  2. how implement the design?
• too much talk about design, not enough about programming
• Good design always starts with something simple and evolves -- Jini and JavaSpaces make this easy: loosely coupled components, dynamic and flexible infrastructure
• Features can be added as needed

Grid computing framework

• master-worker pattern based compute farm
• A layer of abstraction over JavaSpaces API and Jini programming model
• Framework class design
  • Decomposer - concrete class will decide what correct subtask size is
  • Distributor
  • Calculator (processor)
  • Collector
  • Task
  • Result
  • Communicator - communication and synchronization among compute nodes

Putting the Spring into Grid

• have to consider user interface for the programme
• How can we take POJO model and bring it to Jini/JavaSpaces?
• Get a lot of power in POJO approach, because we decouple from underlying system (be it Jini, J2EE, etc.)
• Spring can do remoting without API via exporters on server side, proxies on client side (talk to exporters)

Summary: I like the idea of doing a Grid overlay of federated databases. This is something that I'm going to need to explore more on my own.

Today is just not my day for catching trains

I have been a little off kilter all day today, primarily because I am tired from my extended weekend travels. This morning, it was my strong intention to ride the 7:58 Baby Bullet Caltrain into S.F. I got to the Mountain View station in plenty of time, but was confused (once again) by the signs for the overflow parking. The signs say to follow the normal Caltrain parking rules, which require that money be paid. However, the last time I parked here (January), the parking machines that do the taking of the money weren't configured for the overflow lot.

Fast forward to today -- I assumed that the machines just had to be configured by now, so I wasted a goodly amount of time walking to the machines, finding one that was inservice, and then finding that they still wouldn't take my money! But under normal circumstances, this little detour would have been a minor annoyance. However, when I went to buy my Caltrain ticket, there were lines at every machine. And of course, the woman in front of me was trying to pass a dollar to the machine that it wouldn't take. I jammed a fresh dollar at her, allowing her to buy her ticket and get onto the train. But the doors closed before I was able to punch up my ticket.

:(

So, I took the next train, which put me into the city at least a half hour later than I wanted to be there. This threw off the whole day, as I was going to use that half-hour in order to plan out the sessions that I wanted to see.

Now flash forward to this evening. I cut out of a BOF about 30 minutes early, in order to begin my walk back to the Caltrain station. For some reason, I lost track of time, and didn't start running for the station when I should have. I got there at 9:07:30, and the train left at 9:07. This is a much bigger "Doh!", because the next train is at 10:07 PM.

:( :(

Since the 4th & King Caltrain station can be a little sketchy at night, I decided to walk around. I happened upon a Borders, where I made an impulse buy that has made me feel a bit better. But still, I hope that I have better luck tomorrow, otherwise this is going to be a damn long week.

-Andy.

JavaOne: BOF-9840: Make your java apps more powerful with scripting

These are rough notes, as I was only there for the first part of this BOF and it was pretty informal:

expose scripting interface to your program. allows 3rd parties to write code that interacts with your code (think plugin). Develop features and addons more quickly & cheaply.

idea: add beanshell to existing application. Once in place, you can use beanshell to poke and prod it, and figure out how it works. Questions like: "What happens to app if I change this value?" are easy with an application that supports BeanShell.

to support scripting in an existing app, may need to provide:

• extra API to support scripting
• debugging support
• logging/diagnostic output
• CLI for interactive control
• Editing tools for recording/manipulating scripts (macro recorder)

JavaOne: BOF-9335: Scalable Languages: The Future of BeanShell and Java-Compatible Scripting Languages

Doing JSR for BeanShell, to make it standardized, and potentially part of Java proper (someday). Will give more visibility and participation. BeanShell being developed by small team, so this will expand resources. New in 2.0:

• Full java syntax compatability
• performance: JavaCC 3.0 parser faster and smaller; caching of method resolution gives boost
• better error reporting
• Applet friendly (again) -- doesn't trip applet security; advantage of existing reflection-based implementation (do things w/o code generation)
• new features: mix-ins, properties style auto-allocation of variables (can use BeanShell as more advanced java properties file)
• Mix-ins: import java object into BeanShell namespace.

Java Syntax Compatibility

• Full java 1.4 syntax support (on all VMs)
• Some Java 5 features (all VMs): Boxing, enhanced for loop, static imports
• Core Reflection doesn't allow introspection into core types -- added this in BeanShell 2.0

True Scripted Classes

• Generated classes with real Java types, backed by scripts in the interpreter.
• Scripts can now go anywhere Java goes.
• Expose all methods and typed variables of the class.
• Bound in the namespace in which they are declared.
• May freely mix loose / script syntax with full Java class syntax.
• Full java syntax on classes -- this, super, static, instance variables, and blocks. (no way to access superclass from reflection API)
• Full constructor functionality.

Limitations:

• Reflective access permissions (knocks out applets for the scripted classes)
• bugs

New APIs:

• javax.script (JSR-223) - will be a part of Java 6, powerful API for calling scripting languages from Java
• BeanShell API compiler - have persistent classes backed by scripts.

Compiled API classes are like python -- you can take a .bsh script, and compile it into a .class file. Then it can be used by native Java code. Will it be like Python, in that if you modify the .bsh, it will automatically re-make the .class? I asked about this, and I found that this is sortof different from what Python is doing. Basically, the .class file only includes a stub, that wraps around the functionality that is implemented in the .bsh file. This stub allows the Java code to invoke the functionality of the .bsh file. Behind-the-scenes, BeahShell will launch a separate JVM for each .class file. This separate JVM will execute the code in the .bsh file.

New BeanShell community site, includes Wiki (J2EEWiki). Wiki site is beanshell.ikayzo.org/docs. Subversion for source control.

JavaOne: TS-7725: J2EE 5.0 ease of development

J2EE specification doesn't go far enough -- need "helpers" in order to be productive and effective in order to produce a J2EE application. Certain "artifacts" are common, such as:

• Generate entity beans from DB
• Using resources (JMS, JDBC, etc)
• Using patterns (service locator, etc) and Blueprints
• Provisioning server resources
• Verifying, profiling.

Offload some of these tasks to tools, others to specifications/core langauge/etc. How does this talk contrast with the Spring talk (which says that all of this crap should be handled by frameworks)?

J2EE 1.4 free tools:

• Eclipse - Web Tool Platform (WTP) / J2EE standard tools (JST)
• NetBeans - 4.1 just shipped (May), full support for all J2EE whiz-bangs

NetBeans notes:

• NetBeans can do one-click compile-assemble-startserver-deploy-execute (Run)
• Refactoring at J2EE level (class name change propagates to descriptors)
• Ant native (project in NetBeans makes build.xml). Good for nightly builds!
• Blueprints compliant -- what is this? Need to look it up. Looks like best practices for J2EE application layout.
• Debugging: hides crap from application server in stack trace. Monitor HTTP requests. J2EE verifier tool.
• Can get JBoss plugin for NetBeans.
• Wizards for making EJB calls, doing JDBC access, or sending a JMS message

Java EE 5

• "The focus of Java EE 5 is ease of development"
• EJBs as regular Java objects (standard interface for inheritance)
• Annotations vs. deployment descriptors (dependency injections)
• Better default behavior and configuration
• Simplified container manager persistence
• Developer works less, container works more (app server)

Annotations

• comments that guide code?
• alternative to XDoclet
• Syntax is to use '@' symbol

EJBs are POJOs

• only a business interface to work with
• XML descriptors replaced by annotations

It looks like if I just learn how J2EE 5 works, I can skip learning the older version, which is far harder/more complicated. EJB 3.0 requires dramatically less XML code to be written in order to work, and less Java code as well. Looks like this stuff isn't fully baked yet, however. :( See below:

Java EE 5 status

• specs still under expert discussion
• delivery date is targeted for 1Q 2006
• Many areas ready: API simplification, Metadata via annotation, dependency injection, persistence
• NetBeans 5.0 will be ready at same time

GlassFish Java EE 5 application server is some sort of new app server being written by Sun. Preview builds are available now? GlassFish purportedly works well with NetBeans. Plus, it looks like it is open source (which you know that I like).

Tools mandatory for J2EE 1.4 development. Features of Java EE 5 make development easier, and will be further assisted by smart tools. I knew that there was a new version of NetBeans out, which I was intending to check out at JavaOne. Also, it looks like there is a new NetBeans book out -- "NetBeans IDE Field Guide" which is good, because I don't like the documentation for NetBeans...

JavaOne: new format

I'm going to pick up a bit of a new format. I'm going to try and blog about the parts of the presentation that are interesting to me, getting away from a full outline of the talk. I figure that the slides can probably be found online somewhere, so I'm going to focus on what my take-aways are.

-Andy.

JavaOne: TS-7159: Java Platform Clustering: Present and Future

Research goal is transparent extension of Java programming model and facilities to a clustered environment. More for performance, than failure issues.

Design Approaches:

• Cluster-aware JVMs (potentially optimal [close to hardware], but loses portability)
• Compile to cluster-enabled layer (ex. DSM; good performance, but lose portability and impedence mismatch)
• Systems using standard JVM (transforms at code or bytecode level). lose performance but get portability

Compile to DSM:

• Hyperion - compiles to C code that is DSM aware
• Jackal - violates Java memory model

Cluster-aware JVM software:

• Java/DSM (Rice, 1997) - piggybacks on existing DSM, no JIT
• cJVM (aka trusted JVM) (IBM, 1999) - proxy objects for non-local access (smart), no JIT
• Kaffemik (Trinity college, 2001) - based on kaffe VM, scalable coherent interface, JIT
• Jessica2 (2002) - JIT support, thread migration
• dJVM (2002) - based on Jikes

Systems based on standard JVM:

• JavaParty (1997) - pre-processor + runtime compiles to RMI. Requires langauage change
• JSDM (2001) - supports SPMD apps, not full Java technology
• JavaSplit - bytecode transformation, integrated custom DSM
• J/Orchestra - application partitioning, bytecode transformation

The executive summary is that there is some work going on to make Java cluster-aware at the VM level. I'm not sure why Jini wasn't mentioned more, since it seems like a natural fit for clusters. If I ever need to do some clustering, I can check in on the above projects to see if there is a fit.

JavaOne: TS-5163: XQuery for the Java Technology Geek

What is XQuery?

• New language from W3C
• Queries XML (documents, rdbms, etc.)
• Anything with some structure
• under development, not 1.0, at candidate recommendation stage

XQuery advantages over:

• XSLT - easier to read and write, maintain; designed with DB optimization in mind
• SQL - better for hierarchical data (things that don't fit: book data, medical records, yellow pages). DB is designed for columns of numbers.
• Procedural - define what you want, let engines optimize

demo

• When pulling data out of XML, easier to show more context around the data
• Like breadcrumbs to book, chapter, section
• Then show not only the search term, but also the content around it

Loading Content

• depends on engine, indexed stores require pre-loading

Vendors

• Mark Logic (presenters, demos available), eXist (OSS), Saxon
• Coolest hidden XQuery implementation: Apple's Sherlock

XQuery uses XPath

• a matching language to select portions of an XML document
• Like RE engine for XML; "give me every one of these where that or this"

FLWOR expressions

• pronounced "flower"
• stand for: for, let, where, order by, return
• this is one expression, not five
• XQuery is technology to manipulate XML that you can find with XPath
• XQuery doesn't have to produce XML output -- can produce sequence of elements, or just plain text

Deployment: CGI-style

• Works well on web tier
• Executes in response to HTTP requests like CGI
• Speaks XML to back-end, XHTML to front end
• advantage is easy-and fast, can do blog or searchable FAQ as XQuery (backend is XML, XQuery formats and displays on frontend)

Deployment: Direct Style (POJO)

• Call XQuery stack from Java language
• Think JDBC but for XQuery
• Fits in your Java technology stack

Deployment: JSP Style

• XQuery JSP tag library
• send results straight out, or store in variables

In summary, I feel like I finally understand what XQuery and XPath are all about. This presentation gave a fantastic overview of both, in a way that was engaging and made the two complimentary technologies easy to understand. I don't know if these two technologies are directly relevant to my current work at EDS, but who knows what the future may bring. If you are working with structured data in XML, you need to check out XQuery and XPath.

JavaOne: TS-7949: The New EJB 3.0 Persistence API

Got to this one late (lunch), so this is not full notes.

Extended Persistence Contexts

• Rescue the stateful session bean from obscurity
• natural cache of data that is relevant to a conversation
• allows stateful components to maintain references to managed instances instead of detached instances

Conversations

• A conversation takes place anytime a single user interaction spans more than one request
• sometimes helpful to capture conversation in object(s), can optimize, manage lifecycle, etc.

To be quite frank, the content of this session bored me, so I exited early. The basic summary is that if you are doing hardcore EJB and database stuff, you may want to check this topic out in more detail.

JavaOne: TS-7695: Spring Application Framework

Agile J2EE: where do we want to go?

• Need to produce high quality apps, faster and at lower cost
• cope with changing requirements (waterfall not an option)
• need to simplify programming model (reduce complexity rather than hide with tools)
• J2EE powerful, but complicated

Agile J2EE: Why important?

• Survival: challenges from .NET, and PHP/Ruby at low end
• Concerns that J2EE dev is slow and expensive

Why aren't we there yet?

• Difficult to test traditional J2EE app
• EJB's really tie code to runtime framework, hard to test w/o
• Simply too much code, much is glue code (I concur, based on my experience with a J2EE portal in EDS)
• Heavyweight runtime environment -- in order to test, need to deploy

Enter Lightweight Containers:

• frameworks central to modern J2EE development
• frameworks capture generic functionality, for solving common problems
• J2EE out of box doesn't provide a complete programming model
• Result is many in-house frameworks (expensive to maintain and develop, hard to share code)

Open Source Frameworks

• Responsible for much of the innovation in the last 2-3 years
• Several projects aim to simply development experience and remove excessive complexity from the developer's view
• Easy to tell which ones are popular; driven by collective developer experience (refined, powerful, best-of-breed)
• Tapping into "collective experience" of developers

How do Lightweight Containers work?

• Inversion of Control/Dependency Injection (sophisticated configuration of POJOs)
• Aspect Oriented Programming (AOP)
  • provide declarative services to POJOs
  • can get POJOs working with special features, JMX, etc.

What is Inversion of Control?

• hollywood principle - don't call me, I'll call you
• framework calls your code, not the reverse

What is Dependency Injection?

• specialization of Inversion of Control
• container injects dependencies into object instances using java methods
• a.k.a. push configuration -- object gets configuration, doesn't know where it came from
• decouples object from configuration from environment. Values get pushed in at runtime, so it is easy to run object in test or prod.

Why is Dependency Injection different?

• configuration requires no container API
• can use existing code that has no knowledge of container
• your code can evolve independently of container code
• easy to unit test (no JNDI stub, or properties files to monkey around with)
• code is self-documenting

Advanced Dependency Injection:

• shared instance, pooling
• lifecycle tied to container objects
• maps, sets, other complex types
• type conversion with property editors
• instantiation via factory methods
• FactoryBean adds level of indirection; configured by framework, and returns objects based upon that configuration.

What is AOP?

• paradigm for modularizing cross-cutting code (code that would otherwise be scattered across multiple places)
• think about interception
• callers invoke proxy, chain of interceptors decorate that call with additional functionality, callee finally invoked, and return passes back through chain
• idea for transaction management and security
• enabling technology, for defining own services, and applying them to POJOs.

Incremental AOP

• think of it as a generic way similar to how EJB implemented
• can be implemented with dynamic proxies

DI + AOP delivers POJO ideal

• configure objects w/o invasive API

Spring Framework

• OSS project, apache 2 license
• Aims:
  • simplify J2EE development
  • provide a comprehensive solution to developing applications built on POJOs.
  • aims to address all sorts of applications, large banking, or small in-house
• easy to work with JDBC, Hibernated, transaction management, etc.
• consistency makes Spring more than sum of its parts.
• don't need to deploy, can all run from within IDE if desired.

JavaOne: TS-5958: Amazon Web Services

Terms:

• AWS - Amazon Web Service
• ASIN - Amazon Standard Item Number
• Associate ID - pass this # into all AWS calls
• REST - Representational State Transfer

Concept is the programmable website

• support for industry standards
• remote access to data and functionality
• about getting direct access to guts of website

What is AWS?

• APIs that give any developer outside of amazon programmatic access to Amazon's data and technology.
• Includes product information, customer-created content, shopping cart, etc.

Why AWS?

• Legitimize outside access, site scraping sucks
• Third-party developers extend the Amazon platform
• Harness creativity of others

Offering:

• SOAP API
• REST API
• XSLT transformation service - can apply transform to XML results before returned. Can build website with no physical template, just supply XSLT stylesheet, in order to build "virtual website".
• WSDL - documentation for schemas
• Tons of documentation & community outreach

REST vs. SOAP:

• SOAP is standard, strongly typed, requires toolkit
• REST is convention, ad hoc, easy ramp-up, prototype in browser, really easy to use. Key-value pair based. Easy to script. Develop in browser.
• REST is about 80% used, SOAP other 20%.

Getting started:

• http://www.amazon.com/webservices
• developer blog: http://aws.typepad.com
• download documentation

Summary:

• Amazon offers 3 different things via web services API
• Easy to use via Java
• WebServices is like an API for specific websites, allowing 3rd party developers to build new sorts of apps just like if you were to write an app for the Windows API.

JavaOne 2005

After a too-short recovery time from NYC, I am in San Francisco today, attending Sun's JavaOne conference. I am going to be trying to blog about each session that I attend, and then cross-posting my public posts to the EDS blogosphere. So, for my non-computery readers (you know who you are), you're going to want to ignore the next like 3 days or so.

-Andy.

Steve's wedding wrap-up

So, I have finally made it back from New York, and am reasonably recovered (as recovered as I'm gonna be anyway), so it's time for me to wrap-up the weekend. All-in-all, it was a pretty good trip. The wedding itself was great, simple and direct -- the ceremony got to the heart of the matter at hand, without getting distracted by bells and whistles. The reception immediately followed the ceremony, so there wasn't any odd gap in the day that needed to be filled.

As for the reception itself, it as also lo-key and quite well done. The food was excellent, from the hors d'oeuvre to the main course. The speeches were on topic and well done. In short, the reception was the perfect compliment to the ceremony. Sarah, Justin, Chris, and I were seated at the infamous "Table 27", with Steve's high school buddies and their significant others.

As the story goes, at the first wedding from Steve's group of high school friends, all of the friends were seated at table 27, out of 27 total tables. This table was apparently in an unfavorable place -- in a dank, dark corner in the back (dinner took over an hour to get to them). So, the group apparently made lemonade, and had themselves a whooping good time. Ever since then, there is always a Table 27 at whichever wedding they are all attending, even as if in Steve and Ginger's case, there are only 9 tables total.

After the wedding, us 4 CWRU people played a couple of rounds of Euchre (it has been positively ages since I have done that). Justin and I took Chris and Sarah to school in the first game, but got schooled ourselves in the second. The next day, we drove to New York City for about 24-hours of NYC-based fun before we all parted ways.

In the city, we stayed at the Doubletree hotel located in the upper East side, which is a 3-star hotel that I managed to snag for $100/night via priceline. I forgot to take pictures of it (unfortunately), but it was pretty schwank. Probably the nicest hotel that I have ever stayed at. After getting into town, we tried to get last-minute tickets to the Yankee game via craigslist, but weren't able to find four seats together. So instead, we went to a nice dinner with Justin's high school friend "Wolfie" (nickname). After spending way too much money on a fabulous steak at Smith & Wollensky, we wanted to hit the town.

Unfortunately, NYC is actually reasonable dead on a Sunday night, especially if you're not into the whole "bar and club" scene. So, we did what any set of self-respecting geeks would do, and saw Star Wars Episode III at one of the best theaters in Manhattan (according to Wolfie), the Ziegler. I have seen Star Wars four times now, and I can't remember the last time I have seen a movie four times in the theatre. Maybe I never have. Anyways, Star Wars is that good (in my opinion).

Anyways, the next day, we went to the top of the Empire State Building as a group, and afterwards Chris and I parted ways with Sarah and Justin. At that point, I didn't have too much time left before I had to start my convoluted journey to the airport, so Chris and I just kindof walked around in the light rain. At one point, I was asking Chris why he said he would never want to live in NYC, when he is on record as saying that he could do the city-living thing in Portland. Chris said something along the lines of:

"New York City is just too big. Too many people, too much going on.... (long pause) And plus, there is some guy peeing over there in the corner"

He said it nonchalantly, as if it were a planned part of his argument, but sure enough, there was some dude relieving himself as we were walking by the interior of an L-shaped corner of some building. That's NYC for ya'. :)

-Andy.

Group picture from the wedding

Me, Justin, Sarah, and Chris:

Steve and Ginger

Steve and his new wife Ginger, cutting the cake:

JetBlue

So, for my trip out to the greater NYC area, I decided to fly JetBlue from San Jose to JFK. Primarily, I made this decision because they have a direct flight from California to New York, its cheap, and the idea of in-flight TV appeals to me.

So, the TV worked mostly as-advertised on the flight out. It cuts out occasionally, when the plane loses direct line-of-sight with the satellite. Other than that, you can watch like 36 channels from your seat. The only problem is that these channels are the same that you would get on DirecTV, which means you get commercials. I am so broken by my MythTV box, that I can't deal with commercials anymore. I also haven't channel-surfed in like, forever, and I have grown out of that as well.

Anyways, everything was flight-related was smooth on the way out to New York. Old man Murphy has struck, however, and I am hitting some snags trying to get back. There is some rain in New York today, which appears to be causing delays. Not only that, but there is really no room to sit near my gate, so that I can stay on top of when I can board. Even if there was room to sit there, I probably wouldn't -- because the only place that I could get the free WiFi to work is quite a bit away from my gate. I hope I don't miss it, being engrossed in all of this WiFi...

-Andy.

Those damn Erie boys...

While Sarah, Justin, Chris and myself were the only representatives of Steve's friends from CWRU, there was quite a strong high school contingent. Steve's friends from high school are pretty great -- really funny, spontaneous, and tight-knit. Luckily, we got to sit at their table (table 27 out of 9 total tables). Sometimes we took part in the antics, other times, we just captured them:

L-R: John, Tom, Rob, and Ryan. Horizontal: Steve

-Andy.

Chris doin' schomthin' schtoopid

A picture of Chris, from when we were on a mission for snacks while hanging out at Sarah and Justin's hotel after the wedding:

Wacky fun.

-Andy.

Off to New York

I'm currently at SJC airport, waiting for my JetBlue flight to New York. I'm going to meet Justin, Sarah, and Chris there, and together we're going to head up to Albany for Steve's wedding on Saturday. Then we're going to have about a day in NYC proper, and I will come back to the Bay Area on Monday night. It's going to be a fun trip.

-Andy.

Open Source vs. Commercial Source: where is it headed?

I read a great interview with Linus Torvalds the other day. The main thrust of the interview was questioning Linus as to where the Open Source vs. Commercial Source divide is ultimately headed. Pretty interesting stuff, and well worth a read.

I have been doing some thinking about this as well recently, as I try and evangelize Open Source at EDS. My thoughts are pretty similar to where Linus is at. Open Source is going to continue to commoditize certain things like OSes, browsers, and potentially even office suites. The key for Closed Source commercial vendors is going to be to stay one step ahead of the curve, and earn their revenue by innovating. People will pay in order to be at the cutting edge, the state of the art. And companies will pay for support. Those are the two spaces that I increasingly see commercial vendors playing in.

-Andy.

Album reviews

Time for another installment of my quickie album reviews:

• Sleater-Kinney - "The Woods": The new album from my perennial favorites from the pacific northwest, Sleater-Kinney. This album is quite unlike all of their previous albums -- much dirtier, louder -- offering up more of a sonic assault than a dance beat. For the first week or so, I'll have to admit, I was a little bit depressed because I did not like this album. But then I saw Sleater-Kinney perform it live, and I started to warm up a bit. And I have continued listening, almost every day, and as I have done so, my admiration for this record has only grown. Standout tracks include the quirky "Modern Girl", and the totally stupendous, best-Sleater-Kinney-song-ever, "Night Light". This album is strongly recommended for any Sleater-Kinney fans, but probably won't win anyone over to the band if you haven't liked them previously.
• Ivy - "In the Clear": Amazing album. Ivy is one band that consistently delivers on the great music. I am really into this album, I think that it is every bit as good as "Apartment Life", if not even a notch or two better. Standout tracks include "Four In The Morning" and "I've Got You Memorized". If you looking for some mellow, poppy rock with strong female vocals, you cannot go wrong with this.
• Coldplay - "X&Y": Terrible! I am so shocked by this, because Coldplay supposedly delayed this album in order to bring it up to their standard of quality (which is pretty darn high). Sure, this album is polished, and the songs all "feel" right, but there something lacking. After listening to this album, I am left with nothing. Nothing sticks, it is all monotonous and repetitive. Coldplay is coming to the bay area in August, but I'm not so sure that I even want to go anymore, based upon this album.
• Muse - "Absolution": This is one strange band. This CD alternates between totally heavy, flat out rock, and passages that sound like classical music. It is really amazing how this band is able to shift musical styles so seamlessly, without it seeming forced or out of place. This disc has slowly been growing on me as well. The standout track is "Hysteria", which is one of the "heavier" tracks, but still quite well done. Just bear in mind that it isn't 100% representative of what you will find on this CD.
• Queens of the Stone Age - "Lullabies to Paralyze": Another solid effort from Queens of the Stone Age. I don't know that it is quite as good as their previous effort, "Songs for the Deaf". Gone is the screaming from Nick Oliveri (which is definitely a good thing -- after awhile, those tracks were the ones that I skiped on "Songs for the Deaf"). This disc contains a couple of stand-out songs that have some great guitar grooves and decent lyrics. As a whole however, it doesn't really stand out in my mind like the previous album.
• Minus The Bear - "Highly Refined Pirates": Minus The Bear is awesome! They won me over when I saw them live, and this CD is totally amazing. Great musicmanship, with innovative guitars combined with electronics. The lyrics are quirky, fun and unabashedly heterosexual -- mostly about partying and going after girls. Strongly recommended.
• Nine Inch Nails - "With Teeth": Not recommended. I bought it based on the strength of the song "The Hand That Feeds", which I saw on a long-form commercial on late night TV. That song is pretty decent, but the rest of the album doesn't faire as well. Most of it is slow, 80's-synth-pop-esque, without any driving beats or melodies that really stick in your brain. An utterly forgettable effort.
• Umbrellas - "Umbrellas": This is another solid, lo-key album. This band is from Southern California, but sound like they are from the UK. Beautiful guitars, light vocals, and an overall tight sound. The standout track is "Ghost", which is simply an amazing song. Strongly recommended.

-Andy.

Believe-it-or-not, but I actually had a good day at work today!

So, I couldn't have predicted this when I woke up this morning, but today was a pretty gosh-darn good day at work. For the last several months, I have been evangelizing blogging, and how I think it could really help EDS. I actually started thinking these thoughts after attending Bloggercon last year. My first attempt at blogging was to pitch the idea of allowing me to start up an external blog on eds.com to some random people within the company.

Obviously, that didn't go anywhere.

So, I refactored my idea, and pitched the idea of blogging internally, to my immediate team. Well, my boss bit on the idea, and gave me the freedom to explore this (after we shipped our code two weeks ago, of course). So, I grabbed some OSS blogging software, and got something setup at work. I've been blogging for about two weeks now, and it has been going pretty good. At least, it's making me feel better about work, and it is something that I really look forward to. So far, I have been posting about once a day, except for this week, where I have been posting twice a day.

In fact, I was getting ready to write my first post this morning, when one of my co-workers alerted me to the fact that EDS announced a corporate blog today [registration required: use bugmenot]! The url is http://www.eds.com/blogs - go and check it out!

So, it looks like I won't be "the one" who brings blogging to EDS. But that's okay, I'm just happy that there are some other folks there who are on the same page that I am. What's good is that I am now getting plugged in with some people in EDS who "get" blogs. My whole master plan for this blog that I'm doing at EDS isn't just for me to have a place to write, but to get lots and lots of people in EDS sharing information through blogs. Stage one has been to setup a platform (done), and now I'm in stage two, trying to recruit blogging soldiers for my war on how my company communicates internally. I felt like I made a lot of progress on this front today -- so yeah, it was a quite unexpected, but all together good day.

-Andy.

More details of "The Transition"

I just stumbled across Apple's Universal Binary Programming Guidelines document. It looks like there is quite a bit of detailed technical information in this document, including some information on Rosetta. Some bad news: Rosetta cannot run Classic (MacOS 8/9 apps), and Rosetta only emulates a G3. That means that any software that requires a G4 or G5 is out. In addition, Rosetta cannot be used to emulate kernel extensions, so an x86-based mac is going to need new drivers for all of your old hardware. Is this going to be a new form of "driver hell"?

-Andy.

Shocked and Awed

So, Apple did it. They announced that they are switching the Mac platform to Intel processors capable of running the x86 instruction set. Apple knows how to do these sorts of transitions, and as such, I really cannot fault their plan for making this transition. As of today, they already have a build of Tiger running on x86 where "almost everything works". In addition, they have a new version of Xcode, which supports building applications that can run on Tiger/x86. This means that pretty-much as of now, developers can start porting their code over to the new platform.

In addition, Apple will provide emulation of PPC binaries in Tiger/x86, to ensure a smooth transition. This is really important, because people aren't going to run out and upgrade all of their applications right away. In addition, it is important to ensure that using Tiger/x86 is still a "mac-like" experience. If users need to contemplate as to wether or not they need to download the "PPC" or "x86" version of an application -- then Apple will have lost. But with Rosetta and universal (or "fat") binaries, even grandma will be able to survive this transition.

But there are still a lot of details that Apple hasn't covered. They didn't say if they were going to use an Intel chipset or not (but hinted that it would be so). They also didn't cover if Tiger/x86 would be 64-bit (using the x86-64 instruction set), but it probably will be 64 bit. They also didn't talk about their dual-processor strategy. My guess is that they will follow Intel's lead. Intel is pumping dual core CPU's for the mass market, and keeping SMP in the server space (with the Xeon). While we could see a Xeon-based PowerMac, I'm not so sure that is likely (Xeon's are quite expensive). And of course, they didn't talk at all about how they would keep people from running MacOS X on non-Apple hardware.

Phil Schiller did say "We will not allow running Mac OS X on anything other than an Apple Mac". Note that he didn't say that Apple wouldn't support this. His wording is that Apple would prevent running Mac OS X on non-Apple hardware. So, it could be that Apple will leverage some sort of Intel DRM after all, as I wrote about on Saturday. But at this point, it is all speculation as to Apple's exact plans.

All-in-all, I'm not so sure that this is a good move for Apple. I think it is somewhat prescient that there is no mention of this switch on the main page of Apple.com - I had to dig in order to find the press release, in fact. I think that Apple is going to have a very hard time selling x86-based macs, purely from a psychological perspective. I mean, picture it -- you'll be able to go to your favorite computer store, and make an apples-to-apples (no pun intended) comparison between an Apple box and a Wintel box. These two hypothetical machines will have the same CPU, RAM, Graphics Card, HD, etc. And they will also have two very different prices. So it will be evident, to all consumers, just how much the "Apple tax" is. And I don't think that people are going to go for it. Hell, I think that I am going to have a hard time going for it. In the laptop space, Apple still has a strong chance -- design matters quite a bit more in laptops than it does in desktops.

So, is this "the end" for Apple? Probably not, but it could spell doom for their hardware business. It is too early to tell. What I do know is that I have pretty mixed feelings about this switch, and that Steve Jobs has huge balls.

-Andy.

Bitchin' Sleater-Kinney poster

Finally, my last post about the Sleater-Kinney concert. I bought a sweet poster, from the cover artwork for the new album:

It even came signed by the band!

-Andy.

As seen at WWDC...

On my way home from Sleater-Kinney last night, I just happened to accidently drive by Moscone on my way home. As I drove by, I noticed that they already had all of the big banners up for WWDC. There were a series of banners all hyping Spotlight. Each banner featured the Spotlight search box, with the slogan "You can find it in Tiger". So, there was one where the phrase "your killer app" was typed into the search box.

But the one that made me laugh (as I was driving home), was the one that said "Longhorn - You can find it in Tiger". Man, Apple's PR really shouldn't be tweaking the sleeping giant, but it sure is awful fun.

-Andy.

If you squint, you can make out the band...

Sleater-Kinney, live at the Warfield. I believe that this photo is from the end of their set.

-Andy.

The Marquee

I have learned, that if you want to get a photo of the marquee for a show, you have to do it before the concert. Because they rip that sucker down during the encore.

Sleater-Kinney live in San Francisco

I just got back from seeing Sleater-Kinney play a show at the Warfield in San Francisco. And as always, they totally kicked my ass. Janet Weiss is such an awesome drummer, words just can't describe it. Which isn't to say that Corin and Carrie don't kick-ass as well. That's not what I'm trying to say at all!

The started off with "The Fox", the first track from their new album, "The Woods". I'm still not down with this new album yet, but I've only listened to it a half-dozen times. They played pretty-much everything off of the new album, including the poppy-fun song "Modern Girl" (which I think that Janet messed up), and my super-all-time-favorite (I really like this song): "Night Light". I think that "Let's Call It Love" segued right into "Night Light", just like on the album.

They also played a fair number of songs from "One Beat", including: "Combat Rock", "Step Aside", "Sympathy", "Light-Rail Coyote". But by far, the real treat, was that they played some older songs, including:

• "Was It A Lie?" (from "All Hands On The Bad One")
  
• "Not What You Want" (from "Dig Me Out")
  
• "I Wanna Be Your Joey Ramone" (from "Call The Doctor")
  

In fact, the entire encore was all old songs (there are probably a few that I'm forgetting). It's probably bad that I really appreciated the older stuff, but I'm still holding out hope that I'll fall in love with "The Woods", as I have with every other Sleater-Kinney album...

-Andy.

Apple switching to x86?

In the last several days, several rumors have cropped up saying that Apple is going to switch the Mac platform from PowerPC processors made by IBM and Motorola to X86-64 processors made by Intel. Of course, this is not the first time that the rumormongers or pundits have predicted such a switch. And every time, it hasn't happened (for reasons that I mostly agree with).

Most of the discussion that I have seen has revolved around how "hard" the switch would be, in terms of all of the applications that would need to be re-compiled for a totally different CPU instruction set. And while I grant that would be a challenge, it is not an insurmountable one, and certainly, it isn't what has kept Apple from making the x86-switch.

What I haven't seen discussed, is the "real" reason why Apple hasn't switched to x86. In my mind, Apple hasn't switched to x86 because, if they did so, they would ultimately be killing their hardware business. The reason why is quite simple: if Apple were to release a build of MacOS X that was compiled for the x86 instruction set, people would take that build, and run it on non-Apple hardware.

Now, I'm assuming that an Intel-based Mac would contain some Apple-proprietary hardware, that MacOS X for Intel would require to run. However, any protection that Apple could come up with would be easy to defeat. Heck, the OS that forms the foundation of MacOS X, Darwin, is already open source. So, Apple would have to embed their security into the GUI layer. But still, that would be easy for the hackers to defeat. This sort of cracking has been around for as long as there has been copy protection, and it would be broken in a matter of weeks, if not days.

So, up until now, I haven't seen a whole switch to x86 as being "in the cards" for the Mac platform. I knew that if Apple did it, then people would start running MacOS X on non-Apple hardware, then less Macs would be sold, until Apple was either ruined or exited the hardware business altogether. Apple is run by some smart people (some of whom hate clones), so I know that they would never allow this to happen. Yet, I think that such a switch may be imminent. What do I know that I don't see anybody else talking about on the web?

Last week, Intel announced their newest "Pentium D" processors, along with a new chipset, the 945g. In the announcement, Intel made an oblique reference to the fact that these new chips have the latest iteration of their DRM technology built-in. All of the press coverage that I have seen of the DRM has focused on "protecting digital media" from thieves. While I'm sure that is what Intel is aiming at, I think that Apple could have a different purpose in mind for this DRM hardware.

Consider if all of the non-open source bits of MacOS X for Intel were shipped from Apple in an encrypted format. The DRM technology in the Intel CPU and chipset is able to decrypt the OS into memory, in such a way that there isn't much of a performance penalty. Furthermore, the MacOS itself leverages the DRM hardware, to prevent hackers from reading the OS that has been unencrypted in memory. Now, the only piece that is missing is the special key, that the CPU uses to un-encrypt the OS. This is where Apple's hardware engineers step in, crafting a special chip that holds the key, and is soldered onto the Apple motherboard.

From a very high level, it seems like such a scheme might be difficult enough for the hackers to crack, that it will keep widespread adoption of MacOS X on non-Apple hardware at bay. I think that this is why all of the rumors have been saying that Apple is switching to "Intel" and not "x86". If they just wanted to switch to x86, why wouldn't they consider AMD? I think that Apple would really like to go to AMD, because they are really kicking ass right now, but they won't, because AMD doesn't have the DRM technology that Intel has.

So, while I'm not saying that I want Apple to switch to x86, what I am saying is that for the first time, I see how such a move could happen. Monday could be an interesting day.

-Andy.

[UPDATE]: MacOSRumors has a nice roundup of the Mac-on-x86 rumors that have occurred over the past several years. And John Gruber has a great analysis of the whole situation as well.

[UPDATE2]: The New York Times is corroborating the switch to Intel story. The interesting part of this article is the discussion around the financial relationship between Apple and IBM. According to the NYT, less than 2% of the production capacity of IBM's Fishkill, NY plant goes to Apple processors. And the NYT says that IBM is probably barely breaking even making processors for Apple.

[UPDATE3]: Daring Fireball has some more odds 'n ends, his bet is Intel PowerPC's. And Leander Kahney mentioned the Intel DRM, but thinks that Apple wants it in order to woo Hollywood with some sort of oft-rumoured iTunes-for-movies.

Of course, one monkey wrench in all of this speculation is that Intel is now retracting their recent statements concerning DRM in the new Pentium D.