Idea Details

Gen Java runtime versioning impact on upgrade overhead & lack of backward compatibility

Last activity 07-25-2016 05:59 PM
Anon Anon's profile image
09-25-2014 09:56 PM

Having versioning in the Gen Java runtime package causes a significant overhead at upgrade time due to the required regeneration of all the code which directly references those packages.

Granted that regeneration may be required to be on a supported release but there can still be a large impact due to regeneration of External Action Block stubs etc.

If the versioning was removed it would also be very beneficial if earlier version Gen Java generated code was officially supported/compatible with later version runtimes in the same way it is for Gen z/OS generated code e.g. Gen 7.6 & 8.0 generated code is compatible with Gen 8.5 z/OS runtimes.


Comments

07-25-2016 05:59 PM

Delivered with Gen 8.6

08-27-2015 04:48 PM

This idea is planned for 8.6.

09-30-2014 06:28 PM

Actually, I don’t think we’d need another regeneration as we’re thinking of leaving the names as they are right now.  In other words, when we put out release 47.0 of Gen, the runtime names would still have ‘85’ in them.

09-30-2014 06:47 AM

All very valid points Darius.  I don't think anyone's suggesting mixed action blocks across multiple versions together, though that would be a very interesting idea.  Your spot on as to why it wouldn't work though, as is.  And you'd absolutely have to do one more regeneration at a future level as the forward planning isn't there for it now.

 

I think GlobData isn't a deal breaker.  It historically hasn't changed much, with (at least going back to 5.1) changes being filling in of the slack space bytes they've reserved with new fields, and not modifying existing fields.  If such changes continue ahead, they can mitigate it's impact on runtime callers.  But it would require that the GlobData instance be obtained from the runtimes and not instantiated directly.  You could probably consider GlobData a superclass to future variants, and as long as the runtimes are the factory for it's creation, you should be OK.  However, things like the CFB, if they change it, certainly are potential deal breakers for deployment - if nothing else, it'll constrain interoperability to same versions, so you'd have to upgrade Clients and Servers together, if this changes in future.

 

I won't speak to Unix/Linux variants of C, but you have no drop-in upgrades on Windows/C, only side by side.  If nothing else, the change in supported compilers from release to release means you have to regenerate, as the MSVC++ runtimes linked at each compiler are different, and you can't cross boundaries in that regard.  Plus they've versioned more and more of the DLLs (e.g. tiodbc##n.dll), so they'd have to go back to unversioning this, even if they can surmount the MSVC++ problem.

 

It's a painful problem, and it'll have to transition at least once more.  But there must be a way to do it, provided they don't need to change the runtime interfaces again.  But then, they'd have to version it then (and sell it to customers as to why they had to, as it's no small pain point for them).  It's valuable to end customers.

09-30-2014 06:08 AM

The big difference between C/COBOL and Java is that for C/COBOL runtimes, globdata and other bits of view data can be passed into the runtimes or other action blocks from the calling action block as a pointer, so for example a Gen 8.0 generated action block can call a Gen 8.5 runtime function.

 

It does not work this way in Java because the objects are specific to the Gen version package, so a Gen 8.0 generated class contains a Gen 8.0 globdata class and view classess and these cannot be used by the runtime for any other version. It means that all action blocks in an application need to be generated from the same version of Gen, otherwise they cannot be used together.

 

Would it be possible to have a solution that did not require the regeneration of code between releases, for example by making the runtime objects that need to be passed around independent of the Gen version and in a separate package to the version specific runtimes?

 

Obviously there would have to be one more regeneration to implement this, but once done, no more need to regenerate old code for a new version of Gen. The interface to the runtime objects like globdata would then always have to be backwards compatible, i.e. never renaming or deleting class names, methods and variables.

09-28-2014 06:40 PM

I would think you could still enable the side by side functionality.  After all, it (at least for Java) is all about CLASSPATH resolution.

 

If the build process allows for embedding the Gen runtimes directly in the EAR/WAR file, then it should resolve from that before resolving from an outside/global location.  So when upgrading, if you inject the old runtimes into the EAR/WAR, you should still retain side by side ability.  Obviously not something you necessarily want to do on every build, as it also means you can't just do a drop in replacement.

 

I would expect PATH manipulation would also work for the C# bits, as long as the new and old application aren't running out of the same folder.  For IIS/ASP.NET stuff, you might be able to circumvent it through judicious use of Application Pools and user selection.

 

So I don't think you necessarily have to give up side by side while retaining drop-in replacement capability/simplified upgrades.

09-26-2014 09:42 PM

For most upgrades, applications need to run side-by-side as part of the upgrade delivery.  Pretty similar to the reason that the new toolset is deployed side-by-side for developers, with the old one - contingency and cut-over.  Only where the CA Gen portfolio is a single application is there an application runtime deployment in the new version with no concurrent old-version applications. 

 

So... generally the side-by-side execution is a normal requirement during an upgrade, and as highlighted by The Dans, avoidance of version-specific runtimes, where the interface hadn't changed, would simplify upgrades. 

09-26-2014 03:18 PM

The reasoning behind having runtimes with the version name included was to enable side-by-side running of applications.  The approach we're thinking of taking is to leave the names of all versioned files just as they are with 8.5 (for C, C# and Java).  I believe that this is similar to how the z/OS runtimes work.  It's going to make running applications at different Gen version levels more difficult but it should make upgrades much easier.

 

Is anyone concerned about the loss of side-by-side or is the potential for easier upgrades worth any reduction in functionality as far as running different versions on the same environment at the same time?

09-26-2014 12:10 AM

I think your idea is sound, but that they still need to retain the ability to version the runtimes as needed.  It should just not be tied to a product release, but an interface.  If they find they have to break the interface of the runtimes (parameters, names, etc.), then they'll have to version for incompatibility, or it'll be a god awful mess.

 

But if it's a straight refinement/bug fixing change, and the interface from Java generated within Gen to the runtimes hasn't changed, then I agree - it shouldn't be packaged under a new version, but retain the existing one.