Everything that I see in the video is just the data model. That's by far the easiest part and could be derived from the SQL database schema using an ORM's code generator. I want to see 1000 lines...
Everything that I see in the video is just the data model. That's by far the easiest part and could be derived from the SQL database schema using an ORM's code generator.
I want to see 1000 lines of business logic ported over to Java with consideration for whatever idiosyncrasies COBOL has.
From time to time I have the misfortune of dealing with this kind of “Java” code that has been ported over from COBOL. It is the weirdest stuff you’ll ever encounter. It seems like the way these...
From time to time I have the misfortune of dealing with this kind of “Java” code that has been ported over from COBOL. It is the weirdest stuff you’ll ever encounter.
It seems like the way these projects get ported is one component at a time, while keeping all the data formatting (bizarro fixed length text fields, frequently without without line separators) and heavily overloaded custom data types to strictly emulate COBOL behaviours instead of native data types.
That makes complete sense unfortunatelly. While converting COBOL to Java converter have zero idea about intention of the code, and can't know what is a feature and what is just sideeffect, so...
That makes complete sense unfortunatelly. While converting COBOL to Java converter have zero idea about intention of the code, and can't know what is a feature and what is just sideeffect, so converter have to keep all quirk in a place.
Everything that I see in the video is just the data model. That's by far the easiest part and could be derived from the SQL database schema using an ORM's code generator.
I want to see 1000 lines of business logic ported over to Java with consideration for whatever idiosyncrasies COBOL has.
From time to time I have the misfortune of dealing with this kind of “Java” code that has been ported over from COBOL. It is the weirdest stuff you’ll ever encounter.
It seems like the way these projects get ported is one component at a time, while keeping all the data formatting (bizarro fixed length text fields, frequently without without line separators) and heavily overloaded custom data types to strictly emulate COBOL behaviours instead of native data types.
That makes complete sense unfortunatelly. While converting COBOL to Java converter have zero idea about intention of the code, and can't know what is a feature and what is just sideeffect, so converter have to keep all quirk in a place.