[2281] in java-interest
java-interest-digest V1 #187
daemon@ATHENA.MIT.EDU (owner-java-interest-digest@java.su)
Wed Sep 27 21:51:28 1995
From: owner-java-interest-digest@java.sun.com
Date: Mon, 25 Sep 1995 23:30:10 -0700
To: java-interest-digest@java.sun.com
Reply-To: java-interest@java.sun.com
java-interest-digest Tuesday, 26 September 1995 Volume 01 : Number 187
In this issue:
host handles & the like
Re: AWT instance variables
Re: thread.sleep and java.lang.InterruptedException
Re: AWT instance variables
Re: throws declataration in Java/beta
Re: Fixed coordinate placement of components
simple
Re: is *anyone* doing beta1 code?
Re: Java as developers tool
simple thread examples needed
Re: Q's on File access API's in Pre-Beta
Re: mo betta questions
Re: Fn ptrs & ... callbacks!?
Netscape 2.0a2
Help with java application User Interface
Re: GC and Class management
Painting on the Background
----------------------------------------------------------------------
From: Mike Klein <mklein@ossi.com>
Date: Mon, 25 Sep 1995 17:29:54 -0700
Subject: host handles & the like
This is my nth time posting this question so I don't have any grandious
dreams of it being answered, but here goes anyways...
#1 - I need access to host window handles! The NT source release doesn't
come with key source files for the runtime, making host handle extraction
from a WINDOW object impossible. The raw HWND/HANDLE is needed because the
release of AWT I am using doesn't support Z-Ordering of window planes, and
RE-Parenting of windows, two things pretty key for drag&drop and windowing
in general.
#2 - I need access to a .LIB file or .DLL from NT so I can finish my perform
method. I need these files so I can statically/dynamically bind to
java_execute_constructor and java_execute_method.
These problems are holding up key functionality and currently require klugy
workarounds. Please answer these questions (even with a no!)
MikeKlein...
------------------------------
From: egrossma@ncsa.uiuc.edu (Ed Grossman)
Date: Mon, 25 Sep 1995 20:16:49 -0500
Subject: Re: AWT instance variables
Arthur,
I can hardly believe that you are arguing that I should not be allowed to
provide such obviously useful items as a menu sorted by command name or an
object that, because of special knowledge of the structure in which it
existed, didn't need to use the standard "add" interface (along with the
accompanying update overhead) to set its own parent.
You claim this would "break" AWT. Perhaps this is the where we
misunderstand each other. I don't really see how adding subclasses could
break AWT; certainly the subclasses would not work properly unless they
were careful to clean up any messes they made by not following the standard
interfaces, but AWT itself and the classes comprising it would still be
inviolate, and any code using only AWT classes would work as advertised.
In object-oriented programming, there is always a tension between reuse and
encapsulation. The more that the internals are hidden, the harder it is to
make modifications to an object that were not foreseen by the original
developer. This is one reason the protected access specifier was created,
so that an object coudl present a completely encapsulated interface to
other classes while providing a less restricted interface to its own
subclass. By more or less ignoring the protected access specifier, you
have chosen to stay almost completely on the encapsulation side of the
spectrum, and by doing so, you make it almost impossible for any other
developers to extend the toolkit via inheritance.
In fact, it's clear that even the class hierarchy that your own toolkit
provides could not exist if it weren't for the odd default state that in
C++ terms, makes every class in the AWT package a friend of every other.
Look at the Container, which would not even be able to set the parents of
its children if it weren't for this feature.
In conclusion, I'd like to point out that if you expect the AWT to be used
for anything other than applet development, it will need to be extensible.
Any major project written in AWT will need additional user interface
components. Object-oriented toolkits generally allow extension in two ways
- - inheritance and composition. By providing such a limited interface to
subclasses, you have effectively removed inheritance as an option. I urge
you to look at the class hierarchy provided by other object-oriented
toolkits, find a few classes that are related to ones in the AWT, but
somewhat different (so that it is natural to consider implementing them via
inheritance) and then determine whether you could in fact implement them
given the public AWT interface. I've already given you several examples.
Yours Truly,
Ed Grossman
NCSA
At 12:46 PM 9/25/95, Arthur van Hoff wrote:
>Hi Ed,
>
>> Here is a list of things that I, as a class designer, might want a subclass
>> of an AWT object to do, which cannot be done within the current framework
>> unless the new objects are part of the AWT package.
>>
>> 1) As a descendant of Component, set my parent directly. In fact, even the
>> "add" method of the Container object would not work if it were not in the
>> same package as Component.
>>
>> 2) As a descendant of Menu, change the order of my Menu items, or choose to
>> add a new item anyplace but the end of the menu.
>>
>> 3) As a descendant of Container, sort my children in place.
>
>Any of these operations would break the AWT if you would do them by
>directly accessing the instance variables. I'm glad we stopped you!
>
>> 4) As a descendant of FlowLayout, change my alignment.
>
>The fact that the layout objects have private variables is broken.
>I'll fix that.
>
>> I'm sure I could come up with more. Note that these are all things an
>> object would want to do to itself, not things it would allow other objects
>> to do. The way AWT is written, subclasses as a rule do not have any more
>> privileged access to their ancestors' instance variables (which could
>> really be thought of as their own instance variables) than any other class,
>> thus making AWT extremely difficult to extend.
>
>I disagree. It makes the AWT safer.
>
>> I'd like to know if this state of affairs is going to continue in future
>> releases.
>
>Absolutely!
>
>Have fun,
>
> Arthur van Hoff
------------------------------
From: Arthur van Hoff <Arthur.Vanhoff@Eng.Sun.COM>
Date: Mon, 25 Sep 1995 13:57:19 -0800 (PDT)
Subject: Re: thread.sleep and java.lang.InterruptedException
Hi Jon,
> You have to put a bogus try/catch around your code which uses
> Thread.sleep in order to make the compiler happy.
The try/catch is not bogus.
Have fun,
Arthur van Hoff
------------------------------
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
Date: Mon, 25 Sep 1995 18:53:34 -0800 (PDT)
Subject: Re: AWT instance variables
Hi Ed,
> I can hardly believe that you are arguing that I should not be allowed to
> provide such obviously useful items as a menu sorted by command name or an
> object that, because of special knowledge of the structure in which it
> existed, didn't need to use the standard "add" interface (along with the
> accompanying update overhead) to set its own parent.
The awt components have a platform depended counter part called their peer
components. These correspond to Motif components on Unix and actual Win32
components on the PC. If you were allowed to randomly change an AWT component's
state it would not be appropriatly reflected in the peer object.
> You claim this would "break" AWT. Perhaps this is the where we
> misunderstand each other. I don't really see how adding subclasses could
> break AWT; certainly the subclasses would not work properly unless they
> were careful to clean up any messes they made by not following the standard
> interfaces, but AWT itself and the classes comprising it would still be
> inviolate, and any code using only AWT classes would work as advertised.
You can add as many subclasses as you like. As long as they stick the the
AWT APIs they will work fine! The only concern is that these subclasses can't
directly manipulate the internal state their superclasses. By the way, this
seems like a very common and useful OO methodology to me...
> In object-oriented programming, there is always a tension between reuse and
> encapsulation. The more that the internals are hidden, the harder it is to
> make modifications to an object that were not foreseen by the original
> developer. This is one reason the protected access specifier was created,
> so that an object coudl present a completely encapsulated interface to
> other classes while providing a less restricted interface to its own
> subclass. By more or less ignoring the protected access specifier, you
> have chosen to stay almost completely on the encapsulation side of the
> spectrum, and by doing so, you make it almost impossible for any other
> developers to extend the toolkit via inheritance.
Unless we provide total encapsulation you would be able to exploit platform
dependent behaviours by manipulating a component's state. We can't guarantee
consitency across platforms that way. It would be a loosing battle.
> In fact, it's clear that even the class hierarchy that your own toolkit
> provides could not exist if it weren't for the odd default state that in
> C++ terms, makes every class in the AWT package a friend of every other.
> Look at the Container, which would not even be able to set the parents of
> its children if it weren't for this feature.
Right. But the again, the Motif implementation has to obey the same rules
as you do. It seems to be happy with those rules.
> In conclusion, I'd like to point out that if you expect the AWT to be used
> for anything other than applet development, it will need to be extensible.
> Any major project written in AWT will need additional user interface
> components. Object-oriented toolkits generally allow extension in two ways
> - inheritance and composition.
You can extend the AWT both through inheritance and composition. I don't
understand what your problem is.
> By providing such a limited interface to
> subclasses, you have effectively removed inheritance as an option.
I agree that some interfaces are a little restrictive but in general I
believe that this is the right thing to do.
> I urge
> you to look at the class hierarchy provided by other object-oriented
> toolkits, find a few classes that are related to ones in the AWT, but
> somewhat different (so that it is natural to consider implementing them via
> inheritance) and then determine whether you could in fact implement them
> given the public AWT interface. I've already given you several examples.
I can't remember what your examples are. I'm sorry to hear that you
unhappy with the AWT. I'm really pleased with it.
Have fun,
Arthur van Hoff
------------------------------
From: Arthur van Hoff <Arthur.Vanhoff@Eng.Sun.COM>
Date: Mon, 25 Sep 1995 13:49:51 -0800 (PDT)
Subject: Re: throws declataration in Java/beta
Hi Jon,
> But if I can't sleep in the Run method (as the mail below suggests),
> which is something you very commonly want to do, then I think
> something is horribly broken.
>
> What's the deal?
Of course you can sleep in the run method. The run method simply
can't throw any exceptions so when you call sleep you have to
catch the InterruptedException that it can throw.
Have fun,
Arthur van Hoff
------------------------------
From: Arthur van Hoff <Arthur.Vanhoff@Eng.Sun.COM>
Date: Mon, 25 Sep 1995 13:52:54 -0800 (PDT)
Subject: Re: Fixed coordinate placement of components
Hi Sid,
> How do you add components to a Window/Frame/Panel so they go in exact
> (x,y,width,height)? Do I have to have a layout manager? It seems that all
> containers default to a layout manager that doesn't allow for fixed
> coordinate placement of GUI elements. Is there a schematic showing the
> relationship between containers/components.
This should effectively be happening when you don't have a layout manager.
Unfortunately I think it is broken.
Have fun,
Arthur van Hoff
------------------------------
From: Adam R Holt <holt@MIT.EDU>
Date: Mon, 25 Sep 1995 22:11:43 EDT
Subject: simple
test!
------------------------------
From: Arthur van Hoff <Arthur.Vanhoff@Eng.Sun.COM>
Date: Mon, 25 Sep 1995 13:43:48 -0800 (PDT)
Subject: Re: is *anyone* doing beta1 code?
Hi Scott,
> hello?
Hi?
> is *anyone* doing beta1 code?
Yes.
> where is the source?
To what?
> I've been working for nearly a week trying to convert some textbox
> class to beta1.
>
> I am running into a problem where I get a "null" in return for a
> getFontMetrics call. The (lousy) docs for getFontMetrics say it will
> return null if the component is not on the screen, but this doesn't
> answer why the call seems to work everywhere else other than a
> constructor.
The getFontMetrics call will only return a FontMetrics object once the
component has been "realized", i.e. has been made visible on the screen.
> I can get a value for getFontMEtrics in an applet.init() or most any
> other place, other than a constructor for another class. This is
> really frustrating because this is the *only* place where I *need* the
> getFontMetrics call.
Your applet class really should not have a constructor. You should do
all your constructing in the init() method instead.
> Does anyone have an example of a call that calls a constuctor for
> another class where the second class has a call to getFontMetrics?
>
> I'm about ready and willing to kill for any beta1 code that actually
> works.
There are lots of examples of applets (with source) in the JDK release.
Have fun,
Arthur van Hoff
------------------------------
From: Smiljan Grmek - KSI ZGB <sgrmek@public.srce.hr>
Date: Tue, 26 Sep 1995 03:32:28 +0100 (MET)
Subject: Re: Java as developers tool
On Mon, 25 Sep 1995, Michael Lorton wrote:
> Reminds me so say some things I have been meaning to say for a while.
>
> 1. If there is no available API, and you are planning to do an
> implementation, write it as an *interface*. That way, people can use
> your implementation without becoming tethered to it.
>
> 2. Sun ought to have an informat interface-approval process (based, I
> suppose, on RFCs). Standardize database, R-E, encryption, what have
> you.
>
I agree completetely. And there are a few things to trash about:
From articles and previous discussions on this list (in alphatime), I
really got the impression that Java would be as close as possible to the
independent software developer's dream: free, ubiquitios (means found
almost anywhere), supported by a major company, running on most platforms
- - and nice to write (a bonus!).
Now (in betatime) we see restrictions in essential classes, hear about
licencing problems and fail to hear a commitment from Sun to become a
certification agency. This prompts me to pose a few questions for
discussion, mainly from a standpoint of a full application developer.
1. Certification of Java *interpreters* - if somebody develops an
on-the-fly compiler or throw-away-code system for Java execution, will
Sun (or whoever) certify it or will it wander around the net accompanied
by rumors -it works-it doesnt-it is leaky-...
The interpeters will have to be distributed through secure channels anyway.
2. A plea to Sun to explicitly leave a trap opcode for on-the-fly things
(of course not in official HotJava). The debug opcode may be used, but....
3. A very clear statement of position on using published classes in
commercial products. Some of them are very attractive - e.g. to develop
an HTML editor, the browser classes are tempting.
4. Some sort of users' group and class repository for contributed
software. This should be tested and graded.
5. Some assurances that future safe interpreters will run the potentially
unsafe code in larger local applications.
So getting this off the chest, it would be nice to hear from people who
are considering Java for their main development platform - ensuring
portability and GUI encapsulation.
Have total hilarity
Smi
Smiljan Grmek
KSI Zagreb
------------------------------
From: "ADAM HOLT 11 Harold #3 Somerville 617 666-0240 http://web.mit.edu/holt/adam" <holt@MIT.EDU>
Date: Mon, 25 Sep 1995 22:41:48 EDT
Subject: simple thread examples needed
Sorry if I posted a 'test' here earlier.
I'm trying to puzzle out threads and could use a nice, simple example.
anyone have one?
thanks in advance!!
(I am <really> missing searchable email archives - those aren't being
stored anywhere else now are they? I saw one person offer... )
------------------------------
From: phil@bolthole.com (Philip Brown)
Date: Mon, 25 Sep 1995 20:02:27 -0700 (PDT)
Subject: Re: Q's on File access API's in Pre-Beta
[ Arthur van Hoff writes ]
>
> > 3) There doesn't appear to be any API for locking files or portions
> > of files
>
> I'm not sure how we implement this in a platform independent way.
Well, if you only worry about locking files from other java threads, then
what about, in absence of true file locking system calls, to
have a filelock database maintained by the runtime?
This would then require either that only one runtime be active at once,
or that there be some method of interprocess communication.
------------------------------
From: garya@village.org (Gary Aitken)
Date: Mon, 25 Sep 1995 21:03:48 -0700
Subject: Re: mo betta questions
>YES,YES- we need some good old-fashioned documentation. Some of us can't
always use our computer and some decent docs would help!
As a first cut, How about making the Print option work in the HotJava
browser? That way at least we could generate something to use off line.
As it stands, you can use something like Mosaic to print it, but you
don't get any of the diagrams, and half the documents can't be read in.
Perhaps the situation is better on SPARC systems; I'm trying to deal with
this in a win95 environment, and it sucks.
Gary Aitken garya@village.org
------------------------------
From: garya@village.org (Gary Aitken)
Date: Mon, 25 Sep 1995 21:03:34 -0700
Subject: Re: Fn ptrs & ... callbacks!?
>Actually, with the Callbackable vector scheme you will be subclassing
>for *every* method which you want to have called back, not just every
>new class which you want called back.
This can be avoided, if one uses a canonical form for methods which are
callbackable. Give them a signature which has a single argument, an
object of class "CallbackInfo" or whatever. The different callblack
types subclass CallblackInfo to get their specific input /output data
objects. In the callback you get the generic input object, validate
its type as appropriate, and downcast it to the specific type. Don't
know if Java will allow downcasting to a valid type; I'm a newbie and
still learning...
Gary Aitken garya@village.org
------------------------------
From: "Colin B. Boatwright" <colin@nando.net>
Date: Mon, 25 Sep 1995 23:33:55 -0400 (EDT)
Subject: Netscape 2.0a2
For those developers lucky enough to have Netscape 2.0a2, have any of you
gotten java applets to run (pre-beta, of course). I saw it in New York,
but I can't get my a2 to run applets. It does all the other promised stuff.
Perhaps there is an a3?
Colin
- ------------------------------------------------------------------------------
Colin B. Boatwright | 919/836-5772 Voice | http://www.nando.net
Colin@NandO.net | 919/836-2814 Fax | New Media Division
NandO.net Developer | 919/414-3020 Cell | McClatchy Newspapers Inc.
------------------------------
From: stprabhu@cat.syr.edu (Shashikala)
Date: Sat, 23 Sep 95 04:11:27 EDT
Subject: Help with java application User Interface
Hi,
I am writing a java application, and find that there are no examples
for implementing a user interface ...anywhere.
Can anyone mail me code for a simple program to pop up a window
with a button on the side?
Thanks
Shashi
------------------------------
From: Arthur van Hoff <Arthur.Vanhoff@Eng.Sun.COM>
Date: Mon, 25 Sep 1995 09:50:30 -0800 (PDT)
Subject: Re: GC and Class management
Hi Steve,
> I know java does garbage collection on instances of Object,
> but does java do garbage collection on instances of Class?
Not yet. We need to do some work in the virtual machine to
make that possible. It is on our list.
> I'm imagining a case where I've been surfing with HotJava
> for several hours, and the java interpreter gets chock full of
> old, no-longer-used applet classes from previous pages.
> Could be a memory resource hog? Or a feature? ;-)
You can consider that a bug.
> A related question...
>
> Is there anyway I can force java to GC or unload an instance of Class
> when there are no more instances of that instance of Class?
> (Sorry for that twister. Hopefully, the question is unambiguous.)
No.
> That way I could forcefully unload class X, then reload a new,
> different version of class X.
No. Reload works in HotJava by loading a new X and using it instead
the old one stays around.
> I didn't see anything in the ClassLoader api. Maybe there's a way
> that I can write some native methods to pull off that trick? Or, can I
> just use ClassLoader to load the new class X over the old class X?
We need to fix the VM first.
> Thanks much. Java is pretty cool.
Thanks.
Have fun,
Arthur van Hoff
------------------------------
From: "Jason Osgood" <josgood@seanet.com>
Date: Mon, 25 Sep 1995 23:20:49 +0000
Subject: Painting on the Background
I'm brand new to Java and I'm hoping to discover whether or not I can
paint on the browser background with a Java applet. For instance, I
may want animate clouds which move behind the foreground text and
images.
Any pointers? Please just show the direction and I'll be happy to
ferret out the details.
Cheers, Jason Osgood
------------------------------
End of java-interest-digest V1 #187
***********************************
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
