Trying to compile a multi file package. Needing to compile via: javac mainfile.java while also compiling all the other (about 4 other .java files) at the same time through the one file? I have tried using statements like extend and import package.* Any help would be appreciated.
I have used different compiling methods and arguments but trying to do it just by only inserting javac mainfile.java and java mainfile
Summary: Trying to compile multiple java files at once, through java compiling a single file.
My current code for the main file:
package mypackage;
import mypackage.*;
public class mainfile{
public static void main(String[] args) {
Myfile.main(args) //run main from other file
}
}
Edit: Sorry for the lack of information, when compiling, the compiler returns:
MainFile.java:15: error: cannot find symbol
Myfile.main(args);
^
symbol: variable Myfile
location: class mainfile
1 error
javac as a tool does not do what you want. But, that's why other tools exist.
What you're asking for boils down to 'I want a build system'. The vast majority of java projects use maven or gradle.
It would seem like this works fine:
javac -sourcepath src src/mainfile.java
but you'd be deceived. That will merely compile all source files that are directly referenced by the code in mainfile.java, but there are many other ways to refer to code, such as SPI, reflection, XML config files. The vast majority of java projects will end up using some construct that ends up 'breaking' the -sourcepath "trick" sooner rather than later, which is presumably why all java projects use a build system instead of relying on -sourcepath.
Note that all source files act as if they have:
import java.lang.*;
import yourownpackage.*;
at the top, whether you write this out or not. And, import is java-ese for 'alias'. import foo.bar.Baz; means: Whenever 'Baz' appears in this file as a type, assume I meant to write 'foo.bar.Baz', and that is all: import foo.bar.Baz does not run any code that is in the Baz class whatsoever. If you don't use Baz, then the class file produced doesn't mention Baz at all. This will also not cause javac to then compile your entire directory.
Related
I've used Eclipse for most of my Java programming, but I'm now volunteering at a prison to teach inmates, and they don't have access to any IDE so we have to do everything from the terminal. (I'm also primarily a Math teacher but doing what I can for the CompSci stuff.) As I understand the file structure in Eclipse, when you have a package called, say, fsk, you place it in a hierarchy like
fsk
src
Sort.java
Main.java
bin
Sort.class
Main.class
where the Main class calls on the Sort class, so to compile the source code at the terminal I write
$~/fsk/src: javac Sort.java -d ../bin
The Sort.java file starts with
package fsk;
...
and the Main.java file has the package name and makes a simple call to the Sort class
package fsk;
import java.util.List;
import java.util.LinkedList;
public class Main {
public static void main(String[] args) {
List<Integer> li = new LinkedList<Integer>();
li.add(1);
Sort<Integer> s = new Sort<Integer>();
s.insertionSort(li);
}
}
The Sort.java file seems to compile just fine, but when I try to compile the Main.java file I get the error that it cannot find the symbol "Sort".
If I do all of this without any package declaration, everything works just fine. Besides modeling this after how I understood Eclipse to work I have also been using https://docs.oracle.com/javase/tutorial/java/package/managingfiles.html and thought I was faithfully reproducing the structure and code, but apparently not.
[Edit: Correction, I have been mostly going off of the Eclipse structure as I understand it, I'm now noticing that when the Oracle tutorial structures this it uses a structure like
src
fsk
Sort.java
Main.java
bin
fsk
Sort.class
Main.class
So I suppose my question now is: am I misunderstanding how Eclipse structures the files, and do I need to instead structure them as in the above?]
The structure is fine. You'll want to compile all the Java files with one javac invocation.
javac fsk/*.java -d ../bin
This will get annoying once you start having multiple packages. Long term you should use a build tool such as Maven, Ant, or Make. Compiling files by hand gets mighty tiresome.
I'm trying the sourcecode from jLDADMM which is GibbsSamplingLDA.java, but i cannot compile it because i get this following error:
package utility doesn't exist
maybe any of you ever experience the same problem? or maybe anyone know what is package utility and how to use it?
any help will be appreciated.
did you try with eclipse, This might works in eclipse. Wont compile on command line – says imported package does not exist:
Have two classes in two different packages (no inheritance)
class A SpecialDelivery – PKG = com.mgm2.specialdelivery
– Class B (UrgentMessage) has main() imports com.mgm2.specialdelivery.SpecialDelivery
c:\ src\com\mgm2 – has both specialdelivery and urgentmessage package paths -compile SpecialDelivery.java OK
Try to compile UrgentMessage from directory with both specialdelivery and urgentmessa pat h names so they are visible and get package specialdelivery does not exist.
To compile UrgentMessage.java use command
c:\src\com\mgm2 javac urgentmessage/UrgentMessage.java then it doesn’t reconize specialdelviery package even though I am compiling from the directory with both of them there.
I know I can include a class or collection of classes in my Java project using the import statement.
For example, import java.io.utils.* imports (i.e. makes available for use in my Java program) all the classes in the java.io.utils package.
My question is, do the classes in an imported package need to be compiled? Or can packages also include uncompiled Java files? If it can be either, when can we use class files and when can we use Java files?
Import just means "make the imported classes available by their simple names" - you can remove imports entirely if you use fully-qualified names everywhere. It's definitely not like #include in C for example.
When you compile, if you try to refer to uncompiled code it will be compiled at that point, assuming the compiler can guess where to find the source code. The result never refers to uncompiled code, because the compiler needs to know what each type exposes.
As a complete example, construct the following file structure:
// src/foo/A.java
package foo;
import bar.*;
public class A {
public static void main(String[] args) {
B.sayHello();
}
}
// src/bar/B.java
package bar;
public class B {
public static void sayHello() {
System.out.println("Hello");
}
}
Then in the src directory, run:
javac foo/A.java
That will automatically compile bar/B.java - but wouldn't compile any other code that isn't referenced (potentially transitively).
I would strongly recommend against using this "compile on demand" behaviour anyway though - if you compile class A that depends on class B, it will compile B the first time, but after that if you change B and recompile A, the compiler won't recompile B. I would organize your code into appropriate projects, and always recompile a complete project at a time, adding a project's output directory to the classpath for a project that depends on it, rather than allowing compiling one project to recompile bits of another on demand.
(Note that this isn't talking about the incremental compilation that many IDEs support... that's a rather different matter, and is fine assuming it's been implemented properly.)
Unlike C, import in Java does not "copy" stuff. Packages in Java is simply a way of avoiding ambiguity. javax.swing.Timer and java.utils.Timer are different Timers. When you say import javax.swing.Timer, you are telling the compiler that you mean javax.swing.Timer, not any other Timer.
All these things that you can import comes from the JDK or some other libraries you're using, or they are created by you. The classes that fall into the former category is already compiled (.class). The classes you created are compiled as well, when you do javac. You can't refer to any uncompiled classes. Since they are uncompiled, the computer does not know they exist.
The reason why your IDE knows your packages and classes before you compile your code is because IDEs are smart. They compile your code before you even notice it.
As Java documentation reports.
You might have to set your CLASSPATH so that the compiler and the JVM can find the .class files for your types.
link: https://docs.oracle.com/javase/tutorial/java/package/summary-package.html
I'm about porting a linux tool to windows. The tool works fine on linux system, but now on windows I get this "cannot find symbol" error.
I have this little main class:
package foo;
import foo.bar;
public class Main {
public static void main(String[] args) throws Exception {
bar.getInstance();
}
}
and the error appears now, while doing javac Main.java:
import foo.bar: cannot find symbol
^
symbol: class bar
location: package foo
Main.java and bar.java are in the same directory.
what am I missing?
For one thing, bar should be called Bar to be idiomatic...
Ideally, you should compile from the directory above Main.java, like this:
javac -d out foo/Main.java foo/Bar.java
That will create a directory called "out" containing another directory "foo", which will contain Main.class and Bar.class. So from the parent directory again, you could run:
java -cp out foo.Main
The source locations don't have to match the package structure. You could just call javac from the directory containing Main.java and Bar.java like this:
javac -cp out Main.java Bar.java
(And then run it in the same way as before) However, it's generally a much better idea to structure your source code according to packages.
You may well find it easier to use an IDE (Eclipse or NetBeans, for example) which will handle all the compilation etc for you. If you do want to build a real project from the command line, you should probably look into using a full build system such as Ant or Maven.
(Note that you'd get the same error on Linux as on Windows, if you tried to compile in the same way.)
If any of you have worked on a kotlin project and then working on a complete Java project without the support of kotlin in gradle, and you put a class in kotlin into the Java project and try to import that Kotlin class, you will get this import issue. Not with reference to the exact question, but someone may find it helpful.
Example : trying to import SomeClass.kt in MainActivity.java will throw this error.
I think you need to compile properly the class bar before attempting to compile foo, this is, generate the class file in the proper package structure.
How do I create a Java package for different files? I have tried
the following. What have I done wrong? And what is the
right procedure?
The first file is:
package dil;
public class Hello
{
Support sp=new Support();
int i=sp.tin();
public void man()
{
System.out.println(i);
}
}
The second file is:
package dil;
class Support
{
public int tin()
{
return 3;
}
}
Now while I compile hello.java it shows these errors:
Hello:4:cannot find symbol
symbol: class Support
location: class dil.hello
Support sp=new Support();
^
Hello:4:cannot find symbol
symbol: class Support
location: class dil.hello
Support sp=new Support();
^
Where is the problem and how can I put both
these files in a package?
The files are in c:\src.
Assuming UNIX / Linux pathnames, a UNIX shell, etc, you need the following file structure:
/some/where/dil
/some/where/dil/hello.java
/some/where/dil/Support.java
Then set $CLASSPATH to /some/where, and compile using the commands
cd /some/where
javac dil/*.java
and run using
java dil.hello
Alternatively, you can tell java and javac what classpath to use with the -cp command line option.
You should also fix the following errors in the code:
Change the name of the "hello" class to "Hello", and rename the source file to match. Strictly speaking this is not an error, but it is a gross violation of the standard for naming Java classes.
You declare a member as "ten" but refer to it as "tin". Fix one or the other.
The entry point method in the "hello" class should be called "main" not "man", and should have a signature public static void main(String[] arg). If you don't fix these the code will compile, but the java command won't find the entry point and will fail.
Although the Support class is not public, that would not be a problem as both classes share the same package. My guess would be that you did not put both source files into a directory according to their packagename and call the javac compiler from the current directory where hello.java resides.
If a class is in package a.b this means the project structure should contain a folder ./a/b containing yourclass.java.
In your case, try to create a folder named ./dil, put your source files in it and call javac from its parent folder.
See Creating and Using Packages in Sun's Java Tutorials to learn all the details of using packages in Java.
I've spotted some things you have to check:
class hello starts with a lower case
class hello calls for sp.ten() instead of sp.tin()
Support isn't public. Make it public and try again.
I suggest you try using one of the free IDEs like Netbeans, Eclipse or IntelliJ CE. This will help you start coding rather than setting everything up the hard way.
BTW: These IDEs have quick fixes for most common problems so they not only give you the error but give you options to fix them and do it for you.