We Keep Coding

I have been trying to install Jdownloader2 on fedora linux but keep getting NoClassDefFoundError

Running the executable file (.sh) from terminal gives this output
[akash#fedora Downloads]$ ./JDownloader2Setup_unix_nojre.sh
Starting Installer ...
java.lang.NoClassDefFoundError: Could not initialize class java.awt.Toolkit
at java.desktop/java.awt.Color.<clinit>(Color.java:277)
at com.install4j.runtime.installer.frontend.GUIHelper.<clinit>(GUIHelper.java:46)
at com.install4j.runtime.installer.helper.InstallerUtil.reportException(InstallerUtil.java:1327)
at com.install4j.runtime.installer.Installer.main(Installer.java:48)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.exe4j.runtime.LauncherEngine.launch(LauncherEngine.java:84)
at com.install4j.runtime.launcher.UnixLauncher.start(UnixLauncher.java:69)
at install4j.Installer378667612.main(Unknown Source)
I don't know if there is any other output I have to send since I am still pretty new to Linux.
If anyone else got same error. Just remove your JRE/JDK and install it again.
Note- It might remove some other apps like libreoffice and stuff, so save files and make backups.

Installing Ortus Commandbox on Mac OSX Sierra, running box results in errors and exceptions

I tried installing Commandbox from Ortus by downloading the zip file that also contains the JRE. This landed in the Downloads folder on my Mac running OSX Sierra. I unzipped it and tried running box. It first initialized stuff, then ran fine.
The installation tip here: https://ortus.gitbooks.io/commandbox-documentation/content/setup/installation.html
suggests placing the box binary in /usr/bin. I tried but couldn't. I even tried using sudo to mv it but it said I was not permitted.
SO then I decided to use the Homebrew method of installation. I installed Homebrew. When installation was complete, I then ran "brew install commandbox". It completed ok. I then typed "which box" to see which one it would find, the one in my Downloads dir or another. It showed it was in /usr/local/bin/box. Seems to be ok.
I then ran box. It crashes and burns!
$ box
java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at cliloader.LoaderCLIMain.execute(LoaderCLIMain.java:205)
at cliloader.LoaderCLIMain.main(LoaderCLIMain.java:705)
Caused by: java.lang.NoClassDefFoundError: sun/misc/VM
at lucee.commons.collection.Hashing.randomHashSeed(Hashing.java:263)
at lucee.commons.collection.HashMapPro.<init>(HashMapPro.java:195)
at lucee.commons.collection.HashMapPro.<init>(HashMapPro.java:236)
at lucee.commons.collection.LinkedHashMapPro.<init>(LinkedHashMapPro.java:70)
at lucee.runtime.type.StructImpl.<init>(StructImpl.java:82)
at lucee.runtime.type.StructImpl.<init>(StructImpl.java:68)
at lucee.runtime.type.scope.ScopeSupport.<init>(ScopeSupport.java:85)
at lucee.runtime.type.scope.ArgumentImpl.<init>(ArgumentImpl.java:67)
at lucee.runtime.PageContextImpl.<init>(PageContextImpl.java:263)
at lucee.runtime.CFMLFactoryImpl.getPageContextImpl(CFMLFactoryImpl.java:154)
at lucee.runtime.CFMLFactoryImpl.getLuceePageContext(CFMLFactoryImpl.java:140)
at lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:435)
at lucee.runtime.engine.CFMLEngineImpl.cli(CFMLEngineImpl.java:760)
at lucee.loader.engine.CFMLEngineWrapper.cli(CFMLEngineWrapper.java:267)
at luceecli.CLIMain.run(CLIMain.java:223)
... 6 more
Caused by: java.lang.ClassNotFoundException: sun.misc.VM
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:466)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
at lucee.loader.classloader.LuceeClassLoader.loadClass(LuceeClassLoader.java:173)
at lucee.loader.classloader.LuceeClassLoader.loadClass(LuceeClassLoader.java:138)
... 21 more
Cause:
java.lang.NoClassDefFoundError: sun/misc/VM
at lucee.commons.collection.Hashing.randomHashSeed(Hashing.java:263)
at lucee.commons.collection.HashMapPro.<init>(HashMapPro.java:195)
at lucee.commons.collection.HashMapPro.<init>(HashMapPro.java:236)
at lucee.commons.collection.LinkedHashMapPro.<init>(LinkedHashMapPro.java:70)
at lucee.runtime.type.StructImpl.<init>(StructImpl.java:82)
at lucee.runtime.type.StructImpl.<init>(StructImpl.java:68)
at lucee.runtime.type.scope.ScopeSupport.<init>(ScopeSupport.java:85)
at lucee.runtime.type.scope.ArgumentImpl.<init>(ArgumentImpl.java:67)
at lucee.runtime.PageContextImpl.<init>(PageContextImpl.java:263)
at lucee.runtime.CFMLFactoryImpl.getPageContextImpl(CFMLFactoryImpl.java:154)
at lucee.runtime.CFMLFactoryImpl.getLuceePageContext(CFMLFactoryImpl.java:140)
at lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:435)
at lucee.runtime.engine.CFMLEngineImpl.cli(CFMLEngineImpl.java:760)
at lucee.loader.engine.CFMLEngineWrapper.cli(CFMLEngineWrapper.java:267)
at luceecli.CLIMain.run(CLIMain.java:223)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at cliloader.LoaderCLIMain.execute(LoaderCLIMain.java:205)
at cliloader.LoaderCLIMain.main(LoaderCLIMain.java:705)
Caused by: java.lang.ClassNotFoundException: sun.misc.VM
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:466)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
at lucee.loader.classloader.LuceeClassLoader.loadClass(LuceeClassLoader.java:173)
at lucee.loader.classloader.LuceeClassLoader.loadClass(LuceeClassLoader.java:138)
... 21 more
I have no idea what to do now to fix this.
I suspect it may have fouled up things when I ran box from the Downloads folder, not realizing it would initialize stuff. I deleted the Downloads version containing both the box binary and the JRE folder and emptied the Trash.
Any suggestions on how to get Commandbox up and running now?

I just did some local testing and confirmed that you're on Java 9 which isn't supported right now by CommandBox. The fix is easy and you can leave Java 9 installed as the main JVM for your PC. What you need to do is take the JRE folder that you downloaded before, or just download a server version of Java 8 and rename the folder to JRE. Then place that folder in the same directory as the box binary.
When CommandBox first starts, it checks to see if there is a folder called JRE in the same folder, and if so it uses it. If it doesn't find the folder, then it will fall back to the general version of Java your operating system has installed.
Since Java 9 is popping up more in the wild, I'll see about getting a check for it put into CommandBox to alert people with a more useful message. We already have a similar check in place, but it only looks for Java versions less then 7.

[Eclipse not starting]:An error has occured. See the log file null

I'm unable to get my Eclipse Luna running. It was working fine till now and suddenly crashed. Now when i try to start it, I get the error saying:
An error has occured. See the log file null
I tried launching eclipse from terminal and also tried to delete the metadata folder from my workspace but nothing helped me.
Here is the crash log:
org.osgi.framework.BundleException: Error initializing container.
at org.eclipse.osgi.container.SystemModule.init(SystemModule.java:93)
at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.init(EquinoxBundle.java:209)
at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle.init(EquinoxBundle.java:201)
at org.eclipse.osgi.launch.Equinox.init(Equinox.java:168)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:296)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:231)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
Caused by: java.lang.ExceptionInInitializerError
at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule.initWorker(EquinoxBundle.java:137)
at org.eclipse.osgi.container.SystemModule.init(SystemModule.java:83)
... 12 more
Caused by: java.security.ProviderException: setSeed() failed
at sun.security.provider.NativePRNG$RandomIO.implSetSeed(NativePRNG.java:458)
at sun.security.provider.NativePRNG$RandomIO.access$300(NativePRNG.java:329)
at sun.security.provider.NativePRNG.engineSetSeed(NativePRNG.java:212)
at java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:209)
at java.security.SecureRandom.<init>(SecureRandom.java:190)
at org.eclipse.osgi.internal.framework.UniversalUniqueIdentifier.computeNodeAddress(UniversalUniqueIdentifier.java:127)
at org.eclipse.osgi.internal.framework.UniversalUniqueIdentifier.<clinit>(UniversalUniqueIdentifier.java:35)
... 14 more
Caused by: java.io.IOException: Operation not permitted
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:313)
at sun.security.provider.NativePRNG$RandomIO.implSetSeed(NativePRNG.java:456)
... 20 more

It seems you're using Solaris? This OS has an alternative entropy source called EGD, which needs special protocol to write to, which Sun JDK does not implement...
Can you try adding -Djava.security.egd=/dev/random to the vmargs section of your eclipse.ini.
If you still see the same issue. Make sure your user can write to /dev/random.

I fixed it myself. Few files in my security folder /jre/lib/security had got messed up.
Downloaded latest Java Cryptography Extension (JCE) and put the jars (Download US_export_policy.jar and local_policy.jar) in the security folder. My eclipse works fine now.

UnsatisfiedLinkError when running Jetty9's setUID feature

I just tried to run Jetty 9 as non root users, using setuid feature without success for binding low port numbers.
I enabled the module setuid in the start.ini and added -Djava.library.path=/opt/jetty/lib/setuid
But I have the following stack trace when starting Jetty:
2015-06-09 16:27:27.211:WARN:oejx.XmlConfiguration:main: Config error
at | |
java.lang.reflect.InvocationTargetException in
file:/opt/jetty/etc/jetty-setuid.xml
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:321)
at org.eclipse.jetty.start.Main.start(Main.java:817)
at org.eclipse.jetty.start.Main.main(Main.java:112) Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.set(XmlConfiguration.java:479)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:411)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:815)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1125)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1030)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.call(XmlConfiguration.java:721)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:417)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:354)
at org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:262)
at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1243)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1174)
... 7 more Caused by: java.lang.UnsatisfiedLinkError: org.eclipse.jetty.setuid.SetUID.getpwnam(Ljava/lang/String;)Lorg/eclipse/jetty/setuid/Passwd;
at org.eclipse.jetty.setuid.SetUID.getpwnam(Native Method)
at org.eclipse.jetty.setuid.SetUIDListener.setUsername(SetUIDListener.java:53)
... 23 more
Those are the only references to this error:
dev.eclipse.org/mhonarc/lists/jetty-users/msg01657.html
groups.google.com/forum/#!topic/dropwizard-user/aap2B_U_QPo
But they are either stopped or do not show the solution.
The source code I found for the setuid package is:
https://github.com/jetty-project/codehaus-jetty-project/blob/master/jetty-setuid/modules/java/src/main/java/org/mortbay/setuid/SetUID.java
Even though I cannot be sure this is the version I am using, given this one is from a org.mortbay package, while the one Jetty 9 uses is an Eclipse one.
I tried setting -Djetty.libsetuid.path in the java args (first try-catch block), either adding the path to the $PATH variable or setting -Djava.library.path (second try-catch block) or copying the so to /lib and, finally, leaving it as it is (third try-catch block). I got the same exception stack in all the cases.
I cannot be sure if Jetty is either not finding the so file or not being able to load it, given that, if I remove all the references to the path (the cases I described latter), I still get the same error message.
I use Java7 to run Jetty.
Edit
I added the following snippet to one of my webapps as as matter of test, given that if the webapp succeed, I would know the problem is not in finding the shared object:
SetUID.setgid(1002);
SetUID.setuid(1002);
Passwd pw = SetUID.getpwuid(1002);
System.setProperty("user.name", pw.getPwName());
System.setProperty("user.home", pw.getPwDir());
I have the same UnsatisfiedLinkError as a result.
Edit2
I tried, instead, the following:
System.load(SetUID.__FILENAME);
SetUID.setgid(1002);
Which got me the following error message:
javax.servlet.ServletException: java.lang.UnsatisfiedLinkError: Native
Library /lib/libsetuid.so already loaded in another classloader
I may conclude, therefore, that the library has been loaded, at least.

Exploring the libsetuid file (nm -D /path/to/the/so), I realized that the so I was using was outdated and was not compatible with Jetty 9, the functions were named as mortbay:
root#root:~/# nm -D libsetuid.so --size-sort | less
0000000000000010 T Java_org_mortbay_setuid_SetUID_setgid
0000000000000010 T Java_org_mortbay_setuid_SetUID_setuid
0000000000000015 T Java_org_mortbay_setuid_SetUID_setumask
0000000000000018 T throwNewJavaSecurityException 0000000000000058 T
throwNewJavaException 000000000000008e T
Java_org_mortbay_setuid_SetUID_setrlimitnofiles 00000000000000a7 T
getJavaMethodId 00000000000000f5 T
Java_org_mortbay_setuid_SetUID_getrlimitnofiles 0000000000000102 T
getJavaFieldInt 0000000000000111 T setJavaFieldInt 0000000000000111 T
setJavaFieldLong 0000000000000121 T setJavaFieldString
00000000000001ba T Java_org_mortbay_setuid_SetUID_getpwuid
00000000000001e5 T Java_org_mortbay_setuid_SetUID_getpwnam
000000000000027e T Java_org_mortbay_setuid_SetUID_getgrgid
000000000000029e T Java_org_mortbay_setuid_SetUID_getgrnam
Now, I am using the shared object that already comes in the jetty download, not the one linked in the wiki.
In addition to that, looking through the code of the setuid module, I decided using the property -Djetty.libsetuid.path in my java args for indicating the absolute path of the lib, e.g., -Djetty.libsetuid.path=/opt/jetty/lib/setuid.so

Making an executable jar that evals Clojure strings

I'm building a Java app that loads Clojure files. I'm having trouble making a single executable jar. I'm using One-Jar, but I get an exception when I try to run the jar file:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at com.simontuffs.onejar.Boot.run(Boot.java:340)
at com.simontuffs.onejar.Boot.main(Boot.java:166)
Caused by: java.lang.ExceptionInInitializerError
at com.ziroby.clojure.App.main(App.java:14)
... 6 more
Caused by: java.lang.NullPointerException
at clojure.lang.RT.lastModified(RT.java:374)
at clojure.lang.RT.load(RT.java:408)
at clojure.lang.RT.load(RT.java:398)
at clojure.lang.RT.doInit(RT.java:434)
at clojure.lang.RT.<clinit>(RT.java:316)
... 7 more
When I look at the line that's causing it, it seems to be trying to get jar information for the relative class files:
return ((JarURLConnection) url.openConnection()).getJarFile()
.getEntry(libfile).getTime();
I think this means that it's trying to get jar information for an embedded jar, which doesn't actually exist on the file system. It's looking at that to see if it needs to recompile a file (like common/core.clj).
Am I doing something wrong? Is there some other way to create an executable jar (with dependencies) without confusing Clojure?

I have come to the conclusion that this is a bug in Clojure. I am able to add a single null check (just before the .getTime() call), and it works correctly. I've entered a bug in Clojure's Jira: http://dev.clojure.org/jira/browse/CLJ-971