Given that my paycheck came from a Java shop, learning Java would have probably been the smart move. But the more I looked at it, the less enthusiasm I could muster. I had no problem with the language itself. Java and C# were comparable at the time, and I was comfortable with static typing, case sensitivity, and the C-style syntax in general. But, a variety of issues kept putting me off Java.
- My interest was web development, but JSP was slow, clunky, and annoying.
- The run-anywhere promise had a certain appeal, but the price of portability was poor performance and lowest common denominator functionality With web apps, you wound up coupled a particular application server anyway, so portability was a low value proposition.
- I disliked how SUN conducted business. They’d refused to turn the language over to an independent standards body, and were quick to file lawsuits. Their licensing and prices had grown increasingly draconian as well.
- I wasn’t impressed with the direction many Java libraries were taking, and enterprise JavaBeans was a total mess.
- The tooling was terrible too. I prefer IDEs to command line compilers and plain text editors. Eclipse was the best Java IDE around, but it was not fun. On my high-end workstation, it often took five minutes to launch; and once open it was still slow, buggy, and feature poor.
Ten years later, I’m going back to college to grab that long overdue CS degree. Naturally, my curriculum centers around Java. I still have no love for the language, but I am looking forward to learning my way around it more… it never hurts to branch out.
The last ten years have radically changed C#. A C# developer from 2003 would probably not recognize most code written today. So, when I took another look at Java, I’d expected to see a similar progression. I was wrong.
Using Java today feels eerily like being back in 2003 – cranking out blocky-ass code, casting everything six ways from Sunday, and with precious little of the expressiveness and elegant fluidity I’ve grown accustomed to. The only surprising thing about Java is how stubbornly it has resisted change.
Java’s most significant advance was the addition of generics. After digging deeper though, I find Java’s generics a bit half-baked. They don’t support primitive types, which is super annoying. You can use the reference wrappers, and rely on auto-boxing/unboxing, but it feels clumsy. The syntax for generics is also a bit odd in places. The wildcards are especially interesting, but I’m reserving judgment for now. While confusing, wildcards seem like a good way to handle covariance and contravariance. C# also struggled with those, and its solution wasn’t very intuitive either.
When generics were first introduced in .Net, it gained a significant performance boost across the entire framework. However, Java implemented generics purely as a compiler trick using type erasure, which is an… er… interesting choice. This means Java can’t really optimize around generics like .Net can.
Additionally, Java’s implementation prevents runtime reflectivity over generic types. In C#, I have used generic reflection heavily in a few cases, and was able to produce elegant solutions to some really thorny problems. I’m not even sure how to approach those kinds of problems in Java without generic reflectivity.
Java did pick up some smaller improvements over the years, but they don’t seem to add up to very much:
- Foreach loop. A simple feature, and a solid win.
- Annotations. Weak-sauce compared to C# attributes, but just as essential for tooling, code generation, and reflection.
- Automatic boxing/unboxing. Especially useful given that generics don’t support primitives, and Java has no type lifting (nullable value types to us C# guys). At least auto-boxing/unboxing cuts down the casting cruft. The implementation on the unboxing side gives me the heebeegeebees, but I’ve had no trouble from it in actual practice.
- Enumerations. One of the few things Java does, arguably, better than C#. Java enums are full reference types, and can implement methods and such. Nice!
- Varargs (params to us C# folks). A minor improvement, but a handy simplification to a common code pattern.
- Static imports. Yeah, sure… ok. I don’t often use aliases in C# either.
- Strings in switch statement. How was that not there all along? More to the point, why does Java’s switch statement still allow fall-through? Why doesn’t it work with all types? Overall, the switch statement in Java still seems horribly broken, but at least it works with strings now… so that’s progress I guess.
- Automatic resource management via the Try statement. The same as a “using” statement in C#. A useful little feature to have around.
- Binary integer literals. Anyone who uses binary constants probably loves this, so I imagine there are at least two happy developers out there somewhere.
- Underscores in numeric literals. Sure, why not!
- Type inference. Limited to generic types. A more comprehensive type inference mechanism would have been nice, but some is better than none. Complex usages of generics can produce some gnarly expressions, so if you were going to half-ass tackle type inference, generics would be the place to start.
Java is seriously conservative in adopting changes. There are good things to say about stability and predictability, but there are a few other things from C# that I REALLY miss when working in Java.
This drives me insane, and there is no excuse for Java not having added native property syntax by now. Properties are easier on the developer, and they make the intent behind your code much more apparent. Java’s convention driven naming pattern of manually written getter/setter methods is a piss-poor substitute.
I didn’t really appreciate these when they first appeared in C#, but after getting used to them I find them indispensable for framework development. Extension methods let me quickly add functionality to existing types, even 3rd party components, without any need to modify the original source, write wrapper classes, or create some intermediate abstraction layer.
I completely get why these aren’t in Java yet, but at the same time their usefulness is also unavoidably obvious. The sheer number of amazing capabilities C# picked up after adding lambdas is staggering. This feature is slated for the next release of Java, and I sincerely hope they don’t kick the can down the road any further.
Most of the arguments within the java community over this feature are plain silly, and those arguing against lambdas are just plain idiots. I respect Java’s inner and anonymous class implementations. They are slick, and come close to providing full featured closures already. Enhance what’s already there, and full closure support might be a done deal… but if that’s all that’s done, it would fall far short of the full potential. Lambdas are not just about the functionality; the real benefit is providing an elegant and expressive syntax for using the functionality.
I dearly miss lambdas when working in Java, and I’m 100% sure that Java developers will love this feature as much as C# developers do. I just hope the final implementation isn’t as half-baked as generics were.
Ten years ago C# was just a shiny new clone of Java. Since then though, C# has grown and changed rapidly. It has picked up many of the most useful features of functional and dynamic programming, and balanced them successfully against its own static-typed roots.
Java’s lack of progress should make learning my way around it a lot easier. I’ll have to acclimate to the “Java way” of course. Tackling the design patterns and core libraries of any language takes time and patience, but at least the language itself is simple, predictable, and familiar. I just wish java felt more… alive.