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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------