Java

Google Brings AJAX to Java

Michael Flanakin — Wed, 17 May 2006 08:50:00 GMT

As Google announced, they will be releasing Google Web Toolkit to support building AJAX-ian web applications with Java. I just wish it were available for .NET as well. Not that I don't have faith in Microsoft's Atlas, but I would like to see and play with Google's approach.

Java and C#

Michael Flanakin — Wed, 10 Aug 2005 08:42:00 GMT

I thought this was an interesting outlook on Java and C# - like I care about Ruby. Anyway, I'm surprised there wasn't more on C# at OSCON2005. I've heard that C# has a pretty good following of Linux users. Granted, this was just something I heard from a hardcore Linux person, so I have no idea how much support it has. Of course, this is all because of Mono.

Greg talks about how Java 5.0 (1.5) and 6.0 (1.6) features will help Java surpass C# current capabilities. Well, he's right. That kind of brings one thing I've always worried about to mind: will .NET be able to keep up? Microsoft is always good in the heat of battle, so I'm sure they'll do a good job; but speculation is exactly that. .NET 2.0 is coming soon, but when will 2.1 be around? If .NET releases are continually tied to other product releases, we may be hurting for features as Java spits out releases with smaller feature changes quicker. The 2.0 release will no doubt give us a great advantage over 1.1, but wouldn't it have been better to have gradual improvements to get us here? Maybe it's just me.

I obviously think some things should've waited until the 2.0 release, but I'm sure there could've been a number of features added to 1.2, 1.3, and 1.4 releases. Either way, 2 1/2 years later, we finally get an upgrade - more significant than any Java release since it's move to Java 2. Let's just hope they keep coming...and a little sooner.

IBM Commissions IBM vs. Microsoft Tools Review

Michael Flanakin — Mon, 01 Aug 2005 11:35:00 GMT

I probably shouldn't even be propagating this crap, but I thought it was a ridiculous attempt to make the .NET plastform look worse than Java. IBM hired someone to evaluate IBM and Microsoft tools for productivity. I have no problem with the fact that IBM hired the evaluators. What I have a problem with is the fact that the tools they chose to implement (and not implement, for that matter) don't give a true picture to the appropriate level of effort for the Microsoft side of the picture. Two examples are that (a) BizTalk wasn't needed; and, (b) SharePoint Services could've been used for portal functionality. I have to say that this is a horribly lopsided evaluation. I just hope others realize it before taking it to heart.

null == annoyance

Michael Flanakin — Tue, 17 Aug 2004 14:59:00 GMT

What the hell is up with people putting the value you're checking for first in a comparison expression? I freakin' hate that!!! Is there some sort of advantage? Arrrgh...

Maybe it's just me, but I think, “is <my variable> equal to <some value>?” That just makes sense to me. For instance, “Is your name Michael?” sounds so much better than, “Is Michael your name?” Granted, they both make grammatical sense. Maybe I'm just stuck in a latin-based society that reads (and thinks) left-to-right, but why the hell do people insist on writing expressions backwards (in my opinion, at least)?

If someone could point out a good reason (or ten) as to why this approach is preferred, I would appreciate it. I get stuck in my ways sometimes, but that's only because my way is the best way :-) ...well, until someone convinces me otherwise - and then, I just get a new way. So, in the end, my way is the best way, again. You gotta love my logic...well, I do, anyway.

.NET: The American Choice

Michael Flanakin — Sat, 31 Jul 2004 03:49:00 GMT

Here's something to chew on...

...more-than 50% of programmers in the US use .NET as their primary development framework.

I don't know the date of this, but it came out of a Forrester report, according to Software Development Magazine.

...Ya know, maybe that was a bad title. Oh well.

Java...Still Segmented

Michael Flanakin — Wed, 28 Jul 2004 20:10:00 GMT

As I'm sure you all know, Java was born to provide a single development platform for any hardware system. The dreams were idealistic, yet within reach, but the implementation severly lacks. This is all old news, however.

I've always found it interesting that each J2EE application server provides a different set of extensions to the base J2EE class library. This just shows the inadequacies of the platform and the lack of support Sun and the JCP provide. The question is, with the recent release of Mono, will there be a need to extend the .NET framework to provide functionality that customers need, but Microsoft has yet to provide? Who knows. Only time will tell.

For now, though, the Java community continues to move in different directions. BEA is working on an application framework project with the Apache Software Foundation that can only be used with the BEA WebLogic app server. That makes me kind of wonder why ASF is supporting it, but oh well. Another question arises, though: How will Sun react to this effort? Will they support it, compete with it, or ignore it? Based on the past, I think Sun will try to compete with it. Sun likes to show the Java community that the platform is their baby and they are in control.

We'll see. I can't say that I'm hopeful of the community, but I do hope to see some good things come out of Java. The better Java gets, the better .NET will get. And, we all know who wins when Microsoft gets into a pissing competition...us! :-)

Static Imports for Java

Michael Flanakin — Fri, 23 Jul 2004 09:28:00 GMT

Coming up in the next release of Java, J2SE 5 (aka J2SE 1.5), there will be a new feature: static imports. I thought this was kind of interesting. I'll give an example, but before I do, let me explain something... Like C#'s using and VB's Import statements, Java has a similar import statement; however, Java's import statement can [but does not have to] specify a class name instead of a namespace (or package, in Java terms). I don't really know what the benefit of this is, but it's possible. I guess one thing is that it lets you see at a glance what external classes are being used. Beyond that, however, I don't really know of any reason to do it that way. Here's an example:

ServiceLocations.java

package com.indigo.examples;
public class IfUtil {
    public static object decode(object ifThis, object equalsThis, object returnThis)
    { ... }

    public static object nullValue(object ifNull, object returnThis)
    { ... }
}

This class provides generic conditional logic capabilities. The decode() method takes in two values, compares them, and if they are equal, returns the third value; if not, the first (ifThis) value is returned. There are usually overloads for this to provide more extensive options, but I'll not worry about that right now. The nullValue() method checks to see if a value is null and if it is, returns the second value; otherwise, the original value is returned.

And, here's the follow-on implementation of the static import:

Foo.java

import static com.indigo.examples.IfUtil;
public class Foo {
    public static void main(String[] args) {
        // outputs: 1
        System.out.println( decode(1, 2, 3) );

        // outputs: 3
        System.out.println( decode(1, 1, 3) );

        // outputs: "No value specified"
        System.out.println( nullValue(null, "No value specified") );
    }
}

So, I'm sure you can see how this is trying to add functions (no, not "methods") back to Java. They are "functions" because "methods" are actions taken on or by instantiated objects.

And, more to why I started this post, I'd like to see something like this in .NET (or, at least C#). Assuming a similar IfUtil class in C#, the import could look something like this:

Foo.cs

using static Indigo.Examples.IfUtil;
public class Foo
{
    public static void main(string[] args)
    {
        // outputs: 1
        MessageBox.Show( Decode(1, 2, 3) );

        // outputs: 3
        MessageBox.Show( Decode(1, 1, 3) );

        // outputs: "No value specified"
        MessageBox.Show( NullValue(null, "No value specified") );
    }
}

I think that this would be a nice way to implement static utility methods that some people seem to be missing (1, 2). Personally, I don't know how much I'd use it (except for in examples like the above). The only problem is that, as a new programmer maintaining this code, you may not realize that Decode() belongs to the IfUtil class. And, to make matters worse, what happens if you have 3 or 4 static imports? That will just make the whole thing confusing as hell. The only solution I have to that is to register specific methods. Perhaps one of the following:

// specify an exact method instance
using static Indigo.Examples.IfUtil.Decode(object, object, object);

// specify all method instances
using static Indigo.Examples.IfUtil.Decode(*);

// specify all static members
using static Indigo.Examples.IfUtil.*;

This may or may not ease the readability and maintainability of it, but for those who are begging for similar functionality, it could be an option.

Microsoft Support for Eclipse

Michael Flanakin — Mon, 12 Jul 2004 17:27:00 GMT

Once again, I'm late, but it looks like the Eclipse Foundation has extended an invitation to Microsoft to join its efforts. I guess they think their new directions on web services and SOAs might be of interest to Microsoft, since they're the market leader, right now.

Personally, I don't expect Microsoft to support this. First off, Eclipse has a long way to go to compete with Visual Studio. Secondly, do you seriously think Microsoft will support development for a product on a platform that it is a direct competitor for? Would anybody? I know I wouldn't. I mean, if there was some sort of integration that .NET developers, or the .NET platform might get out of it, then that's one thing. Otherwise, it just doesn't make sense.

One thing being looked at is whether or not to add a platform-neutral layer to its Eclipse Web Tools project. I don't know if this is in addition to a Java approach or not, however. I would hope that this wouldn't be a duplicate. That would be more code to update, which just doesn't make much sense. I'm sure each of you have tried to maintain two similar code bits (small or large) at some point in time. It's a pain. I just see the open source community not supporting that for long.

Anyway, above all of that, Microsoft has just released its Express line of products. They are all in Beta, but I believe these will all be free tools. So, why would Microsoft support a competitor whose tool would require new code, especially when it is so far behind Visual Studio? Life will only get better when VS 2005 is release. (By the way, the Express line will not include Team System.)

Portability: Java vs. .NET

Michael Flanakin — Fri, 26 Mar 2004 07:54:00 GMT

I recently found out that my office did a code review for a tool that may be maintained by my organization. Now, the tool has an odd choice of technology implementations, so I'm not sure who decided on everything. But, essentially, there's a .NET web application that uses Flash for some reporting UI components which talk to Java web services. And, the .NET app also talks directly to the same database that the Java web services talk to for additional admin functionality. (I hope I explained that clearly)

Anyway, I am the only person in my office that is pro-.NET; everyone else supports/backs J2EE. But, this project came to my office (without me knowing, which ticked me off) and a code review was performed. The person who did it is familiar with .NET, but I'm not sure to what extent. Anyway, the report was fine. There were a few vague areas that I had questions about, but overall, it was sound and I'd agree. The problem came when I saw the source code findings. They used a set of quality attributes that are defined in the ISO 9126 Software Quality Model. I haven't seen the code, yet, so I can't say whether or not the ratings (1-5, 1 being poor) are accurate. But, there was one in particular that was an attention-getter: portability.

The review defines portability as:

The ability of the source code to be used on various user environments and development environments. Observations generated on portability indicate risks that the software product can't be used on specific user platforms or that the source code can't be used “as-is” in specific development environments.

Now, maybe I'm just trying to argue the 5-to-1 Java vs. .NET rating, or maybe I'm just trying to give more credit to .NET, but when doing a code review, I don't think portability should be considering moving the code to unsupported environments. Basically, I think this should be relative. For instance, if I have a Perl application, how well can I move my code to one or another Perl server? Obviously, I've already chosen Perl, which means that I've accepted the risk of limiting myself to a Perl server. Now, is my code portable between Perl servers? That's the true question.

In this situation, the Java code got a 5, but I don't know if that means it is completely transferable between any and all other Java app servers, or this means that Java can theoretically run on any platform. One has to question that. They didn't do a full review of all the code, so I doubt they know whether it is completely Java-portable or not.

Anyway, I'm trying to figure out how best to approach this. It'd be interesting to hear other peoples' opinions on how the portability metric should be applied to code reviews. Perhaps the best answer is to have two sub-categories of portability: one to determine how easily the code can be moved to another OS (considering all OSs), and another to determine how easily code can be moved to another implementation of the technology platform.

Table Data Gateway vs. Data Access Object

Michael Flanakin — Mon, 08 Mar 2004 11:22:00 GMT

So, I'm about to create my data access layer... *flashback sequence begins* ...and I reach for my Patterns of Enterprise Application Architecture book. *flips the cabinet door open to see an empty space where the book used to be* Damn...I left it at home. Well, what am I to do? Let me just move over a couple of books and grab my Core J2EE Patterns book (admittedly, still in my to-read stack). I figured this was as good of a time as any to get to know the DAO pattern and how it compares to the TDG pattern. So, I read through the pattern description and I get a little excited. I realize that the only difference in the two patterns is the implementation. While I don't like the idea of tacking on “DAO” to an object name, I figure I'd make a hybrid of the two. *flashback sequence ends*

The fundamental differences between these two patterns are pretty much null and void when you consider that pattern implementation is usually different than the prescribed means. Here are a few of the pros (in my opinion)...

String constants for insert, select, update, and delete statements
- Pro: One place to update table structure changes
- Con: In methods, you don't know the order of values that need to be inserted (i.e. in .NET, using the String.Format() method to insert values)
Method names that match common data access terminology (create, read, update, delete - aka CRUD) and are not specific to any data source
- Pro: Sets a naming standard for the pattern
- Con: ???

Some of the things I didn't like about the TDG pattern were that the method names weren't consistent (where did "find" come from?), methods seemed to be based on SQL (use of "insert" method), and the method signatures didn't suggest the use of objects.*

* The use of objects is very beneficial when passing data through tiers because it allows you to abstract away from the exact data that needs to be transferred. For instance, based on the TDG pattern description, consider the insert method: PersonGateway.insert(lastName, firstName, numberOfDependants). These are the three properties of the Person class, but I don't know why a class instance wasn't passed instead - for instance, PersonGateway.insert(person). Now, consider adding an SSN. With the implementation as-is, you would have to add another PersonGateway.insert() method allowing for the SSN to be passed. And, what if the SSN is required? Then you would have to deprecate the old insert method. However, if you use a class instance, we only have to change the internals of the insert method - no new or deprecated methods. Obviously, this would be a much cleaner implementation.

Also, let me say that the TDG pattern seems to be a bit higher level. It represents the idea of having an object to act as a gateway between business and data. There isn't a lot of guidance for naming conventions or implementation ideas, which I think is important for identifying/using patterns in existing software. As such, you could say that the DAO pattern is just a lower level TDG pattern.

You'd think that this would solve all of my problems, but it doesn't. I like the idea of the Gateway pattern (not the Table Data Gateway pattern) because it is abstract and identifies a way to interface with any type of back-end. Because of this, I think it's important to look at intermediaries as gateways. Now, all of my development is usually in .NET, but I sometimes dabble in Java. I would like to have one standard set of patterns to use, but these two conflict. In my mind, the gateway pattern works in all situations; however, it is pretty much standard practice to have a PersonDAO class as opposed to a PersonGateway class. I don't like deviating from the standard, but at the same time, I don't like having two standards for the same practice.

I've talked to Dan Malks, one of the co-authors of Core J2EE Patterns, and he said that they talked with Martin Fowler when making the book. My question is: Why are there conflicting patterns? And, can we identify the right (read: best) solution so there's only one? I'd like to see the DAO pattern reference the TDG pattern (or maybe just the Gateway pattern). This would identify the relationship and developers would be able to identify each implementation as it was used in projects. This doesn't necessarily get rid of one or the other, which could cause naming conflicts, but at least its a step in the right direction. In my experience, most Java developers don't even know about the TDG or Gateway patterns.