I hava a Java project that uses reflection tech while collecting class method info like method name, return type, parameters info of the method of some classes. In order to get the real parameter name defined for method other than just get "arg*", I should compile classes with -parameters option.
I have been finding solutions for half a day, unfortunatly still can't find where to set the compiler options in vscode.
Both Eclipse and Idea provide a way to set compiler options with "-parameters", in eclipse there is a option in "Java-> Compiler" configurations, which is "Store information about method parameters(usable via reflection)", and in Idea there is a input to add option "-parameters" manually.
Related
Motivation:
In our code we have a few places where some methods are run by their name. There are some big if-else-if blocks with each function name and call of the corresponding method (I use the term function to describe just names, for example function X01 might correspond to method SomeClass.functionX01). I've been looking into ways to improve that
Goal:
Write just methods that are annotated with some custom annotation, removing the need to update or even include if-else-if blocks in order to run specific function. Have access to any generated code if any code is generated.
What I did:
I've created first prove of concept using runtime annotations and it proved successful, but slower then if-else-if. Next attempt was with source annotation
I've followed this link for an example, however it did not seam to run in IntelliJ. What I wanted is to have - in this case PersonBuilder class generated, instead there was none. In some cases an error was raised Error:java: Bad service configuration file, or exception thrown while constructing Processor object: javax.annotation.processing.Processor: Provider BuilderProcessor not found
After some Googling and failing to find anything I've turned to book (Core Java, Volume II - Advanced Features - 9th Edition, Polish translation) and there was reccomended to run the following commands:
javac [AbstractProcessor implementation]
javac -processor [Compiled Processor] [other source files to compile]
This worked, however is unsatisfactory as it needs to happen inside IDE (NetBeans and IntelliJ to be specific) automatically during build. Code does not need to be generated on the fly, but programmer must have access to it after build (as in - be able to call methods of generated classes)
Question:
How to have and use generated code used in NetBeans and IntelliJ without the need of using external tools? Is it possible, or using reflection, runtime annotations or external tools is the only way?
Additional info (just in case):
Language level: Java 1.8
JVM versions: 12 and 13
IDEs: NetBeans and IntelliJ
I can't guess how can I specify class, which is entry-point of my program (therefore shouldn't be obfuscated), and my jar archive. Please show me an command-line example, how to use JBCO when I have /home/example/myJar.jar and within it com.example.EntryPoint class and my external dependency /home/example/dependencies/dependencyJar.jar.
Also, please, does anybody know if this project is still alive and what jdk it supports?
A lot of time have passed, but recently I have passed across the java transformation frameworks and find out that JBCO now is a part of soot framework, hosted on GitHub, but it is #deprecated as for now. There is a wiki where you can get more info about how to use soot/jbco (if you still want to, on your own risk, even though JBCO is deprecated and not under active development it still from time to time accepts PRs from contributors).
As for the command line options it might be:
java -cp .:/home/example/sootclasses-trunk-jar-with-dependencies.jar soot.jbco.Main -process-dir /home/example/compiled -output-dir /home/example/obfuscated -soot-class-path .:/home/example/myJar.jar -output-format class -app -main-class com.example.EntryPoint -t:9:wjtp.jbco_cr
Soot can process your compiled code as class files (then pass it to -process-dir option) or as jar (then pass it as part of soot-class-path) - soot can process many forms of bytecode (java/scala/.. bytecode, android bytecode, jasmin, jimple). There are also options to specify what is library classes and application or argument classes more precisely, for more info please refer to soot's wiki page.
I am reading spring document and I couldn't understand below statement from c-namespace section in the reference document
For the rare cases where the constructor argument names are not available (usually if the bytecode was
compiled without debugging information), one can use fallback to the argument indexes
My questions are :
In what cases constructor argument is not available.
What does it mean that -byte code compiled without debugging information. Can be it checked using eclipse ?
I was checking for this over web, but could get any reference. I found Constructor injection using c:namespace but it didn't explain any thing
Constructor argument names are only available if the class is compiled with variable debugging information. When using javac, this is the -g:vars option. In Eclipse, this is Windows > Preferences > Java > Compiler > Add variable attributes to generated class files.
If the class in question was compiled by javac without the -g flag ("debug info" - see javac docs), then the compiled class bytecode will not contain the names of the constructor parameters. This means that Spring cannot use reflection to match the constructor parameter names, so you need to inject them by position (i.e. by index) instead.
It's up the build environment that generates the compiled bytecode to ensure that debug info is supplied. Once the code is compiled, there's nothing you can do to retrieve that information, short of recompiling it.
See also What does the javac debugging information option -g:vars do?
I'm getting:
NoSuchMethodError: com.foo.SomeService.doSmth()Z
Am I understanding correctly that this 'Z' means that return type of doSmth() method is boolean? If true, then that kind of method really does not exist because this method returns some Collection. But on the other hand if I call this method, I'm not assigning its return value to any variable. I just call this method like this:
service.doSmth();
Any ideas why this error occurs? All necessary JAR files exist and all other methods from this class seems to exist.
Looks like method exists in classpath during compilation, but not during running of your application.
I don't think return type is a problem. If it was, it wouldn't compile. Compiler throws error when method call is ambiguous, and it is when two methods differ only by return type.
Normally, this error is caught by the compiler; this error can only occur at run time if the definition of a class has incompatibly changed.
In short - a class/jar file at runtime is not the same that you used at compile time.
This is probably a difference between your compile-time classpath and you run-time classpath.
Here is what seems to be going on:
The code is compiled with a class path that defines the doSmth() method returning a boolean. The byte-code refers to the doSmth()Z method.
At runtime, the doSmth()Z method isn't found. A method returning a Collection is found instead.
To correct this problem, check your (compile time) classpath.
The current reply just tell you why is failing. Usually is even nicer to know how to fix problems. As it is mentioned, the problem usually is that you built your program but when running or exporting it, the library is not included. So the solution is...
If you are running, check the the run configuration
Select Run tab -> Run configurations -> Select the configuration you are running -> Check the Classpath tab -> Ensure the libraries you need are there
If you are exporting (for example a war file), follow this
Select project -> Select properties -> Select Deployment Assembly -> Press Add -> Select Java Build Path Entries -> Select the libraries you want to be included in your exported file (for example a war file)
In both cases, ensure the library which you are referencing in included.
Other frequent problems for this error are not the right type of parameters or visibility but then, the compiler will detect the error before running. In this case, just check the documentation to match the function and package visibility, and ensure that the library is found in Java Build Path in your project properties.
Maybe still can help somebody, but this exception can happen also when you have on the classpath two classes in different jar files that have the same exact signature but they haven't the same public methods.
For example:
On file mylibrary1.jar you have class com.mypackage.mysubpackage.MyClass with method doSmth()
On file mylibrary2.jar you have class com.mypackage.mysubpackage.MyClass without method doSmth()
When searching the class, the classloader may find first mylibrary2.jar depending on the path precedence but can't find the method on that class.
Be sure you don't have the same package + class on two different files.
I noticed this problem occurring while testing some experimental changes in multiple linked projects, after updating them from SVN in Eclipse.
Specifically, I updated all projects from SVN, and reverted the .classpath file rather than edit it manually to keep things simple.
Then I re-added the linked projects to the path, but forgot to remove the related jars. This was how the problem occurred for me.
So apparently the run time used the jar file while the compiler used the project files.
Another way this can happen and is difficult to find:
If a signature of a method in an external jar changes in a way that there is no error found in the IDE because it's still compatible with how you call it the class might not be re-compiled.
If your build checks the files for changes and only then recompiles them, the class might not be recompiled during the build process.
So when you run it this might lead to that problem. Although you have the new jar, your own code expects still the old one but does never complain.
To make it harder it depends on the jvm if it can handle such cases. So in the worst case it runs on the test server but not on the live machine.
I want the eclipse Java Compiler Warnings available as an ant task (ie without eclipse) - ideally as ant plugins - but I want the cruise control ant task to fail if an eclipse warning shows up. For the following warnings
Non-static access to static member
Method with a constructor name
Serializable class without serialVersionUID
Assignment has no effect
finally does not complete normally
Using a char array in string concatenation
Hidden catch block
Inexact type match for vararg arguments
Null pointer access
Type parameter hides another type
Method does not override package visible method
Interface method conflicts with protected 'Object' method
Local variable is never read
unused local or private member
Unchecked generic type operation
Usage of a raw type
Generic type parameter declared with a final type bound
Annotation is used as a super interface
I assume this means that the eclipse abstract syntax tree would have to be used - and an eclipse compilation unit would have to be created.
The question is:
(1) Has this been done?
(2) If it hasn't - then given a
org.eclipse.jdt.core.dom.CompilationUnit
object - how do you (ie in code examples) get the warnings out of this CompilationUnit?
(I KNOW about PMD, checkstyle etc - none of these EXACTLY match the eclipse preferences for coding style. I want an ant task that exactly matches the eclipse coding style)
What version of eclipse?
It is possible to launch the JDT compiler via ant. See:
http://help.eclipse.org/ganymede/topic/org.eclipse.jdt.doc.isv/guide/jdt_api_compile.htm
See 'Using the ant javac adapter'
Warnings and errors are attached to resources (such as files or CompilationUnits) in the Eclipse workspace. They are known as 'markers'. It may be easier to get the warnings as markers rather than via the compilation process directly.
Another avenue to look into is launching a PDE build but I think this is overkill for your requirements and such build scripts can get very difficult to maintain with time.