Apparently, Sun has switched from bundling the Google Toolbar with their releases to bundling the MSN Toolbar. I'm kind of surprised they aren't using the Windows Live Toolbar, but at the same time, the MSN Toolbar has a much better experience. Whether this was sparked by Google dropping StarOffice like a bad habit or not, it's a win for Microsoft. The toolbar comes with Windows Live Search integration (duh) and, even better, uses Silverlight. There must have been some pretty high-level talks to get this approved because Silverlight is a competitor to the yet-to-be-released JavaFX, so I can't see this going thru just because Google pissed someone off. I have a feeling Sun was just trying to whore themselves out as much as possible. The MSN Toolbar deal only applies to Java downloaded by IE on Windows. Everyone else will keep the Google Toolbar based installer. I know Sun is hurting, so this probably just gives them a chance to pad their slowly declining product line.

Aside from all this, I have to say I hate these things. I wish there weren't deals like this. If you do feel the need to whore yourself out, make it disabled by default. I get aggravated when I see these things as opt-out inclusions. I don't want your crappy toolbar, I don't want an icon on my desktop, I don't want to change my homepage. Get off my freakin' back!!! Bad installer, bad!!!

In early December, I asked myself whether I'd rather go to Mix or SD West this year. I haven't been to either, but have wanted to go to Mix since its inception. After some thought, I've decided to go to SD West. The main reason for that is because I feel like it'll have better content given my focus. The first year of Mix was all about the web and the second year was a mixed designer+developer event, but still heavily rooted in the web world. I definitely feel at home with that mix, but things seem to be changing again. This year, it sounds like there's going to be even more focus on designer content, so I'll let Mix shake itself out one more year and check out SD West. I look forward to it.

It's been a while since I've complained about version numbers, but Rocky Lhotka's  latest post about his versioning scheme for CSLA has sparked another bout. What Rocky is doing is retarded. He's dumbing down version numbers for those who fine versioning difficult. When .NET was first released, this is something I knew was coming. Look at Java, where developers deal with a dozen different frameworks and tools just to work on their project and guess what... they're all different version numbers! Hell, even the desktop and server frameworks are different. Ok, so the latter is a tad ridiculous, but the former makes complete sense. Every tool should have its own version number which accurately depicts its version. Major version numbers only change when there's a major change in the code -- typically a breaking change. Sure, this might include .NET 2.0 vs 3.0, but it doesn't have to. Don't blame Microsoft's stupid version numbers on yours. If your users don't understand proper versioning, why the hell are you listening to them!?

I still have to say .NET 3.0 isn't necessarily wrong. WPF was a major change that should've been introduced as a major upgrade. I'd say that all four parts of .NET 3.0 are major updates. The real problem I see with .NET 3.0 has nothing to do with the version number, but the lack of any other improvements, which would've further justified the version number. Honestly, I would've been fine with 2.1 or 3.0. The real butcher of a job Microsoft did on version numbers was 3.5. What the hell was that!? There were no, nor were there ever planned to be any intermediate versions. Again, I'd have been fine with 2.2 or 3.1, but 3.5 was just stupid. I had hoped this wouldn't turn out to be the next version, but no such luck.

On the lighter side of things, the big improvement for Silverlight will now be Silverlight 2.0. I imagine this had something to do with the .NET 3.x version issues. Either way, it's nice to see.

I'm pretty big on the practice of naming a file after the class it contains. And, yes, I follow the one class per file practice. Ever since .NET 2.0, tho, generics have thrown a kink in the system. We can't have file names with angle brackets (< and >). So, what is the best practice for naming generic class files? Java has the same problem -- perhaps more so since their file names have to be the same as their classes (a restriction I wish .NET had). I haven't touched Java since before generics were introduced, so I'm not sure how it implements that. I'd be interested in seeing, tho. I may have to give that a look at some point. Until then, I started using brackets ([ and ]) to represent generic class file names. For instance, I created a model-view-presenter (MVP) class that extends Control with a signature of Control<TView,TPresenter> and a filename of Control[TView,TPresenter]. That works, of course, but I'm wondering if there's a better way.

On a side, but perhaps related note, GhostDoc will document a generic class/member by HTML encoding the angle brackets; however, Resharper replaces them with curly braces ({ and }). I'm curious as to which is the "right" approach. If it's the latter or both, I might opt to name files with curly braces rather than brackets.

A while ago, I mentioned the next version of Cold Fusion will be able to interact with .NET code . I found out a tad bit more about this and thought it was interesting enough to post. Apparently, this interop will be care of a tool that's been around for around 4 or so years, if memory serves me. I want to say this was the first tool to come on the scene and provide true Java-.NET interop: JNBridge , which I mentioned last week . As I said before, I've never used JNBridge, but it's always the first thing that comes to mind when Java-.NET interop comes up.

Someone briefly mentioned Java Specification Request (JSR) 168  to me a little over a month ago. As most would, I asked what the heck it was about. I know what JSRs are, but I don't make a habit of knowing each one. JSR 168 turns out to be all about portal applications and, specifically, calls out a Java-specific way to implement Web Services for Remote Portlets (WSRP) . Any time I'm asked about integrating Java and .NET, two things come to mind -- and, no, one is not replace the Java with .NET... although, that is a good idea  Those things are JNBridge  and Mainsoft . I don't know much about these tools besides their existence and high-level goals. After talking to Simon Guest a month and a half ago about user experience , he mentioned how JNBridge works. I'm going to liken it to how Visual Studio allows us to easily consume web services. JNBridge creates a proxy class on the target platform that hooks into their system, which wraps the original code, be it .NET or Java, if I understood it correctly. I'm not sure how MainSoft does the job, but I wouldn't be surprised if it's a somewhat similar method.

Of course, anyone who paid attention to the fourth sentence above will notice I said JSR 168 is about web services, so you might ask why one would need to integrate Java and .NET at a component level. I'm going to chalk this one up to a mild case of stupidity. I say mild because there is some logic here, but not enough. Being the brilliant person that he is, an "architect" at a client's site determined that web services were too slow to accomplish what they needed. At first, I started to accept that. Then, I thought about how web services can be streamlined and asked what numbers they had to back up that claim. Apparently, there aren't and never have been any benchmark tests. People: If you're going to claim something is too slow, at least have some numbers to prove it. Later, I found out JNBridge was mentioned to this person before, but was shrugged off. I don't know if it's the presence of Microsoft that made him change his tone, but he was very accepting of the idea. To me, this guy is one of those zealots we run into occasionally. They always have something hateful to say about the competition, but rarely add to the conversation. In this case, he was (and still is) trying to push Microsoft solutions out of the conversation. I find that funny because... well, let me just say Microsoft has brought a lot of value to the client in the past year. We're not alone, by any means -- we work with some really good... and, with any project, some not-so-good people. I guess one of the key differentiators is our extensive training mantra along with our connections and resources back in Redmond and abroad.

Don't ask why or how this came up, but with the talk about Windows redux (1 , 2 , 3 ), I had an interesting thought: imagine Windows being rewritten to run on the Linux kernel. Don't get me wrong, I don't think this would ever happen, but could you imagine? The OS wars would almost be completely naught. You'd have the Linux family, which are all having their own internal battles today; Mac, which is based on Unix; and Windows, the mack-daddy (based on usage), would take the same approach Mac did with OSX, whether based on Linux or Unix, the results would be the same.

Linux advocates would feel like they've won, in a sense, because Linux would then become the most used kernel by far; however, we all know the cost model wouldn't change, so then the only difference would be between the user experience and proprietary software. With this, Microsoft would have to bring .NET to the Linux world, which would completely consume the major portion of Mono. By this time, I imagine the majority of the Windows-specific features and core applications (i.e. Office) would be implemented in .NET, which is what I believe they're moving towards, anyway -- not 100% of the code, but as much as makes sense at whatever pace makes sense. Java would see an even more drastic decrease in usage because .NET would see more "multiplatform" benefits. Honestly, there's so much you could speculate with such an extreme move. All you can really do is laugh at the idea.

For the past month or so, I've been watching quarterly stock percentage changes for a few top tech companies and I've noticed that Sun went down a good bit, but then jumped up pretty quickly, too. Sun made the largest jump by far in the past month. Interesting...

On a side and perhaps related note, Java is moving towards supporting more languages. Java 6 is currently in beta 2 and has added some support for JavaScript, but plans for Java 7 include adding support for even more languages, one of those being Visual Basic. Now, this isn't all that surprising. A few years back, Sun started a program to try and get VB developers over to their side and this seems like more of the same. Don't get me wrong, I think the move is probably a good one, but I don't know how much it'll help. It all depends on the strategy they'll put behind the move. This is where they've failed in the past. From what I understand, they won't plan on supporting a specific Microsoft-released version of VB, but instead support some "popular" features of VB.NET. What that means is really up in the air, but it'll be interesting to see how things play out. The best move Sun could make with respect to VB would probably be to support VB6 to try to bring some of those "estranged" developers to the Java world. Then again, I can't imagine that this would be an easy task.

There are a lot of mixed emotions about the changes in the next two versions. Those looking for multi-language support are excited about the changes; however, the traditional Java developers who have been supporting Java-only systems for a while aren't very interested in the upcoming versions. I believe everyone sees some good in the move, but the question seems to be: How much will this actually affect the Java ecosystem? I can see the potential of the ideas, but I seriously don't think it'll change the Java market enough to effect .NET. Sun is simply attempting to capitalize on the big shift back to dynamic languages. We'll see...