Thursday, October 28, 2010

VMWare and Spring

VMWare bangs their bells for Spring framework, trying to tell it is best choice. Lots of people excited etc.

Now (*cracks my fingers*) questions and doubts:
  1. Spring's arguments are valid. Yes, they are. With one little note: they are valid on EJB2 and JEE5, where first one has incredibly bad design, another is bulky and not really convenient. Wait a second... but we are not talking for old projects future, but for new! So, when you going to choose framework for plain new project, the we do have EJB3 and JEE6 today.
  2. RedHat (also known as a leader at Enterprises in Linux world, by the way) and Snorcle (also know as Oracle, also known as benevolent dictator, also known as Sun Microsystems eater) — both of them completely don't really like Spring. In fact, they think it is a bullshit and they think JEE6 would fit to your datacenter much better.
  3. Do you really like that XML thing? I think this is all like back to a stone-age, instead have just everything minimalistic and cute (means: modern).
  4. Template classes as intrusive as it turns your code to a bullshit. Yes, you can have a workaround for this, but the keywords here are still stays to "bad" and "design".
  5. Tell me, you configuring or you coding?.. In Spring you will code^H^H^H^Hconfigure your project in XML. Well, no, you're literally coding. You are freakin' coding in XML, don't get fooled and mislead.

    Let me explain here a bit: a configuration file is something like you can find in Unix /etc directory. It is a small, simple ASCII text file, you can put comments in there and you can parse it with your Perl/Python/Ruby or just AWK/Sed. This is what is called: configuration file and was more than 30 years around. Now what Spring brings you into? A pile of XML, that are actually built into your WAR file. They do believe you have to change XML, so no need to change source code of Java.

    But this is utterly misleading: you intrude to a deployed application anyway (sane companies will put it through a "Change Request" procedure that involves also testing and quality assurance sometimes), while configuring application means you change only that little cute file in /etc directory (or click few checkboxes in admin UI) and thus your buddy sysadmin can do that with a cigarette in his teeth with a little effort (change request still required, but a consequences are significantly smaller).
  6. Spring adds complexity, it does not removes it. Don't be fooled: you will need to have a serious and difficult learning curve as well as you will need to spend weeks to configure your XML (see above).
  7. Bugs in framework itself will cost you a lot. So make sure your framework is extensively supported, reviewed and updated. Who you will trust more: giants like Oracle and RedHat that has tons of very fat customers, or just a little VMWare — yet another player in virtual world with not the best business model? You choose.
  8. OK, you can dismiss my XML rants by changing from XML to annotations. Great point! Because here is another problem: different ways to do the same thing. Java coders chronically away from Unix, but we already been there and we know it is called as "Tim Toady" or TMTOWTDI or "There's More Than One Way To Do It" or, simply Perl. It results to things like this or like this. In contrast, the beauty of Python language lays in its great philosophy: "There should be only one — and preferably only one — obvious way to do it".
    Little note to above: I was not talking about code obfuscation.
  9. We already learned that doing often casting is a bad idea. So that's why we do have Generics for this and why we are trying to go away from casting operations as much as far as possible. However, Spring is pushing you back to a mesozoic era to fight java.lang.ClassCastException dinosaurs each next step. Stupid.
  10. \u3042\u306a\u305f\u306f\u99ac\u9e7f\u3067\u3059 — this is how to say "Good morning" to your boss in Japanese (anata ha baka desu), or exactly what you will get, once you open your ResourceBundle in VIM editor.
  11. It is going up to eleven... You normally should keep SQL separate from the code. Try it with Spring and see how it works (or not) for you.
Of course, the main question still around: Why bother with Spring, if JEE6:
  • Is getting to be more and more lightweight than Spring 3
  • Is less complicated (recently) than Spring 3
  • Is well designed
  • Is well documented
  • Is well supported
  • Is an industry standard and chosen by industry leaders (sure).
  • Has more features
  • Is easier to learn (because it is less complicated)
  • Is not proprietary, versus Spring which is proprietary container.
I certainly don't have an answer on above. Maybe you have?

Feel free to explain. :-)

Tuesday, October 19, 2010

JSR 286 and crying developers

JSR 286 is probably a primary way of how any web-related stuff should be done. Definitely. However, it has some nasty limitations, that would lead novice to hit the wall, step on rake, step on rake again etc. One of such limitations (well, not really, but still) is to return a file. Normally, JSR286 wants you to return HTML. But what if you want to click on some button and get a PDF file or TIFF or DOC or MP3 and so on? Usually, developers are setting content type, putting some content disposition to define filename etc, put some headers to flush cache, write to the output stream, recompile and deploy.

Problem solved.
No, not really: once they call their portlet, entire application disappears and log is filled with devil's 666 lines of Java traceback from Hell. So, random desperate rants over forums begins usually with "me too!" or "pass me some code!" messages.
The real thing is: you need to read JSR286 properly. See, the JSR 168 does not allows us to use something else than just HTML. Pretty much silly. But JSR 286 allows. How? Easy: serve it as a resource. Hence the recipe:
  1. Implement/override method in GenericPortlet:
    serveResource(ResourceRequest request, ResourceResponse response)
  2. In your JSP (or whatever you use) refer to it with Resource URL. In JSP you do it like this (use it on your own way):
    renderResponse.createResourceURL().toString()
  3. In that "serveResource" thing check your request parameters and then return your content into an InputStream.
Keep in mind, that normally you're dealing with ResourceResponse, which is different than HTTP response in a servlet. So after you've put content type in usual way, "setHeader" method is actually not available. But you can always use "setProperty" instead.
Now, if you are smart enough and using Liferay :-) instead of something else, then you simply could use one-liner PortletResponseUtil class, wher you can find a bunch of "sendFile" or "write" methods. They are just for your convenience: get from byte array, InputStream etc. As an example how it works, watch:
PortletResponseUtil.sendFile(response,
"test.pdf",
new FileInputStream(new File("/tmp/test.pdf")),
"application/pdf");
Now use your own imagination how to make it actually right (by replacing FileInputStream with something more valuable, as a starter).
This is it. Enjoy. :-)

Tuesday, October 12, 2010

Thursday, October 07, 2010

Jasper Reports: gone!

OK, this is it. I fed up fighting Jasper Reports and simply ditched it. BIRT (or "dirt" — you call it) although has interesting things, still is even worse than the Jasper Reports. There is also Pentaho Reports available. They are actually nice, but buggy as hell, crashes and has no much features. Embedding is odd.
At first, I don't need that fancy GUI editor. I simply don't. Do you need? No, you don't either. Here is why: it requires programming anyway. So if you think you will get this sexy full-screen editor with mousedraggable objects and will pass you your girls at operations department — you're wrong, wrong and once again wrong. They won't use that. Because if boss will ask you to make red color some figures that are greater than 1000 — what you will do? It is not anymore mousedraggable and clicketyclickdroppable.
At second, I had a trouble with Japanese, but that's font package installation. Why do they do it this way — their problem. I don't like their (Jasper Report's) way to distribute fonts either.
Therefore I decided to make my own parser of my own markup, that is very similar to RML, but is more looks like just a regular HTML. Basically a 50/50 mix of them.
So far, I achieved (in compare to Jasper Reports):
  • Something like 40 times faster PDF compilation. Yes, up to forty times.
  • A very simple way to embed it to your servlet. The keyword here: "very". It is mostly a re-entrant one-liner, something like this:
    new PDFRender(OutputStream, InputStream);
  • Very small footprint.
  • Resulting PDF simply crashes my Preview.app ... BWAHAHAHAHAHAHA!
It renders still bit ugly sometimes and I still working on styles, but I have fully controlled by styles headers, footers, pagination, page layout, text body, paragraphs, True Type fonts, embedded images and a simple grid-like tables.

Soon table spanning and styling is still coming (probably right tomorrow). Later I will add SVG support for native charts (still don't know how what way to do it is the best), barcodes and lovely Japanese QRCode that is required just everywhere through.