In Python, to install a package, you can use pip install package. Is there a similar concept for Java and if so how does one do this? Is this done by adding a dependency to build.gradle? Is a library for Java the equivalent of a package in Python?
I think it's a good question. Mainly because the difference between Java and python.
Let's start at the beginning:
When I develop via python, I'm using https://pypi.org/ in order to explore 3rd-party libraries. Once I find a good candidate I install it via pip install as mentioned in the question. Easy as pie.. thon.. I guess
In Java things are "slightly" different. Although the libraries in java are built the same way (as jar files) there are various building tools provided for Java. That is to say - when you ask "how to import and install a library in java?" it actually depends on you project's configuration
I, in person, loves https://mvnrepository.com/ when using Java. It is clear, informative and most important - it provides (for each library) various build solutions that you can easily use. Didn't find what you are looking for? Getting into trouble? You can always manually download the library jar file and embed it into your project (not ideal for most use-cases but - it is possible)
I attach here an image to make it clear where to find each of the options that I mentioned above in order to make more sense
Happy coding!
Is this done by adding a dependency to build.gradle
Assuming you're actually using Gradle, then yes.
Otherwise, curl/wget JAR files from Maven Central and export CLASSPATH to the location of those JARs is the closest CLI-only equivalent. This approach is error prone because it won't grab transitive dependencies.
Java libraries include packages, yes. Java modules don't work like Python modules, though.
Related
Let's imagine, I created a bunch of command line utilities, written in Scala and/or Java, and I'm using SBT to build them. They all use a couple of libraries, some of them pretty big, and in case of Scala, also the (not so small) Scala standard library.
I want to have these utilities in completely built form (runnable .jar files) to be able to instantly launch any of them and, if needed, also easily distribute them. But what I don't want is to include their dependencies in all of them, because they will be taking disk space. Instead I want them to get dependencies from a shared folder at runtime, and the application jar should contain only "my" classes.
The question is, is there a standard way to accomplish this? If so, where must be shared .jars located? Otherwise, what would you recommend to do?
You can set the CLASSPATH for this.
The JRE searched for classes in the .jar files named in the CLASSPATH.
Additionally all .jar files in the directory jre/lib/ext are used.
To find the complete serching in classpathes please consult the official documentation from Oracle.
Something you might like to consider (although it will require slightly changing what you plan to do) is to have a local Maven repository.
You could have SBT publish libraries to it when they're built. Instead of building runnable JARs, you could run your applications via SBT, which would pull libraries from the local repository as/when required.
The benefit of this is that all the plumbing to do this is built into SBT, and it would make distribution trivial.
The downside is that you would have to run your apps via SBT instead of building runnable JARs. Whether that will work for you, I don't know.
I do not understand the purpose of ant. I read the introduction, but am missing the big picture. I know the following (or at least that I want to use them),
Java
jdbc
hibernate
jsp
servlet container like Tomcat
But I don't see how ant fits in.
Is there some all comprehensive tutorial that tells me how to put all this together?
Why would I want ant? What is the alternative if I don't have ant?
EDIT: So is this sort of the compiling part of its Visual Studio counterpart?
Ant is used as a build system. You do not have to use it--in fact there are quite a few better systems but since ant was one of the first it's still likely to be very common. It generally is used to compile your java files, create wars and often even put the .war files onto the tomcats.
Maven is bigger and tries to do a lot more, but it's also rather strict in it's format and quite heavy--but it's quite common these days as well. Maven can gather all your dependencies automatically which is nice, with ant you still have to download everything yourself.
There are others, but you get the idea.
Response to comment:
I don't use visual studio, but I think it is more limited. For instance, Eclipse can build all your java files into a jar or execute them directly (in fact, it uses ant internally). If you wanted to take your visual stuido "Build configuration" and put it into another tool (Perhaps an automated build system like Jenkins) that doesn't rely on visual studio directly, can you do so?
I guess Ant is the way we code our builds--it's portable betweeen many tools. Visual Studio would be cleaner to "create" your build, but "Exporting" the ability to build would be more difficult (if even possible).
Also ant is portable across operating systems as well as tools. We can switch from Eclipse to Netbeans to IntelliJ without touching our build toolchain.
How would you completely remove visual studio and replace it with slickedit, emacs or vi (if that was your thing, which I'm sure it's not) without starting over from scratch with your build?
For any web application to work you need to package or build all your java code with all the libraries into an web application archive to accomplish this task we need to some tool or library to package into the correct format and some of the libraries which can achieve this is
Apache Ant and Apache Maven
There some good discussions about Ant vs Maven in SO.
You need ant to build the project. Well you can build project using IDE like eclipse etc. But for production purpose and big projects, it always advisable to some build script like ant. Its a script where you can customize what you want to build and what not. you can define what is the output should be like war/jar/ear etc
Other alternative is Maven which is very prevalent and standard now a days
Is there anything similar to Python virtualenv for Java or JVM Languages?
From what I understand, virtualenv enables you to have separate library installation paths, effectively separate "virtual" Python installations.
Java doesn't have the concept of a "system-wide installed" library(*): It always searches the classpath for the libraries to be loaded. Since the classpath can be (and needs to be!) defined for each application, each application can pick-and-choose which libraries and which versions it wants to load.
If you go down one level deeper and have a single application that somehow needs two different versions of the same library at the same time, then you can do even that with some classpath trickery. It can get complicated, but it's definitely possible (OSGi is one example where this is supported, even Tomcat with two separate webapplications does this).
I've seens some references to security in the virtualenv description: Java has a pretty thorough security system built in. In server applications it's often turned off because it's just easier to configure this way, but you can easily configure what exactly a Java application is allowed to do.
(*) Almost, there are extensions or extension libraries, but they aren't used a lot and even those can easily be loaded from arbitrary directories.
Build tools like Ant, Maven, and gradle are the the closest thing to pip or easy_install.
The concept of virtualenv is done by the classpath. So there is no real need of virtualenv for Java
Yes(see http://www.jenv.be/), like many other languages (Ruby, Python, Go, R, Php, etc. etc.).
I know this may be a little late , but Groovy/Java has gvm http://gvmtool.net/ which is the Groovy version of Ruby's renv.
I would respectfully agree with Gautam K, luthur. Dependency and package version management for projects is not the same as an isolated self-contained virtual environment to maintain different project.
My 2 cents
-W
I have also been looking for a similar solution to simplify switching context between projects that use different Maven versions/settings and/or Java SDKs without having to modify M2_HOME and JAVA_HOME settings every time.
To this end, I developed a solution that helps execute mvn commands with the appropriate configuration based on per-project settings (stored in a .mvn folder).
See: https://github.com/AlejandroRivera/maven-env
Be aware that this only helps if you're using Maven to build and/or run your project.
I'm confused by the assertion that "Java doesn't have the concept of a 'system-wide installed' library". What would you call the jar files in $JAVA_HOME/jre/lib and $JAVA_HOME/jre/lib/ext?
Regardless of whether or not Java "needs" a tool like virtualenv, it seems that something that allowed you to quickly switch between different Java environments (e.g. Java 6 with such-and-such security extensions, Java 7, etc.) would be handy - even if all it was actually doing under the covers was manipulating the PATH, JAVA_HOME, and CLASSPATH env variables.
Maven, you can explicitly specify which packages you would use in a java project
Java as a language does not need the sandboxing features of virtualenv but a JVM Language like Jython can have VirtualEnv to use different environments without any conflict.
It is outlined in this blog post
Quote:
Get virtualenv installed for Jython. Just type "jeasy_install
virtualenv". Once that finishes you should have a 'virtualenv' tool in
the Jython installation's bin folder.
So when using Jython different frameworks and packages can be used without any conflict with global packages.
i am setting up a java project now. in the past, we always included everything (unzipped) from the 3rdparty, such as ant, junit, jfreechart, and others, inside our release. I am wondering is it possible just take those related .jar files but not everything with our software release? then we can get a smaller and neat release. Those 3rdparty library licenses don't allow us to do that way? what's your way? thanks,
You really want to retain the separate jars, if possible. Check out the maven appassembler plugin. It does a nice job of putting together an "unzippable" installation for you, in a controlled way. In the result you'll have a very straightforward "repo" directory filled with all of your dependencies.
I use the maven-assembly-plugin to build a single jar for each application. The plugin quickly handles the fuss of unzipping all the library jars and putting the whole lot back together as a single jar. It also supports writing a manifest with a main class specified which makes running the application simple from a command line (much simpler than specifying a classpath argument as long as your arm anyway).
If their licenses say that you should distribute derivatives with sources, then you are obliged to do that by law.
Another question is if they really force that. As far as I remember GPL, you shall distribute the sources if you want, but there is another way - you must make sources easily availiable to users. So you can drop sources in your distributables.
Any way, you should look at the licenses.
EDIT:
If you will decide to pack the whole program into single jar, I recommend Proguard. It is java optimiser, shrinker, and much more - all in one! To pack everything into one jar, just specify all your jars - program and libraries - as program jars, and specify only one jar as output. Usually it works just fine.
I'm trying to use an open source java library to visualize nodes and edges in a graph, but I'm completely lost.
I have a bunch of jar files in a folder. Clicking on some of the jar files makes java swing windows pop open with graphs displayed. Clicking other jar files does nothing.
If I figured that out, would I just stick the jar files in there with the other ones, or would that still not work?
And if I ever figure out how to use these files, does that mean that I have to include them if I transfer my java project to another computer? How would I go about doing that?
I believe if you put the jars in your classpath, you can import and use classes just like you would a standard library. Figuring out the classpath can be confusing, but you can just set it when you start your jvm. Your IDE may have options for it, too.
Most java problems are classpath problems.
Have you included those libraries in your classpath?
If you are using eclipse, you could
Project - > properties -> Java build path ->addJar.
And the Jar file should be placed in a directory inside your workspace (lib/ for example)
If you have to take your project to another computer, you could take these steps
Before doing anything, export your project (as a Jar file, for example).
Save it into your favorite drive (cd / usb drive/ diskette/ tape).
On "the other" computer, you can import this project into your workspace
In Eclipse, you need to add libraries to the project build path.
In general, you need to provide dependencies via the classpath mechanisms at compile time and runtime. The precise mechanisms vary, but, for example, if you used the javac compiler, you would provide your libraries on the command line:
javac -classpath C:\dir\lib1.jar;C:\dir\lib2.jar foo/MyClass.java
These dependencies would also be required to invoke the app:
java -classpath C:\dir\lib1.jar;C:\dir\lib2.jar;. foo.MyClass
This page gives some good info, though googling for the term "classpath" should provide alternative sources.
You use it by including it in the classpath of your java application, that way you can reference it from your code. Here is a starter document. The JDK 1.6 has some easier options (such as specifying multiple jar files as *.jar). It is definitely a little complicated, but it is very worth knowing.
You should have documentation for these Jars. Some sounds like examples, but one must be the core graph modelling and rendering Jar. Hopefully the examples have source included.
Just add that Jar to your project in Eclipse (e.g., in a /lib folder in your project, then add it to the build path) and use the documentation to use the code. You can also use Eclipse to look inside the Jar file.
Unless there is no alternative, it probably isn't worth using a load of third party code that isn't documented at least on the API level, and without any source examples definitely not.