I would like to use the OpenNTF Domino API but to me it is not clear which version I can use?
The version of the extension library on the Domino server is 9.0.1.v00_00_20151122-0905 (upgrade pack 1).
If you're using Domino 9.0.1 Feature Pack 8, then 4.0.0 is the way to go. Otherwise, 3.2.1 is the right one.
The plan is for 3.2.x to get critical fixes (which is what 3.2.1 itself was over 3.2.0) but otherwise remain as-is, while future development will happen on the 4.x+ Java 8 path.
The version of ODA will depend primarily on the Domino server version. It sounds like you're running Domino 8.5.3 and we've not specifically developed against that version. There was a lot of new functionality added in 9.0, specifically around NoteCollections, which is spread throughout the API. I did compile a version some years ago for 8.5.3, but it was never heavily tested or officially released. The server in question was upgraded to 9.0 before the project went live, so I'm not sure if I even have that version any more.
Version 4.0.0 is the first specifically compiled for 9.0.1 FP8 and will not work on previous versions. That's because it includes the new core Domino APIs (encryption, ID Vault etc) added with FP8. It's not currently compiled for Java 8, but work on that has already begun in the develop branch.
Version 3.2.1 is the recommended version for 9.0.1 up to FP7. It will still work on FP8, but only if there is no intention of using the new Domino APIs added with FP8. It will work with the base Extension Library as long as the Graph API REST functionality isn't required (not a regular requirement at this time), for which ExtLib 9.0.1_v00_17 is required. That's because additional hooks were added to the core Domino REST service functionality in ExtLib.
For any general discussion about ODA, there is an OpenNTF Domino API channel in the OpenNTF Slack. The OpenNTF Slack team can be joined from the main OpenNTF website home page.
Related
I have a library which uses the Apache Commons Text library.
A test suite for my library runs fine in JRE. However, when I use the library in an Android app and try to run it on an old device (running Android 4.4.4 aka KitKat), it crashes with a NoClassDefFoundError. The offending call seems to be StringSubstitutor.replace().
What is the issue here?
As per the release history, Apache Commons Text requires Java 8 since version 1.4 (released in mid-2018), which is not fully supported on older Android versions.
Specifically, one of the missing classes is java.util.Base64, which was introduced with Java 8. On Android it requires API 26 (Android 8) or higher.
If you need to support Android back to version 7, going back to Apache Commons Text version 1.3 works, as long as you are not relying on any of the features introduced in later versions. (StringSubstitutor.replace() was already available back then.)
If you decide to go down that route, bear in mind that you will be stuck with a library that (as of January 2023) is almost five years old, to support an OS that is at least six years old and for which security updates were discontinued more than three years ago.
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)
CA service virtualization can be configured by Java 8
As I checked with CA sv document I had seen its supports only limited Java versions.
Kindly help me to get info.
As far as running DevTest Server and DevTest Workstation are concerned, the Windows installer automatically includes a compatible JDK. As of the latest GA release (10.1.0), that would be Java 8. Most recent releases have been Java 8.
On Unix, you must provide your own JVM, and there are different settings for Oracle and IBM JVMs.
https://docops.ca.com/devtest-solutions/10-1/en/installing/preinstallation/system-requirements#SystemRequirements-SupplyingYourOwnJVM
That link is specific to 10.1.0 which requires Java 8. If you have an older version, please check the version specific documentation.
Note that OpenJRE is not supported at any version.
The JDK that DevTest runs on is only important if you're writing custom extensions. You don't want to build an extension with a Java version newer than what the server uses.
Scripts within a VSM, however, are another matter. The deprecated JavaScript step, I believe, only understands JDK 1.4. I'm not certain about the JSR-223 step but, if you select Beanshell, you're probably still limited to 1.4.
You're also limited to JDK 1.4 in Beanshell expressions like:
{{=new java.util.Date();}}
I have an existing project that I want to use ElasticSearch in.
The core ElasticSearch requires Java 8, which isn't a problem since it will run in a different JBoss than the existing project we want to integrate with.
However, the ElasticSearch client will be integrated in the existing JBoss, which runs Java 7. Does anyone know the Java version requirement for the client? We are unable to upgrade this Java version due to other circumstances.
According to documentation you can use 8 or 7, however 8 is preferred.
I am using Netty for a while now and could never solve this question. One can download four different versions. Three of them are actively getting developed.
3.x
4.0.x
4.1.x
5.x
As far as I understand 3.x is for JRE 1.5 and everything else for JREs greater than that. I am using 4.0.28 because it is the stable and recommended version. But what exactly is the difference or goal of the other versions?
I could not find any information about this on their website.
EDIT: I see close votes coming so I'd like to clarify: I'm not looking for someone who lists me all the differences in the code of the versions. But there has to be some sort of objective or purpose for the 4.1.x and 5.x versions.
3.x is deprecated. We maintain it because some users still use it widely.
4.0 is the current stable version. When in doubt, use this version.
4.1 is a backward compatible version of 4.0. It adds some cool new features like HTTP/2 and asynchronous DNS resolver. So, 4.1 is the version you might want to try when your application already runs on top of 4.0 and you wanna try the new features.
5.0 is a backward incompatible version. However, it's not like a rewrite we did for 4.0 vs 3.x. However, we did fix some API design flaws. You'll need to make some changes in your code to make your Netty 4 application run on Netty 5, but it's not like porting Netty 3 application to Netty 4 application. Eventually, 4.x will be deprecated and 5.0 will be a stable version.
It should be noticed that 5.0 had been revoked in Nov 2015, 4.1 is the newest stable version now.
If you want to know what are all new (and noteworthy changes) between these versions, you can visit these links:
3.x -> 4.0
4.0 -> 4.1
4.x -> 5.0