I am currently working on a program which compares two control - flow graphs with each other(the graphs are generated with Soot). These graphs belong to two different classes; so one cfg for each.
Currently I am using the following to load classes:
SootClass sClassNew = Scene.v().loadClassAndSupport("Calc");
sClassNew.setApplicationClass();
SootClass sClassOld = Scene.v().loadClassAndSupport("Calc2");
sClassOld.setApplicationClass()
This works if I add a folder with classes Calc.java and Calc2.java by right-clicking on the project | Java Build Path | Add External Class folder| choose the folder.
Unfortunately this is not exactly what I want since:
The two classes will have the same name since they are different versions of each other. In other words, one class is an updated version of the other.
When the program is executed, I want to make the user capable of choosing the files so that a cfg is built. Therefore, I must eliminate the above steps so as to add the classes and need a way to add them at run-time.
An important note is that Soot will only load files from JAR files and directories found on Soot's classpath.
Does anyone have an idea how I can solve problems these two problems please?
Soot is not really set up to deal with this. It's main data structure is the Scene, in which it holds all classes it reasons about and the scene can only hold exactly one class instance per class name - there can be no two different versions.
Having said that, we have recently built an extension to Soot called Reviser (currently under submission): https://github.com/StevenArzt/reviser
Reviser incrementally updates a program's inter-procedural control flow graph and the induced IFDS/IDE analysis information. To make this work, we had to poke around with Soot's class-loading mechanism quite a bit, though; this is far from trivial. If you are interested in the details please send a personal mail to Steven Arzt and myself.
Related
I'm trying to implement a jBPM6 project containing both processes and rules.
One thing I would like to achieve (if it is possible) is to develop a separate artifact containing only the rules definitions, and then referencing this jar into the processes' project via maven, being able to execute the rules from my processes.
I implemented this solution, but when I execute one of the process that uses the rules none of the rules is fired. To verify that there were no implementation problems I put the rules definition files into the processes' project directly, and it worked in this way.
So, it is like the system is not able to load the rules definitions when they are contained into another jar archive. Does anyone knows how to solvemy problem, and if what I want to achieve is even possible in jBPM6? Thank you very much.
I have tried with repository1 and its working fine. I can see global variables are accessible across different projects. Go through repository1
This question already has answers here:
Is the use of Java's default package a bad practice?
(3 answers)
Closed 6 years ago.
I'm pretty new to Java, and I know what packages do. You use them to sort multiple files of a Java application together. However, is it standard to put it in a package if your application only has a single class? What are the pros and cons of doing this?
EDIT: I'm packaging this single class into a .jar file after.
From oracle documentation, it is clear that
The primary motivation for jar development was so that Java applets
and their requisite components (.class files, images and sounds) can
be downloaded to a browser in a single HTTP transaction, rather than
opening a new connection for each piece. This greatly improves the
speed with which an applet can be loaded onto a web page and begin
functioning. The JAR format also supports compression, which reduces
the size of the file and improves download time still further.
Additionally, individual entries in a JAR file may be digitally signed
by the applet author to authenticate their origin.
From Package Documentation of Oracle,
For small programs and casual development, a package can be unnamed
(ยง7.4.2) or have a simple name, but if code is to be widely
distributed, unique package names should be chosen using qualified
names. This can prevent the conflicts that would otherwise occur if
two development groups happened to pick the same package name and
these packages were later to be used in a single program.
It really depends on how you're compiling and running the program, but ultimately it's your choice.
Let's have a look at some of the different ways you might build your program.
1. Compiling the file with javac
If you're compiling the file using javac then the package will not matter. It will generate the .class file the same directory as the source file.
2. Compiling to a JAR File
If you're compiling to a JAR File, then the .class file will be inside the directories specified in your package name. Although this would not affect how the program is ran.
In both of these cases, I'd say that the package identifier is unnecessary for a single-file program. However, there is an exception.
The exception...
If ever you plan to use the class in a larger program, then adding a relevant package name would be essential.
This is because it would...
Prevent name collisions when other classes in the default packages have the same name.
Help people know whether or not your class is the one they want.
Can you imagine if 20 different developers made a List class in the default package, and somehow they all ended up in a project? It would be chaos! How would I choose the right List?
So in the case of writing a class that others will use in their own projects, you should definitely use package names.
It is probably non-production application if it has a single class and doesn't have any dependencies or resource files. So it is completely up to you how you will start your app.
If you want to distribute your app - make it in compliance with the standards, put it in a jar, publish to maven...
Java classloaders identify your classes by concatenating the package and the class name. So, if you don't use packages, the probabilities of name collisions are higher. Even though your app consists of only one class, you're going to reference many others, explicitly or not.
Also consider that you'll only be able to build very trivial applications with only one class, so probably that condition won't last forever.
Besides that, a class without package is a border case, so you'll probably find many tools that don't work with it.(I had this problem with the Web Service builder tool for Eclipse).
In short, use a package. It won't cause you any trouble, and (at least potentially) will save you many.
I wrote two jars. Each one of them is responsible for sending different http/https request.
Each one of them uses, naturally, certain same classes. Like the ones that builds the requests or send them. The process might be a bit different, but still the general structure and classes names are the same.
Building different jars per request is a requirement from my managers! So using 1 jar for all my http requests is not acceptable.
Now, in my client program I need to send a request one time for JarA and one time from JarB. But compilation fails because, naturally, I am using very similar namings for the classes and methods.
For example, I have a UserData class in both jars. So when I try to use it in my client program, the compiler yells: "reference to SystemData is ambiguous".
I can start improvising specific classes names for each jar, but it is ugly...
How would you suggest to solve this problem?
If the classes are identical, pull them out into a third JAR and then have the client program reference the common JAR plus JarA or JarB.
If the classes are similar but not identical, then put them into different packages. You can have classes with the same names if they're in different packages.
Put common classes in a third jar and either bundle it in the two http jars or add it to the classpath at runtime (which is the best choice will depend on how you're deploying, etc.).
Firstly you have to decide which kind of architecture you are working with.
If managers asking you to have different jar's for sake of modularization - sure it's worth to make common jar which will contain all common classes.
I suppose you should have your project built with Maven, Gradle or another build system which will help you managing dependencies.
Another issue could be if you are supposed to do 'Microservices' architecture. Then code duplication is inevitable.
To overcome same class names when you have duplication - I would recommend to have for every module different package names then.
Use a build system like maven where one can have library dependencies, to a common third jar. It maintains a repository of versioned jars.
One solution is that - if you see a same class with same package in two different jars and both jars are required in your project,
Solution
you can download the source code of that duplicate class and creat keep the same in your project with package structure. So this way JVM loads your project classes first and give first preference to invoke your project class rather then other jar's class
We want to use Rascal to find all unused public methods in a collection of Java projects in an Eclipse workspace. I have just learned how to create a model of a Java project in Eclipse using createM3FromEclipseProject and navigate that. But this takes only one project into account. How do I perform this analysis across all Java projects in my workspace?
Excellent question. You extract the models from each project, given the right Eclipse compiler settings and everything, then you can merge the models to get an overarching model:
import lang::java::m3::Core;
M3 composeJavaM3(loc id, set[M3] models) // the function to call
This will allow you to do a cross project analysis on the resulting M3 model.
There are some caveats, namely if the same qualified class name exists in both projects but they are in fact different classes then the compose function will map them onto each other. To fix such issues you would first have to do some preprocessing (see the link function), but we have yet to get experience in that.
If you are comfortable programming in Rascal, you could do the following:
Create a java function in rascal that gets the set of projects in the workspace as a set of locations. The locations need to be in the |project://project_name| format and the projects need to be accessible.
Create a rascal function that iterates over the set, creating the models using createM3FromEclipseProject and then composing them using composeJavaM3 into a single model to perform the analysis on.
If not, you can create an issue here and we could add it to an unstable build. This hasn't been added because of the caveats mentioned below.
When writing code in an Eclipse project, I'm usually quite messy and undisciplined in how I create and organize my classes, at least in the early hacky and experimental stages. In particular, I create more than one class with a main method for testing different ideas that share most of the same classes.
If I come up with something like a useful app, I can export it to a runnable jar so I can share it with friends. But this simply packs up the whole project, which can become several megabytes big if I'm relying on large library such as httpclient.
Also, if I decide to refactor my lump of code into several projects once I work out what works, and I can't remember which source files are used in a particular run configuration, all I can do it copy the main class to a new project and then keep copying missing types till the new project compiles.
Is there a way in Eclipse to determine which classes are actually used in a particular run configuration?
EDIT: Here's an example. Say I'm experimenting with web scraping, and so far I've tried to scrape the search-result pages of both youtube.com and wrzuta.pl. I have a bunch of classes that implement scraping in general, a few that are specific to each of youtube and wrzuta. On top of this I have a basic gui common to both scrapers, but a few wrzuta- and youtube-specific buttons and options.
The WrzutaGuiMain and YoutubeGuiMain classes each contain a main method to configure and show the gui for each respective website. Can Eclipse look at each of these to determine which types are referenced?
Take a look at ProGuard, it is a "java shrinker, optimizer, obfuscator, and preverifier". I think you'll mainly be interested in the first capability for this problem.
Yes it's not technically part of Eclipse, as you requested, but it can be run from an Ant script, which can be pretty easily run in Eclipse.
I create more than one class with a main method for testing different ideas that share most of the same classes.
It's better to be pedantic than lazy, it saves you time when coding :-)
You can have one class with a main method that accepts a command-line argument and calls a certain branch of functionality based on its value.