[2768] in java-interest
Re: AWT behavior
daemon@ATHENA.MIT.EDU (ser@jersey.uoregon.edu)
Thu Oct 12 23:50:42 1995
From: ser@jersey.uoregon.edu
To: java-interest@java.sun.com
Date: Thu, 12 Oct 1995 18:54:30 -0700
------- Forwarded Message
> Yes there are some problems with layout. Specially if you are
> re-laying out containers that are already visible. We're still
> looking into it. The problem seems to be worse on Solaris 2.5.
Good, then I'm not just incompetent. ;-)
> Huh? If an applet works in the JDK, it will eventually work in
> Netscape.
That is not true at all. At least, not in the Netscape that was released a
day or two ago. In fact, didn't they just re-release Netscape 2.0 without
Java support? I know some of this is due to the security bug, but the version
which did include Java support crashed almost consistantly on Java apps. In
any case, I find it interesting that many demo apps were written under a
different paradigm than what is suggested. For example, the applet given with
the "Anatomy of a program with a graphical UI" has no start(), spawns itself,
and implicitly calls init() in a function called main(); it produces and
writes to it's own frame. I do not mind this, but I would like to know if
there has been a shift in the definition of "proper" construction of applets.
Which brings up another question about frames; I had thought that creating a
new frame would create a new window (external to the browser); what I see
happening is that if you create a frame from main(), that frame gets
incorperated into the browser window. In essence, your main() program is
taking the place of some hidden function that normally would take place in the
browser when your applet is loaded. Can I increase the stability of my
programs if I use this method for generating applets?
> I'm not sure why you think native code generation is part of the
> prebeta1 release.
I suppose because it was declared in the white paper as being an option. I
certainly didn't see anything which said that that feature was missing.
Further, I assumed that the feature existed because the white paper
practically said that it did:
"In interpreted code we're getting about 300,000 method calls per second on
an Sun Microsystems SPARCStation 10. The performance of bytcodes converted to
machine code is almost indistinguishable from native C or C++."
Since we're here, I'd like to ask if the decision not to have dynamically
referenced objects was an oversight or deliberate. Let me give an example
(I'm being liberal with the syntax, as I'm entering this on-the-fly):
class point {
public int x;
public point(int g) { x=g; }
public boolean eq(point p) { return x==p.x; }
}
class colorpoint extends point {
public int c;
public colorpoint(int g, int f) {
super(g); c=f; }
public boolean eq(colorpoint cp) {
if (x==cp.x) return ci==cp.c;
return false; }
}
class test {
static final void main(String args[]) {
point p;
colorpoint r = new colorpoint(1, 2);
p=r;
/* Here's the funny part ******************************8*/
p.equal(r); // calls point.equal, not colorpoint.equal
System.out.println(String.newInstance(p==q));
}
}
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
