Contact us
17 February 2021

Why today's automatic conversion tools from PL/SQL to Java is not what you need

Read our new blog post to find out why automatic conversion tools from PL/SQL is a trick
17 February 2021

Why today's automatic conversion tools from PL/SQL to Java is not what you need

Read our new blog post to find out why automatic conversion tools from PL/SQL is a trick
17 February 2021

Why today's automatic conversion tools from PL/SQL to Java is not what you need

Read our new blog post to find out why automatic conversion tools from PL/SQL is a trick
The biggest trick is already in the name of such tools. Any company facing the challenge of migrating to Java usually does not understand well what "moving to Java" means. It might look simple at a first glance – all you need is to rewrite all business logic you have from PL/SQL to Java syntax. But this doesn't work in practice. If you try to rewrite in such a way, what you will get is completely unmaintainable code. Why would you need to migrate to Java in the first place?
The biggest trick is already in the name of such tools. Any company facing the challenge of migrating to Java usually does not understand well what "moving to Java" means. It might look simple at a first glance – all you need is to rewrite all business logic you have from PL/SQL to Java syntax. But this doesn't work in practice. If you try to rewrite in such a way, what you will get is completely unmaintainable code. Why would you need to migrate to Java in the first place?
The biggest trick is already in the name of such tools. Any company facing the challenge of migrating to Java usually does not understand well what "moving to Java" means. It might look simple at a first glance – all you need is to rewrite all business logic you have from PL/SQL to Java syntax. But this doesn't work in practice. If you try to rewrite in such a way, what you will get is completely unmaintainable code. Why would you need to migrate to Java in the first place?
“
In short: you need to migrate from PL/SQL to Spring or to JavaEE. You don't need to migrate to plain Java since no one uses plain Java in 2021
“
In short: you need to migrate from PL/SQL to Spring or to JavaEE. You don't need to migrate to plain Java since no one uses plain Java in 2021
“
In short: you need to migrate from PL/SQL to Spring or to JavaEE. You don't need to migrate to plain Java since no one uses plain Java in 2021

Let's analyze all the arguments one by one. You want to have your codebase on Java because:

Your business logic becomes complex and difficult to maintain
New features development and delivery is slow compared to competitors
Your codebase becomes huge over the years and it is difficult to navigate
You need to integrate with 3rd parties in an easy way via RestFul/SOAP services
Your system becomes fragile - you change it in one place and it breaks in another place
You can't use smart code analysis to reveal hidden bugs right during the development process
The onboarding for newly hired engineers lasts for several months before they start to contribute efficiently
Your system is a big monolith which is difficult to develop and scale

Let's analyze all the arguments one by one. You want to have your codebase on Java because:

Your business logic becomes complex and difficult to maintain
New features development and delivery is slow compared to competitors
Your codebase becomes huge over the years and it is difficult to navigate
You need to integrate with 3rd parties in an easy way via RestFul/SOAP services
Your system becomes fragile - you change it in one place and it breaks in another place
You can't use smart code analysis to reveal hidden bugs right during the development process
The onboarding for newly hired engineers lasts for several months before they start to contribute efficiently
Your system is a big monolith which is difficult to develop and scale

Let's analyze all the arguments one by one. You want to have your codebase on Java because:

Your business logic becomes complex and difficult to maintain
New features development and delivery is slow compared to competitors
Your codebase becomes huge over the years and it is difficult to navigate
You need to integrate with 3rd parties in an easy way via RestFul/SOAP services
Your system becomes fragile - you change it in one place and it breaks in another place
You can't use smart code analysis to reveal hidden bugs right during the development process
The onboarding for newly hired engineers lasts for several months before they start to contribute efficiently
Your system is a big monolith which is difficult to develop and scale
Development effectiveness (including engineering, testing, and deployment) which is connected to "time to market"

Scalability (monolith limits freedom to create flexible architecture with effective resource usage when it is needed where it is needed) which is connected to "infrastructure costs"
In general, you understand that you have two types of problems:
1
2
Many more issues could arise but we won't focus on the obvious ones like difficulties finding PL/SQL developers on the market compared to Java, lack of open source frameworks and components, etc …
Many more issues could arise but we won't focus on the obvious ones like difficulties finding PL/SQL developers on the market compared to Java, lack of open source frameworks and components, etc …
Many more issues could arise but we won't focus on the obvious ones like difficulties finding PL/SQL developers on the market compared to Java, lack of open source frameworks and components, etc …
The truth about automatically converted code
Now let's ask ourselves which of the above mentioned goals are achieved by applying automatic conversion of syntax? Right, none of them. Automatically converted code has the following drawbacks:
The truth about automatically converted code
Now let's ask ourselves which of the above mentioned goals are achieved by applying automatic conversion of syntax? Right, none of them. Automatically converted code has the following drawbacks:
The truth about automatically converted code
Now let's ask ourselves which of the above mentioned goals are achieved by applying automatic conversion of syntax? Right, none of them. Automatically converted code has the following drawbacks:
  • It follows Java syntax but uses no Java frameworks (Spring or JavaEE), which are standard to arrange your codebase in reusable components.
  • Java is an object-oriented language whereas PL/SQL is a procedural one. A conversion tool is unable to infer domain entities effectively and connect the corresponding business logic code to these entities.
  • The generated code will not follow one of the most advanced modern system architecture patterns (like: SOA - service oriented architecture or microservice).
  • Generated code works 100-1000 times slower than the original PL/SQL. Initially, PL/SQL was near the data it worked with (inside Oracle Database on the same host). Now the extracted Java code runs on a dedicated host (application server) and communicates with data via SQL requests. Any loops with PL/SQL's cursors translate to Java loops with a call to the DB inside or is at best fetched nearly the entire table into the memory of the Java process and then filters out records are needed. This leads to an inefficient and insecure way to work with data. Instead old cursor-loop needs to be replaced by a couple of complex SQL requests leaving in Java only business logic and data logics must stay in SQL requests. This often requires DB-schema refactoring.
To eliminate all these drawbacks highly qualified human force is required (software engineers, architects and analysts). Even when conversion software generates raw Java codebase which will be adopted by humans it leads to higher costs with lower quality compared to developing Java codebase from scratch.
To eliminate all these drawbacks highly qualified human force is required (software engineers, architects and analysts). Even when conversion software generates raw Java codebase which will be adopted by humans it leads to higher costs with lower quality compared to developing Java codebase from scratch.
To eliminate all these drawbacks highly qualified human force is required (software engineers, architects and analysts). Even when conversion software generates raw Java codebase which will be adopted by humans it leads to higher costs with lower quality compared to developing Java codebase from scratch.
Need a helping hand with your PL/SQL to Java migration? At Enbisys we can help you work out a strategy matching your needs. Contact us now for a free consultation!
Need a helping hand with your PL/SQL to Java migration? At Enbisys we can help you work out a strategy matching your needs. Contact us now for a free consultation!
Need a helping hand with your PL/SQL to Java migration? At Enbisys we can help you work out a strategy matching your needs. Contact us now for a free consultation!
Max Usov
CTO, founder
Previous
Four Pillars of a Successful Machine Learning Project
Next
ENBISYS Named Among Western Europe's Top B2B Companies for 2021 by Clutch.co