Actually this is completely theoretic question. But it's interesting why java specification don't allow uppercase characters letters in package and cause write something like this:
com.mycompany.projname.core.remotefilesystemsynchronization.*
instead of
com.myCompanyName.projName.core.remoteFileSystemSynchronization.*
Directly from Oracle Docs
Package names are written in all lower case to avoid conflict with the
names of classes or interfaces.
But it's interesting why java specification don't allow uppercase characters letters in package and cause write something like this:
The specification allows it just fine. It's only a convention to use all-lower-case.
As gtgaxiola says, this does avoid conflict with type names... in .NET naming conventions this does happen, leading to advice that you do not name a class the same as its namespace. Of course, using camelCase packages would avoid the collision entirely.
I suspect reality is that it wasn't thoroughly considered when creating the package naming conventions. Personally I rarely find it to be a problem - if I end up seeing a package with one element of "remotefilesystemsynchronization" then the capitalization isn't the main thing I'd be concerned about :)
Its just another convention - One may ask why class name always has to start with Capital or method name starts with small case and then camel-cased. Java doesn't forces you to use that way. Its just that a set of underlined rules helps huge community as Java developers to write easily understandable code for the majority who follow conventions.
No definite reason can be assigned as such. Its just what felt good and was in practice by then majority programmers while writing the convention. But yes guidelines would definitely be there before writing conventions. I don't mean its a whimsical work. Guidelines are made so that just by looking at the various elements we should be able to tell if its class, method or package - and via following conventions it has been achieved for so long now.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Java has strong naming conventions for class, method, field and variable names.
For instance:
Class names should start with an upper case character
Methods, fields, and variable names should start with a lower case character
The JDK has only few exceptions to these two rules.
But a convention is not a syntax rule, and therefore classes like the following compile without errors (C# programmers would be happy anyway):
public class string {
private char[] C;
public int Length() { return C.length; }
}
But the gap between a convention and a syntax rule inevitable leads to violations of the convention by beginners which then leads to lengthy explanations about naming conventions.
If the most fundamental naming conventions (like the one cited above) would be part of the syntax then the Java compiler would enforce them and automatically educate those beginners.
So here is the question:
From the Java language designers point of view: Is there any good reason to leave a gap between syntax and naming conventions which should never be violated? Are there any meaningful use cases for namings (of classes, methods, fields, variables) which violate the convention but make sense beyond the convention?
The conventions were written long after the language was defined so they could be retrofitted without breaking compatibility. The problem with conventions are they involve taste. e.g. spaces or tabs, using $ as a variable name, starting field names with m_ or _ etc. even wither to add get and set to getters and setters (which I prefer not to)
Java actually allows you to do things which would make C programmer feel queasy. Why they allowed this I don't know, but I assume they didn't want to limit adoption by imposing more rules than really needed.
Note this is a piece of Java code is valid due to the use of a character which probably shouldn't be allowed but is.
for (char ch = 0; ch < Character.MAX_VALUE; ch++)
if (Character.isJavaIdentifierPart(ch) && !Character.isJavaIdentifierStart(ch))
System.out.printf("%04x <%s>%n", (int) ch, "" + ch);
Most IDEs will help beginners write code which follows conventions. The only problem with this is most developers don't know how to make full use of their IDEs. ;)
Well, personally I think the reason for not enforcing conventions is simply because of the fact because it's technically not really necessary. Counterexample: E.g. in Java you have to name the class file exactly like the class because the Java Class Loader could not load it otherwise. Building these checks into the compiler would bloat the source code and as the name tells it, a compiler converts source code into machine code / byte code / whatever by parsing the source files and checking the syntax. Checking whether a class starts with an uppercase or lowercase letter is simply not the compiler's job.
And of course a programming language gives you a certain degree of freedom by not enforcing such things as conventions to style your code how you like it if it matches the syntax rules of the language.
Well, if I use some Chinese characters in identifiers, there are no upper/lower cases for them:) So the convention cannot be always enforced.
Of course, it's pretty safe to bet that 99.9% Java code are in English. And you may also argue that the enforcement can be limited on some charsets only.
I agree that this naming convention has become critical, and it should be strictly followed. A java source code that does not follow the convention is practically incomprehensible.
From the Java language designers point of view: Is there any good reason to leave a gap between syntax and naming conventions which should never be violated?
Yes. "Never" is a strong word.
The language has requirements and recommendations. The language specification for identifiers is a requirement. But those strong naming conventions are recommendations.
Having some definition of identifiers is necessary for the compiler to recognize them as tokens. Leaving that definition looser than the norm gives us a little freedom for cases outside the norm.
Are there any meaningful use cases for namings (of classes, methods, fields, variables) which violate the convention but make sense beyond the convention?
Yes. Java programs can interact with other languages, which have different conventions.
Code conversion
Sometimes when hand-converting code from another language, leaving the original case is easier and more understandable.
Code generation
Sometimes we generate code from a specification that was not written for Java. For example, we might generate code from a WSDL file, or generate wrappers using SWIG.
Code wrappers
Some Java methods can wrap external functions. For example, JNA allows defining interfaces with a native function's name and signature.
JVM languages
Multiple languages can run atop the Java virtual machine. These other languages have their own conventions. It's possible to mix languages in a single program. Stepping outside the convention can be necessary to interact.
I guess this is why it's only conventions and not rules... I don't see why should it be enforced, there are many other conventions which are not enforced (e.g. putting constructors before alother methods, putting public methods before private methods and many more), it would be too strict (in my mind at least) to enforce it all.
I can think of one case you don't want this convention to be enforced - it's also common to write consts variable in uppercase- again, just a convention.
In any case, I think that in most IDE's you can configure it to give a warning when such conventions are violated. this can help you I guess
Today I was naming a package in a project which would contain code related to a concept called an "access structure".
Now, naming this package "com.myemployer.project.component.accessstructures" seems unappealing and difficult to read because of the triple "S". (The higher level packages are not actually named "project" and "component").
I was tempted to use "...component.access_structures"
I couldn't find anything mentioned in the Java conventions on Oracle's site . And a brief web search brought up nothing.
What is the official convention for names like this?
From Oracle Docs
Package names are written in all lower case to avoid conflict with the names of classes or interfaces.
Companies use their reversed Internet domain name to begin their package names—for example, com.example.mypackage for a package named mypackage created by a programmer at example.com.
Name collisions that occur within a single company need to be handled by convention within that company, perhaps by including the region or the project name after the company name (for example, com.example.region.mypackage).
In some cases, the internet domain name may not be a valid package name. This can occur if the domain name contains a hyphen or other special character, if the package name begins with a digit or other character that is illegal to use as the beginning of a Java name, or if the package name contains a reserved Java keyword, such as "int". In this event, the suggested convention is to add an underscore
Although this text doesn't specify your exact case, it does say that for an invalid package name we should use an underscore. One could argue that accessStructures is how we would define a method in Java and thus naming a package like that could be confusing.
Overall, it is really up to you.
If you want to keep with this convention, I believe you should name your package:
com.myemployer.project.component.access_structures
Also you can look up synonyms and find alternatives that would give less confusion. Some I quickly found:
accessframework
accessfactory
accessarch (accessarchitecture)
accessconstructs
I dont think there is any standard for that. People follow different naming conventions as per there convenience and readability. But most of the programmers find camel case naming as the most convenient. You can name it like accessStructure
Found one Oracle Doc which recommends to use the package name with all small letters
Package names are written in all lower case to avoid conflict with the
names of classes or interfaces.
According to docs you can't use camelCase for package naming. It's ok to use snake_case for package naming in some cases, but it is more appropriate if you can't use your domain properly, because of the hyphen sign in it or it starts with numbers. But it has to be rather an exception from the rule than the rule.
If I were you I would rephrase it. For example: accessstructures -> accesscore
arraylists, buffered reader, scanner, etc.. all "Default" classes that "already exist" in the language..
unlike, say, public class widthOfTable which would be a "made up" class , that " did not already exist in language"..
why is there no term to distinguish these ideas when teaching? I barely discovered this difference in college , despite being here 3 years.
Actually, there is a pretty strong distinction between what you called "default" and "made-up" classes, which has to do with their package names.
All "default" classes are in some java.* package (java.lang, java.util, etc.), and no "made up" class could use a package name that starts with java..
As for the fact that this distinction is blurred "when teaching", my feeling is that it's intentional. Java as a language is pretty much a set of keywords and syntax rules plus a java.lang.Object class that nobody could avoid extending (and which uses a few other built-in types like String, Integer and some exceptions).
The JDK is a Java library to help you with the most common use-cases, but in some cases there are better alternatives.
In my opinion, it would be a mistake to teach someone that java.util.Calendar or the java.util.logging stuff have any advantage over JodaTime or SLF4J just because they're in the classpath by default.
I had the same question in my mind before and i had a different term for your word default and I called them built-in classes.
why is there no term to distinguish these ideas when teaching?
there is already but taught indirectly using the terms packages and namespaces
if there is a time that you will design a programminng language you can tell any developer what are those default or built classes by putting them in right packages and namespaces for example
mydefaultclasses.io.print
mydefaultclasses.io.read
in java its really understandable that any classes under java namespace is a default or built-in class. it really depends upon what will came up on the documentation of the language you are trying to learn.
Not sue if I totally understand your question, but you can find all the predefined classes in Java under the Java Class Library: Java Class Library.
Actually it is more powerful to have packages or namespaces. Your way of thinking is like an implementation that only supports two namespaces. The standard library (in this case the java.*, in c++ std) is one, the other is all your other stuff. After a while, you probably end up with a new set of "default" classes anyway and you put those in a package to avoid clutter your global namespace.
I've seen lots of examples like com.mycompany.someapp. Seems to be the reverse of the domain. Which actually makes sense to me.
But at the end of the day, does it really matter? We are a small shop so maybe we don't see the benefits of proper domain naming.
So, is it good practice to name it to match the domain? If so, why?
Extracted from the link to Naming a Package (Java Tutorial) in Andrew's comment: (I claim no originality or ownership of the following).
Naming a Package
With programmers worldwide writing classes and interfaces using the Java programming language, it is likely that many programmers will use the same name for different types. In fact, the previous example does just that: It defines a Rectangle class when there is already a Rectangle class in the java.awt package. Still, the compiler allows both classes to have the same name if they are in different packages. The fully qualified name of each Rectangle class includes the package name. That is, the fully qualified name of the Rectangle class in the graphics package is graphics.Rectangle, and the fully qualified name of the Rectangle class in the java.awt package is java.awt.Rectangle.
This works well unless two independent programmers use the same name for their packages. What prevents this problem?
Naming Conventions
Package names are written in all lower case to avoid conflict with the names of classes or interfaces.
Companies use [their] reversed Internet domain name to begin their package names—for example, com.example.mypackage for a package named mypackage created by a programmer at example.com.
Name collisions that occur within a single company need to be handled by convention within that company, perhaps by including the region or the project name after the company name (for example, com.example.region.mypackage).
Packages in the Java language itself begin with java. or javax.
In some cases, the internet domain name may not be a valid package name. This can occur if the domain name contains a hyphen or other special character, if the package name begins with a digit or other character that is illegal to use as the beginning of a Java name, or if the package name contains a reserved Java keyword, such as "int". In this event, the suggested convention is to add an underscore. For example:
Legalizing Package Names Domain Name Package Name Prefix
hyphenated-name.example.org org.example.hyphenated_name
example.int int_.example
123name.example.com com.example._123name
Happy coding.
Matching the domain gives you greater confidence against name collisions. It's probably more important to designers of 3rd party libraries than you and your app.
Yes, that's the suggested convention in the Java Language Specification, section 7.7.
If unique package names are not used, then package name conflicts may arise far from the point of creation of either of the conflicting packages. This may create a situation that is difficult or impossible for the user or programmer to resolve. The class ClassLoader can be used to isolate packages with the same name from each other in those cases where the packages will have constrained interactions, but not in a way that is transparent to a naïve program.
You form a unique package name by first having (or belonging to an organization that has) an Internet domain name, such as sun.com. You then reverse this name, component by component, to obtain, in this example, com.sun, and use this as a prefix for your package names, using a convention developed within your organization to further administer package names.
You don't have to follow the convention, but it's generally considered good practice. After all, suppose at some point in the future you want to release some of your code as open source - but you want to avoid naming collisions. At that point, you really ought to follow the same conventions as everyone else - and as it doesn't hurt to do so from the start...
The idea behind using domain name is to avoid namespace collisions in packaging. This only works if everyone follows the convention. So, yes, the convention is important. That said, if you never plan on exporting your code as an API or providing it to a third party, it's likely there is little downside to using whatever package name you feel like.
Practically speaking I like it for a number of reasons:
It gives users an easy place to go to just from looking at the package name
It avoids collisions between packet names (i.e. two "media" packages could be very likely otherwise)
It helps identify the same author over separate pieces of software
It keeps package names roughly the same length (ok, this is just an aesthetic point but I like it!)
As well as this, it's also recommended in the JLS. It's not a requirement, but when it's practically 0 effort to do, I'd do it unless there's a good reason otherwise.
Perhaps a better question to ask is why don't you want to follow that convention? If there's no real reason, there's no harm in following it!
The main aim is to guarantee uniqueness of package names, but if you're never going to release code for others to use then it probably doesn't matter, but there is a lot to be said for sticking with convention and worrying about the stuff that does matter. Otherwise come the day that you realise you have a great library that you want to share you could be kicking yourself for going against the flow.
Yes, it is sensible to always use a naming scheme. As a counter-example, assume that everyone would use the default package for their classes.
Common classes like User or Address would be used by several libraries, but in the end there can be only one class of a certain name in the runtime environment. (loosely speaking, it is not completely correct.)
In big projects you will likely use many external libraries, like Apache Commons, Google Guava, Spring, Hibernate, Terracotta. It's good that these libraries all use their own namespace, so that their internal classes do not accidentally conflict.
I'd like to define an interface called Tag in a Java package I am working on, but am hesitant to use such an ordinary-sounding name because of the collision issue. (e.g. you can import only one class or interface with a particular name; if there are more than one that share the same name, you can use import for one of them, but the rest you have to explicitly refer to with the entire package name e.g. com.yoyodyne.games.outdoors.Tag)
I also don't really have a more detailed name for it (it's supposed to represent a tag like the tags in StackOverflow posts or other online websites); the closest I can think of is maybe TaxonomyTag.
Are there strategies for dealing with this? The only one I can think of is to define a static class (like Collections) that contains a public interface Tag, e.g. if I call it Taxonomy then I can import Taxonomy and refer to Tag as Taxonomy.Tag -- but that doesn't sound much more helpful.
edit: one widely-known example of this collision is ca.odell.glazedlists.matchers.Matcher and java.util.regex.Matcher which is a pain if you are trying to use regular expressions with the GlazedLists library.
I don't see a problem with naming the class Tag. Your package name makes it universally unique and that is one of the purposes of packages - to resolve naming conflicts.
Even within the Java API there are multiple classes with the same name: java.util.Date, java.sql.Date for example. If you need both in your code then use the fully qualified name.
How many people are going to be using this class? If it's meant to be a general purpose library, I would go with a less-generic name to avoid collisions. If it's just you, and you really don't bite the bullet and go with fully-qualified names for now.
If it becomes a problem before you release the package, just refactor it to a new name.
In similar situations I have found some alternate name for short class names because I hate using FQNs. Even something like JasonSTag can work as a temporary fix; just don't release it that way. Often halfway through implementation I'll find a better way to describe the class, something more descriptive than "Tag".
Are you being lazy? If your class is using imports such that "Tag" could be misconstrued by someone reading your code, even momentarily, then it is worthwhile to think of a better name, despite the package naming convention. Don't underestimate the power of naming---or renaming as the class changes.
I wouldn't really be concerned with this.
What you should be concerned with is how well your class/interface name matches what the piece of code actually does. If Tag succinctly describes what the class/interface does and/or is meant to model, then I think it is a great name.
I can't really see the situation where you'd be using this Tag type in the same class along with other Tag types declared in different packages. But, if you have to, then it's not really that much of a pain to refer to the other Tag types by their fully qualified name.
I believe that how well you named something is greater than making things convenient.
The best strategy is to write classes which do one thing well. These classes do need the minimum of imports, so you have the reduction of import statements.
I looked for standard Tag interfaces; found one in java.swing..html, another one deep in servlet API, and another in tapestry library. I am sure that your class should not directly use one of these (or similar APIs), so you may not be afraid of namespace pollution.
Other solution is to prefix tag with the object it will be used on. E.g. ArticleTag. But you must carefully choose the object name. Or, anyway, you can always refactor it later.
Generally the number of conflicts, even with "ordinary" sounding names, is low. I'd chose a meaningful name within the context of the package.
Do not do somethiong "silly" like prefix it with the company name, eg: YoYoDyneTag.
It has gone out of style to use adjectives/adverbs as interface names recently, however, in your case it wouldn't sound that bad if you used 'Tagable' or 'TaxonomyTagable'.
This only tend to be a problem if you need to use more than one class with the same name in a single class. Examples: java.awt.List and java.util.List, java.util.Date and java.sql.Date.
If you stay away from those already used in the standard Java runtime you will most likely not have a problem.
Whatever you do - make the name you choose a good and descriptive one - this goes especially for those in a public API. You will live with them forever.