Re: AWT-Bug in JDK1.1.6v2
All, I am 99% certain that this is the same bug that I reported as bug number 5 on the Java-Linux bug parade. In particular see my most recent comments towards the end re: Swing. It occurs for me when using mwm or dtwn on a remote (AIX) machine. I too saw this appear when JDK116 came out, I think because of the performance improvements that came with 116, and this is timing related. The bug is anumber 5 at http://www.blackdown.org/cgi-bin/jdk Rob Eu Hin Chua wrote: > On Tue, 4 Aug 1998, Kurt Huwig wrote: > > > The bug with Swing-Applications and Menu is still there; Menues overwrite the > > Menutitle until I move the whole window. This does not happen with 1.1.3, but > > happens with both kwm and twm. > > Hi, > > Just to confirm this, I can duplicate this bug when using kwm 1.0 and > WindowMaker when using jdk 1.1.6v2 glibc (Byrne). However, there is no > problem whatsover when I switched to jdk 1.1.5v7 glibc (Byrne). I have > tried this with Swing 1.02, 1.03 and 1.1-beta. > > regards, > > Eu Hin > > -- > "...bottom line, Dilbert teaches you that your computer is your > friend while Quake teaches you not to use your grenade launcher > in a small room." - www.bluesnews.com > > iiNet Technologies -- Rob Nugent Development Manager UniKix Technologies Europe [EMAIL PROTECTED] Tel: +44 (0) 1489 585503 Fax: +44 (0) 1489 881363
Re: AWT-Bug in JDK1.1.6v2
Kurt Huwig <[EMAIL PROTECTED]> writes:
> The bug with Swing-Applications and Menu is still there; Menues overwrite the
> Menutitle until I move the whole window. This does not happen with 1.1.3, but
> happens with both kwm and twm.
>
> Example (you need Swing 1.0.2 for this!):
> - --- cut here
> import com.sun.java.swing.*;
>
> class SwingBug extends JFrame {
> SwingBug() {
> JMenu m = new JMenu( "File" );
> m.add( new JMenuItem( "Open" ) );
> JMenuBar mb = new JMenuBar();
> mb.add( m );
> getContentPane().add( mb );
> setSize( 200, 100 );
> show();
> }
>
> public static void main( String argv[] ) {
> new SwingBug();
> }
> }
Yes, I can reproduce this bug with 1.1.6v2, but the recent sources don't
show the bug anymore. There are still problems with frames, I'm testing
a patch to make setIconImage work with KDE right now.
Jürgen
--
Juergen Kreileder, Universitaet Dortmund, Lehrstuhl Informatik V
Baroper Strasse 301, D-44221 Dortmund, Germany
Phone: ++49 231/755-5806, Fax: ++49 231/755-5802
RE: SwingSet demo does not go on JDK 1.1.6 v2 libc5
I tried the swing-1.0.2 demos with jdk1.1.6v2-libc and it seemed to work just fine. May be. its the probelem with Swing-1.0.1. Did you get any error messages ? Nishi > -Original Message- > From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, August 05, 1998 10:29 AM > To: [EMAIL PROTECTED] > Subject: SwingSet demo does not go on JDK 1.1.6 v2 libc5 > > I think this may be low priority, but worth looking into. > > After I installed JDK 1.1.6v2-libc.tar.gz with ld.so.1.9.9 > and I also installed the Swing-1.1beta.zip. > > So I said set SWING_HOME=/usr/local/swing1.1-beta and > let's run the SwingSet demo. It did not run. I manage to > load classes and terminate with no messages! Worrily > I went back to setting SWING_HOME=/usr/local/swing-1.0.1 > and tried the older SwingSet demo. The same result it did not > work. > > I thought the problem was the JDK so I ran some other Swing > demos. The other demos work as normal as before. Swing1.1beta > and the older Swing1.0.1 work with JDK 1.1.6 v2 libc5 > > Conclusion: > > SwingSet demo does NOT work at all, but any other test of applet e.g > the new JFileChooserDemo work wonderfully. > > > #include // Blankety Blank! >
Re: new VolanoMark benchmark scalability results
Hi, > Matthew Hunter wrote: > > > > http://www.javaworld.com/javaworld/jw-08-1998/jw-08-volanomark.html > > > > have JIT compilers. The Linux JDK doesn't by default, but you can plug > > TYA in and use it, which should give a significant performance increase, > > albeit not sufficient to catch up. An optimizing JIT might help even > Plus the give the specs of the client and server that they ran the tests > on. We could certainly plug in TYA and see if that makes a difference. > Any one got a couple of networked PPro's around that would do the testing? If they are using much ``synchronized'' methods TYA won't help too much. Cheers Albrecht
Updating/Painting
Howdie, Let me first begin to say that it's a great honour for me to finally be here. Anyway, I've got an application, a frame, a ScrollPane in the frame, a Panel in the frame, and these two are not normally updated when I add something to the panel. Any ideas? Have been lookin at setVisible, paint, paintAll, update, PaintEvent, Adjustment, etc, and it's just too weird for now. A final resizing of the window does result in an update of the said Panel. What paintmethod does the resizing stuff use? -- Maarten van Leunen Student - Fontys Institute of Technology Eindhoven e-mail: [EMAIL PROTECTED] http://www.il.fontys.nl/~maartenl http://lok.il.fontys.nl/
java crash at startup
I use a Redhat-5.1 system with glibc. I installed java 1.1.6 v2 (glibc2) When I start javac, I get the following error: No library path set. If I set LD_LIBRARY_PATH to /lib:/usr/lib (or whatever) I get: Failed to locate native library in path: /lib:/usr/lib (or whatever) Aborting. I included the output of ldconfig-D, and my environment. BTW: Until last week I used Redhat-4.1 with java 1.1.3 and never had any problems. Then I did rm -rf / and installed Redhat-5.1.. I probably did something stupid, so I'll apologize in advance, but I'd appreciate any help you can give me (or else I'll have to use Win95 :-( ). tommy -- Tom Huybrechts | [EMAIL PROTECTED] Student @ KULeuven | [EMAIL PROTECTED] -- ldconfig: version 970402 /usr/X11R6/lib: libXm.so.2 => libXm.so.2.0 libXm.so.1 => libXm.so.1.2 libXlt.so.0 => libXlt.so.0.1.0 libMrm.so.1 => libMrm.so.1.2 libforms.so.0.88 => libforms.so.0.88 libXpm.so.4 => libXpm.so.4.10 libXtst.so.6 => libXtst.so.6.1 libXt.so.6 => libXt.so.6.0 libXp.so.6 => libXp.so.6.2 libXmu.so.6 => libXmu.so.6.0 libXi.so.6 => libXi.so.6.0 libXext.so.6 => libXext.so.6.3 libXaw.so.6 => libXaw.so.6.1 libXIE.so.6 => libXIE.so.6.0 libX11.so.6 => libX11.so.6.1 libSM.so.6 => libSM.so.6.0 libPEX5.so.6 => libPEX5.so.6.0 libICE.so.6 => libICE.so.6.3 libXaw3d.so.6 => libXaw3d.so.6.1 libMagick.so.4 => libMagick.so.4.0.5 /opt/kde/lib: libuulib.so.0 => libuulib.so.0.0.0 libmimelib.so.1 => libmimelib.so.1.0.0 libjpeg.so.6 => libjpeg.so.6.0.1 libgif.so.3 => libgif.so.3.0.0 libgdbm.so.1 => libgdbm.so.1.7.3 libQwSpriteField.so.1 => libQwSpriteField.so.1.4.2 libmediatool.so.1 => libmediatool.so.1.0.0 libkhtmlw.so.1 => libkhtmlw.so.1.0.0 libkfm.so.1 => libkfm.so.1.0.0 libkfile.so.1 => libkfile.so.1.0.0 libkdeui.so.1 => libkdeui.so.1.0.0 libkdecore.so.1 => libkdecore.so.1.0.0 libjscript.so.0 => libjscript.so.0.0.90 /usr/lib: libkaffe_zip.so.0.100 => libkaffe_zip.so.0.100 libkaffe_net.so.0.100 => libkaffe_net.so.0.100 libkaffe_native.so.0.100 => libkaffe_native.so.0.100 libgimpui.so.1 => libgimpui.so.1.0.0 libgimp.so.1 => libgimp.so.1.0.0 libgck.so.1 => libgck.so.1.0.0 libqt.so.1 => libqt.so.1.40 libtk8.0.so => libtk8.0.so libtixsam4.1.8.0.so => libtixsam4.1.8.0.so libtix4.1.8.0.so => libtix4.1.8.0.so libtkx8.0.2.so => libtkx8.0.2.so libtclx8.0.2.so => libtclx8.0.2.so libtcl8.0.so => libtcl8.0.so libreadline.so.3 => libreadline.so.3.0 libhistory.so.3 => libhistory.so.3.0 libtiff.so.3 => libtiff.so.3.4 libstdc++.so.2.8 => libstdc++.so.2.8.0 libpng.so.2 => libpng.so.2.1.0 libjpeg.so.6 => libjpeg.so.6.0.1 librle.so.1 => librle.so.1.0.0 libppm.so.1 => libppm.so.1.0.0 libpnm.so.1 => libpnm.so.1.0.0 libpgm.so.1 => libpgm.so.1.0.0 libpbm.so.1 => libpbm.so.1.0.0 libfbm.so.1 => libfbm.so.1.0.0 libstdc++.so.2.7.2 => libstdc++.so.2.7.2.8 libg++.so.2.7.2 => libg++.so.2.7.2.8 libgdk_imlib.so.1 => libgdk_imlib.so.1.4.0 libImlib.so.1 => libImlib.so.1.4.0 libgtk.so.1 => libgtk.so.1.0.1 libgdk.so.1 => libgdk.so.1.0.1 libgpm.so.1 => libgpm.so.1.13 libzvt.so.0 => libzvt.so.0.0.0 libgtkxmhtml.so.0 => libgtkxmhtml.so.0.0.0 libgtktty.so.0 => libgtktty.so.0.0.4 libgnomeui.so.0 => libgnomeui.so.0.0.0 libgnomesupport.so.0 => libgnomesupport.so.0.0.0 libgnome.so.0 => libgnome.so.0.0.0 libglib.so.1 => libglib.so.1.0.1 libgif.so.3.0 => libgif.so.3.0 libgdbm.so.2 => libgdbm.so.2.0.0 libexpect5.24.so => libexpect5.24.so libcrack.so.2 => libcrack.so.2.7 libopcodes-2.9.1.0.4.so.0 => libopcodes-2.9.1.0.4.so.0.0.0 libbfd-2.9.1.0.4.so.0 => libbfd-2.9.1.0.4.so.0.0.0 libz.so.1 => libz.so.1.1.2 libpanel.so.4 => libpanel.so.4.2 libncurses.so.4 => libncurses.so.4.2 libmenu.so.4 => libmenu.so.4.2 libform.so.4 => libform.so.4.2 libnewt.so.0.20 => libnewt.so.0.25 libslang.so.0 => libslang.so.0.99.38 /lib: libproc.so.1.2.6 => libproc.so.1.2.6 libpam_misc.so.0 => libpam_misc.so.0.64 libpam.so.0 => libpam.so.0.64 libpwdb.so.0 => libpwdb.so.0.54 libdl.so.1 => libdl.so.1.9.5 ld-linux.so.1 => ld-linux.so.1.9.5 libuuid.so.1 => libuuid.so.1.1 libss.so.2 => libss.so.2.0 libext2fs.so.2 => libext2fs.so.2.3 libe2p.so.2 => libe2p.so.2.3 libcom_err.so.2 => libcom_err
something I forget in my previous mail (1 minute ago)
I also tried the libc version, but that didn't help either. tommy -- Tom Huybrechts | [EMAIL PROTECTED] Student @ KULeuven | [EMAIL PROTECTED] --
Small Business/Home Office Magazine At No Cost
We are pleased to offer you a free subscription to our electronic Small Office/Home Office magazine. To Subscribe click on the e-mail below and type subscribe in the subject or body of the message. This is a one time only mailing and therefore there is no need to unsubscribe. To subscribe click here [EMAIL PROTECTED] and type SUBSCRIBE.
java takes too much CPU time
Java application takes 10-20% of CPU time even with lot of 'sleep()'. On Solaris it takes less than 0.1%. Is that normal? Even a minimal application which only sleeps and sleeps and prints a message to stdout takes 1-2% of CPU time. Redhat 5.1, jdk1.1.6 Machine is a dual 233Mhz. -Heikki
Re: java takes too much CPU time
Heikki Suopanki wrote: > > Java application takes 10-20% of CPU time even with lot of 'sleep()'. > On Solaris it takes less than 0.1%. > Is that normal? > > Even a minimal application which only sleeps and sleeps and > prints a message to stdout takes 1-2% of CPU time. > > Redhat 5.1, jdk1.1.6 > Machine is a dual 233Mhz. > > -Heikki I'm currently working on a Sun Sparcstation 20. And I generally get a 5% CPU time from my Java Applications and Applets. After all, it's an interpreter. Especially during the creating of a LayoutManager, with lots of components (say for example, a long spreadsheet/or list of labels), it takes forever to get the screen to "calm down". -- Maarten van Leunen Student - Fontys Institute of Technology Eindhoven e-mail: [EMAIL PROTECTED] http://www.il.fontys.nl/~maartenl http://lok.il.fontys.nl/
Re: new VolanoMark benchmark scalability results
Matthew Hunter wrote: > > On Tue, 4 Aug 1998, Leo Cyr wrote: > > > Interesting article comparing Java VMs at > > > http://www.javaworld.com/javaworld/jw-08-1998/jw-08-volanomark.html > > The first thing to note about those tests is that most of the other JVMs > have JIT compilers. The Linux JDK doesn't by default, but you can plug > TYA in and use it, which should give a significant performance increase, > albeit not sufficient to catch up. An optimizing JIT might help even > more. Matthew makes a good point. Also, the Volano benchmark is downloadable for free from their website: http://www.volano.com/mark.html They give some details about it at http://www.volano.net/guide/mark.html Plus the give the specs of the client and server that they ran the tests on. We could certainly plug in TYA and see if that makes a difference. Any one got a couple of networked PPro's around that would do the testing? -- Scott Parish The Truth is out there. [EMAIL PROTECTED] John 14:6
Re: JDK 1.2
[EMAIL PROTECTED] wrote: > Do you have any plans about porting JDK 1.2 to Linux (i386)? Or are you > waiting for the final version? A preliminar work on the beta releases > would be fine, I think - then when the final version is out, OUR final > version won't delay a lot. Firstly I am not JDK source developer. I think the development JDK 1.2 will largely upto Sun. SunSoft only gives the native langauge source to someone it's trusts for instance, a person who has signed the NDA (non-disclosure agreement ). This constrasts with Linux Kernel for example, where anyone on the Net will ability and competence can participate in the development process. Consequently I think the development of JDK1.2 will always lag behind the Solaris version, unless SunSoft commits resources to permanent/contract 10xLinux developers. To just ask one trusted person to port code is nonsense. Anyway that's my two PENCE! #include // Blankety Blank!
SwingSet demo does not go on JDK 1.1.6 v2 libc5
I think this may be low priority, but worth looking into. After I installed JDK 1.1.6v2-libc.tar.gz with ld.so.1.9.9 and I also installed the Swing-1.1beta.zip. So I said set SWING_HOME=/usr/local/swing1.1-beta and let's run the SwingSet demo. It did not run. I manage to load classes and terminate with no messages! Worrily I went back to setting SWING_HOME=/usr/local/swing-1.0.1 and tried the older SwingSet demo. The same result it did not work. I thought the problem was the JDK so I ran some other Swing demos. The other demos work as normal as before. Swing1.1beta and the older Swing1.0.1 work with JDK 1.1.6 v2 libc5 Conclusion: SwingSet demo does NOT work at all, but any other test of applet e.g the new JFileChooserDemo work wonderfully. #include // Blankety Blank!
Re: RE: SwingSet demo does not go on JDK 1.1.6 v2 libc5
Nisha Kapoor wrote: > I tried the swing-1.0.2 demos with jdk1.1.6v2-libc and it seemed to work > just fine. May be. its the probelem with Swing-1.0.1. Did you get any > error messages ? > > Nishi > SwingSet demo did not work in Swing1.0.1 and SwingSet 1.1 Beta on my jdk1.1.6v5 libc5 copy. Previously Swing 1.0.1 SwingSet demo worked on the jdk1.1.3 version. Now that I have upgraded a lot of stuff it does not work. There were no errors messages available. I also looked at `/var/log/messages' and `/var/log/syslog' just to be sure. Strace revealed only that it was loading classes during the progress dialog which first appears. I tried patching `runnit' with `java -mx32M ...' thinking it might be a heap space problem, but that did not work either. I am not really bothered, because my Swing development application and the other Swing demo (in the 1.2beta ) work just fine. It's just FYI , baby bop > > -Original Message- > > From:[EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] > > I think this may be low priority, but worth looking into. > > > > After I installed JDK 1.1.6v2-libc.tar.gz with ld.so.1.9.9 > > and I also installed the Swing-1.1beta.zip. > > > > So I said set SWING_HOME=/usr/local/swing1.1-beta and > > let's run the SwingSet demo. It did not run. I manage to > > load classes and terminate with no messages! Worrily > > I went back to setting SWING_HOME=/usr/local/swing-1.0.1 > > and tried the older SwingSet demo. The same result it did not > > work. > > > > I thought the problem was the JDK so I ran some other Swing > > demos. The other demos work as normal as before. Swing1.1beta > > and the older Swing1.0.1 work with JDK 1.1.6 v2 libc5 > > > > Conclusion: > > > > SwingSet demo does NOT work at all, but any other test of applet e.g > > the new JFileChooserDemo work wonderfully. > > > > > > #include // Blankety Blank! > > #include // Blankety Blank!
TYA & RPM archives
Hi, Rick van Rein <[EMAIL PROTECTED]> was so kind to create some RPM archives for the current TYA release: http://www.cs.utwente.nl/~vanrein/linux/tya-1.0-1.src.rpm http://www.cs.utwente.nl/~vanrein/linux/tya-1.0-1.i386.rpm FYI: we have changed meanwhile the -O compiler switch from -O6 down to -O3. This is because some newer gcc seems to have trouble. For older gcc 2.7.2.1 for example there's no difference. Greetings, Albrecht
Re: new VolanoMark benchmark scalability results
Leo Cyr writes: > > Interesting article comparing Java VMs at > > http://www.javaworld.com/javaworld/jw-08-1998/jw-08-volanomark.html > Linux's results in these tests disturb me. I'd like to hear come > commentary from those who know the VM and Linux internals! These results do not disturb me nearly as much (i.e. not at all :) as the broken Invocation API does, due to the lack of native thread support. Linux performance be bad, Linux could still be a good development platform. But for my purposes, the JDK is useless. I suspect that any development of embedded Java (JVM used by legacy C/C++ app) or "impure" Java (native legacy code used) is not much fun on Linux. It sure as hell did not work out for me. Not only can I not deploy, I can't even develop with JDK. What kept me going is Japhar, but Japhar has quite a bit of catching up to do. Of course, the ones to blame are not the Linux JDK porting teams, but the suits at SMI. I suggest that everybody disturbed about Java on Linux should spend some time and effort testing Japhar. See www.hungry.com. b.
Bug in JDK 1.1.6
Hey, I am a developer at VertiSoft Inc, and I seem to have discovered a bug in your version of the linux JDK. The bug appears to be in the AWT listbox component. I am attaching the classes/source for a JDBC based application in a zip file. You will need to get the SolidDriver for java from www.solidtech.com and put it into your CLASSPATH. The bug is as follows: run the application by typing java GroupMaint. Then type LAC into the textfield at the top of the application. Press the "Faxnet Search button". Then double click on the name that appears in the listbox just below the textfield (this is my name). Following this, attempt to add TESTGROUP1 and the other groups by selecting it in the listbox on the left and then pressing the > button. This *should* add the group to the box on the right and remove it from the one on the left. This works on the windows JDK from Sun. This program is *far* from completion, so don't expect any other fuctions to work. I hope I am of help to you. also, you will need to be connected to the internet for this to work! Jonathan LaCour files.zip
write() bug under 2.1.x kernels...
Hi,
under the 2.1.x kernels, large write()'s to a socket never come
back if they block, unless I/O occurs on another socket. I've seen
this with 1.1.3 thru 1.1.6v2, with both the Steve Byrne and the Sergei
Nikitin ports under at least 2.1.65 and 2.1.114. The problem is VERY
reproducible and does not occur under the 2.0.x kernels.
Anyone care to comment on whether this is a java bug or a
kernel bug? I suspect jdk itself, since people have reported similar
(if not the same) bugs under Solaris, IRIX, etc. (Check bug parade.)
Under Solaris, sun's response was to tell people to upgrade from 5.4
to 5.5 ... under linux, it would be nice to not wind up having to tell
people to downgrade!
Attached is a little program to demonstrate the problem. It
runs for a while, and then gets stuck. The 1M buffer size makes sure it
gets stuck pretty quickly on my Pentium 66, but you can get the
problem using a buffer of 16k or less if you're patient. Oh, if you run this
under jdb, wait for it to get stuck, and hit return at the jdb prompt,
the write() will return and the program will run a little longer each
time you hit return.
I sure hope someone is reading these bug reports,
-Arup
import java.net.*;
import java.io.*;
public class WriteTest {
static final int bufsz = 1024 * 1024;
public static void main (String args[])
{
Socket s;
byte buf[] = new byte[bufsz];
for (int i = 0; i < bufsz; ++i)
buf[i] = (byte) (i % 256);
try {
s = new Socket ("localhost", 9);
OutputStream os = s.getOutputStream();
while (true) {
os.write(buf);
System.out.print (".");
System.out.flush();
}
} catch (Exception e) {
e.printStackTrace(System.err);
}
}
}
