Khi đất nước lâm nguy

Khi đất nước lâm nguy thì đòi hỏi rất cao ở trách nhiệm với mỗi công dân. Trách nhiệm đó không chỉ khi đứng trong đội ngũ có người chỉ huy lãnh đạo mà ngay cả khi mỗi người dân chỉ là một thành tố tự do trong những cuộc biểu lộ thái độ có tính tự phát.

 

Ngẫm lại những ngày ở nước Đức trong những năm 1989 và 1990, nhìn vào dân tộc họ khi ấy tôi suy nghĩ rất nhiều. Nhà máy của tôi làm khi đó có tên là Microelechstonichstahnsdord. Đây là một nhà máy quốc doanh chuyên sản xuất vi điện tử xuất khẩu cho nhiều nước. Do làm bóng bán dẫn và vi mạch nên có phân xưởng giữ nguyên vật liệu rất quý như phân xưởng mạ vàng chân các bóng bán dẫn và vi mạch. Nước Đức những năm đó tình hình rất căng thẳng, khắp nơi biểu tình và có lúc bị đe dọa bởi một cuộc chiến có thể nổ ra giữa Đông và Tây.

Rồi nước Đức thống nhất để sau đó nhà máy giải tán dần từng bộ phận và đi tới chỗ bán toàn bộ cho một tập đoàn Ấn Độ. Là đội trưởng đội Việt Nam, tôi thường phải đi giao ban một tuần hai lần với toàn thể ban lãnh đạo của nhà máy nên nắm rất chắc tình hình của nhà máy. Không khí xã hội khi ấy rất phức tạp, nhưng trong thành phố tôi ở và đặc biệt khu nhà máy tôi mọi hoạt động vẫn rất bình thường. Kể cả khi từng phân xưởng giải tán rồi tới tận khi nhà máy được bán đi, nhà máy không mất cắp bất cứ một tài sản nào. Việc quản lý rất chặt chẽ, nhưng nhà máy rất rộng, ba phía rừng và ruộng lúa mì bao bọc nên nếu ai có hành vi muốn lấy cắp thì không phải là không thực hiện được.

Tôi đã hỏi nhiều công nhân quen biết và đặc biệt anh bạn thân Lotar, bảo vệ trưởng của nhà máy, vì sao các bạn lại làm được như thế, khi tài sản hôm qua thuộc nhà máy của DDR (Cộng hòa Dân chủ Đức), hôm sau thuộc về BRD (Cộng hòa liên bang Đức) thì đều nhận được câu hỏi chung là: Chúng tôi là một dân tộc! Quá trình sống với người Đức tôi càng yêu mến và hiểu họ, mặc dù thể chế có thể thay đổi, nhưng hầu như tất cả công nhân Đức, ai cũng đều ý thức rõ là, tài sản của nhà máy là của nhà máy, là của nhân dân Đức nói chung, nó là cái bất khả xâm phạm.

Trong cuộc biến động chính trị đầy âu lo về sự bất ổn ấy, nhà máy không mất đi một viên gạch, một phân vàng, sau bán trọn vẹn lấy tiền cho công quỹ quốc gia chính nhờ sự giác ngộ có tính công dân của từng người dân người Đức, đặc biệt là đội ngũ công nhân trong nhà máy của chúng tôi làm việc.

Việc thứ hai tôi được chứng kiến là mùa đông năm 1989 tình hình rất phức tạp, nhất là trong thành phố lớn như ở thủ đô Berlin. Bấy giờ quanh thủ đô có rất nhiều trại lính của quân đội Nga chiếm đóng theo Hiệp ước Potsdam sau đại chiến II. Ở Đức bấy giờ cũng xuất hiện nhiều nhóm thanh niên đầu trọc theo chủ nghĩa dân tộc cực đoan, sẵn sàng gây hấn, sẵn sàng đập phá và nổi loạn. Những người Đức đa số cũng không thích sự chiếm đóng của quân đội nước ngoài như Pháp, Mỹ và Nga trên nước họ. Đây rất dễ là mảnh đất tốt nảy sinh những hành vi phá hoại của những nhóm phát xít trẻ.

Sát Noel, trời rất lạnh, 25 âm độ về đêm. Chúng tôi lên Berlin phải dứt khoát qua ga tầu Schoennefeld. Khi đó đã là nửa đêm, ga tàu không một bóng cảnh sát. Tôi từ đường hầm lên sân ga nổi bỗng nghe tiếng la ó ầm ầm. Tôi vọt lên sân ga, thấy một tốp đông thanh niên đầu trọc khoảng 50 người, đang la hét, huýt sáo om sòm. Nhiều thanh niên Đức tầm 16, 17 tay mang theo gậy bóng chầy. Họ đang vây quanh bốn người lính Nga trên sân ga nổi. Những lính Nga cũng đang chờ ôtô như tôi đi về doanh trại của họ ở Teltow hay doanh trại nào ở Postdam. Hôm nay là ngày Chủ nhật và họ được phép đi chơi. Đám đông vẫn la hét quanh bốn lính Nga. Chúng nhổ bọt, làm nhiều động tác khả ố mà người châu Âu coi là sự nhục mạ ghê gớm, như chọc ngón cái chỉ xuống đất hay giơ ngón giữa chọc về phía lính Nga và hét to lên những câu nhục mạ. Tôi nín thở quan sát.

Nhưng những người lính Nga vẫn điềm tĩnh. Trong tay không một tấc vũ khí, tới dây nịt da to bản họ cũng không thèm cởi ra để tự vệ mà đứng áp lưng vào nhau như một vòng thành trì nhỏ. Chừng chục phút khiêu khích vô ích, cũng đúng khi ấy có một chuyến Sbahn về, đổ ra sân ga nhiều người Đức xuống tàu, những người Đức đầu không trọc và họ quây lấy những người Nga im lặng như một vòng tròn bảo vệ những người lính đang bị khiêu khích. Tôi len vào đứng bên những người Đức, cạnh những người lính Nga hiền lành mà im lặng sừng sững tựa như những bức tượng sống. Không có sự kiện đáng tiếc nào xảy ra cả.

Sau đó, có thể ai gọi điện, một tốp cảnh sát Đông Đức và quân nhân tuần tra quân đội Nga tới. Tốp người Đức đầu trọc không la ó nữa và kéo lên một chuyến tàu đi về Berlin. Tôi đi cùng bốn anh lính Nga lên ôtô về Teltow. Bao nhiêu năm rồi, trong tai tôi vẫn nghe rõ tiếng gõ gót giầy rất đều xuống sàn nhà ga đêm ấy của tốp lính Nga. Tiếng gõ giày như nhịp tiếng bát trầm, âm thanh rất buồn vang trong đêm vắng, trên sân ga đầy tuyết lạnh, nhưng gắn kết một nhịp, thành một sự thống nhất trong sự bình tĩnh của những người lính Nga.

Sau này đọc nhiều tài liệu, lại quen thân một bác sĩ trong quân đội Nga ở thị xã Stahnsdorf, tôi được biết, lính Nga được xác định rất rõ, tính kỷ luật để giữ sao không mắc mưu những hành vi quá khích, nếu xảy ra ở đường phố, bên doanh trại, nhất là những trạm nhỏ, từ phía người Đức trẻ, nhằm bảo vệ quan hệ hai quốc gia ổn thỏa, dành quyền ngoại giao cho các nhà nước, dẫn tới sau này những thỏa ước để người Nga, người Mỹ và Pháp rút về nước. Rõ ràng tốp lính Nga kia dù không có sĩ quan chỉ huy vẫn có tính kỷ luật rất cao.

Nước Đức năm ấy đã trải qua một biến động chính trị rất lớn, nó trở thành một quốc gia thống nhất và mạnh tới hôm nay, lại tránh cho toàn thế giới một cuộc đối đầu nguy niểm, là có sự đóng góp xây dựng chính ở tinh thần công dân Đức rất hiểu biết, rất trọng kỷ luật. Những người lính Nga cũng như thế, họ là những người lính có kỷ luật.

Tôi đã ở quân đội 11 năm, thực sự thấy quân đội nhân dân Việt Nam là quân đội từ nhân dân mà ra và rất có kỷ luật. Chính điều đó làm nên sức mạnh của đội quân mà làm nên chiến thắng được những kẻ địch thường chiếm ưu thế về hỏa lực.

Tình hình đất nước những ngày qua đang sôi lên vì nhà nước Trung Quốc đặt giàn khoan lên biển Đông của nước ta. Nhân dân ta ở khắp nơi đã thể hiện lòng yêu nước, tự tổ chức những cuộc biểu tình ở nhiều nơi để tỏ rõ thái độ của mình, phản đối việc nhà nước Trung Quốc xâm phạm chủ quyền biển đảo của nước Việt Nam chúng ta. Hơn lúc nào hết, đất nước cần trách nhiệm công dân, sự hiểu biết của mỗi công dân trong trách nhiệm với đất nước, là tinh thần kỷ luật cao như những chiến sĩ ngoài mặt trận, là ôn hòa đấu tranh, giữ đúng một thái độ: Không khoan nhượng với hành vi xâm phạm chủ quyền của Trung Quốc trên biển Đông với giàn khoan Hải Dương 981, nhưng không có những hành vi tự phát, thiếu suy nghĩ, dẫn tới các hành vi có tính phá hoại tài sản của các tập đoàn kinh tế (bất luận tập đoàn kinh tế ấy là nước nào, đều nằm trong sự bảo trợ của luật pháp của nước Việt Nam chúng ta), đang đầu tư trong nước ta gây ảnh hưởng không nhỏ về uy tín của nước ta trên trường quốc tế...

Khó có sự tập trung sức mạnh thiếu một sự chỉ đạo thống nhất, nhất là trong tình trạng manh mún và tự phát. Đã đến lúc các cuộc biểu tình cần có kiểm soát, bằng sự kêu gọi, bằng ý kiến, sáng kiến của nhân sĩ trí thức, nhân dân và dựa vào đội ngũ nhân sĩ, trí thức để có chủ trương và sự phối hợp hành động công dân.

Tôi tin rằng, nếu tin dân, lại hiểu được dân, khi có sự tham gia lãnh đạo của mặt trận Tổ quốc, các đoàn thể, các các cấp chính quyền, nhất là ở từng địa phương xa trung ương, thì nhà nước ta sẽ có sức mạnh dân tộc, mang lại hiệu quả cao cho sự bảo đảm tính ôn hòa, có văn hóa ứng xử trong đấu tranh vì hòa bình và ổn định kinh tế và chính trị của đất nước Việt Nam...

Nguyễn Văn Thọ

Java exception handling best practices

This post is another addition in best practices series available in this blog. In this post, I am covering some well-known and some little known practices which you must consider while handling exceptions in your next java programming assignment. Follow this link to read more about exception handling in java.

Sections in this post

Type of exceptions
User defined custom exceptions

Best practices you must consider and follow

Never swallow the exception in catch block
Declare the specific checked exceptions that your method can throw
Do not catch the Exception class rather catch specific sub classes
Never catch Throwable class
Always correctly wrap the exceptions in custom exceptions so that stack trace is not lost
Either log the exception or throw it but never do the both
Never throw any exception from finally block
Always catch only those exceptions that you can actually handle
Don't use printStackTrace() statement or similar methods
Use finally blocks instead of catch blocks if you are not going to handle exception
Remember "Throw early catch late" principle
Always clean up after handling the exception
Throw only relevant exception from a method
Never use exceptions for flow control in your program
Validate user input to catch adverse conditions very early in request processing
Always include all information about an exception in single log message
Pass all relevant information to exceptions to make them informative as much as possible
Always terminate the thread which it is interrupted
Use template methods for repeated try-catch
Document all exceptions in your application in javadoc

Before we dive into deep concepts of exception handling best practices, lets start with one of the most important concepts which is to understand that there are three general types of throwable classes in Java: checked exceptions, unchecked exceptions, and errors.

Type of exceptions

Exception Hierarchy in java

Checked exceptions are exceptions that must be declared in the throws clause of a method. They extend Exception and are intended to be an “in your face” type of exceptions. Java wants you to handle them because they somehow are dependent on external factors outside your program. A checked exception indicates an expected problem that can occur during normal system operation. Mostly these exception happen when you try to use external systems over network or in file system. Mostly, the correct response to a checked exception should be to try again later, or to prompt the user to modify his input.
Unchecked exceptions are exceptions that do not need to be declared in a throws clause. JVM simply doesn’t force you to handle them as they are mostly generated at runtime due to programmatic errors. They extend RuntimeException. The most common example is a NullPointerException [Quite scary.. Isn't it?]. An unchecked exception probably shouldn’t be retried, and the correct action should be usually to do nothing, and let it come out of your method and through the execution stack. At a high level of execution, this type of exceptions should be logged.
Errors are serious runtime environment problems that are almost certainly not recoverable. Some examples are OutOfMemoryError, LinkageError, and StackOverflowError. They generally crash you program or part of program. Only a good logging practice will help you in determining the exact causes of errors.

User defined custom exceptions

Anytime when user feels that he wants to use its own application specific exception for some reasons, he can create a new class extending appropriate super class (mostly its Exception.java) and start using it in appropriate places. These user defined exceptions can be used in two ways:
1) Either directly throw the custom exception when something goes wrong in application

throw new DaoObjectNotFoundException("Couldn't find dao with id " + id);

2) Or wrap the original exception inside custom exception and throw it

catch (NoSuchMethodException e) {
  throw new DaoObjectNotFoundException("Couldn't find dao with id " + id, e);
}

Wrapping an exception can provide extra information to the user by adding your own message/ context information, while still preserving the stack trace and message of the original exception. It also allows you to hide the implementation details of your code, which is the most important reason to wrap exceptions.
Now lets start exploring the best practices followed for exception handling industry wise.

Best practices you must consider and follow

1) Never swallow the exception in catch block

view sourceprint?

1.catch (NoSuchMethodException e) {

2.return null;

3.}

Doing this not only return “null” instead of handling or re-throwing the exception, it totally swallows the exception, losing the cause of error forever. And when you don’t know the reason of failure, how you would prevent it in future? Never do this !!
2) Declare the specific checked exceptions that your method can throw

view sourceprint?

1.public void foo() throws Exception { //Incorrect way

2.}

Always avoid doing this as in above code sample. It simply defeats the whole purpose of having checked exception. Declare the specific checked exceptions that your method can throw. If there are just too many such checked exceptions, you should probably wrap them in your own exception and add information to in exception message. You can also consider code refactoring also if possible.

view sourceprint?

1.public void foo() throws SpecificException1, SpecificException2 { //Correct way

2.}

3) Do not catch the Exception class rather catch specific sub classes

view sourceprint?

1.try {

2.someMethod();

3.} catch (Exception e) {

4.LOGGER.error("method has failed", e);

5.}

The problem with catching Exception is that if the method you are calling later adds a new checked exception to its method signature, the developer’s intent is that you should handle the specific new exception. If your code just catches Exception (or Throwable), you’ll never know about the change and the fact that your code is now wrong and might break at any point of time in runtime.
4) Never catch Throwable class
Well, its one step more serious trouble. Because java errors are also subclasses of the Throwable. Errors are irreversible conditions that can not be handled by JVM itself. And for some JVM implementations, JVM might not actually even invoke your catch clause on an Error.
5) Always correctly wrap the exceptions in custom exceptions so that stack trace is not lost

view sourceprint?

1.catch (NoSuchMethodException e) {

2.throw new MyServiceException("Some information: " + e.getMessage());  //Incorrect way

3.}

This destroys the stack trace of the original exception, and is always wrong. The correct way of doing this is:

view sourceprint?

1.catch (NoSuchMethodException e) {

2.throw new MyServiceException("Some information: " , e);  //Correct way

3.}

6) Either log the exception or throw it but never do the both

view sourceprint?

1.catch (NoSuchMethodException e) {

2.LOGGER.error("Some information", e);

3.throw e;

4.}

As in above example code, logging and throwing will result in multiple log messages in log files, for a single problem in the code, and makes life hell for the engineer who is trying to dig through the logs.
7) Never throw any exception from finally block

view sourceprint?

1.try {

2.someMethod();  //Throws exceptionOne

3.} finally {

4.cleanUp();    //If finally also threw any exception the exceptionOne will be lost forever

5.}

This is fine, as long as cleanUp() can never throw any exception. In the above example, if someMethod() throws an exception, and in the finally block also, cleanUp() throws an exception, that second exception will come out of method and the original first exception (correct reason) will be lost forever. If the code that you call in a finally block can possibly throw an exception, make sure that you either handle it, or log it. Never let it come out of the finally block.
8) Always catch only those exceptions that you can actually handle

view sourceprint?

1.catch (NoSuchMethodException e) {

2.throw e; //Avoid this as it doesn't help anything

3.}

Well this is most important concept. Don’t catch any exception just for the sake of catching it. Catch any exception only if you want to handle it or, you want to provide additional contextual information in that exception. If you can’t handle it in catch block, then best advice is just don’t catch it only to re-throw it.
9) Don’t use printStackTrace() statement or similar methods
Never leave printStackTrace() after finishing your code. Chances are one of your fellow colleague will get one of those stack traces eventually, and have exactly zero knowledge as to what to do with it because it will not have any contextual information appended to it.
10) Use finally blocks instead of catch blocks if you are not going to handle exception

view sourceprint?

1.try {

2.someMethod();  //Method 2

3.} finally {

4.cleanUp();    //do cleanup here

5.}

This is also a good practice. If inside your method you are accessing some method 2, and method 2 throw some exception which you do not want to handle in method 1, but still want some cleanup in case exception occur, then do this cleanup in finally block. Do not use catch block.
11) Remember “Throw early catch late” principle
This is probably the most famous principle about Exception handling. It basically says that you should throw an exception as soon as you can, and catch it late as much as possible. You should wait until you have all the information to handle it properly.
This principle implicitly says that you will be more likely to throw it in the low-level methods, where you will be checking if single values are null or not appropriate. And you will be making the exception climb the stack trace for quite several levels until you reach a sufficient level of abstraction to be able to handle the problem.
12) Always clean up after handling the exception
If you are using resources like database connections or network connections, make sure you clean them up. If the API you are invoking uses only unchecked exceptions, you should still clean up resources after use, with try – finally blocks. Inside try block access the resource and inside finally close the resource. Even if any exception occur in accessing the resource, then also resource will be closed gracefully.
13) Throw only relevant exception from a method
Relevancy is important to keep application clean. A method which tries to read a file; if throws NullPointerException then it will not give any relevant information to user. Instead it will be better if such exception is wrapped inside custom exception e.g. NoSuchFileFoundException then it will be more useful for users of that method.
14) Never use exceptions for flow control in your program
We have read it many times but sometimes we keep seeing code in our project where developer tries to use exceptions for application logic. Never do that. It makes code hard to read, understand and ugly.
15) Validate user input to catch adverse conditions very early in request processing
Always validate user input in very early stage, even before it reached to actual controller. It will help you to minimize the exception handling code in your core application logic. It also helps you in making application consistent if there is some error in user input.
For example: If in user registration application, you are following below logic:
1) Validate User
2) Insert User
3) Validate address
4) Insert address
5) If problem the Rollback everything
This is very incorrect approach. It can leave you database in inconsistent state in various scenarios. Rather validate everything in first place and then take the user data in dao layer and make DB updates. Correct approach is:
1) Validate User
2) Validate address
3) Insert User
4) Insert address
5) If problem the Rollback everything
16) Always include all information about an exception in single log message
LOGGER.debug(“Using cache sector A”);
LOGGER.debug(“Using retry sector B”);
Don’t do this.
Using a multi-line log message with multiple calls to LOGGER.debug() may look fine in your test case, but when it shows up in the log file of an app server with 400 threads running in parallel, all dumping information to the same log file, your two log messages may end up spaced out 1000 lines apart in the log file, even though they occur on subsequent lines in your code.
Do it like this:
LOGGER.debug(“Using cache sector A, using retry sector B”);
17) Pass all relevant information to exceptions to make them informative as much as possible
This is also very important to make exception messages and stack traces useful and informative. What is the use of a log, if you are not able to determine anything out of it. These type of logs just exist in your code for decoration purpose.
18) Always terminate the thread which it is interrupted

view sourceprint?

1.while (true) {

2.try {

3.Thread.sleep(100000);

4.} catch (InterruptedException e) {} //Don't do this

5.doSomethingCool();

6.}

InterruptedException is a clue to your code that it should stop whatever it’s doing. Some common use cases for a thread getting interrupted are the active transaction timing out, or a thread pool getting shut down. Instead of ignoring the InterruptedException, your code should do its best to finish up what it’s doing, and finish the current thread of execution. So to correct the example above:

view sourceprint?

1.while (true) {

2.try {

3.Thread.sleep(100000);

4.} catch (InterruptedException e) {

5.break;

6.}

7.}

8.doSomethingCool();

19) Use template methods for repeated try-catch
There is no use of having a similar catch block in 100 places in your code. It increases code duplicity which does not help anything. Use template methods for such cases.
For example below code tries to close a database connection.

view sourceprint?

01.class DBUtil{

02.public static void closeConnection(Connection conn){

03.try{

04.conn.close();

05.} catch(SQLException ex){

06.throw new RuntimeException("Cannot close connection", ex);

07.}

08.}

09.}

This type of method will be used in thousands of places in your application. Don’t put whole code in every place rather define above method and use it everywhere like below:

view sourceprint?

01.public void dataAccessCode() {

02.Connection conn = null;

03.try{

04.conn = getConnection();

05.....

06.} finally{

07.DBUtil.closeConnection(conn);

08.}

09.}

20) Document all exceptions in your application in javadoc
Make it a practice to javadoc all exceptions which a piece of code may throw at runtime. Also try to include possible course of action, user should follow in case these exception occur.
That’s all i have in my mind for now. If you found anything missing or you does not relate to my view on any point, drop me a comment. I will be happy to discuss.

(Source: Internet)

Difference between Set, List and Map in Java

Set, List and Map are three important interface of Java collection framework and Difference between Set, List and Map in Java is one of the most frequently asked Java Collection interview question. Some time this question is asked as When to use List, Set and Map in Java. Clearly, interviewer is looking to know that whether you are familiar with fundamentals of Java collection framework or not. In order to decide when to use List, Set or Map , you need to know what are these interfaces and what functionality they provide. List in Java provides ordered and indexed collection which may contain duplicates. Set provides an unordered collection of unique objects, i.e. Set doesn't allow duplicates, while Map provides a data structure based on key value pair and hashing. All three List, Set and Map are interfaces in Java and there are many concrete implementation of them are available in Collection API. ArrayList and LinkedList are two most popular used List implementation while LinkedHashSet, TreeSet and HashSet are frequently used Set implementation. In this Java article we will see difference between Map, Set and List in Java and learn when to use List, Set or Map.

 

Set vs List vs Map in Java

As I said Set, List and Map are interfaces, which defines core contract e.g. a Set contract says that it can not contain duplicates. Based upon our knowledge of List, Set and Map let's compare them on different metrics.

Duplicate Objects

Main difference between List and Set interface in Java is that List allows duplicates while Set doesn't allow duplicates. All implementation of Set honor this contract. Map  holds two object per Entry e.g. key and value and It may contain duplicate values but keys are always unique.

Order

Another key difference between List and Set is that List is an ordered collection, List's contract maintains insertion order or element. Set is an unordered collection, you get no guarantee on which order element will be stored. Though some of the Set implementation e.g. LinkedHashSet maintains order. Also SortedSet and SortedMap e.g. TreeSet and TreeMap maintains a sorting order, imposed by using Comparator or Comparable.

Null elements

List allows null elements and you can have many null objects in a List, because it also allowed duplicates. Set just allow one null element as there is no duplicate permitted while in Map you can have null values and at most one null key. worth noting is that Hashtable doesn't allow null key or values but HashMap allows null values and one null keys.  This is also the main difference between these two popular implementation of Map interface, aka HashMap vs Hashtable

Popular implementation

List - ArrayList, LinkedList and Vector

Set - HashSet, TreeSet and LinkedHashSet

Map - HashMap, Hashtable and TreeMap

When to use List, Set and Map in Java

Based upon our understanding of difference between Set, List and Map we can now decide when to use List, Set or Map in Java.

1) If you need to access elements frequently by using index, than List is a way to go. Its implementation e.g. ArrayList provides faster access if you know index.

2) If you want to store elements and want them to maintain an order on which they are inserted into collection then go for List again, as List is an ordered collection and maintain insertion order.

3) If you want to create collection of unique elements and don't want any duplicate than choose any Set implementation e.g. HashSet, LinkedHashSet or TreeSet. All Set implementation follow there general contract e.g. uniqueness but also add addition feature e.g. TreeSet is a SortedSet and elements stored on TreeSet can be sorted by using Comparator or Comparable in Java. LinkedHashSet also maintains insertion order.

4) If you store data in form of key and value than Map is the way to go. You can choose from Hashtable, HashMap, TreeMap based upon your subsequent need. In order to choose between first two see difference between HashSet and HashMap in Java.

That's all on difference between Set, List and Map in Java. All three are most fundamental interface of Java Collection framework and any Java developer should know there distinguish feature and given a situation should be able to pick right Collection class to use. It's also good to remember difference between there implementation e.g. When to use ArrayList and LinkedList , HashMap vs Hashtable  or When to use Vector or ArrayList etc. Collection API is huge and it's difficult to know every bits and piece but at same time there is no excuse for not knowing fundamentals like Difference between Set, List and Map in Java.

 

(Source: Internet)