We Keep Coding

Java JDK 16.0.1 installer crashing without even starting the wizard

I'm trying to install Java JDK 16.0.1. When I double-click the install file in the Downloads folder, it prompts me to allow changes, then does absolutely nothing.
I did some digging around in my %appdata% folder to look for crash reports/logs. It turns out every time I double-click the install file, it crashes with:
Exception Code: 0xC0000005
Exception Information: The thread tried to read from or write to a virtual address for which it does not have the appropriate access.
I do have Java Runtime Environment 1.8.0_291 installed, but that shouldn't prohibit the JDK installer, should it?
I also do have Java Runtime Environment 1.8.0_241 installed, and can't seem to be able to uninstall it. Could this be the problem? When trying to uninstall it, it looks for jre 1.8.0_241patch.msi, but can't find it. Regardless, this first issue shouldn't be a result of this old JRE install, correct?

I found this on the OpenJDK bug system:
https://bugs.openjdk.java.net/browse/JDK-8202316
for that user it was happening with the JDK 8 installer but the behavior sounds identical to the issue that you're having. In that post the original poster says "Problem solved. JDK 8u162 installer didn't remove all registry values of 8u152."
Now, I don't know why that's an issue; multiple JDKs should be able to peacefully coexist, but it might be worth a shot in your case before going to the length of doing a fresh reinstall of windows:
uninstall the JRE 8 version (your 1.8.0... version)
use tool or manually clean up any leftover java registry keys if necessary
reboot PC
try JDK 16 installer again
If you truly just have a JRE of version 8 and not a full-blown JDK, you could try using the java uninstall tool here:
https://www.java.com/en/download/help/uninstall_java.html
Also, I did find this old page about manually tracking down java registry entries (from 7.0 and older):
https://java.com/en/download/help/manual_regedit.html
Well, hope this helps. Be sure to let us know whether you get it solved, I'm curious to know. Thanks!

Eclipse aarch64 and OpenJDK (ARM)

I'm trying out the Eclipse 4.20 builds available as Mac OSX (64 bit version for Arm64/AArch64) running under macOS 11 on Apple Silicon. This version doesn't seem to come with a jdk, so I've assumed I need to handle that myself. I installed 16.0.1-librca from Bellsoft with SDKman (Rosetta2 mode false).
I edited the info.plist file of Eclipse like this:
<key>Eclipse</key>
<array>
<string>-vm</string>
<string>~/.sdkman/candidates/java/16.0.1-librca/bin/java</string>
…(Other stuff here)
</array>
and Eclipse does indeed startup, but crashes right away. A while after this macOS claims I don't have the permissions to start the app. Results are identical with the Zulu AArch64.
I typically get
"Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes:
KERN_INVALID_ADDRESS at 0x000000000000000c"
and
"Application Specific Information: abort() called"
in libjvm.dylib.
This with some variations depending on the setup used.
Assuming these releases are supposed to work in macOS 11 on Apple Silicon, then it would seem likely this should be possible to get working. Or have I misunderstood the meaning of aarch64 here? Are these perhaps just versions for jdk developers? I looked over the "Target Environments" for Eclipse and feel unsure what other uses a version labelled as "Mac…for Arm64/AArch64" would have here.
libexec doesn't see the SDKman installed version. When I run java --version in the terminal it does show "openjdk 16.0.1 2021-04-20" and not my main Oracle JDK.
Any suggestions on how to set this up?

I have yet to investigate the actual reason, but after I had installed the "OpenJDK 64-Bit Server VM Zulu (build 11.0.11+9-LT)" and I had started to contemplate overriding eclipse.ini in order to avoid macOS preventing me from starting a modified app (recurrent issue. Note I didn't attempt overriding) I started Eclipse from the command line with the open command and Eclipse starts right up using
-vm
/Users/[user name]/.sdkman/candidates/java/11.0.11-zulu/zulu-11.jdk/Contents/Home/bin/`
At least this starts Eclipse. Double clicking the app renders the same results as before.
A theory is that since the open command runs in the terminal and java --version verifies the zulu jdk set there by sdkman, this is why. However JAVA_HOME is empty and the /usr/libexec/java_home -V command only lists the Oracle JDK.
Thank you #greg-449 and #howlger. I don't think I'd found this without your helpful suggestions.
To not have to be in the terminal just for starting Eclipse I made this little Applescript that opens Terminal (Just executing the command without it involved wouldn't supply the proper JVM):
on run {input, parameters}
tell application "Terminal"
activate
do script "open /Applications/Eclipse.app"
delay 1
close front window
end tell
Save that as an app and start with this instead of Eclipse.
If I could find out how the proper JVM in Terminal is supplied to Eclipse with the open command, maybe this can be used for modifying how Eclipse starts.

How to resolve "unable to find package java.lang in classpath or bootclasspath" in Dr Java?

I am new to Java. I am taking a University beginners Java course. I'm running my first hello world code and am getting an error message. I have installed the latest Dr. Java stable version and have installed Java SE 12 JDK.
I have uninstalled and reinstalled Dr. Java several times and still getting error message. I have also recompiled it to and still the error message is there.
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World");
}
}
I expected the code output to say, "Hello World" under the interactions pane but it isn't and instead there is an error message that says, "Current document is out of sync with the Interactions Pane and should be recompiled!".
Also, under the console pane I receive the following message:
Compiler is using classPath = '[C:\Users\Admin,
C:\Users\Admin\Downloads\drjava-beta-20190813-220051.jar]';
bootClassPath = 'null' Fatal Error: Unable to find package java.lang
in classpath or bootclasspath

Realizing that the OP solved his problem by version of JDK, I ran across this question after experiencing the same symptoms he describes. With that, it seems possibly appropriate to post a solution for the symptoms even though the problem ended up not being quite "identical" to the OP's situation:
I had the same problem with compilation not working. In my case, I am using a Linux system that has both OpenJDK and a manually installed Oracle JDK (extracted from a tarball obtained from java.com), along with some other JRE environments in various places. I "installed" the DrJava Version : drjava-20190813-220051 jar file and ran it from the command-line. I then clicked [ Manual Download ] when it asked about installing updates (drjava-beta-2019-220051).
DrJava reported that my compiler was JDK 8.0_222. Note, I don't know where that compiler came from. As far as I know, I didn't have that version installed. My OpenJDK was:
$ /bin/java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
I typed in a simple "Hello World" program, and every attempt to compile produced:
Compiler Output:
"Compilation completed."
This is a bug, because in fact compilation apparently did not complete.
Clicking Run produced:
Interactions
Welcome to DrJava. Working directory is /home/krb/Projects/Software/java
Current document is out of sync with the Interactions Pane and should be recompiled!
>
Restarting DrJava, saving, clicking Reset, etc., would not clear the problem.
In any event, at some point I noticed the Console tab was full of messages like:
Console
Compiler is using classPath = '[/home/krb/Projects/Software/java, /home/apps/drjava/drjava-beta-20190813-220051.jar]'; bootClassPath = 'null'
Fatal Error: Unable to find package java.lang in classpath or bootclasspath
At this point, I tried various things, but I focused on pointing DrJava to an Oracle Java JDK I had installed a few days ago. Everything I did was in Edit | Preferences ... | Resource Locations, though I beat around in there a while. All of the settings were "blank" before I started. Anyway, I eventually had some success after I'd set:
Web Browser
/usr/lib64/firefox/firefox
Web Browser Command
Tools.jar Location
/home/raid/apps/oracle/jdk-1.8.0_251/jre/lib/tools.jar
Display All Compiler Version [ ]
Extra Classpath
/home/raid/apps/oracle/jdk1.8.0_251/jre/lib
/home/raid/apps/oracle/jdk1.8.0_251/lib
NOTE: Your PATHs will NOT be the same as mine! You need to use the
actual paths on your system. In my case I searched for "rt.jar" and
"tools.jar" that were obviously in folders related to an installed
JDK.
At this point I decided to try to figure out the minimum required to get it working. After a lot of fiddling around, I found it is sufficient just to set Preferences | Resource Locations | Tools.jar Location, but with with one MAJOR caveat. You must BROWSE to the file using that dialog. YOU CANNOT JUST PASTE IN THE PATH! If you just paste in the path, it can look like it is set correctly, but the compiler will continue to not work. This was how I got the oracle jdk compiler to work.
Next, I set about to see if I could get OpenJDK to work. I searched my entire system for another tools.jar that belonged to OpenJDK, and did not find one. Then I realized I did not have the DEVEL OpenJDK package installed (on Mageia Linux 7).
java-1.8.0-openjdk-headless-1.8.0.252-1.b09.1.mga7
java-1.8.0-openjdk-1.8.0.252-1.b09.1.mga7
I installed:
java-1.8.0-openjdk-devel-1.8.0.252-1.b09.1.mga7
Now, even after resetting defaults, DrJava no longer says it is using JDK 8.0_222, but rather JDK 8.0-openjdk-1.8.0.252-1.b09.1.mga7.x86_64-OpenJDK, and everything works fine with NO customization to preferences!
I don't know where the heck JDK 8.0_222 came from. There's nothing on my system with that version. I rather suppose it is some internal thing in DrJava. I think the takeaways are:
If DrJava says its using JDK 8.0_222, it probably is not going to work!
Make sure you actually have a tools.jar installed if your system might split up the OpenJDK installation.
Point Tools.jar Location to an existing tools.jar file where the JDK you are using is installed, and making sure to browse to it (not just paste in a path).
I know what I saw was with Linux and a .jar install of DrJava, and this might not be what you have, but perhaps the information will be helpful in offering you things to look at and try.

As the answers above state, DrJava is not compatible with newer versions of Java than Java 8. Most of the DrJava codebase was written long before the open source version of Java was viable. The Sun Microsystems and Oracle javac compilers are proprietary and cannot be distributed with open source apps like DrJava. So DrJava searches for tools.jar (the library file containing the compiler in Java JDK distributions prior to Java 9) in common locations on Windows, Mac OS X, and Linux to find a compiler (more accurately, what were common locations in 2007). If you are running DrJava from a Java 8 JDK, it almost always finds it (although it appears to be failing for some installations Amazon Corretto 8). The most recent available build (March 3, 2020) of DrJava at www.cs.rice.edu/~javaplt/drjavarice may do a better job. I know it includes a later version the open source Java 8 compiler (JDK 8.0_242) and that it also finds the compiler (JDK 8.0_265) in the Corretto 8 distribution that I am using on Windows 10. The mysterious version of the open source JDK compiler reported above is being retrieved from the drjava.jar file itself. Now that the open source JDK includes a reliable compiler (which I suspect is nearly identical to the Oracle Java 8 SE compiler), the drjava.jar file includes a recent build of the open source Java 8 compiler.

Your solution helped me troubleshoot a problem with DrJava not recognizing the Amazon Carretta JDK on a Mac.
The fix is to open DrJava and go to Edit -> Preferences -> Resource Locations. From the Tools.jar Location box you must use the three dots at the end of that box to navigate to the tools.jar file on your Mac, which is probably in /Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home/lib/tools.jar.

Netbeans 10 not installing

I'm having issues trying to install NetBean 10 (incubating) on a laptop. I've checked that Java is installed, as well as JDK (jdk1.8.0_191). I've checked that Java is installed correctly by going to the command line and typing "java -version" and it correctly responds
java version "1.8.0_191"
Java(TM)SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
I've checked that the environment varible "JAVA_HOME" is correct (echo %JAVA_HOME%), and that the Path variable is correct.
However when I try installing NetBeans (from the C:\netbeans10\bin\netbeans64.exe) (yes, also double checked the laptop is correctly running Win10 64bit, it is) a logo for netbeans briefly appears, goes away after 1 sec, and nothing else happens.
I've tried downloading a fresh NetBeans, reinstalling Java, rebooting the system, disabled anti-virus, disabled firewall, tried from safe boot, however it just does not install.
Anyone have any ideas on what step I'm missing so that I can get this installed?
Thanks in advance.

A possible caused of your problem is that NetBeans is trying to run using a version of Java that does not exist on your machine. To eliminate this as a possibility:
Locate the file netbeans.conf. It will be in the etc directory within the NetBeans installation directory.
Open the file in any text editor. It is just a properties file containing name/value pairs,
Locate the line containing the text netbeans_jdkhome.
If the line is commented out delete the leading # character.
Set the value to the actual path to your JDK. For example, on my machine it would be: netbeans_jdkhome="C:\Java\jdk1.8.0_191".
Save the file and (re)start NetBeans. NetBeans will now use the JDK specified by the netbeans_jdkhome property.
If NetBeans still doesn't start then update your question with the content of the NetBeans log. See NetBeans - where to find the IDE log? for details on locating that file.
One other point: although you can run NetBeans 10.0 using JDK 8, I can't think of any good reason to do that. Most users will probably download and install JDK 11, and use that instead.

Ecilpse Oxygen.3a Java IDE cannot add window GUI via window builder error opening wizard

I try to use the Eclipse Oxygen v4.7.3a (Oxygen) Java IDE.
I try to use window builder to build a GUI application with Java, but when I try to add the window I have an error message.
I tried to google it, but I cannot even know what that message needs from me.
It says:
problem opening wizard
The selected wizard could not be started.
Plug-in org.eclipse.wb.swing was unable to load class org.eclipse.wb.internal.swing.wizards.application.NewSwingApplicationWizard.
An error occurred while automatically activating bundle org.eclipse.wb.core.java (528).
My java -version output:
OpenJDK version "10" 2018-03-20
OpenJDK Runtime Environment (build 10+46-Ubuntu-5ubuntu1)
OpenJDK 64-Bit Server VM (build 10+46-Ubuntu-5ubuntu1, mixed mode)

I had exactly the same error occur in Eclipse Oxygen.3a on my Mac with Java JDK 10 installed. There is code in WindowBuilder 1.9 that uses a Java feature that was either altered or dropped in Java 10. I was able to resolve the problem by making two changes (they assume that a Java 9 JDK is available on your system; if not, you must install it):
change the Java VM for Eclipse to one in a Java 9 JDK (using the -vm setting in eclipse.ini; see this link for a good post on how to do that)
change the JRE for the project to a Java 9 JRE
The first change is the more important one since Window Builder is a development aid running as part of Eclipse.
I made the project JRE change for my own sanity so I didn't have a mix of Java versions. You may be able to skip that change (I didn't try it).
I still have Java 10 as the default for the system, so you don't have to completely fall back to Java 9 if you install both JDKs. It may take some tweaking to get both Java 9 and 10 installed and have the one you prefer working as the system default.