Let's say you create a new project, and want it to make use of some 3rd party library, say, widget.jar. Where do you add this JAR:
File >> Project Properties >> Libraries >> Compile-Time Libraries; or
File >> Project Properties >> Libraries >> Run-Time Libraries; or
Tools >> Libraries (Library Manager) >> Library Classpath; or
Tools >> Java Platforms (Java Platform Manager)
All of these dialogs seem to do the same thing but I'm sure they all have their proper usages. Can't find a good "best practices" article online and the NetBeans Help Contents dialog isn't helping with this either.
Right click 'libraries' in the project list, then click add.
You want to add libraries to your project and in doing so you have two options as you yourself identified:
Compile-time libraries are libraries which is needed to compile your application. They are not included when your application is assembled (e.g., into a war-file). Libraries of this kind must be provided by the container running your project.
This is useful in situation when
you want to vary API and implementation, or when the library is supplied by the container (which is typically the case with javax.servlet which is required to compile but provided by the application server, e.g., Apache Tomcat).
Run-time libraries are libraries which is needed both for compilation and when running your project. This is probably what you want in most cases. If for instance your project is packaged into a war/ear, then these libraries will be included in the package.
As for the other alernatives you have either global libraries using Library Manageror jdk libraries. The latter is simply your regular java libraries, while the former is just a way for your to store a set of libraries under a common name. For all your future projects, instead of manually assigning the libraries you can simply select to import them from your Library Manager.
If your project's source code has import statements that reference classes that are in widget.jar, you should add the jar to your projects Compile-time Libraries. (The jar widget.jar will automatically be added to your project's Run-time Libraries). That corresponds to (1).
If your source code has imports for classes in some other jar and the source code for those classes has import statements that reference classes in widget.jar, you should add widget.jar to the Run-time libraries list. That corresponds to (2).
You can add the jars directly to the Libraries list in the project properties. You can also create a Library that contains the jar file and then include that Library in the Compile-time or Run-time Libraries list.
If you create a NetBeans Library for widget.jar, you can also associate source code for the jar's content and Javadoc for the APIs defined in widget.jar. This additional information about widget.jar will be used by NetBeans as you debug code. It will also be used to provide addition information when you use code completion in the editor.
You should avoid using Tools >> Java Platform to add a jar to a project. That dialog allows you to modify the classpath that is used to compile and run all projects that use the Java Platform that you create. That may be useful at times but hides your project's dependency on widget.jar almost completely.
Project Files Services Tabls
go files tabs
drag drop file to libs files hover.
return project tabs and what are you see :)
Related
I can't find any info on how to call a different java file from a different folder anywhere.
Heres a diagram of what I wanna do
So for example
If the java file was in the same folder you would do:
HUD.HEALTH
but what would you do if the java file was in a different folder.
In Java you normally work in one folder, the so-called source folder. In this folder the classes can be divided into packages, usually using a certain pattern, for example com.company.something. In this case, a class is applied via import. The keyword import and the package name in which the class is located are specified. If they are external resources, the classes are included as external resources (.jar files), nowadays build tools like gradle and maven are used for this. Once the dependencies are imported, they can be used as well.
If you have two local projects, and want to access a class from project B in project A, for example, you work with the IDE. In Eclipse I would simply go to ProjectB's Build Path settings and add ProjectA. I recommend Intellij as IDE, there you solve it as follows:
Steps in IDEA ( You won't need these below steps if you follow below mentioned best practices):
Right click on project and select open module settings
Go to dependencies tab
click plus sign and add the module you want to use.
Best practices:
Never use project class in another project, always create a nice interface and use that interface in other projects.
If possible use Dependency Injection to manage different projects and their dependencies (this internally uses interfaces to do this).
Use build tools like Gradle and Maven to manage build process.
Firstly this is a very n00b question. But being a junior dev I've never needed to import and work with other Java Frameworks. The standard library was always good enough for me to write the classes I needed to write.
But now getting exposed to more "advanced" concepts, I need to start working with external frameworks, e.g. JSON for Java, Apache's HttpClient for java and so on. And I'm looking for a basic understanding on how this works and how to go about importing these libraries so you can start working with the classes...
So my initial understanding is that each of these fraemworks will provide you with a .jar file that contains all the classes for the framework. Which you then import into your project and lo and behold you'll be able to use the classes/library in your project by just importing it e.g. 'import org.json.*;'
Is the understanding correct?
Correct.
You just add the libraries to your classpath and are now able to use classes from these libs.
How you add the libs to your classpath depends on your actual development environment. If you use Apache Maven for example, you just have to define the dependencies (libs) in your projects pom.xml and Maven downloads them automatically for you.
hth,
- martin
EDIT: The following only applies if you are not using automated build-tools like Maven or Ivy
Yes this is correct. To use a third party .jar file, download and place it in a convenient location (either system-wide or project-specific depending on your needs) and then include it in your classpath.
When executing from the command line do:
java -cp /path/to/library:. path.to.main
The :. is necessary so that the JVM will find your main method.
In an IDE you should be able to include the library in your classpath via the options menu.
Then you can just use the third party library like any other:
import name.of.library.class;
//Do something
I am beginning to use java packages like HTMLParser, I have downloaded it and finding that there are many files and directories in it.
I wander, where to place them in my linux system? Is there a convention or a standard?
The quick and dirty answer is "anywhere on the classpath", where the classpath is set either as a system property on the client machine (not recommended), as a temporary system property for the CLI session used to start the JVM (workable from a startup script), or as a commandline parameter to the JVM (usually the preferred choice).
First and second set the CLASSPATH environment variable, see the JDK or JRE documentation for the exact syntax and your operating system's and/or shell scripting documentation as well. Third uses the -cp commandline variable to the Java runtime and compiler, see their documentation for exact syntax.
Where to place the files on the filesystem? For development purposes I typically use a central folder on my computer containing all such libraries and link to that from my IDE or other development environment. For deployment/packaging to end users, it is traditional to have a "lib" subfolder to the product folder that contains all distributable content, and put the jar files in that.
Java packages come in two forms. Source code - all the files and directories you mention - and packaged as jars. A common convention in Java projects is that the project has a lib directory that contains all the jars that the project depends on. These projects often use a shell script which adds all the jars to the Java classpath prior to executing the project code.
However many projects are switching from this method of dealing with dependencies to using a build tool like Apache Maven which automatically handles dependency management. Other alternatives include Ivy or Gradle. For an introduction see the 5 minute introduction to Maven or the Maven 3 tutorial.
Here you write a pom.xml (project object model file) which specifies which libraries (jars) your project uses. Maven then stores all the jars for your different projects in a .m2 directory in your local directory, keeping track of where it obtained them, and their versioning information.
This makes developing much easier as you do not need to create the lib directory or manually manage dependencies. You also avoid a lot of the complexities of setting the classpath, as Maven automatically does this for you during common lifecyle stages such as compilation and test. Recent versions of Eclipse can read the Maven pom and automatically configure your classpath from it.
Once you have built the project, Maven can also help create "fat jars" that contain all the jars your project depends on, via the assembly plugin or the Shade plugin. This makes distributing the code easier when you are building an executable that you want someone to use. If you are distributing a jar, then your pom.xml describes the dependencies of your project, avoiding the need to distribute the jars it depends on.
For laying out files in general on a Linux system consult the Linux Filesystem hierarchy standard.
I have a Java project which is heavily used by all sorts of other Java and Android projects. The project contains some JAR libraries which shall be used by all projects, except for the Android one (in fact the Android project is a Android library project to be precise).
I marked the JARs as "export" in the Eclipse build path preferences of the Java project. However, the Android project shouldn't import these libraries (as they are Java libraries which make use of some classes which are not available on Android), but it shall import the rest of the code (which doesn't really use the libraries, but they are stored in there for convenience reasons and to ensure, that all other projects use the same library.
How can I prevent the JARs from being exported to the Android projects?
You can prevent all jars from being exported so that only the common project is a dependency for each project that needs it.
Then you can change the build path of each project to only include its necessary jars through the add jar.. dialog in build properties.
That's the easiest way.
A more extreme way would be to move to maven and then eclipse will only include the jars you specify in the pom - though that's a load of extra work for not much gain.
Alternatively, you could split the android specific code into a android-common separate project and then make your common project depend on it and export it - then your android project could rely on this android-common project instead of the existing common project.
I am using Eclipse IDE and its derivative like Spring IDE for Java development.
In a web application project, I add external jars like Spring MVC jars, Apache commons jars etc to the Web App library folder, hence they are automatically added to the build path. There are many jars in the Web App library folder.
I want to create folder in the project and add all the source files (zip/jar) of the libraries included in Web App library folder, so that I can navigate through the source of libraries from the Java editor window. Whenever I add a source zip/jar file to this folder, Eclipse should detect it and use it whenever I want to navigate to the source of a library.
Is the above possible in eclipse?
Note: I know how to add source files
for each individual jar by navigating
to the build path window and
specifying the source location. But
this is very crude way, and I need to
do for every library individually.
Also the drawback is that source path
is absolute, which means if I import
the project into another computer then
I need to create the source path or
even worse I might have to add the
source files individually again.
One way to automagically get the sources for the jars would be some kind of dependency management system. Most people would scream Maven (2/3) by now, but others exist and work well. Maven does have nice Eclipse integration, so that should be a plus.
The downside is that setting up a Maven project just for it's dependency management can seem overkill. Another point is that all the jars you depend on should be "Mavenized" as well.
As far as I know Eclipse wont automatically detect/scan source archive files and link them up to libraries in your workspace in the way you described it.
I agree with #Gressie on using Maven and the Eclipse Maven plugins -- as in that case it's just a matter of ticking a few boxes and Maven will do that for you.
If however your project is not Maven-ized, you can still do this in Eclipse but it's more tedious:
for each one of the jars in your project (which appear under the dependecies section) right click on it and select properties
in the dialog that pops up you have (at least) 2 locations you can configure: java source attachment -- simply browse to your jar with the sources -- and also javadoc location (point it to the jar with javadoc if you want the javadoc to appear as a tooltip when you hover the mouse over one of the classes/methods/etc in that library).