I'm writing a spring boot app where I am required to fetch the Linux distribution version within a function.
For example, if my app is running on an Ubuntu-16.04 machine, then I would like to know this version within my method. Or if I'm working on CentOS 6.9, then the method should return this.
I found that jvm stores some system properties which has os name, version and architecture. But the problem is that I have no way of determining the distribution from the kernel version number.
There is also the method of reading /etc/os-release, but this file is not present in older versions of centos.
I also found that /proc/version is not always present.
Is there a generic way to obtain this distribution value?
Java 8 and prior versions have Java Web Start, which auto-updates the application when we change it. Oracle has recommended that users migrate to jlink, as that is the new Oracle technology. So far, this sounds good. This comes with a host of benefits:
Native code on Windows, Mac and Linux
Modularization of the code (although Proguard does this as well)
The use of new, supported technology.
The problem: I can't find the canonical Java solution to auto-update with jlink.
One would think that Java Web Start could continue to be used, especially if one casually reads this document. Notice the fact that Java Web Start continues to be prominently listed. But there's a fly in the ointment: Oracle is deprecating Java Web Start. It's slated for removal in JDK 11. So, what's the official path forward. Failing that, is there a standard way that people proceed?
For the purposes of this question the following are out of scope:
Paying huge amounts of money yearly to someone with an feature-packed enterprise solution. The application to be distributed is already packaged into a single jar that is smaller than 50MB.
Forcing users to run an InstallShield style app to reinstall the new version, and then manually uninstall the old version every time an update is pushed. That's sooo 1990's.
Porting the entire app to be a webapp, rewriting the UI and client side logic to fit in a browser and dealing with all the incompatibilities that entails. The authors of the application worked on GWT and know exactly what web browsers are capable of. Unfortunately, they also know the level of effort required.
Allowing users to continue to run old versions of the application. That, too, is sooo 1980's. Modern apps update quickly, and supporting every version of the application ever released is not tenable. That's what my father's COBOL application had to deal with, and he didn't enjoy it. I'm hoping technology has progressed.
Continuing to use Java Web Start. Until/unless Oracle changes its mind, Java Web Start is a doomed technology.
In May 2019 commented to watch the OpenWebStart project.
Now (October 2019) it is time to give OpenWebStart serious consideration. While not yet feature complete, a alpha beta release of OpenWebStart is now available for download under a "GPL with Classpath exception" license.
The OpenWebStart Technical Details page states:
OpenWebStart is based on Iced-Tea-Web and the JNLP-specification defined in JSR-56. It will implement the most commonly used features of Java Web Start and it will be able to handle any typical JWS-based application. We plan to support all future versions of Java, starting with Java 11. In addition to Java 11, the first release of OpenWebStart will also support Java 8.
The page goes on to state that OpenWebStart will support interactive installers with auto-update, and non-interactive installers. Some JNLP features will be supported, and it will include a replacement for the Java Control Panel. A more comprehensive list of planned features1 and their implementation status is provided in the feature table.
1 - If you have a requirement that is not on their feature list (e.g. jlink support), you could contact the OpenWebStart team, and offer a suitable incentive (e.g. money to pay developers) to implement the feature for you. They also offer commercial versions of the software for paying customers.
Disclaimer: I have no connection with the OpenWebStart project, the company (Karakun) or the project sponsors. This is not a recommendation.
I had a similar problem in a past project. We needed to migrate from Webstart to another technology.
The first approach was to install IcedTea. It is directly bundled with the AdoptOpenJDK Project.
But as far as I understood the problem, Java wasn't meant to be installed on the Client side like this anymore and we didn't want problems with all of our customers.
Our solution was then building an own specific Executable, which connects to the server, ask for enviroment settings from the server side, and then download and extracts the JLink Java. So we could use the old technologies and just wrapped it in an Executable.
Last thing done then was redirecting to the download location of the Executable when calling the jnlp-URL.
Do you use maven?
I've resolved my similar problem with maven (I need to update an EAR).
My main app (the ear package) has a pom.xml with listed the dependencies and repositories.
The dependencies have the <version> tag with a range (documentation) as in this example
<version>[1.0.0,)</version>
That means : get version 1.0.0 or newer of the dependency. (You can put also an upper bound to the version, [1.0.0, 2.0.0) so if you develope a new version, it is not used in old app)
In the repository section I added my personal repository.
Now, in the remote machine I need only to rebuild my ear package with maven : the compiler download the newer version of my jar and put it together.
You need a system to check if there are newer dependencies version and warn the user to update the app and also lock its work (you can't work if you don't update). Maybe you need a little app to make users do the rebuild process easily. It's 1990's but a lot of desktop-app works in this way
PRO
This schema can be used in a lot of different projects.
CONTRO
You need to build the app in the remote machine, so the client must have a JDK and access to your repository (like artifactory);
You must write code in different jars and add them like dependencies in the main archive.
You must change JAR version each time and publish on the repository (this could be a good practice)
We are trying to automatically migrate traffic to the latest built version of our production branch of our app in google app engine. I can't find a good resource after about an hour of investigation on how to do this. Does anyone know if this is possible and where I can find resources on how to do this?
If you change the app/module version in your web.xml file at every build then you need to either assign the new version as the default version or migrate the traffic to the new version. AFAIK both of these actions can only be done manually, from the Developer Console's Versions Page.
But if you don't change the app/module version in your web.xml file then the updated code should automatically receive the same traffic as the previous code simply by deployment. At least in the standard GAE environment.
For Python applications it's possible to use appcfg.py set_default_version <app-directory> to set the default version to the one specified in app,yaml.
I'm assuming that appcfg.sh set_default_version <app-directory>, described in the documentation, does the same thing for Java applications.
I am just learning about android app development and have created my first app which is a relatively simple app with a link to a gallery of images and some text pages. I created this using the 1.5 platform as it seemed sensible to make it backwards compatible. I've been testing it on 3.0 and it comes up tiny on the screen and I have since learnt I need to use supports-screens and other related commands to allow variable screen support which from what i read is only available in 1.6 and above. As a result I need to change the app platform to 1.6 or above and my questions are as follows:
1) Am I able to just go to project properties and change the platform version tickbox to a newer one (in this case 1.6)? As I tried this with the project but the supports-screens tag still gives an error (which it doesn't when I create a brand new project)?
2) What version should I be creating it in these days for ideal backwards compatibility but able to use most desirable features? I understand 1.6 includes a lot of the newer functionality but according to http://developer.android.com/resources/dashboard/platform-versions.html only about 4% of people are using less than 2.1 so is it better to just code using 2.1 (assuming I want to target mobiles and tablets)?
Thanks so much for your help as ever,
Dave
Take a look at this. It explains how you can go about changing your AndroidManifest.xml to specify which version of the SDK to use. You may also need to update default.properties to point the target to the proper api value.
This really depends on what you want to do. If you require something from 2.1 or 3.0, then I think you need to go with that. But if you can get by using just 1.6 and still have all the functionality that you need/want, then I would definitely recommend using 1.6.
I want to make a java-based GUI tool that checks for the latest version of java available online,and compares it to the version currently installed
I already know how to check for the version currently installed on the machine
I don't know about the part where you check for the version available online
This web based Java Tester does what you want to do.
The author of the Java Tester keeps track of the latest version manually. I think you would have to do the same.
Have you looked into java web start for deploying your application? It will automatically perform version checks and perform the installation if a new version is needed.
http://java.sun.com/javase/technologies/desktop/javawebstart/index.jsp