We Keep Coding

Java Library Commons Lang3 'ClassNotFoundException' error

import java.util.Arrays;
import org.apache.commons.lang3.ArrayUtils;
public class MonsterGame {
public static void main(String[] args)
{
Monster.buildBattleBoard();
char[][] tempBattleBoard = new char[10][10];
// ObjectName[] ArrayName = new ObjectName[4];
Monster[] Monsters = new Monster[4];
// Monster(int health, int attack, int movement, String name)
Monsters[0] = new Monster(1000, 20, 1, "Frank");
Monsters[1] = new Monster(500, 40, 2, "Drac");
Monsters[2] = new Monster(1000, 20, 1, "Paul");
Monsters[3] = new Monster(1000, 20, 1, "George");
Monster.redrawBoard();
for (Monster m : Monsters) {
if(m.getAlive()) {
int arrayItemIndex = ArrayUtils.indexOf(Monsters, m);
m.moveMonster(Monsters, arrayItemIndex);
}
}
Monster.redrawBoard();
}
}
When trying to run this code, I get this error:
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/lang3/ArrayUtils
at MonsterGame.main(MonsterGame.java:55)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.lang3.ArrayUtils
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 1 more
I have two files, in the same package. I've only shown this one because I do not believe the other file is the problem.
I followed a tutorial on how to use java libraries: download, import, build path etc.
The problem here is, the import seems to be fine but actually using the library is the problem.
I'm very new to Java so sorry if this is a very simple error to fix.
Thank you for any response/feedback in advance.

The referenced library you are using (apache common lang3) and any other library for that matter is used in three different ways.
First, you need the library during development, so your IDE can
validate your code, when you call classes, objects and methods from
the library.
During compilation you need the library, so the java
compiler can reference the right paths, and optimize your code,
where possible.
You need the library during runtime, when your program is run by the Java Virtual Machine, so it can find whatever you used from the library.
The first 2 are usually seen as one, because both is usually considered 'compile time', though strictly speaking only the second one actually is. This means that you need to have the library in place for the IDE (for points 1 and 2) and for the program (point 3). Your exception is thrown, because during runtime, your library is not found by the ClassLoader. The ClassLoader is the way the JVM loads classes for the programs it uses. If the JVM does not find a class, it cannot continue to execute the Thread you are running, and you are probably only running one Thread (a main thread).
Therefore your program breaks, and stops running. Please either recheck the tutorial you are using on how to correctly import libraries or export the library to the lib folder next to the jar you are exporting.
Edit: When using an up to date version of eclipse, and exporting a project as runnable jar, you are asked what way you want to handle libraries:
If you do not see this subsection of the export dialog, you are doing something wrong (probably you are not exporting as runnable jar).

lm function error on RenjinScriptEngine (EvalException)

I found when all values are the same, the lm function throws errors. But it worked on GNU R. I am using the latest renjin-script-engine-0.8.1593.jar.
Any exception is thrown:
Caused by: org.renjin.eval.EvalException: contrasts can be applied only to factors with 2 or more levels
at org.renjin.primitives.Conditions.stop(Conditions.java:193)
at org.renjin.primitives.R$primitive$stop.doApply(R$primitive$stop.java:72)"
when I called RenjinScriptEngine.eval(..) with this script:
fit<-lm("formula"=vals~index,"data"=data)
The data of input is
"2015-36",9
"2015-37",9
"2015-41",9.

Renjin's goal is to be compatible with the latest version of GNU R. If you find a difference or encounter error like that above, please file a bug report at https://github.com/bedatadriven/renjin/issues. We're happy to have the test cases!

JavaDoc - Undeclared Type Variable

I think everybody who has to work with Maven and Java8 knows of this bug that release builds suddenly fail for spelling mistakes in JavaDoc. As a company we decided to let some poor sap (aka me) work all of them out. Now I'm stuck with the following "error":
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.10.1:javadoc (default-cli) on project org.acme.project.demo: An error has occurred in JavaDocs report generation:
[ERROR] Exit code: 1 - C:\jenkins\workspace\Project 2.0\org.acme.project.demo\src\main\java\org\acme\project\demo\SomeClass.java:36: error: cannot access OtherClass
[ERROR] import org.acme.project.OtherClass;
[ERROR] ^
[ERROR] bad class file: C:\jenkins\workspace\Project 2.0\org.acme.project\target\org.acme.project-2.0.0-SNAPSHOT-v20150128-1503.jar(org/acme/project/OtherClass.class)
[ERROR] undeclared type variable: N
[ERROR] Please remove or make sure it appears in the correct subdirectory of the classpath.
I tried to clean it up a bit, but to summarize: Project B throws the exception when it tries to resolve a method call to Project A (yes, while generating JavaDoc!). The method in question looks like that:
public static <N extends Bean> void hookContinousImageFunction(final OtherClass<N> dialog,
final ImageGroup imageGroup, N model, final BiFunction<Image, N, ? extends Image> imageFunction) {
final Image original = imageGroup.getImage();
dialog.setOnCancelClick((notUsed) -> imageGroup.setImage(original));
model.addPropertyChangeListener(new ContinousImageFunctionListener<>(dialog, imageGroup, imageFunction));
dialog.setInitialModel(model);
}
It doesn't even have JavaDoc (not that any of this should matter when the generation of Project A's JavaDoc is already finished, and Maven is trying to generate JavaDoc for Project B).
As of now, we have this bug in multiple projects, about 1 out of 5. Project A (the one with a typed method / class like above) is more often than not in an entirely different build reactor and sometimes completely out of our control.
How do I fix this bug inside a bug?
(As a as a side note, the error occurs on the Jenkin's running with Java 1.8.0_31 and jdk1.8.0_40 or locally with 1.8.0_45, 1.8.0_60, but not locally with 1.8.0_20, but JavaDoc generation hasn't been that reliable, so I can't say for sure it has something to do with the Java version.)

I got the same kind of error message using a central build while having no problems in my local build. (Unfortunately I have no details about the central build environment.)
Adding a '#param ' explanation in the JavaDoc comment for the static method in question solved the issue. Adapted to the given example I did something like this:
/**
* #param <N> This is the class that ...
*/
public static <N extends Bean> void hookContinuousImageFunction(...)

Okay the answer is to a) downgrade Java to 1.8.0_20, or - if that is not possible - b) to use this code in the pom.xml to disable JavaDoc of the project until the Java people feel the need to fix the bug:
<properties>
<maven.javadoc.skip>true</maven.javadoc.skip>
</properties>

XText: 7 languages tutorial can't resolve reference to JvmIdentifiableElement in example 1 scripting

I'm following 7 languages tutoiral from XText homepage (http://www.eclipse.org/Xtext/7languages.html)
In the first example "scripting" I've managed to get almost everything running, but there seems to be a problem with identifiers scoping.
I have editor running and code generation for empty script, but trying to write anything useful doesn't work.
I typed code for grammar and model inferer verbatim from tutorial and also tried to use versions from github repo with examples https://github.com/xtext-dev/seven-languages-xtext
demo.script
val i = 1
demo.java generated
public class demo {
public static void main(final String[] args) {
final int i = 1;
}
}
This works fine
Now here is input that causes problems
error.script
println("test")
This reports two errors:
Error 1
Description: Couldn't resolve reference to JvmIdentifiableElement 'println'.
Resource: error.script
Path: /org.xtext.scripting.demo/scripting
Location: line: 3 /org.xtext.scripting.demo/scripting/demo.script
Type: Scripting Problem
Error 2
Description: This expression is not allowed in this context, since it doesn't cause any side effects.
Resource: error.script
Path: /org.xtext.scripting.demo/scripting
Location: line: 1 /org.xtext.scripting.demo/scripting/error.script
Type: Scripting Problem
I'm using XText plugins in version 2.4.0
Any suggestions what to change to make this example working as described in tutorial?

You have to add a dependency to the xbase.lib to the project that contains the script file.

Drools: NullPointerException when addPackageFromDrl(source) is called

I'm trying to execute a simple HelloWorld rule within an OSGi application. During parsing and compiling however, the following exception occurs:
java.lang.NullPointerException
at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:47)
at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:446)
at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:304)
at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:167)
The DRL file is found by the application, since introducing syntax errors results in a failed compilation warning. I guess I'm overlooking something trivial, but haven't found it yet...
I'm using Drools 4.0.7, since this one was available on the Springsource Enterprise Bundle Repository. Here are my application code and drl:
//read in the source
Reader source = new InputStreamReader( getClass().getResourceAsStream( "hello.drl" ) );
PackageBuilder builder = new PackageBuilder();
//this wil parse and compile in one step
builder.addPackageFromDrl( source );
// Check the builder for errors
if ( builder.hasErrors() ) {
System.out.println( builder.getErrors().toString() );
throw new RuntimeException( "Unable to compile \"hello.drl\".");
}
//get the compiled package (which is serializable)
org.drools.rule.Package pkg = builder.getPackage();
//add the package to a rulebase (deploy the rule package).
RuleBase ruleBase = RuleBaseFactory.newRuleBase();
ruleBase.addPackage( pkg );
StatefulSession session = ruleBase.newStatefulSession();
session.fireAllRules();
#created on: May 1, 2011
package test
rule "A stand alone rule"
when
eval(true)
then
System.out.println("hello world");
end
As always, help is highly appreciated.
KR,
Niels
EDIT: During debugging I noticed that the internal builder object within the PackageBuilder was null, as were the package and packagedescription. I got around the original problem by adding this description manually:
PackageBuilder builder = new PackageBuilder();
PackageDescr packageDescr = new PackageDescr("be.ugent.intec.doctr.processor.job.fever");
builder.addPackage(packageDescr);
//this will parse and compile in one step
builder.addPackageFromDrl( source );
My rule was edited to the following form:
package be.ugent.intec.doctr.processor.job.fever
rule "hello"
when
eval( true )
then
System.out.println("hello there");
end
This however results in a compile failure:
BR.recoverFromMismatchedToken
[1,0]: unknown:1:0 mismatched token: [#0,0:6='println',<7>,1:0];
java.lang.RuntimeException: Unable to compile "hello.drl".
at be.ugent.intec.doctr.processor.job.fever.FeverJob.execute(FeverJob.java:45)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:525)
When removing the package line from the rule, then my example goes all the way through, without printing anything however. Am I again overlooking anything? I guess this is related to an issue within the drl itself, considering everything stands or falls with the declaration of the package. Just to be clear, the drl is loaded in a class contained in the package be.ugent.intec.doctr.processor.job.fever.
Thx!

A NullPointerException shouldn't happen during compilation: either you get a clear compilation error during parsing (which includes line number) or it works. Drools 4.0.7 is old. This is probably already fixed in a newer version of drools. If it isn't, raise a JIRA issue.
Try a more up-to-date version of drools, preferably even a 5.2 version (5.2.0.CR1 will be out later today or tomorrow), which uses the new, better parser.