Several people have commented on my recent posting about Spring, and I want to make something clear: I'm not saying that Spring (or Hibernate, or EJB, or anything else) is a bad technology. I'm saying that walking up to every project, assuming that Spring will be THE answer, is bad. This kind of dogmatic approach--which, by the way, more than anything else is what led to the downfall of EJB as a popular technology--is bound to bite you in an uncomfortable place sooner or later.

One commenter, in particular, chastised me for not providing specific examples regarding where Spring may fail; I'm not going to stand here and make an exhaustive analysis of Spring's strengths and weaknesses. Besides being something that's already being done elsewhere, it would be beside the point that I'm trying to make--that dogma of any form is bad.

Look, so you've been successful with Spring on a few projects--that's good, and I encourage you to consider Spring again for your next couple. But don't make the dangerous assumption that using Spring will always yield success. In fact, let's take this out of the realm of Spring entirely and restate the point: "Look, so you've been successful with [[TECHNOLOGY-X]] on a few projects--that's good, and I encourage you to consider [[TECHNOLOGY-X]] again for your next couple. But don't make the dangerous assumption that using [[TECHNOLOGY-X]] will always yield success." (Where [[TECHNOLOGY-X]] can be, but isn't limited to, one of Spring, Hibernate, EJB, J2EE, COM+, WCF, CORBA, XML services, relational databases, stored procedures, managed-code-inside-the-database, highly denormalized relational data, highly normalized relational data, ....)

Recently, while cruising the Internet (and, in particular, the Lambda-the-Ultimate site), I ran across the Scala programming language, latest brainchild of Martin Odersky (of GJ fame, which of course was derived from Pizza, among others). It's another entry in the hybrid functional/object language space, and as such, has a lot of interesting features that Ruby holds, but runs on the JVM (and can actually cross-compile into a .NET assembly, though it does require some slightly different mappings), and as such means developers don't have to make a wholesale commitment to the Ruby interpreter.

I thought I'd share some of the more interesting bits of Scala in this and a few more blog posts.

The high-level stuff

First of all, from the Scala website, let's get the high-level overview stuff out of the way:

• Scala is object-oriented. Scala is a pure object-oriented language in the sense that every value is an object. Types and behavior of objects are described by classes and traits. Class abstractions are extended by subclassing and a flexible mixin-based composition mechanism as a clean replacement for multiple inheritance.
• Scala is functional. Scala is also a functional language in the sense that every function is a value. Scala provides a lightweight syntax for defining anonymous functions, it supports higher-order functions, it allows functions to be nested, and supports currying. Scala's case classes and its built-in support for pattern matching model algebraic types used in many functional programming languages. Furthermore, Scala's notion of pattern matching naturally extends to the processing of XML data with the help of regular expression patterns. In this context, sequence comprehensions are useful for formulating queries. These features make Scala ideal for developing applications like web services.
• Scala is statically typed. Scala is equipped with an expressive type system that enforces statically that abstractions are used in a safe and coherent manner. In particular, the type system supports generic classes, variance annotations, upper and lower type bounds, inner classes and abstract types as object members, compound types, explicitly typed self references, views and polymorphic methods. A local type inference mechanism takes care that the user is not required to annotate the program with redundant type information. In combination, these features provide a powerful basis for the safe reuse of programming abstractions and for the type-safe extension of software.
• Scala is extensible. The design of Scala acknowledges the fact that in practice, the development of domain-specific applications often requires domain-specific language extensions. Scala provides a unique combination of language mechanisms that make it easy to smoothly add new language constructs in form of libraries: any method may be used as an infix or postfix operator, and closures are constructed automatically depending on the expected type (target typing). A joint use of both features facilitiates the definition of new statements without extending the syntax and without using macro-like meta-programming facilities.

Enough overview. Let's look at code.

Hello, Scala

OK, Scala really isn't all that interesting as a Hello World program, but it does highlight one of the more interesting elements of Scala that I already like:

object Hello {
  def main(args: Array[String]): Unit = {
    Console.println("Hello, Scala!");
  }
}

Some of what's interesting to see here is that the Scala compiler actually produced two .class files--one entitled App.class, another called App$.class, the second App$ class apparently to provide "module" behavior (which I suspect is related to the singleton-ness of the object declaration in the code). As you might expect, Scala injects some additional support methods into both classes, including getScalaType, which is obviously intended to return the type of the object to Scala, just as the .class or getClass does for Java. Which brings up another interesting point.

Scala presents a unified type hierarchy, such that scala.Any is the root of the type system, and (like the CLR) is bifurcated into two basic elements, one being the object-family of types (java.lang.Object, known to Scala as scala.AnyRef) and the "primitive type" family of types, known to Scala as scala.AnyVal. Scala calls these reference classes and value classes, respectively--the same monikers the CLR uses. There's also reference to a type scala.All, which the introduction/tutorial page puts at the bottom of the type hierarchy, apparently inheriting from everything, but I'm can't find documentation on it or what purpose it serves. *shrug* More on that later, I guess.

Another interesting tidbit is that we can run Scala interpretively, the same way we can do to Groovy:

> scalaint -nologo HelloWorld.scala
> HelloWorld.main(null)
Hello, world!
(): scala.Unit
>:q

Update: Forgot to mention, Scala has another interesting element to it that makes it very interesting to Ruby in much the same way:

object HelloWorld2 with Application { 
  Console.println("Hello, world!"); 
}

I consider myself a relative newbie to Scala, but as I progress through the language and see some useful applications of features, I will blog more. I'll also blog some of the features themselves, but you can find that for yourself by working through the Scala tutorial material on the site, if you're so inclined. In the meantime, catch the presentation I'm doing on Scala at the No Fluff Just Stuff symposiums, starting 2Q this year.

And, by the way, for those of you in the .NET space, Scala does, as I mentioned before, cross-compile to .NET assemblies, though I haven't spent much time exploring this. Frankly, I'd be more comfortable using Scala in the .NET world if there was a .NET-based compiler for it, rather than having to install a JRE just to run the compiler, but F# serves much the same space in the .NET world that Scala does here, and that's another language I'm pursuing with some vigor, as well. More on that later.

There are a few things, I've found, that are fun about being a speaker and general rabble-rouser, but none of them are nearly as much fun as when I get an opportunity to interview industry icons and ask them all my questions on camera. In this case, while at JavaPolis2005, my victims were the well-known pair Joshua Bloch and Neal Gafter, who, more than anyone else in the world, are most directly responsible for the language features that came in Java5. I tried to keep the interview pleasant and friendly, but I did ask the questions that've bothered me for a while, like "Why did generics end up the way they did?", "Is Java too complicated and hard to use now?" and "What are you doing at Google these days, anyway?"

Online (registration required) at the JavaPolis2005 site. Keep an eye on the site for the other interviews Dion did, as well as one more I did with Brian Goetz, who's got a GREAT book on Java Concurrency coming out in 2006.

CrazyBob just wrote about how he "doesn't get Spring", and although it runs the risk of sounding like something from the "Me, too" bandwagon, I have to say, I agree with him (and have been saying this in conferences and panels for a while now):

Even worse, I've noticed what I consider to be a dangerous and blind increase in the rate of Spring adoption. I've yet to read a critical article or book on Spring. It seems like everyone loves Spring except me.

Maybe Spring adoption is a knee-jerk reaction to J2EE. "J2EE is bad, and the Spring guys say their stuff is better, so Spring must be good." It doesn't work that way.

For starters, I'm with Bob on the statement that blind adoption of Spring is dangerous. I wrote once before that dogma of any form is bad, and Spring dogma is just as bad and just as dangerous as J2EE dogma ever was, for much the same reason: dogma discourages thinking. Walking onto a project, prepared already to believe that Spring is the best solution to the problem, without considering the context, is just as bad as when we did that with J2EE. In fact, any technology can fall into that trap, be it Ruby, .NET, J2EE, Spring, LAMP, Vista, COM/DCOM/COM+, you name it. ANY kind of dogma that allows developers to shut off the analytical part of their brain is dangerous. Spring is a useful technology, no question. But so is J2EE, and so is .NET, and so is LAMP, and...

Don't ever make the mistake of letting dogma drive your technology decisions, period. No matter who justifies them. I thinke states it best when he says

If you do [adopt Spring], go in with your eyes wide open. Be skeptical, critical. Just because someone has a popular Open Source framework, they have slick marketing, and they're supported by a big vendor (IBM pushed Struts on me for a number of years after all), it doesn't necessarily mean they know what's best for you or even that they know better than you.

Bob then goes into how he likes the setter-injection that Spring provides; I personally don't have the same degree of fondness for dependency injection, to be honest: I find JNDI (and Service Locator) to be a superior approach, mostly because with the Service Locator, I can control when the resource moniker is resolved, meaning that if the resource should fail somewhere during the call, I can control where and how I go back to the Service Locator for a failover attempt. More importantly, I can re-resolve the resource as my failover policies permit, and I'm not held hostage to how--or mre importantly when--the container decides to inject the dependency.

At the end of the day, it's important to remember that "lightweight" and "testable" doesn't have to mean "Spring". In-process testing of EJB components is possible thanks to the in-proc nature of the OpenEJB stack. Testability of JNDI is easily accomplished with unit tests that use the Hashtable JNDI provider that Sun makes available in the Java Tutorial, if you want or need to test the Service Locator code itself. Or, you take the "black box" approach (as some recommend for servlet containers), and test your code through the container itself by doing the heavierweight communication through the communication stack from out-of-process calls. In the end, it's not the APIs that define the tool's testability, but the ability to embed the tool inside a unit-test environment.

Would I recommend Spring? Certainly, under the same circumstances and for the same reasons I'd recommend J2EE: when it's appropriate, because there's some good stuff there, and it's well-known and an official (in J2EE's case) or de-facto (in Spring's case) standard.

Oh, and let's not forget, this applies to any technology, including the upcoming rise of dynamic languages...

Billy Hollis, famed Visual Basic lecturer and secret programming language anthropologist, has compiled a succinct history of programming languages. As he puts it,

If you like VB, look at the history of the C family [of languages] first. If you like C#, Java or C++, look at the history of the BASIC family first.

Happy Friday.

A number of you have made comments about my LINQ paper, and rather than respond in comments in turn, I thought I'd gather them up and respond to them en masse. So, without ado....

Stu Smith said:

Nice article. Two things occur to me immediately...

1. Based on my current understanding of LINQ, it's purely for querying, and so compared to most O/R systems it lacks caching support. (ie its queries may be optimal but that's not much consolation if it keeps re-executing them).
2. The O/R system we use (which admittedly only needs to support a particular kind of application) solves the 'lazy load vs N+1' issue by generating joined queries based on either the path taken to the data, or on particular routes to a marked-up tables. ie, if you navigate from a Customer to a collection of Orders, that's a single select. If you then start iterating the Orders and inner-iterating the OrderDetails, then on the first one a second joined select is issued, and for subsequent iterations the data is already cached and thus no further SQL statements are emitted.

1. No, LINQ can, in fact, do any sort of relational manipulation, including INSERTs, UPDATEs and DELETEs, but the real strength of the language integration is in the query aspects, particularly the fact that LINQ can do these queries across any rectangular data store, so it's fair to say that LINQ is mostly about query.
2. I'd be interested to hear more about your solution to solve the lazy-load issues, partcularly how you handle the situation where you need to display only a small part of the full OrderDetails data--remember, part of the criticism of O/R is that they either eager-load too much, or lazy-load too much, and can't infer the amount or areas of data to retrieve that's "just right".

Bryant wrote:

I thought the article was well written and informative. While I think it's cool that I might one day be able to use the same object model to query databases, XML documents, and even the file system I still feel compelled to look back upon my days as a DBA. This looks a lot like building ad hoc SQL statements in the code except we're a little more type safe here. LINQ still does not answer the question of storage abstraction. The developer still needs an intimate knowledge of the database structure. So, LINQ appears to cover "Conflicting type systems" and maybe "Transactional boundaries" and "Query/access capabilities". There are still four more items in your list that I don't see being solved with LINQ. Your article was a great read but sorry, I am still not excited.

James commented:

I thought the article was great! I'm a little unclear as to why it's not getting ranked better on MSDN but for someone who didn't really understand/appreciate the problem domain LINQ is serving, your article really got me thinking and cleared up a lot of fogginess in my mind. Excellent work!

Andy Maule said:

Very interesting! I liked the discussion of Rail's ActiveRecord which I think is an approach that most people miss when talking about OR Mappings.

There's a good research paper discussing the same stuff here. It mentions something recently developed for doing statically typed queries in Java 'Native Queries' which is an interesting comparison to LINQ. Anyone interested in this area should take a look.

I'm currently doing a PhD in this area, and I have to say that LINQ is making things very interesting.

Karmencita is my lightweight alternative for in memory object querying.

As for the rest of you who offered kudos (Bart De Boeck, Dan Kahler, Paul Wilson, Eric Bachtal), thanks; every author likes to know that their work is appreciated, particularly when so much of what they say seems to stir up more controversy than discussion.

Matt Morton commented, "One might be able to say that Ted Neward is cynical about any new technology. You might also say he puts himself in the position of the "old" kermudgeon (sp) who opposes anything new and cool." Yep, guilty as charged, for a very specific reason.

Ages ago, when EJB first shipped, I was one of the first who looked at it with stars in my eyes. It seemed like such a great, easy solution to all the problems of developers building server-side systems (and I'd done a C++-based 2-tier, CORBA-based 2-tier and Java/NetDynamics-based 3-tier system before this, so I kinda fit into that space already). I was excited. I was ready to swear it to all my friends. And then....

It was a lunch with Don Box and Kevin Jones, shortly after I'd joined DevelopMentor, and I asked Don and Kev about EJB. Don looked at Kev with this silly grin on his face, and Kev just shook his head and said, "It's a thing on a thing. That's always slower than just a thing." Slowly, the light dawned. Over the course of several conversations with Kev and Don later, I came to realize that EJB wasn't a distributed object technology, but a component technology focused on transactions. Over time, developers' stupidity in using EJB for their single-database simple-HTML-form apps drove me to be widely proclaimed as an "EJB expert who consults against EJB", which isn't exactly correct--I've recommended EJB in scenarios, but only where it seems appropriate.

Which, if you think about it, is what we're supposed to do: recommend tools where they're appropriate.

What does this have to do with being a curmudgeon? Simple: I trust no technology until it proves itself to me. Our industry is SO filled with hype, it's surprisingly easy to get caught up in the energy and excitement that surrounds a new tool, particularly those that deal with presentation issues. (Face it, folks, the "jazz factor" surrounding Avalon/WPF or Ajax is exponentially higher than that surrounding RIFE/Continuations, despite the fact that the latter is far more interesting from a technology perspective. Why is this? Because you can SEE the niftiness in Ajax; the continuations story isn't something you can show off to your mom or impress your significant other.) I look at new tools, new technologies and deliberately look to find the flaws, the various fallacies they fall prey to, and I routinely caution people against them JUST because they're new. I would much rather err on the side of caution and hestiation than fall into the trap of hyperbole and bandwagon, because I think, ultimately, it's a more responsible position to my clients and audience.

I don't think I'm unjustified in this position: there's an unhealthy absence of cynicism in our world right now. My two big examples: the terrible tragedy of the miners in West Virginia (why didn't anybody in the media CONFIRM the story of their rescue before reporting it?) and the South Korean human cloning story. Or the supposed report of "cold fusion" from a decade or two ago. Our industry could use, I think, from a large dose of, "OK, so you've created a new framework. What's it to me?" right now.

Matt went on to say,

I dont totally agree with #4 though. When a large scale Ruby project fails it wont be because of the language. Just as it is faulty to claim a language will reduce project failures, it is just as faulty to claim that a language or platform will be the cause. Projects fail because of people, plain and simple. People in general have trouble being honest especially when they have something vested emotionally (or financially) in a project. Perhaps this is what he is getting at. The proponents are so emotionally involved with Ruby that when less experienced folks try to apply it to a larger scale the project, it will blow up.
Personally I have found that Rails and Ruby are a joy to use. I guess then you could say that I get emotionally involved with things that bring me joy. Perhaps Rails strength is its weakness. It is such a joy that it blinds you to its true uses.

Which, if you think about it, is exactly the same thing that happened with EJB before it.

Lego, those folks who brought you Mindstorms in the first place, have done it again--they've announced a next-generation programmable brick, the NXT, that offers some really cool enhancements, including Bluetooth capability. Suddenly, the old Robotwar clones from ages ago take on an entirely new meaning....

More interestingly, supposedly they've announced that the VM itself will be documented, which leads me to wonder how long before we see J-NXT and NXT#. It's amazing how the managed environment is just spreading like wildfire through the world, if'n you ask me....

Hey, Santa, if you're listening, this just went on my list in a BIG way.

So the December CTP of $g{Vista} is available, and I'm finding a recurring problem trying to install it into VMWare. When I tried this with the Beta1 of Vista into VMWare 5.0, the same problem occurs as what I'm getting now: when trying to boot off of the .ISO inside of VMWare (in other words, not physically off a burned CD/DVD, but out of the .ISO image itself mapped into the virtual CD in VMWare), I get a BSOD every... single... time. Is this indicative of a f-ed up installation of my VMWare image, is this a known bug in Vista (sidenote: yes, I know about the raw partition issues with Vista, but doing an XP-first install of Vista gives the same BSOD on reboot), or is it just the combination of ISO-image-and-VMWare? Anybody got ideas for a workaround or a fix?

I've been contacted by a third party (not a recruiting agency) who's having a hard time finding a J2EE architect with familiarity/expertise with concepts of architecture and the low-level chops not to lose sight of the code. To put it in their words:

This is strongly influenced by component-based methodologies such as OpenDoc, but would be extending the RCP Platform developed by Eclipse, and encompassing other concepts from systems such as Squeak... We are having trouble finding someone senior enough to understand the conceptual architectural issues, but technical enough to know important lower-level details such as how design choices will effect performance and scalability.

By the way, DON'T send me your resumes--in your email to me, tell me what your favorite alternative language or platform is, and why. I'll use that to know if you're somewhere in the ballpark.

And no, job postings are NOT going to become a regular part of this blog; I'm doing this as a once-off. (My motivation? I just want to help these guys; this isn't an easy requirement to fill, and I'm hoping I get to meet whomever it is they end up selecting, 'cuz I'm thinking they'll be a kindred spirit. )

Update: They sent me a formal job description, and it seems the desires changed just a bit. *shrug* See for yourself:

A lead software architect for [[name snipped]]. Applicant must be able to take a high level conceptual framework and architect a conceptually sound implementation using open standards in collaboration with an existing team. Experience with Java, Eclipse, and the Rich Client Platform (RCP) sub-project in Eclipse is a significant advantage. Experience with Aspect Oriented Programming is a plus. Participation in the open standards community a plus (e.g. W3C and Eclipse standards communities). Five or more years of experience required with experience as a lead software architect, industry experience preferred. Opening is for a full-time onsite position.

Jim Hugunin strikes again: IronPython 1.0 beta 1 is out. I think Jim should get an award for "first language designer to operate on both the JVM and CLR". Now he just needs to do one more implementation to get the hat trick.

Flame away...

The Pragmatic guys are at it again... This time it's a whole course, taught by two of the finest instructors I have had the privilege to know (and, quite honestly, argue with), on everybody's favorite presentation-layer hot topic, Ajax.

By the way, dear audience, this is one class you can attend regardless of which camp you prefer--both Stu and Justin are equally adept on both enterprise platforms (Java and .NET) and the new hot language, as is clear when they say that they will show you how "to use frameworks such as Rails, Spring, and ASP.NET"; Justin, for example, co-authored "Better, Faster, Lighter Java" and the "Spring Developer's Handbook", as well as built DevelopMentor's ASP.NET website and infrastructure. Stu was one of the COM cognoscenti back in the day (his poems on the subject (towards the bottom, search for Stu) are legend), and then took over as Java curriculum lead when DevelopMentor... well, created a Java curriculum. Two brighter guys--and better instructors--you're not likely to meet.

Oh, and, uh, they seem to know a fair amount about Ajax, too. Enough that I'd attend the course, were I not already busy that week.... Do yourself the favor, if you want to know more about Ajax, go see them. I can think of a lot worse ways to spend a grand in cash and 3 days...

An interesting question emerged during a discussion with some buddies/co-workers/peers/whatever-you-want-to-call-them today:

"Which conferences have you attended in the past that you thought was really good, and why? Which sessions were your favorites, and why? What made them that way?"

Yes, this is somewhat selfish, since the new conference season is amping up, and obviously I'd like to make sure my sessions are ones that people find interesting and recommend to others, but the question actually stemmed from an unrelated discussion to that. I promise.

Microsoft has done it again--this time, they're previewing the next release of C# planned for after LINQ/C# 3.0. They call it, for obvious reasons, the YODA programming langauge. Judge me by my size, do you? As well you should not, for my ally is the Source, and a powerful ally it is, indeed.

Remember: A Jedi uses the Source only for knowledge and defense, never for a hack.

In a recent thread on TheServerSide.com, Rick Hightower, a fellow NFJS speaker, commented on the JSR-175/annotations specification, and I felt a little obligated to respond, since this is a common critique/criticism:

Why don't you like the implementation? I hate the fact that your code has to import the annotations and then your code is tied to the annotation. It does not seem that different than depending on a interface (i.e., a marker interface). I'd like to see a soft import for annotations that does not impact compilation. (from TheServerSide.com)

The basic problem was this: if the compiler runs across an annotation, and it doesn't match an annotation type defined anywhere in the compilation classpath of imported symbols, what is the proper behavior? In any other scenario, such as:

public class App
{
  public static main(String[] args)
  {
    Systme.out.println("Hello, world!");
  }
}

public class App extends Object
{
  @Overide public String toString(Object obj) { return "App"; }
}

The big IDE vendors were particularly upset at this idea, leading one to claim, "If we cannot solve this problem we will consider JSR 175 to have been a failure." Unfortunately, then, we failed--there is no good way to solve this problem without breaking the fundamental vision of the Java platform. We tried a variety of ideas, including a few centered around the JDK 1.4 assertion idea (some kind of runtime flag indicating which annotations were safe to ignore), but couldn't work out the basic semantics of such without requiring a definition of the annotation to be present on the compilation path. And frankly, in the grander scheme of things, it makes sense to me that annotations ARE required at compilation time--just as interfaces, helper classes, member field types, and other types are required to be present at compilation time, as well.

Rod Johnson continued his critique of annotations by citing the following two reasons:

1. No proper mechanism for overriding annotations at runtime, despite the fact that just about any framework that uses annotations is going to need to consider doing that.
2. Inability for an annotation to extend an existing interface (even if that interface is simple enough to sit within annotations). Of course there are implementation issues around this one, I guess. But it means that it's hard to avoid code duplication when working with annotations and alternative metadata sources--something that's going to be particularly important until everyone and their dog uses Java 5, and anyway will remain important to work with existing code that may not have the right annotation.

Nutshell version of all this, the JSR 175 EG did, in fact, think long and hard about "soft imports" and "runtime annotation modification", and both ideas were shot down for what we felt were good reasons.

In keeping with the tradition, I'm suggesting the following will take place for 2006:

1. The hype surrounding Ajax will slowly fade, as people come to realize that there's really nothing new here, just that DHTML is cool again. As Dion points out, Ajax will become a toolbox that you use in web development without thinking that "I am doing Ajax". Just as we don't think about "doing HTML" vs "doing DOM".
2. The release of EJB 3 may actually start people thinking about EJB again, but hopefully this time in a more pragmatic and less hype-driven fashion. (Yes, EJB does have its place in the world, folks--it's just a much smaller place than most of the EJB vendors and book authors wanted it to be.)
3. Vista will be slipped to 2007, despite Microsoft's best efforts. In the meantime, however, WinFX (which is effectively .NET 3.0) will ship, and people will discover that Workflow (WWF) is by far the more interesting of the WPF/WCF/WWF triplet. Notice that I don't say "powerful" or "important", but "interesting".
4. Scripting languages will hit their peak interest period in 2006; Ruby conversions will be at its apogee, and its likely that somewhere in the latter half of 2006 we'll hear about the first major Ruby project failure, most likely from a large consulting firm that tries to duplicate the success of Ruby's evangelists (Dave Thomas, David Geary, and the other Rubyists I know of from the NFJS tour) by throwing Ruby at a project without really understanding it. In other words, same story, different technology, same result. By 2007 the Ruby Backlash will have begun.
5. Interest in building languages that somehow bridge the gap between static and dynamic languages will start to grow, most likely beginning with E4X, the variant of ECMAScript (Javascript to those of you unfamiliar with the standards) that integrates XML into the language.
6. Java developers will start gaining interest in building rich Java apps again. (Freely admit, this is a long shot, but the work being done by the Swing researchers at Sun, not least of which is Romain Guy, will by the middle of 2006 probably be ready for prime-time consumption, and there's some seriously interesting sh*t in there.)
7. Somebody at Microsoft starts seriously hammering on the CLR team to support continuations. Talk emerges about supporting it in the 4.0 (post-WinFX) release.
8. Effective Java (2nd Edition) will ship. (Hardly a difficult prediction to make--Josh said as much in the Javapolis interview I did with him and Neal Gafter.)
9. Effective .NET will ship.
10. Pragmatic XML Services will ship.
11. JDK 6 will ship, and a good chunk of the Java community self-proclaimed experts and cognoscente will claim it sucks.
12. Java developers will seriously begin to talk about what changes we want/need to Java for JDK 7 ("Dolphin"). Lots of ideas will be put forth. Hopefully most will be shot down. With any luck, Joshua Bloch and Neal Gafter will still be involved in the process, and will keep tight rein on the more... aggressive... ideas and turn them into useful things that won't break the spirit of the platform.
13. My long-shot hope, rather than prediction, for 2006: Sun comes to realize that the Java platform isn't about the language, but the platform, and begin to give serious credence and hope behind a multi-linguistic JVM ecosystem.
14. My long-shot dream: JBoss goes out of business, the JBoss source code goes back to being maintained by developers whose principal interest is in maintaining open-source projects rather than making money, and it all gets folded together with what the Geronimo folks are doing. In other words, the open-source community stops the infighting and starts pulling oars in the same direction at the same time. For once.

Whilst perusing the latest VMWare Workstation offering from their website, I noticed that not only does VMWare offer a free VMWare player (in other words, take a VMWare disk image created by somebody else and use it), but the VMWare site also has links to various pre-built VMWare disk images, including one for BEA's complete WebLogic 8.1 environment.... Whoever thought this idea up deserves to be knighted--what a great way to make it trivially simple for somebody to get started with a rather intimidating task (be that either installing a new O/S or a new app server).

Are you listening, Microsofties? VPCs of Vista, Visual Studio Team System and, heck, even just a base Visual Studio Express (pick a language, C# and VB sound like good starters) image are definitely something to consider if you want to make it easy for dev's to play with your tools.... Particularly people who DON'T want to install Windows just to play with Microsoft's implementation of .NET....

If you read no other book this coming year, you must read "Blink", by Malcolm Gladwell, the same author who wrote "The Tipping Point" (which is about why certain trends seem to just "take off" with no prior warning--case in point, the incredible rise of certain fashion trends, such as "Hush Puppies")..

I won't tell you what it's about except to quote the back cover; to do so would ruin the book's effect, to be blunt. The inside jacket reads,

In his landmark bestseller The Tipping Point, Malcolm Gladwell redefined how