I need to extract some specific functionality from a large legacy Java codebase, in order to turn it into a standlone command-line application. This code is not documented at all and is not very modular or even clear. So I'm having a really hard time figuring out what I need to keep.
Basically what I need is a a dependency tree, listing all the direct or indirect dependencies of this one *.java file. (Preferably I would like this listing to be in a format that I can save to a text file, as opposed to some un-copy-able whiz-bang GUI tree with a bazillion collapsed nodes...)
I'm using Eclipse for this detective work. I am an Eclipse beginner, but I figure that there may be Eclipse tricks/tools to perform this kind of operation with a bit less effort.
Any suggestions (using Eclipse or otherwise) would be appreciated.
There's a free version of eUML2: http://www.soyatec.com/euml2/features/eDepend/, one of its features is exactly what you need. Also another one, i'm not sure if eUML can export any text files.
Here is a kind of detailed guide installing eUML2.
I've used Dependency Finder for this kind of work recently and it works well.
You can make use of the Java doc generation functionality to be able to generate a java doc that in this case will not contain much information about the methods but will give you an idea of which classes extend which classes, interfaces and such, resulting in a sort of a dependency tree.
Related
I'm trying to figure out how to use Soot in an existing project (a metacircular interpreter). Specifically, I want to use Soot to convert java bytecode into a convenient 3-address code (either Jimple or Shimple) that I can interpret. I may want to do more things later, but for now I just want the conversion.
What's the best way to perform this translation? Soot seems like a ginormous project which as tons of functionality, but I really only need a single method
compileClass: Byte[] -> ShimpleClass
Preferably as pure as possible (i.e. no setup/teardown required, everything packaged within that method). I've spent hours going over the javadoc/papers/presentations, but most of them seem focused on usage as a command line tool or an eclipse plugin. Could anyone give me some pointers as to where to start?
This is probably easiest answered on the Soot mailing list.
Soot is set up to load .class files from the file system but it should not be that hard to instruct it to load something from a ByteArrayInputStream as well. I guess that should help you in your case.
I'm writing an applet, which uses ~10 external libraries. Together they occupy more than 2 megabytes. In some libs we use only 1-2 classes, so a lot of others can be safely deleted. So the question is how to remove unused classes from jar libraries?
A lot of other questions link to Proguard. But it doesn't process libraries (or I am doing something wrong) and also ruins parts of code which use reflection.
You could use the maven-shade-plugin and tell it to build a minimized jar file that combines your code and libs.
You could use something like ClassDep, which statically identifies which classes you will use.
However it's possible to easily fool this. Imagine some of your code contains:
Class.forName(className);
so you can dynamically build a classname and load that class. Tools like ClassDep can't identify these cases, so you'd need to perform comprehensive testing on your shrunken jars.
ProGuard can process your code together with the libraries (with the option -injars). You can still keep external libraries that you don't want to process (with the option -libraryjars).
Any automatic shrinking tool will have problems with reflection. ProGuard recognizes some basic reflection and it allows you to specify the parts of the internal API that should be preserved for the sake of reflection. ProGuard supports some powerful configuration, but depending on the amount of reflection in the libraries, it may still require trial and error.
You can simply "unzip" the JAR's, take only the classes you want from each, and place them in a custom archive. Brian A. gave a good suggestion on how to identify those classes and some caveats. I would add they you may be violating licenses as well...
There are few open source projects/APIs/libraries that we use in our project (Spring, Struts, iBatis etc.) and I want to understand their design and how they work internally.
What is the best way to understand these projects? Note that I am already using these libraries in my project. And I know the input-output interaction/configurations for these libraries. What I don't understand is how these APIs/libraries work internally.
The problems I face is:
Finding the entry class of the library. Is there any way I can know the entry class for the library - something which is kicking the whole API?
Tools/Plugins to use in Eclipse to get an overview of the design of the library. Going through each and every class of the library, can be a very daunting task. Is there any tool you would like to recommend which can generate the class diagrams of the API in Eclipse.
Thanks in advance!!
UPDATE: I need some inputs on eclipse plugins which can help me in getting an overview/class diagram of the library
I always use the same strategy for this: I never try to "understand" the code base as a whole, and I usually try to follow the request flow. I read enough of the documentation to determine what is necessary to use the application, and I read that code (Keep all source code loaded in your IDE).
For example, in struts you'll be installing a servlet filter in web.xml. Start reading the filter and follow the path a single request takes through your stack.
Likewise for spring, there are two main entry points, the filter and "getBean", both of which are mentioned real early in the documentation. Read those two.
For both of these cases you'll find one or two classes that represent the "core" of the framework real quickly. Read those really well and let actual use cases & needs drive your further exploration.
Approaching "understanding" of an open source library (or any other code base for that matter) by trying to find all the pieces is usually not a very good way of approaching these things, it will usually just lead nowhere because a lot of these things contain too much code. When following the request flow I find making diagrams can also be quite distracting, it tends to draw attention/focus away from understanding (and since my understanding increases rapidly most of them are out-of-date even before they reach the printer).
Nice question!!!, what I've done, specially in the case of Spring, apart from consulting the Documentation and their API's is to attach the sources of the project to my project on Eclipse, that way I'm able to navigate through the source code, not just the API. Its been quite helpful specially in the case of the Spring-Security project, there were some concepts that I just couldn't understand until I inspected the source code.
That's one of the advantages of using Open Source libraries.
Regards.
Tools like Structure101 (http://www.headwaysoftware.com/products/structure101/index.php), and Lattix (http://www.lattix.com/) let you analyze code and produce architecture diagrams / dependency matrices.
This is not exactly class diagram - the main focus is on layering. So the entry point is usually the topmost layer.
But then again, as I specified above, you will notice that some libs are just a mess, and these tools will not be helpful enough.
See the S101 online demo: http://www.structure101.com/java/
This for example is the Sonar project architecture: http://www.structure101.com/java/tracker/sonar/1.11.1/arch.html
Your best bet for those three would be to consult the official documentation (make sure you are looking at the version you are using) or to get a book on the technology.
Most APIs don't have a class with a main method; they're running in the webserver called by the server itself. Unless they're running as their own server, they won't have a main method.
It is possible to access bits of MATLAB's internal java code to programmatically change MATLAB itself. For example, you can programmatically open a document in the editor using
editorServices = com.mathworks.mlservices.MLEditorServices;
editorServices.newDocument() %older versions of MATLAB seem to use new()
You can see the method signatures (but not what they do) using methodsview.
methodsview(com.mathworks.mlservices.MLEditorServices)
I have a few related questions about using these Java methods.
Firstly, is there any documentation on these things (either from the Mathworks or otherwise)?
Secondly, how do you find out what methods are available? The ones I've come across appear to be contained in JAR files in matlabroot\java\jar, but I'm not sure what the best way to inspect a JAR file is.
Thirdly, are there functions for inspecting the classes, other than methodsview?
Finally, are there any really useful methods that anyone has found?
There is no official documentation nor support for these classes. Moreover, these classes and internal methods represent internal implementation that may change without notice in any future Matlab release. This said, you can use my uiinspect and checkClass utilities to investigate the internal methods, properties and static fields. These utilities use Java reflection to do their job, something which is also done by the built-in methodsview function (I believe my utilities are far more powerful, though). In this respect, I believe we are not crossing the line of reverse-engineering which may violate Matlab's license.
If you are looking for documentation, then my UndocumentedMatlab.com website has plenty of relevant resources, and more is added on a regular basis so keep tuned.
I am also working on a book that will present a very detailed overview of all these internal classes, among other undocumented stuff - I hope to have publication news later this year.
I am an eclipse fan. If you use that as your IDE, the jar can be imported into one of your projects and you can inspect the methods in there.
To find out more about java objects, I use uiinspect.
The only place I know that is documenting the Matlab hidden Java stuff is Undocumented Matlab by Yair Altman. His site lists plenty of very useful tricks. Being able to use Java to format text in list boxes has come in very handy for me, for example.
EDIT
The man has spoken. Listen to him, since I don't think there's anyone outside MathWorks who knows more about Matlab's internal java code.
Undocumented Matlab is a great place to start looking.
I intend to develop a system that is entirely based on modules. The system base should have support for finding out about plugins, starting them up and being able to provide ways for those modules to communicate. Ideally, one should be able to put in new modules and yank out unused modules at will, and modules should be able to use each other's funcionality if it is available.
This system should be used as a basis for simulation systems where a lot of stuff happens in different modules, and other modules might want to do something based on that.
The system I intend to develop is going to be in Java. The way I see it, I intend to have a folder with a subfolder for each module that includes a XML that describes the module with information such as name, maybe which events it might raise, stuff like that. I suppose I might need to write a custom ClassLoader to work this stuff out.
The thing is, I don't know if my idea actually holds any water and, of course, I intend on building a working prototype. However, I never worked on a truly modular system before, and I'm not really sure what is the best way to take on this problem.
Where should I start? Are there common problems and pitfalls that are found while developing this kind of system? How do I make the modules talk with each other while maintaining isolation (i.e, you remove a module and another module that was using it stays sane)? Are there any guides, specifications or articles I can read that could give me some ideas on where to start? It would be better if they were based on Java, but this is not a requirement, as what I'm looking for right now are ideas, not code.
Any feedback is appreciated.
You should definitely look at OSGi. It aims at being the component/plugin mechanism for Java. It allows you to modularize your code (in so-called bundles) and update bundles at runtime. You can also completely hide implementation packages from unwanted access by other bundles, eg. only provide the API.
Eclipse was the first major open-source project to implement and use OSGi, but they didn't fully leverage it (no plugin installations/updates without restarts). If you start from scratch though, it will give you a very good framework for a plugin system.
Apache Felix is a complete open-source implementation (and there are others, such as Eclipse Equinox).
Without getting into great detail, you should be looking at Spring and a familiarization with OSGI or the Eclipse RCP frameworks will also give you some fundamental concepts you will need to keep in mind.
Another option is the ServiceLoader added in Java 1.6.
They are many way to do it but something simple can be by using Reflection. You write in your XML file name of file (that would be a class in reallity). You can than check what type is it and create it back with reflection. The class could have a common Interface that will let you find if the external file/class is really one of your module. Here is some information about Reflexion.
You can also use a precoded framework like this SourceForge onelink text that will give you a first good step to create module/plugin.