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

["Samuel A. Falvo II" <sam.falvo@xxxxxxxxx>]

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.

-- 
Samuel A. Falvo II