cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Java Language Advocacy (was Re: How ASF membership works and what it means)
Date Sat, 28 Jun 2003 11:30:19 GMT

Stefano Mazzocchi wrote, On 26/06/2003 20.37:
> But my point is slightly different: the java metaphore for achiving WORA
> is 'common denominator abstraction' which, many times, forces
> reinvention of the wheel.
> I used to believe this was the case, but after SWT, I've completely
> changed my mind and I think that 'behavioral abstraction' would be a
> much better pattern even if the implementation of the API normally
> requires much more work and the system using the API has to check for
> existance of particular behavioral properties and adjust to that.

I'm really confused about this SWT thing. On my computer Eclipse feels 
slower than JBuilder. And I still have to understand what makes SWT so 
compelling and AWT so dreaded.

The fact is that *if* the abstraction of the JVM is performant, then 
there are no problems in keeping "pure" java code.

So the question is not about speed. I've seen and done myself tests that 
show how JNI stuff can be much slower than pure Java. HotSpot can be 
pretty smart.

> Also note that behavioral abstraction is an extension of common
> denominator abstraction, just requires to stop thinking that having
> system specific properties that are not available everywhere is a bad
> thing. And *this*, for java programmers, is a problem which doesn't
> exist on any other software programming culture that I know of.

It reminds me of assembler code in C programs, and how many wined that 
some reimplemented stuff in C.

Having system-specific properties sucks big time. Abstractions are what 
makes programs be useful on different platforms.

What is the APR. An *abstraction*.

So the question is not wether we should abstract, but wether a JVM is a 
good abstraction.

Points are:

  1 - speed
  2 - interaction with OperatingSytem services
  3 - code reuse

1 - For speed, I think it's a moot point. It has always been, since the 
days assembler was starting to be superceded.
The real problem with Java is not spees, it's *memory*. Some programs 
need so much memory that the HW architecture sometimes cannot even 
address. Memory is cheap? If you can install it on your system, that is.

2 - Java has too many "soft" implementation if features, that instead 
are part of an OS. Is java an OS abstraction? Ok, stop laughing, I get 
the point ;-)
This percieved and real distance from the system services is what 
doesn't make Java run well with other systems, and makes devs talk about 
native calls and system properties. Instead, IMHO, it's all about an ill 
devised abstraction for these services in most cases.

3 - Code reuse is another important issue. In Unix (term improperly 
used, please be kind), whatever language I use, I can mix programs. This 
is the *real* power of that system, and something Java lacks. NET has 
put languages on top of the abstraction, or taken the abstraction on a 
more OS level by integrating it (use the definition you prefer).
Java should be much easier to make these things happen, and make Java 
rely on external libs loke the Apache stack, or Unix commands, rather 
than reinventing each time.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message