[2150] in java-interest

home help back first fref pref prev next nref lref last post

Re: Public class == File Name = Why?

daemon@ATHENA.MIT.EDU (Arthur van Hoff)
Tue Sep 26 06:20:01 1995

Date: Mon, 25 Sep 1995 11:18:46 -0800 (PDT)
From: Arthur van Hoff <Arthur.Vanhoff@Eng.Sun.COM>
Reply-To: Arthur van Hoff <Arthur.Vanhoff@Eng.Sun.COM>
To: anders.rundgren@seuppbt.pharmacia.se
Cc: java-interest@java.Eng.Sun.COM



Hi Anders,

> In the current (Alpha3) language specification there is a line that says 
> that there can be max 1 public class or interface per CU (compilation Unit). 
>  Also there is a compiler warning if the source file differs from the name 
> of the public class.  The reason behind all this seems to be that the 
> compiler can automatically invoke source files for external classes.
> 
> My question is: Is Java the only computer language where the source file 
> name is a part of the language grammar?  Should not be there IMO.

This is merely an artifact of the compiler implementation. A better 
development environment would not have this requirement.  It is merely
a work around so that the compiler can find classes without requiring
you to import them explicitly. 

> Assuming that I am correct this is what I would like to see in the Beta 
> release:
> 1. Delete the requirement that multiple public classes cannot be in the same 
> CU.  It is nice to put public classes and interfaces that belong together in 
> the same file.  BTW, It works just fine in A3. You get a warning but thats 
> all.  In the planned Beta all warnings have been taken away so this pratice 
> is soon broken.

I wish it was that easy. How does the compiler find public classes if they
can be burried in any .java file?

> 2. As the auto-source-search feature *may* be useful (until an integrated 
> environment is here) if standard MAKE files are to be used, this should be 
> controllable with a switch like "-disable-auto-source-search" that 
> effectively disable the tests for multiple public classes/interfaces and 
> source file name comparisions.

Unfortunately the compiler must do it the way it does it today. Some classes
are mutually depended and there is not "correct" order in which to compile
them. That's why the compiler has to be clever and do some of the work.

Have fun,

	Arthur van Hoff
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com

home help back first fref pref prev next nref lref last post