Netx (Network eXecute) is a JNLP (Java Network Launching Protocol) client that can also be used as a component to provide applications with JNLP features and support. It downloads code over a network, caches it, and runs it in a secure sandbox environment. It operates in a manner similar to Web Start, but is smaller, faster, and has no splash screens.
Re: What about Java?
> If Hotspot is so technologically
> superior, why is IBM taking it to the
> cleaners on a lot of numerical stuff?
The benchmarks cited don't even test hotspot-specific features (such as dynamic inlining) at all. Read the Hotspot benchmarking FAQ.
> I have read-up on Hotspot to try and
> figure out if the marketing hype was
> blowing smoke and sure enough they were
Look you don't have to like Java, but you opinions are obviously based on an unfortunate combination of outdated information, lack of information, and questionable reasoning. Go download the Hotspot VM source code if you want the proof -- it's in C so you should have no trouble following it.
It's not like C/C++ doesn't have performance advantages because of value types and mass-allocation, but most of the things you've said wrt Java in these posts is incorrect.
Re: What about Java?
> % Check out some benchmark results:
> % benchmark results
> Thanks - I took a close look and two
> things jump out: One is that it seems
> you and the benchmark post are drawing
> some conclusions comparing de-optimized
> C code to other runtime systems.
Comparing to debug build shows that Java is well within the same ballpark as C.
> What I'm trying
> to say is that debug builds for any
> compiler / runtime are not valid for any
> benchmarking, because that is not what
> is distributed to an end-user but is for
> the consumption of the development tools
> and developer only - that's a well
> established standard for fair
In Java you don't have separate "debug builds" or build for specific processors. Java generates processor instructions relavent to your processor at runtime so you don't need X different "builds" for different processor versions -- that's for stone age languages.
> The 2nd thing that jumps out is that a
> normal (built for production) C/C++
> binary is on average 2.3 times faster
> than the Java code.
Those numbers compare Microsoft's VC++ to Java, and Java is doing array bounds checking. And the IBM JVM seems to be ~1.8x faster than Sun's for this type of computation, making it very close in speed to a C++ compiler were LOTS of resources have been put into maximum performance.
> What does this
> have to do with client-side GUI
> toolkits? Nothing except to say that I
> think Java has been over-extended to be
> the end-all to application development
> so it is neither really scalable on the
> server nor really fast on the client.
If 1.2x or even 2x slower is not an acceptable performance loss for getting an easy to use, safe language with huge, quality class library for programs that spend most of their time idle waiting for user input then what's the point in logic and reasoning? You have to use it.
> % [Why hotspot is awesome.]
> Again, this sounds like it's from the
> Sun site :-)
So download the hotspot VM source code and look at it. It's true, whether you want to believe it or not.
> Under almost all
> circumstances, the static C/C++ compiler
> will have as much info. to feed "inline"
> heuristics as the Java code at runtime
> plus it will have a lot more time to
> (reasonably) use this info. [...]
You should read up more on hotspot and runtime optimizations.