Home

Reflections - half a year of Java

So, since re-joining the hordes of hackers-with-a-regular job earlier this year, I haven’t been able to do much with Smalltalk. Where I work, it’s PHP, Java, Javascript, Perl, shell scripting, etcetera. Since summer, it has been almost exclusively Java for me so it is maybe a good time to share my experiences.

First, Smalltalk has me spoiled to a point where I don’t want to use a language that does not come with a decent integrated editor, code browser, debugger, source control environment. PHP has some stuff but we’re still at PHP4 and that is just plain and simply a broken language (PHP5 might be better but I never did an actual project with it so I won’t comment), but Java has some options - NetBeans, Eclipse seem to be the top contenders, and at our company it’s Eclipse.

To a Smalltalker, Eclipse is quite familiar. It is slower, and bigger, and less stable, but still familiar. There are some nice features that help getting around in Java code (like if you highlight a word, a thin bar at the right of the edit window shows tiny indicators indicating the relative positions of other occurrences of the word), and one or two of them I could even imagine flowing back into a Smalltalk IDE. I particularly like the perspectives idea, where the IDE reconfigures itself based on what you happen to be doing - debugging, coding, source code control. I also like the orderly layout - one master window neatly laying out its children for you makes for a lot less window hunting than the average “just pop up a new window” Smalltalk IDE.

Ok, first what I miss - I dearly miss the image and the fact that a Smalltalk system is just always “there”, alive and waiting for your next command. In Eclipse, you will not find “Inspect” or “Debug” menu items in your pop-up, and I don’t think they are likely to ever appear. Although… Eclipse is already closer to a Smalltalk IDE than what I ever thought possible 5 years ago, so I’m not betting on it :-) . But the system not always being alive is the biggest thing I miss - it hurts even more than the whole static typing thing.

Of course, the latest JDK’s have class reloading support and other goodies that make the debugger almost look like any run-of-the-mill Smalltalk debugger. You can actually, in a limited way, change code while debugging, and in the debugger you do have an “Inspect” menu entry in your pop-up, albeit with limitations. However, living inside the debugger is not an option - code reloading does not work in all circumstances, so with larger edits you’re forced out of the debugger and back into editing “dead” code. For a Smalltalker used to living inside the debugger this is a very big step back.

Next, static typing. Eclipse makes use of static typing information in the refactoring browser, which is good - global refactorings can be made with more certainty because the type info assists the IDE in finding all the spots in your code that must be refactored, and excluding all others based on type signatures. In theory, the static type info could also help in entering code, by means of code completion aids, but that functionality in Eclipse is so horribly broken (certainly on Linux, it seems less so on Windows), that on average it could just as well not be there. I did a small C# project this summer, and I think the Eclipse folk should take a very good look at how Microsoft’s code completion tools interact with the user, because these just plain work.

A side note: this C# project was small - I just wrote the unit tests for a web API I was writing in C# so I had sample code to share with Microsoft-based customers and could be sure that my XML marshalling was compatible with at least one non-Java platform. But my very short experience showed that C# got a couple of things right, like automatic boxing and unboxing of primitive types and a better IDE, that overall suggests to me that I would prefer working in C# over Java. Pity it’s still platform-bound to Windows…

Lessee… ah - I mentioned boxing and unboxing. Yup, they made some progress in Java but overall it’s just not there yet. Too often, the language still wants to confront me with the difference between an int and an Integer. It’s stupid, because the only one who could care is the compiler, and the compiler is there for me, not the other way around. Besides, Smalltalk had shown long before Java was ever born that you can get decent performance here so this is just an unexcusably stupid design decision that should be removed (I think only Java’s fascistic emphasis on backwards compatibility comes higher on my list of Java mistakes than its handling of primitive types).

More on typing I simply cannot get used to - the lockdown of class libraries. To be fair, this is mostly self-inflicted pain: I have the whole source code at my disposal, so I could just, like under Smalltalk, include it in my project and start by removing, say, the final keyword on lots of classes in the JDK libraries. And as a matter of fact, when I have some time I am going to try that and see what happens if I subclass String, but somehow I have a feeling that the JVM might trip over this…

Anyway, final classes are the biggest stumbling block - not being able to extend an existing class is one thing, but not even being allowed to subclass an existing class is a misfeature that firmly stands in the way of good design. Let’s put the final keyword on position #3 of my list of Java mistakes.

Good feature: standardization. Java is a marketplace built on standards, and it shows. I can develop using Apache Tomcat, which has extremely good integration with Eclipse and feels quite dynamic when developing, and deploy on Caucho’s Resin which is the appserver our system admins prefer mostly because they know it best (I also must add - it performs impressively). The thing around interfaces is good as well - here I get back at how Jini leverages that whole concept, but I won’t digress too far, suffice it to say that I’m still thinking about how to slip Jini into my employer’s environment ;-) . Some of the standards (EJB) are just plain stupid, some - in my opinion - worthless (JDO), but sticking to some basic standards like Servlets and stuff helps a lot (we prefer to develop webapps that are Servlets on the front-end and talk JDBC at the backend - letting JDO a tool generate SQL is just too tricky for our performance requirements).

Soso: generics/templates or whatever they call the angle bracket construct under Java. It works in a lot of places, and together with the iterator language construct they added for the for statement, it does take away a lot of clutter. Of course, when it doesn’t work, you find yourself automatically in a worst case scenario and there it horribly adds to the clutter. The fact that these bits of code tend to be the more tricky bits doesn’t help either - you end up with a lot of clean code, but the price you pay is extra line noise in exactly those places where you dearly want clean code: the tricky bits.

Overall: I am less productive in Java than I would be in Smalltalk, but not by as wide a margin as I would expect. I do notice I am different from my (mostly junior) colleagues - unit testing, continuous integration, refactoring are all terms they heard about, but they don’t have this built-in urge to actually do it. Smalltalk is probably the best teacher in this respect, and it is nice to see that these skills are at least mostly transportable to more mainstream environments.

Still, I’m less productive, and I write code that I think is not as maintainable as my Smalltalk code because Java precludes some design options that force me to go to more complex alternative solutions. And that seems to be the bottom line, developer productivity and maintenance costs. Java still fares worse than Smalltalk here, and it has a very long way to go (including having to break with the past) if it ever wants to get “up there”.


Stumble it!  Post to del.icio.us 

23 Responses to “Reflections - half a year of Java”

  1. murphee (Werner Schuster) Says:

    About Code Completion:
    Why do you claim it’s broken in Eclipse?
    I’m using it constantly (for methods, templates, etc) and I don’t see anything wrong with it - or do you experience GUI related problems?

    BTW: have you discovered the QuickFix/QuickAssist features yet?
    Wherever you are, you can hit Ctrl-1 (or use Menu Edit->QuickFix) and you’ll get proposals for little, mostly inline refactorings.
    Even better: whenever Eclipse shows an error in the source, put the text cursor on it and hit Ctrl-1: nearly always will it give you a proposal that will fix the problem. Eg. add a ‘implements Foo’ to your class definition and save - you should get an error, since the class is missing some methods from that interface - simply put the text cursor on the class name, hit Ctrl-1, and Eclipse will offer to add the unimplemented methods (well, their stubs).
    Even better: this will hide a lot of functionality behind one single keyboard shortcut that will offer context sensitive solutions to the specific problems.

  2. dell Says:

    Do yourself a favor and try using IntelliJ. Eclipse has always felt like a tool built by committee, and a soviet-era eastern bloc committee at that. IntelliJ was built by people who have writen a lot a of code and really know what a great software development tool requires. The two are like night and day. I’ve been using it for nearly four years and hate to write java with anything else. You should give it a try, but only if you’re willing to advocate purchasing it at your company, because Eclipse will be painful to use after a week of IntelliJ.

  3. Just grin and bear it… - Smalltalk: The original IDE as a silver bullet language. Says:

    […] I’m not quite as up to speed on smalltalk as I’d like to be, but this guy seems to know a thing or two about it. He reports on being forced into using java at work for 6 months. Fortunately, he went straight for an IDE (SmallTalk is -heavily- IDE based. It had refactor-like tools and live debugging in an editor environment as early as 1976!), specifically, eclipse. […]

  4. Tony Morris Says:

    Non-final classes are the mistake, but then, so is Smalltalk.
    Ever tried a functional language?

  5. James Says:

    I think you’d dig python and pymacs. Or even Erlang with it’s integrated modes in Emacs. ALSO, lisp with slime for emacs.

    Basically, emacs is awesome. :)

  6. lowdown Says:

    Hrm.. IntelliJ is sweet - that is what I’d use for making Java programs if I did so.

  7. Troy Brumley Says:

    Cees, I feel your pain with regard to refactoring. I normally use VS.NET 2003, VS 2005 is a big improvement. I also agree with your “not as unproductive as I expected” comment. I’d say the the real annoyance is the productivity to lines of code ratio.

  8. Greg Trasuk Says:

    I know where you’re coming from. I do most of my work in Java, mostly with Jini. I use Jython for the higher-level stuff in Java applications. I’m not a huge fan of Eclipse; for some reason I like Netbeans more, although it’s not a strong preference. But having said that, Squeak keeps calling to me. That’s what I start up when I want to play, and that’s what I’m teaching my kids.

  9. cdegroot Says:

    Okay… geezz, more people are reading this blog than I thought… ;-)

    @Werner: yes, I know about the quickfix stuff. Code assist is broken in the GUI interaction - either it doesn’t pop up, or it pops up and adds a function with formal parameters which are then not overwritten, etcetera. It finds the stuff, but how it inserts it is - especially under Linux, it seems - quite buggy.

    @dell: yes, I probably should.

    @Tony: yup, but never for a complete project. I’ll refrain here from a longish explanation on my feeling on “human” (smalltalk) versus “mathematical” (functional) languages, but there seems to be a reason that the former group - including Python, Ruby, etcetera - is far more widely accepted. I do think languages like Haskell and OCaml have some interesting features, though, especially in the area of type inference there is a lot the “mainstream” (and Smalltalk) should learn from them. I think to put Smalltalk down as a “mistake” is a bit too strong in any case. I’m not even putting down C++ as a mistake - it’s just a tool, often the application of the tool is where the mistake sits :)

    @James: I used to live inside Emacs (remember JDE, anyone?), but it never “clicked”. I did a lot of Python work, including open source work (Linux’ SGML tools), and yes I do like the language. I would like it even more, though, with a decent IDE :-)

    @Greg: isn’t Jython still suffering from the performance impairment caused by the fact that the JVM cannot dispatch dynamic functions? See Avi’s blog on Ruby for details. I used JPython back in ‘98 or so, and was quite happy with it except for performance.

  10. cdegroot Says:

    As Reinier Zwitserloot thinks that my 6 month mark marks my complete Java experience, and others may get the same impression, just to be sure here’s what I answered on his blog:

    Err… I started with Java when half the documentation was still referring to “OAK”, was the first guy ever to write a type IV JDBC driver, have been a CTO of a Java startup and was a member of the Blackdown Java porting team. So I think my Java credentials are enough to be entitled to an opinion about the language :)

    Hmm… and I forgot the bit about the Jini Technology Oversight Committee membership… must be getting old…

    Anyway, this is not to boast or something - there’s nothing to boast about a lot of time spent with Java - but just to hopefully help drive home the fact that I am actually quite experienced with Java, know the language literally inside out, and think I am therefore in a position to give a reasonable judgement.

    (dell - downloaded IntelliJ in the meantime, it won’t start up - presents me with an empty window. Bad out-of-the-box experience…)

  11. Greg Trasuk Says:

    Re: Jython performance…

    I use it for two things; running the user interface behind Swing apps (i.e. responding to events and delegating the real work to other objects), and for creating Jini services that act as a facade for other objects written in Java, or for running database queries, etc. So in most cases, the heavy lifting is not done in Jython. I haven’t seen any performance issues, although I probably wouldn’t use it for numerical analysis, etc. My suspicion is that the JVM’s optimizer does a fair job optimizing out the boilerplate interpretation code.

    It does suffer from a lack of ongoing development, although that seems to be changing a little. I also have high hopes for the PyPy project.

  12. Lenny Says:

    Having done a thesis using Smalltalk on a Mac2 back in the day (1990), cdegroot which Smalltalk flavor/IDE/environment are you used to using? My most recent experience is with Squeak, but just to fire it up, say, “Yep, that’s Smalltalk,” and shut it down again — work got in the way. Thanks! (found this on reddit)

  13. Steve Says:

    Firstly, JDO is far from worthless, and letting it generate SQL is extremely effective in most cases, giving amazing portability and development speed. But anyway, it is not a case of either JDO or SQL - you are free to use SQL where you need to.

    The big thing about JDO is that it is not just for relational systems. I would have thought that idea of a truly portable and store-independent object persistence API would appeal to a Smalltalker - the higher the abstraction, the more productive the developer; only dropping down to lower levels (raw SQL) when really necessary.

    Secondly, Java’s backward compatibility has been one of the reasons for its success. It is not facistic - it helps explain why Java is the No. 1 language, at least for now. Having had to deal with lack of this in other languages (mainly C++ and Smalltalk dialects) I find the security of this extremely appealing.

    And as for Smalltalk showing how you could get performance with out primitive types long before Java was born; well, I really have to challenge you on that. I am a great fan of Smalltalk, but I battled issues of performance with many Smalltalk dialects from the mid 80s until I switched to Java at the end of the 90s.

  14. Jan M. Says:

    Your remarks abour eclipse are quite interesting. I thought (in my rather short experience) that squeak is quite horrible to program in. I have done my share of lanugages and have to admit that producitivity is the last word that comes to my mind when remembering squeak.

  15. The grinding of functional axes : Pensieri di un lunatico minore Says:

    […] It started simply enough, with a growing discussion of alternative languages—fueled, I believe, by the rise and acceptance of so-called scripting languages—but the near deafening shrill chorus of functional programming people who have taken a good idea and driven it to absurdity is getting to me. The latest mindless addition to the cacaphony is this comment on Cees’ great post on Java productivity: […]

  16. Ramon Leon Says:

    Jan M, if you think Squeak is horrible to program in, then might I suggest you never really got to know Squeak. Squeak is IMHO the best programming environment I’ve ever seen, you really should give it another go.

  17. cdegroot Says:

    @Lenny “cdegroot which Smalltalk flavor/IDE/environment are you used to using?” - I’ve used Squeak, VisualWorks and VisualAge for paid projects. The VisualAge version was old so I won’t comment on it, Squeak and VisualWorks each have their strengths and weaknesses.

    @Steve - I have nothing but bad experiences with O/R mapping. Nice to get started, but sooner or later performance requirements will make you regret it - the O/R schasm will come and haunt you with suboptimally generated SQL, SQL spit out at the wrong moment, etcetera. After the umptieth failed attempt at trying to do a high performance system with O/R mapping, I have decided to give up and trade development speed for control, working with manually coded SQL. On the other hand, I do think that object databases are a very good solution, but somehow they don’t seem to get traction.

    Regarding Smalltalk performance - the end of the 90’s also saw some great improvement in machine speed. I dare you to run Java on an ’80s machine :-) . But particularly to the topic of hiding primitive types, I think the various Smalltalk VM’s had fairly good solutions that weren’t performance showstoppers as much as the JVM designers once made it look like when defending this particular design decision.

    @Ramon, Jan - Smalltalk programming is a different thing from programming in most other languages. It really, really helps to have a tutor handy. If you try to “get it” by yourself, prepare to spend a lot of time and read a lot of books (I can recommend some if you want to).

  18. Ignorant Bystander Says:

    “prepare to spend a lot of time and read a lot of books (I can recommend some if you want to)”

    Please do!

  19. jRave Says:

    I would like to pair with “Ignorant bystander” and humbly request your recommended list (maybe it wouldn’t be bad to post it here too, so all future visitors could benefit). I’m slowly becoming fluent in smalltalk, but I’ve got still a lot to grasp to truly get on “the smalltalk way” ;-) )).

    To all “infidels” :
    Since sliced bread is an atrocity to me, I wouldn’t compare Squeak/Smalltalk to it, but it’s the first environment/language under which I am comfortably and without unnecessary fuss able to “use the source”, ie. get from a point that a bug in code I didn’t write pops out to the point that the bug is (and mostly in no time, really) fixed. The most wonderful aspect is that I can patch bad/obsolete code _while_ I’m importing it into the system. It just feels natural.

    I agree, it may look like shit (this can also be fixed in no time ;-) ), and it really is “And now for something completely different”, so the first time I tried it i ditched it after a few hours. But as I constantly (as a ruby programmer) kept hearing about how great (and superior) smalltalk is, I reviewed it from a different point of view (ie. “I keep hearing about it as superior, so there must be something to it. I doesn’t make any sense when I look at it, but what “others, who already got it” see in it ?), and i was hooked.

    I won’t try to list all the advantages (already listed elsewhere, and you probably wouldn’t get it (or it wouldn’t seem as appealing), as I wouldn’t, until I found out on my own), but here’s a simple (catch-)story .

    Case 1:
    I installed keybinder (what it is is not important), and it kept popping up an menu whenever i moved mouse over it’s icon. The moment i turned this feature off, I realized that I don’t know what shortcut will bring it up, and that there is no way to get it using other conventional means (ie. clicking, context-sensitive menus, etc.)

    Normally, you would be screwed, not so in smalltalk. I popped a browser on the morphs (thats how you say a control/widget in squeak ;-) , skimmed through the (source) code and found that there is a method with mouseover in name. It modified an instance variable (menuOnMouseOver or something like that), so I popped up an inspector on the morph instance and modified it (the iVar) from false to true. And voila, the menu was back. Try this in windoze/whatever ;-) )

    I don’t “get” smalltalk good enough to be able to explain all the really good stuff (the story is child’s play compared to what it enables you to do), but I can already see some of it.

    Now I am dreaming of (no, not white christmas ;-) smalltalk-based OS (talk about power to the user), so that the “everything is smalltalk” concept (the best thing of em all, to be able to redefine/reprogram/debug everything INCLUDING the language itself - plus the VM - from/in the language/environment itself - uniformity I had not seen anywhere else) encompasses your/my whole computer.

    So at least give it a try and - for gods _and_ yours sake - try to overlook such childish aspects as what the Squeak gui looks like, there’s more to it (Squeak/Smalltalk) then looks.

    Cheers, jRave.

  20. John Says:

    Nice work. Thanks. John

  21. guanhua Says:

    On personal opinion, I find this very helpful.
    Guys, I have also posted some more relevant info further on this, not sure if you find it useful: http://www.bidmaxhost.com/forum/

  22. Strafverteidiger München Says:

    Nice work. Thanks a lot for it.

  23. maniero Says:

    Good work. Thnak you so much.

Leave a Reply

(note: comments may be moderated so don't always appear right away)


Copyright (C)2000-2005 Cees de Groot -- All rights reserved.