Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We know Java has fail-fast and fail-safe iteration design.
I want to know , why we need these basically. Is there any fundamental reason for this separation? . What is the benefit of this design?.
Other than collection iteration , Java follows this design anywhere else?
Thanks
For a programmer it is useful that a code, if it contains a bug, tries to fail as fast as possible. The best would be at compile time but that is sometimes not possible.
Because of that an error can be detected earlier. Otherwise it could happen that an error remains undetected and is contained in your software for years and nobody notices the bug.
So the goal is to detect errors and bugs as early as possible. Methods that accept parameters therefore should immediately check if they are within allowed range, this would be a step towards fail-fast.
Those design-goals are everywhere, not just at iterations, simply because it is a good idea. But sometimes you want to make a trade-off with the usability or other factors.
As an example the Set implementations allow null values which is the source for many bugs. The new Java 9 collections do not allow this and immediately throw an exception when trying to add such, this is fail-fast.
Your iterators are also a nice example. We have some fail-fast iterators, they do not allow modifications to the collection while iterating it. The main reason is because it could easily be the source of errors. Thus they throw a ConcurrentModificationException.
In the special case of iterations someone needs to specify how things should work. How should the iteration behave when a new element comes or gets removed while iterating? Should it be included/removed in the iteration or should it be ignored?
As an example, ListIterator provides a very well-defined option to iterate List and also manipulate it. There you are only allowed to manipulate the object the iterator is currently at, this makes it well-defined.
On the other side there are some fail-safe iteration methods like using a ConcurrentHashMap. They do not throw such exceptions and allow modifications. However they work on a copy of the original collection which also solves the "how" question. So changes on the map are not reflected in the iterator, the iterator completely ignores any changes while iterating. This comes at an increased cost, a complete copy must be created each time you iterate.
For me personally those fail-safe variants are not an option. I use the fail-fast variants and memorize what I want to manipulate. After the iteration has finished I execute those memorized manipulations.
This is less comfortable to write for the programmer but you get the advantage of fail-fast. This is what I meant with trade-off with usability.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
I have a set of private methods that are used in a main public method (that receive a list) of a class, these methods will mainly use java 8 classic stream operations as filter, map, count e.t.c. I am wondering if creating stream single time in public api and passing to others method instead of passing list have any performance benefits or considerations as .stream() is called single time.
Calling stream() or any intermediate operation would actually do nothing, as streams are driven by the terminal operation.
So passing a Stream internally from one method to another is not bad IMO, might make the code cleaner. But dont return a Stream externally from your public methods, return a List instead ( plz read the supplied comments, might not hold for all cases)
Also think of the case that applying filter for example and then collecting to a toList and then streaming again that filtered List to only map later is obviously a bad choice... You are collecting too soon, so dont chain methods like this even internally.
In general it's best to ask for what is actually needed by the method. If every time you receive a list you make it a stream, ask for the stream instead (streams can come from things other than lists). This enhances portability and reusability and lets consumers of your api know upfront the requirements.
Ask for exactly what you need, nothing more, nothing less.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
There is an explanatory code of what I'm trying to ask. Sureley, the difference between the codes below is ignorable, yet it describes the point.
Which one is the most efficient in terms of memory usage and performance?
if( MathUtil.CalculateSin(angle) > Angles.ACUTE){
// Something is done
}
or
double angleSin = MathUtil.CalculateSin(angle);
if( angleSin > Angles.ACUTE){
// Something is done
}
It simply depends if you are going to re-use the variable.
If yes, use the second case.
If no use the first case.
There is no reason to store the value in a variable if you are not going to re-use it.
Edit :
As per your comment, it seems you are mostly asking this question for performance concern...
Actually my question is not about the algorithm nor the way I
implement it. I'm curious about the memory usage of the approaches,
therefore efficiency is the purpose.
Don't expect any difference in term of memory usage for both approaches, the JVM and JIT will optimize it as much as possible so that both case become the same.
To extend the other answers, you should also consider readability of your code. In this case, the meaning of MathUtil.CalculateSin(angle) is pretty obvious. However, if you have a more complex condition, it would be a good idea to precompute that condition, give the variable a meaningful name and then use the variable in the if-statement.
In your case it also depends on the context of the if-statement. Again, MathUtil.CalculateSin(angle) > Angles.ACUTE is quite easy to grasp at a glance. However,
final boolean angleIsAcute = (MathUtil.CalculateSin(angle) > Angles.ACUTE);
if(angleIsAcute) { ... }
would carry the meaning better. In this case, of course, both possibilities are quite similar, but I hope you see where I am going with this.
Do not worry about the overhead that is introduced by storing that extra variable. Even though the java-compiler does not optimize your code, any JVM worth its salt will optimize the bytecode and the performance overhead will be negligible.
I often use the first pattern even when I won't need the variable later in the code. The advantage is for debugging.
You can examine and change the value of the variable when stepping through the code in a debugger.
If an exception occurs in the call on the right-hand side of the statement, it is sometimes clearer what happened than if the call is embedded in an if or as an argument to another call.
If you're concerned about memory usage for the variable, don't be. Trust the compiler to optimize away variables that it knows aren't going to be used later. If you declare the variable final, it will be optimized aggressively as described in the JLS.
References do take memory. So if you are not going to use angleSin anywhere else then second option is what you should go for. Besides it does not pollute the namespace. That is one reason people make Comparator as an anonymous class instead of creating a new one. If they do not need to use somewhere else.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
The following example is tailor made to make my doubts clear.
EG: WAP, with a method getAllWordsStartingInputChar to return the frequency of a word in the dictionary. The dictionary in form of a hashmap would be provided to the constructor.
Now, before getAllWordsStartingInputChar is called for the first time, I need to create another map of char->list of words begining with that char
Where should this map be created ?
In the constructor ?
Lazy initialization ?
Anything else ?
Please try to avoid being specific about my example, the idea i am trying to convey is 'some computation that needs to be done, whose results would be stored and used over and over again'.
Where should such computation be done.
Please try to avoid being specific about my example
Thats's no problem, because I cannot be too specific about this example when the example itself is not very specific (just kidding a little).
Seriosly, there is no problem to initialize a HashMap in the constructor
as long as you don't start a thread which uses these variables or call a method which do that or, also evil, call a overridable method in the constructor. Probably I forgot something.
Strategie of creation
If your Map list of words beginning with that char is used in each case, which means, there is no case in which you don't need the map, than you should create it during construction.
If these map is used very seldom, chose lazy initiaization, e.g. at the first call of a getter.
That is just my opinion without knowing very much about your needs.
Where should this map be created ?
1) In the constructor ?
Possibly.
2) Lazy initialization ?
Possibly.
3) Anything else ?
Probably not.
In purely performance terms, the choice between 1) and 2) depends on the probability that the constructed object won't use the second map. You need to balance the cost of the laziness (extra tests each time the map is used) versus the cost of creating the map unnecessarily.
The only "anything else" that I can think of is creating the second map each time that you use it. That only makes sense from a performance perspective if the map is only ever used zero or one time.
Where should such computation be done.
From a performance perspective, that's probably not relevant. From a design perspective ... you can make make a variety of arguments about where the code belongs. It is a matter of personal taste (IMO).
But looking back at the above comparison of 1) versus 2), the other observation is that this smells of "premature optimization", and premature optimization is often a complete waste of time. For more on that topic, read this: https://softwareengineering.stackexchange.com/a/80092/172.
If you have perfect information of how the costs will work out in practice, then the optimization is just "maths". But in practice, you rarely have enough information, and the mathematics is frequently too complicated. And general "rule of thumb" answers are not going to be reliable. Hence, each situation needs to be optimized on its merits ... based on real performance measurement. (If the effort is warranted!)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Yesterday I have attended interview in one Leading IT Service company. Technical interview was good, no issues, then I have moved to another set of round about Management, Design and Process. I have answered everything except the below question.
Question asked by interviewer:
Let say you are developing a class, which I am going to consume in my
class by extending that, what are the key points you keep in
mind? Ex, Class A, which has a method called "method A" returns a Collection,
let say "list". What are the precautions you will take?
My Answer: The following points I will consider, such as:
Class and method need to be public
Method 1 returns a list, then this needs to be generics. So we can avoid class cast exception
If this class will be accessed in a multi-threaded environment, the method needs to be synchronized.
But the interviewer wasn't convinced by my points. He was expecting a different answer from me but I am not able to get his thought process, what he was excepting.
So please provide your suggestions.
I would want you holding to design principles of Single Reaponsibility, Open/Close, and Dependency Injection. Keep it stateless, simple, and testable. Make sure it can be extended without needing to change.
But then, I wasn't interviewing you.
A few more points which haven't been mentioned yet would be:
Decent documentation for your class so that one doesn't have to dig too deep into your code to understand what functionality you offer and what are the gotchas.
Try extending your own class before handing it out to someone else. This way, you personally can feel the pain if you class is not well designed and thereby can improve it.
If you are returning a list or any collection, one important question you need to ask is, "can the caller modify the returned collection"? Or "is this returned list a direct representation of the internal state of your class?". In that case, you might want to return a copy to avoid callers messing up your internal state i.e. maintain proper encapsulation.
Plan about the visibility of methods. Draw an explicit line between public, protected, package private and private methods. Ensure that you don't expose any more than you actually want to. Removing features is hard. If something is missing from your well designed API, you can add it later. But you expose a slew of useless public methods, you really can't upgrade your API without deprecating methods since you never know who else is using it.
If you are returning a collection, the first thing you should think about is should I protect myself from the caller changing my internal state e.g.
List list = myObject.getList();
list.retainAll(list2);
Now I have all the elements in common between list1 and list2 The problem is that myObject may not expect you to destroy the contents of the list it returned.
Two common ways to fix this are to take a defensive copy or to wrap the collection with a Collections.unmodifiableXxxx() For extra paranoia, you might do both.
The way I prefer to get around this is to avoid returning the collection at all. You can return a count and a method to get the n-th value or for a Map return the keys and provide a getter, or you can allow a visitor to each element. This way you don't expose your collection or need a copy.
Question is very generic but i want to add few points:
Except the method which you want to expose make other methods and variable private. Whole point is keep visibility to minimum.
Where ever possible make it immutable, this will reduce overhead in mutithreaded environment.
You might want to evaluate if serializability is to be supported or not. If not then dont provide default constructor. And if serializable then do evaluate serialized proxy pattern.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Every time I see a method were one of the parameters is an output parameter like
void addTokenErrorsToReport(List<String> tokens, Map<String, Integer> report)
I get the feeling that this is just plain wrong. From my point of view, parameters in general should be immutable, and not changed within a method. E.g., the above method could be rewritten to
Map<String, Integer> createTokenErrorsReport(List<String tokens)
The returned Map could then be merged with the original report Map.
Is this assumption right? Or are both versions equally acceptable?
As with most things, it's only "bad practice" if it leads to poorly functioning / unreadable / hard-to-maintain code or if you don't know why you're doing it.
In most cases using an output parameter doesn't have those effects.
In your addTokenErrorsToReport, it certainly is an appropriate approach. You are adding token errors to a report - the function needs to know the tokens it is adding and the report it is adding to. The function clearly performs precisely the operation it was designed to perform with no disadvantages.
If you were to take the createTokenErrorsReport approach, you would have to follow every call to it by inserting the new tokens in the existing report. If adding tokens to an existing report is a common operation, it most definitely makes sense to have a method that adds. That's not to say that createTokenErrorsReport shouldn't exist as well - if creating new reports from a token list is a common operation, then you would want a function that does that.
A great example of a good use of an output parameter is Collections.sort, which sorts a list in place. The performance hit of creating a new copy of the list and returning the sorted copy is avoided, while at the same time it does not limit you from creating a copy and sorting the copy if you want to.
Just use the best tool for the job and keep your code succinct.
How would you add something to the map in the second example? I think it would be bad practice if you have to pass an empty map that gets filled in addTokenErrorsToReport. But in this case: no, I don't think it's bad practice. How would you implement otherwise if you have several List<String> tokens that you want to process? I think the first example is the straightforward one.
I think it depends on where you come from (language). If you used to write c or c++, where you could use pointers as parameters, which is nice and practical, you could easily write code like your first example. I don't really think there is some kind of good or bad but just how your style of coding is.
I have seen this coding practice reasonably often and found it quite elegant. It allows you to 'return' multiple Objects.
For instance, in your above example, you could return an integer value corresponding to an error code.