We need an accurate diff utility for Java and Javascript files, written in Java. It should be invokable from within an Eclipse (version 3.2 or 3.3) application. Preferably we need the Java source code for this utility also.
The utility should be able to compare two files (old and new, say) and determine the following accurately:
Number of LOC added to the new file
Number of LOC deleted from the old file
Number of LOC changed in the old file
Number of change deltas, i.e., contiguous blocks of code added/changed/deleted.
Eclipse has a very good diff/compare plugin installed by default. Have you looked into using and/or extending that (it's opensource)? I would not think that adding some statistics reporting to the existing plug-in would be all that difficult, though sometimes plug-in development (even just simple extension) can be deceiving.
Good luck.
See Diffj.
I needed a Java diff implementation and found this: http://javacook.darwinsys.com/javasrc/textproc/Diff.java which I adapted.
Related
In Java, I often see JAR files named with the version number of the software (jsoup-1.11.2.jar), while others are not (freemarker.jar).
Is this just a best practice/convention, or is there some functional reason for it?
Simple answer: no, this is purely a convention.
Obviously, tooling that checks versions can do that easily when version numbers are hard-coded like this. But there is no generic (like jvm based) tool relying on it.
And beyond that - sometimes this scheme is even counter productive. In our self grown build setup we have to always remember to update the build scripts after replacing JAR files - because a new version changes the file name (because version part of the file name).
Having the version in the name of the file allows you to quickly determine which of the n files you have is the latest. Also if you have no way of determining what the version is from within the program it can be helpful.
My team inherited a system to support and develop and it's mostly created in IBM Process Designer with some functionality coming from external Java classes.
Documentation is missing or incomplete (what a surprise!) so I need to make some kind of "architecture map" for further refactoring based on the existing implementation.
So the question is: what's the best way to find and list all calls to Java integration components (ideally, to all Java methods) in IBM PD? Going process by process manually is a big troublesome because solution is rather complex.
Found the solution:
If you go to Snapshots in Process Center you can export Installation Package to local machine. Unzip it, then unzip export.twx and in Objectss folder you'll find XML representation of all objects.
Search for 'javaClassName' string and you'll get the list.
Unfortunately I had to use this workaround because default tab "Where is used" in PD did not provide any information.
I'm trying to create a process to patch our current java application so users only need to download the diffs rather than the entire application. I don't think I need to go as low level as a binary diff since most of the jar files are small, so replacing an entire jar file wouldn't be that big of a deal (maybe 5MB at most).
Are there standard tools for determining which files changed and generating a patch for them? I've seen tools like xdelta and vpatch, but I think they work at a binary level.
I basically want to figure out - which files need to be added, replaced or removed. When I run the patch, it will check the current version of the software (from a registry setting) and ensure the patch is for the correct version. If it is, it will then make the necessary changes. It doesn't sound like this would be too difficult to implement on my own, but I was wondering if other people had already done this. I'm using NSIS as my installer if that makes any difference.
Thanks,
Jeff
Be careful when doing this--I recommend not doing it at all.
The biggest problem is public static variables. They are actually compiled into the target, not referenced. This means that even if a java file doesn't change, the class must be recompiled or you will still refer to the old value.
You also want to be very careful of changing method signatures--you will get some very subtle bugs if you change a method signature and do not recompile all files that call that method--even if the calling java files don't actually need to change (for instance, change a parameter from an int to a long).
If you decide to go down this path, be ready for some really hard to debug errors (generally no traces or significant indications, just strange behavior like the number received not matching the one sent) on customer site that you cannot duplicate and a lot of pissed off customers.
Edit (too long for comment):
A binary diff of the class files might work but I'd assume that some kind of version number or date gets compiled in and that they'd change a little every compile for no reason but that could be easily tested.
You could take on some strict development practices of not using public final statics (make them private) and not every changing method signatures (deprecate instead) but I'm not convinced that I know all the possible problems, I just know the ones we encountered.
Also binary diffs of the Jar files would be useless, you'd have to diff the classes and re-integrate them into the jars (doesn't sound easy to track)
Can you package your resources separately then minimize your code a bit? Pull out strings (Good for i18n)--I guess I'm just wondering if you could trim the class files enough to always do a full build/ship.
On the other hand, Sun seems to do an okay job of making class files that are completely compatible with the previous JRE release, so they must have guidelines somewhere.
You may want to see if Java WebStart can help you as it is designed to do exactly those things you want to do.
I know that the documentation describes how to create and do incremental updates, but we deploy the whole application as it changes very rarely. It is then an issue of updating the JNLP when ready.
How is it deployed?
On a local network I just leave everything as .class files in a folder. The startup script uses robocopy or rsync to copy from network share to local. If any .class file is different it is synced down. If not, it doesn't sync.
For non-local network I created my own updater. It downloads a text file of md5sums and compares to local files. If different it pulls file down from http.
A long time ago the way we solved this was to used Classpath and jar files. Our application was built in a Jar file, and it had a launcher Jar file. The launcher classpath had a patch.jar that was read into the classpath before the main application.jar. This meant that we could update the patch.jar to supersede any classes in the main application.
However, this was a long time ago. You may be better using something like the Java Web Start type of approach, which offers more seamless application updating.
I have one GUI with one list box to display the list of methods in the class.
I can achieve it using reflection.
But can I view the source code in another text area on selecting the method name?
I knew about decompilers. but I don't want to see source code in their window.
I want to use some thirdparty lib so that I can see the source code of specific method in my own GUI.
Please suggest if there is an API available for this.
You will need a decompiler of some sort, that you can link to. I am not sure there are any libraries, but here's a link to the JD Java Decompiler.
Remember that you lose variable names and such during compilation, so if you decompile the resulting source code may be less readable.
If you have access to the source you could link it to the class files, and find the chosen method source in the source files linked. This can be achieved by a simple one-pass parse of the source files.
Your biggest problem will be determining when a method ends, and a simple solution is to count {'s and }'s and determine when the { of the method declaration is closed.
This is an old question, but seeing as the decompiler landscape has changed significantly in the past year, I feel it's worth resurrecting.
Procyon is an open source framework that contains, among other things, a Java decompiler. It is written in Java, and the decompiler APIs can be integrated into another application fairly easily. In fact, there are already two third-party GUI front-ends, including the SecureTeam Java Decompiler.
CFR does not have source code available yet, but it is also an excellent decompiler. It too is written in Java, and while I have not tried to integrate it with an existing application, it should certainly be possible.
I once created application that included it's own source code viewer. I think it's a good alternative to decompilers, which can come with quite dependencies.
I was using NetBeans so packaging the .java files was as easy as changing one filter option. I checked java properties to find the jar file and scanned it just as any zip file for java source files. With this approach having a GUI with JTreeTable populated with source files and JTextArea displaying source code was trivial.
I believe You could do the same with addition of one step more - clipping the source to contain only the selected method. I think it should boil down to simple parser, one that counts opening and closing brackets.
I'm leaving the earlier answer up in case you need it, but JODE hasn't been updated in a long time. Searching around, I can't find any decompiler that is open-source or available in library form.
JODE may be just what you want. The core decompiler is released as a library under the GNU LGPL, so you can integrate it into your program with no issues.
I am working with a large Java web application from a commercial vendor. I've received a patch from the vendor in the form of a new .class file that is supposed to resolve an issue we're having with the software. In the past, applying patches from this vendor have caused new and completely unrelated problems to arise, so I want to understand the change being made even before applying it to a test instance.
I've got the two .class files side by side, the one extracted from the currently running version and the updated one from the vendor. JAD and JReversePro both decompile and disassemble (respectively) the two versions to the same output. However, the .class files are different sizes and I see differences in the output of od -x, so they're definitely not identical.
What other steps could I take to determine the difference between the two files?
Conclusion:
Thanks for the great responses. Since javap -c output is also identical for the two class files, I am going to conclude that Davr's right and the vendor sent me a placebo. While I'm accepting Davr's answer for that reason, it was Chris Marshall and John Meagher who turned me on to javap, so thanks to all three of you.
It's possible that they just compiled it with a new version of the java compiler, or with different optimization settings etc, so that the functionality is the same, and the code is the same, but the output bytecode is slightly different.
If you are looking for API level differences the javap tool can be a big help. It will output the method signatures and those can be output to a plain text files and compared using normal diff tools.
You could try using a diff tool (such as SourceGear's free DiffMerge tool) on the decompiled sources. That should pick up the file differences, although it will likely pick up "insignificant" differences, for example if variables have been named differently in the two versions.
http://www.sourcegear.com/diffmerge/
You can use javap (in $JDK_HOME/bin) to decompile java .class files. It will tell you (for example) the class file version among other things