Slashdot Mirror
Sun To Give StarOffice Java Flavor
ilovestuff writes "Sun Microsystems is building a Java-based development kit for its StarOffice software to help corporate programmers customise desktop applications, a move that better pits it against Microsoft's dominant Office. The software development kit will be available in the middle of next year as part of a minor upgrade to the business version of Sun's StarOffice 6.0, said Joerg Heilig, director of engineering for StarOffice at Sun."
...unless this will help me stay up longer so I can finish this paper that was due yesterday.
Great, so now virus-writers will be able to create cross-platform office viruses.
Java is a very nice OO language. Because of this, there is an extremely large body of existing class libraries that have names that are often abbreviated to acronyms. If you think the "learning curve" is too big, then by all means, use another language and start from scatch.
Java's slowness is often maligned, but java actually stacks up pretty well if you look at objective benchmarks. In Bagley's Language Shootout, java was 9th of 30 languages tested on linux. It does use a lot of memory, but only because of the overhead associated with the JVM runtime. Of course this is the price for writing code that work on windows, linux, mac, and random unix, so it is a tradeoff many accept. If this really bothers you, get a native java compiler and then you'll have smaller footprints but no portability.
I use several java apps on my P2 300, so I think you are exagerating. Odds are that you don't have much memory and that is what is slowing you down.
Java can only be considered a failure
Really? Java was invented a few years ago. There are now more jobs programming java than any other language. I really don't see how that is a failure.
Sun's StarOffice division intends to make Java a scripting language for StarOffice,...
A word processor running scripting language? Doesn't that sound so familiar to everyone?
which will help customers take advantage of Java's security features. Java's security model works by limiting the areas of the computer the code can manipulate.
Fortunately, smart people can learn from mistakes of the other and built it with security in mind from the ground up.
but it doesn't stop the creative minds of programmers.....
Sun's StarOffice division intends to make Java a scripting language for StarOffice
Great, let's call it Javascript.
Java is good at some things, worse at others. Look at the following for instance:And now for Java:The results get even more interesting as you compute higher and higher numbers of the Fibonacci sequence. When computing the 43rd Fibonacci number the java bytecode beats the statically compiled C machinecode by a full 10 seconds. For the 44th number it beats it be 19 seconds.
Does this mean that java bytecode is faster than machinecode in all cases? No. Does the fact that a few java applets on your P2 run poorly mean java itself is slow? No. It is true that Java has poor performance in the GUI realm, but it is great for backend server applications. So making the blanket statement that java is slow or fast in general based on a single or handful of benchmarks is just plain wrong.
* I'm not running some special optimized pre-release version of Apple's JVM. It's the pre-release 1.4.1 implementation. Nothing that isn't available on Windows, Linux, Solaris, etc.
I don't think it is. Perl, Python, and TCL all run under UNIX and Windows. Hell, they're even compiled at runtime. And somehow they still use much less CPU and memory.
I have 128M of memory. If that's not enough, then that's ridiculous. XNap, a Java napster client, takes ~20 seconds to start up. Java applets in Netscape take 15-30 seconds to start. Oh, and Sun's java plugin likes to crash Mozilla constantly, so I don't even bother enabling it in the first place.
And they're all boring enterprise level applications. While you may consider that a success, Java didn't change anything. Had it never been invented, though would have been written just the same, in C++.
Most of those apps are likely written so poorly they only run on Windows anyway. I've heard Java's cross platformness is mostly a myth.
Java has done nothing to make consumer apps cross platform.
It was invented before Flash. It has Netscape's backing. And it still has less market penetration.
The benchmark becomes even more interesting once you realize that the java benchmark includes the overhead of starting up java and jit compiling the class file. It still is faster.
Jilles
Good argumentation. One point though. You seem to suggest that Applets are not a primary application (no pun intended) for Java. In my opinion, Java Applets should be one of the main strengths of Java. Platform independence is a necessity for software intended to be embedded in webpages. JavaScript and Java are the two main alternatives here. JavaScript, intended as a scripting language for the enhancement of webpages, lacks the features necessary for writing full applications. Java is plagued by Virtual Machine incompatibilities (mostly thanks to MicroSoft), and the general bloat and slowness of Java virtual machines. There are opportunities here. Big opportunities. Java has the edge here, as it is the only widely adopted language for webpage-embedded software. It's a pity that Java sucks so hard at what it's best at (better than any competing language).
Please correct me if I got my facts wrong.
Wow, that is quite surprising -- so much so that I tried it myself. I reproduced this test on Linux with similar results.
I've tried to figure it out: first I thought maybe the Java compiler did some heavy optimization, but inspecting the bytecode with javap showed it was a straight forward translation of the source.
My other thought is this particular example plays right into the strength of Java's JIT. Since the same code is run over and over, it can be compiled once at runtime. The code is very short, so the just-in-time compilation doesn't take much time. And it can fully exploit Java's key performance advantage: the ability to incorporate runtime profiling information into the optimization process.
Don't get me wrong, this is extremely impressive. But it *is* a contrived example that shows off Java in its best light.
Oh yeah? Well beat this!
./fib.sh 40
# cat fib.sh
fib() {
n=$1
if [ "$n" -lt "2" ]; then
echo -n "1"
else
first=$(fib $((n-1)))
second=$(fib $((n-2)))
echo -n $((first+second))
fi
}
fib $1
# time
(it's been 10 minutes and I'm still waiting...)
SWT is more like AWT in that, rather than use actual JAVA code to draw things like windows, buttons, pulldown-menus, text fields, and the like, SWT (like AWT) will make a call to a native OS function that renders that widget for it.
SWT is different from AWT in that it does not try to adhere to the least-common-denominator principle -- is like Swing in that regard because it has more GUI widgets that can be added to the program.
SWT is unlike Swing, however, in that rather than using Java to draw the widget and listen for inputs, SWT merely tells the OS to do it for the program and handles anything the OS reports back. Because the code for handling that widget is optimized compiled code for the operating system, there is a massive net speedup in GUI interactivity.
SWT would probably be unnecessary if Sun would just put out a VM that handles the "power" of Java threads in a much better way.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
My other thought is this particular example plays right into the strength of Java's JIT. Since the same code is run over and over, it can be compiled once at runtime. The code is very short, so the just-in-time compilation doesn't take much time. And it can fully exploit Java's key performance advantage: the ability to incorporate runtime profiling information into the optimization process.
Static compilers make "eduated" guesses as how to best optimize code. When it comes to a fork in the road it, since they don't have actual run-time information, they have to do the best they can and move on. Java can leverage run-time information against the statically compiled bytecode and utilize dynamic optimization. Granted completely linear code will always run better when statically compiled to machine code, but if at any point in the compilation process the compiler has to make an "educated" guess, a better decision can be made at run-time through dynamic optimization. General information on dynamic optimization can be found here.
It's big and slow.
In some cases, it's faster than C++.
Don't believe me? Download the Markov examples from Kernighan & Pike's "The Practise of Programming" and time the C++ and Java examples. On a P3-550 I get 3.63 seconds for the C++ and 2.90 seconds for the Java version.
-- Alastair
On a P3-550 (dual CPU, but that has no effect here) I get 10.82 sec for the C version (GCC 2.95) and 9.74 for the Java version (JDK 1.3).
-- Alastair
(and similar in Java), I get times of 0.004 seconds for C and 0.567 seconds for Java -- most of which is the time to load the JVM (ie the difference between 'time java fastfib 40' and 'time java fastfib 0' is lost in the noise).Rewriting fib(int n) along the lines of
Proving that choice of algorithm can make far more difference than choice of programming language.
-- Alastair
For all practical purposes ".NET" is basically the name that Microsoft is now associating with every latest version of most of its products, so it means nothing. (Yes, there is a very nice JVM ripoff in there somewhere...)
This JVM-inspired environment is called .NET Framework. Look for the word "Framework" in Microsoft .NET product literature to find references to what most Slashdot users seem to associate with ".NET".
C# fails
Some critics have described the Java language as "C++ done right". The C# language is Microsoft's re-hash of the Java language. Now if you stick two ++'s on top of each other, you get something that looks like a hash sign; thus, (C++)++ is C#.
Will I retire or break 10K?