I have created a package in c:\world and I want to import it to my java source file stored in d:\java. It says that unable to access the package c:\world\Balance.class. What do i need to do??
You'll need to have the location of the imported classes on your classpath when compiling your classes and running your code.
From your description and comment, it sounds like you have a package named world with a class named Balance, with Balance.class in c:\world. This should work from d:\java:
javac -cp %CLASSPATH%;c:\ SomeClass.java
Replace SomeClass.java with the name (one or more) of the classes that you're trying to compile in d:\java.
You'll also need to have c:\ in the classpath when you run your code.
If you are seeing what I think you are seeing (no c:\world in the specific error message), then it's easy. You need to add c:\world to your CLASSPATH setting.
After that, a simple import Balance (or whatever) should suffice.
Otherwise, a MWE (Minimal Working Example) illustrating the issue, and the exact error message you are getting, would be helpful.
You have 2 ways to solve this problem:
Make the packages available in a single project, this means, both packages would be in the same source directory.
Make a jar that contains your world package. Copy this jar to your lib folder in your project and add it to the classpath, now the world.Balance class can be reached in your current project.
Related
Within Eclipse if a class is not found and is available on classpath Eclipse can auto import the required package. What is the mechanism that allows this ?
I doubt there some repository of class files and their associated packages that Eclipse searches...
The reason I tagged this java and scala is I assume the mechanism is same for both languages.
It's as simple as searching through the whole classpath to see if it can match the class name. Then if it can, just adding the path it took to get there. There's nothing mysterious about this
The Eclipse feature simply searches the entire collection of folders in the classpath until it finds one or more matches, then it gives you those matches as options. In pseudocode:
Find Foo.class:
For Each FOLDER in CLASSPATH
For Each PATH...Foo.class Found There
import PATH...Foo.class
You can count JAR files as folders. To see their content, try this on the command-line:
jar tvf MyJar.jar
The class path includes jars containing all JRE classes.
I'm trying to learn Java ( I know php ) but I don't know what path the included classes have. For example, I create a new directory in Eclipse (in the package) and drag there a class from other project. When I try to import it, it cannot find the class. Even if I don't have any dirs and the class is directly in the package, using import package.classname doesn't work...
I must be missing something but googling doesn't show me any replies.
How do I get the class path? Is it somewhere in the properties?
Java has the concept of a classpath: a path where all classes should be found.
You can get the existing classpath with this code:
System.getProperty("java.class.path")
If you run java from the command line then you have to set your own classpath with your classes.
From the classpath, use the package to find the class. For example, if the classpath is ".", which is the current folder, and you have a class called A, which is in the package com.yourcompany, then you will find the class under ./com/yourcompany/A.class
On the example you gave, go to the terminal and look for the "bin" folder and you will see all classes. However, if you want to add a new class from another project to your project, then there are simpler ways. You can simply open your build path in Eclipse and add the class from the other project onto your project.
Another way is to create a jar from the other project and add the jar to your project.
In Eclipse, go to Project->Properties-Java Build Path where you can config the classpath which allow you to import.
This is part of a demo code, I am trying to learn this code
import com.jgrindall.android.connect4.lib.board.*;
What is this code doing? is a lib a folder? if it is a folder then where is it located?
It's importing all classes in the com.jgrindall.android.connect4.lib.board package. The source for this can vary - I assume it's in the com/jgrindall/android/connect4/lib/board source folders but sometimes it refers to code in an existing jar library used in the project.
Import means you want to be able to use the named classes without having to specify their full qualified name. In particular, since this import ends in *, you're saying you want to be able to use any class in the com.jgrindall.android.connect4.lib.board package by just giving the short classname -- Board rather than com.jgrindall.android.connect4.lib.board.Board
Where those classes are loaded from is a separate question, determined by your classpath and classloaders.
it is importing a PAKAGE. You can see the package as folder, and the ending wildchar means import all class in the packge.
If you are using plain source code, then package are folder, but they can also be packaged (no pun intended) in a jar. you can open a jar as a zip, and you will se a manifest file, and thepackage structure.
Also there ase some standard class in their own package in the visrtual machine, and they are all the standard library
I have two .class file with the same name and same package in two different .jar file
First jar:
Second jar:
When i run the program from eclipse i haven't problem, eclipse use the first .class file (i must use the first . class, i don't need the second .class, i want exclude it).
When i export runnable .jar i saw that is executed the second .class file and then i have
NoSuchMethodError exception, because the second .class is different from the first.
How can i use always the first .class and exclude the second?
I don't need the second .class, but i need other class from his library.
Java loads classes from classpath that is defined dynamically when you are running application in eclipse and is controlled by property Class-Path in file MANIFEST.MF located under META-INF in you jar file.
So, first open jar file using any ZIP tool and take a look on manifest. Try to change the order of jar files into manifest and run again. I hope this will help.
BUT this is extremely bad that your alive-matchmarker.jar contains file that it should not contain. I do not know what library is it but is there a chance that they have other distribution that does not contain their own dependencies? Or probably try to find other version of this library. The worse thing that can be is if you have different versions of the same class in your classpath: the behavior of your application can be buggy and unpredictable as a result of this duplication because you can never know what version of class is used now.
Do not import the whole package like
import org.mindswap.*;
You can import specific class you want from any specific package like
import org.mindswap.wsdl.WSDLTranslator;
I'm working on some Java code in eclipse. Code is contained in a single class called Adder, which in Eclipse is in the package org.processing. The first thing in the class file is the line
package org.processing
Q1) What, exactly is this line doing? Why is there, what's it's role.
The code runs fine in eclipse, however, when I move into the workspace if I go to the src/org/processing/ folder in src, compile with javac Adder.class when I try and run using java Adder I get the following error
java.lang.NoClassDefFoundError: Adder (wrong name: org/processing/Adder)
On the other hand, if I compile from src using
javac org/processing/Adder.java
and I can run it from src using java org.processing.Adder but STILL not from within the processing directory.
Q2) Does this mean that compilation is always relative to directory structure?
Finally, if I remove the package org.processing line from the start are the .class file I can compile and run from within the .class file's directory.
Q3) Why is all this the way it is? I can fully understand enforcing a directory structure for code development, but once you're in bytecode this seems a bit over the top, because now I can (apparently) only run the bytecode from one director (src) using java org.processing.Adder. Now, I'm sure I'm missing the point here, so if someone could point out what it is, that would be great.
The compiler has to be able to find related source code files when compiling. This is why the package and directory structure must agree for source code. Similarly, the JVM must be able to find referenced .class files. So the same directory structure is required at runtime. It's no more complex than that.
Q1) The issue here is that once you got into the folders that represent your package hierarchy, you set that as the working directory. It's gonna look inside of org/processing/Adder for the path org/processing/Adder (essentially looking from the root for org/processing/Adder/org/processing/Adder). You need to call it from the root with the full path. The purpose of packages is A: to organize related classes into groups. And B: Along with A, classes in package Foo.bar can't view private classes in other packages, as they are like internal classes for that package, only the package they're in can use them
Q2) Yes
Q3) The paths are used as a basic structure for the JVM to know where exactly the class files (each containing their bytecode) are. If you change where you call it from, your basically trying to change the location for the JVM to look for the class files, but their true location hasn't changed.
The short answer - Packages help keep your project structure well-organized, allow you to reuse names (try having two classes named Account), and are a general convention for very large projects. They're nothing more than folder structures, but why they're used can burn beginners pretty badly. Funnily enough, with a project less than 5 classes, you probably won't need it.
What, exactly is this line doing? Why is there, what's it's role.
The line
package org.processing
is telling Java that this class file lives in a folder called /org/processing. This allows you to have a class which is fully defined as org.processing.Processor here, and in another folder - let's say /org/account/processing, you can have a class that's fully defined as org.account.processing.Processor. Yes, both use the same name, but they won't collide - they're in different packages. If you do decide to use them in the same class, you would have to be explicit about which one you want to use, either through the use of either import statements or the fully qualified object name.
Does this mean that compilation is always relative to directory structure?
Yes. Java and most other languages have a concept known as a classpath. Anything on this classpath can be compiled and run, and by default, the current directory you're in is on the classpath for compilation and execution. To place other files on the classpath, you would have to use another command-line invocation to your compilation:
javac -sourcepath /path/to/source MainClass.java
...and this would compile everything in your source path to your current directory, neatly organized in the folder structure specified by your package statements.
To run them, as you've already established, you would need to include the compiled source in your classpath, and then execute via the fully qualified object name:
java -cp /path/to/source org.main.MainClass
Why is all this the way it is?
Like I said before, this is mostly useful for very large projects, or projects that involve a lot of other classes and demand structure/organization, such as Android. It does a few things:
It keeps source organized in an easy-to-locate structure. You don't have objects scattered all over the place.
It keeps the scope of your objects clear. If I had a package named org.music.db, then it's pretty clear that I'm messing with objects that deal with the database and persistence. If I had a package named org.music.gui, then it's clear that this package deals with the presentation side. This can help when you want to create a new feature, or update/refactor an existing one; you can remember what it does, but you can't recall its name exactly.
It allows you to have objects with the same name. There is more than one type of Map out there, and if you're using projects that pull that in, you'd want to be able to specify which Map you get - again, accomplished through either imports or the fully qualified object name.
For Q1: The package declaration allows you to guarantee that your class will never be mistaken for another class with the same name. This is why most programmers put their company's name in the package; it's unlikely that there will be a conflict.
For Q2: There is a one-to-one correspondence between the package structure and the directory structure. The short of it is that directories and packages must be the same, excepting the package is usually rooted under a folder called src.
For Q3: Once it's compiled, the class files will probably be in the appropriate folders in a jar file. Your ant or maven tasks will build the jar file so you won't really have to bother with it beyond getting the ant task set up the first time.