What is the use of marker interfaces in Java?

In earlier versions of Java, Marker Interfaces were the only way to declare metadata about a class. For example, the Serializable Marker Interface lets the author of a class say that their class will behave correctly when serialized and deserialized.

In modern Java, marker interfaces have no place. They can be completely replace by Annotations, which allow for a very flexible metadata capability. If you have information about a class, and that information never changes, then annotations are a very useful way to represent it.

http://stackoverflow.com/questions/1995198/what-is-the-use-of-marker-interfaces-in-java

Initial size for the arraylist

You're confusing the size of the array list with its capacity:

• the size is the number of elements in the list;
• the capacity is how many elements the list can potentially accommodate without reallocating its internal structures.

When you call new ArrayList(10), you are setting the list's initial capacity, not its size. In other words, when constructed in this manner, the array list starts its life empty.

One way to add ten elements to the array list is by using a loop:

for (int i = 0; i < 10; i++) {
  arr.add(0);
}

Having done this, you can now modify elements at indices 0..9.

http://stackoverflow.com/questions/8896758/initial-size-for-the-arraylist

Why is Java Vector class considered obsolete or deprecated?

Vector synchronizes on each individual operation. That's almost never what you want to do.

Generally you want to synchronize a whole sequence of operations. Synchronizing individual operations is both less safe (if you iterate over a Vector, for instance, you still need to take out a lock to avoid anyone else changing the collection at the same time, which would cause a ConcurrentModificationException in the iterating thread) but also slower (why take out a lock repeatedly when once will be enough)?

Of course, it also has the overhead of locking even when you don't need to.

Basically, it's a very flawed approach to synchronization in most situations. As MrSpandex pointed out, you can decorate a collection using the calls such as Collections.synchronizedList - the fact that Vectorcombines both the "resized array" collection implementation with the "synchronize every operation" bit is another example of poor design; the decoration approach gives cleaner separation of concerns.

As for a Stack equivalent - I'd look at Deque/ArrayDeque to start with.

http://stackoverflow.com/questions/1386275/why-is-java-vector-class-considered-obsolete-or-deprecated

How to choose the right bean scope?

It represents the scope (the lifetime) of the bean. A request scoped bean lives as long as a single HTTP request-response cycle. A view scoped bean lives as long as you're interacting with the same JSF view by postbacks returning null/void. A session scoped bean lives as long as the established HTTP session. An application scoped bean lives as long as the web application runs.

Which scope to choose depends solely on the data (the state) the bean holds and represents. Use the request scope for simple and non-ajax forms/presentations. Use the view scope for rich ajax-enabled dynamic views (ajaxbased validation, rendering, etc). Use the session scope for client specific data, such as the logged-in user and user preferences (language, etc). Use the application scope for application wide data/constants, such as dropdown lists which are the same for everyone.

Abusing an application scoped bean for session/view/request scoped data would make it to be shared among all users, so anyone else can see each other's data which is just plain wrong. Abusing a session scoped bean for view/request scoped data would make it to be shared among all tabs/windows in a single browser session, so the enduser may experience inconsitenties when interacting with every view after switching between tabs which is bad for user experience. Abusing a request scoped bean for view scoped data would make view scoped data to be reinitialized to default on every single (ajax) postback, causing possibly non-working forms (see also points 4 and 5 here). Abusing a view scoped bean for request scoped data doesn't affect the client, but it unnecessarily occupies server memory.

Note that the scope should rather not be chosen based on performance implications, unless you reallyhave a low memory footprint and want to go completely stateless; you'd need to use exclusively request scoped beans and fiddle with request parameters to maintain the client's state.

See also:

• "Under the covers" (basic Servlet) working of request/response, session and application scopes
• Communication in JSF2 - Managed bean scopes

http://stackoverflow.com/questions/7031885/how-to-choose-the-right-bean-scope