Very interesting blog about J2EE performance
Tuesday 1 May 2007 @ 10:36 am
Filed under:

Hi all,

Vincent Partington from Xebia has been blogging about J2EE performance problems he and his colleagues have encountered.

They have compiled a top 10 list. It is a very interesting read, as it is all very recognizable :-)


(and as that is where I stumbled across the link to Vincents blogposts)

— By Ruben Sprangemeijer   Comments (0)   PermaLink
javaone2007: coolest session title
Thursday 19 April 2007 @ 4:16 pm
Filed under:

This years javaone conference is about to happen and since my conference pass has been ordered it is time to wrestle myself through the program in order to find the most optimal schedule in terms of quality and time. Meaning a lot of reading, shuffling, weighting and head-scrabbing. A process which probably will last untill the last session of the conference. But some sessions are a definitive certainty. And one of these sessions tagged whith the coolest session title of the conference:

Java™ Puzzlers, Episode VI: The Phantom-Reference Menace/Attack of the Clone/Revenge of the Shift

After last years ‘Tiger Traps’, changes are big this session will end up high in this years top-10!

— By Okke van 't Verlaat   Comments (0)   PermaLink
Two-0-Four, Twelve times faster
Thursday 19 April 2007 @ 12:09 pm
Filed under:

Last week the latest release of the Spring frame work was announced on the springframeworkdotorg website. Nothing special, just an .0.x bugfix and enhancement release, actually nothing exiting. So why is it worth a blog entry? Because of the curious announcement that spring bean creation has gone through tremendous performance improvements. Let me Quote: “Regarding the performance improvements, repeated creation of Spring bean instances is up to 12 times faster in this release than previous versions of Spring 2.0. AspectJ-based weaving performance has also increased by a significant factor. “.

Wow, twelve times! That is a pretty precise and accurate number! So not ten, not eleven but exactly twelve times faster! But to bad, my manager asked me to speed up bean creation time by a factor thirteen so I think I need to switch to Guice instead.

The problem in this statement is not the number itself but the fact a number is used to express improvements in an area the expresser has no full control. Currently I’m downloading both the 0.3 and 0.4 releases of Spring2 and my first conclusion is the 0.4 release is about 1.01 times bigger in terms of megabytes (off the record, 62.2 MB for a framework download is pretty fat). My second conclusion is the 0.4 release got downloaded 1.3 times faster. Both are facts, (it’s happening straight in front of me!) but the last fact does not express anything! There are too many factors that are influencing this magic number. Same with the 12 times faster statement. I won’t argue about the fact 2.0.4 has improved bean creation and I immediately believe there situations the number is matched by the comma. But personally, it says nothing to me: I’ll wake up when someone tells me the startup time of all my spring based apps have been square rooted. And even then I’ll point to the useless sleep statements in my constructors which are sitting there only to invalidate bold performance claims.

Note I’m not trying to nitpick on anything; every improvement is more than welcome, as long as my beans see the light, but this kind of statements are besides hollow, technically completely insignificant. Why not give insight *what* has been done to improve performance. Like:

  • AbstractAutoProxyCreator caches advice information per bean, for efficient prototype creation with auto-proxying
  • AnnotationAwareAspectJAutoProxyCreator caches Advisors for singleton @Aspect aspects, increasing performance
  • BeanWrapperImpl mimimizes bean name parsing overhead and caches parsed property path tokens
  • DefaultListableBeanFactory caches pre-converted property values as far as possible
  • ConstructorResolver caches the resolved constructor or factory method, for faster re-creation of prototype instances
  • ConstructorResolver caches converted argument values, to avoid conversion overhead for re-created prototype instances

(As one can see, ‘grep “cache” changelog.txt’ clarifies everything)

Nevertheless, I’m pretty happy with this release and I’m only writing this down as an advice for the upcoming 2.0.5! And now the changelog is still open on my desktop, I can end this blog entry by probably the most important enhancement:

By the way, JRuby 0.9.8 claims IO sometimes to be 6.5 times faster ……

— By Okke van 't Verlaat   Comments (1)   PermaLink
Javacard introduction
Friday 23 March 2007 @ 10:21 am
Filed under:

A couple of weeks ago I joined a project that involved javacard technology. A search for ‘javacard’ on this site returned the rather disappointing ‘Sorry, no posts matched your criteria.’ on my screen. Today, there are literally billions of smartcards on the market and a large portion of them are javacards! Reason enough to add a javacard blog to this site, starting with a quick introduction into smartcards.

A smart card is nothing more than a chip (the ’smart’ portion) on a piece of plastic (the ‘card’ portion). Usually it doesn’t have a power supply, keyboard, mouse or display attached to it. To communicate with the outside world, it is placed in or nearby a ‘card acceptance device’ (CAD) that is connected to a computer. This setup creates all kinds of business opportunities like: identification and physical access (event- and travel ticketing), financial transactions, discount card, membership card, pre-paid cards, etc.

Enter java card. Java card technology enables programmers to write software for smart cards in the java programming language. The javacard programming environment, - virtual machine and - runtime environment can be looked upon as the light versions of their big brothers. Among other things, javacard technology doesn’t support garbage collection, threads, ints, longs, doubles, floats, strings and multi-dimensional arrays. Yikes! Programming javacard applications (applets) made me count my blessings. The normal, well-known java programming environment is really quite fancy! A simple task like subtracting € 3.25 in a javacard e-wallet applet already forces you to juggle with a couple of shorts. No floats or doubles, remember!

javacard application architecture 
Figure 1 - javacard application architecture

However, expressing yourself in a much more primitive environment isn’t so bad at all. It’s amazing how fast you can get used to an environment that lacks the common tools. For example: the java card communicates with a CAD using a byte oriented protocol. The CAD sends a command APDU (Application Protocol Data Unit) to the card and the card sends a response APDU in return. Figure 1 provides the reader with an overview of the components of a typical javacard application. So instead of calling a simple method like ’subtract(3.25)’, you could be sending the lovely APDU byte array ‘80 01 AE 0D 04 00 03 19 05′. When I was demonstrating an applet to a colleague I heard myself saying: ‘You see: the card returns 03 FF 4C 00 19 90 00; it works!’. Of course he thought I had taken leave of my senses, but the point I’m trying to make is that the human mind’ gets used to these circumstances pretty quickly. Maybe a debug file would be nicer, but when necessary, ‘03 FF 4C 00 19 90 00′ will do.

Taken together, programming with handicaps isn’t so bad. And because there’s such a huge market out there, the next time you feel like surfing the web, I suggest you skip youtube and take a look at some nice introductions into smartcards and javacards. Programming with more tools isn’t always necessarily better, and programming with less tools can be a nice challenge. Remember Maslows quote ‘When all you’ve got is a hammer, every problem starts looking like a nail’. It sure does!

— By Maarten Metz   Comments (3)   PermaLink
NLJUG gives away free Spring courses
Monday 26 February 2007 @ 1:53 pm
Filed under:

On my new job all Java consultants have a NLJUG membership. So when I joined the party I was given a NLJUG membership too. The name did ring a bell but a very faint one, so I decided to check out their website. NLJUG is a Dutch community of java developers. The first thing that caught my eye on their website was a Spring course given by or at least sponsored by NLJUG. The Spring framework caught my attention some time ago, but I never got around getting familiar with it. I decided that it was time to get acquainted with the Spring framework. This was a great opportunity and one other advantage of the course was that is free of charge.  

There are a few things they would like to know about every possible participant, like how many years of Java experience you have and how much time you have for exercises. After I send them an email telling them I had lots and lots of time and that I was really interested in learning Spring I had to wait and see if the would take the bait. After two week I got an email from NLJUD in which they congratulated me with my enrollment in the Spring course. I was told that I was very lucky with my enrollment, because there was a lot of response for this course. I think the exaggerated a bit but the important thing was I could participate and I was looking forward to it.
The course was given by two experienced Spring developers who would lead us into the world of Spring. Our teachers had there work cut out for them. The entire course consists of four study sessions followed by a session in which we would get our certificate, something like a graduation day. Every study session would treat one specific subject.

  • Day one:    Power to the POJO.
  • Day two:    Spring for the Web.
  • Day three: Connecting your database.
  • Day four:   Remoting.

Every study session has three or four exercises attached to it. Because there the study sessions are two weeks apart there’s enough time to finish the exercises and send them in for evaluating.
There is a website for everybody who participates in the course. Here you can download the sheets shown on the study sessions, view the exercises and afterwards view the solutions. There is even a page where you can view your progress and that of everybody else. It shows your score for every solution you have provided and a big red cross for every exercise you failed or forgot to turn in. Some exercises are not mandatory and it turns out hardly anybody provides solutions for them. I don’t know if it is just a lack of time but at the end only three of us have provided solutions for almost all exercises.  

According to the teachers the first exercises should take about eight hours. Maybe it’s my inexperience with a XML configurable frameworks but it took me a bit more. After a little fight with Tomcat and Eclipse I’m ready to go. The first exercise is about configuring and wiring Spring beans. It turns out the sheets shown during the first day do not contain enough information to make the exercises. Luckily someone advised me to buy “Java Development with the Spring Framework” and after reading the first chapters the exercises were a piece of cake.  

This course of action seems to work very well for me. In the two weeks in-between courses I read the chapters that are covering the subjects of the next study session. It makes the study sessions easy to follow and it gives me the opportunity to ask questions about parts I did completely understand. Another advantage is that the exercises are not as abstract as they were the first time. It still takes quite some time to make all the exercises, but after the first exercise of the week is complete, the other exercises are more or less easy going.  

The final session was a more of a meeting. Most participants took the time to come together in Hilversum to conclude the Spring course. We discussed the last exercises for a short time and then it was time for drinks and snacks. The rest of the time was spent on talk about our experiences in general and with the course we just finished. Most people we quite satisfied with the sessions that were provided. After we thanked them for there time and effort it was time to go home, with a certificate telling us we know something bout Spring.  

Looking back at the Spring course I think it was worth my time. The exercises gave me insight in how to use Spring. The study sessions were a bit too long for my taste, especially because they were three hour evening sessions in Utrecht. If you planned to participate in the next course somewhere in spring 2007, you should ask yourself if you are willing to spend some time making exercises. If not I suggest you get yourself a good book, cause the study session alone are probably not worth your time.  

— By Jan Peter Ruiter   Comments (0)   PermaLink
A short one
Friday 23 February 2007 @ 2:24 pm
Filed under:

Here are a few lines of code I found in an application that I’m currently maintaining. I don’t know who wrote this code originally.

// Values read from somewhere
int budgetSpent = ...;
int budget = ...;

// Compute percentage of budget spent
int percentage = Math.round(budgetSpent * 100 / budget);

The last line of code is wrong. Can you tell me why? Every Sun Certified Java Programmer should be able to anwer this.

— By Jesper de Jong   Comments (6)   PermaLink
Java Scripting
Tuesday 12 December 2006 @ 4:31 pm
Filed under:

Currently i am attending the JavaPolis 2006. A nice event with interesting topics and nice interesting people to meet. It is located at a nice venue in Antwerp called ‘Metropolis‘. If you are in the neighbourhood it is surely worth a visit and grab a movie if you are there. Enough said about the venue lets talk Java.. Yesterday the JRuby guys had a nice talk about the current state of the JRuby platform and possibilities. The current JRuby implementation and Rails framework are more or less available ontop of the JVM. It is interesting because it opens possibities using the Ruby language ontop of a robust JVM environment so we can program Ruby using the possibilities the Ruby language gives us and combine this with the awsome power of Java. I cannot wait to get my hands on JRuby and start creating some applications.

— By Marco Pas   Comments (3)   PermaLink
All I want is coffee flavoured coffee!
Wednesday 22 November 2006 @ 3:03 pm
Filed under:

Never thought I would ever quote Denis Leary in a J2EE context but I’m dying for coffee-flavoured-coffee right now. Just one (damn strong) taste of coffee which strikes the tongue and keep you awake. I’ll try to explain

The immediate cause: InfoQ’s has published an interview with Gaving King about the evolution of Seam, Gavin’s version of a framework telling you how to build (web) applications. I’ve written about Seam before and at that time in my opinion the framework was based on some interesting ideas and principles but lacked simplicity mainly caused by hard to set-up working examples. Never looked at it again (although the intentions were there ….) and I’ll point out immediately I’ll probably won’t look at it right now. So what’s so interesting about the interview? Besides some nice food for thoughts about the implications of a fine grained AJAX approach on database load and some old insights about the effects of state management on clustered environments, not very much. Except for one small comment Gavin makes as a reply to someone commenting exactly what has hit me one year ago. Let me quote:

Comment: I haven’t gotten the time to try out the new Seam release but I hope that setting up a project has gotten easier.

Gavin King’s reply: seam-gen makes it *super* easy, at least for EJB3 on JBoss users. We will be working on expanding the functionality of seam-gen to support other usecases (JavaBeans+Hibernate, Tomcat, J2EE, etc).

And that answer shows exactly what is completely wrong with the so called enterprise edition of java: There is no simple straightforward one-way road for doing things! Choices, choices, choices and a lot more choices that make life easy to model but hard to implement. Isn’t the power of application frameworks that choices are made four you? I would expect a framework like Seam dictates me to take the EJB3 route and pave things in such a way I really start to like the usage of EJB’s. Gavin, seam-gen is okay the way it is, actually it is right what was missing in your initial try. Instead of focusing on other choices, focus on more/better/advanced code generation! Expand into real functionality and help developers by filling room instead of giving it. Another illustration from the exact same interview: the different JSF frameworks Gavin lists. They seem to talk with each other to guarantee smoothness. Gavin calls this maturity, I rather use the term abstemious. A small sidestep without going into a fully blown JSF discussion but isn’t it remarkable (that’s the right word for maturity!) within EE we need a standard (JSR 299) as a glue between two other standards (JSF and EJB) in order to deal with application components in a unified way.

Right now I see a lot of developers (technical designers, architects, name them) spending too much ineffective hours on the which framework to utilize and which standard to adopt question. (not even mention the effort that can be thrown away due to steep learning curves and unexpected showstoppers after the answer to this question once again has lead to unknown trails). One can argue technical design is all about decision making and deciding what to apply is part of it. But in my point of view, technical design is all about the decisions that need to be made in order to translate a business problem into a technical solution. It’s not about choosing frameworks for every layer we can think of. Why are we programming Java? Not because at the start of every project we reconsider it. Nope it’s because we know the language and we know the language is capable of building what is desired in a (cost) effective way. And maybe once in a while we enter some self reflective mode to find arguments that reach beyond the arguments needed to make choices in a project context. And once in a while we pick up innovations, jump on bandwagons and maybe leave the paths we’re walking. Simply because we (as in the average software developer) know that when we do this every day, we can not keep pace with those who don’t.

Why is it frameworks and standards are treat in a different manner? What makes the adoption of yet another framework or standard so tempting?  The steps of changing seem to be relatively small. Due to the it’s all Java isn’t it and hey we have a new project so what the hack we’re here to learn aren’t we mentality, risks are not identified clearly. And as a result, unified application development is a farce and for every different twist, more glue is needed. And as soon as the need for glue is identified by more than one developer, new frameworks and standards arise.

Note, this blog entry is not meant to bash Seam nor the interview. It is meant to address a fundamental problem that has been floating around for a while and has been addressed in the past but seems to be persisting enough to get repeated every now and then. And Seam just functioned as a trigger (this time). Everyone who like to use Seam, go ahead, fine with me. If you do not mind, I’ll focus (projectwise) on a Spring based application design until Rails has really swallowed the way I think :-) . But if you use Seam, stay with it at least the coming years (and so, stay with EJB3 and push Gavin to put all his energy in this choice instead of serving all other ways to technically layout an application).

A final thought: Is it a coincident Joel on software has published an article about choices (=headaches) on the exact same date as the interview publication? It probably is. But what Joel describes (15 ways to shut down your laptop) is exactly how we (as in the java community) build applications. Nuff said. Where’s my coffee?

— By Okke van 't Verlaat   Comments (3)   PermaLink
ui, gui, yui …. and beyond
Tuesday 26 September 2006 @ 11:41 am
Filed under:

Some people seem to have either too much time in their hands or are exorbitant effective spending time and energy in order to produce beauty in a browser. Take a look at YUI in combination with Yahoo.ext: just for the sake of showing an example, Jack Slocum, the creator of Yeahoo.ext, has build a rich frontend on top of a well known php based discussion system. Prabably the first time I see a rich internet framework/toolset/library coming with a decent and out of the box useful example. Pretty cool I think!! (now sit and wait untill the GWT’s, the Echo2’s, the Dojo’s and the whatever ajax branded yet to come personal-but-o-so-aha-good-looking-investments are coming with their version of dynamic skins for phpBB :-) )

— By Okke van 't Verlaat   Comments (0)   PermaLink
happy birthday alphaworks
Tuesday 26 September 2006 @ 9:41 am
Filed under:

happy happy happy, joy joy joy

This should have been posted yesterday but just listen to the podcast or read the transcript from the team that gave use one of my favourive programming toys.

— By Okke van 't Verlaat   Comments (1)   PermaLink
Next Page »


Sha256 mining

Blog Categories

Browse by Date
September 2007

Upcoming Events

Monthly Archives

Recent Comments


XML Feeds Option

Get Firefox  Powered by WordPress

code validations
Valid RSS 2.0  Valid Atom 0.3
Valid W3C XHTML 1.0  Valid W3C CSS