[4291] in java-interest
java-interest-digest V1 #265
daemon@ATHENA.MIT.EDU (java.sun.com!owner-java-interest-d)
Fri Dec 15 14:12:07 1995
From: java.sun.com!owner-java-interest-digest@asoft.msk.su
Date: Wed, 15 Nov 1995 15:11:05 -0800
To: java-interest-digest@java.sun.com
Reply-To: java.sun.com!java-interest@asoft.msk.su
java-interest-digest Wednesday, 15 November 1995 Volume 01 : Number 265
In this issue:
Re: Native methods in apllets
? about package stability, security manager, and sockets
Help with hello world
Buttons with graphic contents
Re: How java apps get krb tickets?
Re: protected is not?
Re: How java apps get krb tickets?
Simple Draw Image
Re: How java apps get krb tickets?
Re: How java apps get krb tickets?
Re: protected is not? (longish)
Re> Re: How java apps get krb tickets?
Re: declaration v.s. definition ambiguity
----------------------------------------------------------------------
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
Date: Wed, 15 Nov 1995 10:02:02 -0800
Subject: Re: Native methods in apllets
Hi Otto,
> Can I call external C code (using native methods) from a Java Applet?
> (I need to interface a Windows DLL for a particular demo with Java
> Applet - I'm using Netscape 2.0.b2 on Windows 95)
No. It would have serious security implications.
> If no, is there anything than can help me to solve this problem?
I'm not sure if Netscape will let you do this at all. It's internal
APIs have not been published and I believe dynamic linking is turned
off completely.
In HotJava you could ask the user to install the DLL on the file system.
You have to be careful though, that DLL can do whatever it likes! It is
not constraint by Java's security mechanisms.
Have fun,
Arthur van Hoff
------------------------------
From: brown@sss.iii.net (douglas)
Date: Wed, 15 Nov 1995 13:16:56 -0500
Subject: ? about package stability, security manager, and sockets
Greetings,
I have been lurking on this mailing list for the
past few months. I have been working with the alpha and
beta kits trying, to the best of my abilities, to get a
handle on what IS Java and how I can make use of it.
I got the alpha kit up and working. Wrote a few small apps.
Then I crashed and burned with beta (geez guys, ya changed
the world around!). Finally, I am up and flying again. I
sorely miss having a reasonable browser (Netscape, Phhhhtttt!)
that can run/load applets from the local file system.
Now, my questions:
Many things disappeared from java.util and some new
things have appeared. The URL code has moved
from net.www.html to java.net. and functionality appears to
have changed. How much can I depend upon the classes located
in java.util?? Are the classes now located in java.net and
java.util going to stay there? Or, do I have to recreate
the functionality which those classes provide(ed). Part of
my difficulty with the Beta kit was/is that some of the
utility classes I was making use of are now gone! I am
concerned that you guys are going declare some more of the
current classes proprietary and move them into the
sun.* class tree. This has already seems to have happenned
once. Is it going to happen again and, if so, what classes
willbe affected?
A review of the beta code indicates that there is/will be
an underlying security system. I seem to have missed the
discussion of the architecture for this system. One of my
concerns regarding the alpha release was the lack of any
type of security system/manager. I am happy to see that
there will be one and that I do not have to design/build
a system which, in all probability, would be incompatible
with other peoples designs. However, where is the
documentation? Where can I find the past discussion on the
security managers architecture? How can I join in on the
current discussion? Will the security manager be extensible
by trusted parties? Will there be a means for identifying
trusted entities by signatures? If so, will the signature
mechanism be extabdable? Etc, etc...
Much change seems to have ocurred in the sockets class and
the layout for servers. What is the current architecture?
I admit to being a bit puzzled about the current design. Is
there any documentation for sockets, servers, and what you
guys are doing and what the architecture is/will be?
Please note: my desires for documentation extend
beyond the APIDOCs provided. What's there is nice but, it
doesn't talk about how all the pieces fit together. Between
the APIDOC and the source code I have puzzled out some
aspects of the design. However, this is fraught with danger
in that my guesses and assumptions regarding the design are
not gaurenteed to be correct.
Java looks good. It's going to have a lot of growing pains.
I would like to get a discussion going about a distributed
computing environment which has a homogeneous base and the
capabilites for heterogeneous extensions.
Doug Brown
------------------------------
From: Darren Roberts - CM53-4 <derober0@pine.shu.ac.uk>
Date: Wed, 15 Nov 1995 14:17:34 +0100 (MET)
Subject: Help with hello world
Hello,
I have recently come across Hotjava and the Java programming language and have
tried the HelloWorld examples but to no avail. The java source file compiles okay
and produces the corresponding class file, this is then inserted in the Html file
like so:-
<APPLET CODE="HelloWorld.class" WIDTH=150 HEIGHT=25>
</APPLET>
This prints all the text in the Html file but just leaves a red blob where the
class should be. I have also tried this with the given examples like the tape and the
bouncing heads and although all of these work in the appletviewer, they don't in
hotjava when you give the file:// name etc.
Another problem I had occured when trying to do the example run protocol handler
this gives errors on all the import statements and whenever you use 'extends'
for example on Applet this also gives an error.
I am using Hotjava v1.0 alpha3 and JDK beta 1
Can anybody help me, all ideas greatly appreciated.
Thank you
Darren.
------------------------------
From: davest@teleport.com (David C. Stewart)
Date: Wed, 15 Nov 1995 11:16:13 -0800
Subject: Buttons with graphic contents
The "Button" class in awt (java.awt.Button) gives buttons which have
text labels. Does anyone have an extension of Button which has
a graphic (a .gif for example) as the label? Or a suggestion as
to how to go about adding this? Thanks...
Dave
- --
David C. Stewart -- davest@teleport.com
Home Page -- http://www.teleport.com/~davest/index.html
------------------------------
From: David R Richardson <normanb@citi.umich.edu>
Date: Wed, 15 Nov 1995 14:36:51 -0500
Subject: Re: How java apps get krb tickets?
This is a multipart MIME message.
- --===_0_Wed_Nov_15_14:34:50_EST_1995
Content-Type: text/plain; charset=us-ascii
A few more comments about kerberos access through java applets.
I think we still have some confusion about which resources applets will be
able to access; I've included a security summary by Marianne Mueller
of Sun and added her to this message in hope that she might be able
to clarify a few things.
> Date: Sat, 11 Nov 1995 13:52:55 -0600
> From: Adam Cain <acain@snapple.ncsa.uiuc.edu>
> To: java-kerberos@lists.Stanford.EDU
> Subject: How java apps get krb tickets?
>
[information about Kerberized Mosaic and importance of single login/
ease of use elided]
>
> But back to the orginal question of how the kerberized java app gets
> its tickets. Let me summarize my understanding of the last couple notes
> from Mark and Roland, with respect to this question (and again, please
> forgive my relative unfamliarity with the details of java's security
> mechanisms). It seems there are two basic approaches for this:
>
> 1. The java applet could get the user's kerberos password and then
> get a TGT. From that point on, it gets its own tickets from the KDC,
> as needed.
>
> 2. The java applet could get tickets using the user's ticket cache.
> Assuming the cache has a TGT, the applet can also get tickets from
> the KDC.
>
> As Mark mentioned, #1 makes security people nervous, as it is quite risky
> and somewhat contrary to the intent of kerberos.
>
> As for #2, Roland points out that the applet probably can't (and should
> not be able to) access the user's ticket cache.
Ken Arnold (addressing an unrelated issue for the
java-interest@java.sun.com
list members) also drives Roland's point home. This point was
also described by David R Richardson <normanb@citi.umich.edu> for the
java-kerberos list last week. Because the applets are not allowed to load
native methods, #1 will be the only way to go.
While I think Adam has a good summary and the issue is probably still true,
access to local files is different from using native methods. The choice
of whether or not an applet can use the file system is somewhat browser
dependent, but access to native methods seems much less likely. In addition
to file access though, we also have to worry about socket connections to
hosts other than the orriginating web server (contacting the kdc and
potentially a third server if the endpoint is different from the web
server). These connections are almost as problematic as the file access.
But in short, I think we're more likely to be able to do file and
socket access than native method access.
It seems to me that we are either going to have to implement the whole
thing in java, plus the sort of certified class loader described by Marianne,
or hope that it is included in the browser or standard java distribution.
As a side note, while I've seen descriptions like the following of the
sorts of things java can and can't do, I haven't seen any descriptions
of how java applets can take advantage of browser security features.
For example, is it possible for java applets to utilize the
RSA certificates that a netscape user might have?
David Richardson
University of Michigan
- --===_0_Wed_Nov_15_14:34:50_EST_1995
Content-Type: message/rfc822
Content-Description: java security
From: mrm@puffin.Eng.Sun.COM (Marianne Mueller)
Newsgroups: comp.lang.java
Subject: Re: PRINCETON STUDENTS FIND HOLE IN INTERNET SECURITY SOFTWARE
Date: 9 Nov 1995 00:50:27 GMT
Organization: Sun Microsystems, Inc. Mt. View, Ca.
Lines: 180
Distribution: world
Message-ID: <47rj8k$6fd@handler.Eng.Sun.COM>
Reply-To: mrm@puffin.Eng.Sun.COM (Marianne Mueller)
NNTP-Posting-Host: puffin.eng.sun.com
Keywords: alpha3 hotjava security
Originator: mrm@puffin
The paper written by the two students at Princeton describes possible
attacks on the alpha3 HotJava browser, which have all been fixed in
JDK beta. Granted, until this week, the source code for JDK beta
wasn't available, so it's understandable that they analyzed the alpha3
source base.
We understand people need more information on the security model, and
we're taking time right now to document the security story more
rigorously. A security FAQ, an updated whitepaper, detailed user
documentation and detailed implementor's documentation are all being
worked on.
The Java security mechanisms include:
Java langugage mechanisms
* no pointers
* private interfaces, classes and methods
* class loader that enforces namespace divisions
* runtime byte code verifier that enforces language
type rules and name space divisions
Browser mechanisms, used by JDK beta appletviewer and by
Netscape Navigator 2.0beta
* AppletSecurity: extends java.lang.SecurityManager; strict
applet checks
* AppletClassLoader: extends java.lang.ClassLoader; strict
class loading
The goal for JDK beta is to enable browsers to run untrusted applets
in a trusted environment. The approach is to be conservative at
first, and to add functionality when it can be added securely.
So, JDK beta applets (and Netscape 2.0beta applets) may not do the
following.
1. Files:
Access Control Lists are greatly restricted in beta,
as compared to the situation in the alpha3 HotJava browser.
ACLs are initialized - only once - by the applet security
manager, and are not user configurable.
For a file not on the access control list, an applet cannot
- check for the existence of the file
- read the file
- write the file
- check the file type
- check if the file is a directory
- check the timestamp when the file was last modified
- check the file's size
- create a directory
- rename the file
- list the files in this file (as if it were a directory)
Applets cannot
- create a FileInputStream
- create a RandomAccessFile, either for reading or writing
- Open file descriptors
2. Sockets:
Applets cannot
- Create socket connections other than to its own host
- Create a socket factory
3. Loading/linking:
Applets cannot
- Create class loaders
- Access a package in the sun.* hierarchy
- Define a new class in the java.* hierarchy
- Link dynamic libraries using System.loadLibrary()
- Disable or override the AppletSecurityManager
4. Process control:
Applets cannot
- Define native methods
- Fork processes
- Manipulate threads or thread groups outside of the
applet's thread group
- Exit the virtual machine (eg the browser or the
appletviewer)
5. awt:
Applets cannot
- Create toplevel windows that don't have a warning banner
Applets can use network connections only to connect to the host they
originate from, to download files that are part of the applet's
implementation. Those files might be java bytecode class files, or
they might be input files used by the applet (GIF, JPEG, audio, other
data files.)
Taking a look at the specific attacks mentioned in the paper -
alpha3 HotJava JDK
---------------------- ---
1. socket accept() and applets cannot use
listen() aren't protected accept() and listen()
adequately, allowing a
browser to eavesdrop
2. applets can connect to applets cannot connect
the SMTP (mail) port on to the SMTP port on
some web server and use the computer the applet
that as a covert channel is visiting
3. InetAddress.getByName() applets cannot use
is public and does not InetAddress to inquire
check the security mode about hosts they are
before making DNS request not already allowed to
connect to
4. applets can use DNS to applets may not get the
create a covert channel internet address of any
host
5. Access Control Lists (ACLs) ACLs are greatly restricted
for reading and writing in JDK beta.
files are not strict enough Reading/writing files is
disabled for web browsers,
such as Netscape Navigator 2.0.
6. applets can use the System.getenv() is obsolete
System.getenv() method and is not part of the JDK
to gather information about API
the computer that it is
running on
7. applets can change the applets cannot read or alter
property manager database client properties
8. applets can change the The fields that hold the
HTTP and FTP proxy server HTTP and FTP proxy names are
private. The values are stored
in a property manager database
that an applet cannot read or
write.
It's very difficult, if not impossible, for a web browser to
completely prevent denial of service attacks. The JDK applet API
doesn't claim to prevent denial of service attacks. A "denial of
service" attack is where someone writes an applet whose goal is to
consume all available resources on your computer, forcing you to kill
the browser you're running. For example, someone could write an
applet that creates a million popup windows. The windows don't do
anything, but creating a million of them might use up all the virtual
memory on your computer and you'd have to kill the web browser to
reclaim the virtual memory.
Before people engage in too much wailing and gnashing of teeth about
how applets have been too severely restricted -
We want to enable applets to do interesting things, including making
socket connections, and reading and writing to the file system. One
way to enable that is to used a signed class loader. When a trusted
applet is loaded, then the applet could be granted permission to do
some of the things they are prevented from doing by default.
The goal is to ensure that untrusted applets can't steal or damage
information on a computer running a Java-enabled browser. Later, we
can allow trusted applets to do things that untrusted applets are not
allowed to do. Since an implementation bug in a trusted applet could
open a loophole that could be exploited by an untrusted applet, design
matters.
Marianne
Java Products Group
http://java.sun.com/people/mrm/
- --===_0_Wed_Nov_15_14:34:50_EST_1995--
------------------------------
From: Edith Au <edith@pencom.com>
Date: Wed, 15 Nov 1995 14:29:13 -0500 (EST)
Subject: Re: protected is not?
Hi,
> Edith Au wrote:
> >
> > protected variables can be accessed by the methods of its class and subclasses
> >
There is something missing from this statement. Ken Arnold gave a better
explanation for protected variable (but I lost that mail so I can't include
his statement here). Protected variables (and methods) are "friendly" to the
classes in its package. So, protected variables (and methods) can be accessed
by classes from the same package. Also, the default for variables and methods,
and even classes is protected. Sorry for the confusion.
>
> Following your logic what is the value of protected then?
I am not sure if there is a package concept in C++. But one of the
advantages of using protected is preventing people from stealing your
"classes".
Let's say you wrote an application with 5 classes and all of your
variables, methods, classes are protected so classes are "friendly"
within the package. Now, let's say I want to reuse one of your classes
in my class, say class A. The only way class A can use your classes is
by packaging Class A in your package. Which means I have to create a
package directory structure just like the way you do. If your package
name is CompanyX.DeptY, it might not be a good idea for me to do that.....
Anybody has a better idea on the value of protected in Java?
>
> I would interpret the above quote to mean that I can only access protected
> members from within the (sub)class - like protected in C++.
I just got your mail so you know protected in Java and in C++ is not the
same.
I am not sure if Java needs an extra access identifier to implement
protect in C++. I can't think of any reason why it is needed...
Cheers,
Edith
==============================================================================
Edith Au Tel: (212) 513 7777
WWW Specialist Email: edith@pencom.com
Pencom Systems Incorporated WWW: http://www.pencomsi.com/~edith
40 Fulton Street,
NY, NY 10038
===============================================================================
------------------------------
From: mrm@puffin.Eng.Sun.COM (Marianne Mueller)
Date: Wed, 15 Nov 1995 12:10:54 -0800
Subject: Re: How java apps get krb tickets?
In JDK 1.0, an applet cannot read or write files on a remote client,
so I don't think it can get a Kerberos ticket in that way. (By
client, I mean a Java-enabled browser running on a desktop computer.)
What you could do is implement some style of server-side persistent
data, which applets can access. I guess for Kerberos, this isn't any
good, since the whole point is that you don't want to expose the
Kerberos private-ticket traffic to IP.
Maybe the problem of bootstrapping Kerberos security is similar to the
key management conundrum. Short term, people might could get around
some of the key management problems by keeping a set of public keys on
their local hard disks, and not attempting to get those over IP.
Physical devices like smart cards might also gain popularity as a way
to store and share public keys.
Marianne
Java Products Group
------------------------------
From: "Brian D. Elliott" <belliott@world.nad.northrop.com>
Date: Wed, 15 Nov 1995 12:47:55 -0800 (PST)
Subject: Simple Draw Image
I am having a major flicker problem drawing a very simple gif file. This
applet seems so simple - what am I doing wrong? Do I have to use a panel
or a canvas to draw to? It also takes a long time to display.
If I use the NoFlickerApplet from the net(mkgray), it doesn't flicker but
it still takes a long time to display the image. This applet draws the
image off screen first.
Here is my code:
import java.awt.*;
import java.applet.*;
import java.awt.image.*;
import sun.awt.image.URLImageSource;
public class MapTest extends Applet {
private Image joe = null;
public void init() {
joe = getImage(getDocumentBase(), "world.gif");
}
public void paint(Graphics g) {
if (joe != null) {
g.drawImage(joe, 0, 0, 708, 386, this);
}
}
}
=========================================================================
Brian Elliott | 310-948-7038
Northrop Grumman Corp. |
belliott@world.nad.northrop.com |
=========================================================================
------------------------------
From: gwz@geek.ocsg.com
Date: Wed, 15 Nov 1995 13:30:27 -0800
Subject: Re: How java apps get krb tickets?
- -----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=us-ascii
Marianne ~
>
> In JDK 1.0, an applet cannot read or write files on a remote client,
> so I don't think it can get a Kerberos ticket in that way. (By
> client, I mean a Java-enabled browser running on a desktop computer.)
>
That's unfortunate, since it eliminates the transparency of using Kerberos.
> What you could do is implement some style of server-side persistent
> data, which applets can access. I guess for Kerberos, this isn't any
> good, since the whole point is that you don't want to expose the
> Kerberos private-ticket traffic to IP.
>
True.
> Maybe the problem of bootstrapping Kerberos security is similar to the
> key management conundrum.
I don't understand this comment. If I have a Kerberos TGT, I already have a
key -- it's been distributed, it's being managed (sort of :-), the problem is
that Java can't use it.
> Short term, people might could get around
> some of the key management problems by keeping a set of public keys on
> their local hard disks, and not attempting to get those over IP.
> Physical devices like smart cards might also gain popularity as a way
> to store and share public keys.
>
If an applet can't access local files, I'm not sure how this helps anything,
in the Java case. Or am I missing your point?
> Marianne
> Java Products Group
~ gwz
Glen Zorn Senior Scientist Voice: 206-883-8721
gwz@cybersafe.com CyberSAFE Corporation FAX: 206-883-6951
Since I was forced to write it by the alien parasite which attached itself to
my brain stem during my recent visit to an isolated area of Northern Arizona,
it could hardly be construed that this message would reflect either the
opinions or the policies of my employer.
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMKpb6zUVUtyACBApAQHTXAP+KXVwzE4a5d6AsCbyoEx85BrVDmhQwW2x
pt9CqOmvv9B9Cc+YefCTfl7DYPA7b6f3yDXvOYZ0FssJjCIp4CA4PZvBbN3q0u2z
gmX0vEO1XBzNG/3aR9sUwkWuPT7QdqSLgK+qL4K7dGXJVgisXhy8DVOvDqE9yhTm
PF9m8Pdhiog=
=l4Ow
- -----END PGP SIGNATURE-----
------------------------------
From: Marc Horowitz <marc@MIT.EDU>
Date: Wed, 15 Nov 1995 16:58:55 EST
Subject: Re: How java apps get krb tickets?
You all seem to be overlooking an obvious solution to this problem.
Implement a set of native methods which are *installed by the user*
which does safe accesses to the credential cache. This class would
probably implement a reasonable subset of the kerberos api, or even
better, the GSS API.
Then, implement a class on top of that which implements safe
operations based on kerberos, implemented in java, and also locally
installed, not downloaded. Make *only these methods* available to
applets. Acceptable methods here (to me, at least) would be
- instruct the browser to get a tgt if none was present (this would
have to be via a "well-known" interface to prevent trojan initial
ticket applets).
- get a service key for a service on an appropriate server host
(probably the same host as the web server). Restrictions on what
services are available are probably appropriate. This does
potentially open up a covert channel in the service names, but if you
want a covert channel, you can always encode whatever you want in
http. Examples of covert use would be whitespace, ordering, time
delays, etc. You don't need to put the data in the clear. IMHO, the
1.0 JDK precautions are overkill.
- Authenticate to a server.
- Perform certain authentic or confidential operations, such as
encrypting valid http requests, etc.
More specific operations could be added, locally, as more kerberized
applications become available. For instance, you could have a method
available to applets which would do a secure ftp transaction under
certain circumstances (to a configured set of servers, for instance).
By restricting these methods enough, it will be safe to make them
available to applets. As long as all access to sensitive data (the
tgt and other kerberos tickets) were done in trustable, auditable,
locally-installed C code, this would not present a security risk.
Marc
------------------------------
From: Aleph One <aleph1@dfw.net>
Date: Wed, 15 Nov 1995 16:22:05 -0600 (CST)
Subject: Re: protected is not? (longish)
I compleatly agree with your comments. If one of the members of the Java
team care to comments. Is this necesary or are we missing a point and
there already is a way to acomplish this in Java?
Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
On Wed, 15 Nov 1995, D'Arcy Smith wrote:
> Introduce a new keyword?
>
> How about this:
>
> (current java)
> public - world access
> private - class access
> protected - package access
>
> (new java?)
> public - world access
> private - class access
> protected - class/subclass access (like C++)
> shared - package access
>
> thus the above becomes:
>
>
> class Base
> {
> protected int x;
> shared int y;
> }
>
>
> class Derived
> {
> public void f()
> {
> x = 1;
> y = 2;
> }
> }
>
>
> class OtherClass
> {
> public void g()
> {
> Base b = new Base();
>
> b.x = 1; // good I can't access Base::x here :-)
> b.y = 2; // good I can access Base::y here :-)
> }
> }
>
> This also has the effect of getting rid of the implicit friending
> of all package related classes. (I like that :-))
> So now a class can say what it's friends are allowed to see and not
> be exposed to the world =:-0.
>
> comments?
>
> ..darcy
>
> --
> D'Arcy Smith, Systems Analyst
> Applied Research in Computer Systems (ARCS) Laboratory
> British Columbia Institute of Technology (BCIT), Burnaby, BC, Canada
> E-Mail: darcy@arcs.bcit.bc.ca URL http://www.arcs.bcit.bc.ca
> Tel: (604) 432-8281 Fax: (604) 436-1297
>
------------------------------
From: "Sid Conklin" <sid.conklin@nora.stanford.edu>
Date: 15 Nov 1995 14:57:48 -0700
Subject: Re> Re: How java apps get krb tickets?
Marianne,
We plan on Applets access the Kerberos functionality via dynamic libraries by
native method callouts. We have this working under Solaris using Java instead
of HotJava. Do we lose this mechanism when we write an applet to take
advantage of this inside a Netscape browser and/or HotJava browser?
Someone already mentioned that applets won't have the ability to make native
calls to dynamic libraries, is this true? And if so why?
Thanks,
Sid Conklin
Stanford University
------ From: Marianne Mueller, Wed, Nov 15, 1995 ------
In JDK 1.0, an applet cannot read or write files on a remote client,
so I don't think it can get a Kerberos ticket in that way. (By
client, I mean a Java-enabled browser running on a desktop computer.)
What you could do is implement some style of server-side persistent
data, which applets can access. I guess for Kerberos, this isn't any
good, since the whole point is that you don't want to expose the
Kerberos private-ticket traffic to IP.
Maybe the problem of bootstrapping Kerberos security is similar to the
key management conundrum. Short term, people might could get around
some of the key management problems by keeping a set of public keys on
their local hard disks, and not attempting to get those over IP.
Physical devices like smart cards might also gain popularity as a way
to store and share public keys.
Marianne
Java Products Group
------------------------------
From: daconta@primenet.com (Michael Daconta)
Date: Wed, 15 Nov 1995 16:09:32 -0700 (MST)
Subject: Re: declaration v.s. definition ambiguity
At 09:47 PM 11/13/95 -0700, Gary Aitken wrote:
>>declaration: Only an announcement to the compiler of an identifier to be
>>reserved in the current name space. In ANSI C, accomplished with the
>>extern keyword. For functions accomplished by omitting the function body.
>>For structures and classes accomplished with type identifier and no body.
>
>>definition: An announcement to the compiler of an identifier to be
>>reserved in the current name space. For primitive types, accompanied
>>with a reservation of storage space. For user-defined types,
>>accomplished by specifying the structure or class body. For functions
>>accomplished by specifying the function body.
>
>If I read the above correctly, the following is a declaration of Foo,
>not a definition:
>
> public static void main ( String argv[] ) {
> MyClass foo;
> }
>
>But it seems to me this is a definition.
>Also, abstract methods cannot have a body (unfortunately; should be may not)
Hi Gary,
In the above, the
MyClass foo;
is only a definition if MyClass has already been defined which
I'm sure is what you meant.
>
>As I understand the current syntax and semantics,
>it seems to me that a declaration is:
>
> An announcement to the compiler of an identifier to be reserved
> in the current name space, with no storage allocation.
>
>and a definition is:
>
> An announcement to the compiler of an identifier to be reserved
> in the current name space, together with the reservation of
> storage for the identifier.
>
>If we remember to take into account the difference between a class, and
>an instance of a class, the above is all consistent. In a class definition,
>the storage is allocated for the class itself -- the stuff which implements
>the class; not an instance of the class.
I think you are close; however, I don't think there is actually any storage
allocated for "the stuff which implements the class." Not at runtime anyway.
At compile time there is of course symbol table entries. However,
I think the ANSI C distinction of storage allocation was referring to
runtime allocation.
However, I think you are correct in that you need to take into an account
that a class is different than a primitive type. A class definition is
much closer to a function definition than a primitive type definition.
Using the analogy of a function definition seems to clear it up for
me.
>
> A class, in java, is never just declared. It is declared
> and defined in one operation. The definition amounts to allocating
> storage for all aspects of the class which do not require additional
> storage allocation when an object of the class is instantiated.
>
> A class instantiation, such as the "MyClass foo;" above, is a
> definition, as it reserves the storage associated with the instance.
>
> An interface, in java, is always declared, but never defined,
> since the definition of an interface is dependent on the class
> which implements the interface; a definition for an interface
> effectively occurs in the context of a class which implements
> the interface.
>
>Does this make sense?
>And please remember I'm no expert on this -- Arthur or somebody else
>should pass judgement on any statements like the ones I made above.
>
>Gary Aitken garya@village.org
>
Gary I think your definitions are good. Of course, when you say,
"It is declared and defined in one operation," that is not technically
correct because a definition is a declaration. That is why they are
so often used interchangeable. It is perfectly legal to say that for
int a;
the identifier a is declared in this namespace.
int a is a definition but a definition is a declaration so,
(using logic) if A=B=C then A=C.
I have it down now. Thanks for your help.
- Mike
------------------------------
End of java-interest-digest V1 #265
***********************************
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
