I'm talking about the import statements at the top.
Eg:
import java.util.Scanner;
import javax.swing.JFrame;
So, can I just say that:
Anything that starts with a lower-case letter (java, util, javax and swing here) is always a package and everything that begins with an uppercase is always a Class (which may be followed by an Inner class in some cases).
That's not necessarily true, as you can create classes starting with lowercase letters and packages starting with uppercase letters, but it is generally good practice to follow the Java coding conventions.
These dictate that what you said should be true.
If you look up Java naming conventions on the Oracle site, you will see that package names should, by convention, start with a lower-case letter and class names, method names, interface names, and others, should, by convention, start with an upper-case letter. This allows you and anyone who reads your code later to know what statements are imports of packages (although the import keyword makes it obvious) and where you have classes and methods. It also makes your code appear neater aiding readability. You could say that it allows your one's brain to compile what it is reading faster. For example, seeing a constant value in all caps like static final int MIN_WIDTH = 4; makes it much easier to understand what is going on.
I would like to point out that the information is relatively easy to find via google and there are other questions on Stackoverflow that would have the answer to your question. Please do your research in the future.
If the naming conventions have been followed and we are not talking about static imports, then what you say is true.
With static imports you can import constants and methods as well.
import static java.lang.Math.PI;
import static java.lang.Math.cos;
Related
I am a novice high school Java programmer and I am having an internal conflict as to which of the following methods is more efficient in Java. If you are importing a single class in Java, is it more efficient to import it as per usual, e.g., import java.util.Scanner; or to use that import statement as part of the Scanner's declaration, as in java.util.Scanner scan = new java.util.Scanner(System.in);.
I know the first is more common and looks nicer, but what if you only need one scanner object? I am sorry if this question is a duplicate; I did not know how to properly word this question in my searches to see if it already existed.
import statements create a compiler-time alias to the symbol imported. That is, it's just a shortcut for typing the full name out - it has no effect on the program while it's running. The compiled code is identical in both cases.
There is no added expense to importing a class, so it makes sense to put all of your imports in the header where anyone looking at your code can easily see what classes are utilized in the program. If you decide later that you want to have more than one scanner object or more than one class from java.util you can use import java.util.* as well.
Pick the more readable of the two. There is no difference in performance, at the end of the day they both get compiled to exactly the same bytecode.
The efficiency lies in how often you might need to write out the package/class/symbol path to the type. If you are certain that you will use it only once, not using an import would work.
But, that is the only upside. There are multiple downsides to avoiding an import statement, including readability, ease of seeing which classes are used in this code file, and extra typing if adding more references becomes necessary. The compiler is completely neutral in all of it, as source either way will compile to the same JVM code.
I can't understand why I'm getting the following error - cannot find symbol - class Line2D - when I try to compile this code:
import java.awt.*;
public class KochSegment
{
public Line2D base = new Line2D(); public Line2D[] Lines = new Line2D[4]; //error is on this line
etc.
}
It's in a subpackage:
java.awt.geom.Line2D
So you'd need either
import java.awt.geom.Line2D;
or
import java.awt.geom.*;
Some lessons that should be learned from this:
Star imports only import classes from a package. They do not import from sub-packages as well. In fact, sub-packages in Java are purely syntactic. As far as the Java language is concerned, there is NO semantic relationship between classes in different packages or sub-packages.
Star imports tend to obscure problems. A lot of people recommend not using them. Write the imports out in full. Or better still, use an IDE that can do classname completion, and generate missing imports. (Granted, you do need to be a bit careful when for example the IDE offers you multiple completions for (say) Date or List.)
Searching and reading the javadoc is a good way to help with problems like this. A javadoc search (or a class list scan) would tell you what the fully qualified name for the Line2D class is.
I don't like the fact that in scala its not obvious what some of my imports are doing - imports for implicits so i'm trying to come up with good naming conventions for them so when i see in my import statements something like:
import com.mycomp.example.RectangleImplicits
or
import com.mycomp.example.RectanglePimper
I know i cant remove that import because its being used for pimping.
My problem with the above names is that sometimes I actually do an adapter, in that case
import com.mycomp.example.RectangleAdapter
does not say anyting about the fact that its actually a pimper however i don't want to name it RectangleAdapterPimp because the name becomes to combersome...
is there a golden bullet naming convention for that?
thanks
In std Scala library such classes are prefixed with Rich, like RichString, RichInt, etc... So why not to use RichRectangleAdapter
My question is very basic. I wanted to use the randomX in my java code.
jgap.sourceforge.net/javadoc/3.01/org/jgap/util/randomLEcuyer.html
sample code from here:
https://code.google.com/p/fractalproject/source/browse/FractalProject/src/org/dla/model/DlaModel.java?spec=svn40&r=40
I am already using another package, lets say MyProj, with other files of my current code.
I used the following lines,
package MyProj;
import org.jgap.util.randomLEcuyer
But eclipse does not recognize the randomLEcuyer. I appreciate if you help me.
First of all, you have two package declarations in your code:
package MyProj;
package org.dla.model;
This is invalid. Second, the class you want to use, as the javadoc you linked to indicates, is org.jgap.util.randomLEcuyer, and not org.rda.dice.randomx.randomLEcuyer.
Finally, I would be careful in using a class that doesn't even respect the basic Java naming conventions: classes should start with an upper-case letter.
Recently i cam across a statements :
import static java.lang.System.out;
import static java.lang.System.exit;
I read these statements in some tutorial. Are these statements O.K ?
If the statements are alright what do they mean and should they be used regularly while writing code ?
They are called static imports. The effect is to allow you to use the names out and exit in your program as if they were defined in the current scope; so you can write exit(0) instead of System.exit(0).
Now, are they a good idea? Sometimes, when used sparingly, they are a good way to reduce clutter. But most of the time, they actually just make your code harder to understand. The reader will ask "Where is this out defined?" and "Where does exit() come from?" In general, you should avoid them.
But if you're writing a class that's all about processing SomeReallyLongName objects, and SomeReallyLongName defines a bunch of FINAL_CONSTANTS, importing them with static imports will save a lot of typing and a lot of clutter, and it will be pretty clear where those constants are coming from.
They are static imports. It allows you to do something like exit(0) instead of System.exit(0).
I do not recommend this for well known Java classes because it can be confusing to some. But sometimes it is useful for utility classes like Guava.
Iterables.filter(list, SomeClass.class)
is very verbose but you can make it easier to read with static imports: filter(list, SomeClass.class)
You should check with your team to see what they code guidelines are and try to be consistent.
Yes,it is perfectly alright .
This is known as static import.This allows members defined in class as static and
public to be used without specifying the class in which the field is defined.
This feature was defined in J2SE 5.0.
For example :
import static java.lang.Math.*;
import static java.lang.System.out;
// in main
out.print( max(100,200) ); // prints 200.You didn't have to use Math.max(.,.)
I think it may not be a good idea to use static imports as it'll make your code hard to read.
Yes, these statements are referred to as static imports and are perfectly valid. Take a look at the javase guide on static imports for more information.
With respect to usage, the guide states:
So when should you use static import? Very sparingly! Only use it when
you'd otherwise be tempted to declare local copies of constants, or to
abuse inheritance (the Constant Interface Antipattern). In other
words, use it when you require frequent access to static members from
one or two classes. If you overuse the static import feature, it can
make your program unreadable and unmaintainable, polluting its
namespace with all the static members you import. Readers of your code
(including you, a few months after you wrote it) will not know which
class a static member comes from. Importing all of the static members
from a class can be particularly harmful to readability; if you need
only one or two members, import them individually. Used appropriately,
static import can make your program more readable, by removing the
boilerplate of repetition of class names.
Static imports are a new feature added in Java 1.5
The static import construct allows unqualified access to static members without inheriting from the type containing the static members. Instead, the program imports the members, either individually
There is nothing wrong with your example if you want easy access to out and exit so that you can call them directly as out.println() for example. There is nothing syntactically incorrect about it nor from a style aspect though some may argue it is "confusing" and hard to figure out where out came from, but any modern IDE can help them figure that out.
These are static import concept.These are like simple imports but having different type of concept.See here you import one function exit() and one field out and both are static in their corresponding classes(in case both here Systen is their class).After this instead of writing System.out.println() you can simply write out.println().Similarly instead of System.exit(),you can write exit().