on 6/26/03 1:03 AM Noel J. Bergman wrote: > Do you really know only such cloistered Java programmers despite all of the > ones you meet?
Yes. Very few have the guts to exit the celebrated monocultural java vision (and I was one of them since not so long ago) >>basically they are totally isolated, which leads to concepts such as > > server > >>microkernel architectures (avalon Phoenix) which look cool from a purely >>architectural perspective, but are totally weak from a security and >>stability perspective, because they use one JVM for the entire thing, a >>very weak setup. > > > However, having something like httpd front-end lots of backend JVMs on > multiple machines is nice. Hey, I know that. I was one of the designers of mod_jserv, you know? ;-) > And what prevents mod_jk2 from using a launcher > to control and monitor JVM processes? Nothing. that's exactly how mod_jserv worked. > It would be nice to be able to do > something like: > > <virtualhost ...> > ServerName RingBearer > JkUserID frodo FoTR > Jk... > ... > </virtualhost> > > and have Coyote communicate to a "jkLauncher" a connection request for a JVM > running as that user (configuration of the JVM not being the launcher's > responsibility). It would certainly make my configuration easier, and more > robust. Currently, I do something similar by hand. > > A problem with multiple JVM instances is the lack of sharing between > multiple instances. ??? on some operating systems, different JVMs share as much as 80% of their memory. > f you run multiple instances of tomcat, one per > virtual host for example, your memory overhead is considerable since none of > the class code is shared. I would like to see the JVM/JIT generate and > share common class code on platforms that support it. This is already there. > Sun appears to prefer intra-process threading or inter-process communication > over network interfaces. You might find: > > http://www.iee.org/Publish/Journals/ProfJourn/Proc/SEN/vinter.pdf > http://www.cs.berkeley.edu/~szewczyk/cs267/Final.html > http://matsu-www.is.titech.ac.jp/~sohda/research/javag2001.pdf > > interesting. I didn't say practical. :-) Although JPS looks interesting. > > True, Java is not a systems programming language. But without WORA, I do > not believe that Java would have the success that it has on the server. A few months ago, I had a very interesting conversation with Pier on JAMES. <background>JAMES (james.apache.org) is a mail server written in Java that contains pluggable programmatic modules called "mailet" to extend its functionality (much like servlets for an HTTP server) Pier and I designed the concept of Mailet on the plane going to ApacheCON '98, then we met with James Duncan Davidson at Sun to discuss the issues we had with the Servlet API at that time (James was not yet an apache fellow, but he was the spec lead for the Servlet API). There we proposed to add "mail" capabilities to the servlet API. After a long discussion, James turned the proposal down, basically because the Servlet API *looked* like it's abstract enough to take mail operation in consideration, but it's not: it's designed with the concept that the response goes back to the requestor. Which is not the case for email. Also, there were major marketing problems in moving a clearly web-centric architecture in a realm (email servers) where Sun (nor the other vendors) had no interest in going. So, we created the Mailet API and started JAMES, later we had Federico involved that did most of the coding.</background> Now, Pier, Fede and I share our email infrastructure on betaversion.org. It's a pretty complex (and very powerful) setup made with qmail+cyrus+bogofilter+sieve+Horde/IMP glued with some croned-invoqued python code that updates every 5 minutes the bogofilter database extracting the spam/ham from the cyrus folders. I also added some PHP to IMP to allow me to update my sieve file directly from a web interface. The system is solid, very powerful, but hey, from the eyes of a software architect, looks messy as hell. So, one night, when I was visiting them in London, Pier and I sit down and talked about how feasible/useful/dangerous was to update our email infrastructure to JAMES. [despite the little coding I've done on it, I'm still emotionally attached to the idea of having an entire email infrastructure based on the beauty of java modularity and pluggability] It turned out that Pier had pretty rock solid arguments *not* to use JAMES as a MTA and all came from the sysadm paranoia that he grew accustomed to (and which I totally lack, given my very basic sysadm skills and experience). Unfortunately, I don't recall exactly what his arguments were, Pier, do you have a minute to chime in? I think the JAMES people would love to hear your criticism. Anyway, i remember that all of his points came from the fact that by using the JVM you are basically giving away all multi-processing features of the operating system and since UNIX is basically designed around the concept of processes, java strongly limits your ability to 'well behave' in a modern operating system environment. this is something I remember Brian was strongly concerned about as well: qmail is *strongly* multi-processed and this is something that qmail users normally love. qmail is an orchestra of processes, each with different capabilities and security protections, that work toward a the common goal of delivering email. This separation-of-concerns-driven design is incredibly solid and very scalable (too bad qmail is not opensource and it's a one-man show), something that can be matched (or even improved, I believe) in a multi-threaded environment, but this gives a single point of failure to the system that is not acceptable from a paranoid sysadm point of view. So, my point is: java is great and solves a lot of problems, but it's 'common denominator abstraction' design paradigm is, IMO, hurting severely the ability to adapt to different environments. SWT vs. Swing shows exactly what I mean: SWT is native, has to be implemented completely in every OS, but it *ROCKS* compared to Swing, which is a common denominator abstraction, but it's *SLOW* as hell, because such virtualization stops it from being hardware accelerated (so, basically, Swing is 10 years behind from a graphic architecture perspective, except on MacOSX, where Swing is natively implemented, thus accelerated) Java doesn't have concepts like native process forking capabilities, no notion of OS security, nothing that cannot be found in all OS is present and, if present in different ways, it's virtualized. So, the silly java architects want java to be your OS and in order to have you buy this shit, they tell you that if you don't do this, you won't have WORA. And people buy it! The power of marketing. This attitude is hurting the ability to java to be a *solution* for your problems, whatever they are, not simply a rotation of you problem realm. As you, I would love to see JAMES be used as the ASF email infrastructure because it would allow fancy interoperability, expecially between the email realm and the web realm, which are, historically, hard to mix in an elegant and coherent way. At the same time, I strongly believe that without a healthy amount of native code, it is impossible to match the sysadm needs and fears. And I'm afraid that WORA is getting in the way and it's preventing us from taking java to the next level, where it enters its medieval religious crusade-like attitude and simply becomes a modern, peaceful and cooperating technology. Apache made java known and possible on the server side. Now Apache has to liberate java from its WORA mental jail in order to move it to another level. And in order to do this, we must commit a few sins, one of which could be compiling our existing code for .NET CLI and another creating APR Java API and stop using the java standard libraries. Java is a lot more than what Sun wants us to believe. Take the red pill and exit your virtualized common denominator matrix that the big ball of fire in the sky calls "platform", and see with your own eyes what java is really about. -- Stefano. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
