I have got jar compiled in java 1.8 from maximo dir and on my machine i have java 1.7 installed do i need to update my machine java before i run this jar. I can not run it before knowing this since it will get recorded in some logs and will update some server side files.
This is more of a Java question than a Maximo question, but no, it will not. You will get an "Unsupported major.minor version 52.0" if you do. This is not because of any features issue, this is simply because the bytecode is tagged as being from Java 8 and so earlier JREs will not run it.
Now this assumes you actually compiled the class files using Java 8, which probably only happened if you have custom code in there. If you are just using the out-of-the-box Maximo classes, those came pre-compiled (in I don't recall which version of Java) and so all you might have done was to bundle them into a jar, or more likely into the Maximo ear (since you don't run the businessobjects.jar). In that case, it doesn't matter what version of Java you used to created the jar/ear, it will run on any version of Java that is the same as or higher than whatever version IBM used to compile the code into classes.
Related
I have read a lot about how bad this issue is and understand the options available to locate it within the code our company is producing and update servers that are using vulnerable versions.
What I am unable to find is if a particular server does not have Java installed i.e. if I log in as root and run java -version and get java: command not found is this server completely safe from this issue and so I can move on?
My initial instinct was: no Java - no issue. However, GitHub released an update for their Enterprise servers stating:
CRITICAL: A remote code execution vulnerability in the Log4j library, identified as CVE-2021-44228, affected all versions of GitHub Enterprise Server prior to 3.3.1. The Log4j library is used in an open-source service running on the GitHub Enterprise Server instance. This vulnerability was fixed in GitHub Enterprise Server versions 3.0.22, 3.1.14, 3.2.6, and 3.3.1. For more information, please see this post on the GitHub Blog.
And yet Java is not installed on their enterprise server.
I am guessing the offending service must be with Java running in a docker container. So I think I need to consider Java on the machine or Java running in a container.
Are there other hidden ways I have not considered in which this log4j process can be running?
log4j2 is a library that must be used by a running java process, to be vulnarable. But you are right, that checking if the java command is installed to the command line is not enough.
Here are two options (not meant to be complete), how your system could still be vulnerable without having the java command available on the command line.
Java could be downloaded into a directory without adding the java command or directory to the executable PATH. By using a .bash (or .bat) script a java process pointing to the downloaded java version could still be started. But when the directory is not added to the path, you will not find the java command enabled.
Java could be running inside of a docker container. the java command would only be available inside of your docker container but not visible from outside. I am not sure if an additional exploit would be required to break out of the container of if this is easily possible without extra effort.
I don't have a full answer yet but very definitely NO you are not safe even if Java is not installed, and Docker is not installed, and Java is not running in the process list, and Java is not in your yum/apt installed applications lists.
An obvious case I had not considered is when Java is added to an app as a JRE.
A Coverity platform server we have does not install Java but Java is running e.g. ps -ax | grep java
/home/coverity/cov_platform-2021.9.0/jre/bin/java -Djava.awt.headless=true -Djdk.tls......
Working out if a vulnerable version of Log4j is included in that JRE is much harder.
Further, just checking the process list is not enough either. In this case the process list contained java but Java may only be run when triggered by another process e.g. cron, nginx, etc
I am on a Linux Mint machine where I installed the latest version of Java (HotSpot VM 1.7.0_45) and using Gradle 1.8.
I also have Groovy installed, version 1.8.6, but I think that does not matter as Gradle has its own groovy-all.jar.
My problem is that I could not compile my Groovy project using gradle because the JavaFX classes do not seem to be in the classpath. The errors are like this:
unable to resolve class javafx.scene.Node
# line 3, column 1.
import javafx.scene.Node
I finally fixed this by adding the following horrible hard-coded path into my dependencies:
compile files( "/usr/lib/jvm/java-7-oracle/jre/lib/jfxrt.jar" )
Is there a better way to add JavaFX to Gradle's compilation classpath so that it is visible to all my projects without me having to add this to each one of them??
I have tried everything I could imagine:
added the jfxrt.jar to the standard JRE (I confirmed gradle is using my standard java to run) ext folder, so that I now can compile java classes with javac and run them with java (I know that in this version of Java the JavaFX jar should be already in the JDK's classpath, but I still couldn't RUN, as opposed to compile, my Java app before doing this).
also added a soft link to the same jar in the groovy classpath, so that I can do something like shown below from the groovy shell and it works:
import javafx.application.Application as A ; println A
This also works in the Groovy Console.
It only does not work in Gradle!
Thanks for any help.
Use the JavaFX Gradle Plugin.
The JavaFX Gradle Plugin should be able to work out where the JavaFX runtime is located without you having to perform manual, environment specific configuration.
For further information on JavaFX classpath resolution (not Gradle related), see:
Compile code using JavaFX 2.0 (using command line).
Also note, if you are using Oracle Java 8 or newer, JavaFX classes are now on the default runtime classpath for an Oracle Java implementation.
Incidentally, the build system for the entire JavaFX system is based on Gradle, so there is definitely no incompatibility between JavaFX and Gradle.
I've read several questions on this site and elsewhere that indicate that when Oracle JDK7 is installed, it should not be necessary to specify the classpath to jfxrt.jar when the JDK is installed correctly. Unfortunately, my installation does not seem to be correct, but I cannot figure out what is wrong.
I used the correct RPM for my Red Hat Enterprise Linux 6.2 Server and I'm able to build JavaFX apps in Eclipse when I added the jfxrt.jar to the External Jars. But when trying to compile and run from the command line, it does not find JavaFX classes unless I specify the -cp option to javac and java. The server was originally using openjdk-1.6, but I used alternatives to configure javac and java to point to the newly installed JDK. It looks like that is working fine, except for this issue.
I found that the same problem plagued me when trying to run the JavaFX Exporter. I was trying to export a project that runs fine in Eclipse. But it could not find the JavaFX classes when trying to run. And I haven't worked out how to tell the exporter where the jfxrt.jar file is located.
For reference, the jfxrt.jar is located at /usr/java/jdk1.7.0_21/jre/lib/jfxtr.jar on my system.
when Oracle JDK7 is installed, it should not be necessary to specify the classpath to jfxrt.jar when the JDK is installed correctly.
That is not true.
If you want to compile and run a JavaFX application in Java 7 (u21) and you are not using the JavaFX packaging tools, you need to add jfxrt.jar to your classpath.
See Compile code using JavaFX 2.0 (using command line) for samples of setting the JavaFX classpath for compiling (with javac) and running (with java) a JavaFX 2 application from the command line.
Some IDEs or IDE extensions are aware of this and will automatically add jfxrt.jar to your classpath (e.g. the e(fx)clipse plugin or the NetBeans JavaFX project type).
Some 3rd party tools such as the JavaFX Maven Plugin or the JavaFX Gradle Plugin also package JavaFX applications so that you don't need to add jfxrt.jar to your classpath.
For Eclipse development, use of the e(fx)clipse plugin is recommended, as it takes care of classpath issues (as well as providing other useful capabilities for JavaFX developers).
For Java 8, jfxrt.jar is on the default classpath, so you don't need to explicitly set your classpath to use JavaFX with tools like javac.exe or java.exe for that Java version.
OpenJdk7 does not include jfxrt.jar. Use Oracle Jdk7 instead will help.
I am new to groovy and I cannot understand, if it is possible to compile a groovy program, so it runs at all computers, were the JRE is installed.
The application I am developing has to run on any computer with JRE 1.5. Is it possible to start using groovy and maintain this flexibility? With JRE 1.6?
I have heard about the library groovy-all-VERSION.jar. Is this the one required library to be shipped with my application?
The answer is yes. In fact, all groovy code compiles down to Java classes that run on the JRE. All you need is JRE 1.4 or higher and the groovy-all-*.jar on the classpath of your application.
Since you are looking to support JRE 1.5 or higher, make sure your source compatibility is set on your compiler to this level.
There are a few options for compiling your groovy code. Groovyc (Ant Task), GMaven (Maven) and Gradle are all options.
Another option you have is to 'not' compile your groovy code. The groovy distribution only requires the JRE to be installed. You can ship your application as a set of scripts that can simply be run using the groovy install. It depends on how sensitive your source code is.
The short answer is yes. How you do this depends on your build system. I do all my development in eclipse, right click my project, select export, select runnable jar file, and all the required librarys are exported in the jar file. I can then run this file on a machine with out Groovy installed. I know build systems like Maven support Groovy but don't know the details on how they do it or how good there support is. According to this question Java 1.4 or above is fine. When looking at the "Setting up your Java environment" section of the initial tutorial it looks like you need Java 1.5 installed.
I need to build the jars for Hibernate 3.2.0 but I am having trouble finding directions. I am trying to follow along in the tutorial but it is wanting me to create classes and other files, is that really necessary just to compile the jars? I need to compile on a 64 bit Linux CentOS machine.
Also the directions in the tutorial are for 3.5 or 3.6 and they say to use maven but when I downloaded the source it came with a build.xml file, so am I supposed to use ant? and when I try ant it tells me I am missing antl/tools.
I am a brand new intern and I am just trying to figure this out so I can do what is asked of me. Any help would be greatly apprecited.
Thank You in advance.
For branch 3.2, you'll just need to run the run.sh (Linux) or run.bat (Windows). It should be enough. But keep in mind that 3.2 is an old branch. If you are developing a new application, consider using a newer version (3.6, for instance).
Binaries for Hibernate 3.2 can be downloaded from their SourceForge project page. Hibernate distributions typically contain hibernate3.jar, dependent jars, reference manuals and source files. The jars can be used on any JVM with version higher than 1.5 (or 1.4, I don't remember precisely) available on 64-bit CentOS.