更改包名称大小写约定的Java原因 [英] Java reason for changing of package name case convention

问题描述

就在您说这是重复的之前，我已经看到其他问题了，我仍然想发表这个问题.

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

所以我正在阅读 Java中的思想-Bruce Eckel ，这一节是关于小写字母命名约定的:

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

在Java 1.0和Java 1.1中，域扩展名 com ， edu ， org ， net 等. ，按惯例大写，因此该库将显示为: NET.mindview.utility.foibles .但是，在开发Java 2的过程中，发现这会引起问题，因此现在整个程序包名称都是小写.

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?

我已经在Google上进行了搜索，但是得到的只是:为什么Java程序包名称要小写?:

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.

我也搜索了java package lowercase convention changed all-caps domain name，但无济于事.

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

那么，有谁知道为什么要在中途更改命名约定?

推荐答案

只是一个疯狂的猜测，而不是基于任何可靠的来源:程序包名称与文件系统目录结构相关.如果其中包含NET的软件包名称，可能会引起问题.区分大小写的文件系统中的源树被复制到不区分大小写的文件系统上，或在不区分大小写的文件系统上使用，并且由于任何原因，目录名都从"NET"更改为等效的"net".

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.

另一个潜在的问题是，它与类命名约定中的允许冲突.类通常是首字母大写的，但是对于例如首字母缩写为全大写，例如一个名为API或COM的类.这允许包和类命名约定之间有一些重叠.但是我的感觉是文件系统问题很可能是问题.

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.

这篇关于更改包名称大小写约定的Java原因的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！