A little background, I'm hitting a situation where I haven't been able to enable assertions (asked here) and using a great solution like forceassertions is not possible for me because of this.
Assertions have always been a formidable weapon for us during the development and testing phase and we're not prepared to let it go.
That being the case, 2 options came into my mind.
The first, much like JUnit's Assert class:
Assert.assertTrue(result.financialInfoDTO.getPeriods().size() <= FinancialInfoConstants.NUMBER_OF_VISIBLE_PERIOD);
The second, trying to mimic Java's native assert keyword behaviour where we can enable or disable it:
Assert.assert(new Assertion() {
public boolean doAssert() { return result.financialInfoDTO.getPeriods().size() <= FinancialInfoConstants.NUMBER_OF_VISIBLE_PERIOD; }
});
I would like to have the luxury to enable and disable the assertion feature, which only solution I can think of is something like the later. What I am asking is, given most assertion would be comparing the size of collections and comparing values of some sort, would we better off using the first option or the later?
To put it in a more technical context, which is more efficient? evaluating simple expression or creating new objects in the heap all the time?
Object instantiation is usually more expensive. You can benchmark it yourself.
I will choose option 1.
It prevents from the creation of a new anonymous class and the
instanciation of this object each time you pass through your code.
With the second option you are accessing an object
(result) defined outside of your assertion class.
That's the first reason, don't you think that first one is more readable?
Related
Currently working on modifying big mapping classes and some new rules have appeared making me wonder what is the best option here.
Imagine a classic mapping function like so:
yyy.setType(xxx.getType);
yyy.setSomething(xxx.getSomethigElse);
yyy.setThisAsWell(xxx.getThatAsWell);
And I now have a condition to check, what would be better? (knowing that I won't have future similar condition checking to do):
final Boolean isRuleApplying = xxx.getRule == RULE;
yyy.setType(
isRuleApplying ? RULE_STUFF : xxx.getType
);
yyy.setSomething(
isRuleApplying ? RULE_STUFF_OTHER : xxx.getSomethigElse
);
yyy.setThisAsWell(
isRuleApplying ? RULE_STUFF_AGAIN : xxx.getThatAsWell
);
Or is it better to use the old if else?
if (xxx.getRule == RULE) {
yyy.setType(RULE_STUFF);
yyy.setSomething(RULE_STUFF_OTHER);
yyy.setThisAsWell(RULE_STUFF_AGAIN);
} else {
yyy.setType(xxx.getType);
yyy.setSomething(xxx.getSomethigElse);
yyy.setThisAsWell(xxx.getThatAsWell);
}
I feel that using ternary operation make it less maintainable and adds more complexity (checks everytime). But I wanted to get some other opinions.
Note: I have a bunch of try..catch so using if means duplicating those try blocks or adding an if in every block which kind of kills readability.
There's no absolute answer to this question. It depends.
With the ternary operator, you immediately see:
Three properties are always set to some value, and it's always the same properties, independent of the condition.
You see the two alternative values close to one another, so for a reader it's easy to compare them.
But there are some (many?) developers who arent't used to that operator (is that their fault or ours?), so using it might force them to look up its meaning instead of immediately understanding the code (to me, having a LISP background, the ternary operator always was as least natural as the if statement).
And it's true, with the ternary operator, you end up with three conditionals instead of one (but you should ignore these minor performance effects unless you find out that it really hurts in your application).
On the other hand, with the if statement, you immediately see:
It's just one condition that influences all properties.
You see the properties combinations for the two situations close together.
And even Java beginners will understand your code.
So, it depends on:
the Java fluency of your co-workers
whether you want to stress the different values for the single properties or the value-sets for the three properties.
And of course, all this isn't very object-oriented. If code structure and budget allow, maybe you could come up with a solution using polymorphism instead of the conditionals.
Edit 2:
Does a program with a fully object-oriented implementation give high performance? Most of the framework is written with full power of it. However, reflection is also heavily used to achieve it like for AOP and dependency injection. Use of reflection affects the performance to a certain extent.
So, Is it good practice to use reflection? Is there some alternative to reflection from programming language constructs? To what extent should reflection be used?
Reflection is, in itself and by nature, slow. See this question for more details.
This is caused by a few reasons. Jon Skeet explains it nicely:
Check that there's a parameterless constructor Check the accessibility
of the parameterless constructor Check that the caller has access to
use reflection at all Work out (at execution time) how much space
needs to be allocated Call into the constructor code (because it won't
know beforehand that the constructor is empty)
Basically, reflection has to perform all the above steps before invocation, whereas normal method invocation has to do much less.
The JITted code for instantiating B is incredibly lightweight.
Basically it needs to allocate enough memory (which is just
incrementing a pointer unless a GC is required) and that's about it -
there's no constructor code to call really; I don't know whether the
JIT skips it or not but either way there's not a lot to do.
With that said, there are many cases where Java is not dynamic enough to do what you want, and reflection provides a simple and clean alternative. Consider the following scenario:
You have a large number of classes which represent various items, i.e. a Car, Boat, and House.
They both extend/implement the same class: LifeItem.
Your user inputs one of 3 strings, "Car", "Boat", or "House".
Your goal is to access a method of LifeItem based on the parameter.
The first approach that comes to mind is to build an if/else structure, and construct the wanted LifeItem. However, this is not very scalable and can become very messy once you have dozens of LifeItem implementations.
Reflection can help here: it can be used to dynamically construct a LifeItem object based on name, so a "Car" input would get dispatched to a Car constructor. Suddenly, what could have been hundreds of lines of if/else code turns into a simple line of reflection. The latter scenario would not be as valid on a Java 7+ platform due to the introduction of switch statements with Strings, but even then then a switch with hundreds of cases is something I'd want to avoid. Here's what the difference between cleanliness would look like in most cases:
Without reflection:
public static void main(String[] args) {
String input = args[0];
if(input.equals("Car"))
doSomething(new Car(args[1]));
else if(input.equals("Boat"))
doSomething(new Boat(args[1]));
else if (input.equals("House"))
doSomething(new House(args[1]));
... // Possibly dozens more if/else statements
}
Whereas by utilizing reflection, it could turn into:
public static void main(String[] args) {
String input = args[0];
try {
doSomething((LifeItem)Class.forName(input).getConstructor(String.class).newInstance(args[1]));
} catch (Exception ie) {
System.err.println("Invalid input: " + input);
}
}
Personally, I'd say the latter is neater, more concise, and more maintainable than the first. In the end its a personal preference, but that's just one of the many cases where reflection is useful.
Additionally, when using reflection, you should attempt to cache as much information as possible. In other words employ simple, logical things, like not calling get(Declared)Method everywhere if you can help it: rather, store it in a variable so you don't have the overhead of refetching the reference whenever you want to use it.
So those are the two extremes of the pro's and con's of reflection. To sum it up if reflection improves your code's readability (like it would in the presented scenario), by all means go for it. And if you do, just think about reducing the number of get* reflection calls: those are the easiest to trim.
While reflection is most expensive than "traditional code", premature optimization is the root of all evil. From a decade-long empirical evidence, I assume that a method invoked via reflection will hardly affect performance unless it is invoked from a heavy loop, and even so there have been some performance enhancements on reflection:
Certain reflective operations, specifically Field, Method.invoke(),
Constructor.newInstance(), and Class.newInstance(), have been
rewritten for higher performance. Reflective invocations and
instantiations are several times faster than in previous releases
Enhancements in J2SDK 1.4 -
Note that method lookup (i.e. Class.getMethod) is not mentioned above, and choosing the right Method object usually requires additional steps such as traversing the class hierarchy while asking for the "declared method" in case that it is not public), so I tend to save the found Method in a suitable map whenever it is possible, so that the next time the cost would be only that of a Map.get() and Method.invoke(). I guess that any well-written framework can handle this correctly.
One should also consider that certain optimizations are not possible if reflection is used (such as method inlining or escape analysis. Java HotSpot™ Virtual Machine Performance Enhancements). But this doesn't mean that reflection has to be avoided at all cost.
However, I think that the decision of using reflection should be based in other criteria, such as code readability, maintainability, design practices, etc. When using reflection in your own code (as opposed to using a framework that internally uses reflection), one risk transforming compile-time errors into run-time errors, which are harder to debug. In some cases, one could replace the reflective invocation by a traditional OOP pattern such as Command or Abstract Factory.
I can give you one example (but sorry, I can't show you the test results, because it was few months ago). I wrote an XML library (custom project oriented) which replaced some old DOM parser code with classes + annotations. My code was half the size of the original. I did tests, and yes, reflection was more expensive, but not much (something like 0.3 seconds out of 14-15 seconds of executing (loss is about 2%)). In places, where code is executed infrequently, reflection can be used with a small performance loss.
Moreover, I am sure, that my code can be improved for better performance.
So, I suggest these tips:
Use reflection if you can do it in a way that is beautiful, compact & laconic;
Do not use reflection if your code will be executed many-many times;
Use reflection, if you need to project a huge amount of information from another source (XML-files, for example) to Java application;
The best usage for reflections and annotations is where code is executed only once (pre-loaders).
I am wondering a stupid question but well, I love to learn :)
Say I got the following code :
public String method(<T> a)
{
String dataA = a.getB().getC().getD();
}
At what point it becomes interesting to define a map which cache our requests and holds this :
Map<<T>, String> m;
m.put(a, dataA);
and then of course,
[SNIP the usual tests of nullity and adding the object if it is missing and so forth plus the refreshing issues]
return m.get(a);
Let me stress that the successive gets are NOT costy (no things such as DB calls, or JNDI lookups).
It's just that it's clearer if we define a dictionnary rather than read the whole string of "gets".
I consider that making a get call is NEARLY "free" in CPU time. Again, I suppose that retrieving the data from an hashmap is NOT exactly free but nearly (at least, in my case, it is :) ).
My question is really in terms of readibility, not performance.
Thanks !
To increase readability (and decrease dependencies), you should define an accessor in A, such as
public String getDataA() {
return getB().getC().getD();
}
Then your calling code becomes
String dataA = a.getDataA();
You may say that you would need too many such shortcut methods in A, cluttering its interface. That is actually a sign of a class design issue. Either A has grown too big and complex (in which case it may be better to partition it into more than one class), or the code needing all these far away pieces of data actually belongs to somewhere else - say into B or C - rather than to A's client.
A couple of things to consider:
Apache Beanutils has a lot of utilities for this sort of thing: http://commons.apache.org/beanutils/
java.util.properties, if the values are all strings
If you really want to access things like this you can also look at using groovy instead. All lookups on maps in groovy can be done with '.' notation and it also supports a "safe" accessor which will check for nulls.
MVEL is another option:
String d = (String) MVEL.eval("b.?c.?d", a);
I will say that data dictionaries lead to typesafety issues. There's no guarantee that everyone puts the right types in the right data elements, or even defines all the required elements.
Also, when using an expression language as above, there's also typesafety issues, as there's no compile time check on the actual expression to make sure that a) it makes sense, and b) it returns the right type.
Original Question: Given a method I would like to determine if an object returned is created within the execution of that method. What sort of static analysis can or should I use?
Reworked Questions: Given a method I would like to determine if an object created in that method may be returned by that method. So, if I go through and add all instantiations of the return type within that method to a set, is there an analysis that will tell me, for each member of the set, if it may or may not be returned. Additionally, would it be possible to not limit the set to a single method but, all methods called by the original method to account for delegation?
This is not specific to any invocation.
It looks like method escape analysis may be the answer.
Thanks everyone for your suggestions.
Your question seems to be either a simple "reaching" analysis ("does a new value reach a return statements") if you are interested in any invocation and only if a method-local new creates the value. If you need to know if any invocation can return a new value from any subcomputation you need to compute the possible call-graph and determine if any called function can return a new value, or pass a new value from a called function to its parent.
There are a number of Java static analysis frameworks.
SOOT is a byte-code based analysis framework. You could probably implement your static query using this.
The DMS Software Reengineering Toolkit is a generic engine for building custom analyzers and transformation tools. It has a full Java front end, and computes various useful base analyses (def/use chains, call graph) on source code. It can process class files but presently only to get type information.
If you wanted a dynamic analysis, either by itself or as a way to tighten up the static analysis, DMS can be used to instrument the source code in arbitrary ways by inserting code to track allocations.
I'm not sure if this would work for you circumstances, but one simple approach would be to populate a newly added 'instantiatedTime' field in the constructor of the object and compare that with the time the method was call was made. This assumes you have access to the source for the object in question.
Are you sure static analysis is the right tool for the job? Static analysis can give you a result in some cases but not in all.
When running the JVM under a debugger, it assigns objects with increasing object IDs, which you can fetch via System.identityHashCode(Object o). You can use this fact to build a test case that creates an object (the checkpoint), and then calls the method. If the returned object as an id greater than the checkpoint id, then you know the object was created in the method.
Disclaimer: that this is observed behaviour under a debugger, under Windows XP.
I have a feeling that this is impossible to do without a specially modified JVM. Here are some approaches ... and why they won't work in general.
The Static Analysis approach will work in simple cases. However, something like this is likely to stump any current generation static analysis tool:
// Bad design alert ... don't try this at home!
public class LazySingletonStringFactory {
private String s;
public String create(String initial) {
if (s == null) {
s = new String(initial);
}
return s;
}
}
For a static analyser to figure out if a given call to LazySingletonStringFactory.create(...) returns a newly created String it must figure out that it has not been called previously. The Halting Problem tells us that this is theoretically impossible in some cases, and in practice this is beyond the "state of the art".
The IdentityHashCode approach may work in a single-threaded application that completes without the garbage collector running. However, if the GC runs you will get incorrect answers. And if you have multiple threads, then (depending on the JVM) you may find that objects are allocated in different "spaces" resulting in object "id" creation sequence that is no longer monotonic across all threads.
The Code Instrumentation approach works if you can modify the code of the Classes you are concerned about, either direct source-code changes, annotation-based code injection or by some kind of bytecode processing. However, in general you cannot do these things for all classes.
(I'm not aware of any other approaches that are materially different to the above three ... but feel free to suggest them as a comment.)
Not sure of a reliable way to do this statically.
You could use:
AspectJ or a similar AOP library could be use to instrument classes and increment a counter on object creation
a custom classloader (or JVM agent, but classloader is easier) could be used similarly
How can I find out what caused equals() to return false?
I'm not asking about a sure-way, always right approach, but of something to aid in the development process. Currently I have to step into the equals() calls (usually a tree of them) until one of them is false, then step into it, ad nauseam.
I thought about using the object graph, outputting it to xml and comparing the two objects. However, XMLEncoder requires default constructors, jibx requires pre-compilation, x-stream and simple api are not used in my project. I don't mind copying a single class, or even a package, into my test area and using it there, but importing a whole jar for this just isn't going to happen.
I also thought about building an object graph traverser myself, and I might still do it, but I'd hate to start dealing with special cases (ordered collections, non-ordered collections, maps...)
Any idea how to go about it?
Edit: I know adding jars is the normal way of doing things. I know jars are reusable units. However, the bureaucracy needed (at my project) for this doesn't justify the results - I'd keep on debugging and stepping into.
It's presumably not a full graph comparison... unless your equals include every property in each class ... (you could try == :))
Try hamcrest matchers - you can compose each matcher in an "all of" matcher:
Matcher<MyClass> matcher = CoreMatchers.allOf(
HasPropertyWithValue.hasProperty("myField1", getMyField1()),
HasPropertyWithValue.hasProperty("myField2", getMyField2()));
if (!matcher.matches(obj)){
System.out.println(matcher.describeFailure(obj));
return false;
}
return true;
It will say things like: 'expected myField1 to have a value of "value" but was "a different value"'
Of course you can inline the static factories. This is a bit heavier than using apache-commons EqualsBuilder, but it does give you an accurate description of exactly what failed.
You can create your own specialised matcher for quickly creating these expressions. It would be wise to copy apache-commons EqualsBuilder here.
BTW, the hamcrest basic jar is 32K (including source!) giving you the option of reviewing the code and saying to your bosses "I'll stand by this as my own code" (which I presume is your import problem).
You could use aspects to patch "equal" on the classes in your object graph and make them log the object state to a file when they return false. To log the object state you could use something like beanutils to inspect the object and dump it. This is one jar-based solution which can be easily used in your workspace
If the hierarchy of the objects stored in your tree is simple enough, you could place conditional breakpoints on your classes "equal" implementation which only triggers when "equal" returns false which would limit the number of times you have to step into ... you can use this wherever you have debugger access. eclipse handles this just fine.
It sounds like you want java-diff, or something like it.
Okay, this is a completely bizarre way of looking at it, but how about introducing a new static method:
public static boolean breakableEquals(Object o1, Object o2)
{
if (o1 == o2)
{
return true;
}
if (o1 == null || o2 == null)
{
return false;
}
// Don't condense this code!
if (o1.equals(o2))
{
return true;
}
else
{
return false;
}
}
I know, the last bit looks mad... but the difference is that you can put a breakpoint on the "return false". If you then use breakableEquals in all your deep equality comparisons then you can break as soon as you hit the first "return false".
This doesn't help much if you're comparing lots of primitive values, admittedly... but it might be helpful. I can't say I've ever actually used this, but I can't see why it wouldn't work. It will be a bit less efficient, of course - so if you're dealing with high-performance code you may want to change it afterwards.
Another option would be to use something like:
boolean result = // comparison;
return result;
Assuming your IDE supports them, you can then put a conditional breakpoint on the return statement, and set the condition to be "!result".
Yet another option:
public static boolean noOp(boolean result)
{
return result;
}
You can then use this within comparisons:
return Helpers.noOp(x.id == y.id) &&
Helpers.noOp(x.age == y.age);
I'd hope that when you're not debugging, this would be optimised away by the JIT - but again, you can use a conditional breakpoint in noOp. It makes the code uglier, unfortunately.
In short: no particularly appealing solutions here, but just some ideas which might help in certain situations.
I don't mind copying a single class,
or even a package, into my test area
and using it there, but importing a
whole jar for this just isn't going to
happen.
Um... what? Adding a jar to your classpath is, if anything, easier and less disturbing to the project than copying classes, or entire packages as source code.
As for your specific problem, do you have a lot of different classes that use many different properties to determine equality, or do you just a have deeply nested object graph of essentially the same classes? In the latter case, it would be very easy to just strucutre the equals() methods so that you can put breakpoints on the "return false" statements. In the former case, this might be too much work, I suppose. But then, an XML-based comparison may not work either, since it will show differences between semantically equal objects (e.g. Sets and Maps).
Given that your project can't add a jar, it seems quite beyond a SO answer to give a whole implementation of a solution that other projects take a substantial amount of code to accomplish (and nicely include in a Jar for you).
How about a non-code solution - conditional breakpoints in the debugger? You could add breakpoints that trip only if the method returns false, and put them on all the relevant classes. No stepping.
I know adding jars is the normal way of doing things. I know jars are reusable units. However, the bureaucracy needed (at my project) for this doesn't justify the results - I'd keep on debugging and stepping into.
One way around this is to include a library like Spring (which pulls in loads of other jar) I have seen Spring project which didn't actually use any Spring jar just so they could use any jar which is bundled with it.
commons-jxpath might be useful to quickly examine the object tree. I don't fully understand the issue of including jars, but you can just use it in your own project in whatever IDE you use that presumably lets you use expressions during debugging.
Maybe this article about method tracing will help you.
How it Works
A custom class loader reads the class file and instruments each method with tracing code. The class loader also adds a static field to each class. This field has two states, 'on' and 'off'. The tracing code checks this field prior to printing. The command line options access and modify this static field to control tracing output.
The sample output they show looks promising for your problem, as it shows the return value of some methods (like isApplet):
isApplet=false
It should be easy for you to spot the exact class that started to return false in equals.
Here's the complete sample output from the page:
% java -jar /home/mike/java/trace.jar -classpath "/home/mike/jdk1.3/demo/jfc/SwingSet2/SwingSet2.jar" -exclude CodeViewer SwingSet2
|SwingSet2.()
|SwingSet2.
|SwingSet2.main([Ljava.lang.String;#1dd95c)
||isApplet(SwingSet2#3d12a6)
||isApplet=false
||SwingSet2.createFrame(apple.awt.CGraphicsConfig#93537d)
||SwingSet2.createFrame=javax.swing.JFrame#cb01e3
||createSplashScreen(SwingSet2#3d12a6)
|||createImageIcon(SwingSet2#3d12a6, "Splash.jpg", "Splash.accessible_description")
|||createImageIcon=javax.swing.ImageIcon#393e97
|||isApplet(SwingSet2#3d12a6)
|||isApplet=false
|||getFrame(SwingSet2#3d12a6)
|||getFrame=javax.swing.JFrame#cb01e3
|||getFrame(SwingSet2#3d12a6)
|||getFrame=javax.swing.JFrame#cb01e3
||createSplashScreen
.run(SwingSet2$1#fba2af)
..showSplashScreen(SwingSet2#3d12a6)
...isApplet(SwingSet2#3d12a6)
...isApplet=false
..showSplashScreen
.run
||initializeDemo(SwingSet2#3d12a6)
|||createMenus(SwingSet2#3d12a6)
||||getString(SwingSet2#3d12a6, "MenuBar.accessible_description")
|||||getResourceBundle(SwingSet2#3d12a6)
|||||getResourceBundle=java.util.PropertyResourceBundle#6989e
||||getString="Swing demo menu bar"
XMLEncoder only encodes bean properties, whereas equals can, obviously, work on non-beans and and any internal fields.
Part of the problem is that you don't know what equals is actually looking at. An object could have many diffrent fields and still claim it was equal to some other object, it may even be a diffrent type. (for example, a custom URL class might return true for a string that equals it's external form).
So I don't think it's possible without bytecode instrumentation where you can actually modify the classes equals() function to see what fields it accesses. Even then, it would still be extreemly difficult to 'truly' know why a function returned false. But hopefully it would be a simple issue of comparing the fields that are actually accessed in equals()