I have a very simple code:
public static void main(String[] arg){
FileSystems.getDefault();
}
It runs good in Java7
But throws UnsupportedCharsetException: GBK in java8, full stack as below:
Exception in thread "main" java.lang.ExceptionInInitializerError
at sun.nio.fs.WindowsFileSystem.<init>(WindowsFileSystem.java:67)
at sun.nio.fs.WindowsFileSystemProvider.<init>(WindowsFileSystemProvider.java:53)
at sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:36)
at java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:108)
at java.nio.file.FileSystems$DefaultFileSystemHolder.access$000(FileSystems.java:89)
at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:98)
at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:96)
at java.security.AccessController.doPrivileged(Native Method)
at java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:96)
at java.nio.file.FileSystems$DefaultFileSystemHolder.<clinit>(FileSystems.java:90)
at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
at com.yy.ent.test.Test1.main(Test1.java:26)
Caused by: java.nio.charset.UnsupportedCharsetException: GBK
at java.nio.charset.Charset.forName(Charset.java:531)
at sun.nio.fs.Util.<clinit>(Util.java:41)
... 12 more
I am using windows7 in Chinese
And my java8 is:
Java(TM) SE Runtime Environment (build 1.8.0_66-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, mixed mode)
How can I solve this problem?
Either try changing "sun.jnu.encoding" property to something else, for example:
-Dsun.jnu.encoding=UTF-8
or check if your JVM contains "lib/charsets.jar" which is required for GBK support according to (http://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html)
It would seem that the JRE installer only installs "extended" character sets if the locale requires it: https://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html
Oracle's Java SE Development Kit 7 (Java SE 7) for all platforms (Solaris, Linux, and Microsoft Windows) and the Java SE Runtime Environment 7 (JRE 7) for Solaris and Linux support all encodings shown on this page. Oracle's JRE 7 for Microsoft Windows may be installed as a complete international version or as a European languages version. By default, the JRE 7 installer installs a European languages version if it recognizes that the host operating system only supports European languages. If the installer recognizes that any other language is needed, or if the user requests support for non-European languages in a customized installation, a complete international version is installed. The European languages version only supports the encodings shown in the following Basic Encoding Set table. The international version (which includes the lib/charsets.jar file) supports all encodings shown on this page.
This should also apply to Java 8. I read this to mean, that the JDK supports all charsets (includes lib/charsets.jar). The JRE tries to install a minimal environment and won't install extended characters sets, such as GBK, if the installer is being run by a user with a European locale.
Solution:
Try installing the JDK or set your user's region and language to Chinese (Simplified), then re-install the JRE.
Related
This question falls somewhere between Firebase Tools, MacOS and Java. Probably 75% Java, 20% Firebase Tools and 5% MacOS.
Starting with v10.5, firebase-tools started stating that 'Support for Java version <= 10 will be dropped soon in firebase-tools#11. Please upgrade to Java version 11 or above to continue using the emulators.'
I run macOS v11.6.5 on a Macbook Pro from mid-2014. When I go to Java's Downloads page, it recommends Java 'Version 8 Update 331'. Not Java 11.
Information on downloading Java 11 seems to be scarce. Oracle's page of certified configurations includes MacOS 11, but I can't find anywhere obvious where Java 11 can be readily downloaded.
A big part of the problem seems to be the terminology used. If I run java -version, I get:
java version "1.8.0_331"
Java(TM) SE Runtime Environment (build 1.8.0_331-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.331-b09, mixed mode)
Okay, I have build 1.8 of the Java Runtime Environment, aka the JRE if you are a Java enthusiast. That is apparently what is triggering the warning in Firebase Tools.
There is also a Java product out there called 'Java SE 11'. The product itself is ambiguous, but the checksums all say 'SDK'. (A Software Development Kit: a thing that enables developers to develop Java programs. The name doesn't imply a Runtime Environment: a thing that enables Java to run on an operating system.) There is an article out there which claims that, if you install Java SE 11 and run java -version, it will spit out java version "11.0.7". That will probably satisfy Firebase Tools.
But Oracle's release notes say: 'In Windows and macOS, installing the JDK in previous releases optionally installed a JRE. In JDK 11, this is no longer an option.' No longer an option... as in now you implicitly get JRE 11 with SDK 11? Or as in the SDK and JRE are now fully divorced, and the JRE must be ferreted out of its hiding like a wild beast?
UPDATE 6/5/22: Java's checksums page now says 'JDK', and I guess that is better than 'SDK' because it implies 'Java Development Kit', which this Wikipedia article claims to include both a JRE ('java') and SDK (most of the other files).
To install Java SE:
Go here.
Scroll down to find your product. I chose Java SE 11. (Oracle will probably list later versions as they are made available.)
Choose your operating system. I chose MacOS.
Choose your file set. I chose the DMG installer.
Download your chosen file set.
5. Do whatever is required by your platform to install Java SE using the downloaded file set from #5.
After installing Java SE 11, java -version now says "11.0.14" and Firebase Tools is now satisfied. My best guess is that JRE 11 was implicitly downloaded, and that developers need to start ignoring the main Download page used by everyone else. (Why didn't the main Download page recommend Java 11 from the start?) Hopefully someone will see this question and clarify whether in the future, the 'Java SE' product implicitly includes both the JRE and SDK, and that the numbering system will always encompass both. In other words, hopefully when someone says we need 'Java 11', it means that we need to download SE 11, containing JRE 11 and SDK 11.
This link has a JDK installer that solved my problem today. I needed to close and reopen all my VScode windows to get it to work.
https://www.oracle.com/java/technologies/downloads/
With latest versions this error appears: !! emulators: firebase-tools no longer supports Java version before 11. Please upgrade to Java version 11 or above to continue using the emulators.
You can download Java SE Development Kit 18 from this link. Just choose your operating system, download and install the file. When installation is complete you need to restart you terminal and voila it works now:
firebase emulators:start
But Oracle's release notes say: 'In Windows and macOS, installing the JDK in previous releases optionally installed a JRE. In JDK 11, this is no longer an option.' No longer an option... as in now you implicitly get JRE 11 with SDK 11? Or as in the SDK and JRE are now fully divorced, and the JRE must be ferreted out of its hiding like a wild beast?
With Java 8 and earlier, the end user of a Java application was responsible for providing a Java runtime environment for the application to run on. This is what the JRE was for. The user would have to install this runtime environment on their system in order to run Java applications. This is also why the https://www.java.com/en/download/ page recommends Java 8 (the JRE), which was the last version of Java where an end-user should concern themselves with installing a runtime environment.
Starting from Java 9, it is now the application distrubutor's responsibility to provide a Java runtime that can run the application. So, there are no more JREs.
The application developer should use jlink, which is a tool included in the SDK, to create a 'runtime image' (essentially a bespoke JRE to run a single application), that can be used to run the application, and bundle that runtime image with the application. The jpackage tool can also be used to create application images (including a runtime image), as well as installers.
Following the posts here and here, I had to have two different versions of Java/OpenJDK installed
brew install java
brew cask install java
now I have openjdk 13.0.2
openjdk 13.0.2 2020-01-14
OpenJDK Runtime Environment (build 13.0.2+8)
OpenJDK 64-Bit Server VM (build 13.0.2+8, mixed mode, sharing)
in two different locations
/usr/local/opt/openjdk/bin
/usr/local/opt/openjdk/libexec/openjdk.jdk/Contents/Home/bin/
and openjdk 14
openjdk 14 2020-03-17
OpenJDK Runtime Environment (build 14+36-1461)
OpenJDK 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)
also in two different locations
/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/
/Library/Java/JavaVirtualMachines/openjdk-14.jdk/Contents/Home/bin/
so my questions are
why there are two different locations for each installation of OpenJDK?
how to find out if there are more installations of JDK on my system? Ran sudo find / -name java which nuked my terminal (see log here).
How to know how those different versions of java are installed?
I understand that JDK is Java SDK and JRE (Java Runtime Environment) is an oracle thing which I think OpenJDK doesn't have (?) but looking at OpenJDK download page what are "JMC" and "Java SE"?!
what you are seeing is the way that a JDK works on macOS. but basically what you should know that we have two entities called JDK and JRE. JDK is a tool for java developers to compile and run their applications. JRE is a runtime for clients to run java applications. JDK is containing a JRE, so you don't need to install JRE when you have JDK.
A JDK is a folder that you can have based on your OS and copy paste it every where that you need and just add the bin folder to your PATH . so you might have lot of JDK folders but only the one that is added to your PATH is your current working JDK, and they are not working at the same time in one environment but you can have multiple Java versions on different user profiles.
what you have is one installation with its meta data and links all over the macOS.
you can have multiple JDK folders all around your hard disk but only one of them at the current time is working and that would be the one that you have in the user profile.
I don't know a way to find out how they are installed. you can query the tools like brew in your os to find out that if they installed any java or not but not from JDK itself.
JMC is java mission control which is a monitoring application for java application. JRE, as I said, is a runtime for running the applications and OpenJDK also includes a runtime in itself. JavaSE is the specification of Java for Standard edition since we have other editions too.
I need to install open JDK in my Windows 64-bit os. I have used ORACLE open JDK and downloaded from the below link: https://jdk.java.net/8/
While downloading I have selected Accept License Agreement and installed.
But, after the installation when I tried checking the version using command java -version it's showing like regular JDK.
Can anyone help me to get where I went wrong? Or is there any better vendor to install open JDK in windows. Thanks.
Amazon offers an open jdk for Windows (and other OS), but just for Java 8, 11 and 16.
You can download it from here: https://aws.amazon.com/es/corretto/
After installing it and running the java -version command, you will see something like this:
>java -version
openjdk version "1.8.0_242"
OpenJDK Runtime Environment Corretto-8.242.08.1 (build 1.8.0_242-b08)
OpenJDK 64-Bit Server VM Corretto-8.242.08.1 (build 25.242-b08, mixed mode)
You need to set your java version in environment of you machine and target your JDK8 bin folder, or any JDK that you want to have at your disposal when you run java -version.
The best way to do this is to use the builds from adoptopenjdk. They're very high quality and come in multiple variants for Windows ranging from zip files to MSI installers. Dead simple to install JDK 8, 11 or 15.
But, after the installation when I tried checking the version using command java -version it's showing like regular JDK.
This is because JAVA_HOME is pointing to your old JDK. You need to go to Control Panel and change the Environment Variables. Just do a search on Windows 10 for "Environment Variables" to easily find that configuration panel.
Azul Systems provides builds of OpenJDK and relative installers, for all OSes and JDK versions.
It also provides builds of the JDK with OpenJFX included.
The installers bind JAR files to be executed by Java on Windows.
Download from azul.com website
I know this is old but should anyone run across this in search of OpenJDK 8 go here
https://developers.redhat.com/products/openjdk/download
I am getting below result, Does it mean I am having JDK 1.7.0_45 and JRE is 1.42 ? Please advise.
$ javac -version
Eclipse Java Compiler v_677_R32x, 3.2.1 release, Copyright IBM Corp 2000, 2006. All rights reserved.
$ java -version
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
$ alternatives --config java
There is 1 program that provides 'java'.
Selection Command
-----------------------------------------------
*+ 1 **/usr/lib/jvm/jre-1.4.2-gcj/bin/java**
Enter to keep the current selection[+], or type selection number:
It would appear that you have two versions of Java installed:
The Java on your PATH is Java 1.7.0. I think it is an Oracle build rather than a build from your Linux system's package repository.
The Java configured using alternatives looks like a GCJ Java that is compatible with Java 1.4.2. It was probably installed from your package repository. IMO, it is inadvisable to use this from a technical standpoint. In fact, I would recommend uninstalling it.
Actually I am getting "Unsupported major.minor version 51.0" error after uploading a external jar file to Informatica powercenter Java transformation.
That implies that Informatica is using the Java 1.4.2 installation.
Now, the version of Java that an application uses will depend on what version of Java the application's launcher / launch script is using. That could depend on a number of things:
If the launcher uses an absolute path for the java command, then that is what will use.
If the launcher uses a simple name (e.g. java) then the version used will depend on the launcher's $PATH. This is probably what is happening ... and the $PATH used is different from your shell's $PATH.
So what is the solution?
You could add the Oracle Java install to the alternatives system. See man alternatives or Google for instructions using "java oracle alternatives install"
You could tweak the $PATH used by the application's launcher.
Depending on your Linux distro, you could install an OpenJDK 1.7.0 JDK or JRE from the package repos. That will (should) add the new installed Java to the alternatives database, so that you can select it instead of the old GCJ 1.4.2 installation.
I am just learning Java. I compiled and created a jar file for a simple quiz game with a light GUI. All done from Ubuntu 14.04 terminal manually with 'javac -d ...' and 'jar -xvmf...'
Here are my version details:
java version "1.8.0_11"
Java(TM) SE Runtime Environment (build 1.8.0_11-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode)
javac 1.8.0_11
I followed a tutorial dealing with Java SE 5.0 for creating it, so I guess no new features from '1.8' were used. It compiled and it worked fine for me. When my friend who uses OpenJDK (latest version available) in Ubuntu 14.04 tried running it he received a lot of errors including Unsupported major minor ... 52....
I don't have the full verbose output from the terminal. Is there any way to avoid this and why is this happening though I didn't use use any new features specific to the latest version?
I thought Java was supposed to be "Write Once ,Run Everywhere", and compatibility issues with even the simplest of things with just a slightly little older version involved makes me rethink things!
The version of the byte code doesn't depend on whether you use Java 8 new features or not. It simply depends on which compiler you use. A Java 8 compiler will by default produce Java 8 bytecode, unless you use the option -target to specify an earlier version.
Side note: your friend is not using the latest version of OpenJDK (which is Java 8), otherwise, he would not get this exception.