Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Technical Term For This Class

 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


This code is all in a file called AnotherClass.java. What is the technical term for SomeClass? A colleague of mine and I can't seem to find it anywhere. Bruce Eckel's TiJ uses these types of classes all throughout his book.

Thanks.
 
Charles Lyons
Author
Ranch Hand
Posts: 836
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there actually a technical term? Correct me if I'm wrong, but isn't this just a way to declare package-private classes without having to write a new .java source file? When compiled, these classes just get turned into the normal .class files, just as though they had been written in separate .java files.

So isn't this 'feature' is more of a convenience for writing lots of associated classes in one file - the package-private classes themselves are just normal classes compiled in the normal way. For that reason, I don't think they have, or need, another name.

This does bring up the other question of why we can't write more than one public class in the same file - just compiling the classes into separate .class files? This would work quite well for some small applications or tightly coupled structures; does anyone know of a good reason as to why this is prohibited?
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gregg Bolinger:
This code is all in a file called AnotherClass.java. What is the technical term for SomeClass? A colleague of mine and I can't seem to find it anywhere. Bruce Eckel's TiJ uses these types of classes all throughout his book.

Thanks.


It's just another top level class. As far as I'm aware it's left to the compiler to decide whether or not a public top level type must be declared in it's own file with the same name.

Excerpt from �7.6 Top Level Type Declarations:
When packages are stored in a file system (�7.2.1), the host system may choose to enforce the restriction that it is a compile-time error if a type is not found in a file under a name composed of the type name plus an extension (such as .java or .jav) if either of the following is true:

* The type is referred to by code in other compilation units of the package in which the type is declared.
* The type is declared public (and therefore is potentially accessible from code in other packages).

This restriction implies that there must be at most one such type per compilation unit. This restriction makes it easy for a compiler for the Java programming language or an implementation of the Java virtual machine to find a named class within a package; for example, the source code for a public type wet.sprocket.Toad would be found in a file Toad.java in the directory wet/sprocket, and the corresponding object code would be found in the file Toad.class in the same directory.

[ May 04, 2006: Message edited by: Ken Blair ]
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Charles Lyons:
Is there actually a technical term? Correct me if I'm wrong, but isn't this just a way to declare package-private classes without having to write a new .java source file? When compiled, these classes just get turned into the normal .class files, just as though they had been written in separate .java files.

So isn't this 'feature' is more of a convenience for writing lots of associated classes in one file - the package-private classes themselves are just normal classes compiled in the normal way. For that reason, I don't think they have, or need, another name.

This does bring up the other question of why we can't write more than one public class in the same file - just compiling the classes into separate .class files? This would work quite well for some small applications or tightly coupled structures; does anyone know of a good reason as to why this is prohibited?


You can. See the exercpt in my previous reply. In fact, the JLS strictly prohibits a system where packages are stored in a database from enforcing the (optional) restriction. Not too long ago there was a student who had some IDE/compiler I've never heard of at their school that didn't enforce it either.
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The term I've seen used for these is "supporting classes."
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Top level class with package access. I don't think it gets any more technical - can you provide more context for your question?
 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks everyone. That pretty much clears it up. I'd seen it here and there and a lot in TiJ but never really considered what it was doing.

Reminds me I really need to just break down and read the jvm spec.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic