Interview with Rod Johnson

Rod Johnson talks about lightweight containers, IoC (dependency injection), Spring, AOP, EJB and Java 1.5. The interview was recorded at this year’s TSS symposium. I’ve just gotten Rod’s new book (see also the review blogged yesterday) and this interview has gotten me all excited to dive in.

Book Review of J2EE without EJB

First review of Rod Johnson’s new book J2EE Development without EJB by Dion Almaer on the ServerSide. As I’ve just had email from Amazon.co.uk that my copy was dispatched last week, I’ll reserve judgment for now. However, I’m hoping for some useful insights that will help in the redevelopment of my “Client Server Programming in Java” course. Pity it arrives too late to go into the booklist!

Bruce Eckel’s MindView, Inc: 7-9-04 Java Issues & Directions

Bruce gave a talk at UC Berkley and 9 July 2004. This is his blog entry 7-9-04 Java Issues & Directions which popped under my radar cover via the Dion on Tech who blogged a ServerSide new forum announcement (which has comments). The blog links to a 2 hour 16 minute streamed video.

“Be warned, those of you who feel Java is the best language, forever and without bounds, and that it has no limitations: herein I critize Java, but in the spirit of understanding the limitations of the language. I strongly believe that understanding these limits makes you a more effective programmer.”

Here’s my summary of the key points that I made as I watched the talk for the first time. [Times are for points at which the points are made in the talk] Some key points worth following up on:

  • Macromedia Flex and MXML for rich client application development. Great technology which could really have an impact in the market that Applets have failed to capture provided it’s not released as an enterprise development environment with enterprise pricing!

  • Eclipse 3.0 as a Rich Client Platform

  • Java’s success in the server market: but all the problems and confusion with EJB makes its continued success uncertain. New approaches: lightweight containers, AOP, dependency injection, etc.

  • New features of Java 1.5

  • Generics and Autoboxing: Generics is really a way of making collection classes typesafe. Objects accepted are predefined and you don’t need to upcast and downcast. Autoboxingis the automaticconversion of primitive and wrapper object. Again designed to make it easier to use collection classes. Because of they way these have been implemented, they don’t work in some cases that you’d expect if you’d come from a C++ (Generics) or Smalltalk (Autoboxing) background. Worth noting is that in untyped languages like Python this is not even an issue! It just works without any syntax support!

  • Enumerations [1h16m38s]: Seems like a successful addition. And like you’ expect from the author of Thinking in Java, Bruce has some wacky ways to push the envelope much further than you ever would want to!

  • Attributes/Metadata (inspired by C#) [1h23m19]: Added, in Bruce’s opinion, because C# had them, metadata will be a big feature of EJB 3.0 and will eliminate the need to declare all those interfaces that you need to implement an Enterprise Java Bean, and possibly some of the deployment descriptor files. Similar in intent to the XDoclet tags, but handled now by the compiler. Bruce’s example was of pickling classes.

  • New Concurrency [1h32m0s]: Fixes some problems. Uses Doug Lea’s libraries. Better model but still something you haveto think about. Example is a Car washing program that puts wax on and takes wax off. New concurrency library has a new factory method that can pool threads and returns executor objects to execute a callable. This executor object cab be sent an interruptAll method to gracefully shutdown threads.

  • JUnit and Testing [1h41m30s]: not a new language feature, but a topic that Bruce got a lot of flack about when he published this article on his blog. He wants to make it easier to write tests. So do I so I’ll be interested to see what he comes up with (idea for mini project: see if Leo makes Bruce’s approach easier. Also doctest in python is really interesting.

  • Other syntax improvements

  • The D language

Great stuff!

New Leo RST Plugin Announced

I have today announced the availability of a revised RST plugin that does most of the proposed functionality discussed here and announced in this Blog last Thursday. This is my first chance to give something nack to the open source community! It’s purely selfish of course! I need this functionality and I’ve just scratched my own itch!

Proposal for a Merged Leo RST Plugin

Posted today to the Leo Developer’s forum.

Context

I have used the RST2 plugin for a couple of days translating a lab sheet for a programming exercise and think I have gotten a feel for how it works, and perhaps how it should work.

Tracking back through the forums it seems clear that the original rst plugin (developed by Josef Dalcolmo) was intended only to produce reST documents. All the nodes of an @rst tree would become an reST document with the headlines becoming different levels of heading.

The idea was extended by Stephen Zatz who developed a version that could produce code documentation. He added support for embedded @file-noindent nodes, introduced the @rst node for documentation (which have to contain the @ignore directive) and extracted any leo code nodes into reST preformatted code blocks with syntax colouring. This is the rst2 plugin which is enabled in preference to rst plugin in current versions of Leo 4.2. I think Edward tidied up the code and wrote the documentation that appears on the Leo website.

Unfortunately there are incompatibilities between rst and rst2 and inconsistencies between rst2 and leo that means

  1. rst2 can’t be used in the way originally planned,
    ie to simply creation of reST documents.

  2. rst2 is too difficult to use for it’s stated purpose

  3. because of the need to create an @rst node for
    reST documentation nodes,

  4. the need to put the @ignored directive in all @rst
    nodes which itslef requires that @file-nosent nodes
    have to
    be used rather than @file or even the new @file-thin
    nodes

  5. which itself implies that neither reST documentation, nor
    normal leo code documentation can appear in body text.

Proposal

Having played with the system I think that the incompatibilites can be removed if the usual leo interpretation of @file nodes are used instead of having a distinction between @rst and code nodes.

This is what I mean. reStructuredText (reST) is a text-only form of documentation that uses layout conventions, familiar to email users, to give the impression of typeset documentation without the need for tags. There has long been a clamour in the leo community (although not for a while now) for some form of rich text in documentation nodes. Let us propose that (at least for documentation nodes in @rst trees) reST becomes our rich text documentation format. [It will do no harm if it occasionally slips into documentation nodes, and hence into tangled code, because it’s designed to work in text-only views!]

Thus, instead of having a separate @rst node, I propose that the rst plugin simple assumes that within an @rst filename tree, text introduced with the @ directive is valid reST text and the normal leo rules for @file nodes otherwise apply. That is

  • body text is code by default

  • body text is documentation if introduced by the @ directive

  • body text can be a mixture of code and documentation when the
    @ and @c directives are use.

Here are the advantages as I see them

  1. The new plugin will immediately allow @rst to be used for
    it’s original purpose. In effect, all body text in an @rst
    could be assumed to be documentation.

  2. When a @file tree appears in an @rst tree, the rst plugin
    assumes that it is now a code documentation tool. We simply
    pass
    documentation text to reST and wrap code in code blocks
    (as now). Presumably the @language directive could guide the
    syntax colouring feature.

  3. @file trees within a documented @rst tree would be
    transparent. They could be cloned and reused in other non-rst
    contexts without change.

  4. All the advantages of reST as a “rich-text” documentation
    format immediately, and transparently, become available to leo.
    Improving the readability of leo documentation nodes and the
    readability of embedded documentation in files with sentinals.

The only disadvantage (perhaps not trivial) is that new-style
Leo+reST code documentation would be incompatible with existing documentation written for rst2. The @rst documentation node would perhaps have to be maintained for backwards compatibility. But I have the feeling that rst plugin working has described above is actually quite natural and is certainly more “leo-nic”.

The price is increased complexity in the rst plugin code which now
has to look inside code nodes to distinguish documentation and code sections, but presumably that code is available within the leo APIs.

Refinements

The above proposal provides a merger of current rst and rst2 functionality. aving tried reST+Leo for code documentation there are a couple of additions that I would propose.

  • Rst2 deletes @others when it appears in code. I would prefer
    it to put in a place holder. Perhaps […]. This indicates
    to the reader that the following code sections fill in the
    ommited details.

  • Use of line numbering, the labelling (or not) of
    code sections in the generated reST documentation,
    and syntax colouring should perhaps be configuration options.

  • It would be nice if > could become hyperlinks.
    Thus::

    def aFunction():
    <>
    :
    <>
    return “Hello There”

    would be “typeset”::

    def aFunction():
    <<aFunction body>>_
    :
    .. _<<aFunction body>>
    return “Hello There”

Comments Welcome

I’d appreciate any comments that you have on this proposal, particularly from the authors of the rst/rst2 plugins.

As to implementation, I’m willing to have a go, but only if no-one more competent wants to take on the challenge.

Warp

Warp is a new literate programming tool created by Harold Thimbleby of UCL to help accurately write about programs. The approach is described more fully in Explaining code for publication. The idea, in a nutshell, is to mark-up source code with commented XML tags so that code can then be extracted by the warp tool into a file that can be included in a word document or LaTeX file or even (using JavaScript) an HTML file.

The extracted code (which can be as much as a whole compilation unit or merely a fragment) is guaranteed to match the source code. The source code can be edited using conventional tools — no need for a literate programming markup a la WEB, or outlining editor like LEO. The documentation can be prepared using conventional word processing tools like word, LaTeX or even reStructuredText — the only requirement is the ability to include another file.

A possible downside is that code and documentation are kept separate (but who really keeps them together?) which increases the “cognitive distance” between the explanation and the code to be explained.

A couple of positive advantages are that

  • warp is a Java program so it’d be easy to add to a Java project’s build process.

  • It’s open source, so useful extensions, e.g. a reStructuredText filter, should be possible

  • It uses XML so many other filtering tasks are possible with XSLT and scripting

I have an immediate requirement for a version of warp that could support the docutils format. I’ll let you know if that’s an itch that can be scratched.

Programming in Java

Online, and seemingly publicly accessible, course on Java (for people with prior programming experience) with some very rich multimedia resources including streaming videos of lectures.

Annoyances

Today was an open day at UWS. Every department and school was expected to lay something on for potential students. Every admissions tutor (who usually gets lumbered with this sort of thing) is expected to take time off to be pleasant and show the little kiddies around. Except that all the labs that I would have shown were locked because no one had told the technicians that they should be opened! I’m afraid that I blew a gasket and got out of there. So if there was a tour of EEE and ICCT facilities, I didn’t give it. I feel quite guilty about letting folks down … but I’m also angry that here’s yet another example to support my growing perception of the decline of Electrical Engineering at Swansea and my need to get out of here!

Furthermore, the Exchange web server is down so I can’t read my email from home. Given that my connection to exchange via Outlook at work is also next to useless, I’m incommunicado for a while!