With IO64 PL/SQL to Java Conversion Toolkit, you can convert from PL/SQL to Java with a fully automated process and run on an open source pure Java framework. You can rewrite or refactor provided framework according to your needs. Since converted code preserves the logic, it can be used as a baseline for other migration options.
Access Demo Application Here
Use readonly/readonly for readonly access. ( write-enabled account available, see below )
Contact firstname.lastname@example.org for
- Free write-enabled credentials
- Initialization of private workspace and credentials for your proprietary code
- Any other questions or batch conversion demo
Follow us on Twitter for upcoming news..
-On-premise installation is available via custom Linux VM. ( Ubuntu 16.04 LTS + Custom GLIBC + Custom JVM )
-Conversion as a service option is available.
- Pricing schema
- Documentation for on-premise installation
IO64 Conversion Console is developed for functional examination of the toolkit as of first phase. It does not include any limitation of capability. Only limitation of public URL is daily source size for single user. At it's core, it uses BaseGenerator described in Batch Mode section below. All required steps are executed in-memory.
The following video shows complete conversion process in batch mode; DDL export, indexing source codes for fast lookups through conversion, PL/SQL to Java conversion and execution of resulting Java code. Example package first selects records with cursor from a source table and inserts or updates to target table. After each iteration inserts changelog to another table.
Details of batch mode is described below. Any intermediate step is repeatable. But once a step is performed, succeeding steps may need to be performed again during conversion period. E.g: If you add or change signature of a function in PL/SQL, you will need to parse and save the AST and build object tree again for converting dependant sources or update it directly in the resulting Java code. When the conversion is complete, you won't need any PL/SQL source.
1. Run ExportUtil. It selects simple definitions like table, argument, synonym, table column, type definitions from DBA tables, dumps to csv files and generates the folder structure for the following steps of conversion process. Same result can be achieved without ExportUtil.
2. Export DDL. Include package, procedure, function, materialized view sources to separate files, using Oracle SQL Developer. Save files to the DDL folder generated at the previous step. Same result can be achieved with any other tool.
At this point, all required definitions becomes available and portable for migration.
3. Run SchemaIndexer. It parses exported DDL and saves resulting AST(Abstract Syntax Tree) to disk for later use. Parsing large DDL files is CPU and memory intensive. The resulting files prevent parsing over and over again and speeds up minor conversion works which may be required at some future point in conversion path.
4. Run DBAMainIndexer. It reads all simple definitions and DDL files, builds contentless, but complete object tree structure and saves it to disk for later use (TypeMap). Singular and complete conversion operations reads this object tree for resolving any kind of dependency.
5. Run BaseGenerator. It reads object tree, all AST files and generates Java code in specified folder. It may be run for individual package conversion repeatedly.
PL/SQL to Java Conversion Toolkit is developed for 100% complete Java conversion and removing PL/SQL dependency in mind. Or even Oracle DB dependency. Any additional usage of commercial or open source library is avoided. This allows generating portable and refactorable Java code. Resulting code may run in any container (E.g. Application Server) or even without a container as a pure Java executable.
All conversion process run for one complete schema. Migration of multiple schemas is possible through regular conversion process but this requires additional manual linking and refactoring. Since multiple schema conversion is not automated, this introduces exclusion of other schemas parametrically. For these schemas, only empty object tree and non-functional empty Java Project is generated and left for manual linking through JDBC to underlying database or imitating functionality in Java.
As a result, migration process ends up with 3 Java Projects;
One for the schema under focus, one for all other custom schemas and one wrapper project for PL/SQL standard functionality.
While some PL/SQL specifications are valid, the Java
equivalent is strictly forbidden.
E.g. unreachable code in PL/SQL is allowed and compilable but in Java it is not compilable in any way.
PL/SQL functions having return type may or may not return appropriate values in flow but in Java if a function has a return type, it must be returned in the execution flow.
To automate quick fixes, an Eclipse plug-in is implemented and will be delivered for on-premise installations. This plug-in adds the quick fixes automatically with one click and will not impact original PL/SQL logic since it never really runs in the original source.
Exported schema source should be valid. Other custom schemas and third-party libraries need NOT to be exported but should be verifiable via DBA_ARGUMENTS table. Type resolution at remote end of DBLINK will result a generic Java "Object" type and thus will cause manual editing of resulting Java code. This may be prevented by providing additional configuration files that describes the DBLINK remote end tables for continuous conversion environment (if requested as on-premise deployment for continuous conversion). Currently, triggers are not supported.