6 posts tagged “java”

Not sure why I took so long to source a networking library for use at work. I've already wasted so many hours dealing with packet fragmentation, socket handling, and assorted bugs. (TCP isn't a great protocol for sending messages. I await SCTP adoption eagerly.)

Not only fragmentation, but dealing with simple stuff like reading and writing using Java NIO. ByteBuffer is oddly a hard class to use. Something about having to flip it around and whatnot. It's also fixed length buffer, which makes it pretty much inappropriate for serializing a variable length message.

I went with JBoss Netty on a project which handles framing, has a nice replacement for ByteBuffer, and a pretty simple and elegant architecture as well. And I managed to implement a replacement for an old bit of code in about two, three hours, just following the surprisingly good documentation and examples.

There are a couple of things to keep in mind. One is that all reads/writes are asynchronous and even closing the connection is asynchronous. Thus, you need to pay attention with the ordering.

Competing products Grizzly and MINA don't seem to be as simple or have the above features.

In the new world of frameworks and dependency injection, objects are typically constructed "empty" and have a series of initialization calls made to them, and often (in Java) a series of disposal calls.

This initialization can't really happen independent of the framework. You lose the flexibility of using your code without the framework. (Generally speaking, anything "really interesting" in your code should be independent of the framework, so usually this isn't a great loss.) But frameworks (usually) ask you to violate a fundamental principle of OOP: Which is successfully constructed objects should be fully functional.

A common "code smell" you run into often is when you try to use an object but have to do 3-4 method calls to even use it, e.g. "setX" "setY" and run "init" or "start". It's not onerous to require this but developers are horribly lazy and will use your class "wrong" the first few times and curse you and your family.

Web Beans allows for multiple styles of injection. Luckily, and unlike Seam on which it is based, it supports an @Initializer annotation for injecting dependencies when creating components. This is annotation is used on a construction and allows for immutable objects as well. This style of injection is borrowed from Google Guice.

(Web Beans, is summarized thusly: A combination of Guice, JSF, Java EL, and Seam for Java EE.)

Programmers write code and code review is often required by managers to be done prior to code submission. I tend to dislike the process since there's a tendency for reviewers to place an emphasis on certain trivial problems and little attention is made to important qualities.

Here's my list of what a code reviewer should look for, from most important to least important:

1. Validation by additional or changed unit tests.
   
2. Duplication of functionality available elsewhere. Ironically, a lot of programmers like to rewrite things, even though it's obviously more work for them.
   
3. Sections of code or idioms repeated.
   
4. Clarity in what the new functionality does.
5. All code is clearly required. Programmers love to make things that "might be useful someday" and usually it's never used. In Java, I often see people implementing "equals/hashCode", serialization, etc. for classes that never use these methods.
   
6. Signs of junior programming practice: "Utility" classes, "Constant" classes, multiple layers (see 5), singletons, and other "Design Patterns Book" nonsense, etc. Note that utility classes aren't really bad per se, it's just that they are often written instead of supplying the appropriate functionality to an existing class or writing a new class.
7. Untyped or too many parameters. Often the same sequence of parameters appear in multiple places, see 3.
   
8. Premature optimization. See: 2. Actually this doesn't really matter as much, assuming this optimization is well tested.
9. Class names that repeat the current namespace. Names that are too long. See 3.

The above common problems are pretty easy to spot. The longer you spend on code reviews and generating comments the more it seems you're being overly critical, so always comment on the most important areas only.

Here are things that aren't as important and almost worth ignoring:

1. Code (in)correctness. It's fairly impossible to find bugs just by reading code and unit testing is hopefully going to prove the code is correct. If you do spot some problem, mention it, I just don't see why you should try to "run" the program in your brain, that's what automated testing is for.
   
2. Missing boiler-plate information, such as legal or copyright notices. This can be corrected using a tool, if needed. We eventually stopped adding boiler-plate to code at m-Qube since our code wasn't shared.
   
3. Lack of code comments. The problem with most comments is they take up space, are often wordy, and don't explain anything new. Comments grow more and more inconsistent over time, so it's almost better to leave them out until the end of a project.
   
4. Improper formatting. Batch tools exist to fix formatting, so there's no need to address formatting concerns in the middle of a project. But since converting line endings causes trouble for code merging, if you see line endings change mention it.
5. Lack of parameter checking. It's a good idea to check parameters when constructing objects, but especially in Java it's not so important for every function.
   
6. Not following naming conventions. Some reason people I work with insist "enum' type names should end in "Type", but everything is a "Type" already so I don't see how it clarifies things. I also worked with people who wanted Java interfaces prefixed with "I", which is not done in the standard Java library. If 90% of programmers don't follow your naming strategy, then maybe it's not necessary.

Windows XP, that venerable operating system from Microsoft, wants to update itself every so often. Then, for a week after the automatic update, every hour a dialog box pops up asking permission to restart Windows. And I do my best to ignore it since restarting and getting everything back up takes about 20 minutes.

Today I started working and immediately the system died; audio was still playing but none of the application windows were visible. Perhaps because I refused to apply the updates? Then I restart. I log in, then as soon as I start to get to my desktop, it blue-screens.

I also got hassled by Firefox, Java, and some other software with automatic updates today.

To me, it seems the most buggy software has the most frequent updates. But I experience roughly the same amount of hangs and lock-ups in Windows. I also updated Eclipse (IDE) and it seems to crash just as often as before, about twice a day on average.

I was introduced to JBoss at m-Qube, when several developers selected it to build the applications that made up the m-Qube initial offerings. Once I got over the initial discomfort of understanding this new system (from Tomcat I had used almost exclusively at Openwave), I fell in love with the elegant JMX microkernel and the powerful built-in features which I had previously had to write myself or bring in with third-party software. I later started building additional components and -- most importantly -- identified or fixed many bugs in the product. Soon after a few patches, I was able to get access to the source code and make modifications myself. Although I didn't find Adrian Brock or other JBoss developers to be very welcoming of my contributions, my code got to get in.

The system built on top of JBoss at m-Qube eventually attracted several buyers. Last year, the company was bought for $250 million in cash. Without JBoss, and the fact it was open source (free software) and open for me to add critical features, I'm not sure we could have easily built the software that we had. Perhaps if we were on top of a proprietary system our market valuation would have been less? It's hard to say. Sometimes the features, such as the messaging system, were buggy causing outages. There were problems in upgrades to newer versions that caused random start-up class-loading hell, some bugs that got me up in the middle of the night on the phone with our operations team. But proprietary software is not necessarily less buggy, and if it is, you rely on your vendor for help and cannot often fix the problem yourself. That puts you in a powerless situation many times.

Last year, I quit m-Qube after acquisition by Verisign. I was ready to move on from my four years. I was actually looking at JBoss as a potential employer and had interviewed with them, to join with the JBoss Messaging team. I turned them down, because they offered less salary than m-Qube was paying. It also seemed likely I would be working hard or harder than I was at m-Qube, which was pretty hard and tiring, and Autodesk was attractive for being (likely) less stressful.

One of the downsides with Autodesk was I would be "forced" to work with BEA WebLogic. This is not entirely bad, as Weblogic is arguably the best proprietary application server. However, it was immediately evident that Weblogic was missing many useful (perhaps key) features that JBoss provided back in 2002. And as part of the next release of a system, I'm considering JBoss Microkernel integrated with Weblogic as a way to gain some of the features I miss.

Autodesk has been very kind in allowing me to go to JavaOne. Typically, when a largish company is doing well, they allow their developers to go to trade conferences. I don't know to what end, though I'm learning a bit of this and that. It's unlikely that many things will be adopted by the fairly conservative division. If anything, I understand my position as a Java "expert" a bit better.

I'm also here to have a good -- though educational -- time. From the JBoss.org website, there was a party scheduled for tonight, which simply required a registration form to be completed. I was generally curious as to the content (Who goes to these events? What sort of food or music do they have?) as well as I wanted to meet some of the developers I usually interact with only on-line. Now, I don't really have "friends" I continually interact, mostly people who from time to time send me messages. But I wanted to put a face to these people.

I met a few non-JBoss developers from Holland. Some JBoss people were kind enough to approach us. I met some old guard JBoss developers. I also met a developer from Singapore working on some distributed processing software built on top of JBoss. I ran into the JBoss recruiter who was interested in finding "top level" Java developers. I talked about my reasons for turning down JBoss (stated above). And despite any body's outward interest, I rambled on about some of the software I worked on, on top of JBoss. I ate some food and drank free beer. The party started winding down around 8:30PM.

I wish the JBoss team a lot of luck. I hope that, if for some reason, I get fired from Autodesk or can't find work elsewhere, I can work with the JBoss team. And I'm sure if I moved to Fiji they'd let me work there, and that sure would be convenient.

I've been a Java developer since JDK 1.0 beta back more than ten years ago at the start-up Starwave. It's exciting to follow all the new developments of this now mature platform, and through the generosity of Autodesk, I got to go to my first JavaOne conference.

Most of my conferences have been anime-related, and this is (maybe?) my first professional trade conference. I scheduled myself to attend mobile-related and server-related sessions. Here's my thoughts on Day One.

First of all, I found a lot of the content and presenters to not be as polished or quality as I had expected. Most of the panel presentations were 90% text and 10% examples and demos, and as for the speakers some of them weren't so good in English or very engaging. The talks were also quite short, in that only a few times did they actually have time to answer questions after presentations. And though the general conference session I attended did have engaging demos, much of it was thinly disguised shilling up Sun's technologies or platforms. The dramatic music when speakers came up on stage and scripted banter between speaker and keynote speaker was a little phony.

My goal was to keep my eyes open for technologies we should be using at Autodesk. The problem is many of the newer technologies we cannot yet use since we are "stuck" on a fairly old application server (Weblogic 9.2) for JEE, and it has only been very recently that we can now exploit JDK 5 features. The scope of third-party libraries we may want to use is actually quite small for the next release.