Why Java Is so Young After 25 Years: An Architect’s Point of View

Java completes 25 years of programming life and remains closer to developer's minds; almost 69% of the worldwide developer community remains to code in Java, even now. Oracle recently released Java 15 with tonnes of features like Sealed Classes, Hidden Classes, Edward-Curve Digital Signature Algorithm (EdDSA), Text Blocks to name a few. This makes Java 15 to be 25 years young and not 25 years old programming language.

History and Evolution of Java

When there were dozens of programming language which were very stable in the early 1990s like FORTRAN, COBOL, Pascal, C++, and Visual Basic, many platforms like Windows, Mac, Unix, Linux, and Mobile platforms demanded a unified approach in program development and architecture design. James Gosling and his friends discussed these aspects under an Oak tree near James' office where they felt a new programming language to be developed to address these gaps. They were very particular on foundational aspects in developing a new language called Oak, which was then named as Green (as the team is named as Green team) and later Java (based on their favorite coffee from Indonesia called Java Coffee).

SKP’s Java/Java EE Gotchas: BCEL Issue on JiBX 1.2.5 (java.lang.CharSequence)

So, I spent some time on resolving this issue with a combination of the following:

1. JiBX 1.2.5 / JiBX 1.2.6
2. JDK 1.8

During the jibx-maven-plugin:bind phase of the Maven Build, you may get an error when you upgrade from JDK 1.x to JDK 1.8; The issue will manifest in the following most common form/error:
 
Failed to execute goal org.jibx:jibx-maven-plugin:1.2.5:bind (bind-compile) on project common: Error loading class java.lang.CharSequence: Error reading path java/lang/CharSequence.class for class java.lang.CharSequence
 

You can modify your pom.xml, to make these changes to fix this error.

1. Include the Repository for BCEL 6.0
Include the Repository for BCEL 6.0



2. Check the version of JiBX [Choose any of 1.2.5 or 1.2.6]
Check the version of JiBX [Choose any of 1.2.5 or 1.2.6]


3. Exclude default 'BCEL' from the Build
Exclude default 'BCEL' from the Build


4. See the modifications for the plugin 'jibx-maven-plugin'
See the modifications for the plugin 'jibx-maven-plugin'


5. Voila!
Build Success!

SKP’s Java/Java EE Gotchas: Clustered Nodes Issue Using Apache Lucene 5.4.y

So, We just spent about 28+ days — using Stack Overflow and Hibernate Search Forums as also various other resources to 'FIX' the strangest of issues using Hibernate Search and Apache Lucene. The right help or pointer came from the 'Hibernate Search Committers/Creators' (Official Forums). Thanks a lot to 'sanne.grinovero'.

Issue Description: In a (non-replicated) clustered environment, if the Indexing by Lucene or Hibernate Search is done from the Same Database (Instance) using the Same Data the Results obtained are Different on Different Nodes. In other words, the Same Data from the Same Database Instance Indexed using the Same Code Yields a Different Result Set for the Same Search Term (Index Contents are Different on Different Machines).


Issue Resolution / Root Cause: The point to note is that, if you open a 'Hibernate Session' that you use for your 'Apache Lucene or Hibernate Search Indexing' and if a 'Runtime/Exception' occurs before you 'Close' the session, the results that are obtained across different machines, when queried using the same search term. Though this occurred after the 'console logs' reported that the Index is '100% Successfully Completed' — It has led to an inconsistent index across machine. My analysis is that 'session.close()' below may be leading to some 'flushing or committing to the indexing', which leads to the inconsistency when a runtime exception occurs — even after indexing is reported complete by the Hibernate/Hibernate Search on the 'Console Logs'.

Suggestion: Make sure that there are no Runtime Exceptions (or Errors) before Closing the Session. Even if you find that the Indexing is 100% Complete and there is an Exception right at the End — Please do not Ignore/Keep/Park it (Considering it a Minor or Unrelated Error) for a fix at the 'End of Dev Cycle' as it may Impact Results. This is true for any seemingly unrelated exception that may occur before calling 'session.close()'.

I am pasting the statement here from Hibernate Search Forums (Committer), which may be useful for all of you and helped us to finally resolve this error:  If a batch of documents failed, you might have a block of documents missing in one of the indexes (and this could happen several times). By default errors are logged, you might want to hook up an ErrorHandler to raise a more serious notification to your admins — if logs are ignored.



The culprit line of code, pointed out in red. [CULPRIT LINE OF CODE - WHERE RUNTIME EXCEPTION OCCURS - POINTED OUT USING ARROW]

Spring, Hibernate, EhCache Recipe

A Simple Scenario explaining the Usage and Performance, when using EhCache (2nd Level Cache of along with Hibernate in a Spring environment. The performance results are taken using mySQL as the Database. 

Though this Example is from Spring 2.5.x and Hibernate 3.x and EhCache 1.4, MySQL 5.0 => The Concepts Demonstrated will Continue to Hold Good for any Version of any Make of Second Level Cache Product with Hibernate (Optionally, Spring) such as Infinispan, Redis, Hazelcast, ...

[Download Sample Code] Please be informed that the size is about 10MB; as i have provided all the dependencies.

In this example, I need to retrieve close to 5,000 records in a single fetch and then cache this information. As usual, setup Spring contexts in your Spring configuration file. I have just one class, which is a Hibernate DAO, HibernateDoctorDAO.java. The dependency injection hierarchy is dataSource sessionFactory hibernateTemplate. hibernateTemplate is then injected into the HibernateDoctorDAO.java at runtime by the Spring Framework.

The Implementations of Each of These Are:
dataSource > org.apache.commons.dbcp.BasicDataSource
sessionFactory > org.springframework.orm.hibernate3.LocalSessionFactoryBean
hibernateTemplate > org.springframework.orm.hibernate3.HibernateTemplate

The results clearly shows the difference in performance with EhCache enabled, even in this simple example:
 
PERFORMANCE COMPARISON (In Seconds)
==============================
QUERY FETCH TIME (INITIAL): 0.599
QUERY FETCH TIME (HIBERNATE CACHE): 0.212
QUERY FETCH TIME (2ND LEVEL CACHE): 0.091
Version Reference > Spring-2.5, Hibernate-3.0, EhCache-1.4, mySQL-5.0
 

Instructions: Unzip the file and start by creating the database. Any mySQL database that is compatible with the MySQL Connector 5.0.8 is fine for this example. You will have to create the database data_explosion (USERNAME: root, PASSWORD: architect.2012) and the table DOCTOR_TABLE. You can use the provided doctor.sql as reference. Then run the java standalone com.sumsoft.spring.orm.hibernate.dataload.JDBCDataLoader to create and load a large number of arbitary records into the DOCTOR_TABLE. You can ignore or remove every invocation that is to PATIENT_TABLE, as this is only additional for this example. Then use spring_hibernate_cache.bat to run the application. Though not tested on UNIX, you may write a script similar to the batch file to run this application. 

Top 40 Questions for a Spring Framework Interview

The Spring framework makes J2EE (Java 2 Platform Enterprise Edition) development easier and is used to create testable, high performing, reusable code. Spring is commonly applied in the information technologies and financial sector due to its modularity and dependency injection features.

Financial technology is an exciting and evolving field for developers who want to work at companies like MIT, Accenture, or Visa, which prefer Spring over Java EE. These companies are looking for developers like you with Spring Framework experience to help digitize their enterprise needs.