La Tortue Cynique / The Cynical Turtle

WebLogic Workshop vs IBM WSAD: what Crossvale doesn't say

Via Dion.

Crossvale has produced a report comparing the productivity between WebLogic Workshop (WLW) and IBM WebSphere Studio Application Developer (WSAD). They explain a lot what they do, and why they do it this way, while developping and enterprise grade application. To my taste, they fail to mention strongly certain points.

Why so little line of codes with WLW?

WLW uses BEA's Javelin, which combines a source code parser, an attribute based code generator (XDoclet based) and a compiler. They choose for WSAD to not use an attribute based code generator, because they insist on using stock products.

What can I do with my application developped with WLW 8?

Run it on WebLogic Server, end point. Even if BEA provides a Page Flow Portability Kit, there is no such thing for the Controls. The application developped in WSAD needs minor tweaks on EJBs to be ported to another J2EE server, as usual, but nothing prevents you to do that.

Why explain in such great length that they don't use Entity Beans with WSAD?

To mask the fact that they don't know what a DataBase Control is and how it is going to be deployed?

All in all, is it a choice of IDE?

Not really, WLW is tied to WebLogic Server, and it's almost given for free nowadays. The choice is in the application server, and make you swallow the price tag with nice IDEs, and justify (in the case of BEA) a vendor lock-in.

Why just count first developement time and no maintenance task?

Perhaps to mask the fact that WLW java editor is really poor, and doesn't even include refactoring tasks.

What is really compared eventually?

Developement of a J2EE application with a framework integrated into a lightweight (in functionnalities) Java IDE versus a heavyweight Java IDE without any special framework. What to conclude? Use an integrated framework. Is it a surprise? It should not.

(Cyberpunk, 2004/03/26 07:44) lien permanent

Enervement

La gestion des styles dans Word 2002 est tout simplement catastrophique. La mise à jour facile d'un style à partir d'un mot est tout simplement impossible à achever, le partage de styles entre documents est foireux, et la définition automatique de pseudo styles est stupide. C'est la porte ouverte aux documents complètement incohérents. Comme d'habitude dans ces cas là, on ne choisit pas ses outils.(Cyberpunk, 2004/03/25 06:35) lien permanent

I'm fed up with this MVC abuse

<pedantic:rant> This morning in the javablogs daily mail, I see Solving Swing's MVC Deficiencies by Ryan. I start to read and... geez, solving Swing's MVC deficiencies requires a unique controller? I mean, either there is a misunderstanding about MVC, or with its Swing implementation, but the problem Ryan deals with, which is a valid problem, is not a Swing's MVC deficiency. But there is worse, let's take for instance php.MVC, whose misleading name implies that it's an MVC implementation, whereas it's a Struts copy in PHP. Even it has been done over and over, let's set down some facts.

1. MVC has been conceived in 1978 by Trygve Reenskaug while working at Xerox PARC.
2. The reference implementation of MVC is in Smalltalk-80.
3. MVC is a paradigm, not a design pattern.
4. MVC is fine grained.
5. Corollary: there is no such a thing as MVC for the web. There are valid "Separation of Concerns" oriented frameworks, like Tapestry, WebWork or Struts, but none has the adequate "model notifies the view" mechanism for instance.
6. MVC requires a hierarchy of views.
7. MVC attaches one controller per view (and thus builds a hierarchy of controllers).

So please, pay more attention to the venerable MVC. Like for all other controversial architectural debate, there is a page about MVC on the Portland Pattern Repository's Wiki. </pedantic:rant>(Cyberpunk, 2004/03/23 05:05) lien permanent

Welcome to the mess

In JSP 2.0 Thoughts: What a mess, Russell points what JSP has become with the last evolution. I disagree on one point: "When Sun jumped to JSP 2.0, they missed a chance to break backwards compatiblity and improve the page language". They can't improve the page language, it's Java (pathetic pedantic argument)! Everything else is a kludge. Back in JSP 1.0, there was an attribute in the page directive: language. I cite the specification here:

• language

  The scripting language used in scriptlets, declarations, and expressions in the JSP file and any included files. In JSP 1.0, the only allowed value is java.

And here is the version 2.0:

• language

  Defines the scripting language to be used in the scriptlets, expression scriptlets, and declarations within the body of the translation unit (the JSP page and any files included using the include directive below).

  In JSP 2.0, the only defined and required scripting language value for this attribute is java.
  This specification only describes the semantics of scripts for when the value of the language attribute is java.
  When java is the value of the scripting language, the Java Programming Language source code fragments used within the translation unit are required to conform to the Java Programming Language Specification in the way indicated in Chapter JSP.9.
  All scripting languages must provide some implicit objects that a JSP page author can use in declarations, scriptlets, and expressions. The specific objects that can be used are defined in Section JSP.1.8.3, “Implicit Objects”.”
  All scripting languages must support the Java Runtime Environment (JRE). All scripting languages must expose the Java technology object model to the script environment, especially implicit variables, JavaBeans component properties, and public methods.
  Future versions of the JSP specification may define additional values for the language attribute and all such values are reserved.
  It is a fatal translation error for a directive with a non-java language attribute to appear after the first scripting element has been encountered.
  Default is java.

Such an evolution. The new specification still blocks PHP5 which doesn't support the JRE (or I don't understand "to support" the right way), but allows Groovy or Jython for instance. So, the Expression Language has not been designated as a valid language for scriptlets, they've just added another pile of monstruosity on this thing. Putting JSP on a resume doesn't mean much now.(Cyberpunk, 2004/03/21 16:12) lien permanent

Re: C++ wrapper generator for Java classes?

Some time ago I was asking if anyone knew about some tools to do the plumbing with JNI. JNI code is remarkably error prone and some help is always desirable. Eventually someone mailed me to point Jace. From the documentation, It looks very interesting, a bit more heavy than what I planned to do (and never done of course). You can see a heated discussion between Jace author and concurrent solutions on Javalobby and an article on JavaWorld from the author.(Cyberpunk, 2004/03/04 20:24) lien permanent

Il s'annonce bien celui-là

J'avoue avoir été déçu par les derniers PDA de Sony, et spécialement par le PEG-UX50 : un écran trop petit ( une résolution de 320x480 (soit 100% de pixels en plus qu'un Pocket PC) avec un écran plus petit dans la largeur que le Sony PEG-T625C ou le Palm Tungsten T, qui sont tous deux des 320x320), une interface pas aboutie avec l'impossibilité de passer en mode portrait. De plus, la simplicité de navigation caractéristique des Palm avait disparu. Mais là, le PEG-TH55 s'annonce bien né, qui plus est à un prix relativement raisonnable pour les fonctionnalités.(Cyberpunk, 2004/03/03 21:39) lien permanent

Et il enfenta d'un monstre

Une attraction certaine pour le facteur de forme mini-itx, une attraction passée mais qui fut certaine aussi pour les briques danoises (royaume de la briquette faut-il rappeler), tout ça pour ça. Le design est proprement ignoble, on s'aperçoit bien vite que les ressources d'antan ne suffisent pas à abriter le mammouth (ni disque dur de portable, ni lecteur DVD slim, que du gros), et qu'il faut recourir aux plus belles couleurs de la palette : blanc, jaune et rouge, couleurs disponibles en quantité. Et ce qui était prévu pour être un centre spatial grouillant de vie devient un bloc à mi-chemin entre un blockhaus brevinois et un barnum bariolé. On dira que ce n'est qu'un coup d'essai !(Cyberpunk, 2004/03/01 20:17) lien permanent

In memory JSPC with WLS 6 and 7

Dion thanks BEA for in memory JSP compilation with WebLogic Server 8.1 sp2. I have to thank BEA for having so good salesman, the last enterprises I worked with used WLS 6 and 7, even an antiquated WLS 6.1Sp1 and its truckload of bugs. You know how big co' work, they apply service packs at the will of their IT department, most of the time 6 months after their releases at least. So thank you BEA for ensuring corporate software developpers another couple of years before they can gain decent compilation time. Only one more thing to say: a project with a dozen of session EJBs, and about thirty JSPs, compile and redeploy on a UNIX server with WebLogic 7 tools, equals roughly one hour. TDD ? No, back to pfort.(Cyberpunk, 2004/03/01 17:22) lien permanent