We Keep Coding

NanoHTTPD: How do I add it to a current Java eclipse project and use it?

This is my first time with Java and Eclipse. I started a brand new Java project and I want to import/add NanoHTTPD into it. How do you this?
This is NanoHTTPD's site: http://nanohttpd.com
Thanks!
Edit
Lesson learned, be specific or you get backslashed for asking. I edited the question and here's some background and the problem I'm running into.
I'm developing a Nodejs backend that needs to query a JAVA project I was given. Pipes are a no go because the services will run on different machines. Tomcat seems like an overkill so I decided to use NanoHTTPD to develop the web service. I come from Ruby & Nodejs so compilation and Eclipse are very new to me. First off, I have no JAR file just TAR and ZIP and from what I read they are fundamentally different. However, I tried importing the TAR and ZIP files as recommended but the structure I get in Eclipse does not seem right compared to the JRE System Library or others I've seen. Notwithstanding, I went ahead and tried to import the package from my Main.java file
package fi.iki.elonen;
public class Main {
public static void main (String[] args)
{
System.out.println("Main");
}
}
When I try to run it I get the following error:
Exception in thread "main" java.lang.Error: Unresolved compilation problem:
at Main.main(Main.java:4)
I found a great article from IBM "Managing the Java classpath (UNIX and Mac OS X)" where it mentions that an IDE such as Eclipse can alleviate the pain of dealing with the source path, classpath and compilation. Unfortunately, I'm afraid this is where I might be getting stuck.
I tried uploading images of what I have but apparently I'm not popular enough yet to do it.
Could someone help me figuring out how to not only import libraries but using them on projects? Even just a URL to a clear Linux/Mac OS X post that explains import with multiple packages would be great.

NanoHTTPD is designed to be very lightweight.
I just cut and pasted the 'NanoHTTPD' class from the source on github, its all in there - and pasted it as a class into my own project.
Then I created a subclass of nanoHTTPD, overrode the 'serve' method to send my own stuff and it was job done.

Download the jar, drag it into the project, and right-click it to add it to the build path.

LuaJ and Android: cannot bind class

I am currently writing a game engine in Java using the LibGDX framework. For several months now, I have successfully used LuaJ 3.0 with my engine. I have had no problems getting scripts to run on Android (tested on two devices) or Desktop (in and out of Eclipse).
However, when I tried to deploy to Android today, I got the following error:
org.luaj.vm2.LuaError: script:2 vm error: java.lang.ClassNotFoundException: com.javamon.console.ScriptPlayerCreate
The line of the script causing this error is:
Result = luajava.bindClass("com.javamon.console.ScriptPlayerCreate")
This is typographically identical to the class supposedly "not found" on Android.
If I try to bind a regular java class, such as java.lang.ClassNotFoundException, I don't get any error. However, this error does not occur on the Desktop version, whether run from within Eclipse or via a runnable *.jar.
Here is the stack trace, retrieved from LogCat:
org.luaj.vm2.LuaError: script:2 vm error: java.lang.ClassNotFoundException: com.javamon.console.ScriptPlayerCreate
at org.luaj.vm2.lib.jse.LuajavaLib.invoke(Unknown Source)
at org.luaj.vm2.lib.VarArgFunction.call(Unknown Source)
at org.luaj.vm2.LuaClosure.execute(Unknown Source)
at org.luaj.vm2.LuaClosure.call(Unknown Source)
at com.javamon.console.Script.runFunction(Script.java:91)
at com.javamon.console.Script.runFunction(Script.java:96)
at com.javamon.console.ScriptPlayerCreate.run(ScriptPlayerCreate.java:39)
What bothers me is the very last line. ScriptPlayerCreate certainly exists -- it's running the very script that produces the error!
Things I have tried:
Trying different versions of LuaJ
Binding a different class within the com.javamon package (same problem)
Updating my ADT/SDK plugins
Cleaning/rebuilding the project within Eclipse
"Starting Over" (creating a new LibGDX project using the GUI tool, and manually importing my source files)
Checking classes.dex -- ScriptPlayerCreate is certainly there
Testing on separate Android devices (Moto X and Incredible 2)
I would like to reiterate that I have successfully used LuaJ with Android for several months without incident. Additionally, I have not changed my scripting engine since my last (successful) Android deployment.
UPDATE
After trying to revert to backup versions of my app and Eclipse, the problem persists -- even on another computer. I am beginning to suspect that luajava.bindClass() does not know how to interpret the contents of classes.dex, and is instead searching for actual class files.
When I attempted to recompile some backup versions, I noticed that the recompiled version almost always has a smaller classes.dex file than the backup. Perhaps something is wrong or has changed with Eclipse's/Android's compiler?
I tried manually inserting class files into the com/javamon/console/ folder within the APK, but of course that messes up the file integrity, and even after re-signing the app will not load. Any ideas?

I got a similar problem，and I'd fix it
LuaJavaLib.java:202
original
return Class.forName(name, true, ClassLoader.getSystemClassLoader());
change to
return Class.forName(name, true, Thread.currentThread().getContextClassLoader());

Reverting to LuaJ 2.0.1 solved the issue.
It appears that all versions of LuaJ above 2.0.1 have a different implementation of LuajavaLib.class. In the new implementation, only Java system libraries can be accessed through luajava.bindClass(), whereas in the older versions, bindClass() permits access to local application classes as well. All other script functions behave normally; only luajava.bindClass() is affected.
In the newer versions, if a class is not found in the Java system libraries, LuaJ apparently checks the local application directory. Because the Desktop project is a runnable *.jar and contains actual class files, the Desktop version of the game would have worked properly in any version of LuaJ. Contrastingly, Android bundles everything in a classes.dex file, which is not "searchable" in the file-path sense. Hence the ClassNotFoundException.
Lastly: I have been using LuaJ successfully for months, so what changed? Apparently, when I upgraded to 3.0 several months ago, Eclipse never actually recognized the file change. It was only when I refreshed and cleaned the project that Eclipse realized a new version of LuaJ was present. Because the main project in LibGDX is source-files only (assets are in -android), you almost never click "refresh". Thus, the LuaJ problem has been a time-bomb of sorts.
I plan on submitting a support ticket to the author so he can address this issue. Until he does, I advise Android developers to stay with LuaJ 2.0.1!

Also you can fix it with your class Helper.
Create package: org.luaj.vm2.lib.jse
In this package create following class:
package org.luaj.vm2.lib.jse;
public class Helper {
public static JavaClass forClass(Class c) {
return JavaClass.forClass(c);
}
public Class<JavaClass> huskClass() {
return JavaClass.class;
}
}
Then create something like bridge class:
public class LuaBridge {
public Varargs getClass(String clazzName) {
try {
Class clazz = Class.forName(clazzName);
return Helper.forClass(clazz);
} catch (Exception e) {
e.printStackTrace();
Crashlytics.logException(e);
}
return null;
}
}
And now when you run your script you can pass instance to your lua script:
_globals = JsePlatform.standardGlobals();
_bridge = new LuaBridge();
//...
_globals.loadfile(scriptName)
.call(CoerceJavaToLua.coerce(_bridge));
Inside your LUA script:
First line:
local luaBridge = ...
-- some code here...
UserManager = luaBridge:getClass("com.dexode.cree.ScriptPlayerCreate")
-- used like luajava.bindClass("com.dexode.cree.ScriptPlayerCreate")

Error compiling Jenkins plugin using Java and Maven

I'm hoping somebody could help. I'm trying to compile a simple plugin for Jenkins/Hudson that will execute code on a slave, however this block of code is failing to compile:
// Define what should be run on the slave for this build
Callable<String, IOException> task = new Callable<String, IOException>() {
public String call() throws IOException {
// This code will run on the build slave
return InetAddress.getLocalHost().getHostName();
}
};
// Get a "channel" to the build machine and run the task there
String hostname = launcher.getChannel().call(task);
I'm getting an exception when trying to compile when declaring the Callable variable Task. The error is 'error: wrong number of type arguments; required 1'.
I'm new to both creating jenkins plugins and Java so I'm hoping someone more experienced could aid me. I've googled extensively and the documentation suggests I'm doing the right thing (http://grepcode.com/file/repo1.maven.org/maven2/org.jvnet.hudson.main/remoting/1.366/hudson/remoting/Callable.java#Callable) which is why I've came up stuck.
Thanks for your time.

Are you compiling against 'java.util.concurrent.Callable' rather than 'hudson.remoting.Callable'? Check the import statements.

You're looking at a really old version of the Jenkins code. Here are links to the current JavaDoc and the latest code.
It looks as if the Remoting class that you were trying to use doesn't exist any more.

Multiple main-methods for testing purposes in Netbeans 7.4 (project from Netbeans 7.2.1)

I recently switched from my older Netbeans version 7.2.1 to 7.4. I am working on a bigger project which uses only one main-entry point of course. However, for testing purposes I am using a second class which also contains a main-method. In my older Netbeans version I was able to Shift+F6 (Run File) and it did what it says: It runs the file because if has a valid main-method. With the never version of the IDE the program keeps telling me, that there is no main-method. This main-method is anything but special and the autocheck does not warn me either (Why wouldn't it? It is totally valid and worked in version 7.2.1).
Here is my testing class definition for the sake of completeness:
package Tests;
// various imports from surrounding project or external packages
public class TEST001 {
// variables and methods for further testing
public static void main(String[] args) throws IOException{
// [...]
}
}
Now, are there incompabilities between projects of Netbeans 7.2.1 to these of version 7.4 which might have caused this?
Or do I have to check a special option somewhere to allow the handling of multiple main-entry points? Which seems unlikely because running a file instead of the project seems to be permanent feature with its own user controls.
Or is this simply a bug?
Thank you for your suggestions.

Can't compile an application using Eclipse, Maven, and the Android Plugin for Maven

I'm trying to create an Android application in Eclipse using the Maven plugin and the m2eclipse-android-plugin as well. Things were going "ok" until recently. I'm using Helios on Ubuntu and have the latest JDK (removed the default one installed by Ubuntu).
The project references two libraries that I've also created. One is an Android specific utility project and generates the .apklib (successfully). The other library is a more general purpose set of utilities not specific to Android which produces a JAR file. Both of these projects are also built using the Maven plugin for Eclipse. In addition, I've verified that both the .apklib and .jar files are in the local repository and both included all of the generated class files as would be expected.
When it goes to build the .apk file, I'm getting a "cannot find symbol" on a class in my Android project where the symbol is a class from the non-Android utility JAR file. For some completely bizarre reason, the class file cannot be found inside the JAR file. I verified that, in fact, the JAR file is in my local maven repository and that the class file is in the JAR file. I've also run the maven install command with debugging on, copied the command line that gets fed into the Java compiler. When I execute that command in a console, I receive the SAME error (indicating that it's a Java compiler error and not a Maven error).
Has anyone else run into this type of situation before? It's extraordinarily strange and I've completely combed the command line for potential issues and, best as I can tell, everything seems correct.

Well, through what appears to be trial and error I seem to have fixed the problem. I had a file that looked "similar" to this:
import Test.TestObserver;
import com.myself.ImportedClassThatCouldntBeFound;
class Test extends ImportedClassThatCouldntBeFound {
public interface TestObserver {
public void event ();
}
public void addObserver (TestObserver observer) {
...
}
}
public class AnotherTest {
private Test test = new Test ();
public void blah () {
this.test.addObserver (new TestObserver () {
public void event () {
...
}
});
}
}
The problem happened at the TOP of the file. For some reason, Eclipse imported the inner interface!
When I "REMOVED" that import, and then changed AnotherTest to:
public class AnotherTest {
private Test test = new Test ();
public void blah () {
this.test.addObserver (new Test.TestObserver () {
public void event () {
...
}
});
}
}
it compiled correctly! I even verified it by putting the import BACK into the file and removing the fully declared interface name and it caused it to fail again! It's definitely one of the craziest compiler issues I've ever seen and once I get back the FOUR HOURS of my life that I lost researching this, I'll do more investigation into why this is occurring.
This will be the first time I do this on StackOverflow, but I'm going to mark this as the solution because it most definitely was the issue. However, it definitely requires more research (at least on my part) to try and understand what was causing the compiler to become so confused.
edited this to make it apparent that the class that had the inner interface was extending the class that could not be found when compiled

To me, it looks like a problem caused (ultimately) by putting two top-level classes into a single source code file. This is generally thought to be bad practice.
It is not clear whether the compilation error is mandated by the JLS, whether it is a bug in the Java compiler. But either way, the best fix is to not put multiple classes into one source file.