It's an old and tiring camplain, but could people stop writing stuff
in Java, since all they obtain is to slow our PCs to a crawl???
so could the problem be the initial loading of the Java interpreter, or
some other Java-related initialization, and not just initializing the
window per se?
Then of course there's the issue of how else to handle this. One option
is to write everything in a platform-dependent way and avoid a
cross-platform tool such as Java entirely. But that has its
down-side,too: increased time to program it, higher cost,....
> It is just me, or the handling by Java of the new Function Navigator /
> Virtual Book is terrible? It needs a huge time to init the window, and
> its reponse time is awful, even worse than the Doc Center.
> It's an old and tiring camplain, but could people stop writing stuff
> in Java, since all they obtain is to slow our PCs to a crawl???
Murray Eisenberg mur...@math.umass.edu
Mathematics & Statistics Dept.
Lederle Graduate Research Tower phone 413 549-1020 (H)
University of Massachusetts 413 545-2859 (W)
710 North Pleasant Street fax 413 545-1801
Amherst, MA 01003-9305
I have made extensive use of J/Link in connection with my Super Widget
Package, and it is certainly not the case that Java is intrinsically
slow - in fact it is comparable in speed with C. Java is compiled to
P-code which used to be interpreted by the JVM. This made Java a slow
language, but those days are long gone, because nowadays the P-code is
compiled to native machine instructions just before it is executed, and
runs well. The J/Link-Mathematica connection also seems pretty fast, but
it obviously does involve interprocess communication, so it is important
to use as few calls as possible.
If the delays are not internet related, there might be excessive
Mathematica-Java communication at some point, or some sort of tricky
waiting situation between threads.
Certainly, I agree with your general sentiment - on my 2GHz machine, I
really can't see any reason why every documentation page should not
We have been seeing the Java timeout error a lot, on machines on campus
and at home. It started a few months ago, and the upgrade from 6.0.1 to
6.0.2 has not helped. If anything, I'm seeing the Java timeout more
frequently than before, even on two very speedy new machines where I was
rarely getting the Java error before. What happens much/most of the time
now is that when you start up Mathematica and go to execute a command,
Mathematica just hangs for a while. Eventually, after quite a long wait,
you get the first output, together with the Java timeout error.
*Usually* it's OK if you quit Mathematica and restart, or if you just
close up the error window and go on.
We have been in contact with Wolfram tech support about the problem, but
so far they have not had anything of help.
We seem to be seeing fewer timeout problems with the Documentation
Center in 6.0.2 than we were in 6.0.1, though I don't think that problem
has gone away completely. The Java error is quite aggravating.
University of Vermont
Murray Eisenberg ha scritto:
> My experience with the Documentation Center in 6.0 and 6.0.1 is that the
> first call to it is slow, but that after that things are faster at a
> given session.
> so could the problem be the initial loading of the Java interpreter, or
> some other Java-related initialization, and not just initializing the
> window per se?
> Then of course there's the issue of how else to handle this. One option
> is to write everything in a platform-dependent way and avoid a
> cross-platform tool such as Java entirely. But that has its
> down-side,too: increased time to program it, higher cost,....
I see of course the need to keep things simple when a project is
dealing with multiple platforms - although I imagine that a
development firm as big as Wolfram should be capable of handling it.
Yet this argument doesnt convince me that Java was a good answer: what
is more platform independent, for example, of a well written HTML
documentation? Or, simply, the use of Mathematica notebooks without
Java - as in the good old days?
No, the huge slowness that many people experience (not everybody, I
admit) is a faux pas.
Java can be better than in the old days, as David Bailey says, but it
still contains too many unresolved speed issues if 2GHz machines are
crawling when simply reading documentation.
What about an option to turn it off at least in the docs, losing some
I wonder if Mathematica is trying to update some component on startup.
Any internet access would probably occur via Java. In particular, have
you configured your Mathematica to pre-load any software?
As I said in another reply, the Java/J/Link system seems robust to me -
but maybe I have a lucky machine!
I do think it is unfortunate that the help system, that is so basic to
beginners, uses Java.
It seems unrelated to internet access. We have quite good connections at
the university, and we get the Java error there all the time. I have
dial-up at home, and I get the Java error regardless of whether I am
> I wonder if Mathematica is trying to update some component on startup.
> Any internet access would probably occur via Java. In particular, have
> you configured your Mathematica to pre-load any software?
Nope. But apparently Mathematica itself tries to load some Java stuff on
startup, hence the timeout errors.
I'd like very much to know what kind of Java code is needed right from
the start in the Doc center, and in particular in the Virtual Book and
the Function Navigator - since these last two are noticeably even
Helen Read ha scritto:
Note that Java is not used to actually display the documentation - it
appears in a notebook. HTML documentation would be greatly inferior
however, because you could not actually execute documentation cells
(possibly with changes).
I suspect WRI have bought in some Java search component that is too
inefficient - hopefully they will re-code it in a faster form, possibly
inside Mathematica, in C.
We are seeing this on many, many machines, some of which are quite new,
speedy dual cores. It happens with XP and Vista. It started happening
around the time we switched most of these machines from Norton
Anti-virus to NOD32, so we did initially suspect that NOD32 was
involved. It happens on machines that are still running Norton, though,
and WRI tech support insists it has nothing to do with NOD32.
Since you are seeing it on a variety of machines, and others such as
myself have never seen this problem, it almost has to be related to some
software that you have running on your machines.