I have checked the following posts already:
https://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.2
and SO post:
Is this a valid java package name?
and
What package naming convention do you use for personal/hobby projects in Java?
I tried creating a package like this:
package 01;
public class Test
{
// ...
}
When I compile I get this:
I:\code>javac 01\Test.java
01\Test.java:1: error: <identifier> expected
package 01;
^
1 error
I am looking for syntactical correctness of the name not the convention.
Is there a oracle/SUN reference that lists out the syntax for a package or does it follow the same rules as for variable names in java? May be a reference in the Java Language Specification saying package names follow the same rules as variable names.
Found it:
If any of the resulting package name components start with a digit, or any other character that is not allowed as an initial character of an identifier, have an underscore prefixed to the component.
In JLS 6.1 Declarations
This links to identifier grammar that Java uses, which applies everywhere identifier is mentioned, including but not limited to package name. So 01 is definitely not a valid package name, since it's not a valid identifier.
Related
I want to create a package named form validator.
Is it better to write
form_validator,
formValidator or
formvalidator?
I want to mention that I want to avoid form.validator. And that form-validator is forbidden.
From the documentation on package naming convention:
Package names are written in all lower case to avoid conflict with the names of classes or interfaces
So this would leave you with the following two possibilities:
form_validator
formvalidator
Actually the documentation also makes it clear that underscore plays a special role when it appears in package names:
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" ... the suggested convention is to add an underscore.
So, underscore is suggested only in special cases, into which your naming problem does not seem to fall. So I would recommend formvalidator as the package name.
The most conventional one would be the 3rd one: formvalidator.
The Google Java Style guide notes:
5.2.1 Package names
Package names are all lowercase, with consecutive words simply concatenated together (no underscores). For example, com.example.deepspace, not com.example.deepSpace or com.example.deep_space.
As #teppic said, the Oracle Java Docs state that
Package names are written in all lower case to avoid conflict with the names of classes or interfaces.
In Java package names are written in all lower case. Which means following would be the most ideal packaging name.
formvalidator
This is also accepted.
form_validator
Package names are written in all lower case to avoid conflict with the names of classes or interfaces. So
form_validator or
formvalidator.
For details see here.
I'm using IntelliJ Idea and I wanted to move some classes related to data import from foo.bar into a new package which I named foo.bar.import
Idea creates new package for me, but doesn't let me move anything into it. I've tried dragging and also Refactor->Move
I know that import is a reserved word in the source code, but I couldn't find any reason, why I couldn't name a package like this. Is this a bug in Idea or is there some restriction in java language?
The java language specification defines a package name as a sequence of identifiers, and identifiers are defined
Identifier:
IdentifierChars but not a Keyword or BooleanLiteral or NullLiteral
Because import is a keyword, it is not a valid identifier and so cannot be used as a segment of a package name.
As #4Castle points out, package names are composed of identifiers, which cannot contain keywords. import is a keyword.
I can suggest an alternative package name: for.bar.domainmodel.dataimport
This question already has answers here:
Why are modifiers allowed for a package when they don't seem to do anything?
(2 answers)
Closed 9 years ago.
Please see the sample:
private package com.xm.aws;
import static com.xml.aws.PcgTest.test;
public class PackageTest {
public static void main(String[] args) {
test(args);
}
}
What does the private tell me about the package?
Let's not confuse this with package-private or other access modifiers that can be added to classes, methods and fields.
The Java language specification clearly states:
6.6.1. Determining Accessibility
A package is always accessible.
Looking at that, the only answer, that comes to my mind is, that (some) compilers don't treat this as a compiletime error but that it is completely meaningless. It is not possible to restrict accessibility to a class or package that way (and every package is always accessible).
Another section from the java language spec:
7.4.1. Named Packages
A package declaration in a compilation unit specifies the name (ยง6.2)
of the package to which the compilation unit belongs.
PackageDeclaration:
Annotationsopt package PackageName ;
So the keyword may be preceeded by annotations. But the access modifiers is not part of the package declaration. And even if we expand on "Annotations" we won't find access modifiers here.
Another reference, according to JLS 18. Syntax the only thing allowed to precede package is an Annotation.
CompilationUnit:
[[Annotations] package QualifiedIdentifier ;]
{ImportDeclaration} {TypeDeclaration}
The code sample you have provided is not valid in java. The private access modifier can be applied to members and methods, including inner classes. Your code compiles in Eclipse, but is rejected by Oracle's own compiler.
In fact, the byte-code generated by Eclipse for this java code, is exactly the same with or without that private keyword. This shows that this is probably an Eclipse bug where it ignores the text before the word package during compilation.
What you have probably read or heard, is the phrase "package-private", which means that nothing outside the package can access the class or member. You do this by not using any access modifier on the class itself. Not by using the private keyword on the package.
If you add private before the package name this will be compiler error
Though package is not the highest degree of Encapsulation in Java which is achieved using private keyword, it still second best option and must to encapsulate whole functionality rather than just a class.
In short, Access modifiers are not part of the package declarations
Refer this link
Looks to me like it is only happening in eclipse. When i compile the code though javac command through command prompt, i get this compile time error:
error: class, interface, or enum expected
Looking at the post here, looks like eclipse uses its own jdk:
Do I need to install java sdk if I have eclipse
Writing "private package" and "package" is the same. They identify the same access level (the dafault one).
The private modifier specifies that the member can only be accessed within its own package (as with protected).
I could not execute my java program by a command line, although the Eclipse's "Run" menu executed it. While examining the problem, I happened to find that changing the name from HELLOWorld to HelloWorld fixed the problem for my particular case. Does really Java's naming rule restrict such names?
Your file name must match to the public class name that you defined in that file. May be this might be the case in your scenario.
The Java Language Specification states the requirements for a class name (which is an Identifier). To sum it up: it must begin with a letter or underscore, and the remainder may contain letters or digits.
Thus, HELLOWorld is a valid classname, however, if your class is public, the filename and classname must match (you will receive a compilation error otherwise).
in one word, Yes
public class name must be same as class file name
Yes. The name of your public class must be same as the name of your filename i.e .java file.However you may have number of other classes also.
I am writing a simple program:
class Demo{
public static void main(String[] args){
system.out.println("Hello");
}
}
on compilation it gives an error: package system not found.
Why it do so that package not found instead system is a misspelled class name.
System.out.println("Hello");
You need a capital S
Package names are lower case like java.lang.SomeClass, since it's lowercase it assumes you're looking for a package named system.
Why it do so that package not found instead system is a misspelled class name
When you say something.somethingElse the compiler assumes you are doing a packageName.classname. In this case you were intending to access out of the System class, but you could very well be trying to access a package called system that is not present (in the classpath for instance). So it is a guess from a compiler.
And (I guess) it is so because this is the better guess. Let's say the compiler said class not found. You might be happy. But tons of others doing Java.util.List (instead of java.util.List) would complain "I was trying to access the java.util package but misspelled it. The compiler wrongly says Missing class name.
Update (for the sake of completeness)
From #paxdiablo's answer below:
The reason why the compiler is assuming it's a package name rather
than a class or variable name lies in section 6.5 of the JLS,
"Determining the meaning of a name"
It's System with a capital S:
class Demo {
public static void main (String[] args) {
System.out.println ("Hello");
}
}
The reason why the compiler is assuming it's a package name rather than a class or variable name lies in section 6.5 of the JLS, "Determining the meaning of a name":
The meaning of a name depends on the context in which it is used. The determination of the meaning of a name requires three steps.
First, context causes a name syntactically to fall into one of six categories: PackageName, TypeName, ExpressionName, MethodName, PackageOrTypeName, or AmbiguousName.
Second, a name that is initially classified by its context as an AmbiguousName or as a PackageOrTypeName is then reclassified to be a PackageName, TypeName, or ExpressionName.
Third, the resulting category then dictates the final determination of the meaning of the name (or a compilation error if the name has no meaning).
Your particular use is an AmbiguousName, due to 6.5.1:
A name is syntactically classified as a MethodName in these contexts: (1) Before the '(' in a method invocation expression; (2) some other irrelevant contexts.
A name is syntactically classified as an AmbiguousName in these contexts: (1) To the left of the '.' in a qualified ExpressionName; (2) To the left of the '.' in a qualified MethodName; (3) some other irrelevant contexts.
Based on your code, system.out.println(whatever) is a qualified MethodName preceded by an AmbiguousName. Later on in the process, 6.5.2, the reclassification, mentioned earlier, takes place:
If the AmbiguousName is a qualified name, consisting of a name, a '.', and an
Identifier, then the name to the left of the '.' is first reclassified, for it is itself
an AmbiguousName.
If the name to the left of the '.' is reclassified as a PackageName, then if
there is a package whose name is the name to the left of the '.' and that
package contains a declaration of a type whose name is the same as the
Identifier, then this AmbiguousName is reclassified as a TypeName.
Otherwise, this AmbiguousName is reclassified as a PackageName.
A later step determines whether or not a package of that name actually exists.
Because the reclassification walking up the tree (from println towards system) never results in a TypeName, the default reclassification to PackageName is always done.
That's why the error message you see is about a missing package rather than a missing class.
THe only error in this code is that you have written small s instead of capital S in System.out.println("Hello");
The most case in which you get an error Package system not found in system.out.println(" "); is because, you have to give your file name as "nameofpublicclass.java".
In this example, file name must be "Demo.java".
I think that will solve the error.
The compiler says system package not found...
Because it can't find a package called system ( starting with a lower case s.)
It might be able to find one called System, but that's not what your code asked for.
The compiler almost never guesses.