Forum OpenACS Q&A: Questions on AD's restructuring.

Given the recent activities it is my feeling that AD has been slowing
repositioning itself to be a complete toolkit that is 100% Java and
will run inside Oracle itself.  I do not think this is a bad move
for them but I think it does have some implications for OpenACS.
Considering the performance penalities incurred in such an 
architectural design I believe they will start to add more and more 
Oracle-isms. I see it very likely that if they complete this task they 
would be an attractive takeover target for Oracle. 

 If this does occur what implications does it have for the GPL part of 
the codebase? What is to stop another firm from taking GPLed code and 
creating separate package?  

Actually my real concern is that OpenACS becomes overextended
trying to remain ACSish. I think there may come a time where OpenACS
would be best served to just evaluate the new aspects of ACS take the
best and ditch the rest and not be too concerned about remaining
*compatible*.  AD has given OpenACS alot but I think the paths may
indeed be diverging. I wish success for both but plan on helping out
OpenACS in the not too distant future. Just some thoughts ... 
Comments?

As far as ACS 4.x goes, since aD is ditching it (over time, but in terms of new development ASAP), OpenACS has already in essence forked the code base.  OpenACS 4.x will support both Oracle and PG, in fact getting the infrastructure in place to do so is what's been taking up Ben and my time the past two weeks.

We're almost there though it's been frustrating - I spent most of today rebuilding Oracle after it corrupted itself on my laptop, grrr...

As far as ACS 5 goes, aD has backed off the approach of putting much of the API in PL/SQL, specifically in order to make it possible to support multiple dbs.  In other words, Uday's right.  At least, that was the plan as communicated to Ben and I in January and AFAIK nothing  has changed.

Ironically, we can deal with the API-in-PL/SQL approach fairly easily in PG, since it has a nice little PL/pgSQL that has much of the same functionality as PL/SQL (no packages, no default params and only positional params but we can handle most PL/SQL semantics no sweat).

This isn't true in certain other RDBMS engines, though, so you can presume that the goal is to make it easier to support any SQL92-ish RDBMS that has decent market share.

Sorry for not closing my initial PRE tag

I first learned about ACS during one of Philip's seminars at Stanford in Jan 2000. As a then Java bigot, I was really surprised to hear about Tcl. But eventually I became convinced by Philip's discussion of how much more appropriate a scripted language is for web applications than is a compiled language like Java. Philip was particularly derisive about Java "junkware/bloatware" like BEA/WebLogic.

So what happened to this basic architectural belief at aD in the meantime? How is aD's new direction different from what Philip was once criticizing? What about the Tcl argument is no longer compelling?

I programmed in Java for several years and built two systems with it (both still in use today) before starting to use the ACS and Tcl. I was one of the people pushing internally at aD for ACS Java, and it was exciting to work on the project. ACS Java came about for a number of reasons, but I think the two strongest were customer demand and developer support.

In my experience, Java is a match for both business and engineering interests. There are some good APIs defined by Sun in the J2SE and J2EE specifications that have done much to consolidate enterprise development knowledge. The J2EE standards provide a solid means of education and adoption by developers and companies. The standards process is open and there are open-source reference implementations.

Java is not a perfect programming language, becuase no programming language is perfect. I could list some things that I like better about LISP, ML, and Ruby. I program in these languages for fun. Maybe some day they'll become more commerically viable. Part of what makes Java useful is its relatively simple (compared to C++) OOP framework. Java's real value is in building reusable software. When combined with regression testing frameworks like JUnit and a modeling language like UML, one can design, implement, and maintain enterprise class software in an cost-effective manner. Its also fun.

It did take some time for Java to be adopted by the OSS world. However, its adoption is now wide. The Apache group, Enhydra, numerous SourceForge projects, IBM's alphaworks, CoolServlets.com. There is so much open-source Java code out there its almost overwhelming.

A couple of technical advantages that I find personally compelling:

1. People often complain about the annoying "compile step," of Java because it is slow or interrupts the write/run/debug cycle. Scripting langauges, such as Perl, Tcl, and Ruby don't require this. However, Java compilers are fast and produce code that runs faster than any of these languages. If you prototype code in a JSP, you don't even need to invoke the compiler manually.
2. Maybe people can write neater code than me, but I'm a sloppy coder. When writing Tcl, I can't believe how many times I had to re-evaluate a page or a library file because of yet another syntax error or misspelling. The compiler has saved me lots of time as it can usually tell me what my problem is. Java compilers tend to be much smarter than C/C++ compilers.
3. Java gives you the ability to use rich datastructures and object oriented programming. This allows you to write code that is more modular, functional, and maintainable.
4. Between J2SE and J2EE, the platform has a lot of usable APIs. This increases the speed of development.

Java isn't perfect, but I do find it a better match for building enterprise software than Tcl. I hope that we'll do a good enough job on ACS 5 to convince people to make the upgrade. In any case, language choice doesn't really matter. Enterprise software must solve an enterprise's business problems. In many cases, Java is a great tool to use, but its not a perfect fit for everyone. However, Java is a workable tool, and its more workable than the alternatives for what we're trying to accomplish with the ACS: provide a flexible, enterprise-class, and open-source e-business platform.

Bryan: on the whole, you are correct. Java has major advantages for building enterprise software, primarily because of the strong frameworks & libraries surrounding it. APIs added in response to marketing hype about Java being 'the language of the internet' -an ad circa '97. I am not decrying this approach; I am not a techie with my head in the sand - in the end we benefit from all these groups consolidating interfaces. I am trying to continue the point I was making in my previous post: that the political differences between the open source community and the way that Java has been pushed may impede Java's acceptability in this market. And by market I don't just mean the several hundred respectable software engineers you'd like implementing highly visible ACS's, but also the thousands of kids unversed in UML and ACID tests. For ACS to be the first response to an earnest question of community systems, we want a base of the size and composition of, say, slashcode.

And that's really something I should say before I slide into rant mode (and then sleep) - this group is becoming steadily focused on "design, implement, and maintain enterprise class software in an cost-effective manner" and downplaying quick hacks; which is sad, b/c over the lifespan of the Web, that's where innovative services have sprouted like weeds (b/c when you're developing something totally new, UML patterns don't leap to hand). Language zealotry I'm indifferent to, but I don't want to be part of a group where process has killed creativity.

<RANT>
Your panel of suspects, "Apache group, Enhydra, IBM's alphaworks, .." only reaffirms my suspicions. I scan freshmeat.net daily, and I don't see many apps being writting in Java - I see supporting architectures&servers, eg, Enhydra. Nor are we seeing it used much outside the servlet space.(which is a fine place to be, if you happen to be a servlet.) I think the most popular OSS web app that leaps to mind would be half-empty.org's engine.

Java is not a perfect programming language, becuase no programming language is perfect. -- B. Quinn
While you have the truth of it in that no language is perfect, (I also never used the term 'perfect' in my post....), I feel you missed my point. Java sucks. Okay, a visit to alt.sysadmin.recovery will inform you that all languages suck, so I should elaborate: in terms of language design, Java was a step backwards for almost everyone who switched to it, with the major exception of the poor bastards grinding MFC over VisualC++. Maybe I'm just too young; maybe this happened with C++ & PL/1 & everything else; but Java was the first time I've seen a product so evidently unready for the light of day being rabidly supported by three quarters of an industry.
</RANT>

Talli: If you make the guacamole, they will come.