I have a JavaFX app that reads in a configuration file. I'd like the config file to remain outside of the jar to facilitate modification without recompiling. Is there a way to set up netbeans to grab the config file and include it in the installer?
I've found the option to change to icon and that works fine but I haven't been able to discover how to tell it to also include specific external resources.
I've read the information posted here: http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm but I'm still not seeing a way to accomplish this.
I don't think there's a way to do this (though I may be wrong). I needed something similar to this once, and the approach I took was
Package the file in the jar file
At program start-up time, check to see if the file exists in the expected location on the local drive
If it's there, read it, etc
Otherwise, read the contents from the jar and write them to the expected file
This solves the problem of "deploying outside the jar", and it also solves the problem of the user inadvertently deleting the file after deployment, etc.
The way I solved this issue (due to having many dependent .dll's and other type items) was to use netbeans to compile the jar, which has things like images/css/fxml etc. etc. and then use an Inno Script to actually compile and configure the installer, since inno makes it pretty straightforward to include extra resources. I have yet to find a way to do this properly within javafx itself.
Related
I'm re-using a standalone Swing-based Java class which backs up and restores mysql databases.
I've tested running it from a Windows batch file (.bat) on my dev system, and it works there.
But, if I run the batch file on a different Windows , I get a "main class not found" exception.
However, when I run the command directly on the command line, it works.
The command in the batch file to run it is:
java -cp lda-services.jar;bip-services-1.6.0.0-SNAPSHOT.jar;decryptor-1.6.0.0-SNAPSHOT.jar;slf4j-api-1.7.31.jar;commons-io-2.6.jar com.ilcore.util.SosaMaintenanceJFrame
The SosaMaintenanceJFrame class is contained in the lda-services jar.
Here's the error message:
Error: Could not find or load main class com.ilcore.util.SosaMaintenanceJFrame
Caused by: java.lang.ClassNotFoundException: com.ilcore.util.SosaMaintenanceJFrame
The class is definitely in the jar file, as I've extracted it the file and seen it.
Any thoughts on why this would be happening? I need to run inside a batch file so the user can just click on it to run it.
Most likely explanation
Your paths are relative, which means that the batch file isn't going to work unless you run it from the right place. In general, having a batch file that has an invisible rider stapled to it with: "I break in mysterious ways if not run from the appropriate dir" is a crappy batch file - make it better.
Better solution
Or, even better, get rid of it. You don't need batch files to distribute java programs.
Proper ways to distribute java programs:
The modern take is very very different from what you have here: JREs are dead, you must ship an installer that does the whole thing, notably including a java runtime (no longer called a JRE, and one you ship and keep up to date if relevant). That's perhaps a bridge too far for what you're doing here. Relevant tools include jlink.
A slightly less modern take involves jars with manifests:
Your jar file should contain a manifest. This manifest must contain 2 relevant entries:
Class-Path: lda-services.jar bip-services-1.6.0.0-SNAPSHOT.jar decryptor-1.6.0.0-SNAPSHOT.jar slf4j-api-1.7.31.jar commons-io-2.6.jar
and
Main-Class: com.ilcore.util.SosaMaintenanceJFrame
You can use jar's -m switch, or just include the manifest (it's just a file in the jar): it's at META_INF/MANIFEST.MF and it's a text file, each line is an entry, and an entry consists of a key: value pair.
When a jar contains this, just double clicking the jar and running java -jar thejar.jar will then take care of it all: Java will load the stated jars as part of the classpath, and these, crucially, are resolved as paths relative to the directory the jar is in, so it DOES work when you try to launch them from elsewhere, i.e. if you do:
C:
CD \
java -jar "c:\Program Files\MyApp\myapp.jar"
it works fine, whereas that batch script would fail due to being in the wrong place.
Build systems let you define the manifest too, check your build systems docs for how to do this, it'll be easy, and there are tons of tutorials if you search the web for e.g. 'manifest executable jar maven' or whatnot.
You can consider making a shaded jar. But I wouldn't.
A shaded jar takes all your dependencies and packs them into your main jar, so that there is only one jar. There is now no need for a Class-Path entry (the jar you run is obviously already on the classpath and there's nothing else to include) and your app is shipped as 'just' a single jar file.
But this is mostly a red herring: There are no consumer JREs anymore so you've made the user experience from a D- to a D. If you actually care about giving your users a nice experience, there's no getting around an installation process of some sort and once you have that, having the separate jars is no longer a problem. Separate jars are less hairy when signed jars are involved, are much easier to keep up to date, and have a significantly faster turnaround (when you build your stuff and want to ship what you built, shading takes ages, so it's nice to cut that step out). The faster your CI system tells you about failing tests, the better.
Meet in the middle
You don't have to upgrade to modules and the like. What you can do instead is use something like launch4j. The aim is to end up with a zip file along with the installation instructions: Make a dir somewhere. unzip this zip in it. Doubleclick 'myapp.exe'. Done.
The zip would contain an entire JRE, all your jar file deps, and your main app, and an exe file which launch4j made for you, that launches your app using the JRE packed into the jar. This means you know exactly which JRE is being used, and it'll work even on systems that didn't have one installed yet (which, these days, should be all of them - the notion of 'end user downloads a JRE from oracle and the user + oracle work together to keep that thing up to date and security-issue-free', is dead).
The fact that it's an EXE is nice: Now if the user e.g. alt+tabs through their apps, they get your app, with your name, and your icon, instead of 'javaw.exe' with an ugly coffee mug logo.
But when I try running it from the jar file generated by Maven, however, I get a "class not found" exception.
Even if you didn't get that error, you'd get another one unless you'd used Maven Shade, as that's the only way you're going to run that with a single jar. My guess as to why that particular error occurs is that the app class you're attempting to run is in fact in one of the *SNAPSHOT* jars
I need to provide a settings file for my program, to which the user should have access to write some of the settings i need.
I created a file under a new directory (called settings) on the root of my application, but i have problem finding it at run time.
I use
File SettingsFile=new File(ClassLoader.getSystemClassLoader().getResource(".").getPath()+"settings/CreateSettings.txt");
When i execute this under eclipse i get
/application/home/dir/target/classes/settings/ZipCreateSettings.txt which is wrong.
If i execute it on terminal using java -jar, i get the correct path,
/application/home/dir/settings/ZipCreateSettings.txt
This would cause me problems cos i need to run the application directly from eclipse and not use the terminal, even though it is going to be executed using the jar when it is up and running.
I cant keep it like that anyway, cos this code might end up in someone else's hands, and they would have no idea what to do with it.
I have also used some other techniques like
new java.io.File("").getAbsolutePath(); but this always gives me the current working directory, so if i execute the jar from /home, i would get /home.
I think the problem might be maven (which i am not familiar with at all) since my code worked with a plain java application some time ago.
Since your file will be located outside your classpath, it is basically outside your application. Your application is not aware of files existing outside it's classpath. So you will need some kind of way to provide the Full/Absolute path to your file. You can't use the classloader in your case.
I suggest you use a system param instead of a hardcoded value. See here
One of the problems I'm running into is that my jar files and my source files don't match.
I'd like to:
Be Notified when when source and binary don't match (I think Visual Studio can do something like this...)
Set break points not by line, but by function. For example, set a break point at the entry of function foo().
I use eclipse mainly; so Solutions for eclipse would be most appreciated, but any IDE (or command line debugger) will do.
Thanks!
When developing just use and link to .class files that are saved by your IDE.
If your project starts to grow to a point where it's really useful to link to a .jar you're better off treating the jar's as separate projects.
Go to Project tab in Eclipse and then
click clean: Project->Clean…
click build automatically: Project->Build automatically
Use method breakpoints instead of line breakpoints. They can be set to halt on entering/exiting a method. You get them by double clicking the left editor side in a line containing a method declaration.
The debug information is limited to line numbers in the source file... I do agree that having a warning that the lines are wrong would be nice, but that would require more meta data in the jar than I think is available...
You might want to consider addressing the challenge with a change in your build process. This isn't exactly answering your question, but hopefully it will give you a strategy that will address the underlying problem.
When you generate the jar for deployment, also generate a jar with the binary AND source. For investigating the source code of a stack trace on the live server, set up a separate project in eclipse and have the binary+source jar be on the classpath. You may have to explicitly set the source code location back to the same jar (though I think Eclipse will just do this automatically).
Then you just have to add copying of the binary+source jar into the appropriate location in your workspace as you do your deployments (preferably with a deployment script).
If it's your server, you may want to even consider deploying the binary+source jar to the live server - that way you will always be able to get at the source.
we have downloaded jar files for lambdaj and its dependencies which are again jar files.
we do not know how to go about it. we have copied these files in the
C:\Program Files\Java\jre6\lib\ext
have set the class path in environment variales as:
variable: classpath
path: C:\Program Files\Java\jre6\lib\ext
but we do not know how to go further. we want to run some lambdaj programs.
can anyone suggest how to run lambdaj programs?
You would run a Java program that requires lambdaj in exactly the same way you'd run any other java program with an external dependency, i.e. by invoking the java executable passing in the fully-qualified name of the Main class, or the JAR with an appropriate manifest, or by deploying it in a servlet container, etc. Additionally you should be putting the LambdaJ JAR on the classpath for this invocation, not in the lib folder for your entire JVM.
What have you tried so far and why/how is it not working? Your question at the moment is a bit analogous to "I want to use Microsoft Word to view some Word documents, how do I do this?".
Update for comment 1: You said "it's not working". That doesn't help anyone address your problem as it gives no clue what you expected to happen and what you observed, only that they were different. As for where JAR files can be stored - you can put them in any directory, so long as that directory is on the classpath (or you add it to the classpath) of the Java application that runs. The canonical place to put external dependencies is in a folder called lib below the root of your project, but the important thing is that you choose somewhere consistent and sensible.
It sounds like you don't quite grok Java and classpaths yet. If you have followed some tutorials and are still stuck, ask for help to let you understand. Adding more detail to your question, including the layout of your files, the commands you issued, and the response that came back would be useful too.
If you are using Netbeans create a project and right click on the Libraries folder within the desired project. Click Add JAR/Folder...
I was unfortunately forced to result to uploading a WAR file as my backup for a web application I am working on.
Luckily I have the most recent WAR file available. I am using Eclipse IDE and am using the Web Tools plugin for all the J2EE work that I am doing with the Dynamic Web Application Project.
When I imported my WAR file, and ran it on a local server, everything works fine. The problem I a ran into is that in the Java Resources/src folder that all my packages and .java files were now only consists of all the same packages, but they are empty.
I checked to see if I could find the files and I found the .class files in an "Imported files" folder that is not accessible in the Eclipse Project Explorer. I believe that I need to do some type of build or something so that my .java files are available for me, but unfortunately this is one area where I lack.
One thing I would also like to know is, one way or the other, am I able to obtain the .java source code files if I have access to the .class files?
Also, I would like to configure this environment as it was before where my Java Resources:src folder contaiend the packages and .java files.
One thing I would also like to know is, one way or the other, am I able to obtain the .java source code files if I have access to the .class files?
The short answer is No. There is no way to regenerate original source files from bytecode files.
If you were really, really desperate you could try to use a Java bytecode decompiler on your bytecode files, but the result will be be nothing like your original source code.
All comments and javadocs will be gone.
All original code layout will be gone.
Original local variable and parameter names may be gone, depending on your original compiler switches.
Constant expressions may have been pre-evaluated, and loops, string concatenations and other constructs may have been transformed unrecognizably.
Depending on the maturity of the decompiler, the Java code might not be semantically equivalent to the original code, and might not even be compilable.
I hope you haven't spent too long developing this application because the best answer may be to start again.