When updating a large java project from one LTS version (java 1.x) to the next (java 17), one may set the java compliance level of the compiler of the new javac compiler to match older versions of the standard, so that the compiled bytecode can be run with older java runtime environments that may be installed on the user devices. This advantage is plausible to me, but is there any downsides to doing this?
I have updated my java version in my project, but are unsure of the consequences of setting a lower compliance level for the compiler.
Related
I'm using Grails 5.1.4 for a number of projects now, and planning to move to 5.1.7 soon. I've been continuing to develop with Java 8 and deploy with Java 11, but I'm wondering whether there is a more recent version which I could be using without problems? The docs talk about the minimum JDK version required (8), but not the maximum usable one.
Im deploying an application in a docker container that requires CUDA 10. This is necessary to run some of the underlying pytorch functionality that the application uses.
However, the host server is running docker ce 17, Nvidia-docker v 1.0 with CUDA version 9, and I will not be able to upgrade the host.
I’m under the impression that I’m handcuffed to the v1 nvidia docker runtime and CUDA version available on the host.
Is there a way to run CUDA 10 on the container so I can leverage the functionality of this toolkit?
In the general case, any specific CUDA version will require a minimum GPU driver version. That is covered in places like here and here (table 1). So to use CUDA 9.0 you would need at least a GPU driver version that supports CUDA 9.0, such as a R384 driver. To use CUDA 10.0 you would need at least a GPU driver version that supports CUDA 10.0, such as a R410 driver.
The usage of containers doesn't fundamentally change this. If you want to use a container that has CUDA 10 code in it, your base machine needs a driver that supports CUDA 10.
NVIDIA did start publishing compatibility libraries that allow modifications to the above statements. These compatibility libraries are available but not installed by default with a CUDA toolkit install. These compatibility libraries only work in certain cases, and they have certain requirements to be usable. The compatibility libraries are documented here.
One of the specific requirements for use of these compatibility libraries is that the GPU(s) in use must be Tesla-brand GPUs. GeForce, Quadro, Jetson, and Titan family GPUs are not supported by these compatibility libraries.
Furthermore, the libraries only work with certain combination of CUDA toolkit versions, and GPU driver versions installed on the base machine. This "compatibility matrix" is documented here (Table 3). Only the specific combinations of CUDA toolkit versions with installed driver versions will be usable for compatibility. To pick one example, if you wish to use CUDA 10.0, and your base machine has a Tesla GPU with a R396 driver installed, there is no compatibility support. In the same setup, however, if you wish to use CUDA 10.1, there is compatibility support for that.
If you have satisfied the requirements for compatibility usage, then the remaining step would be to install the compatibility libraries (or build your container from a base container that has the compatibility libraries already installed).
For a package manager CUDA install method, the method to install the compatibility libraries is simple (example on Ubuntu, installing the CUDA 10.1 compatibility to match CUDA 10.1 toolkit install):
sudo apt-get install cuda-compat-10.1
Make sure to match the version to the CUDA toolkit version that you are using (that you installed with the package manager method, or that was already installed in your container).
This compatibility "path" only began in the CUDA 9.0 timeframe. Systems that are equipped with drivers that predate CUDA 9.0 will not be usable in any way for this compatibility path. There are also various functional limitations and restrictions, which are covered in the documentation.
When this "compatibility path" is correctly installed and in use, the overall system configuration can "appear" to be violating the rules indicated at the top of this answer. For example a CUDA 10.1 application could possibly be running on a machine that had only a R396 driver installed.
For the specific question in view here, OP eventually indicated that the base machine had a Quadro GPU, so this "compatibility path" does not apply, and the only way to run e.g. a CUDA 10.0 container would be if a CUDA 10.0-capable driver is installed in the base machine, e.g. R410 or later driver.
Suppose I have a C++ project, and I compile it with gcc and with clang. You can assume that the gcc compiled version runs in another linux machine. Will this imply (in normal circumstances) that the clang version will also run on the other linux machine?
Clang binraries are as portable as gcc binaries are, as long as you are linking to the same libraries and you aren't passing flags like -march=native to the compiler.
Clang has one huge advantage over gcc, it can deal with alsmost all libstdc++ versions,
while gcc is bound to its bundled version and often can't parse any older versions.
So the following often happens in production environments:
Install an LTS distro (Ubuntu 12.04 for example)
Keep gcc, glibc and libstdc++ untouched
Install a recent clang version for C++11, etc
Build the release binaries with clang
So (in my specific example) those binaries will work on all
distros with libstdc++ >= 4.6 and glibc >= 2.15.
This may be an interesting read for you.
If the program is a simple Hello world, it should work on the other machine when compiled through Clang.
But when the program is a real program with a lot a lines and compilation units, and calls to many external libs everything is possible depending on the program itself and the compilation options :
hardware requirements (memory) being different (mainly depends on compilation options)
use of different (versions of) libraries between gcc and clang
UB giving expected results in one and not in the other
different usages for implementation defined rules
use of gcc extensions not accepted by clang
For all of the above except 2 first, it should run on other machines it it runs on one
linux programs depend on their build environment. If your glibc version or kernel is different there will be lots of possibilities that the executable will not be able to run. You could use the interpreter language of llvm though, it compiles into bytecode which can be interpreted on various operating systems.
The answer is, well, depends.
The first hard requirement is the same CPU architecture. 64 Bit is not enough of a qualifier. If you compile of x64 you won't have much success running it on 64-Bit ARM.
The next big one is libraries. If you use any libraries in the program, the target system needs to have those libraries. This includes the kernel headers. So if you compile for e.g. a current kernel version, using the most cutting-edge features, then you will have no joy running that program on a very old version of Linux.
The last one is hardware dependencies. If you create a program that e.g. requires 4 GB of RAM and then try to run it on a small embedded device with 256 MB RAM, that won't work either.
To fit better to your changed question: From my experience there shouldn't be much of a difference in portability between Clang and gcc. Also googling didn't turn up anything, so it should basically work. But better always test stuff like that before you publish some binary in production.
If you could answer these questions or help me out a little with clarity, it will be greatly appreciated:
Is Java 7 just Java SE 7? and Java 6 is Java SE 6?
Is Java SE 7 also Java JDK 7? and also what is the JDK?
Does this mean that the Java JDK is the same as the java number (Java SE 7)?
what is java 1.5 and 1.6? and how does that correspond to the java number (Java SE...)?
Is Java's SDK the same as the JDK?
Yes, it can be confusing.
You didn't ask for it, but I'll start from here. The JVM is the Java Virtual Machine. It is a program that can read compiled Java code (the .class files, and the .jar files that are simply .zip files containing a bunch of .class files packaged together) and execute it. There are many JVMs, for example you need a JVM for Windows, one for Linux, one for OSX etc. but there are also many alternative JVMs, JVMs for embedded device etc. (many will disagree and say that the JVM is only one, and it's a specification. However, commonly a sysadmin will say "the JVM" to indicate the actual binary running on the server).
You didn't ask for the following either. The JRE is the Java Runtime Environment. It includes everything needed to run a Java application, that is the JVM itself, the standard library and a bunch of other files. The standard library is itself very important, because it contains a lot of useful things you'll use when developing Java applications. It contains all the stuff in java.* packages and some private stuff in com.sun, com.oracle packages.
Different versions of Java (1.0, 1.1, etc. all the way to 1.7, also known as Java 7) usually contain improvements to both the JVM and the standard library, so the two usually need to run together, and are packaged together in the JRE.
If you are running any Java program on your computer, you have a JRE installed.
The JDK is the Java Development Kit. It contains the JRE as well as a lot of other useful stuff for developing Java applications. That includes the compiler obviously (which is also contained in the JRE for some good reason, but you can ignore this fact now), the JAR utility to create .jar files, many tools for "decompiling" class files, inspect .jar files, repackage them, etc.
It also usually contains documentation for the standard library and also all the sources of the standard library, because they are useful for developers to read and inspect. If you want to seriously develop Java applications, you need the JDK.
When talking about JavaSE, JavaEE, JavaME etc. those are so called "editions". Basically, since the Java ecosystem is huge, Sun decided to offer Java in different editions:
JavaSE: is the standard edition, it is usually a good fit for client side software, normal applications, etc.
JavaME: is the mobile edition, it is what small games on old phones was made with, but it's basically a "smaller" version of Java suitable for very low capacity processors.
JavaEE: is the "enterprise edition". It is used to develop server side stuff, so it includes a lot of libraries used on server side.
Regarding numbering, they messed it up quite a bit. Actually, after Java 1.4 they created the JCP, to involve the community in the development of Java itself, and starting from Java 1.5 it is officially named "Java 5", despite most in the industry calling it 1.5. Also, Java 1.2 was Java 2, but everyone I know who was not working in Sun at that time always called it 1.2.
Is Java 7 just Java SE 7? and Java 6 is Java SE 6?
Yes.
There are a couple of Java "editions", namely Java SE, the "Standard Edition", Java EE, the "Enterprise Edition" and Java ME, the "micro edition".
"Java N" where N is some number refers to the SE. There are separate edition numbers for Java EE which is up to version 6 now. Java ME has its own versions as well - it is currently at version 3. Java ME is intended for mobile and small devices.
Java EE is a set of libraries and interfaces, such as EJB, JMS, JNDI, Servlets/JSPs that are built on top of the Java SE.
Is Java SE 7 also Java JDK 7? and also what is the JDK?
JDK = Java Development Kit. When you download Java you can either get the JRE (Java Runtime Environment) which only lets you run already compiled Java applications or you can get the JDK which allows you to compile and run Java apps. Java SE 7 refers to both the JDK and the JRE.
Does this mean that the java JDK is the same as the java number (Java SE 7)?
Yes.
what is java 1.5 and 1.6? and how does that correspond to the java number (Java SE...)?
Sun's numbering for Java changed midstream and is a bit confusing. They went from 1.0 to 1.1 then 1.2. Then they decided to call 1.2 "Java 2" and that label lasted until Java 1.4. Then Java 5 was called both 1.5 and 5.0 and that has continued - Java 7 is also Java 1.7, Java 6 is also Java 1.6, etc.
Is Java's SDK the same as the JDK?
Yes.
Answer 1: SE stands for Standard Edition. It is mostly like for every JRE nowadays to be in Standard Edition, so you can take Java 7 and Java SE 7 as the same thing.
Answer 2: JDK stands for Java Development Toolkit. Java SE is the technology, and JDK is the set of tools for developing in that technology.
Answer 3: Technically yes. Actually, you're most likely to see "JDK 1.6" alongside "Java 6", "JDK 1.7" alongside "Java 7" and so on.
Answer 4: Same as 3, I guess.
Answer 5: Java's Software Development Kit equals Java's Development Kit, so yes.
This diagram might help:
http://www.oracle.com/technetwork/java/javase/tech/index.html
SE = standard edition, standard version of java, often named just java X. The other version is EE, more oriented to components.
JDK = java development kit, this is a subset of the sdk that is what you use to develop java app, is a framework.
The version number has 1.7 is named java 7. And you can get both SE version or SDK of this version.
Anyway you can find the whole information at Wikipedia
I am currently learning F# and preparing to write my first program. I will be using Visual Studio 10 in Windows 7 to write the code, because the F# support for MonoDevelop is a few versions behind.
My normal day-to-day development environment is Mac Os X 10.7. I have Mono and MonoDevelop installed. After I finish writing my masterpiece, how do I package it for running on Os X? What DLLs do I need to send to other Windows users so that they can run my .exe file? How do they install those DLLs?
In the Java world (where I usually live), I just package my Java code with any dependencies into a monolithic UberJAR that I can send to anyone who has the appropriate version of Java (usually 6) and they can run my code by typing
java -jar MyUberJar.jar
I routinely write code in Scala and include the Scala library, along with any other dependencies.
Is there any easy way to do something similar for .NET, and specifically for F#?
One alternative is to use the --standalone flag to fsc which will statically compile all the DLL's you need into a single large EXE. The people you send it to will still need to install Mono, but there are no other dependencies.
I think this is what most people use:
http://wix.sourceforge.net/
I say "I think" because at work we've got a release team that builds the installer package for us.