I am running project in netbeans, and I want to run the same project on command prompt...
But during compilation the message comes
Note : filename.java uses or overrides
a deprecated API
Note : Recompile with
-Xlint:deprecation for details.
How can I compile and run the project in command prompt?
How can I remove this problem please tell me...
Try this at the command prompt:
javac -Xlint:deprecation filename.java
The message is telling you that you are using a deprecated API. A deprecated API means an API that you shouldn't be using because it has been replaced by something else. The code will still work for now but someday a future release may eliminate the deprecated API and then your code will break. It is a good idea to stay away from deprecated APIs. The message is telling you to invoke javac with the -Xlint:deprecation flag and it will tell you exactly what it is complaining about.
Note: even if you get this warning message when you compile, you can ignore it - your program still compiles and works.
You might as well try using the following annotation:
#SuppressWarnings("deprecation")
#SuppressWarnings—the
#SuppressWarnings annotation tells the
compiler to suppress specific warnings
that it would otherwise generate. In
the example below, a deprecated method
is used and the compiler would
normally generate a warning. In this
case, however, the annotation causes
the warning to be suppressed.
// use a deprecated method and tell
// compiler not to generate a warning
#SuppressWarnings("deprecation")
void useDeprecatedMethod() {
objectOne.deprecatedMethod(); //deprecation warning - suppressed
}
But you might end up leaving the deprecated code there forever. Best is for you to consider using the new API.
NetBeans by default will create an Ant project (although you can use Apache Maven, as well, with NetBeans). If you see a file named "build.xml" in your folder, then you should build with:
ant
If you see a file named "pom.xml" in your project folder, then you should build with:
mvn package
The warning message that you see is not an error, meaning that it did compile successfully, but you should probably deal with the warnings, since they indicate that you are using deprecated features. As to executing your project, simply invoke the java command with your JAR file. For example:
java -jar build/myproject.jar
Typically the resulting JAR is placed in the "build" directory; you will need to replace "build/myproject.jar" with the name of the actual JAR file. For some projects, the output directory may differ.
Related
I have a Java class which uses a .jar file.
Every time that I want to compile this class, I have to do something like javac -cp ".:myJar.jar" myClass.java and every time that I want to execute it, I have to do the similar thing but with java instead of javac.
Is there a way to avoid doing this?
I know that I could put this jar file into my class path but I don't want to do that. I don't neither want to do a maven projet.
There is nothing preventing you from using an IDE, taking advantage of all its super useful features when developing the program, and then submit just the source code and associated jars to the professor.
Advantages of using IDE that your professor don't need:
Syntax color-coded editors with auto-complete.
Built-in display of javadoc, so you know what all the built-in Java methods do, and how they work.
Instant high-lighting of syntax errors.
Never having to compile the code, since IDE always keeps the code compiled.
Easy single-button execution of the program when you want to run it.
Debugger. Very important feature when your code is not working as you intended.
... more ...
When I attempt to run scons (2.3.0) to build a class from a SWIG interface file, scons fails to pick up all the generated files, either as being in the sourcepath, or to be included in the build (even with classpath set). Instead only two java files are attempted to be compiled, both of which fail because they are derived from other classes.
loc_env = env.Clone()
loc_env['JAVACLASSPATH']= ['build/$TARGET_ARCH/$TARGET_OS/.../java']
swig_j = loc_env.Java(target='.', source=['source_java.i']) #1
#swig_j = loc_env.Jar(target='.', source=['source_java.i']) #2
Both #1, and #2 fail to produce a result. #2 shows an error message that the source has not been accepted, and is a blank string, which I can accept, even with example code suggesting it should work.
For #1 The root cause seems to be in Scons/Tool/swig.py def _find_modules(src):, which has a regex to match all modules generated, but fails to account for any raw enums or other artefacts from wrapping up C code. When I had a hand-rolled makefile the classpath
For reference, The javac build instruction for #1 is:
javac -classpath build/x86_64/linux/.../java -d build/x86_64/linux/.../java/ -sourcepath build/x86_64/linux/.../java build/x86_64/linux/release/.../source.java build/x86_64/linux/release/.../sourceJNI.java
Is this a known bug (As part of SCONS' handling of 1->N mappings)? Is it a flaw in the Scons Parsing of .i files? or is it a more fundamental issue?
This is a bug in SCons. The changes slated for 2.5.0 fix the issue, by improving cross-language scanning. I look forwards to ripping out my hack sometime next year!
I'm trying to compile my Java program, however I am getting a "Deprecated File" error.
I normally compile the file by typing "Javac FileName.java", however I get an error saying:
FileName.java uses or overrides a depreacted API.
Recompile with Xlint-deprecation for details.
What do I type into the command line to make it run?
It's not an error, just a warning.
The compiler will still produce a class file and you will be able to run it. However, it's a good idea to address the warning, since using deprecated API could lead to more problems later on.
If you choose to see the warnings, you can do this:
javac -Xlint:deprecation FileName.java
If you don't have a deprecation
javac -Xlint Filename.java
I was getting the same exception in running a gradlew build. I discovered that the path included Java 1.7 and my JAVA_HOME variable path had 1.8 specifed. Once I updated the path to 1.8, the build was successful.
Had the similar issue and setting the PATH to the correct file that contains the JDK worked.
For windows,
search environnement variables > select edit environnement variables > Enter JAVA_HOME as variable and set the value to the jdk file.
I'm trying to compile a whole java project dynamically using the Compiler API. My initial thoughts of achieving this is to first know how to compile it in one-line using command line, then apply the same principle/parameters on the compiler object. Problem is, I never did, err, compiled using CLI. (Disadvantage of using an IDE? Haha)
So, am I on the right track? Moreover, can the project compilation achieved in one line execution? I'm having a hard time figuring this out because of the fact that it's a project, it contains packages galore.
So you either want to learn javac or Java Compiler API?
If you want CLI compilation look at javac (Linux | windows).
Alternatively for API, then programmatic use of Java's compiler API will definitely require more that one line, this will get you the compiler:
JavaCompilercompiler =ToolProvider.getSystemJavaCompiler();
Then you'll still need to load classes, write out byte code, and possibly package as a JAR.
You should use StandardJavaFileManager as you've probably many classes to manage, there's an example in the top of the JavaCompiler javadoc, but search for StandardJavaFileManager+JavaCompiler+example to find clearer examples like this blog post.
I have an annotation processor for an annotation of retention policy=SOURCE.
I have not idea how to step-debug it.
I have issued print statements, logger info when I run mvn install, compile or package or ant javac, and I see their sysouts in the compile log.
However, I have no idea how to step-debug the processor in Eclipse. I mean, how do you step-debug compile-time?
An option in recent times is to use something like http://github.com/google/compile-testing which lets you invoke the compilation job against arbitrary annotation processors, which you can set break points, step through, etc.
#Test public void testStuff() {
// Create a source file to process, or load one from disk.
JavaFileObject file = JavaFileObjects.fromSourceLines("test.Foo",
"package test;",
"",
"import bar.*;",
"",
"#MyAnnotation(blah=false)",
"interface TestInterface {",
" Bar someBar();",
"}",
// assert conditions following a compilation in the context of MyProcessor.
assert_().about(javaSource()).that(file)
.processedWith(new MyProcessor())
.failsToCompile()
.withErrorContaining("some error message").in(file).onLine(5);
}
This test expects you will get some error message because #MyAnnotation is incorrectly declared in the test data source. If this assertion fails, you can run it in debug mode in your IDE, set breakpoints in MyProcessor, and step through with a full compiler environment active during debugging.
For unit testing specific methods within your processor, you can also use the #Rule called CompilationRule from which you can obtain Elements and Types utility classes in order to test specific logic in your compiler in a more isolated way.
You have to invoke the Java compiler from Eclipse, using a debug configuration (you'll need to create the configuration manually, from the "Debug Configurations..." menu choice.
The "correct" way to invoke the Java compiler under JDK 1.6 or above is to use the JavaCompiler interface in javax.tools, which you get from the ToolProvider (I include all the links because there's a decent amount of class/package documentation that you should read).
The "quick-and-dirty" way (that should work, but I make no guarantees) is to invoke com.sun.tools.javac.Main.main(), passing it your normal command-line arguments. To do this, you'll need tools.jar on your classpath (it's found in $JAVA_HOME/lib).
Annotation processing occurs during compilation, so normal debugging won't work. If you want to debug it in the context of you project, you can use Eclipse remote debugging, while having Gradle or Maven in debug mode. Then you can put breakpoints in the Annotation Processor's files.
See Debugging an Annotation Processor in any project.
Disclaimer: I wrote the post.