RE: Java-based Client for Forte/IIOP

Question

We have deployed an application using JDK 1.1.6,
Swing 1.0.3, Visibroker 3.2, and Forte 3.0.G.2.
We are also using Forte's Java Interoperability
Service.
We have a closely-held client base (i.e. not a
million random yahoos off the internet), so we can
secure a Java port between client and server and
download a fairly significant client. The Java
client is deployed with Sun's JRE (to control the
environment) with the following configuration:
2.6 MB JRE
765 KB Forte.zip
2.0 MB swingall.jar
1.6 MB vbjtools.jar, vbjorb.jar
100 KB application classes
1) The Swing controls don't interoperate well
with the AWT and Symantec widgets, especially in
an internal frame. They paint slowly on top of
each other, move jerkily, and paint before moving
to the programmed coordinates so it looks silly.
100% Swing controls play well with other Swing
controls and are reasonably fast.
2) We used Symantec Cafe 2.5a to paint the
screens, and had some problems with the
setLayout(null) on things like the Swing tab
folder and split panel. Commenting out the line
fixed it, but I'm hoping Cafe 3.0 will fix it (I
have a person installing it but haven't gotten a
report...)
3) The initial search time to turn an IOR file
into a reference is an annoying 10 seconds, and
the first method call takes about 7 seconds, but
after that is less than a tenth of a second.
Haven't done any digging to find out why yet.
4) If we were deploying this as an applet, we
would probably use the IDL IIOP export--when using
the Java Interoperability service, any method call
seems to load the whole 765K across the
line...class by class. Ugly. IDL just gets what
it needs and is smaller.
5) Also, if deploying as an applet, we wouldn't
have to download the JRE or visibroker jar files,
and would only download the swing and Forte IDL
generated classes as needed, so it would be a much
smaller footprint than the 7MB above. (Note:
However, we would be at the mercy of the browser
being used by client.) Different strokes for
different folks...
-DFR
From: [email protected]
Date: Tue, 01 Dec 1998 15:15:18 -0800
Subject: RE: Java-based Client for Forte/IIOP
Sean,
My worry is that Swing, while eloquently designed,
represents an attempt to
write a totally new display system which, at least
in the case of my
project, will run on top of Windows. I really like
the Java (or a Java-like
i.e. J++) language, but I feel safer using the
native MS widgets. It does
not seem that anyone on this forum has used Swing
extensively and can
testify to its stability and performance.
Regards,
David
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Answer 1

We have deployed an application using JDK 1.1.6,
Swing 1.0.3, Visibroker 3.2, and Forte 3.0.G.2.
We are also using Forte's Java Interoperability
Service.
We have a closely-held client base (i.e. not a
million random yahoos off the internet), so we can
secure a Java port between client and server and
download a fairly significant client. The Java
client is deployed with Sun's JRE (to control the
environment) with the following configuration:
2.6 MB JRE
765 KB Forte.zip
2.0 MB swingall.jar
1.6 MB vbjtools.jar, vbjorb.jar
100 KB application classes
1) The Swing controls don't interoperate well
with the AWT and Symantec widgets, especially in
an internal frame. They paint slowly on top of
each other, move jerkily, and paint before moving
to the programmed coordinates so it looks silly.
100% Swing controls play well with other Swing
controls and are reasonably fast.
2) We used Symantec Cafe 2.5a to paint the
screens, and had some problems with the
setLayout(null) on things like the Swing tab
folder and split panel. Commenting out the line
fixed it, but I'm hoping Cafe 3.0 will fix it (I
have a person installing it but haven't gotten a
report...)
3) The initial search time to turn an IOR file
into a reference is an annoying 10 seconds, and
the first method call takes about 7 seconds, but
after that is less than a tenth of a second.
Haven't done any digging to find out why yet.
4) If we were deploying this as an applet, we
would probably use the IDL IIOP export--when using
the Java Interoperability service, any method call
seems to load the whole 765K across the
line...class by class. Ugly. IDL just gets what
it needs and is smaller.
5) Also, if deploying as an applet, we wouldn't
have to download the JRE or visibroker jar files,
and would only download the swing and Forte IDL
generated classes as needed, so it would be a much
smaller footprint than the 7MB above. (Note:
However, we would be at the mercy of the browser
being used by client.) Different strokes for
different folks...
-DFR
From: [email protected]
Date: Tue, 01 Dec 1998 15:15:18 -0800
Subject: RE: Java-based Client for Forte/IIOP
Sean,
My worry is that Swing, while eloquently designed,
represents an attempt to
write a totally new display system which, at least
in the case of my
project, will run on top of Windows. I really like
the Java (or a Java-like
i.e. J++) language, but I feel safer using the
native MS widgets. It does
not seem that anyone on this forum has used Swing
extensively and can
testify to its stability and performance.
Regards,
David
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>