Comments (0)

By fungrim, April 16, 2009 10:24

Btw, I unearthed a Java concurrency bug the other day. Here’s how.

Comments (0)

By fungrim, February 25, 2009 18:34

I have a new article up on how to debug class loading with AOP at Cubeia’s site, in which I briefly discuss how Aspect Oriented Programming (AOP) using AspectJ can be used to debug class loading, in particular in instances where a system have multiple class loaders. Check it out!

Comments (0)

By fungrim, July 26, 2007 16:46

Perhaps I’m being a bit grumpy today, but this article rubs me the wrong way. It describes the Singleton pattern in Java but contains some problems. And one of the is a pet peeve of mine. The article claims:

• There can only be one singleton instance per JVM == Plain wrong in every respect.
• Singletons are good for object pooling (such as connection pooling) == Dangerous.
• You can get away with synchronization problems with a nested inner class == Naive.

The singleton pattern does not guarantee anything regards to the number of instances of an object, and certainly not per JVM. You see, even if we disregard cloning, serialization, reflection or thread safety the following is still true: A class instance of an object is guaranteed to be unique per class loader, not JVM. In other words, if you have multiple class loaders (as do almost all application servers) you can have multiple instances of a singleton per JVM; one for each class loader.

Singletons can help guard limited resources such as object pooling. That is correct, but the implication that it is good design to use it to do so is wrong. Statically held object pools in larger and long running applications and servers are not a good idea as their lifetime cannot be directly controlled by the code. Also, if there are multiple class loaders… See the paragraph above.

And the synchronization discussion is naive as one of the comments suggests. See this, this, this or google it yourself.

So, yes, the Singleton pattern is useful, but not as massively so as many articles and tutorials suggests. In a world of serialization and class loader hierarchies it can be a real pain in the ass as well. Use with care.

Comments (0)

By fungrim, July 24, 2007 18:46

The Codist asks what open source frameworks we use. Now, he says frameworks, but it looks more like libraries and utilities. Which is fine by me as I generally tend to avoid the larger frameworks, and just as The Codist himself wrote my own web framework for my regular site.

So, without further ado, here’s some regulars:

• Jetty – good stuff
• c3p0 – JDBC pooling
• log4j – logging, I don’t really like it, but…
• jgroups – data distribution/messaging
• JBoss Serialization – for high throughput servers
• JBoss Cache – data replication
• Mina – network IO framework
• XFire – for all your SOAP needs
• HSQLDB – just works, but I’ll probably check out H2 soon
• Jaxen – very good xpath engine
• Hibernate – ORM, because it is more or less standard
• GNU Trove – primitive fast collections
• Wicket – if I really must code an web UI

But I must admit, for my home coding I use a lot of my private libraires, I’ve got my own XML API and XPath engine. My own commons collection, UUID API, simple object -> XML lib, logging, email API, etc.

Comments (0)

By fungrim, May 22, 2007 20:04

My book library have been updated. First, the latest installment of Steven Erikson’s epic fantasy series, The Bonehunters. I am, as I suspect many others, slightly in awe of Erikson. Extremely complex. Extremely well written. Extremely good stuff.

The second update is the classic The Design of Everyday Things, by Donald A. Norman. This is really good stuff, and anyone aspiring to design software, be it GUI or API’s, really, really should read it. I picked it up after reading an interview with Ken Arnold over at Artima.com:

Taste is a very personal thing. There is no textbook. When people ask me about books on object design, the books I hand them have nothing to do with object design per se. I commonly recommend The Design of Everyday Things, by Donald Norman. This book promotes focusing on usability in the design of doors, teapots, and faucets – everyday things. If you do that for objects, you’ll have the idea.

Oh yes, Ken Arnold as in:

State is hell.

Or:

Every program has at least one bug and can be shortened by at least one instruction — from which, by induction, it is evident that every program can be reduced to one instruction that does not work.

Comments (0)

By fungrim, May 21, 2007 18:38

This years JavaOne announced several important Java technologies. The one that got most initial attention was of course JavaFX. Well, exciting as this may sound I wasn’t alone in wondering how on earth Sun could hope to launch such a technology on their existing platform. Take these bullet points:

• Huge download (JRE)
• Slow startup (no pre-loading here, no)
• Crappy browser integration (seen any applets lately?)
• Bad JRE detection (part of the above problem)
• Somewhat slow graphics performance
• Sub-standard installer

As a profoundly specialized server developer (I still have nightmares about the one time I had to dive deep into the source of JTable and JTree, the horror! the horror!) I’ve never been very concerned personally. It has annoyed me on an academic level, as I’ve never understood why Sun just didn’t smarten up and fix it.

So why launch JavaFX now? Well, it turns out someone was a bit smarter than I first thought. You see, there was an announcement made on JavaOne which got drowned out a bit, the Consumer JRE. It would appear Sun has finally granted all our wet dreams. Here. And here.

Wheee! Damn good stuff!

Comments (2)

By fungrim, May 14, 2007 17:12

Rob Walling has posted an excellent article on How to become a programmer. I especially liked that he stresses the importance of apprenticeship, formal or not, if nothing else because that’s how I did. My first two years as a professional I played wing mate to Mr Gibara, which was in hind sight, extremely valuable. I also agree to his answer on the question “Is it necessary to know mathematics?”, although my answer is simpler but, if I read him correctly, amounts to the same thing: No, but in order to be a great programmer you need to be good at it should you apply yourself. In other words, you can be a good programmer in many fields without knowing maths, but I have yet to meet a great programmer who wasn’t at least in potentia good at maths too.

Other than that, two comments on his article prompted me to add my two cents to the stack:

Is programming an art?
No, it is not. Although “art” can be used as in “the art of driving a car” very few uses it, and mostly my impression is that the following definition is the most understood:

4 a : the conscious use of skill and creative imagination especially in the production of aesthetic objects; also : works so produced b (1) : FINE ARTS (2) : one of the fine arts (3) : a graphic art

But reading Merriam-Webster shows up a synonym which in my mind is much closer, that of the “craft” (m-w.com here). Programmers do not create art, the most important thing when programming isn’t to stimulate the mind, it is to produce working software. In fact, I think Wikipedia actually nails it:

For example, a painting may be a pure art, while a chair, though designed to be sat in, may include artistic elements. Art that has less functional value or intention may be referred to as fine art, while objects of artistic merit but serve a functional purpose may be referred to as craft.

Bingo. If you can’t sit in the chair you aren’t a craftsman, but you may still be an artist. There are also other stimulating similarities between a craftsman and a programmer, we have our tools and our toolbox. Craftsmen of old often traveled to were they were needed. A craftsman, at least in my imagination, has pride (and to me, pride is a vital component if you want to be a great programmer). Etc.

Do not forget: programming is a task that can be learned much learning a foreign language, or how to refurbish a bathroom. In many fields you can be a good programmer indeed without the slightest bit of creativity, curiosity or mathematical abilities. The difference between the master and the merely very good isn’t necessarily about artistic abilities, it is all about how good [insert definition here to your own liking] the end product is.

Is programming engineering?
No, it is not. In some fields, like aviation control or satellite navigation, it may come quite close, but I wager it isn’t there either. There are many reasons for this, but merely asserting “if only programming was more like engineering” is like wishing for cold fusion: it would be nice to have, but we have no idea how it would work. Many smarter persons than me have discarded this notion so I’ll leave it as this.

Comments (0)

By fungrim, May 13, 2007 11:16

Currently Cubeia Ltd is using the methodology called Scrum, which is a part of the family of so called Agile software methodologies.

Works fine for us and many others. There are some problems though. One is that it feels curious committing on hard deadlines in the future, “product X will be delivered at date Y”. Another is the lack of a design phase, and hence this little post.

Designing component X is about finding out how X is supposed to work (perhaps you’d call this “requirements”, but I think there’s a tangible difference between “requirements” and “specification”), how X can be made to work as specified, and how we can ensure X a long lifetime, in other words that X can be reused and that X will not impair future designs.

Design is hard.

Software has become a commodity. It is everywhere. The mass of software produced worldwide is staggering. And 99% of it is bug-ridden and/or badly designed.

When people ask me why software isn’t like engineering, perhaps something in the lines of “why does software always have so many bugs, I mean, we can build bridges and machines, and they don’t have that many errors do they?”, I usually sneer back: “Well, give me enough cash and I’ll give you bug-free software.” This may sound strange considering how much software costs to develop as it is, but not if you take software complexity in mind. A bridge for example is, at least in its basic forms, is simple, static and built with material which has static and reliable properties. Software on the other hand is often complex, dynamic and is very seldom build upon reliable hardware components.

Scrum works because it provides a pragmatic way forward in a rapidly shifting and changing problem domain. On the other hand, more traditional “engineering” does exist in software development. And no, I’m not primarily talking about waterfall methodologies, but something like this: How do they write software at NASA? It should be pointed out quickly though, that, say,  an ordinary web developer, has no control over that hardware, whereas NASA probably knows on beforehand exactly what hardware the software is going to run on, so you can perhaps remove one tier: complex, dynamic but build on reliable components.

Seems to work well for them. I’d love to try it one day, if nothing else because I hate, with all my body and soul, to write bugs; to the point of physical nausea at times. But I doubt we’ll see any major revolution in the software industry yet for a while.

Design will remain hard.

Comments (0)

By fungrim, March 26, 2007 16:51

Hacknot has put together a good article on the rise of the “dynamic” languages as we see it in publiscations all over. Ruby is the new shit. Or, as it may well be, not. Well worth reading.

I liked the article. The points are well made, and I wish I had expressed many of them myself. And it flows with an hilarious sarcastic edge, I read the whole stuff from start and started laughing when I reached the “Conclusion: For Weenies” which brings the irony and sarcasm into a wonderful full front assult.

Comments (0)

By fungrim, March 16, 2007 19:14

There’s an article on DevX comparing the three major Java IDE’s, picked up by Mats Henricson of Crisp fame, here (SV).

I have a small grief with the article. Nothing major mind you, just a small grief.

To start off though, a small clarification. The article compares the editors in some separate areas – which is comendable – namely Swing, JSP/Struts, JavaServer Faces (JSF), and J2EE/EJB3. Of these the only one I’m at all interested in is EJB3, and when I do code in EJB3 I expect I’ll belong to the “hard coder” line, and do most of it be hand. Hard coder? *shrug* I guess so. (For example: Hibernate/JPA support? What’s the point? It’s not exacly rocket science is it?) So given its constraints, I haven’t got much to say as I don’t expect to have to use those features for quite a while, and don’t mch disagree with it’s conclusions anyway.

But its constraints, I do have something to say about. It seems that every article I glance at comparing editors are written by an author thinking along these lines: “Oh, and Eclipse have all those plugins, how tedious. I’ll mention them and the community and then go on and compare Eclipse without them anyway, that’ll be much easier, and fairer too.” This seems a bit strange to me. You see, I’ll believe that the plugins and the community around them is one of the major contributing factors to why people like Eclipse. Many coders will of course be unable to articulate why they use a particular IDE at all, it is mostly habits, but when you sit down with them I’ll bet you that the plugins are there in the “good bits”-list in 95% of the cases. And if it is so, wouldn’t it be fair to include them?

Take this qoute from the article for example:

Out of the three IDEs, Eclipse is the only one that exists in multiple versions/distributions, starting from the base distribution to pre-packaged ones with extra open-source plugins (such as EasyEclipse) and open-source/commercial hybrids such as Genuitec’s MyEclipse. In order to provide a fairly realistic review of what Eclipse is capable of, I focused on the base distribution (including default Eclipse sub-projects such as the Visual Editor and Web Tools Project). Wherever I felt it was lacking, I also considered what MyEclipse offers as a commercial alternative. Frankly, at a subscription price of $49/year, I’d be hard pressed to find any commercial IDE with the functionality that MyEclipse provides.

“Fairly realistic review”? I don’t understand. So it is ok to use some plugins but not all? Also, if you’re realising that Eclipse is quite a different kind of beast, thanks to the community and the plugins, why do you insist on comparing apples with oranges anyway? Or, why not ingore features from the other two editors instead? Wouldn’t that be even fairer? I mean, the article author does mention that he found 24 (!) different Struts plugins quite easily, but that, somehow, doesn’t count?

Seriously. ’tis silly. If you are evaluating Eclipse, include the plugins. Otherwise, people like me might not take you seriously enough to listen.

That said, I thought it was quite a good article anyway. I’ll stay with Eclipse for a while though. The perspectives/views fits me, I love the debugger, and I really like the platform (inluding the plugins). For example, right know I’m writing a custom launch configuration for my company which will make it amazingly simple to develop multiplayer games on our platform. I just find the ease of which I can extend the IDE functionality really cool.

And, if you didn’t know, OSGI, upon which the entire Eclipse platform is built, rocks.