[
Lists Home |
Date Index |
Thread Index
]
Well, I'm writing about Java because it represents 80% of the code I wrote
these last 7 years. My point would be the same with any other language, and
it's not rocket science : keep projects within precise functional
boundaries, and use carefully designed API whenever you have to cross those
boundaries. Don't think about building a project that spans those
boundaries, let people who know how to handle the stuff from abroad handle
it. If you're interested into changing your scope, then start a new project.
Java is not a core issue here, it is just that I mentioned sample Java APIs
that could be used.
As for the performance aspects of Java, I won't enter the debate, thank you
:). I would just like to say something simple : in C/C++, your price for not
coding correctly is memory leaks and segmentation faults. In Java, your
price for not coding correctly is bad performance. Granted, the "you won't
have to worry anymore about memory usage" was not true, but believing in
this was a bit naive (I did, but I was naive :).
All languages are perfect provided you code correctly (and you are a
believer, of course :). I hope I finally managed to do so, anyway my
experience is that since JDK 1.3 is out (and even before on the Win32
platform), I never encountered any performance problem in server-side Java
(in *my* version of server-side Java, i.e. no EJBs). Plus, the portability
feature is truly important for us, who develop on Win32 platforms and deploy
on Win32, Linux and Solaris ; as we are extensively using multithreading and
advanced memory management (soft references et al), this really saves us
days and days of worries.
I don't want to gain any new believers in Java, here. This is a free world.
You can stick to C, I'll stick to Java. I only regret that the code we write
won't easily be compatible :).
Regards,
Nicolas Lehuen
>-----Message d'origine-----
>De : Daniel Veillard [mailto:veillard@redhat.com]
>Envoye : mercredi 27 mars 2002 12:59
>A : Nicolas LEHUEN
>Cc : 'Matthew Gertner'; 'James Clark'; 'xml-dev@lists.xml.org'
>Objet : Re: [xml-dev] RELAX NG Marketing (was RE: [xml-dev] Do Names
>Matt er?)
>
>
>On Wed, Mar 27, 2002 at 12:29:33PM +0100, Nicolas LEHUEN wrote:
>> Like I wrote before, I don't think that trying to stuff as
>many features as
>> possible under the hood of the parser is a wise thing. I
>think we should
>> have a lean and mean parser API (SAX2) and lean and mean
>parsers (less than
>> 100 kb or JAR). Then, separated from the parser, you would
>have a lean and
>> mean XML tree API (DOM2 for compatibility, or dom4j for
>functionality), a
>> lean and mean XPath API (Jaxen), a lean and mean validation
>API (Sun MSV), a
>> lean and mean pipe building API, and so on and so forth.
>
> Nice rethoric, however:
> - it seems to only be centered around Java
> - SAX/SAX2 outside Java is a mess, especially for pure C
> - running a minimalist prime number algorithm on a Java
> machine seems anyway to use between 80 and 170MBytes of
> virtual memory usage see the Test1 report from
> http://www-106.ibm.com/developerworks/java/library/j-native.html
>
> So even if your jar is 100KB or even 1KB, I'm afraid you have trapped
>yourself into the bloat by the way of your "there is a single
>development
>infrastructure" premice, and much of the remaining arguments of your
>post don't make much sense.
> Unless I misunderstood, the Java performance report paper I point to,
>or the guy is very biased against Java (which look unlikeley
>considering
>it's an IBM developper work paper in the Java section).
>
> I will stick to C thank you, even if this mean that designing the
>code or API requires being a bit more careful.
>
>Daniel
>
>--
>Daniel Veillard | Red Hat Network https://rhn.redhat.com/
>veillard@redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
|
