Problem with delay at Javascript start

[Rene Grothmann]

I have managed to communicate between forms and Java applets. A button
press sends the content of the text area to an applet, a second button
gets some text from the applet and puts it into the textarea.

However, at the start, there is a delay of several seconds, before any
of the buttons react to a click. After the first reaction has happened,
all further clicks work immediately.

Is this meant to be so, or can I speed up the first event handler a bit?

[Thomas 'PointedEars' Lahn]

Rene Grothmann wrote:

I have managed to communicate between forms and Java applets. A button
press sends the content of the text area to an applet, a second button
gets some text from the applet and puts it into the textarea.

However, at the start, there is a delay of several seconds, before any
of the buttons react to a click. After the first reaction has happened,
all further clicks work immediately.
Maybe the user agent is just busy loading the JVM or the JVM is busy loading
the applet?
Is this meant to be so, or can I speed up the first event handler a bit?

In that case, no. In fact, you should avoid using Java applets.
PointedEars

[Rene Grothmann]

No, the applet has long started and is running perfectly. If anything
is slowly starting, it is Javascript, or at least it's connection to
Java.

In fact, you should avoid using Java applets.

You must be kidding. You don't know what I use applets for. The advise
is not appropriate, nor is it feasible.

[Thomas 'PointedEars' Lahn]

Rene Grothmann wrote:

No, the applet has long started and is running perfectly. If anything
is slowly starting, it is Javascript, or at least it's connection to
Java.
Then you should post some code.

In fact, you should avoid using Java applets.

You must be kidding. You don't know what I use applets for.

Which is why I did say "should avoid using" and not "should not use".
The advise is not appropriate,
It is. Using Java applets has profound negative impact on load and
system performance, and another plugin is required for them to work.
nor is it feasible.

That depends on the application, of course. I did not debate that.
PointedEars

[VK]

Rene Grothmann wrote:

I have managed to communicate between forms and Java applets. A button
press sends the content of the text area to an applet, a second button
gets some text from the applet and puts it into the textarea.

However, at the start, there is a delay of several seconds, before any
of the buttons react to a click. After the first reaction has happened,
all further clicks work immediately.

Is this meant to be so, or can I speed up the first event handler a bit?

While DOM parsing goes relatively quickly, the initial JVM launch takes
much longer (depending on the complexity of your applet and on the
amout of custom classes to load / total .jar size if you use .jar)

If you went so far that you can communicate DOM<>Applet, then have
relevant buttons on the page as disabled="true" and extend init{}
method in applet to enable these buttons.

[Rene Grothmann]

Since you obviously do not believe me, that the JVM has nothing to do
with it, go to the following page:

http://www.rene-grothmann.de/Test/Scripting.html

Wait until the applet has started, wait longer, wait still longer, then
press "Get". On my system, you get a 6 second delay, before there is
any reaction. After the first time, everything goes quicker.

[Andrew Poulos]

Rene Grothmann wrote:

Since you obviously do not believe me, that the JVM has nothing to do
with it, go to the following page:

http://www.rene-grothmann.de/Test/Scripting.html

Wait until the applet has started, wait longer, wait still longer, then
press "Get". On my system, you get a 6 second delay, before there is
any reaction. After the first time, everything goes quicker.

I get a near instant response every time.

Andrew Poulos

[VK]

Rene Grothmann wrote:

Since you obviously do not believe me that the JVM has nothing to do
with it, go to the following page:

http://www.rene-grothmann.de/Test/Scripting.html

Wait until the applet has started, wait longer, wait still longer, then
press "Get". On my system, you get a 6 second delay, before there is
any reaction. After the first time, everything goes quicker.

Yes, because the first time JVM has to be fully initialized wich is a
rather long process. After that everything goes quicklier. As JVM
initialization is an expensive process, system usually doesn't dismiss
JVM right after page unload but keeps it for another few minutes (in
case if it's needed again).

Games to play:
1) Restart your computer and open the page with applet. Ovserve your
delay.
2) After delay disappears, close the window, count to three and open it
again. Observe that there is no delay (JVM has been kept for you).
3) Close the window and go take a cup of caffee. Come back and observe
the delay (system got tired to wait and dismissed JVM).

This is why on Java-applet-intensive sites (almost no left, but in the
past) one usually has an applet on every single page to keep JVM
running. If some page doesn't need an applet, you still insert 10px x
10px (minimum allowed size) "JVM holder" applet, wich simply renders
background in the page background color. This ensures that JVM will be
initialized only once per site visit.

Nothing to do with JavaScript though.

[Rene Grothmann]

Thanks Andrew. So maybe it is my Firefox and its JavaScript
implementation. I checked in other Browsers (IE) and the delay is
almost non-existent.

[Thomas 'PointedEars' Lahn]

Rene Grothmann wrote:

Thanks Andrew. So
So?

<URL:http://jibbering.com/faq/faq_notes/pots1.html#ps1Post>
<URL:http://www.safalra.com/special/googlegroupsreply/>
maybe it is my Firefox and its JavaScript implementation.
Certainly not; you have to distinguish between the (ECMAScript)
language implementation and the AOM/DOM that can be accessed with it.

Probably the problem is caused by Mozilla/5.0 rv:0.9.4.1+ and its
Netscape plugin support implementation as I observe the same delay
here in

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8)
Gecko/20060110 Debian/1.5.dfsg-4 Firefox/1.5 Mnenhy/0.7.3.0

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051007
Debian/1.7.12-1

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805
Netscape/7.2

and

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
Netscape6/6.2.3

but not in

Opera/8.51 (X11; Linux i686; U; en)

using the same plugin version each time, Java(TM) Plug-in 1.4.2_05-b04.

That delay occurs in Mozilla/5.0 only if the JVM has not been started
before by either browser; not on uncached reload, for example. (Once
running, here the process java_vm is not terminated/killed before the
respective browser process [group] is terminated/killed.)
Regarding <URL:http://www.rene-grothmann.de/Test/Scripting.html>:
<html>
The DOCTYPE declaration is missing. <URL:http://validator.w3.org/>
<head>
<title>Test</title>
<script language="JavaScript">
Should be

<script type="text/javascript">

See numerous previous discussions here.
function get ()
`get' is potentially harmful as _JavaScript_ identifier since there is the
`get' keyword to define a getter:

<URL:http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Def ining_Getters_and_Setters>
{ document.form.text.value=document.zirkel.getString ();
}

</script>
</head>

<body>
With the recommended changes above and below, it should be at least

<meta http-equiv="Content-Script-Type" content="text/javascript">
<script type="text/javascript">
function getValue(oInput)
{
if (getValue.o && oInput)
{
oInput.form.elements['text'].value = getValue.o.getString();
}
}
</script>
</head>

<body onload="getValue.o = document.getElementById('zirkel');">
<h1>JavaScript Delay Problem</h1>
<p align="center">
<APPLET name="zirkel"
CODE="Test.class" WIDTH="200"
HEIGHT="100">
Should be at least

<applet id="zirkel" code="Test.class" width="200" height="100"></applet>

See also
<URL:http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/using_tags.html>
(Take into account that the scripts used there are not to be recommended as
they are.)
</p>

<p align="left">
`align="left"' is the default for this element and left-to-right text, and
therefore unnecessary to set here.

<URL:http://www.w3.org/TR/html4/present/graphics.html#adef-align>
[...]
<form name="form" onSubmit="return false;">
The `action' attribute is missing.

<URL:http://www.w3.org/TR/html4/interact/forms.html#h-17.3>

Following the recommendations above and below, the `name' attribute will no
longer be necessary to be set.
<p align="center">
Better than `<center>', but stylesheets should be used for presentation, not
markup. See the URI above.
<button onClick="get()">Get</button>

The same can be achieved more compatible and without annoying users without
client-side script support

<script type="text/javascript">
document.write('<input type="button"'
+ ' onclick="getValue(this);" value="Get">');
</script>
HTH

PointedEars

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

With the recommended changes above and below, it should be at least

[...]
<body onload="getValue.o = document.getElementById('zirkel');">

I forgot about the shortcut reference (hence the "at least" ;-)):

<body
onload="getValue.o = document.applets && document.applets['zirkel'];">

See also:

<URL:http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-26809268>
PointedEars

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 1/17/2006 9:31 AM:

<snip>

Regarding <URL:http://www.rene-grothmann.de/Test/Scripting.html>:

<html>

The DOCTYPE declaration is missing. <URL:http://validator.w3.org/>

<head>
<title>Test</title>
<script language="JavaScript">

Should be

<script type="text/javascript">

See numerous previous discussions here.

Are you, by chance, referring to the previous discussions where it has
been pointed out to you, repeatedly, to practice what you preach?

<URL:
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/a345ec6a6b028733/3445007d9f9310ed?q=Gerard+Talbot+&rnum=1#3445007d9 f9310ed>
<URL:
http://groups.google.com/group/comp....a1ac5bbb5ae252

Is but two where your hypocritical behavior has been pointed out to you.
Mow your own grass before bitching about the neighbors.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Rene Grothmann]

Thanks Andrew for your education on newsgroup and javscript style.
Note, that the link is only a test page I quickly put up for
you.Nothing you said about Javascript solve the problem, however.

[Randy Webb]

Rene Grothmann said the following on 1/18/2006 1:39 AM:

Please quote what you are replying to.

If you want to post a followup via groups.google.com, don't use the
"Reply" link at the bottom of the article. Click on "show options" at
the top of the article, then click on the "Reply" at the bottom of the
article headers.

Thanks Andrew for your education on newsgroup and javscript style.
Don't pay much attention to Thomas.
Note, that the link is only a test page I quickly put up for
you.

He doesn't understand that concept. But, it should be a priority to
provide a valid document for review as it can make a difference in some
cases when you are trying to solve a JS problem.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Thomas 'PointedEars' Lahn]

Rene Grothmann wrote:

Thanks Andrew for your education on newsgroup and javscript style. ^^^^^^
My name is _Thomas_, and you did not follow any of my recommendations
as again you quoted _nothing_ from the precursor, you not even mentioned
its author using an attribution line.
Note, that the link is only a test page I quickly put up for
you.
Sure, however test cases that are this broken are not supposed
to provide a viable test _result_. Scripts operating from within
and on not Valid markup are inherently unreliable, for example.
Nothing you said about Javascript solve the problem, however.

Scripts can seldom solve problems that are introduced by the UA.

As for one of my recommendations, I stand corrected: It appears that
obtaining a reference to an HTMLAppletElement object once and using it
later is _not_ regarded as a reference to the applet object in Firefox
1.5's Gecko DOM (if you try that, you get something similar to
"getValue.o.getString is not a function".) In fact, it appears that
any previous reference to the HTMLAppletElement object before the applet
object is loaded, breaks the later applet object property/method access.

This is probably the reason why the initial delay occurs: the reference to
the applet object has to be obtained once through XPConnect, which appears
to require some time for initialization.

<URL:http://developer.mozilla.org/en/docs/XPConnect>

There is no workaround I am currently aware of since the `onload'
attribute/property does not apply to the HTMLAppletElement object,
not even in Quirks Mode.
PointedEars