Re: gEDA-user: Free Dog meeting report: Notes on the topics we discussed

[Olgierd Eysymontt <olgierd.eysymontt@xxxxxxxxxxx>]

I've made A LOT of Java program, including the one of power systems,
that made A LOT of complex matrix inversions very quickly.

And YES IT RUNS ON LINUX as all the progrmas I've made has been made on
linux and run on Windows WITHOUT NATIVE LIBRARIES.

I think you really don't know what Java is, you can ask yourself why is
one the most used languages now, check Sourceforge if in doubt.

Java virtual machines has been very optimized in the last years and
represent a hardware abstraction layer which I think is very necceasary
today specially for folks on NetBSD, Solaris, AIX or whatever you want. 

Olgierd

On Tue, 2005-09-20 at 07:55 -0700, Samuel A. Falvo II wrote:
> On 9/20/05, Karel Kulhavy <clock@xxxxxxxxxxxxx> wrote:
> > Question: "Does it work on Linux?"
> > clock@kestrel:~$ java -classpath
> > *** glibc detected *** free(): invalid next size (fast): 0x08059d88 ***
> > Aborted (core dumped)
> > ^^^^^^^^^^^^^^^^^^^^
> > Answer: "No."
> 
> bash-2.05b$ java -classpath
> -classpath requires class path specification
> Usage: java [-options] class [args...]
>            (to execute a class)
>    or  java [-options] -jar jarfile [args...]
>            (to execute a jar file)
> 
> where options include:
>     -client       to select the "client" VM
>     -server       to select the "server" VM
>     -hotspot      is a synonym for the "client" VM  [deprecated]
>                   The default VM is client.
> 
>     -cp <class search path of directories and zip/jar files>
>     -classpath <class search path of directories and zip/jar files>
>                   A : separated list of directories, JAR archives,
>                   and ZIP archives to search for class files.
>     -D<name>=<value>
>                   set a system property
>     -verbose[:class|gc|jni]
>                   enable verbose output
>     -version      print product version and exit
>     -showversion  print product version and continue
>     -? -help      print this help message
>     -X            print help on non-standard options
>     -ea[:<packagename>...|:<classname>]
>     -enableassertions[:<packagename>...|:<classname>]
>                   enable assertions
>     -da[:<packagename>...|:<classname>]
>     -disableassertions[:<packagename>...|:<classname>]
>                   disable assertions
>     -esa | -enablesystemassertions
>                   enable system assertions
>     -dsa | -disablesystemassertions
>                   disable system assertions
> bash-2.05b$ 
> 
> 
> Answer: "Yes."
> 
> Sorry, but I don't know how you have your Java configured, but it
> works just fine for me.
> 
> > I was once impressed by slowness of Java. A game "Jet Set Willy" for ZX
> > Spectrum was emulated in Java - it ran on maximum speed on pipelined
> > 32-bit CPU with 1800MHz clock as fast as original machine code version
> > ran on 8-bit CPU with 3.5MHz clock where fastest instruction took 4
> > cycles.
> 
> There are still entirely too many variables to say that "JAVA" isn't a
> viable platform.  First of all, you have the implementation of the JVM
> itself, which greatly influences speed.  Then you have the Java
> compiler itself used to create the .jar and .class files.  Note that,
> just as Intel's C compiler is optimized for Intel x86 and not AMD's
> x86 line, it's entirely possible for Sun's javac to be optimized for
> Sun's JVM runtime characteristics.  Therefore, another vendor's JVM
> *may* not run a piece of code particularly fast.  Or, it may run it
> *faster*.  You just don't know.  Nobody actually does.
> 
> I'm not apologizing for the rubbish that was passed off as a great
> technology in Java.  But when you get down to the core of it, Java's
> VM should be about as fast as Perl or Python, because all it's doing
> is interpreting bytecodes -- just as Perl or Python does.  Any
> sluggishness of "Java" you see is quite likely the result of (a)
> poorly implemented libraries, and/or (b) inefficient bytecode
> compiler.
> 
> > scarce energy. Not a great tool of you want to run a program.
> 
> Our e-commerce servers at work run their software as Java servlets
> (Kurant Storesense).  The load on the machine is not much higher than
> running osCommerce, which uses PHP as its dynamic content engine. 
> Performance on the server is acceptable enough to handle the 200
> stores that's hosted on it, which are accessed quite regularly.
> 
> I'm not a fan of Java by any means.  I'm a FORTH person, and always
> will be.  But I really abhore disinformation.  It really sours an
> otherwise excellent discussion.
>