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 (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.

Comments (0)

By fungrim, March 12, 2007 18:46

Regarding my last post about Spring. The crazed man himself tells me that Google now have released its own IoC framework. Hum… I’ll have to check it out when I get time.

Comments (2)

By fungrim, March 11, 2007 11:02

Crazy Bob had a post i January which he got a lot of feedback on, namely: I don’t get Spring. Spring, as in the Java framework of course. He has a lot of specific concerns that I won’t repeat here, but many of them are good.

Introduction
I’m afraid I don’t “get” it either. Religion does that to me, as soon as someone tells me if I would only get it I would understand, I automatically back off, ready to fight. I mean, if I only would let Jesus into my life I would start believe, right? And if I would only start getting Spring I would be a follower too, right?

Yeah, right.

You don’t think it is a religion? Well, try critizising it, and then check what kind of responses you’ll get. (In fact, have you read a critical analyzis of spring at all? Probably not, I know that I haven’t. And that worries me, and apparently Crazy Bob as well, a bit). Or you can read Bobs post and then scan through the comments:

• “I use it and it works for me”
• “If you just get it you would understand”
• “So? Don’t use it then”

And many will testify to the fervor with which Spring advocates jumps at any doubting voice. (Also among the comments, there’s some long sales pitches from Keith from the Spring Web Flow team.)

So why am I sceptical? Well, the religion issue apart, here’s some things about Spring which I question:

• It is not very a light-weight sollution
• Spring does affect you code
• There’s no clear demarcation between code and XML
• Spring XML effectively is another language
• Refactoring and debugging becomes a pain

Let’s take them on, shall we?

Heavy Ball and Chain
Light-weight? Erhm, no, I don’t think so. Light-weight in my book means small, non-intrusive and without any particular runtime impact. Also, I don’t expect light-weight sollutions to have any significant impact on my coding style. And let’s not forget what Bob points out, the public contracts of Spring are very much not light at all (but to their defence, they do have extensive API documentation provided).

Don’t Touch My Code
Contrary to claims, spring does “touch” my code. Just becasuse what injects your dependencies on the right places sits outside your code instead of within it, doesn’t mean it doesn’t exist. I mean, how do you start you application? It is correct that no Java code is visible in your project, but this is not necesserally a good thing. And as Bob puts it:

Spring advocates tout that Spring doesn’t “touch” your code, i.e. you don’t have to implement any Spring-specific interfaces (with the exception of life-cycle interfaces, etc.). News flash: the XML configuration *is my code*, and from what I can see it often ends up constituting a lot of code, all of which is Spring-specific.

Demarcation
Where do you draw the line between Spring and Java? If you do it too coarse-grained you don’t particulary need Spring at all, but as you penetrate deeper the amount of XML will grow rapidly, and that will soon become a problem. I have been in projects with fully grown “XML Hell” problems. It. Is. Not. Funny.

Mixing Langauges?
Please read the Bob-qoute a few paragraphs above: XML is code in a Spring project. A “fully Springified” project will most probably, thanks to the demarcation problem, have a lot of XML files in a 3rd party language. In other words, in order to fully understand, and therefore effectively work in, such a project you need to be fluent in Spring. Light-weight? No. Does it affect my code? Yes.

Do I really want projects written in two separate lagauges? Perhaps it isn’t a problem, but you must understand that when you take the Spring step, you are forever relying on dual-language programmers to work on and support it. And large projects tend to live longer than their programmers. That might be a really big problem for any Spring project in the near future. Seriously. What if you can’t find any good Spring programmers to hire? Legacy code is bad enough. Legacy code in an obscure XML language that no-one really uses any more is even worse.

Hard references and strong types
I like strong types. I like hard references. They make my life as a programmer so much simpler. And both of them are negatively affected by Spring. This problem will shrink a bit when IDE’s becomes better at handling Spring files for you. But right now, they’re not up to schratch.

Conclusion
Does this mean I don’t like dependency injection? Not at all. Good programmers do that all the time without the help of any heavy-weight framework. Does this mean I will never use Spring? Not at all. But I consider the above points very important and unless I’m wrong, which of course may well be the case, I’ll probably try to stay away. And to be very, very clear to any Spring zelaot happening to read this: Don’t bother to answer unless you have answers, they’re specific, and to the point. I’m not interested in your religion, I’m interested in writing damn good code.

Comments (0)

By fungrim, March 1, 2007 20:51

And yes: Today Cubeia Ltd started officially! Wheee! And I got a shiny new 22″ wide LCD to work on (here, in all its splendid glory)! Wheee! It is all really, really sexy! Wheee!