Designed to compete against MS Office, EIOffice 2004 is coded in Java therefore able to run on both Windows and Linux. EIOffice 2004 offers features which should get a few users’ attention, but does it have enough to have people switching from MS Office? Flexbeta has the review.
I wonder how its performance compares to OOo on Windows and Linux, especially seeing as it’s an all-in-one executable (IIUC). Prolly nothing like GP either way though.
Yeah, I was dissappointed to hear that it was so slow. I think it would be possible to write a responsive office suite in Java. Even with the Swing GUI. It’s a matter of not having too much code run every time something is done.
OpenOffice is coded in C++ and it was pretty damn slow at first. Maybe later they will speed it up. But it’s dissappointing to see them deliver such an unusable product (from what I read in the review).
It would be possible to have a fast java office using something like SWT/JFace/RCP. Swing is going to be a memory hog, most likely be slow, and is going to look like crap even with Windows Look-n-Feel. I just tried IDEA 4.0 last night and unless there is some magic you can perform to get it to use your native fonts then it just looks like crap compared to Eclipse with cleartype enabled.
EI Office looks VERY promising. However I really dislike the fact that the presentation tool always seem to be the least developed since it’s ALSO very important. This is the area where OOo is light years behind MS Office for instance. Ei Office looks closer but probably has quite some time before it comes up to pace.
Another thing which EI OFfice will support (it’s said somewhere on their homepage) is SPSS syntax/scripts which would make their spreadsheet application more mean than I can ever imagine. When that happens I’ll be the first to buy the software =)
If it’s Javabased we might even see it available on OpenBeOS when it arrives as Java support is being worked on.
>It would be possible to have a fast java office using something like SWT/JFace/RCP.
SWT does not offer any advantage for a Word processor
or a Spreadsheet. With advanced controls like that, you’ll
end up developing the whole control yourself anyway, so
all your code for rendering and user input would be in
Java anyway.
You cannot use default controls for the wordprocessor (neither SWT nor Swing offers a TextEdit widget flexible
enough to compete with a word processor) nor for the
spreadsheet (the SWT Table implementation is particularly
poor; this has been a major gripe for some time; there
is a hack to solve this in Eclipse M8, but … well it’s
a hack).
Mind you: I use Eclipse every day, so I’m not bashing
Eclipse or SWT.
>Swing is going to be a memory hog, most likely be slow, and >is going to look like crap even with Windows Look-n-Feel. I >just tried IDEA 4.0 last night and unless there is some
Would you mind reading the article before talking nonsense?
Look at the screenshots: E!Office looks almost exactly like
the MS Office applications, the author of the article
remarks this on several occasions. How can the E!Office
application written in Swing look “like crap” if it looks
just like a native app?
> Yeah, I was dissappointed to hear that it was so slow.
Er… where in the article did you read that it was “so slow”?
The author just remarks occasional lags, that’s all. I really
don’t see how you get from that to thinking the application
is generally very slow.
i hope people can see the true power of java and swing on the desktop with this application. enough java bashing.
for those who have tried EIoffice and OpenOffice have you found EI any better at creating .DOC files with correct formatting?
OOo still has a long way to go for MS compatibility bullets, auto-numbering, auto-paragraphing and tabs.
“Yeah, I was dissappointed to hear that it was so slow. I think it would be possible to write a responsive office suite in Java. Even with the Swing GUI. It’s a matter of not having too much code run every time something is done.”
Well, for what it is worth without a boatload of memory to run it on java is inherently slow. This is not a troll, just from my experience. Java stays resident in memory, so anything less then 256MB even java applets on web pages take time to load compared to other types, so a full application in java that is responsive is hard for me to fathom.
Its a shame it uses Java 1.4.1 only. The Windows XP theme was added in 1.4.2 and that’s been shipping for about a year already. 1.4.2 also added some nice speed enhancements, most notably the use of SSE/SSE2 instructions though that probably wouldn’t help in an office suite.
What you’re describing will just result in slow startup times, and not in the lack of responsiveness. That is mainly due to the (arguably) over engineered Swing and poor programming practices.
> Java stays resident in memory, so anything less then 256MB
>even java applets on web pages take time to load compared to
>other types,
Er… I don’t get what you’re trying to say. What does “Java stays resident in memory” mean? And how does that have a
negative impact on responsiveness?
And the fact that Java applets may seem slow to load stems
from the fact that the JVM is launched when you start an
applet (unless you already started another applet), and then has to download the .jar file for the Applets code.
> so a full application in java that is responsive is hard for me to fathom.
http://www.eclipse.org
http://rssowl.sourceforge.net/
http://www.limewire.com/english/content/home.shtml
http://www.jedit.org/
Just to name a few (haven’t tried IntelliJ, but that’s
supposed to be pretty quick too from what I hear).
“Er… I don’t get what you’re trying to say. What does “Java stays resident in memory” mean? And how does that have a
negative impact on responsiveness?”
By that I basically mean that in my experience you need a lot of memory in the machine. Specifically more then the 128MB that is typical of a home machine, preferably over 256MB.
“And the fact that Java applets may seem slow to load stems
from the fact that the JVM is launched when you start an
applet (unless you already started another applet), and then has to download the .jar file for the Applets code.”
True enough for the load times.
“> so a full application in java that is responsive is hard for me to fathom.
http://www.eclipse.org
http://rssowl.sourceforge.net/
http://www.limewire.com/english/content/home.shtml
http://www.jedit.org/
Just to name a few (haven’t tried IntelliJ, but that’s
supposed to be pretty quick too from what I hear).”
I’ll give the first 2 a try. Limewire and jedit are very slow on my test system. That system has 128MB memory. I will say that on my system with 1GB Memory they run fast.
I cannot say that the performance reports surprise me one bit. Despite all the hype surrounding Java one simple fact remains.
Despite all the fancy words they have come up with like ‘virtualization’ the unescapable fact is that no matter how you look at it, Java is, to put it in the most “BASIC” terms, an INTERPRETER. Like Rom Basic before it there is no doubt it will always be painfully slow compared to an IDE. While ‘just in time’ compiling does make native code, it is handled on a case by case basis as the code is interpreted, not ahead of time for the whole application. While the constant compiling of routines just before running them may be faster than flat interpreting, there is no way it can EVER compete with a real compiler in the speed department.
End result, JVM will always be agonizingly slow compared to a true native executable. Virtualization, bah. Let’s call it what it REALLY is. I know why Sun called it that, because they wanted to avoid all the negative connotations that STILL APPLY to what Java really is: AN INTERPRETER.
That’s not to say it’s not a useful interpreter… But an office suite written in an interpreter? At that point why don’t I drag out my 386/40 and boot up Windows 3.11?
You can also try NeoOfficeJ, the Java version of OO. Runs quite smoothly on my powerbook. Despite all warnings that it still is in beta, etc. I do most of my work with it… and since I write stuff for a living (manuals, copy, etc.) you can take it for granted that I really use a wordprocessor.
I don’t think (and haven’t looked for it) NeoOffice includes the Lotus 1-2-3 thingy.
Despite all the fancy words they have come up with like ‘virtualization’ the unescapable fact is that no matter how you look at it, Java is, to put it in the most “BASIC” terms, an INTERPRETER. Like Rom Basic before it there is no doubt it will always be painfully slow compared to an IDE. While ‘just in time’ compiling does make native code, it is handled on a case by case basis as the code is interpreted, not ahead of time for the whole application. While the constant compiling of routines just before running them may be faster than flat interpreting, there is no way it can EVER compete with a real compiler in the speed department.
Obviously, you have no idea what you’re talking about. A JIT compiles everything into native code at startup. There is no interpreter there. What you’re describing is the HotSpot VM, which is an interpreter, but it profiles code at startup and optimizes the ‘hotspots’ (i.e. frequently executed code) into native code. After a while, it stops profiling code and just runs. That is why Java isn’t as slow as say BASIC/Python/Perl and the rest of the interpreted languages.
The HotSpot approach to compiling has benefits compared to traditional static compilers. It can *devirtualize* virtual function calls, which is something that static compilers can’t do without profile guided optimization.
From your post, its painfully obvious that you’ve got no clue as to what an IDE, JIT, or virtualization(???) is.
>Despite all the fancy words they have come up with like
>’virtualization’ the unescapable fact is that no matter how
>you look at it, Java is, to put it in the most “BASIC” terms,
>an INTERPRETER.
No, that’s a very antiquated view of Java (or .NET for
that matter, as it is alike in that aspect).
JIT Compilers compile the code *the first time* it is
used, not *each* time* it is used. So, after a slowish
startup, a Java VM with only a JIT (ie. before the Hotspot
dynamic compiler) will only execute native code (the
JIT compiles a method, and then updates the method tables
to link to the native code instead of the bytecode).
Modern JVMs are even more optimized, in that they solve
on problem of JITs: JITs don’t have enough time to properly
optimize code; a JVM with a dynamic compiler executes the
code in a slower manner (simple JIT or optimized interpreter)
at first, and then compiles the really used methods to
*highly* optimized native code (this removes a lot of
overhead, and features method inlining, devirtualization
among all the common, textbook optimizations).
If you are into compiler construction, think of Java
as this: the javac compiler (that turns Java source code
into Java Bytecode) is the Frontend of the compiler;
the JVM (with a dynamic compiler) is the backend of the
compiler. (Note: The Compiler frontend turns Source into
an intermediate code; the compiler backend turns this
intermediate code into native code. Retargetable Compilers
have used this for decades).
The advantage of having the backend on the computer where
the code is actually executed are manifold; of course,
the bytecode is independent of the CPUs code; besides that,
it also allows the backend to make optimizations that can
exploit the specific details of the CPU it is run on.
The Sun JVM for instance can use SSE instructions to speed
up code. Further optimization, like optimizing the code
for the available cache size, cache line lenght, … are
possible too (don’t know if these are used in production
JVMs yet).
The advantages are basically the same as with a source
based Linux distro: you get the source, and compile it
into native code that is always optimized for your CPU.
The optimizations might not be equal to what a recent
Intel compiler optimizer might churn out, but they’re
good enough.
As for the argument, that this compilation happens at
runtime: well, for a desktop app this doesn’t matter
anyway; look at your CPU monitor… the damn thing is
twiddling its thumbs all day long, there is no way to
use the whole power of a CPU. And I’m not talking about
a state of the art CPU; this has been the state of
affairs for 10-15 years now;
In conclusion: Desktop and Server JVMs are not interpreters
that handle each bytecode one by one; the bytecode is
simply a way to store the source in a quickly parseable
format, which is then turned into optimized native code
which is then executed.
A JIT compiles everything into native code at startup. There is no interpreter there.
While I fully agree the original poster is full of cr*p, I don’t think this is correct. Compiling everythnig at startup would do _very_bad_things_ with the startup time (which isn’t that great to start with) for large applications. Starting Eclipse takes long enough as it is… The description you gave of Hotspot is AFAIK the definition of a Just In Time compiler.
Well spotted. Which is why they no longer use a pure JIT, but have replaced it with the HotSpot VM 🙂 Murphee has given a very good explanation on the cons of a JIT and why HotSpot was created.
I think it’s not easy to write fast software, it depends on many things (language, libraries, program self etc.). OpenOffice and Mozilla are both coded in the fastest language (C++) and imho way to slow (especially startup and main menu) for frequent use (start more then once a day). The sad thing is hardware is getting faster but at the same time software is getting slower, Longhorn (.NET/Avalon) will be a resource hungry beast.
I disagree, for most programs the language and the libraries doesn’t matter much. IO is what makes programs slow, and waiting for IO is what makes programs _feel_ slow. Waiting for the harddisk, the soundcard, network traffic or just waiting for input from the user it what most programs spend most of their time at.
The reason why OOo or mozilla takes ages to start is because they are huge programs that takes a long time to read from the harddisk. Try this: start OOo, exit and start it again. Did you notice how much faster it was the second time? That’s because it was loaded from diskcache (memory), instead of from disk.
Of course, in seroius scientific number crunching applications it’s a different picture, but that’s not what we’re talking about here.
It’s an old rule of thumb that says “10% of your code runs 90% of the time.” And usually, those 10% of the code are IO related. You are only partially right about hardware getting faster. While the speed of CPUs are doubled each year, the speed of you harddisk isn’t. The speed of harddisks are almost as slow today as 10 years ago, so an application that was harddisk bound 10 years ago will be almost as slow today. It’s sad, but true…
you are right with IO is one of the big problems, many people don’t have the money for fast hardware, I’m pretty sure with enough money I could speed up my disk access twice or more, my drive is 5400, I thought I buy silent disk
If you want Intellij Idea fonts to look good, don’t forget to activate the option “use antialiazed fonts in editor” in the control panet, under “appearance”.
Howdy
It`s always funny to see the C/C++ fan boys come out and say “if only it was C/C++” but honestly being written in java is not going to be as bad as you think.
Sure Java might not currently be as fast as C/C++ in general but the complexity it allows you to acheive is really unsurpased and all this with out dangly pointers, memory leaks (ok these can still happen but not if you have more then 3 brain cells) etc, java is VERY good at hiding complexity that previously a C/C++ guru would of been the only one to acheive.
This is IMHO a great reason to use Java .. sure you want to run as fast as a processor will allow then use assembler .. you want HUGE complex apps that just work accross multiple platforms then use Java, horses for courses my friends :0)
that Mozilla and Open Office(which are written c++) are neither lightweight or quick at startup.
I don’t have a problem with the quickness of java, but I would like some of the vm vendors to start concentrating on reducing memory footprints. I think after 1.5 comes out, with all the new language enhancements, Sun and others can concentrate on optimizations.
I’m just happy that .NET is out there to give Java some competition, because it always seems that Sun likes to rest on their laurels if there isn’t any competition.
Ok, I have no clue why it says IDE, as it should read compiled executable… Brainfart… No, wait, my Notepad copy says .exe … What the?
As to hotspot, you may wish to read the actual description on it from sun’s website (http://java.sun.com/products/hotspot) or this press release on what it is (http://www.javaworld.com/javaworld/javaone99/j1-99-hotspot.html):
Adaptive optimization involves profiling the Java bytecode while it is running and picking out the “hot spots” that will offer the best performance improvements when optimized.
Ok, so while the bytecode is being INTERPRETED they are taking time out to profile the code to find sections that are better to JIT than others (which is funny, they are doing a JIT but not calling it that… HMM, this repeated coming up with new names for doing the SAME THING is getting tired fast). That overhead is STILL going to be slower than if you just wrote a blasted compiler for it in the first place and made a REAL executable! Is it faster than flat interpreting? Probably, considering they say roughly double the speed that puts it at what, still about a quarter the speed of a real native executable?
YOU are obviously the one who knows not what JIT is. “Just in time” means exactly that, it is compiled AS THE BYTECODE IS EXECUTED, not ahead of time. You may wish to read SUN’s WEBSITE on the subject (http://www.sun.com/software/solaris/jit) so you know what the blazes you are talking about, and can stop accusing others of same.
The Java source is NOT compiled ahead of time, no matter how you repack or add flavor to it, Java is an interpreter. Interpreters are slow. Anyone who tries to sell you any other line on that is full of manure. While a lot of techniques can reduce that speed gap, it can never be closed without biting the bullet and making the whole thing a real executable.
Oh, and Dolemite, C++ is NOT the fastest language, that’s Machine code.
Well said about the I/O bottlenecks by the way. In reality that is the weak point in most any computer today. In the lifespan of IDE from it’s orginal release back in ’93-94 to the ATA-133/SATA of today we have seen maximum throughput jump from a 16MB/sec to 133MB/sec (theoretical in both cases, about 80% that real-world), a jump of 16.5x. In that same space we have seen processors jump from 50-66mhz to over 3ghz, a jump of 45x (or more).
Just a little disparity.
to deathshadow:
You are misisng a lot of points.
1- Hot spot basically finds out the “hot spots” which are mostly common loops and frequent function calls (usually %10-20 of the application) and instead of interpreting the byte code it executes the native CPU command. i dont see you point here anyway.
2- JAva’s byte code interpreter cannot be compared with BASIC, or script language interpreters. it is more like converting one microprocessor opcode to another. it is very low level, therefore performance hit is usually very small, in nowadays systems, i say negligable. it is like the approach of transmeta processor in software. Honestly, in console applications java can keep up with C++ in many cases.
3- telling “C++ is not the fastest, it is machine language” is an incorrect statement. All the languages produces machine code at the end.
4- you are simply ignoring the fact that there is a very good office application entirely written in java and multi platform, which is comparable to latest MS Office and there is no concern about speed. Just because you dont know, or dont like java doesnt make that platform bad. Get over it . stop the fud and come with facts.. Virtual machine is the future.
.net takes up more resources than java anyway so, bleh
Ok, so while the bytecode is being INTERPRETED they are taking time out to profile the code to find sections that are better to JIT than others (which is funny, they are doing a JIT but not calling it that… HMM, this repeated coming up with new names for doing the SAME THING is getting tired fast). That overhead is STILL going to be slower than if you just wrote a blasted compiler for it in the first place and made a REAL executable! Is it faster than flat interpreting? Probably, considering they say roughly double the speed that puts it at what, still about a quarter the speed of a real native executable?
The difference between a JIT and the HotSpot VM is listed in the document that you’ve posted. Look at Chapter 4. You obviously read it, didn’t you? I made a snafu assuming that a JIT wouldn’t require an interpreter, but it does since it compiles the method the first time its run. That’s the only mistake in my post.
Now, you’re assuming that the profiling and interpretation is going to run all the time. It doesn’t. It runs only during a warm-up period. Plus, because its compiling at runtime, it gets information that wasn’t previously available so you ‘could’ get a more optimized program. That’s why Java is close to C and C++ in speed and sometimes surpasses it. http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
Also, a .exe file doesn’t necessarily mean its native. You can wrap a Java program in a .exe file and still require a VM. Heck, .NET produces executables but still requires the VM installed.
The Java source is NOT compiled ahead of time, no matter how you repack or add flavor to it, Java is an interpreter. Interpreters are slow. Anyone who tries to sell you any other line on that is full of manure. While a lot of techniques can reduce that speed gap, it can never be closed without biting the bullet and making the whole thing a real executable.
Got anything to back that up? Or you just talking from your behind? The Java source is compiled into bytecode. You can think of that as you .obj/.o files in a traditional compiled language. That’s why its different from a BASIC/Perl/Python interpreter. And there are benchmarks where Java beats C in numerical code. Fact is, if it were pure interpretation, it would be slow. But its not pure interpretation. Java stopped being purely interpreted in ’97 with the release of the JIT compilers.
There are ahead of time compilers for Java. See Excelsior JET. But, the speed improvements you get are negligeble. The standard server VM that ships with the Sun JDK is a lot faster than JET. The only areas where JET might win is in startup time and memory footprint.
Oh, and Dolemite, C++ is NOT the fastest language, that’s Machine code.
So you’re telling me you can write assembly or even machine code that’s going to beat the Intel C++ compiler? Compilers these days are getting advanced enough so much so that just writing in assembler or in *pure* machine code isn’t going to get you any benefit. But obviously, you already knew that.
it’s called anyware and it run fine…….
http://www.vistasource.com/page.php?id=7
by the way, the slowest apps I ever used are jedit and limewire….
I don’t know why java apps on linux suck so much, when I run them on windows or mac os X (limewire) it’s just fine.. maybe a little slower to launch….
Funny how people flip when MS tries to implement concepts previously invented –see latest longhorn article as an example– and yet noone cares about this clonework.
How many minutes of thought went into creating this program? Truely pathetic, and yet symptomatic some large opensource efforts (yes I know EIOffice isn’t opensource). If MS products are *so wrong*, why is so much effort invested in making copies of look and functionality.
There is of course a lot of awesome effort in the opensource world of doing things differently, and that’s where hope is found.
>How many minutes of thought went into creating this program? >Truely pathetic, and yet symptomatic some large opensource >efforts (yes I know EIOffice isn’t opensource). If MS
>products are *so wrong*, why is so much effort invested in
>making copies of look and functionality.
A few moments of thought before posting would have given
you the answer: E!Office is obviously trying to get
a part of MS marketshare for Office suites; it is far
easier to get ordinary users to use another product, if
the re-training effort isn’t too big.
No one said anything about innovation; this is just
business…
>YOU are obviously the one who knows not what JIT is. “Just in >time” means exactly that, it is compiled AS THE BYTECODE IS >EXECUTED, not ahead of time. You may wish to read SUN’s
>WEBSITE on the subject
>(http://www.sun.com/software/solaris/jit) so you know what
> the blazes you are talking about, and can stop accusing
>others of same.
Friend deathshadow: read the damn link and you’ll understand
that you’re wrong. It says (in the 2nd-to-last paragraph)
that the JIT really pays off, if the compiled method is
run more than once; Why? Because then it already is compiled
and will not be interpreted again.
It might also help to actually read some papers by people
who have actually implemented JVMs, before you talk out
of your ass; like about the Jikes RVM, which was *written*
in Java and performs about as fast as IBMs native JVM and
… you wouldn’t believe it: there is absolutely no
interpreter in sight; Jikes RVM always compiles code before
executing (then profiles the running code, and optimizes
it and replaces the JIT compiled code with the much faster
optimizied one).
But, read for yourself:
http://www-124.ibm.com/developerworks/oss/jikesrvm/info/pubs.shtml#…
“Oh, and Dolemite, C++ is NOT the fastest language, that’s Machine code.”
what’s this statement about? Do we talk here about languages appropriate for writing office suits or what?