|
|
|
| Authored by: Anonymous on Monday, April 30 2012 @ 09:33 AM EDT |
| Oops... Looks like it ate my backslashes. I hate typing on this mobile
phone.
I meant "multiple dots works fine in Windows", but it wont work for
Java
packages, at least not with the default classloader. They have to be
subdirectories.
C:\java_stuff\java\nio\channels\Overla
ppingFileLockException.java
[ Reply to This | Parent | # ]
|
| |
| Authored by: greed on Monday, April 30 2012 @ 10:58 AM EDT |
(See also your correction with the backslashes.)
For anyone wondering why this is, Java started out without a librarian. There
was no way of putting several related classes together in a filesystem object:
such as an 'ar' .a file on UNIX, a .lib file on DOS-family systems, and so on.
Instead, Java just used the filesystem as its librarian.
When it wants to load a class "George" in a package
"java.curious", it constructs a pathname fragment by changing all the
dots to file separators (I'll use the POSIX / character) and dropping '.class'
on the end. So we get "java/curious/George.class".
Now it goes through all the directories specified in the CLASSPATH--an
environment variable like PATH, LD_LIBRARY_PATH, LIBPATH, SHLIB_PATH, and so on.
In each directory, it tries to find the path fragment it worked out above.
(There's also a commandline flag; individual implementations may provide other
methods, such as a property file or a registry interface.)
So that meant all the .class files for the Java runtime would be sitting around
as plain files on your disk. As Java evolved, this got to be a ridiculously
large number of files.... But because they were in subdirectories based on all
parts of the package name, this wasn't a big deal: each individual directory had
a reasonable number of files, so the "cost" of looking up any one file
was reasonable. (And on btree-based or hash-assisted-lookup filesystems it was
really quite fast.)
Problem came with Web applets: you'd have to send every .class file in your
applet to the client's JVM. HTTP 1.0, as it was back then, is not efficient at
sending lots of little things: it starts from scratch for every single file it
sends.
So IBM walks in and says, "Hey, if we were to just stick files in ZIP files
and put those in the CLASSPATH, we could make this a lot more convenient. We
could send a single ZIP file containing the entire applet to the browser; it
could even have HTML and GIFs and other assets!"
And the .jar was born--without changing the search model for .class files at
all. It just treats any file in the CLASSPATH as a ZIP file, and looks inside
the ZIP for the given path fragment.
It was a beautifully minimalist solution to a problem that shouldn't have
existed.... (Sun knows about librarians: you have to, to make a UNIX system.
You at least need 'ar' and 'tar' and 'cpio'.)
As a result, though, your .class file structure MUST follow your package
hierarchy and class name structure. To keep things sane, Sun required you to
have the source file structure match. (I believe in 1.0 and earlier it only
recommended; now it is required.)
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Monday, April 30 2012 @ 04:45 PM EDT |
On a command line, you can use dots in a fully qualified class
name,
java sun.tools.jar.Main
or you can use
slashes
java sun/tools/jar/Main
or you can max
them
java sun/tools.jar/Main
But in .java source
files, you have to use dots.[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Tuesday, May 01 2012 @ 12:51 AM EDT |
The dots in filenames under Windwos is teh cause of quite a bit of social
engineering, for example, having a file called picture.jpg.exe is a classic
example as Windows hid (by default) the .exe part and the user doesn't spot the
fact that normal pictures do not show the .jpg bit.
On OS4000 the dot was the directory separator and teh C header files were files
called "H" in directories called "STDIO", "MATH",
etc (which were sudirectories of "INCLUDE").[ Reply to This | Parent | # ]
|
|
|
|
|
