I think it goes without saying that I should be able to use Oracle's own JDK with JavaFX (from gluonhq) to build a distributable jar file that users can just USE.
After an exhaustive search, much reading (24 hours or more over the last few months)and finally this Google search query:
how to make a fat jar -maven -gradle -scala -eclipse -ant -docker -hadoop -netbeans -jerkar -phy -mozni -yogurt -pizza - throwing -python -bacon
I'm absolutely at the end of the road. Why on earth is this so much work? How can I build a JavaFX application and give it to people that want to actually use it without knowing anything else except how to use the application itself?
This has been answered a few times already for Maven and Gradle. Build tools make things way easier than doing it on command line, and not only because of the dependency management.
Since you ask specifically about command line, there is already a full set of instructions documented for it here: https://openjfx.io/openjfx-docs/#modular.
Non modular App
The section Non-Modular from CLI covers JavaFX non-modular projects from command line, and gives you the whole set of instructions to create an old classic fat jar, where all the dependencies, including the JavaFX ones, are bundled all together.
There is a note that warns you not to use this procedure:
Warning: This is a discouraged tedious error-prone manual process that should be avoided by using the Maven's shade plugin or the Gradle's jar task, in case jlink is not applicable.
After you get the fat jar (it can be cross-platform), you can distribute it, and your user will need to have Java installed and run:
java -jar myFat.jar
Modular App
The section Modular from CLI covers JavaFX modular projects from command line, and refers to the use of the jlink command, in terms of distribution, as it creates a custom image that you can send to your users. It is not a fat jar, but it will allow you sending a zip to your user that needs only to be unzipped and run like:
hellofx/bin/java -m hellofx/hellofx.HelloFX
In this case your user won't even need to have Java installed.
And with a little bit of extra work you can also create a batch, so you can run:
hellofx
However, if you still want to do a fat jar with a modular app, you can still apply the exact same instructions from the non-modular apps. In this case, you will probably have to remove the module-info.java file, as it doesn't really makes sense at this point.
Other options
You still have a few more options to distribute your application.
Custom Java+JavaFX image
Another option, covered in the same document, section Custom JDK+JavaFX image, explains how to create your own "JDK" that includes JavaFX. Then you will produce your jar as usual in Java 8 and you will be able to run it with:
/path/to/custom/java -jar myFat.jar
Note that there are already some JDK distributions that bundle JavaFX, like this one.
jpackage
jpackage tool is not there yet, but there is an early access: http://jdk.java.net/jpackage/, that is using Java 13-internal. The exiting documentation explains what are the command line options you need to produce a custom image or an installer.
Note that you can still use JavaFX 11 or 12 with this.
Build tools
And finally, you can still decide to use build tools (Maven or Gradle), that will really help you in many ways. See any of the linked questions above.
I have just set up Nailgun (https://github.com/martylamb/nailgun, http://martiansoftware.com/nailgun/), which is a clever piece of kit which makes the JVM hang around in memory making Java and Jython (potentially) launch more quickly.
This is great for Java, but it promises to be absolute gold dust for me for Jython, particularly during development (Jython is the best language in the world, but has a slow start-up time).
Googling to see whether anyone had tackled running Nailgun on Eclipse I found a red herring, which is "nailgun/eclipse-gtkrc" at GitHub: "nailgun" is just the guy's handle.
I also found a CS dept had in fact tackled this, at http://www.cs.dartmouth.edu/~jygsaw/getting_started.html. They seem actually to have managed getting this working for Jython, which was potentially brilliant, but unfortunately their system relies on using a BASH script (Mac OS), and I'm forced to work on Windows (W7) for the moment.
What I then did was
1) Started up the Nailgun server outside Eclipse, including jython.jar in the CLASSPATH,
2) Then I created a client.bat file consisting of a single line:
ng org.python.util.jython %1
3) Then I set up an "external tool configuration" in Eclipse called "ng_client", as per the above CS dept's instructions, except that I set the Location to the above client.bat file, and I made the Arguments: "${selected_resource_loc}" (<-- including quotes, because unfortunately at the moment I have spaces in this path)
4) I ran this "ng_client" once so it failed, but was then included in this External tools list of tools.
5) I then selected a trivial Jython py file (trivial.py) and went Run --> External tools --> ng_client.
The console showed the following result
C:\Program Files (x86)\eclipse-jee-luna-SR2-win32\eclipse>ng
org.python.util.jython "G:\My Documents\software projects\trivial.py"
recv: No error
NB "recv: No error" is in red. The program, I hasten to add, did not run.
Incidentally, for anyone interested, this led to the Nailgun server terminal giving out the following error message:
C:\Users\Mike>java com.martiansoftware.nailgun.NGServer
NGServer 0.9.2-SNAPSHOT started on all addresses, port 2113.
NGSession 1: 127.0.0.1: org.python.util.jython exited with status -1
java.lang.ClassCastException: org.python.util.JLineConsole$Stream cannot be cast
to com.martiansoftware.nailgun.ThreadLocalInputStream
at com.martiansoftware.nailgun.NGSession.run(NGSession.java:263)
Exception in thread "NGSession 2: 127.0.0.1: org.python.util.jython" java.lang.C
lassCastException: org.python.util.JLineConsole$Stream cannot be cast to com.mar
tiansoftware.nailgun.ThreadLocalInputStream
at com.martiansoftware.nailgun.NGSession.run(NGSession.java:381)
I seem to be quite close ... does any Eclipse expert have any idea how I should proceed?
PS I've also tried running a trivial Jython program outside of Eclipse. So far it always trips up the Nailgun server as above. There is a bit of evidence out there of people doing it successfully, but they always seem to be on a Linux box, not Windows. Naturally enough I'm planning to take a look at the server source code where the errors are happening in due course.
Result!
And it makes Jython start-ups super-fast. I recommend this to all Jythonistas.
As I realised eventually yesterday (PS comment), the first thing was to get Jython to run outside Eclipse.
What I found I had to do was comment out 6 lines in the file nailgun-master\nailgun-server\src\main\java\com\martiansoftware\nailgun\NGSession.java:
ll 263-265
ll 381-383
And then rebuild the jar as per Nailgun setup instructions (i.e. mvn clean install).
After this, I made a handy .bat file to run the Nailgun server ("...\jars" is the place where I put nailgun-server-0.9.2-SNAPSHOT.jar and all the other jars I want to include):
set classpath=d:/apps/jython2.7.0/jython.jar;d:/apps/jython2.7.0/jars/*
java com.martiansoftware.nailgun.NGServer
After this, to run from a DOS window go:
ng org.python.util.jython "G:\My Documents\software projects\my_jython_project\__main__.py"
And then, in Eclipse, after following the steps above for setting up ng_client, select the .py file you want to run (in Project explorer window) and go
Run --> External tools --> ng_client
NB the sys.out & sys.err output is directed to the server window... presumably this is a consequence of the changes made to NGSession.java. If the Nailgun author, Marty Lamb, ever reads this, first Thanks for this great app, and second it'd be nice if you have any comments about the changes I made to NGSession.java.
later
Some strange things happen... hopefully just teething troubles.
In particular, I wanted to use this for unit testing which, like most development, involves constantly running things over and over. The trouble is I tend to find that the classes I am developing sometimes seem to "linger" in the "Nailgun memory". I've even seen classes run an older version of themselves when the NG server is stopped and a new one started... which is utterly baffling. It tends to suggest that older versions of .class files are somehow being "cached" in the Nailgun memory when I don't want them to be. And this happens even when using the "ng-cp" option to specify CLASSPATH additions in the client, not the server!
Unfortunately this is all quite "niche": using the Jython with the unittest module, running Nailgun. Sigh.
Instead of making the code changes to Nailgun that Mike suggests doing to prevent the java.lang.ClassCastException, an alternative is to change the console used by Jython to the PlainConsole by supplying the following system property when you start Nailgun:
-Dpython.console=org.python.core.PlainConsole
This prevents the class cast exceptions and results in the console output being returned to the client rather than the server window too.
I'm aware several people have asked very similar questions to this one, but I really need help finding the solution to my particular case.
Please read and understand this question before posting an answer :)
I'm using
Eclipse (both Juno and Kepler)
JDK 1.7
Tomcat 7
the Sysdeo Tomcat plugin
and in one particular project (other projects are fine), the following happens:
I set a breakpoint
start Tomcat
execution arrives at that point
I get a message: "Unable to install breakpoint on com.foo.bar.Main.class due to missing line number attributes" Reason: Absent Line Number Information
The thing is, if it can't install a break point - why is it stopping at exactly that point in the code where I set the breakpoint? Also, it says line number information is missing but I've verified all Compiler options and even used javap to confirm that line number information is in the compiled Main class file.
Note:
I am not using Ant to build
I am using the 1.7 JDK in Eclipse (not JRE)
Any guidance or suggestions welcomed.
Edit:
Hmm.. further information that may be important. I'm using Spring, and the actual class that Eclipse tells me has no Line Number Information is actually of the form: 'Main$$EnhancerByCGLIB$$87eae52c'
Could it be that a pre-compilation layer is generating classes without line numbers?
Maybe your class files in Eclipse class path is not matched with the class files you have in Tomcat webapp folder. There are out of synchronization.
You can try to deploy newly built war file again.
Having dealt with yet another stupid eclipse problem, I want to try to get the lightest, most minimal Eclipse installation as possible.
To be clear, I use eclipse for two things:
Editing Java
Debugging Java
Everything else I do through Emacs/Zsh (editing JSP/XML/JS, file management, SVN check-in, etc). I have not found any aspect of working in Eclipse to do these tasks to be efficient or even reliable, so I do not want plug-ins that relate to it.
From the eclipse.org site, this is the lightest install of eclipse that they have, and I don't want any of those things (Bugzilla, Mylyn, CVS xml_ui), and have actually had problems with each of them even though I do not use them.
So what is the minimal build I can get that will:
Ignore SVN metadata
Includes the full-featured editor (intellisense and type-finding)
Includes the full-featured debugger (standard Eclipse/JDK)
Does not have any extra plug-ins, platforms, or "integrations" with other platforms, specifically, I don't want to deal with plug-ins relating to:
Maven, JSP Validation, Javascript editing or validation, CVS or SVN, Mylyn, Spring or Hibernate "natures", app servers like a bundled Tomcat/GlassFish/etc, J2EE tools, or anything of the like.
I do primarily Spring/Hibernate/web-mvc apps, and have never dealt with an Eclipse plug-in that handles any of it gracefully, I can work effectively with my own toolset, but Eclipse extensions do nothing but get in the way.
I have worked with plain eclipse up to Ganymede, MyEclipse (up to 7.5), and the latest version of Spring-SourceTools, and find that they are all saddled with buggy useless plug-ins (though the combination is always different).
Switching to NetBeans/Intellij is not an option, and my teammates work with SVN-controlled .class/.project files, so it pretty much has to be Eclipse.
Does anyone have any good advice on how I can save a few grey hairs?
You can download the empty Eclipse platform and then manually install the JDT tools.
Go to the The Eclipse Project Downloads page.
Choose the bundle you want, probably Latest Release.
On the download page of the chosen bundle:
Download Platform Runtime Binary
Download JDT Runtime Binary
Extract the Platform Runtime Binary archive file and run it (for example, by double clicking on eclipse.exe).
Install the JDT binary:
Click Help → Install New Software → Add... → Archive.
Choose the JDT zip file you downloaded.
Uncheck Group Items by category.
Select the Eclipse Java Development Tools.
Click next to install and restart Eclipse when prompted.
JDT from the Eclipse update site
You can also install JDT from the Eclipse update site, instead of downloading the binary.
To do this, do this following:
Skip downloading the JDT Runtime Binary, only download, extract and run the Platform Runtime Binary.
Go to the Install New Software, but instead of Archive chose the Eclipse download site.
Search and install Eclipse Java Development Tools.
The "Eclipse IDE for Java Developers" version isn't the smallest one! Look for "Eclipse Classic" - it doesn't contain most of the things you mentioned. It's larger in download size only, because it comes with source code.
See this comparison: http://www.eclipse.org/downloads/compare.php
You can use a thirdparty distribution builder like Yoxos and download just what you want.
A bit late to this party, but I asked myself the same question for a while, and while now I'm back to a more fully-fledged Eclipse installation, I used to to the following to streamline it a bit. Hope it helps.
What I Needed
Functionalities:
Java Support
Java + Java EE (XML) + Debug Perspectives
Pretty much it. There's a lot of other things I like to use in Eclipse, but I needed to keep it down to the skinniest possible because I was in a 3GB environment where I also needed to run other servers in parallel, so I couldn't afford much.
Resulting Perspectives:
Lightweight Java
Lightweight Browser (fairly tweaked for code reviews and code inspection - that one was actually heavier than the others)
Lightweight Debug
What I Did
Install Eclipse Java EE (install classic if not caring about the Java EE/XML bits)
disable hungry views
disable outline (when you need one, just do CTRL+O)
disable call and type hierarchies
disable decorators
disable menu entries (right-
disable toolbar items
even better: hide the toolbar
disable hovers and actions associated with that
disable spell-checking
disable XML validation
disable Mylyn
disable non-needed search forms in CTRL+H dialog (I usually actually only use the "File Search" mode, sometimes the "Java" one)
disable usage reporting
disable unnecessary plugins or features
disables perspectives and plugins loaded automatically on startup
restrict internal limits:
some views have a scope (enclosing class, project, working set, workspace...)
some views and UI elements have boundaries (console/loggers, highlighters, markers...)
tweak the eclipse.ini to:
-clean the workspace (slower, but I tend to prefer to do that)
use G1GC
reduce memory usage (I noticed that I can perfectly live with -xss128k and -xmx384 with G1, for instance. YMMV, of course, as always with JVM tuning.)
use a server VM (and point directly to the VM's DLL)
Also disable views you don't need in the "Debug" and "Code Browsing" perspectives.
Sorry, I had actually saved all of these as a set of 3 lightweight perspectives to re-import everytime on my new project, but I cannot get my hands on them at the moment. If I ever find then, I'll add a link to them here.
Instead of going for a ready package from Eclipse Downloads, from the same page go for the Eclipse Installer. Currently available for Mac, Windows & the beloved Linux. Launch the Installer which should update (or not if you are lucky enough :) ). Select "Eclipse Platform" which is the absolute minimum from this IDE, set your other installation preferences and install.
After the download/installation process, I'd suggest your head to Help->Install New Software and search for the Eclipse Marketplace (Yes, even that is not included in this package) just to make your life a bit easier.
Get as minimal an installation as you can, and then remove whatever is left that you don't want.
Longer answer:
I played around a bit. Here's how I experimented:
Extract a clean eclipse*.zip to two different directories; call it eclipse and eclipse-bak. We'll only modify eclipse.
Before starting it the first time, remove some of the features from the features folder. I got rid of org.eclipse.cvs, org.eclipse.epp.\*, ...mylyn\*, ...wst\*.
Start up Eclipse to a workspace. Create in that workspace a Java project, debugging configuration, etc. Stuff that you would want to do and that will complain if we remove the wrong thing. Open up the Error Log view.
Close Eclipse. Remove something (or a group of things) from the plugins folder.
Open Eclipse. Check the error log to see if something you care about couldn't load. If it did, add those things back from eclipse-bak/plugins. If not, close Eclipse and return to step 4 for a new set of plugins.
Using this I got my configuration to still be able to edit and debug Java files, but including only these plugins:
com.ibm.icu*
org.apache.*
org.eclipse.compare*
org.eclipse.core*
org.eclipse.debug*
org.eclipse.draw2d*
org.eclipse.ecf*
org.eclipse.epp.package.java*
org.eclipse.equinox*
org.eclipse.help*
org.eclipse.jdt*
org.eclipse.jface*
org.eclipse.ltk*
org.eclipse.osgi*
org.eclipse.platform*
org.eclipse.rcp*
org.eclipse.search*
org.eclipse.team.core
org.eclipse.team.ui
org.eclipse.text
org.eclipse.ui*
org.eclipse.update*
org.hamcrest*
org.sat4j*
Most of that is core stuff, but you might be able to trim it down further. Notably gone are Mylyn, the usage collector, EMF, CVS, WST, even JUnit (though I think you should keep JUnit).
I feel you man, when working with Eclipse, the application is constantly trying to help.
Ignoring workspace corruptions, I spend my development time fighting all the "helpful" things Eclipse does.
XML is not that hard to read, but it still confuses the shit out of me when I get the XML designer.
All it does for me is add an extra manual step to click on the source tab.
Every time a new version of eclipse comes out they redesign the front page and the distributions.
At which time a new quest starts for finding a way to debloat Eclipse again.
I have the same experience with extensions to Eclipse by third parties and avoid them if at all possible.
WTP has somewhat usefull stuff, but overall I prefer a basic java eclipse.
It is a good idea start with the Platform Runtime Binary and add JDT.
Manually extracting the JDT runtime doesn't seem to work for me these days, so it it better to use the update client.
You can use the marketplace client, but personally I have always found it rather annoying.
An alternative is to use the director. The director can install JDT without starting the GUI.
Here is a script that downloads eclipse Oxygen 4.7.3a and installs JDT unnattended:
#!/bin/sh
die() {
echo >&2 "$#"
exit 1
}
[ "$#" -eq 1 ] || die "exactly 1 argument required [INSTALL_DIR]"
[ -e "$1" ] && die "*warning* Aborting! location exists, eclipse already installed?"
INSTALL_DIR="$1"
TARBALL=eclipse-platform-4.7.3a-linux-gtk-x86_64.tar.gz
mkdir -p $INSTALL_DIR
if [ ! -f $TARBALL ]
then
wget http://mirror.csclub.uwaterloo.ca/eclipse/eclipse/downloads/drops4/R-4.7.3a-201803300640/$TARBALL
fi
tar -v -xf "$TARBALL" -C "$INSTALL_DIR" --strip 1
echo "\nUsing director to install java development tools, this may take a while..."
$INSTALL_DIR/eclipse -noSplash -application org.eclipse.equinox.p2.director -repository http://download.eclipse.org/eclipse/updates/4.7 -installIUs org.eclipse.jdt.feature.group
Simply call the script with one argument, the directory you want Eclipse installed.
Running the script gives me an unpacked install of roughly 129MB, which is more than 100MB smaller than the default download (zipped).
That is not to say you would not be able to shrink it further, but it should rid you of most of the crap.
The executable will be cached for future executions of the script, but it will still be slow, since it needs to go online to download JDT.
Unfortunately, I do not know of a way to cache the plugin download in a local folder.
You could of course zip the created installation, but the script is easier to commit to git.
This script will only work for new users as long as the mirror stays up and will need some updates when a new version is released.
But I am sure most developers are savvy enough to update the script if need be.
If you only want to use Eclipse for editing / Debugging Java I would suggest using a plain Text editor. It seems an overkill to install Eclipse and not use most of its features.
A very popular choice is VIM. Also check out this SO link for tips in using VIM as a Java editor. You can also debug Java code with a command line debugger as mentioned in this SO link.
I have figured out how to get the lightest possible eclipse with minimal efforts(imo). For the reference this is what I want in my eclipse:
Java project with Maven support
JavaEE support(Servers)
Debugging of Java application
(Irrespective of these you can install any feature that comes with Eclipse IDE with minimal effort, just follow the guide below)
Here's how I get it:
Go to eclipse download packages (Here's the link)
Find MORE DOWNLOADS (right hand side) and go to Other builds (Here's the link)
Now go to any build you like (Usually Latest Downloads -> whatever the first Build Name. Also There is links for older versions and archive site)
Under Platform Runtime Binary you can download Eclipse Platform as per your OS and/or requirement.
Now extract the archive and run the eclipse
Go to Help -> Install New Software...
Using Work with you can install your desired plugins and tools which usually ships with bulky eclipse
In Work with drop down select the site(mostly first) similar like this 2022-03 - https://download.eclipse.org/releases/2022-03 here 2022-03 is my eclipse version you may see different depending your version.
Now you can select the group(s) or expand the group(s) and select the specific plugins which you need and also you can filter by name like maven, debug, server, marketplace client etc in filter text input just below the Work with drop-down menu.
Install plugins and enjoy your very own lightweight eclipse.
Visual Studio Code
Fast forward to 2019 and we now can use Visual Studio Code with Java plugins. They provide a plugin pack to get you started with lightweight debugger and auto complete. Other plugins include maven integration, dependency viewer and more.
Visual Studio Code is a new(ish) editor/mini-ide from Microsoft which runs on Win/Max/Linux and has plugins for many languages.
Tutorial for setup: https://blog.usejournal.com/visual-studio-code-for-java-the-ultimate-guide-2019-8de7d2b59902
Edit 2019-06-21: MS now has a dedicated installer for Java integration with VS Code, including Spring Boot support as well. While the Intelisense is not 100%, it's vastly improved and now my go-to Java editor for testing and trying new things. Announcing the Visual Studio Code Installer for Java
Everything was going well. Nightly builds ran for more than a month with no problems. However, suddenly when invoking the feature builder from Eclipse the execution ends right away with the message.
ERRORLEVEL 13
As far as I know I haven't changed anything, as this computer is normally not touched. (It is only used for the nightly builds).
I've googled around to see what this error means but to no avail. I found a link from IBM that shows a custom bat file that catches this error, but the explanation given is not very useful.
My guess is that this is related to the workspace, somehow, or that the whole eclipse installation is corrupted.
Do you have any idea what this error means and how can it be corrected?
After reading what the error code means thanks to the answer from VonC I understood where to look. The problem was a lot more obscure that it seems.
I looked into the configuration folder for Eclipse (logs are either written there or in the .metadata folder when something goes wrong), and I found a huge log file. Inside the file I found the following error:
application org.eclipse.sdk not found
and the following exception, followed by a plugin name, several times:
java.util.zip.ZipException: Too many open files
Several plugins could not be loaded, causing a cascade of missing dependencies that prevented Eclipse from launching. I searched the web for this exception and found the following bug description from SUN, which says that Java 1.5.0 can not open more than 2,100 zip files.
The problem started a while after I installed the BABEL project translations for Eclipse into the build computer. These are more than 900 fragments, containing translations for many plugins, one for each language. As I installed it on top of an existing eclipse installation, it seemed that it was not a problem to open them.... until I cleared the workspace for the builds. Then Eclipse wouldn't launch anymore. I went over the limit. It didn't help that the first thing I tried to fix the build was, again.... clearing everything.
Because I only use this computer for headless builds, I didn't realize that the problem was in Eclipse itself and I was looking inside the build process. I only realized when I looked into the log file.
After installing Java 1.6.0_11 I was able to launch Eclipse and go on with my build.
It should mean "ant build failed", meaning the headless ant script fails at some point.
You should check if you can catch the log/output generated by this script to analyze this ant session and see at what point the ant script fails.
If it fails right away, it usually is because of:
a change in rights (writing access), or
in environment variable modifications, or
in resource access (path non accessible).
You also have to check if the computer is still in its original windows domain, and if the rights (admin ?) associated with the account running the ant script are still the same.