I have the In package from Princeton loaded into the same directory as my files, and I compiled it.
And, I use the package in my code. But, when I use import In; somehow I still get an error?
java:7: error: '.' expected
import In;
^
What is the solution to this silly problem?
The code you linked to has no package.
Just delete import In, and somewhere in your code create an instance In myIn = new In(myUrl);, and you should be good.
Alternatively, modify your copy of "In.java" and make it the same package as you're using for the rest of your code.
Look at the main() in the code for examples of how to use class "In".
In order to fix this problem, you either need to add a package declaration to In.java that is the same as your package (and then simply omit your import statement), or (my recommendation) you need to add a package declaration to In.java that is different than your package (and move it to the corresponding folder), and then import In by the name of the package that you've given it.
To make this more concrete:
Add the following to the top of In.java:
package edu.princeton.cs.introcs.in;
Then move it to the corresponding "edu/princeton/cs/introcs/in" directory.
(Create it if it doesn't exist).
Then, in your file, import it by its qualified name:
import edu.princeton.cs.introcs.in.In;
Note that, in both of the cases above, you'll need to compile In.java along with your code that uses it (or you need to compile In.java, first, and ensure that it is on the classpath when compiling your code that uses it), and at runtime, you need to bundle In.class with your code (e.g. in the JAR you produce) or similarly guarantee that the byte code for that class (either the .class file or a JAR containing the .class file) are on the class path when executing your compiled code.
Related
Recently started studying Java for an exam.
While learning packages, tried this and got an error message. What I did was
//Creating class A (Within package the package: com.test.helpers)
package com.test.helpers;
public class A {
public void sayHello(){
System.out.println("Hello World");
}
}
//And then the class App utilising the class A
import com.test.helpers.*;
public class App{
public static void main(String args[]){
A a = new A();
a.sayHello();
}
}
I had both of these files in a directory called 'JavaTest' (on Windows 7), and first compiled the A.java using the command javac -d . A.java
And then, while attempting to compile App.java, I got the following error message:
App.java:5: error: cannot access A
A a = new A();
^
bad source file: .\A.java
file does not contain class A
Please remove or make sure it appears in the correct subdirectory of the source path.
1 error
However, the problem seems to resolve in two ways,
Deleting the Source file A.java
Changing the import statement from import com.test.helpers.*; to import com.test.helpers.A in the file App.java.
I'd be highly grateful if you can explain what happens here. Or I might be making a goofy human mistake or a syntax error.
Here's the link to the source files
Hi the problem here is that the JVM confuses the class file due to the ambiguous class file name in both the directory (the JavaTest as well as the com.test.helpers directory).
when you do javac -d . A.java the compiler makes a class file in the directory com.test.helpers and now it confuses it with the sourcefile there in JavaTest
Deleting the Source file A.java
When you delete the source file A.java from JavaTest, JVM knows now that the class file in com.test.... is to be used, ambiguity goes away.
Changing the import statement from 'import com.test.helpers.*;' to 'import com.test.helpers.A' in the file, 'App.java'.
Here you are specifying which particular file to use in your class implementation that is you are telling the compiler to use the file A.java from com.test... and not from JavaTest package
Now, the solution for this ambiguity to not ever be a problem for you, you must import the specific files with import statement i.e. import com.test.helpers.A; or if you want to do import com.test.helpers.*; then you must specifically use com.test.helpers.A in place of A everywhere in your current class implementation to tell the compiler not to confuse it with the source at JavaTest
I know it's a lot late for this particular answer, but I wanted to share my views for the upcoming readers, if it could help them in any way, it would be great.
Thanks!
move the A.java under folder JavaTest to com/test/helpers. the error you are seeing is for the compiler complaining that A.java is in a folder that does not match its package declaration. Remember, you cannot access A from App without A being in a package.
from under src driectory run the following command to compile your classes
src> javac ./*.java ./com/test/helpers/*.java
then from under src folder
src>java App
that should run your program.
the file A.java should be in the path JavaTest\com\test\helpers\A.java
and don't forget to compile it like this:
javac -d . com\test\helpers\A.java
every thing is in right place, java does not ask to put your A.java file, in the helpers folder
the whole reason why your code ran with the A.java file removed and not otherwise is:
when your app.java (or the main java file which is importing other classes in it, -->) is in a default package then while importing the classes it gives priority to the same directory and not to the package directory(if there exist any file that has the same name as the class file -> and thats why it gives error bad source file A.java -> as it wanted A.class)
And because of that there is a rule in java : That never place a .java file (of the same name)in parallel to the packages
so to solve this problem you have to either remove the file, A.java
or rename it (to any other name that does not present in the package)
or you can use fully qualified import statement
I have the same problem finally,
I was solved.
//Use like this
import com.test.helpers.A;
If u have a more than class in com.test.helpers then u can use import com.test.helpers.*;
If you are not using an editor with auto-save, it might be helpful to check if the code you have written has actually been saved to the java file previously created
The bad source file error may be wrong if it is preceded by another error (below) which, in my case, provided guidance for how to fix the real problem. From my log file:
Error 1: a\g\GoodClass error:duplicate class: a.g.GoodClass //Not the problem
Error 2: a\b\BadClass error: cannot access GoodClass //The problem
bad source file: a\g\GoodClass //No, it's fine
file does not contain class x.y.GoodClass //How to fix it
Please remove or make sure it appears in the correct subdirectory of the sourcepath.
Java reports the first line of Error 2 because BadClass is using a wildcarded import, either import x.*; or import x.y.*;.
THE FIX: remove the wildcarded import from BadClass and add only the specific imports you need from library x.y.
So I made a folder called util and placed four classes along with program named unit10Assignment in it. I created a package util and typed " package util; " at the top of each one of the classes code like this:
package util;
public class Employee
Then i wrote:
import util.*;
import javax.swing.JOptionPane;
public class unit10Assignment
On top of the program. However when I compile it, it tells me. Anyone know why? I tried playing around with it and it disappeared when I typed in import java.util*; instead but I'm not sure that what my teacher wanted as her example did not have the java in front.
It also says " bad source file" "package does not contain class Employee " However, everything compiled and ran perfectly before I typed in the package statement and I have not made any change to the code since then. If I removed the package statement from the employee class tho, the same message would appear but it would say another class does not exist.
Thanks for any help
Note: whether or not i put java.util or just util, this problem with the bad source still appears.
thanks for any help
I'm going to make the assumption that you have your project set up like this:
util/
Employee.java
unit10Assignment.java
bin/
(If it isn't, that's fine - so long as they're in some folder. bin/ should exist, though.)
The way that packages work is that they're folders on the hard drive - the package you want to import requires that the folder and class you wish to import both exist in that specific folder. This is why packages are handy - you can have two classes named Employee and have them live in completely different locations.*
Here's how you compile these into a package-like structure without the use of an IDE. Substitute $HOME for the full path of your Java class folder.
javac -sourcepath $HOME/util -d $HOME/bin *.java
And here's how you run your main class:
java -cp $HOME/bin util.$MAIN_CLASS
A breakdown of what these flags mean:
-sourcepath instructs javac to look in this specific directory for your source files.
-d specifies an output directory for your .class files.
-cp instructs java to add this folder to its classpath.
*: Really, really large projects can often use the same name as other classes; if you wanted to use a specific one, you'd have to use the fully-qualified class name for it.
Make sure that:
the filename matches the class name (e.g. Employee.java for class Employee)
the files are inside the corresponding folder according to their package (i.e. util)
Are you using any IDE? If not, using one realy helps a lot with this kind of things.
Basically I wish to use the methods of a class within the Jar file, which looks like this:
Can somebody please tell me what I need to import in order to use those methods and variables?
You don't need to import anything.
Jar files aren't imported, they are added to the classpath.
From the screenshot you've posted, we can see that the myJar.jar file is included in your eclipse classpath, so there's nothing more to do there.
Classes are imported, if they are in a different package.
Your Examplew class is in the default package. BMIcalculator is also in the default package. Because they are the same package, you don't need to import it.
You should be able to simply make references to BMIcalculator from within Examplew. Just try it.
Try compiling this code - it should work:
public class Examplew
{
private BMIcalculator calc = new BMIcalculator();
}
You might get warnings about the unused private field, but you can ignore that for now.
If that doesn't work for you, then please post the error, because it doesn't look like the problem is with your imports (or your classpath)
Quote from this question:
You can’t use classes in the default package from a named package.
Prior to J2SE 1.4 you could import classes from the default package using a syntax like this:
import Unfinished;
That's no longer allowed. So to access a default package class from within a packaged class requires moving the default package class into a package of its own.
If you have access to the source generated by groovy, some post-processing is needed to move the file into a dedicated package and add this "package" directive at its beginning.
I'm not sure how to import a file from a directory above. That is, I have a setup like so
directory: MyProject
Main.java
directory: Other
Other.java
Basically, Main.java is in "MyProject" and Other.java is in a folder inside the project's root folder. I can easily do
import Other.*;
to get those files available in Main, but how do I get Main.java to be visible to Other.java?
import ../Main.java
Obviously this doesn't work, but that's the general functionality I'm looking for. Any suggestions? I would prefer not having to use absolute paths. Thanks!
Edit: I meant import not include. Sorry. Been using C++ too much.
Java does not include files. You can however directly use classes using the simple name by using import statements.
Basically you need a file per (top level) class you define. This allows IDE's to rename compilation units, and do other refactorings. Besides that, it lets you easily add code at the right spot.
Java does use packages to create namespaces. Packages themselves are completely separate namespaces. Although the namespace seems to be a tree structure, in Java each package is actually not related to any other package. Hence you cannot use it as a folder structure, using .. is not allowed. This may change once "super packages" are introduced.
The Java import statement looks a lot like #include, but the name change is deliberate: instead of grabbing the file to make the definitions in that file known, it is simply a statement to make it easier to refer to classes and interfaces. It has no other effect than having a shorter name to a class (or, for import static, constants and other static members).
Most of the time the top level classes are represented using a folder structure that reflects the package name. This makes it easy for IDE's and developers to find the file representing the class. It also makes it easy to put in version control. It is however not part of the Java specification itself; the location of Java source and classes is not defined. Earlier IBM IDE's actually stored Java source and classes in a database for instance; they did not use files at all. Newer IDE's such as Eclipse may use different source folders, e.g. one for Unit test files and one for the library itself.
So finally, the only way to include packages is by specifying the full package name, then a dot and then the class to import, or the * wildcard to import all classes of that package.
import java.util.Vector;
import java.util.*;
Most IDE's will create these import statements for you, possibly after you have chosen the right class to import (in case there are classes with the same name in different packages).
More information can be found in the Java Language Specification (Java 7 version).
In your case you have defined a Main class in the root or default package which is strongly discouraged. You can directly refer to Main without any import statement. The Other class is in the identically named Other package (using uppercase in package names is strongly discouraged as well). You can refer to it by using import Other.Other.
include ???
Java doesn't have file source inclusion support, it rather use a naming conversions, so you should import the namespace (package) that you need in your source file.
You should define a package for your main class and then import it in the Other class .
the Main.java is in the default package, this is impossible to import from other (named) packages
put it in a package and import as normal
directory: MyProject
directory: base
Main.java
directory: other
Other.java
(also package names are lowercase normally)
if you have file outside of your project it means this file:
wouldn't be compiled by project
wouldn't get into jar
can't be used in runtime
so you really shouldn't include it.
Either move it into project, or include dependent project which contains that file.
Java is not like C++. You include by package name. So if toplevel file is in project AAA in folder src/aaa then you should include that project as dependent jar and refer to file as import aaa.Main
I think import Main; should just work.
You should read up java concepts package and classpath. Please look at the documentation here. The options that will work for you are sourcepath and classpath.
I'm trying to compile a java file which imports other packages I created; however, it doesn't seem to find them.
In my compile.bat file I have:
set classpath=c:\t\DB;c:\t\Frame
javac comchange.java
where the beginning section of commChange.java has
package commchange;
import java.sql.*;
import java.awt.event.*;
import java.applet.*;
import DB.*;
import java.awt.*;
import java.util.*;
import javax.swing.*;
import java.awt.Graphics;
import Frame.*;
and the directory structure is:
c:\t\commChange.java
c:\t\DB
c:\t\Frame
The error I'm getting is:
commChange.java:12: package DB does not exist
import DB.*;
commChange.java:17: package Frame does not exist
import Frame.*;
commChange.java:23: cannot find symbol
symbol: class Frame
...
Any ideas?
classpath is the list of directory roots where classes, identified by package.ClassName, are loaded from. You need to set the following classpath:
set classpath=c:\t
I have a couple of remarks (as many things are actually wrong):
Traditionally, packages have all lower case names i.e. db, invoicechange, frame, etc.
Sun coding standards require classes to begin with a capital letter i.e. commChange should be named CommChange and the compilation unit should use the same name CommChange.java.
Source files should be arranged in a directory tree that reflects their package tree which means that invoicechange.CommChange should be located in C:\t\invoicechange\CommChange.java.
Once you'll have done these changes, you'll be able to compile your classes. To do so, either define the user class path explicitly in the CLASSPATH environment variable to include the root of the sources tree:
C:> set CLASSPATH=C:\t;%CLASSPATH%
And just call javac from the C:\t directory:
C:> dir
invoicechange/ db/ frame/
C:> dir invoicechange
CommChange.java
C:> javac invoicechange\CommChange.java
C:> dir invoicechange
CommChange.class CommChange.java
Note that if you don't set the user class path (and thus don't override the default class path), javac will use the current directory as default. In other words, calling javac from C:\t without setting the user class path in CLASSPATH environment variable will just work.
See Setting the class path for more details. Actually, you should also look at the documentation of javac. And reading the Sun coding standards previously mentioned would be a good idea too.
You have at least three big problems. First, the classpath needs to point to the "root" folder as mentioned in the first answer. When you import DB, then it needs to start looking in the folder called t. (It bothers me a little, though, that the error message you posted, lists Import DB.*; in the error message, with Import highlighted like a class name instead of a keyword.)
Second, there is no Frame package, so the import statement that tries to import Frame.* doesn't make any sense at all. If you want to import the Frame class you can import java.awt.Frame;, but you already have a wildcard import for the java.awt package so you don't need that.
Finally, the file comChange.java must be located in the folder C:\t\InvoiceChange, not in the C:\t folder. That's because it belongs to the InvoiceChange package.