Develop Reference

HBASE error : Unrecognized VM option 'UseConcMarkSweepGC'

I have jdk-15.0.1 on my laptop, and have installed HBASE (hbase-2.2.6 version).
I followed every steps to install HBASE on this link : https://www.learntospark.com/2020/08/setup-hbase-in-windows.html
The problem is that when I try running HBASE in my command line using :
start-hbase.cmd
I get the following error message :
Unrecognized VM option 'UseConcMarkSweepGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
ERROR: Could not determine the startup mode.
As a beginner, I tried scouring around for information, but nothing that matches my problem.
I would be glad for any help you could give me.

CMS garbage collector is removed in JDK 15, thus UseConcMarkSweepGC too is removed.
JEP 363: Remove the Concurrent Mark Sweep GC
So, either you should switch back to java 8 or 11, or you should modify below line:
set HBASE_OPTS="-XX:+UseConcMarkSweepGC" "-Djava.net.preferIPv4Stack=true"
with
set HBASE_OPTS="-Djava.net.preferIPv4Stack=true"

Cannot run Eclipse: bad constant type in NatureManager clas

Today I cannot run Eclipse, due to this error:
java.lang.ClassFormatError: Signature index 405 in LocalVariableTable has bad constant type in class file org/eclipse/core/internal/resources/NatureManager
I am not sure of any changes in my system since last time I could run Eclipse (last week).
I am pointing to the same Java 8 VM (-vm argument in eclipse.ini), and there were no updates in the Eclipse installation neither.
The affected JARs should is org.eclipse.core.resources_3.11.1.v20161107-2032.jar.
I am a bit clueless now: any suggestion?

Cassandra start error with ThreadPriorityPolicy=42

When I am trying to start Cassandra it shows me error like this I already did changes in the conf file also in env.sh, the file also.
No options of similar type error is working for this.
intx ThreadPriorityPolicy=42 is outside the allowed range [ 0 ... 1 ]
Improperly specified VM option 'ThreadPriorityPolicy=42'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Other Information
java version "9.0.4"
Java(TM) SE Runtime Environment (build 9.0.4+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)

This is a known issue of Cassandra - CASSANDRA-13107.
Before Java 9 JVM accepted any integer value for ThreadPriorityPolicy, while 0 and 1 were the only valid values.
ThreadPriorityPolicy=1 allows to raise thread priorities, but only if the process starts with root privileges. When ThreadPriorityPolicy=1, JVM explicitly checks that euid=0:
static int prio_init() {
if (ThreadPriorityPolicy == 1) {
// Only root can raise thread priority. Don't allow ThreadPriorityPolicy=1
// if effective uid is not root. Perhaps, a more elegant way of doing
// this is to test CAP_SYS_NICE capability, but that will require libcap.so
if (geteuid() != 0) {
if (!FLAG_IS_DEFAULT(ThreadPriorityPolicy)) {
warning("-XX:ThreadPriorityPolicy requires root privilege on Linux");
}
ThreadPriorityPolicy = 0;
}
}
Note a bug (or backdoor) in the above code: if you set ThreadPriorityPolicy to something other than 0 or 1, euid check will be skipped, but the application will be still allowed to use priorities above normal. Cassandra uses this backdoor.
As a result of JEP 245 JDK 9 improved command line argument validation, and therefore ThreadPriorityPolicy does not accept values other than 0 or 1 anymore.
How to fix
Edit %CASSANDRA_HOME%/conf/jvm.options file:
If you run Cassandra under root on Linux,
replace -XX:ThreadPriorityPolicy=42 with -XX:ThreadPriorityPolicy=1
Otherwise remove -XX:ThreadPriorityPolicy=42 line altogether.

As the exception message is already telling you, the ThreadPriorityPolicy must be between 0 and 1:
intx ThreadPriorityPolicy=42 is outside the allowed range [ 0 ... 1 ]
Did you use Gateling? Than this might help you: https://github.com/gatling/gatling/issues/2950 (issue is resolved since Gatling 2.2).
It might be also worth checking if on your OS this setting makes sense at all. The meaning of this setting is somewhat like this:
0 : Normal. VM chooses priorities that are appropriate for normal applications. On Solaris NORM_PRIORITY and above are mapped to normal native priority. Java priorities below NORM_PRIORITY" map to lower native priority values. On Windows applications" are allowed to use higher native priorities. However, with ThreadPriorityPolicy=0, VM will not use the highest possible" native priority, THREAD_PRIORITY_TIME_CRITICAL, as it may interfere with system threads. On Linux thread priorities are ignored because the OS does not support static priority in SCHED_OTHER scheduling class which is the only choice for" non-root, non-realtime applications. 1 : Aggressive. Java thread priorities map over to the entire range of native thread priorities. Higher Java thread priorities map to higher native thread priorities. This policy should be used with care, as sometimes it can cause performance degradation in the application and/or the entire system. On Linux this policy requires root privilege.

If there is no $CASSANDRA_HOME setup as it was not a source install, then it can likely be under /usr/local/etc/cassandra
janani#janani-C02Z78CMLVDQ fievel % find / -name jvm.options
find: /usr/sbin/authserver: Permission denied
/usr/local/etc/cassandra/jvm.options
In my local, it was not under cassandra install path.
janani#janani-C02Z78CMLVDQ fievel % brew --prefix cassandra
/usr/local/opt/cassandra
janani#janani-C02Z78CMLVDQ fievel % ls /usr/local/opt/cassandra
CHANGES.txt LICENSE.txt NOTICE.txt homebrew.mxcl.cassandra.plist share
INSTALL_RECEIPT.json NEWS.txt bin libexec
janani#janani-C02Z78CMLVDQ fievel % find /usr/local/opt/cassandra -name jvm.options
janani#janani-C02Z78CMLVDQ fievel %

Removing package with Chef

Can you please tell me, is this possible to remove Java JDK package with Chef, with windows_package, or I have to execute command to silent uninstall? Much better would be the first option.
I've tried this way:
windows_package node['name']['JDK1.6'] do
action :remove
end
and even added option installer_type :custom, still got this error:
FATAL: Mixlib::ShellOut::ShellCommandFailed: windows_package[Java(TM) SE Development Kit 6 Update 35] (line 4) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0, 42, 127], but received '1603'
---- Begin output of MsiExec.exe /I{32A3A4F4-B792-11D6-A78A-00B0D0160350} /qn ----
STDOUT:
STDERR:
---- End output of MsiExec.exe /I{32A3A4F4-B792-11D6-A78A-00B0D0160350} /qn ----
Ran MsiExec.exe /I{32A3A4F4-B792-11D6-A78A-00B0D0160350} /qn returned 1603
Well, I am out of ideas. On official Opscode site I've found this information:
:remove: remove a package. The remove action is completely hit or miss as many application uninstallers do not support a full silent/quiet mode.
But as far as I know, JDK supports silent uninstall.
So - how should I do this in order to properly uninstall packages? Is this even possible?
Many thanks for every help.
Specification:
Chef 12.4.1
Windows 7
Java JDK in versions: 6u35, 7u79, 8u45
If you need additional information, feel free to ask.

Well, I've ended up with my own implementation. For those, who would need this, too:
# variable 'code' is for JDK version code from registry.
# Uninstall comand: MsiExec.exe /quiet /X[CODE]
# Codes are in regkey HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. Be aware to check key for JDK, not JRE!
remove_command = "MsiExec.exe /quiet /X#{code}"
execute "Remove JDK from system" do
command remove_command
returns [0,1605] # 1605 for non-existing product error
end
For example, for JDK 1.6.35 (mentioned in question) code should be
code = '{32A3A4F4-B792-11D6-A78A-00B0D0160350}'
So it seems like this is different command than used by Chef:
used by Chef
MsiExec.exe /I{32A3A4F4-B792-11D6-A78A-00B0D0160350} /qn
this command
MsiExec.exe /quiet /X{32A3A4F4-B792-11D6-A78A-00B0D0160350}
Maybe somebody will find this useful.

This looks like it might not be a chef problem as such. The uninstaller is hitting an error for some reason. Try googling for "java install error 1603" and you'll see a bunch of posts, including one that's apparently a bug that's currently under investigation https://www.java.com/en/download/help/error_1603.xml - though it sounds like that might be install not uninstall.
Try removing it manually and debug that, then once you understand it you can chef it.

I did something similar to your answer, but it only requires the package name rather than the code from the registry.
execute 'uninstall_jdk8u72' do
command "wmic product where name=\"#{node[:java8u72][:package_name]}\" call uninstall"
end
I got the idea from https://github.com/chef-cookbooks/windows/issues/89

How to catch 'Unsupported major.minor version' error?

I understand the issue regarding this type of error. I would like my program to be able to detect the java version running and provide a more elegant message to the user rather than the somewhat cryptic 'Exception in thread "main" bla bla bla' message. I can detect the Java version running, but it appears that my program never gets far enough to run my checking code.
In short... how can my program catch this error, present a message and exit gracefully?

This exception is throwing from ClassLoader, so I could suggest you write your own version of ClassLoader which will backtrace such errors.
UPD: More specifically you can try to override method defineClass, catch there such exception and wrap it in convenient way.
UPD-2: As I mentioned in comments, and as us2012 reformulated my idea (thanks to him), you have to compile your classloader with a -target that is guaranteed to be lower than the user's VM version

So it's java.lang.UnsupportedClassVersionError. It is (evidently a descendant of the Error class in Java) which subclasses java.lang.ClassFormatError which in turn subclasses java.lang.LinkageError (which is a direct subclass of java.lang.Error)). This error is thrown in the cases when the JVM (Java Virtual Machine) attempts to read a class file and finds that the major and minor version numbers in the particular class file are not supported. This happens in the cases when a higher version of Java Compiler is used to generate the class file than the JVM version which is used to execute that class file.
This is quite easier to understand – how can the compiler have the information at the time of compilation about which version of JVM would be used execute the compiled class file? It can't, right? So is the case with other errors as well. This is the reason why all the Errors are unchecked.
Why you even give user the chance to see this error message! This as you say "cryptic" message will only be emitted out when you are using an earlier version of JVM to execute the class file than the corresponding version of compiler you used to compile the source code. Now, why would you do that?