How to make an application to work with any Java versions? - eclipse

I have created a Java project application in eclipse and i am using the JRE System Library[JavaSE-1.7].
when i make an executable jar file of the application then test it on different computers which have different Java versions. The problem is that the jar file only works on some of the computers because of the java version.
my question is: is there away to make the application to check the computer see which java version it has and just use that version instead of the java version that was used to implement the project? in other words can you make an application which is not java version dependent?
any suggestion is of great help.
thanks
Thanks for all the suggestions and comments. But i think i'll just stick with the java 7 version and let the user know that they need java 7 to run it.

No, there's no way to check that, not in the way I think you mean.
In fact, on the one hand you have the Java version in which you compile the class (which you can choose), and on the other hand the Java version (of the JVM) in which your application runs (which you cannot choose).
Well, I do believe there's a way to check the Java version through some method call or similar, but I don't think it would help you here, I mean that I guess you can't do something like:
if(java-7) {
//do try-with-resources
} else {
// do usual try-statement
}
As #skiwi suggested, make sure your application compiles against an older Java version, and you should be fine with JVMs of that version and beyond.
I'm not sure what's causing your ClassNotFound error, but it could be that the JVM checks the required Java version needed and stops if it is above the available.
If you compile from the command line, there are switches to tell javac the source Java version and the target Java versions. I never had used them, so you better search for questions about them (i.e. javac source and target options). With those tools it will be the compiler that warns you against problems, without you having to explicitly check the version in your code.

There is a way to check the Java version, but you would need multiple executables to do it.
You would need a root executable, that would have a low-bar minimum Java version, simply so it can check the version of the systems, then it would launch an executable from there based on the system's Java version.
How you would come about this:
System.getProperty() allows you to, well, get system properties, along with a few other things, like versions of installed applications like Java.
You should create a separate JAR with one class:
public class Launcher {
public static void main(String[] args) {
String javaVersion = System.getProperty("java.version");
// Conditional to launch Jar file
if(correctVersion) { // if version is confirmed
Runtime.getRuntime().exec("java -jar whatever.jar");
}
}
}
The reason we need a root, lower bar executable, is because if the original executable can't run in the first place, how is it going to check the Java version?
Hope this works out for you. Sorry it took so long to get an answer.

Related

How do I use JavaFX in Eclipse 2021-06 JRE x86_64_16.0.2

There are a couple postings on this topic, but I can't get this to work with the latest version of Eclipse. I am using the JRE that comes with 2021-06, the one it puts in p2, x86_64_16.0.2.
I have tried various configurations of User Libraries, Maven dependencies, setting PATH_TO_FX, searching Eclipse Marketplace for JavaFX-as-a-plugin, e.g.,
How do I use JavaFX 11 in Eclipse? (2.5 years old)
https://www.javatpoint.com/javafx-with-eclipse
https://www.tutorialspoint.com/javafx-with-eclipse
https://gluonhq.com/products/javafx/
On a couple more elaborate examples, a couple builds had a scattering of missing methods, which I assume is due to JavaFX being somewhat in flux or instructions being quite outdated. I can get a simple Hello, World to build with javafx-sdk-17.0.1 as a User Library (what I'm doing now) and also some of the other configurations. When I try to launch Hello, World with various build-able configurations, I keep getting
Error: JavaFX runtime components are missing, and are required to run this application
Well, I was a bit too quick. I kept playing around, and adding quotes in the VM arg seems to work,
--module-path="C:\Program Files\Java\javafx-sdk-17.0.1\lib" --add-modules=javafx.controls
If the project is not a module project, the Used Library goes on the Classpath in the project properties, Libraries tab. If it is a module project, it goes on the Modulepath,and the following module-info.java file must be in the src with this minimal information:
module <myProject> {
requires javafx.controls;
exports <myPackageContainingFXAppClass>;
}
I just don't get it why people prefer to search half of the internet for tutorials instead of just consulting the official documentation first. Here it is: https://openjfx.io/openjfx-docs/#IDE-Eclipse It seems to be the best hidden secret that there actually is documentation for JavaFX that one could start with.
I just did the test. Googling for "javafx documentation" gives https://openjfx.io/ as the first search result.
I use --module-path=${PATH_TO_FX} --add-modules=javafx.controls.
Obviously PATH_TO_FX needs to be defined in Preferences->Run/Debug->String Substitution.

How to disallow a certain Java version in JNLP?

Sometimes there are serious regression bugs in Java which make our product unusable. So I would like to disallow the associated version, e.g. currently 8u161 and 8u162 (bug JDK-8195830).
How can I do so in JNLP? The docs only mention + as a wildcard. So is the only possible way to list all other Java versions instead? like
<java version="1.8.0_05"/>
<java version="1.8.0_11"/>
... until ...
<java version="1.8.0_151"/>
<java version="1.8.0_152"/>
?
Update:
So the result looks like this.
<java version="1.8.0_172+ 1.8.0_152 1.8.0_151 1.8.0_144 1.8.0_141 1.8.0_131 1.8.0_121 1.8.0_112 1.8.0_111 1.8.0_102 1.8.0_101 1.8.0_92 1.8.0_91 1.8.0_74 1.8.0_73 1.8.0_72 1.8.0_71 1.8.0_66 1.8.0_65 1.8.0_60 1.8.0_51 1.8.0_45 1.8.0_40 1.8.0_31 1.8.0_25 1.8.0_20 1.8.0_11 1.8.0_05"/>
Conclusion: In the end I decided not to provide any version constraints in the JNLP, because the popup says it recommends to start the application anyway – which is quite the opposite of what I have to tell the user.
The problems seems to be that *racle seems to have dropped support for loading and using earlier JREs except for the most up to date JRE.
Your approach seems to be the only pure JNLP-way as also suggested here.
You may also try to write it in one big line separated by spaces. The only thing which I would change is the order so that the highest is a the top.
"If several JREs are specified, this indicates a prioritized list of
the supported JREs, with the most preferred version first."
You may want to theck similar quesions posted here
A different approach to exclude a specific java version is to check it within your application.
public static void main(String [] args) {
String version = System.getProperty("java.version");
if("1.8.0_161".equals(version) || "1.8.0_162".equals(version){
//print an error dialog
}
else{
//continue normal flow
}
}
In a previous application I even went a bit further and had two different web applications: A "light" web application which was started before the actual application. This light web app nearly had no requirements regarding java version (even started with 1.4) and it would then check all the necessary requirements (Java Version, OS, RAM, CPU, files ...). Only after all went well the actual application would be started.

Cannot disable CompactStrings Java 9 using Netbeans

I am trying to disable the CompactStrings feature of Java 9 using the VM option: -XX:-CompactStrings, but it does not work.
When I tried to debug my application, the COMPACT_STRINGS variable in String class is always true (with or without the VM option)
I have the latest version of Java 9: jdk-9+181
And the Netbeans IDE Build 201709070001
I tried various options to set the VM option and none of them works.
What I tried is:
setting the VM option in app.conf, setting it in project.properties, running netbeans by ./netbeans -XX:-CompactStrings, setting the JVM option in Project->Properties->Run->VM Options
Is this a bug in Netbeans? Or am I doing something wrong?
I tried to reproduce your problem using a trivial "Hello World" Java application. However, toggling the CompactStrings feature in the project properties settings worked fine for me, and caused COMPACT_STRINGS to be set appropriately, so this is not a bug in NetBeans.
Although I am using the same version of Java (181) as you, I have a more recent Dev Build of NetBeans (Build 201709220002), and there are several discrepancies between my project properties screen and yours. For example, mine shows the Runtime Platform field but yours does not:
Something else to check is that you really do have the environment you expect. I find it easy to mess things up when multiple versions of Java and Netbeans are installed.
This is what I see when I do Help -> About:
If your environment looks fine then I can only suggest that you download the latest DEV Build of NetBeans and try again.

How to run GWT RequestFactory Validation Tool on Eclipse project

I've got a Android AppEngine Connected Project I'm trying to build using GWT2.4 RequestFactory and Objectify on my Eclipse IDE.
Apparently I need to run the RequestFactory Validation Tool because I'm using ServiceName and ProxyForName annotations (these are required especially when working on the Android client side). My problem is the Eclipse can't validate it and the solution provided at http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation#IDE_configuration is enough to make me rip my eyes out.
Since I'm working on a Windows machine, the shell script provided is not very useful. Trying to run Validation Tool from a cmd propt returns the error message:"This tool must be run with a JDK, not a JRE"
Can someone explain how this Tool is supposed to be run? Is there a way to use it as an External Tool in eclipse?
Normally if you follow carefully the instructions in the link you show, and run the GWT Development Mode from Eclipse, the Validation should be done automatically at the time you access the development URL with your browser.
For the record, I've actually had some problems with it, but launching the application several times maked it work.
Well, I ran into the same problem as well. When I tried annotation processing (under Java Compiler-> Annotation processing )was being disabled. So RequestFactoryDeobfuscatorBuilder was not being generated. Try enabling that and rebuilding your project.
I've just recovered from two days of hunting this bug down in a project that used to run validation properly but stopped.
In my case I had a new-ish generic BaseRequestContext and a specific sub-interface that extended it. My parent interface declared a method that didn't match the Locator's exactly (e.g. getThing(T) vs get(T)) and this wasn't reported as an error but did stop the validation tool from completing.
Apt is also removed in Java 8 : http://openjdk.java.net/jeps/117 . So beware.
Switching back to Java 7 will fix the issue if you are using Java 8.
I understood why the error happens sometimes in a project: the compiler was complaining it cannot find the directory .apt . But when I tried to create it manually it was not possible (under windows). I think the validation tool mutes the exception of not being able to create the directory: try renaming .apt in your validation tool calls (do a text search in your project)

Overriding acm.program init() method; does Java have to be this hard?

Java problems
I am a student of Java. I managed to write about 15 Java programs so far and get them working on the PC. But I have not yet written a init() method like my latest assignment requires in order to initialize some instance variables. The compiler tells me that my init() method is attempting to override the final init() method in the acm.program. Isn’t that what an init() method is supposed to do? After exhausting all avenues on PC for the last week, I thought maybe it is an Eclipse problem on the PC. All the example code in the Java documentation shows little Mac windows. So I thought I would try moving my code to a Mac running Lion OS 10.7.2.
Switching to MAC environment.
The Mac claims to have Java installed but I think it’s just the run time environment, not a development environment. All I could find for applications is the Java VisualVM, which I assume is the virtual machine so there is no java development software. So… I downloaded Eclipse for Mac from Stanford’s website and got Eclipse IDE for Java Developers Version: Helios Service Release 2 and tried to run a simple program which included an import statement.
The import acm.program.*; statement is giving the compiler a problem: "acm cannot be resolved”. After researching this I think the problem is I have not downloaded the acm.jar archive and added that to my build path. Why this isn’t already done for me, as part of Eclipse I have no clue. I guess everything has to be difficult.
So I downloaded the acm.jar archive and it’s sitting in my download folder. I tried double clicking it and thankfully the mac won’t execute it. I tried dragging it into my source folder in Eclipse and then adding it to the build path. Once in the build path, Eclipse tells me the jar is missing. So I removed it from the build path and instead from inside Eclipse went to Properties/Java Build Path/Libraries/add External JARS… and navigated to my downloads folder where the acm.jar folder is to select the JAR. However, Eclipse seems to be looking for a .jar;.zip file, which there are none because my Mac helpfully already unzipped the folder. So I changed the open window to look for all files (.) and now I see individual .java files that are too numerous to add to the build path individually.
So back to the PC and download the acm.jar zip file and copy it over to the Mac in unzipped form and again add it to the build path as a zip file. This resolved the compiler error and my simple program executed on the Mac!
Next I will try my program with the init() method to see if that now works. Nope. Same problem on the Mac. This init method causes the following error: Multiple markers at this line
overrides acm.program.Program.init
Cannot override the final method from
Program
public void init() {
canvas = new HangmanCanvas();
add(canvas);
}
Does it have to be this hard or am I missing something?
Generally Macs have the whole JDK installed. Eclipse is nice, though.
This "acm" package isn't installed because it's not any kind of standard thing; this is like asking why your refrigerator doesn't come with asparagus already in it.
That last dialog was the right one; you need the original jar file. Try again, right-click and "Save As..." the link to save the file from your browser.
See 3. I find it particularly funny that anybody would use a Windows computer to make up for shortcomings of a Mac; in reality the Mac is infinitely more flexible and more powerful.
If you got a message that complains you're trying to override a final method, then you are indeed trying to do something wrong; final actually means "You're not allowed to override this." Perhaps you didn't fully understand the instructions for the assignment.
It gets better, I promise. Just be sure to use each of these annoyances as a learning experience.
There is no reasons why Java for the Mac would be any better than Java for the PC. The language and tools should work the same ... assuming that you are using the same versions of the language and similar versions of the tools.
Your problem with init is nothing to do with PCs versus Macs. So don't waste your time switching platforms to try to fix it. You need to figure out what the
On the face of is, the compiler / IDE is telling you the truth. Java won't let you override a final method. In fact the whole point of declaring a method to be final is to prevent overloading.
However, this does not make sense. According to the documentation I found here, the acm.program.Program.init() method is designed to be overridden. So why won't it let you?
I suspect that the cause of your problems is that you've downloaded or been given a copy of the JAR file that someone has messed around with. Someone has changes the method to be final (for some reason best kown to themselves), compiled it and put it up for people to download. Google is not always your friend ...
So, what I suggest you do is review all of the handouts and the files that were provided to find either the copy of the JAR that is provided, or the instructions on WHERE to download it from. Then replace the copy of the JAR you are currently using with the recommended one.
Why this isn’t already done for me, as part of Eclipse I have no clue. I guess everything has to be difficult.
How is Eclipse supposed to know what this "acm" stuff is? Which version you require? Where to download it from?