May 21, 2012

Posts Comments

You are here: Home / Languages / Java

Speedy Django Development

July 7, 2006 By Bruce Kroeze 3 Comments

guitar Speedy Django DevelopmentAs I’ve mentioned before, I am building my own web store using Django. The coding is going extremely quickly, thanks to the excellence of the framework.

I find myself marvelling at how quickly and simply various elements come together, especially when I contrast this to my previous experience doing the same thing with Java for an employer.

For example, the Login/User framework. With Django, I simply include the auth middleware, and create a couple templates to “skin” the login, profile, password change, and password reset pages. In return, I get a full-featured, working login system with sessions, cookies, and all that tedious plumbing done for me. Total time from decision to use the built-in framework to implementation? Two hours, including learning the system. Unbelievable.

Contrast that with my use of Acegi/Spring to handle authentication in a Java app. I was shockingly fast implementing this, taking just two full working days. The documentation directly states that you should plan on at the very least one full week. The system was huge, slow, and baroque. Modifying the system was clumsy and frequently required I relearn things from the reams of documentation. Yes, overall it offered more functionality. No, there was no stripped-path to just get the most needed set of features for a website. The craziest thing is that the config files for Acegi
alone were larger than all the code and templates I wrote for django login.

Another example is my need to generate thumbnails for some graphics. I want to generate them “on the fly”, when needed. Total lines of code to do this in Python with PIL, integrated with Django? 7. Total time? 15 minutes, including all the logic needed to make sure that I only create the thumbnail once.

Contrast this with the nightmare that is the Java image API. I seriously spent days making a caching thumbnailing system in Java for an Auction site I worked on. Even after that, it was much slower than my Python solution.

Now that I am actually developing a serious app for Django, I find myself feeling the love more and more. Thanks Django team!
[tags]django,python,spring,acegi,pil[/tags]

Filed Under: Django, Java, Languages, Python

XML Is Java's Scripting Language

March 13, 2006 By Bruce Kroeze

troll XML Is Java's Scripting LanguageGreat article at Lesscode.org, responding to Gosling’s dismissal of scripting languages.

Usually, I ignore attacks like Gosling’s as not worth my limited time and attention. I love Python, and it really doesn’t bother me when the ignorant attack my language-of-choice. This article is better than the original by orders of magnitude, due to its heavy linking and its excellent reader commentary.

My favorite quote from the article is: "this is why XML is used so heavily in Java for things like O/R mapping, dependency injection, configuration, build processes, etc. — XML is Java’s scripting language". It is actually from a reader comment, which is worth quoting in full.

But Ruby, Python, Perl, Smalltalk, etc. are not specialized scripting languages. They are general purpose programming languages. I believe one of the reasons the term “scripting language” has stuck with them is partially because it’s become so common to create mini-languages (i.e. DSLs) in dynamic languages that are specialized for certain tasks. So it’s sometimes hard to separate the specialized pieces from the general purpose pieces. Contrast that with static languages, where you are forced to create a completely separate “scripting language” when you need to provide a constrained/specialized language (this is why XML is used so heavily in Java for things like O/R mapping, dependency injection, configuration, build processes, etc. — XML is Java’s scripting language). In dynamic languages, you are generally not required to leave the core language to get that specialization: you use techniques like meta-programming and DSLs or just include/require/use some designated file at a designated point and let it do it’s thing with the API.

Filed Under: Java, Python, Rants

Bitter Java

February 13, 2006 By Bruce Kroeze 3 Comments

coffee Bitter JavaI’ve been saying for years “The only time I program in Java is when someone pays me.” I was half joking, just stupid office banter, but I’m getting more and more sure about that opinion. Rant mode – engage.

I spent the entire day today chasing down Java configuration errors when upgrading Resin 2 to Resin 3. It is a moderately complex application I’m upgrading. Built on Java 1.4, Spring, Hibernate, and JSTL, it really shouldn’t be that hard to upgrade. After hours of careful debugging, I found that it is a bad combination of JSTL and newly strict adherence to the JSTL spec that is causing most of my upgrade woes.

Basically, Resin will no longer allow me to access a public static method of a class using Javabeans syntax conventions. Why? Because it is static. Not because it isn’t useful, but for the sake of strict interpretation of “the rules”. I seriously hate that attitude, which is very prevalent in the Java world. So, I need to rewrite many of my classes to make non-static class methods to access the same information I used to be able to get at directly. It leaves a bitter taste in my mouth.

Don’t trust the programmer

But that sort of “don’t trust the programmer” attitude is depressingly common in Java. Most everything is “strictly typed”, sure, but to work with a collection you always have to cast the object back to the proper type. Isn’t that “secret scary knowledge the programmer shouldn’t have to know”? I submit that it is. Doesn’t that break the supposedly big advantage of finding errors at compile time? Yes, it does. Can a good programmer get every bit of the same advantage and early error-validation by doing proper unit checks? Of course he can. So why do it like that, why be so wordy and needlessly strict? Because that’s Java’s corporate, designed by committee, not for love, spirit.

XML Sit-ups

There are a lot of people debating the merits of the so-called “XML sit-ups” that many frameworks require. Java invented the XML sit-up. Spring is a gorgeous framework. It almost rescues Java in my eyes, but looking at the horrible horrible config files it requires almost brings junior programmers to tears. Seriously, take a look at the Spring Acegi security framework configuration files. I think that may be one of the most complex, interleaved, multi-layered config files I’ve ever seen. I strongly believe that that particular XML serves absolutely no purpose, and would actually be clearer, cleaner, and more testable if it was instead expressed in code.

It saddens me to see Zope 3 heading down that same XML path. It is a myth that anyone other than a programmer will ever really be editing the config files. Why add needless cruft, delays and obfuscation? I don’t buy the “then it can be validated using XML validators” argument for one second. That’s like smashing an ant with a hammer.

Ugly Ugly JSTL

JSTL is another bitter pill. It is just unforgivably wordy. It is so amazingly wordy, and yet it fails to even remain valid XML. What the hell? I can forgive Zope Page Templates which are very wordy and involved, yet manage to remain valid XML the whole time. I still don’t really like them, but at least I can understand why some people do. JSP/JSTL on the other hand is so crufty, so layered and whacky, so inelegant, that it feels like the wrong solution every time. The programming community should simply throw it out and take a look at a decent, mature, truly object oriented solution like Cheetah for a well designed, terse and effective templating system. Why continue adding to the ugly pain that is JSP/JSTL? I have to think it is simple NIH syndrome at this point.

Conclusion, anyone having fun?

What I honestly find myself wondering is whether anyone actually programs in Java for fun. Or do they all do as I do, program in Java on the day job, come home, strip off the straightjacket, and dive into Python, Ruby or PHP? I hope so, for their sake. Java is a language with a broken spirit, and without exposure to other languages, I fear that Java developers will have their spirits crippled as surely as if they were VB developers.
[tags]Java,Spring,Hibernate,JSTL,Zope,ZPT,Acegi[/tags]

Filed Under: Java, Rants