This is little different from what already been asked for here
I would like to know what topics/APIs are most important for Java interviews. for example -
Concurrency,
Collections
.....and like that.
The reason is because implementations like ConcurrentHashMap (read here) have so much details in them, that one would like to discuss about them as it covers many important aspects
java.io - difference between streams and writers. Buffered streams.
java.util - the collection framework. Set and List. What's HashMap, TreeMap. Some questions on efficiency of concrete collections
java.lang - wrapper types, autoboxing
java.util.concurrent - synchronization aids, atomic primitives, executors, concurrent collections.
multithreading - object monitors, synchronized keyword, methods - static and non-static.
I'd say there are two things you need for every java interview:
For Basic knowledge of the Language, consult your favorite book or the Sun Java Tutorial
For Best Practices read Effective Java by Joshua Bloch
Apart from that, read whatever seems appropriate to the job description, but I'd say these two are elementary.
I guess these packages are relevant for every java job:
java.lang (Core classes)
java.io (File and Resource I/O)
java.util (Collections Framework)
java.text (Text parsing / manipulation)
IMHO its more important to have a firm understanding of the concepts rather than specific knowledge of the API and especially the internal workings of specific classes. For example;
knowing that HashMap is not synchronized is important
knowing how this might affect a multithreaded app is important
knowing what kind of solutions exist for this problem is important
I wouldn't worry too much about specific API details like individual methods of ConcurrentHashMap, unless you're interviewing for a job that is advertised as needing a lot of advanced threading logic.
A thorough understanding of the basic Java API's is more important, and books like Effective Java can help there. At least as important though is to know higher level concepts like Object Orientation and Design Patterns.
Understanding what Polymorphism, Encapsulation and Inheritance are, and when and how to use them, is vital. Know how to decide between Polymorphism and Delegation (is-a versus has-a is a decent start, but the Liskov Substitution Principle is a better guide), and why you may want to favor composition over inheritance. I highly recommend "Agile Software Development" by Robert Martin for this subject. Or check out this link for an initial overview.
Know some of the core patterns like singleton, factory, facade and observer. Read the GoF book and/or Head First Design Patterns.
I also recommend learning about refactoring, unit testing, dependency injection and mocking.
All these subject won't just help you during interviews, they will make you a better developer.
We usually require the following knowledge on new developers:
Low level (programming) questions:
http://www.interview-questions-java.com/
Antipatterns:
http://en.wikipedia.org/wiki/Anti-pattern
Design:
http://en.wikipedia.org/wiki/Design_Patterns
On some of the interviews I have been to, there is also the java.io package covered, sometimes with absurd questions on what kind of exceptions would some rarely used method declare to throw, or whether some strange looking constructor overload exists.
Concurrency is always important for higher-level positions, but I think that knowing the concepts well (and understanding them ofc) would win you more points than specific API knowledge.
Some other APIs that get mentioned at interviews are Reflection (maybe couple questions on what can be achieved with it) and also java.lang.ref.Reference and its subclasses.
I ask some basic questions ('whats the difference between a list and a set?', 'whats an interface?', etc) and then I go off the resume. If hibernate is on there 5 times, I expect the candidate to be able to define ORM. You would be surprised how often it happens that they can't. I am also interested in how the candidate approaches software -- do they have a passion for it? And it is very important that the candidate believes in TDD. Naturally, if its a really senior position, the questions will be more advanced (e.g. 'whats ThreadLocal and when do you use it'), but for most candidates this is not necessary.
Completely agree with Luke here. We can not stick to some API's to prepare for Core Java interviews. I think a complete understanding of the OOPS concept in Java is must. Have good knowledge of oops shows the interviewer that the person can learn new API's easily and quick.
Topics that should be covered are as follows:
OOPS Concept
Upcasting & DownCasting
Threading
Collection framework.
Here is a good post to get started. Core Java Interview Q & A
Related
I know that Java is mostly object oriented language since you can do things like encapsulation, inheritance, and run-time polymorphism.
But when I watch a lot of talks on youtube about RxJava they say under Android you work with imperative rules? Does this relate to the life-cycle methods?
When I work with POJO's isn't that Object Oriented? Does this have to with how we handle data through our architecture layers? I'm getting confused with all these 'paradigms' and 'styles' especially since RxAndroid is getting thrown into the mix with 'functional-reactive' style.
First of all: Android is an operating system, not a programming language. That language is mainly object oriented, but lately a lot of effort is going into making java more suitable for functional programming. Frameworks such as RxJava emphasize that, too.
Of course, there are different programming models that can be used on the Android platform.
Coming from there: there is simply no sense in assuming that this large, complex environment can be reduced to some simple, always correct single word description. It is a combination of many different aspects.
Or as the US citizens say: in pluribus unum.
Android itself is a platform, not a language, so the question contains a category mistake.
In general, the only way this kind of question can be definitively answered is by resort to fundamental definitions. These were stated by Peter Wegner in 1987 in the paper 'Dimensions of Object-based Language Design'.
Wegner provides the following definitions:
Object-based: a language is object-based if it supports objects as a language feature.
Class-based: an object-based language is class-based (classical) if every object has a class.
Object-oriented: an object-based language is object-oriented if its objects belong to classes and class hierarchies can be incrementally designed by an inheritance mechanism.
I think you've got it a little bit wrong.
Java is an imperative language. You'd be better to ask what the difference between declarative vs imperative programming, or the difference between object oriented and functional programming.
Here is a great article on imperative vs declarative:
https://tylermcginnis.com/imperative-vs-declarative-programming/
Here is a stack overflow answer explaining the difference between object oriented and functional:
Functional programming vs Object Oriented programming
Android provides a framework written in java. Android isn't a language, but Java is. Java is an object oriented language.
I hope that clears things up a bit.
Some people say that Java is more like a hybrid, taking this piece from this article:
That said, Java is not a pure Object-Oriented language. Someone said Java is a hybrid, which, IMO, is an accurate description. I would posit Java is a dirty hybrid of an OO language. Consider:
String s = string2.trim();
First, since "String" is immutable, the above code reeks of functional programming. The "trim()" operation should cause the whitespace to be trimmed off both ends of "string2", without needing reassignment. That is to say, operations should act on the data as close to the object as possible. This, to me, makes Java feel dirty (it also leads to tightly-coupled systems due to the prevalence of "get" accessor methods, but that's another topic entirely). Ahem, what? That example is perfectly OO. Object-orientation does not make mutable state necessary. Actually, since strings are passed around so often, the lack of mutator methods really just saves a lot of headache.
Second, Java cannot alter the behaviour of all messages. It mixes the types of "operations" available to objects, depending on their type. The "+" is equally applicable to ints as it is Strings, but not to Matrices, or Colors. This isn't so bad, because you can do matrix.add( matrix ), but serves to illustrate the point about Java being 'dirty' (or 'impure', if you prefer).
Lastly, it is a hybrid to provide performance gains. Even though Smalltalk has an advanced virtual machine, its inability (when I was using it) to provide a machine-correlated bytecode for integer math placed a significant performance impact on its entire environment. Being a hybrid, Java cannot be called a true Object-Oriented language. But then, why does it matter?Use the right tool for the job and life will be happy!*
So:
You can work all like procedural programming if you want, and not use anything of OOP, but also, is not pure OOP programming, because not everything in Java is an object.
Also:
Java8 introduces some concepts about Functional programming, one of them is the use of lambdas.
In resume, Java is imperative, OOP and functional language(dep on version).
What was the driving factor or design plan in making the methods of HashTable synchronized?
This link says that HashTable is synchronized because its methods are synchronized. But, I want to know the reason "why" the methods were synchronized?
Was it just to provide some synchronization feature? A developer could explicitly handle a race condition through synchronization techniques. Why provide HashTable with this feature?
Keep in mind: these classes were created "ages" ago - when you check the javadoc for Hashtable, you find it says "since Java 1.0"; whereas HashMap says "1.2"!
Back then, Java was trying to compete with languages like C and C++; by providing unique selling points such as "built-in concurrency".
But people quickly figured that one better synchronizes containers when using them in multi-threaded environments!
So my (more of an opinion-based) answer is: at the time when this class was first designed, people assumed that the requirement "can be used by multiple threads" was more important than "gives optimal performance".
Because Java was "advertised" like: "use it to write multi-threaded write once run everywhere code". That approach fails quickly when the default container classes given to people need additional outside wrapping to actually make them "multi-threaded" ready.
During the years, the people behind Java started to understand that "more granular" solutions are required. Therefore the core collection classes are not synchronized to avoid the corresponding performance hits. Meaning: the default with collections is to go "unprotected"; so you have to put in some thoughts when your requirements is that "multi-threaded" correctness.
Same for "lists" btw: Vector is synchronized; ArrayList is not.
We cannot tell you why. Those who designed Java over two decades ago maybe can. It's not a useful question. Assuming you actually wanted to ask about java.util.Hashtable and not the fictional HashTable type, bear in mind that it's been obsolescent for nineteen years. Nineteen years! Don't use it. It (and Vector) have cruft that the replacement types, both synchronized and unsynchronized, do not carry. Use the modern (as of nineteen years ago) types.
The questions asks:
Recount all of the java lenguage mechanisms that
(a) Facilitate code reuse, and
(b) Minimize ripple effects due to requirements
changes.
I am not sure if I am understanding this correctly. For (a) I thought it would be Composition, Association and Inheritance, and for (b) I thought it would be Encapsulation and Polymorphism; but I'm not sure if this is what the question asks and I am not sure if I am missing another mechanism. Also I am not sure about what the question mean by "Java language mechanisms" ?
Can someone help me to clarify this, my book really does not do a good job of explaining this.
In my opinion, composition and association aren't Java language mechanisms, they're related to OOP as a concept.
But Interfaces, Abstract classes and Generics are.
Regarding ripple effect, I would go with this definition:
http://www.javapractices.com/topic/TopicAction.do?Id=123
Constants, private fields (Encapsulation) and again Interfaces/Abstract classes (Polymorphism).
A) Methods, Classes and Inheritance. These are the pure language mechanisms. I wouldn't say composition and association are real mechanisms, they are concepts of oop in general and not associated with the java language.
B) Named Constants instead of magic numbers, minimizing visibility. There is no real polymorphism in java as there is in c++ for example. But using Interfaces as references is a really good idea, as the implementations are easily replaceable. It also allows you to make your code more configurable using the factory pattern or even Dependency Injection. This problem and the advantages of using interfaces is well explained in this article.
Again, polymorphism and encapsulation are oop concepts and not associated directly with the java language.
Why java.util.Iterator interface has method remove()?
Certainly sometimes this method is necessary and all have become accustomed to its presence. But in fact the main and only objective of the iterator is just to provide access container elements. And when someone wants to create his own implementation for this interface, and cannot or does not want for any reason to provide the ability to remove an element, then he is forced to throw UnsupportedOperationException. And throwing of that exception usually indicates a not too well thought out architecture or some flaws in design.
Really I don't understand the reasons for such a decision. And I guess it would be more correctly separate a specific subinterface to support the optional method:
Any reasoned versions why remove() is part of the Iterator? Is not this example of a direct violation of the single responsibility principle from SOLID?
In addition to fancy technical answers ... please consider the timeline too. The "single responsibility principle" was coined by Robert Martin at some point in the middle/late 90es.
The Java iterator interface came into existence with Java 1.2; so around 1998.
It is very much possible that the folks at Sun had never heard of this concept while working on the early releases of Java.
Of course, many smart people have the same ideas without reading a book about it ... so a good designer might have implemented "SRP" like without knowing about "SRP" - but it also requires a high degree of awareness to unveil all the big and small violations of this rule ...
This design decision is explained in the Java Collections API Design FAQ. Specifically, see the first question on why collections don't support immutability and instead require optional operations. The short answer is that they didn't want "an explosion" in the number of interfaces.
There seems to be a mix-up of semantics here. Robert C. Martin defines Single Responsibility as a "single reason to change" (SRP.pdf), not as "doing only a single thing". SRP is very much related with cohesion: a software module should only contain things that are functionally related to each other.
With these things in mind, I don't think that having the remove method included in Iterator violates the SRP. Removing an element is often something you might want to do while iterating over the elements; the operations are essentially cohesive. Also, enabling the removal of elements through Iterator makes the Iterable interface (which was added in Java 5) much more powerful. This feature is utilized in e.g. many of the methods in Guava's Iterables utility class.
More info on the history of the term in this excellent article by Uncle Bob himself.
I'm studying the visitor pattern and I wonder how this pattern is related to the open/closed principle. I read on several websites that "It is one way to follow the open/closed principle." (citated from wikipedia).
On another website I learned that is follows the open/closed principle in such a way that it is easy to add new visitors to your program in order to "extend existing funcionality without changing existing code". That same website mentions that this visitor pattern has a major drawback: "If a new visitable object is added to the framework structure all the implemented visitors need to be modified." A solution for this problem is provided by using Java's Reflection framework.
Now, isn't this solution a bit of a hack solution? I mean, I found this solution on some other blogs as well, but the code looks more like a workaround!
Is there another solution to this problem of adding new visitables to an existing implementation of the visitor pattern?
Visitor is one of the most boilerplate-ridden patterns of all and has the drawbacks regarding non-extensibility that you mention. It is itself a sloppy workaround to introduce double dispatch into a single-dispatch language. When you consider all its drawbacks, resorting to reflection is not such a terrible choice.
In fact, reflection is not a very bad choice in any case: consider how much today's code is written in dynamic languages, in other words using nothing but reflection, and the applications don't fall apart because of it.
Type safety has its merits, certainly, but when you find yourself hitting the wall of static typing and single dispatch, embrace reflection without remorse. Note also that, with proper caching of Method objects, reflective method invocation is almost as fast as static invocation.
It depends on precisely what job the Visitor is supposed to accomplish, but in most cases, this is what interfaces are for. Consider a SortedSet; the implementation needs to be able to compare the different objects in the set to know their ordering, but it doesn't need to understand anything else about the objects. The solution (for sorting by natural order) is to use the Comparable interface.