cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject Re: Java Language Advocacy (was Re: How ASF membership works and what it means)
Date Thu, 26 Jun 2003 17:01:07 GMT
Although I think Stefano's observation is correct that Sun's codebase is 
a primary reason for Java "running everywhere", nevertheless it is an 
undeniable reality that in my opinion makes Java development _much_ more 
pleasant compared to C and C++. In the past I've had to write C and C++ 
code that ran on a multitude of Unix platforms, as well as embedded 
real-time operating systems, and Windows. You spend much of your time 
dealing with "portation" issues: writing #ifdef's and macros to hide 
platform differences and work around platform compiler bugs and 
limitations. That isn't fun, believe me. Building and testing on 
multiple platforms is also very time-consuming and tedious.

Another aspect not always noticed is the speed of the compiler. Because 
Java compilers don't perform any compile-time optimizations, they are 
significantly faster than C++ compilers. This is very important when 
dealing with very large codebases.

Of course, Python doesn't get compiled at all, and I've heard it argued 
that interpreted languages will be used exclusively in the future with 
very large code bases for that very reason.



Berin Loritsch wrote:

> Stefano Mazzocchi wrote:
>> on 6/24/03 6:55 AM Dirk-Willem van Gulik wrote:
>>> Then perhaps my observation means absolutely nothing - and I should 
>>> really
>>> try to get my mind around a fundamentally different development 
>>> model (and
>>> some aspect you call WORA).
>> Oh, sorry, WORA := Write Once Run Anywhere. It's java's first
>> commandament. Basically, it's bullshit: java runs everywhere because all
>> virtual machines descend from the same codebase (in fact, those exotic
>> virtual machines like Kaffe or natively-gcc-compiled are not used
>> because the number of small incompatibilities/deficiencies is simply too
>> big).
> I guess we aren't on the topic of ASF membershipe anymore ;P
>> WORA translates automatically into Java's biggest sin: native code. Java
>> programmers were tough the religion of "java purity" as the only way to
>> purify their souls from the "sin of native code".
>> This is the reason why we basically we have mod_* where * is any
>> programming language, but not mod_java, there is no java API that mimics
>> the HTTPD API because we preferred to avoid the "sin" of doing JNI (java
>> native interface) and preferred the socket disconnected way with 
>> mod_jserv.
> To be honest, Stefano, I partially agree with you--though not completely.
> To me one of Java's strengths is the ability to develop on Windows and 
> deploy
> on a real operating system (read UNIX).  It's for that reason that I am
> not too thrilled about .NET--although in my brief brush with C# and 
> the suite
> of open source tools supporting it there are many features to like 
> (and some
> to dislike).
> I don't see JNI necessarily as a sin, but I do see it as a management 
> problem.
> Just because a library works flawlessly in Linux systems doesn't mean 
> it will
> do that for Windows based systems, and vice-versa.  Typically the 
> library will
> be strongest on the platform that the developer of the library is 
> strongest.
> That can be a problem if there are key features that you need in a 
> library,
> but it is unstable on the platform you are deploying.
> SEDA's nbio package is awesome--on UNIX.  It is much more efficient 
> than Java's
> nio package.
> Another major strength for Java is that there is one API for all 
> platforms.
> That means I can develop with a very high degree of confidence that 
> what I
> write will work on platforms I care about.  It also makes me much more 
> efficient
> as I don't have to worry about some low level details or what the exact
> differences between POSIX calls on Windows and true POSIX calls are.
> There is alot of advantage that Java provides--but it is not a panacea.
>> note that for apache 1.3.x, JNI would have been hard because of the
>> multi-process environment, but for apache 2.0, a JNI-based mod_java is
>> perfectly valid architecturarely, but nobody works on it because of this
>> "sin" syndrome.
> :)  I think it has more to do with all the choices they have available,
> and it is not a particular itch that many people have to scratch.  It 
> takes
> an inovator to proove that folks can't live without it.  It's the 
> "Build it
> and they will come" syndrome.  You always run the risk of nobody comming.
>> Also, java programmers tend *not* to have any knowledge of things like
>> "how to link a library in a native environment". 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.
> Oooh, those are fighting words ;P
> Seriously, Phoenix and other microkernel based systems have their place.
> Trying to put a mail server and a web server in the same JVM may not be
> all that great an idea, but that doesn't negate the need for something
> like Phoenix.
> Security models are something that NO ARCHITECTURE EVER can get totally
> right.  It takes a dedicated crew to stay on top of changes and try to
> anticipate the ways that people will try to break your system.  That
> said, there is a lot to do in any Java based system.
>> Pier is probably the only person I know who has great capacity on both
>> sides of the fence and he tried to add unix deamon-like capabilities to
>> java but crushed into several JCP walls where native stuff is still seen
>> as a sin.
> There are isolates comming which provides ways of managing child JVMs
> and virtual JVMs.  Not here yet.
>> Note how Java failed on the client side because of how slow swing is.
>> Eclipse introduces SWT, something that Sun really disliked because of
>> considered again a "sin" to have something OS-specific.
> Whatever.  It is catching on and folks are using it.  I'm contemplating
> that myself.  Then again, Swing performance is much better than it used
> to be.
>> Again, the culture difference between java and python, for example, is
>> that python has OS-specific features, java does not and will never.
>> java is based on a common denominator. Python is based on giving access
>> to what you have.
> I want a common interface to common things.  If Python can give me a
> common API for controlling windows, et. al. then I can use the same
> script on both Windows and UNIX.  If I have a separate API for each one,
> then I have to write some glue code, detect what platform I am on, etc.
> etc.
> If you can give me that with C++, then I am all over it, and I will
> leave the Java fold (just kidding--maybe).
>> personally, I feel ashamed I was not able to see that this WORA concept
>> is just bullshit and that I wasn't able to see how mentally limiting
>> this "pure java" thing is.
>> But it's far from common to have language open mindness in the java
>> world and this is due to this purity religion.
> Every language has its zealots.  Every platform has its zealots.  
> Practical
> people use what works.  That's me.  I have to work with both Windows and
> Unix platforms all the time.  I don't have to worry about embedded 
> programing
> or anything like that.  I don't want to waste time when I bounce back and
> forth.  For now, I get that with Java.  If the Mono project takes off, 
> then
> there is a good chance to use .NET based stuff (or at least C#) which has
> the same pragmatic idea as Jython.
> We already have a port of the Avalon framework in sandbox for .NET.  I am
> playing with that (at work we will have to know .NET in about a year--I
> plan to be ready with tools that I like).
> All that said, I use what works.

View raw message