Some Interview Quetions

1.Difference between composition and inheritance ?
2.What is the difference between callable and runnable  interface?
3.what is the difference between EJB and web services ?
4.how to synchronize int variable?
5.How cookies are managing in HTML5?
6.Request dispatcher and send redirect difference ?

Java Interview Quetions

Wipro 1st technical
1. Brief about yourself and current project.
2. qustions on Restful webservices
     > uri or url, MIME types, Operatios
    > how you implemented
    >  navigation process
3. spring
    > di , wiring, mvc flow,
4. Angular JS
     > services, directives
5. have learned any new technologies
9. performance tuning"

 Wipro 2nd technical Process AVP has done this and asked about the project , not much on technical side Success


 Wipro 3rd technical
"1. questions about concurrent hashmap & nio package
2. What are the differences b/w REST & Soap, and what scenarios we use.
3. for performance improvement what you will do in respective layers (GUI,Controller,Service, DAO etc.,)
4. What are the core strength in your career and explain
5. what are the issues that you face during code reviews..."


State Street 1st technical
"this is screen round , asked only about the current proj, what are the problems that you faced how you resolved, and why you are looking for change like that..,

 Mindtree 1st technical
"1. write down the basic spring and hibernate configuration of your projece
2. brief me about your current project architecture.
3. questions on exception hierachy
4. given one problem statement (man-colors), and asked me which ds is useful

JDBC Driver Types

Type 1 Driver - JDBC-ODBC bridge[edit]

Schematic of the JDBC-ODBC bridge

The JDBC type 1 driver, also known as the JDBC-ODBC bridge, is a database driver implementation that employs the ODBCdriver to connect to the database. The driver converts JDBC method calls into ODBC function calls.

The driver is platform-dependent as it makes use of ODBC which in turn depends on native libraries of the underlyingoperating system the JVM is running upon. Also, use of this driver leads to other installation dependencies; for example, ODBC must be installed on the computer having the driver and the database must support an ODBC driver. The use of this driver is discouraged if the alternative of a pure-Java driver is available. The other implication is that any application using a type 1 driver is non-portable given the binding between the driver and platform. This technology isn't suitable for a high-transaction environment. Type 1 drivers also don't support the complete Java command set and are limited by the functionality of the ODBC driver.

Sun provides a JDBC-ODBC Bridge driver: sun.jdbc.odbc.JdbcOdbcDriver. This driver is native code and not Java, and is closed source.

If a driver has been written so that loading it causes an instance to be created and also calls DriverManager.registerDriver with that instance as the parameter (as it should do), then it is in the DriverManager's list of drivers and available for creating a connection.

It may sometimes be the case that more than one JDBC driver is capable of connecting to a given URL. For example, when connecting to a given remote database, it might be possible to use a JDBC-ODBC bridge driver, a JDBC-to-generic-network-protocol driver, or a driver supplied by the database vendor. In such cases, the order in which the drivers are tested is significant because the DriverManager will use the first driver it finds that can successfully connect to the given URL.

First the DriverManager tries to use each driver in the order it was registered. (The drivers listed in jdbc.drivers are always registered first.) It will skip any drivers that are untrusted code unless they have been loaded from the same source as the code that is trying to open the connection.

It tests the drivers by calling the method Driver.connect on each one in turn, passing them the URL that the user originally passed to the method DriverManager.getConnection. The first driver that recognizes the URL makes the connection.

Advantages[edit]

• Almost any database for which an ODBC driver is installed can be accessed, and data can be retrieved.

Disadvantages[edit]

• Performance overhead since the calls have to go through the jdbc Overhead bridge to the ODBC driver, then to the native db connectivity interface (thus may be slower than other types of drivers).
• The ODBC driver needs to be installed on the client machine.
• Not suitable for applets, because the ODBC driver needs to be installed on the client.

Type 2 Driver - Native-API Driver[edit]

Schematic of the Native API driver

The JDBC type 2 driver, also known as the Native-API driver, is a database driver implementation that uses the client-side libraries of the database. The driver converts JDBC method calls into native calls of the database API.For example: Oracle OCI driver is a Type 2 Driver

Advantages[edit]

• As there is no implementation of jdbc-odbc bridge, its considerably faster than a type 1 driver.

Disadvantages[edit]

• The vendor client library needs to be installed on the client machine.
• Not all databases have a client side library
• This driver is platform dependent
• This driver supports all java applications except Applets

Type 3 Driver - Network-Protocol Driver(MiddleWare Driver)[edit]

Schematic of the Network Protocol driver

The JDBC type 3 driver, also known as the Pure Java Driver for Database Middleware, is a database driver implementation which makes use of a middle tier between the calling program and the database. The middle-tier (application server) convertsJDBC calls directly or indirectly into the vendor-specific database protocol.

This differs from the type 4 driver in that the protocol conversion logic resides not at the client, but in the middle-tier. Like type 4 drivers, the type 3 driver is written entirely in Java. The same driver can be used for multiple databases. It depends on the number of databases the middleware has been configured to support. The type 3 driver is platform-independent as the platform-related differences are taken care of by the middleware. Also, making use of the middleware provides additional advantages of security and firewall access.

Functions[edit]

• Sends JDBC API calls to a middle-tier net server that translates the calls into the DBMS-specific network protocol. The translated calls are then sent to a particular DBMS.
• Follows a three tier communication approach.
• Can interface to multiple databases - Not vendor specific.
• The JDBC Client driver written in java, communicates with a middleware-net-server using a database independent protocol, and then this net server translates this request into database commands for that database.
• Thus the client driver to middleware communication is database independent.

Advantages[edit]

• Since the communication between client and the middleware server is database independent, there is no need for the database vendor library on the client. The client need not be changed for a new database.
• The middleware server (which can be a full fledged J2EE Application server) can provide typical middleware services like caching (of connections, query results, etc.), load balancing, logging, and auditing.
• A single driver can handle any database, provided the middleware supports it.
• E.g.:-IDA Server

Disadvantages[edit]

• Requires database-specific coding to be done in the middle tier.
• The middleware layer added may result in additional latency, but is typically overcome by using better middleware services.

Type 4 Driver - Database-Protocol Driver(Pure Java Driver)[edit]

Schematic of the Native-Protocol driver

The JDBC type 4 driver, also known as the Direct to Database Pure Java Driver, is a database driver implementation that converts JDBC calls directly into a vendor-specific database protocol.

Written completely in Java, type 4 drivers are thus platform independent. They install inside the Java Virtual Machine of the client. This provides better performance than the type 1 and type 2 drivers as it does not have the overhead of conversion of calls into ODBC or database API calls. Unlike the type 3 drivers, it does not need associated software to work.

As the database protocol is vendor specific, the JDBC client requires separate drivers, usually vendor supplied, to connect to different types of databases. This type includes, for example, the widely used Oracle thin driver.

Advantages[edit]

• Completely implemented in Java to achieve platform independence.
• These drivers don't translate the requests into an intermediary format (such as ODBC).
• The client application connects directly to the database server. No translation or middleware layers are used, improving performance.
• The JVM can manage all aspects of the application-to-database connection; this can facilitate debugging.

Disadvantages[edit]

• Drivers are database dependent, as different database vendors use widely different (and usually proprietary) network protocols.

Java interview Quetions

1.Could you pease explain Struts2.x flow ?
2. What is diffrence between Struts1.x and Struts 2.x?
3. Performance tuning in plsql ? how to do ?
4.Multithreading handling in core java ?
5.how many ways can we create thread? why we prefer runnable interface?
6. What is threadpooling ? how we can implement?
7.JDBC steps to get connection?which step database connection established?
8. JDBC with Datasource?
9.Servlet lifecycle?
10. Diffrence between JSP and Servlet?
11. Message driven bean implemtion steps? where you implemented in your projects?
12.How JMS implmented? how kind of API used to Implement JMS?
13.Spring AOP concept? Where you Implemnt AOP concepts ? How ?
14.some Unix commands Like ls,ps,Kill,find,Grep commands.
15.Diffent types Cursors in PLsql?
16. how do u handle Exceptions in procedure?
17. Triggers in Pl/sql?
18 Joins in sql? diffrence between innerjoin and Outerjoin?
19.Diffrence between Union and joins?
20. diffrence between restful webservces and soap services?
21.Singleton desinpattren ?
22. IOC and DI?
23. Proxy design Pattren?
24.could yu please explain collection frame work?
25.diffrence between concureent hashmap and hashmap?
26.synchrnization in java? externalization?
27.searlization in java? is marshling same as searlization?
28. Could you please explain oops to non technical person?
29. diffrence between string and stringbuffer?
30. Transction mangement in spring? how it internally works?
31.Spring benefits?
32. what are the issues faced while deloping hibernate application?
33. quaries exection in hibernate ? HQL vs criteria
34.java 5 features?
35 customized annatation implemention?
36.secound highest salary in sql?
37. higest salary from each department query?
38.union vs unionAll
39.Hashcode and equals methods implmetion?
40. spring mvc application with restful services implemntion? responseBody?
41.spring mvc application with jquery ?
42.Filters concepts in servlet?
43. authorization and authentication ?
44.sendredirect and forward
45.how set avioding duplicate data?
46.what are issues faced in your carrer?
47.optimstic locking in hibernatr?
48.spring annations?
49.monitors and semaphores in java?
50.jsp lifecycle?
51.spring mvc  flow?
52.strutss flow?
53.garbage collection in java.
54.memory management in java?
55.customized immtable class? defency copy immtable?
56.transction management in ejb?
57. methods in object class?
58. customized sorting using compartor?

Top 10 causes of performance issues in Java

 

 

Cause #1: The JVM spends more time performing garbage collection due to

• improper Garbage Collection (GC) configuration. E.g. Young generation being too small.
• Heap size is too small (use -Xmx). The application footprint is larger than the allocated heap size.
• Wrong use of libraries. For example, XML based report generation using DOM parser as opposed to StAX for large reports generated concurrently by multiple users. 
• Incorrectly creating and discarding objects without astutely reusing them with a flyweight design pattern or proper caching strategy.
• Other OS activities like swap space or networking activity during GC can make GC pauses last longer. 
• Any explicit System.gc( ) from your application or third party modules.

Run your JVM with GC options such as 

• -verbose:gc (print the GC logs) 
• -Xloggc: (comprehensive GC logging) 
• -XX:+PrintGCDetails (for more detailed output) 
• -XX:+PrintTenuringDistribution (tenuring thresholds)

to understand the GC patterns.

Cause #2: Bad use of application algorithms, strategies, and queries. For example

• SQL queries with Cartesian joins.
• SQL queries invoking materialized views
• Regular expressions with back tracking algorithms.
• Inefficient Java coding and algorithms in frequently executed methods leading to death by thousand cuts.
• Excessive data caching or inappropriate cache refresh strategy.
• Overuse of pessimistic locking as opposed to favoring optimistic locking.

Cause #3:  Memory leaks due to

• Long living objects having reference to short living objects, causing the memory to slowly grow. For example, singleton classes referring to short lived objects. This prevents short-lived objects being garbage collected.
• Improper use of thread-local variables. The thread-local variables will not be removed by the garbage collector as long as the thread itself is alive. So, when threads are pooled and kept alive forever, the object might never be removed by the garbage collector.
• Using mutable static fields to hold data caches, and not explicitly clearing them. The mutable static fields and collections need to be explicitly cleared.
• Objects with circular or bidirectional references.
• JNI memory leaks.

Cause #4: Poor integration with external systems without proper design & testing.

• Not properly deciding between synchronous vs asynchronous calls to internal and external systems. Long running tasks need to be performed asynchronously. 
• Not properly setting service timeouts and retries or setting service time out values to be too high.
• Not performing non happy path testing and not tuning external systems to perform efficiently.
• Unnecessarily making too many network round trips.

Cause #5: Improper use of Java frameworks and libraries.

• Using Hibernate without properly understanding lazy loading versus eager fetching and other tuning capabilities.
• Not inspecting the SQLs internally generated by your ORM tools like Hibernate.
• Using the deprecated libraries like Vector or Hashtable as opposed to the new concurrent libraries that allow concurrent reads.
• Using blocking I/O where the the Java NIO (New I/O) with non blocking capability is favored. 
• Database deadlocks due bad schema design or  application logic.
• Spinning out your own in efficient libraries as opposed to favoring proven frameworks.

Cause #6: Multi-threading issues due to to deadlocks, thread starvation, and thread contention. 

• Using coarse grained locks over fine grained locks. 
• Not favoring concurrent utility classes like  ConcurrentHashMap, CopyOnWriteArrayList, etc. 
• Not favoring lock free algorithms.

Cause #7: Not managing and recycling your non memory resources properly.

• Not pooling your valuable non memory resources like sockets, connections, file handles, threads, etc. 
• Not properly releasing your resources back to its pool after use can lead to resource leaks and performance issues. 
• Use of too many threads leading to more CPU time being used for context switching. 
• Hand rolling your own pooling without favoring proven libraries. 
• Using a third-party library with resource leaks.
• Load balancers leaking sockets.

Cause #8: Bad infrastructure designs and bugs.

• Databases tables not properly partitioned. 
• Not enough physical memory on the box.
• Not enough hard disk space.
• Bad network latency. 
• Too many nodes on the server.
• Load balancers  not working as intended and not performing outage testing.
• Not tuning application servers properly.
• Not performing proper capacity planning.
• router, switch, and DNS server failures. 

Cause #9: Excessive logging and not using proper logging libraries with capabilities to control log levels like debug, info, warning, etc. System.out.println(….) are NOT ALLOWED. Favor asynchronous logging in mission critical and high volume applications like trading systems. 

Cause #10: Not conducting performance tests, not monitoring the systems, and lack of documentation and performance focus from the start of the project.

• Not performing performance test plans with tools like JMeter with production like data prior to each deployment.
• Not monitoring the systems for CPU usage, memory usage, thread usage, garbage collection patterns, I/O, etc on an on going basis. 
• Not defining SLA’s (Service Level Agreements) from the start in the non-functional specification.
• Not maintaining proper performance benchmarks to be compared against with the successive releases and performance tests.
• Not looking for performance issues in peer code reviews or not having code reviews at all.

Migrate the xml to a @Configuration

 @Configuration Implement in Spring

Migrate the xml to a @Configuration in a few steps:

1. Create a @Configuration annotated class:

   @Configuration
   public class MyApplicationContext {
   
   }

2. For each <bean> tag create a method annotated with @Bean:

   @Configuration
   public class MyApplicationContext {
   
     @Bean(name = "someBean")
     public SomeClass getSomeClass() {
       return new SomeClassImpl(someInterestingProperty); // We still need to inject someInterestingProperty
     }
   
     @Bean(name = "anotherBean")
     pubic AnotherClass getAnotherClass() {
       return new AnotherClassImpl(getSomeClass(), beanFromSomewhereElse); // We still need to inject beanFromSomewhereElse
     }
   }

3. In order to import beanFromSomewhereElse we need to import it's definition. It can be defined in an XML and the we'll use @ImportResource:

   @ImportResource("another-application-context.xml")
   @Configuration
   public class MyApplicationContext {
     ...  
   }

   If the bean is defined in another @Configuration class we can use the @Import annotation:

   @Import(OtherConfiguration.class)
   @Configuration
   public class MyApplicationContext {
     ...
   }

4. After we imported other XMLs or @Configuration classes, we can use the beans they declare in our context by declaring a private member to the @Configuration class as follows:

   @Autowired
   @Qualifier(value = "beanFromSomewhereElse")
   private final StrangeBean beanFromSomewhereElse;

   Or use it directly as parameter in the method which defines the bean that depends on this beanFromSomewhereElse using @Qualifier as follows:

   @Bean(name = "anotherBean")
   pubic AnotherClass getAnotherClass(@Qualifier (value = "beanFromSomewhereElse") final StrangeBean beanFromSomewhereElse) {
     return new AnotherClassImpl(getSomeClass(), beanFromSomewhereElse);
   }

5. Importing properties is very similar to importing bean from another xml or @Configuration class. Instead of using @Qualifier we'll use @Value with properties as follows:

   @Autowired
   @Value("${some.interesting.property}")
   private final String someInterestingProperty;

   This can be used with SpEL expressions as well.
6. In order to allow spring to treat such classes as beans containers we need to mark this in our main xml by putting this tag in the context:

   <context:annotation-config/>

   You can now import @Configuration classes exactly the same as you would create a simple bean:

   <bean class="some.package.MyApplicationContext"/>

   There are ways to avoid spring XMLs altogether but they are not in the scope of this answer. You can find out one of these options in the blog post on which I'm basing my answer (disclaimer - the post is written by me).

---

The advantages and disadvantages of using this method

Basically I find this method of declaring beans much more comfortable than using XMLs due to a few advantages I see:

1. Typos - @Configuration classes are compiled and typos just won't allow compilations
2. Fail fast (compile time) - If you forget to inject a bean you'll fail on compile time and not on run-time as with XMLs
3. Easier to navigate in IDE - between constructors of beans to understand the dependency tree.
4. Possible to easily debug configuration startup

The disadvantages are not many as I see them but there are a few which I could think of:

1. Abuse - Code is easier to abuse than XMLs
2. With XMLs you can defined dependencies based on classes that are not available during compile time but are provided during run-time. With @Configuration classes you must have the classes available at compile time. Usually that's not an issue, but there are cases it may be.

Bottom line: It is perfectly fine to combine XMLs, @Configuration and annotations in your application context. Spring doesn't care about the method a bean was declared with.