Re: lifeless javac with RedHat 5.0 JDK1.1.6v5
Jason Chambers wrote (well, quoted): > If I create a test.java file and then invoke "javac test.java", nothing > happens. I just get a command prompt back. No test.class file is > created, no errors, no messages, nothing. A few weeks ago, when I decided to start using Java, I downloaded the JDK (version 1.1.6v4a) and installed it on my Red Hat 5.0 system. I had this exact problem. A further problem was that most other Java programs would cause the java runtime to segfault. I fought with it for a while (being the type of person who exhausts all possibilities before asking for help). Eventually, I ran across this section in the README.linux file: Generally, you should get the glibc version if your machine is running glibc, but libc5 should work acceptably as well, if you have a recent (say, past April 1, 1998) version of the glibc library installed on your machine (RedHat 5.0 by default comes with an older version of glibc, you need to get the 2.0.7-7 version from RedHat to win). Even though this text referred to a different case than my setup (it talks of running the libc5 version of JDK, not the glibc version), I decided to try upgrading my C libraries to see if it would help. So I downloaded the latest glibc update packages from ftp.redhat.com (glibc-2.0.7-19) and installed them. Once I did that, the JDK worked flawlessly. Can we get an official answer from someone on the porting team to the following questions: 1. Should the latest version of the JDK for glibc work on a stock Red Hat Linux 5.0 machine? It would appear the answer to this is "no", since I and others have had problems. 2. If the answer to #1 is "no", is the recommended solution to update the glibc package on your system? While this was the solution I found, the previous poster noted that some people would rather not make such a drastic change to their system unless absolutely necessary. 3. If the user does not wish to upgrade their C library, is there a workaround (I've seen talk of doing stuff with the C libraries in the green_threads directory, but didn't try it since I had already solved the problem). Or, is the Red Hat 5.0 glibc package sufficiently broken that the only solution is to upgrade? 4. Once official answers to these questions are determined, I think they should be explained clearly in README.linux. I looked at the v5 version of this file, and no new information on this subject was added since v4a, when I fought with the problem. Thanks in advance (and keep up the good work!). -Jim Burmeister, Metro Link Incorporated <[EMAIL PROTECTED]>
Re: Working Button mnemonics under Linux Java?
Eu Hin Chua <[EMAIL PROTECTED]> wrote:
> Has anyone ever managed to get keyboard mnemonics working for JButtons
> using Swing?
>
> e.g.
>
> OKButton.setMnemonic('o');
>
> Under windows 95/8/NT, all of my code (including the SwingSet demo)
> performs as expected, with the ALT key being used to activate the mnemonic
> for both buttons and menu items. Under Linux, nothing happens at all.
Swing button mnemonics work just fine for me, both in standalone buttons
and menus. I've used them in my own code, and I also just checked the
SwingSet demo and it works OK too. I did nothing special to set them up;
pressing Alt+key has always just worked.
Here's my setup:
Red Hat Linux 5.0 w/upgraded glibc libraries
Blackdown JDK 1.1.6v4a
Swing 1.0.3
Metro-X 4.3 X server
Chances are, the problem is not with the JDK; it's with the way you have your
X server configured. Are you able to use the Alt key in other X applications?
Check your .xinitrc or .xsession script for "xmodmap" commands; if you've used
xmodmap to reconfigure your keyboard, the Alt keys might be generating keysyms
other than what the JDK is expecting. You can use the "xev" program to see
whay keysyms your Alt keys are generating; here's what the output looks like
on my system, for the left and right Alt keys respectively. The keysym on
the third line is what's important: it should be "Alt_L" and "Alt_R".
KeyPress event, serial 23, synthetic NO, window 0x441,
root 0x26, subw 0x0, time 2229881684, (-6,-24), root:(720,883),
state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
KeyPress event, serial 23, synthetic NO, window 0x441,
root 0x26, subw 0x0, time 2229886534, (-6,-24), root:(720,883),
state 0x0, keycode 113 (keysym 0xffea, Alt_R), same_screen YES,
Another thing to try is displaying your program on a different X display, if
one is available on your network. If the problem goes away, then you know
it's something to do with your X server.
-Jim Burmeister, Metro Link Incorporated <[EMAIL PROTECTED]>
