I recently took an Object Oriented Design class, and we used Java as the primary language for development. As a .Net developer, this was my first major experience using the language and tools aside from some minor exposure via SalesForce’s Java-like Apex code and the talend data integration environment built on Eclipse. Note that I didn’t dive very deeply into the language – the main project consisted of about 5 main model classes and a maybe a couple dozen total classes for accessory functionality and user interface. There was no data persistence or multi-threading, but we did write extensive unit tests.
Lambdas and First Class Delegates
Once you start thinking functionally, it’s very hard to get out of that mindset. It’s so simple to create reusable components with just a touch of functional programming. While it may be technically possible to mostly simulate the same thing in Java using interfaces and anonymous inline classes, the extra boilerplate code and repetition really slows the process down.
An example, I wanted to create a simple data binding class that could handle linking up Swing UI components to my object model so I wouldn’t have to do all the getting and setting by hand. This is logically a class that says, “When a UI element raises a particular event, take an action – update the model.” If I could add a lambda, that update action could be set easily in the constructor of the binding – no need to create a separate binding class for every UI-component/model combination I need. Because I can’t define an Action-with-a-big-A, this becomes cumbersome. I believe, and am too lazy to check, that Java doesn’t support capturing local variables in an anonymous inner class, meaning there is an actual substantive difference between that and C# lambda expressions.
On the flip side, being forced to think about delegates as interfaces with implementations defined inline with a convenient shorthand provides a new perspective. IntelliJ IDEA even displays anonymous inline classes as lambda expressions, which is comforting to a C# developer, even if I can’t actually type in an expression and have it auto-converted to Java code.
I know, I know, it’s a little thing. But typing out the full name (even with IntelliJ IDEA’s great auto-complete), just feels like a waste of time to me now. Some argue that var can obfuscate meaning, especially when used to receive the value of a method call, but for initializing variables, it’s always very clear on what’s being assigned, and it always saves time, especially with big honkin’ generic type parameters.
It’s really a great piece of software. One particularly brilliant touch is the spell-check that’s enable in comments and inside camelCase or PascalCase code terms. I think that shows just how much JetBrains cares about code not just working, but also being clean, readable, and maintainable as well.
While it has a full suite of refactoring functionality, I didn’t need this for my basic school project. The pieces I did use were very nice, and the idea icon and code-highlighting (marking where in code a refactor was recommended, or a warning/error was detected) were very useful.
Emphasis on Abstraction
Almost all Java examples I looked at showed good best practices on using the most abstract base class or interface possible when creating a class. A common example was with List and ArrayList.
Even now I forget to apply this technique in my .Net code sometimes. To be fair, much of that confusion revolves around the fact that the .Net collections interfaces are a big ol’ ball of messed up, but it’s a good reminder that we use abstractions for a reason and (generally) they don’t cost us much.
Undecided – Exceptions
The forced declaration or handling of exceptions seems like a good idea on the surface, but in practice I couldn’t really decide if it was useful or busy work. I’d be interested to see if there have been any studies or research on if this sort of exception handling reduces defects in software.
A Nice Place to Visit
All in all, it wasn’t as bad as I was expecting. I wouldn’t be upset to do more work in Java in the future.