3

Just before you say this is a duplicate, I saw the other questions already and I still wanted to post this.

So I was reading Thinking in Java -Bruce Eckel and this passage is about the lowercase naming convention:

In Java 1.0 and Java 1.1 the domain extensions com, edu, org, net, etc., were capitalized by convention, so the library would appear: NET.mindview.utility.foibles. Partway through the development of Java 2, however, it was discovered that this caused problems, so now the entire package name is lowercase.

I'm having the issue at "it was discovered that this caused problems". What problem? It couldn't have been name conflict because the domain name was in all caps, right?


I've searched on Google for this, but all I got was: Why should java package name be lowercase?:

Package names are written in all lower case to avoid conflict with the names of classes or interfaces.

I've also searched for java package lowercase convention changed all-caps domain name but to no avail.


So does anyone have any idea why they changed the naming convention midway?

Community
  • 1
  • 1
Daniel Cheung
  • 4,779
  • 1
  • 30
  • 63

2 Answers2

3

Just a wild guess, not based on any credible source: Package names are tied to filesystem directory structure. A package name with NET in it could conceivably cause problems if e.g. a source tree from a case-sensitive filesystem was copied to / used on a case-insensitive filesystem and for whatever reason the directory name was changed from "NET" to the equivalent "net".

Same deal in the opposite direction, too: Resolving filesystem paths from package names, I can conceive of situations where this could cause some ambiguity or at least catch a user by surprise.

I could see this causing confusion in some scenarios.

Another potential issue is the fact that it conflicts with what's allowable in the class naming conventions. Classes are generally first-letter-uppercase but it's not uncommon for e.g. acronyms to be all capital, e.g. a class named API, or COM or something. This allows some overlap between the package and class naming convention. But my feeling is that the filesystem issues are a more likely problem.

Jason C
  • 38,729
  • 14
  • 126
  • 182
  • 1
    On some versions of some Windows file systems names that are entered in all caps are displayed in all lowercase as the default. This is probably to be friendly towards files from systems that don’t distiguish case — these may come in in all uppercase and look better in all lowercase. While the file name is still uppercase behind the scenes, this may have caused confusion. All just specuilation, of course. – Ole V.V. Aug 30 '16 at 15:59
  • I couldn't find an email for James Gosling (lol) but I sent Bruce Eckel a letter. Maybe he will reply. – Jason C Aug 30 '16 at 18:57
  • 2
    He replied! But alas, looks like his guess is as good as ours: *"So sorry, that was a long time ago and especially in early Java days there were a LOT of design hiccups, so I don't remember. That should definitely have been a footnote in the book. However, the Windows uppercase/lowercase treatment that one SO replier mentioned does sound plausible."* Well at least I feel somewhat validated in my guess, lol. – Jason C Aug 30 '16 at 21:35
  • I think I understand that problem now. Thanks. Didn't think of emailing the author though. But at least the problem is made clear on the Internet now so others can see should they come from the book. – Daniel Cheung Aug 31 '16 at 00:38
1

I think the quote in the book refers to errors like the following: RS01799: IMPLEMENTATION CLASS IS NOT FOUND WHEN A JAVA PACKAGE NAME START S WITH AN UPPER CASE CHARACTER.

I don't think the author wrote about programmers confusion but internal JVM implementation. I've made tests using JDK 1.8 and could not reproduce the problem. Do notice the use of "may not be found" in the bug report description.

acm
  • 2,086
  • 3
  • 16
  • 34
  • That's a good guess, maybe things like that. Although that was filed in 2014 (Java 1.2 was released in 1998) and *might* be programmer confusion, e.g. a WS Decision Server implementation error in some reflection logic or something. But yeah could have been something along these lines, so +1. – Jason C Aug 30 '16 at 19:06
  • 1
    I noticed the date but the quoted book says it was discovered in Java 1.2, so the standard was changed. Not a word about when/if it was fixed. But, sure it can be programmer confusion as well. An implementation of the JVM which used a database instead of a file system could have also caused problems. The phrase "avoid conflict with the names of classes or interfaces" in the current documentation suggests that there might still exists conflicts in some scenarios. I hope Bruce Eckel replies your letter. – acm Aug 30 '16 at 19:50