I want to comment out a few lines of a .class file. I do not have the source file, but when I decompiled that file, I found that it is trying to import non-existing classes and this leads to errors and exception. So, I wanted to comment out those troublesome lines to remove the cause of the errors. As far as I know comments are just removed in the .class file. How can I remove a command line in the .class file?
A classfile is a binary file format. There is no notion of comments at the classfile level. For that matter, there is no notion of imports either. You can just reference any class you want and the JVM will load them as needed.
It sounds like what you are actually trying to do is to edit a classfile for which you do not have the source, and you are failing because the decompiled code results in compiler errors. Apart from the issue of not having the source for the dependencies, this is not unexpected because compilation and decompilation are both lossy processes. You can't expect to be able to roundtrip classes through a decompiler in general.
One option is to edit the classfile directly at the bytecode level, using an assembler/disassembler pair such as Krakatau. Krakatau can roundtrip any valid classfile to a human readable assembly format and back. This lets you edit classfiles without having to worry about compilation errors or missing dependencies, or any other similar issues. The downside is that it requires you to understand Java bytecode and the classfile format.
Related
I'm wresting with SonarQube reporting errors on C# files which I didn't write. For example, I might import a particular piece of code from an open source library where I didn't want to take the entire library as a dependency.
This usually raises a lot of SQ warnings.
Instead of dealing with these one by one, is there a way to just mark the entire file to be ignored? I'n thinking something similar to the new #nullable disable directive.
Thanks very much.
Yes, there is way to remove or better to say exclude the particular files from being analysed by sonarqube.
You can use the sonar.exclusionswhich is a sonar analysis parameter, using this parameter you can exclude files or folders.
Here is the article from sonarqube on this https://docs.sonarqube.org/latest/project-administration/narrowing-the-focus/
In my project, I want to get rid of tons of empty and pointless cpp files for interfaces in IBM Rational Rhapsody.
Setting CPP_CG:File:Generate to Specification yields only header file generation of a class, which is almost what I want. But, the makefile (gpj) still looks for the *Ifc.cpp file. Is there a straight way to exclude these cpp files from makefile?
There is an option CG::File::AddToMakefile which does only work for component files. I found some info that it was working before but with Rhapsody 8, it stopped working.
You should be able to force the suppression of the either header or implementation file of the interface using those properties. However!
Rhapsody expects to find the cpp file of the interface and suppressing it will cause problems with roundtrip function - Roundtrip doesn't just occur explicitly, it will also trigger implicitly by default when you save the project or change focus from code editor to model browser.
During this roundtrip, Rhapsody will try to "fix" the model by replacing the missing cpp file. This will be followed by roundtrip error messages. Disregarding the errors and continuing with roundtrip will probably cause duplicate elements and all sorts of mess.
In other words, what you're trying to do is not really supported and is a bad idea.
I wonder what is the best practice for protocol buffer regarding source repository (e.g. git) :
Do I have to put ONLY the .proto file in the repository and let anyone else who uses the source code to regenerate classes code with protoc compiler ? or is it a best pratice to put both .proto files AND source code generated by protoc compiler ?
You should never check in generated code if you can avoid it.
If you check in generated code, you take on multiple risks, such as:
You risk losing the knowledge of how to correctly regenerate that code. If it's not automated as part of the build, it's too easy to forget to document, or to have the documentation be wrong.
You risk the generated code getting out-of-sync with the schema. For example, someone could make a change to the .proto file but forget to update the generated code. Their changes won't actually "take effect" until someone else later on regenerates the generated code for some other reason -- and then all of the sudden they see side effects they weren't expecting.
Your generated code might be for a different version of protocol buffers than what the builder has installed. In this case it won't work correctly, since it's necessary to use the exact same version of the compiler and runtime library.
If for some reason you absolutely have to check in generated code, I highly recommend creating an automated test that checks if the checked-in code matches what protoc would generate if run fresh. (For example, the protobuf repository itself contains checked-in copies of generated code for descriptor.proto because this code is needed to compile protoc, creating a circular dependency. But there is a unit test that checks that the checked-in code matches what protoc would generate.)
If your project is commonly used in its source code form (e.g. a library or a program every user is supposed to compile himself), I would make available release packages that have the generated files.
But I wouldn't put the generated files into the repository directly. And if most users will use a compiled binary, it is not that important to provide easy-to-compile source packages either. The protobuf generator then becomes just another build dependency.
I have a 20+ yo .dll, written in C that none of my colleagues want to touch. With good reason, it uses macros, macro constants and casting EVERYWHERE, making the symbol table quite lean.
Unfortunately, I have to sometimes debug this code and it drives me crazy that it doesn't use something as simple as enums which would put symbols in the .pdb file to make debugging just that little bit easier.
I would love to convert some of the #defines to enums, even if I don't change the variable types as yet, but there is a genuine fear that it will cause possible issues in terms of performance if it were to change the code generated.
I need to show definitively, that no compiled code changes will occur, but it would seem that the .dll is actually changing significantly in a 64 bit build. I looked at one of the function's disassembly code and it appears to be unaffected, but I need to show what is and is not changing in the binary to alleviate the fears of my colleagues as well as some of my own trepidation, plus the bewilderment as to why any changes would propagate to the .dll at all, though the .dlls are of the same size.
Does anyone have any idea how I could do this? I've tried to use dumpbin, but I'm not that familiar with it and am getting some mixed results, prolly because I'm not understanding the output as much as I like.
The way I did this was as follows:
Turn on /FAs switch for project.
Compile that project.
Move the object file directory (Release => Release-without-enums)
Change #defines to enums
Compile that project again.
Move the object file directory (Release => Release-with-enums)
From a bash command line. Use the command from the parent of the Release directory:
for a in Release-without-enum/*.asm; do
git diff --no-index --word-diff --color -U10000 $a "Release-with-enum/$(basename $a)";
done | less -R
The -U10000 is just so that I can see the entire file of each file. Remove it if you just want to see the changes.
This will list all of the modifications in the generated assembly code.
The changes found were as follows:
Symbol addresses were moved about for apparently no reason
Referencing __FILE__ seems to result in not getting a full path when using enums. Why this would translate to removing the full path when using enums is a mystery as the compiler flags have not changed.
Some symbols were renamed for apparently no reason.
Edit
2 and 3 seem to be caused by a corrupted .pdb error. This might be due to the files being used in multiple projects in the same solution. Rebuilding the entire solution fixed those 2 problems.
I have found that when creating a .tar.gz archive with the maven assembly plugin, the timestamps of the files being archived are not being preserved. Instead they are stamped with the time of archive creation. This is not the way tar behaves.
I could not find any documentation about this on the maven site and I'm surprised it isn't mentioned more.
Or am I missing something obvious?
I did a quick overview of the plugin source code and while I may be missing something, it seems like the source is all oriented around inclusion/exclusion and directory management with some provision made for permissions. All the file copying methods filter down to a stream copy and I'm betting that once the file is opened into a stream they've forgotten all the file attributes such as timestamps, and thus cannot reproduce them.
I hope I'm wrong.
Failing that, how else might I preserve timestamps while operating in a maven environment?
UPDATE:
A Jira issue was opened on this.
It turns out that timestamps generally are preserved by the plugin, unless you specify the <lineEnding> tags. These are implemented by a routine within the plugin that reads the original file, converts the line endings, and writes a new file. It is apparently not easy to preserve the original date in this case. They make no promises of a quick fix but some possible approaches to fixing it were discussed.