|
|
MRJ Bug - Details updated May 4, 1998 at 08:00am |
|
id |
|
|
title |
Disappearing components in ScrollPane |
|
severity |
Really really bad "cosmetic" (user-interface) bug |
|
description |
When using a ScrollPane, I found that components disappear from the pane randomly if there are a lot of them. I couldn't find any hard facts on when this occurs. All I know is it didn't happen when there were only a few components in the pane. The components are there, but not visible to the user. The same code ran fine under Linux. Other users have reported similarly vague and intractable problems with ScrollPane. |
|
workaround |
Tell the user to scroll around and cover/uncover the window. All the components are still there, they just become invisible for a while. |
|
reported by |
Mark Fardal <fardal@weka.phast.umass.edu> |
|
# votes |
16 |
|
id |
|
|
title |
Consume() doesn't |
|
severity |
Major AWT bug |
|
description |
Consuming events doesn't work in at least one instance, where a key press is not swallowed properly in a TextField. This means on-the-fly text validation doesn't work. |
|
workaround |
Use exit validation of the text field instead. |
|
reported by |
Mark Fardal <fardal@weka.phast.umass.edu> |
|
# votes |
4 |
|
id |
|
|
title |
MRJ has a blocky cross hair cursor |
|
severity |
The cross hair cursor in MRJ is not suitable for drawing and painting programs. |
|
description |
MRJ's cross hair cursor is like the cursors used in spreadsheets but it's not like the ones used in all other JVMs and not like the ones llustrated n Java books. |
|
workaround |
none |
|
reported by |
Wayne Rasband <wayne@codon.nih.gov> |
|
# votes |
3 |
|
id |
|
|
title |
Swing performance is unacceptable |
|
severity |
|
|
description |
|
|
workaround |
|
|
reported by |
|
|
# votes |
41 |
|
id |
|
|
title |
readLine() is too stupid to handle CR-only lines properly over a network |
|
severity |
|
|
description |
Yup, this is the infamous CRLF network issue, that's appeared each week now on MRJ-dev for about 3 weeks in a row. I don't expect Apple to fix it (since a "fix" would actually go AGAINST the spec), but the very least they should do is write it up as a real FAQ, extracting elements of the countless postings I and others have made on this issue, and *PUT IT ON THE FAQ WEB PAGE*. Hell, it should be listed as THE MOST FAQ. Especially since everyone assumes it's the client (Mac), and it's really the server. And even more especially because the Mac is doing the right thing, but the user is telling it to do the wrong thing (do what I mean), and the stupid server-side readLine() is deeply complicitous in this misbehavior but "it works fine with W95 and Unix". If Forrest Gump's mother was right, "Stupid is as stupid does", I nominate readLine() for Most Stupidly Avoidable Programming Error, with a special Diverts Attention From Real Problem poison-oak-leaf cluster. And yes, "Java Examples in a Nutshell" really *DOES* make the huge blunder of saying and assuming that PrintWriter's or PrintStream's println() method works over the network. There are many examples that have this fundamental flaw. And most annoying of all, before JavaSoft added the platform-dependent "line-ending" property, THIS WORKED FINE IN JDK 1.0.2. Yet nowhere does JavaSoft say that the semantics of println() changed, nor offer any advice that this may be a problem, except the overly general and brief comments about line-endings in their flimsy "100% pure" cookbook, or guidebook, or whatever they call it. |
|
workaround |
Don't believe everything you read in a book, even an O'Reilly book. Just because "everybody does it" does NOT make it correct. Understand exactly what you're trying to accomplish first. Know whether a method will work for a use before you use it. Search the archives before asking a question. |
|
reported by |
Greg Guerin, glguerin@amug.org |
|
# votes |
15 |
|
id |
|
|
title |
postEvent seems to be called twice when a CheckboxMenuItem is selected |
|
severity |
|
|
description |
Attached is code for a small Application that I've run with JBindery. When the menu item is selected, the console shows "Hello!" twice when run under MRJ 2.0, once (as expected) under Metrowerks VM (CWPro2). import java.awt.*;
import java.applet.Applet;
public class MainClass extends Applet {
static Frame window;
public static void main(String args[]) {
window = new Frame("Checkbox Menu Item Test");
window.setSize(200, 200);
window.show();
Menu menu = new Menu("Menu");
menu.add(new MyMenuItem("Hello"));
MenuBar menuBar = new MenuBar();
menuBar.add(menu);
window.setMenuBar(menuBar);
}
}
public class MyMenuItem extends CheckboxMenuItem {
public MyMenuItem (String title) {
super(title);
}
public boolean postEvent(Event evt) {
if (evt.target instanceof MenuItem) {
System.out.println("Hello!");
}
return super.postEvent(evt);
}
}
|
|
workaround |
|
|
reported by |
Wayne Maddison, wmaddisn@U.Arizona.EDU |
|
# votes |
1 |
|
id |
|
|
title |
Windows and dialogs are resizable even though resize is turned off |
|
severity |
|
|
description |
Continuing the series of strange behaviors generated with David Geary's AWT book examples... The dialog generated by this applet should not be resizable, but it is. The Metrowerks VM also suffers from this problem. (Mark Fardal) related to my earlier report today...it turns out that Frame.setResizable() also doesn't work. But it seems closer to working than dialog.setResizable(). When the frame is popped up with the button, it has a grow box and can be resized, just like its parent frame. I told both of them to not be resizable so this seems erroneous. But if I close it and open it again, the grow box is missing and it can't be resized! The MW VM does exactly the same thing. (Mark Fardal) See: |
|
workaround |
It appears that order makes a significant difference in his piece of code. Switching the order of pack() and setResizable() seems to make it work. This is about setResizable not behaving correctly in MRJ. My solution has been to put setResizable(false) as the first method in my creator, before SetLayout() or anything. Seems to work reliably. (Bob Gonsalves), pinknoiz@ccnet.com |
|
reported by |
Mark Fardal <fardal@casa.colorado.edu> |
|
# votes |
9 |
|
id |
|
|
title |
Graphics:Grabbing pixels from off-screen bitmap only works in millions mode |
|
severity |
|
|
description |
When drawing into an offscreen image, which is the only way to draw into an image, and then using the PixelGrabber class to grabPixels(), from within Netscape the result will be nothing but ZEROS ('0'). This happens even after drawing the offscreen image onto the screen. |
|
workaround |
|
|
reported by |
John Hager, Julian Saunderson |
|
# votes |
4 |
|
id |
|
|
title |
Graphics.setXORMode color is being ignored, not producing the XOR color |
|
severity |
|
|
description |
I didn't know this, but if real it poses a VERY serious problem for me in some stuff I was planning to do in the near future. I'm not looking forward to having to work around this. |
|
workaround |
|
|
reported by |
Greg Guerin, glguerin@amug.org |
|
# votes |
2 |
|
id |
|
|
title |
setHelpMenu() does not work (can't add items to existing Help menu) |
|
severity |
Major AWT bug |
|
description |
You can't add items to the Mac Help menu. If you try, you instead get a second Help menu. Confirmed by many others. The standard Mac help menu is not accessible using MRJ. With MW Java, the following app (from Geary's "Graphic Java") works just fine. The help menu items go in the Mac help menu. But with MRJ, you get TWO help menus. You can't use Menubar.getHelpMenu() to avoid this either, because it will return null if you haven't set the help menu (thus acquiring the extra help menu). This bug has been known for a long time, and is periodically reported on mrj-dev. |
|
workaround |
none |
|
reported by |
Mark Fardal <fardal@weka.phast.umass.edu> |
|
# votes |
17 |
|
id |
|
|
title |
GC architecture flawed |
|
severity |
|
|
description |
The MRJ VM does not compact free VM memory and hand it back to the OS properly. Apple have allocated the following id in their bug tracking system - #2213113. Applications over time will chew up more and more memory and not hand it back to the O/S - this problem prevents prevents deployment in mnay situtations. |
|
workaround |
None |
|
reported by |
|
|
# votes |
20 |
|
id |
|
|
title |
ScrollPane and GridBagLayout bug |
|
severity |
|
|
description |
There are some extreme problems using ScrollPanes with GBL's. Basically it corrupts the entire layout. Apple has confirmed this as a bug - refer to Apple Bug ID #2214341 |
|
workaround |
We have had some success replacing ScrollPane with the ScrollingComponent class from the JDK 1.02 version of the Graphic Java Toolkit, which can be found on the CD accompanying the book "Graphic Java" by David M. Geary. (John Brewer) |
|
reported by |
|
|
# votes |
5 |
|
id |
|
|
title |
A frame does not show its menubar the first time it shows |
|
severity |
|
|
description |
Here's a major and long-known bug: menu bars attached to Frames can disappear. The best description I've seen is Wayne's here (posted to mrj-dev). Note this is really an app not an applet so run it with JBindery not the applet runner. I'm a new subscriber [to the MRJ-DEV mailing listserv] who's been flustered by the MRJ Menubar disappearance problem. I wanted to add some details (and my voice to the chorus of outcry). The Menubar disappears if the Frame to which it belongs is brought to the fore using show(), but not if it is brought to the fore using a mouse-click or by sending all other windows to the back using toBack(), then the Frame's menu bar is shown properly. I didn't notice code snippets in the archives about this issue, so in case it's useful code is appended. On startup the menu bar is missing (just "Help"), and selecting the menu item "Sister to Front" brings sister window to front but its menu bar is also missing. Touching from window to window succeeds in making the menu bar appear. Luckily, I don't need to have a product out the door soon, but this is a disastrous bug for any of us who have ambitions about serious applications programming in Java on the Mac. Would it be a "cosmetic" bug if the Finder's menus would periodically disappear to be recovered only by pushing a window to the background then clicking to bring it back to the fore? |
|
workaround |
Here is a solution I have come up with: Set up your menu bar, as you are doing now, in the constructor, but keep a private class variable to the menu bar (e.g. private MenuBar myMenuBar). Then, insert the following method into your Frame sub-class: public void show() {
super.show();
setMenuBar(myMenuBar);
}
Or: frame.setVisible(true);
frame.toBack();
frame.toFront();
|
|
reported by |
Wayne Maddison |
|
# votes |
19 |
|
id |
|
|
title |
MRJ crashes with high memory usage |
|
severity |
|
|
description |
I have found that MRJ does not handle high-memory usage applications well. In fact, it is easy to crash the whole machine when running one. I have a bug id assigned by Apple for this: 2227668. I sent Apple the Java code that illustrates this problem, so it should be fairly easy for them to track it down. I think there are several other bug ids assigned that are similar to this. |
|
workaround |
none |
|
reported by |
Ronald Guest <ronaldg@airmail.net> |
|
# votes |
17 |
|
id |
|
|
title |
MRJ crashes with high memory usage |
|
severity |
|
|
description |
calling Socket (remote_server_inetaddr, rem_port, local_client_inetaddr, local_port) always causes an OT error -3155 (kOTOutStateError). Steps to Reproduce: call the above function with local_port = 0 (in order to let the system choose a free port number).. Results: Stack trace: java.net.SocketException: OpenTransport error -3155; TEndpoint::Bind failed at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:286) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:129) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:115) at java.net.Socket.<init>(Socket.java:206) at java.net.Socket.<init>(Socket.java:147) |
|
workaround |
none |
|
reported by |
Giuliano Gavazzi <monk@humph.com> |
|
# votes |
2 |
|
id |
|
|
title |
DatagramSocket.receive() Doesn't Update |
|
severity |
|
|
description |
Well, I got a chance to do a little debugging and found the exact nature of the Datagram bugs in MRJ 2.0. Bottom line: if your code expects DatagramSocket.receive() to update the buffer you pass to 'new DatagramPacket', it will be broken under MRJ 2.0. This is an update to my rather uninformative claim that Datagrams are broken in MRJ 2.0. I now have some extra information about HOW they seem to be broken. My reference JVMs are MRJ 1.5 and SGI's latest 1.1.x JVM and the code is all Java 1.0.2. |
|
workaround |
A temporary workaround seemed to be using packet.getData(). Strangely, this routine returns a different array than 'buf' that _does_ contain the received packet. However, the returned array is HUGE! In this example, rarr.length is 65508. Since I think this array should be pointing back to (or a copy of) but, it's a little worrisome where this data is stored and makes me a bit nervous about using it. Note that packet.getLength() does return the correct length for the received network packet. |
|
reported by |
|
|
# votes |
2 |
|
id |
|
|
title |
Crashing With Type 3 Error |
|
severity |
|
|
description |
MRJ 2.0 final crashes with a Type 3 error while my Java program initializes. My Java application is Pure Java, no native code or weird stuff of any kind. It runs just fine on Windows (both Sun's JRE 1.1.5 and Symantic Cafe). The GUI is written in IFC 1.1. It performs some initializations and puts up two windows. MRJ crashes after the first and before the second window is displayed. Another version of my application (a server process with no GUI component) runs ok under MRJ with no crashing. The crash also leaves a file called "JMAllocñ4938" (different number each time it crashes) in my Trash, under a folder called "Recovered from MyHardDisk". |
|
workaround |
|
|
reported by |
|
|
# votes |
4 |
|
id |
|
|
title |
Popup trigger is unconventional |
|
severity |
|
|
description |
Java popup menus are not exactly broken with MRJ. However, they behave oddly enough that I consider their behavior to be a bug, or actually two bugs. The first problem is that the trigger for a popup is a Command+Control+click. This is NOT the usual popup trigger on a Mac. I only found this after a period of wondering why popups didn't work at all, and some developers even were unaware that a trigger existed. The second problem is that the popup behavior on a mouse release doesn't agree with the standard (well, since OS8.0!) behavior. On Mac, the popup should go away when you first PRESS (not click) and then release the mouse. It doesn't with the Java popup. |
|
workaround |
If you release a program that uses MRJ, inform users how to to trigger popup? Don't use popups at all? |
|
reported by |
Mark Fardal |
|
# votes |
1 |
|
id |
|
|
title |
(De/)Iconify doesn't generate events |
|
severity |
|
|
description |
A long-known bug in MRJ and in MW Java is that windowshading, which is the analogue of window iconification on the Mac, does not generate iconfify/deiconify events. Here's an instant demonstration. This was reported by several people on mrj-dev. |
|
workaround |
|
|
reported by |
Mark Fardal |
|
# votes |
1 |
|
id |
|
|
title |
Scrollbar maximum bug |
|
severity |
|
|
description |
There appears to be an off-by-one error in the java.awt.Scrollbar component, in both MRJ and MW Java. When you set a maximum value in a Scrollbar to n, the actual maximum value that's allowed appears to be n-1. This applies both to the constructor and and the set(Maximum, Value) methods below. This bug was reported by in the mrj-dev mailing list. |
|
workaround |
Don't depend on the value being returned as "n" for fully scrolled. (Mark Fardal) In fact, it's more than an "off-by-one" error. It's off by whatever amount you have set "visible" to. To get around this, I created a "hacked" scrollbar class that actually causes every Java platform to behave in the same way as MRJ (I could have just as easily done the opposite). If you are interested in the fix, please send me e-mail. (Jim Cushing) |
|
reported by |
Olga Medvedova |
|
# votes |
2 |
|
id |
|
|
title |
JBindery forgets memory allocations |
|
severity |
|
|
description |
The applications panel of JBindery allows for the specification of the minimum and maximum heap sizes; however, if you save the definition as an application, this information is lost. |
|
workaround |
|
|
reported by |
|
|
# votes |
2 |