Forum OpenACS Q&A: Response to A Technical Paper on Java

Collapse
Posted by Malte Sussdorff on
Okay, I stuck my head out and asked a couple of colleagues of mine to comment on the paper (hit me on the head for distibuting the link if you like). They mentioned a few corrections where in order, not from an evangelist standpoint, but from a technical one (and I need to translate german -> english on the fly, please bear with me):

Imperative programming has proven not to be well suited for complex application development which allows reusability. One step into this direction is OO related programming, but it is still a long way to go (check out component based development or aspect oriented and generic programming). But a lot of small things are not as easy to programm in OO than in other languages (e.g. sorting algorythms and the like). But when it comes down to a complex application (e.g. using the sorting algorythm as a component for encryption or hashing), reusability make it worthwhile again. If OpenACS is all about displaying data on the web, retrieved via SQL from a database, OO is like hitting flies with a canon. If you want to have an extensible and reusable application with some more logik, OO is the way to go. If you want to access this application with Webapplications, Palmtops and normal programms, use an application server. Once that is done, you should choose the programming language. Take C++ or C# for speed, Java for portability and tons of cheap modules. So, use TCL, Java whatever you like for your development but anticipate further needs and their complexity in advance to stay flexible enough to switch the plattform.

EJB-Containers are compatible to each other as long as they follow the J2EE specification. Companies need to distinguish themselves though, therefore they add additional functionality. An intelligent developer does not use those features or writes a layer around them. The comparison between J2EE and TCL lacks the following strenghtes of J2EE: EJBs (Components), Nameservice (JNDI), messaging (JMS), transaction service (JTA/JTS), a mechanism for distribution and all the design patterns around J2EE. Furthermore the Java Connector API, which allows connections to SAP of Host Systems. How would you connect AOLserver to a database not knowing SQL (which is quite common in large companies). Java datatypes match SQL datatypes 1:1. Using java.lnag.String and Stringbuffer allows very good string manipulation. Using Visual Age you can easily debug JSPs and their compilation into HTML. Using a persistent layer over the database allows independency from the database and the structure of the tables (you don't need to change the Java source, if the table structure changes). Using Java the scalability increases in form of multiple layer architectures. Application Server allow vertical and horizontal clustering, therefore allowing a dynamic load sharing on a server farm. Furthermore some points concerning the split between application, presentation and database logic would be in place, including a grafic how this is done with OpenACS. From a marketing perspective it might not be that a good idea to bash on J2EE.