I recently read an article talking about the Java annotations, and on this latter comes the #Generated one. They say that it is used for automatically generate code.
Could someone explain me that in further with a little example ?
All what i found on the net was some pro question or something beyond what i was looking for.
As per the JavaDoc:
The Generated annoation is used to mark source code that has been generated. It can also be used to differentiate user written code from generated code in a single file.
#Generated is used by meta-programs such as Auto/Value which generate source code so you don't have to manually write it. If you're writing a .java file by hand (which is normally what one does), don't use #Generated.
Fox example are good and bad policies on the border between generated and written code. Way of thinking is (i belive) different in compiled (static) languages, nad interpreted / dynamic.
Worst is to modify generated code (will be lost at next generation, or next generation is then prohibited)
Usually is accepted to derive (manual) class from generated, or generate class what extends core "manual" class.
If someone know good policies in this area, please comment.
Some code linters use the annotation to skip generated code. For example, it doesn't make sense to calculate cyclomatic complexity on generated code.
Related
Is there a way to add to a description in a methods quick documentation? I have some methods I created that I plan to use later down on the line and want to add to its quick documentation to remind myself what the method is for in case I forget, without having to go into the method itself to read comments describing what the method does.
Is there a way to add to a description in a methods quick documentation?
The best way to document your methods is giving them (and their parameters) meaningful names.
Comments should not repeat what the code expresses itself. But no generator will ever look into your head to extract your intention from there. It rather will analyze the code and build the comment based on what's already written.
Therefore (meaningful) comments cannot be generated.
There are two valid reasons why you should write comments (yourself):
Interfaces
Interfaces need (JavaDoc) comments to explain the contract behind the method, to express the callers expectation as a help for the implementer.
odd ball solutions
Is there something in your code done in an unusual way?
Then add a comment why you did it so.
There might also be comments for legal reasons e.g. copyright marks, license texts and alike. But there should not be any other comment then this, especially nothing generated.
If you want to put comments in a single place for an entire project, or keep comments co-located with a set of files, try using a README. These are usually written in Markdown for easy conversion to beautifully formatted HTML for easier reading. Try an online markdown editor.
With reference to the following link, I have created the classes at run time, http://blog.javaforge.net/post/31913732423/howto-create-java-pojo-at-runtime-with-javassist. Now I need to view the created class that means Where will it create the class file? Is it possible to save it on disk/work space?
You can call cc.writeFile() right before or right after you call cc.toClass() to store a class file containing the bytecode of the generated class.
I don’t know of an equivalent operation to get a source file, however, you may consider the fact that you are actually generating the source code already (at least for the methods) and passing it to Javassist’s CtClass in order to be compiled.
So it’s not that hard to use the same code to generate the source code for an entire class as you only need to concatenate these methods, add field declarations and enframe it with a class body. After all, generating a source file means just writing a text file in a format that you already know very well…
The process of taking a java object and writing it to a text-like file is called serialization. The language has good built in support for this.
Oracle's documentation for these features can be found here and a tutorial here.
In general it's pretty easy to use and well understood and provides some clever features including the ability to detect if one version of a program saved the record but an incompatible version is trying to load it.
Also this stack overflow question will be useful to you.
Why would you want do do that? It's possible to create files from Pojos, then youll have to follow this tutorial:
http://www.mkyong.com/java/how-to-write-an-object-to-file-in-java/. But then you'll only write the contents of the fields to a file.
So, I have a large project that serializes many things when saving a configuration, and had to do a re-design of a large section of it. Since I had already defined the serialVersionUID field for a lot of classes, I wanted to know which files I needed to re-calculate the UID for.
I couldn't find any post on SO about what properties of a class were used in the calculation of the serialVersionUID (via ObjectStreamClass.lookup(classname) ). I finally found the spot in the spec that defines it. So, this is more of one of those self-answering questions for the sake of saving this small piece of knowledge.
If this is out-of-etiquette (since it is a spec question) please let me know, I'll gladly remove it or whatever is SO-appropriate.
So, what particulars of a class are used when using the Java-built-in algorithm of calculating a serialVersionUID?
It's detailed right here in the Java spec!
http://docs.oracle.com/javase/6/docs/platform/serialization/spec/class.html#4100
Does anybody know if it's different based on different implementations/utilities? (Such as via ObjectStreamClass.lookup vs. serialver utility?)
Not sure if the title is the most descriptive way of putting it, but it's about as descriptive as I could think of.
Anyway, onto the question. I want to know how I can find similarities in bytecode. What I mean by this is rather difficult to properly explain (at least for me), so I will give an example instead.
I have aba.class, and nhf.class. These classes are obfuscated classes from a game I made. I offer a modified version of this game which simply has some small code changes in some places, but because the game is for sale it gets reobfuscated every time there is a new update. I want to be able to tell what class has changed to what in the reobfuscation by checking how similar the bytecode is for the classes. I know this is possible, but I have no idea how to check how to do this.
Is there a library, program or something that can parse bytecode and check how similar it is, or would I have to write this myself? If I would have to write it myself, I would appreciate someone to point me in the right direction (or link me to something that might help, etc).
Also, I'm looking at doing this with code, rather than manually, in case that wasn't apparent.
There can be a simpler solution:
I don't know what obfuscator you use (maybe Proguard), but it probably generates a map that maps obfuscated classnames to non-obfuscated classnames. (If not, you can switch to Produard, which generates such map.)
So, you can translate obfuscated classnames to original classnames (and vice versa) provided that you have the map for the version.
So, you can make such map from these two maps by matching original classnames.
Is there any diff tool specifically for Java that doesn't just highlight differences in a file, but is more complex?
By more complex I mean it'd take 2 input files, the same class file of different versions, and tell me things like:
Field names changed
New methods added
Deleted methods
Methods whose signatures have changed
Methods whose implementations have changed (not interested in any more detail than that)
Done some Googling and can't find anything like this...I figure it could be useful in determining whether or not changes to dependencies would require a rebuild of a particular module.
Thanks in advance
Edit:
I suppose I should clarify:
I'm not bothered about a GUI for the tool, it'd be something I'm interested in calling programmatically.
And as for my reasoning:
To workout if I need to rebuild certain modules/components if their dependencies have changed (which could save us around 1 hour per component)... More detailed explanation but I don't really see it as important.
To be used to analyse changes made to certain components that we are trying to lock down and rely on as being more stable, we are attempting to ensure that only very rarely should method signatures change in a particular component.
You said above that Clirr is what you're looking for.
But for others with slightly differet needs, I'd like to recommend JDiff. Both have pros and cons, but for my needs I ended up using JDiff. I don't think it'll satisfy your last bullet point and it's difficult to call programmatically. What it does do is generate a useful report for API differences.