This is the third time I've installed it. I had it working on Windows, and up until a few days ago on Linux. I've done all I can do and I don't understand how to run this Java program.
The source code is a folder with a lib, src some jars and a classpath and project file.
The classpath file makes some declarations like classpathentry=src/main and path=lib, path=src.
All of these make sense. There is a folder 'main' inside 'src'.
The tiny file I'm trying to run starts off by
import de.l3s.boilerpipe.demo
I'm trying to run 'Oneliner.java'. I cannot compile it.
No matter what/where that class file is, I cannot run it. It results in a noclassdeffound.
I've run it in the main, the src, the root, the demo, the ... anywhere.
I've tried compiling it in different directories, running it with various java command line switches that were recommended. Supposedly you can have it 'search' for the file, which I've yet to experience. The sheer stubbornness of this java environment is terrifying. And massively humiliating for me.
I had the same problem with installing it. The 'Getting Started' page is poor quality.
My solution was to use a python wrapper, which you can find here: https://github.com/misja/python-boilerpipe
It takes care of all of the dependencies you'll need (however, you might be missing jpype if you're on a Mac. In that case, you'll need to install it manually from: http://jpype.sourceforge.net/).
The best way to start using the boilerpipe algorithm (and to see what it is for) is to use the demo site:
http://boilerpipe-web.appspot.com/
If you want to integrate the boilerpipe library into your applications, or even intent to modify/improve the code, you will definitely need solid Java programming skills.
As a quick-start I suggest that you install a recent version of the Eclipse IDE for Java Developers and import boilerpipe-core as a project. This avoids pretty much of the classpath configuration, and almost everything should be set up correctly for you.
The classpath file you mentioned is probably ".classpath", which is part of the Eclipse project configuration. You don't need it unless you want an Eclipse project.
Related
I'm a Java veteran, but I've been using JDK8 for a long time. I've decided I finally want to upgrade, so I've been using Java11. I've been enjoying the new features, but I've gotten the point where I need to deploy my software.
In the past I would export a runnable JAR from Eclipse and bundle it with an appropriate JRE. Then I'd use both to run the software from an OS-specific program (e.g. an EXE file that fires up the bundled JRE with the given JAR). Of course, now this isn't really an option because JREs are a thing of the past. Supposedly the new system in its place is much lighter weight and straight forward, the only problem is I can't figure out how to actually use it.
I've been reading about how to deploy programs with JDK9 and above and have seen people mention JLink and link documentation to it, but I can't seem to find a straight answer on how to just simply export a runnable JAR. The thing is - I don't really need all of the module support and don't really want to have to configure it. Is there a tool for simply exporting something I can run? How is this done now?
Sorry if this is a dumb question, I'm just genuinely confused at how this all works and can't really find anything online that lays it out in a clear and concise way. There's a lot of documentation on JLink and what it does, but I haven't really found anything that explains the root purpose for all of it.
TL;DR; how do I export working Java programs with JDK9 and above using Eclipse (latest version)?
Thank you for your time!
...how to just simply export a runnable JAR.
Well, if you're not planning on using modules for your application classes, the JAR part should be the same as before. You basically just have to create your own JRE using jlink, e.g.:
jlink --add-modules java.se --output jre
That would create a jre folder with a runtime image that includes all the java.se modules.
You can then bundle that with your JAR like before.
The interesting part here is that you can pick and choose which modules go into this runtime image. java.se is an aggregator module that transitively includes a bunch of other modules. But you could also specify your own specific list of modules, leaving out some of the ones you don't need, making the final runtime image smaller.
I've spent literally months on trying to figure out how to create a single, clickable executable using Java 9+. I now conclude that it is impossible. Whether you use jlink directly yourself, or indirectly via Maven or Gradle, the result is that jlink produces a full directory structure that you are left to "distribute to your users" (somehow, I guess magically, since nothing in Java 9+ tells you anything about how you're supposed to do this). Then, once your user (somehow) has this directory on their machine, they are forced to invoke runtime-image-directory/bin/your-program-name. As though your user is a programmer who is happy to have to install a directory structure, and drill down to invoke a specific file name, which is buried in a directory with lots of other files, rather than being a user who USED to be able to simply double-click on a .jar file to run it. This makes me really wonder if whomever designed all this thought at all about the "user experience". The fact that there appears, as of Java 9+, to be NO WAY to simply deliver ONE file (such as a .jar) to users, together with the fact that just BUILDING this "runtime image" is fantastically complicated, means that developers are going to abandon Java in droves. It really seems to me that the brainiacs at Oracle simply didn't think this through. They have created a death knell to Java by making something onerous for developers to build and distribute, and onerous for users to invoke. I don't see how this situation can be allowed to remain without Java ultimately dying off. Somebody please correct me if I am missing something here, but I've spent months now trying to figure out how to create a runnable jar in Java 9+, USING MODULES, and it appears there is no way to do it.
I have an application that works fine and that I can execute from a .jar file. But I want to know how to make it runnable from any computer even if there is no JRE or the JRE version is not the good one. I thought about a .exe file but don't know how to do it.
I made my code with Eclipse and it use jxl,jdom and jfx librairies.
I tried to use Inno Setup 5.5.6 but when in Eclipse I run my build.xml as Ant Build it return me an error that says :
"'Launching JFX Build - Myapp' has encountered a problem.
The achive : C:/Program%20Files/eclipse/plugins/org.eclipse.swt.win32.win32.x86_64_3.104.0.v20150528.jar which is referenced by classpath, does not exist."
JavaFX provides specific utilities for bundling your application as a native package, which is referred to as "Self contained application packaging". These utilities are provided as a command-line tool, or as ant tasks. Additionally, the common IDEs support this via wizards, either out of the box (NetBeans) or via a plugin (e(fx)clipse for Eclipse). The details of how to use any of these are far beyond the scope of a stack overflow question, but the basic documentation is available here. A tutorial for e(fx)clipse is here.
Briefly, for e(fx)clipse, you should double-click the build.fxbuild file that is created in your project. Under the "Overview" tab, find the "Packaging format" option, and select "All" (or the specific type of package you want to create).
Note that you can only create a package targeted at the platform on which you are building, so if you want to create packages for windows, Mac, and Linux, you will need access to all three types of machine.
I know I am late. I faced same problem a trick worked for me. Look at the given directory in the error message. It contains a space (C:/Program Files/...). Move your e(fx)clipse to another directory where the directory doesn't contains any space.
Not sure it will work your everyone or not but it worked for me.
Thanks
There are various tools that let you wrap your Java application in a Windows executable. Some tools are only simple installers, others allow you to bundle your application with a specific JRE version.
A widely used but commercial tool is install4j, but there is a bunch of other tools, such as WinRun4J.
I've searched far and wide, I can create my JAR using eclipse but when I run it, it doesn't run half of the program because it didnt import the API's, because the API's don't exist in the JAR.
I made a simple pac-man game (still learning java :O)
I compiled it into an executable JAR so I could use a program called 4J to turn it into an exe!
However, the JAR doesn't even run the game :/
Don't know what sources you need, so just ask.
Sorry I'm a newb D:
You can supply third-party API within your jar file. This is so called fat jar approach (all classes will be put into one jar according to names of the packages). So you will deal with one jar file (then convert it to exe, or add shell scripts for specific operating systems which will just run java -jar game.jar - too many options).
As for Eclipse search for specific plugins. Or, as mentioned above, use Maven or tool that will give you a portable installer. It's completely up to you.
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.
How do you ensure, that you can checkout the code into Eclipse or NetBeans and work there with it?
Edit: If you not checking in ide-related files, you have to reconfigure buildpath, includes and all this stuff, each time you checkout the project. I don't know, if ant (especially an ant buildfile which is created/exported from eclipse) will work with an other ide seamlessly.
We actually maintain a Netbeans and an Eclipse project for our code in SVN right now with no troubles at all. The Netbeans files don't step on the Eclipse files. We have our projects structured like this:
sample-project
+ bin
+ launches
+ lib
+ logs
+ nbproject
+ src
+ java
.classpath
.project
build.xml
The biggest points seem to be:
Prohibit any absolute paths in the
project files for either IDE.
Set the project files to output the
class files to the same directory.
svn:ignore the private
directory in the .nbproject
directory.
svn:ignore the directory used for
class file output from the IDEs and any other runtime generated directories like the logs directory above.
Have people using both consistently
so that differences get resolved
quickly.
Also maintain a build system
independent of the IDEs such as
cruisecontrol.
Use UTF-8 and correct any encoding issues
immediately.
We are developing on Fedora 9 32-bit and 64-bit, Vista, and WindowsXP and about half of the developers use one IDE or the other. A few use both and switch back and forth regularly.
The smart ass answer is "by doing so" - unless you aren't working with multiple IDEs you don't know if you are really prepared for working with multiple IDEs. Honest. :)
I always have seen multiple platforms as more cumbersome, as they may use different encoding standards (e.g. Windows may default to ISO-8859-1, Linux to UTF-8) - for me encoding has caused way more issues than IDEs.
Some more pointers:
You might want to go with Maven (http://maven.apache.org), let it generate IDE specific files and never commit them to source control.
In order to be sure that you are generating the correct artefacts, you should have a dedicated server build your deliverables (e.g. cruisecontrol), either with the help of ant, maven or any other tool. These deliverables are the ones that are tested outside of development machines. Great way to make people aware that there is another world outside their own machine.
Prohibit any machine specific path to be contained in any IDE specific file found in source control. Always reference external libraries by logical path names, preferable containing their version (if you don't use maven)
The best thing is probably to not commit any IDE related file (such as Eclipse's .project), that way everyone can checkout the project and do his thing as he wants.
That being said, I guess most IDEs have their own config file scheme, so maybe you can commit it all without having any conflict, but it feels messy imo.
For the most part I'd agree with seldaek, but I'm also inclined to say that you should at least give a file that says what the dependencies are, what Java version to use to compile, etc, and anything extra that a NetBeans/Eclipse developer might need to compile in their IDE.
We currently only use Eclipse and so we commit all the Eclipse .classpath .project files to svn which I think is the better solution because then everyone is able too reproduce errors and what-not easily instead of faffing about with IDE specifics.
I'm of the philosophy that the build should be done with a "lowest common denominator" approach. What goes into source control is what is required to do the build. While I develop exclusively in with Eclipse, my build is with ant at the command line.
With respect to source control, I only check in files that are essential to the build from the command line. No Eclipse files. When I setup a new development machine (seems like twice a year), it takes a little effort to get Eclipse to import the project from an ant build file but nothing scary. (In theory, this should work the same for other IDEs, no? Surly they must be able to import from ant?)
I've also documented how to setup a bare minimum build environment.
I use maven, and check in just the pom & source.
After checking out a project, I run mvn eclipse:eclipse
I tell svn to ignore the generated .project, etc.
Here's what i do:
Only maintain in source control your ant build script and associated classpath. Classpath could either be explicit in the ant script, a property file or managed by ivy.
write an ant target to generate the Eclipse .classpath file from the ant classpath
Netbeans will use your build script and classpath, just configure it to do so through a free form project.
This way you get IDE independent build scripts and happy developers :)
There's a blog on netbeans site on how to do 3. but i can't find it right now. I've put some notes on how to do the above on my site - link text (quick and ugly though, sorry)
Note that if you're using Ivy (a good idea) and eclipse you might be tempted to use the eclipse ivy plugin. I've used it and found it to be horribly buggy and unreliable. Better to use 2. above.