It seems classes built for Java 1.8 do not always run with classes built for Java 1.6.
Since OpenMRS 2.0 platform is built for Java 1.8, it is difficult to build Reference Application modules which will run on earlier OpenMRS platforms.
How are we going to handle this situation?
One way is to have separate branches for the Reference Application modules rather than trying to have one omod run one OpenMRS 2.0 platform and earlier versions.
Any ideas on how to proceed?
@raff, RA-954 documents my efforts to build reference application modules. Detailed information per module is given in the sub-task for the module.
My latest problem is with uiframework, in which I used the various schemes to conditionally build for various platform versions, essentially based on webservices.rest and the associated wiki page.
The problem is the tests don’t run for earlier versions of the platform because of an error stating class layout is incompatible.
Create a 2.0 version of each module and compile with 1.8 for instance? I’m sure there’s a catch, but it seems the most logical.
fyi, don’t know if is related or not, but I ran into a recent issue where some modules (metadata sharing, registration app) no longer compile using Java 6. I added a comment to RA-954 with my findings.
I had assumed that we would build only openmrs core with Java 8, and we would continue building reference application modules with Java 6 as long as we are still supporting the current platform versions of openmrs.
What is a specific example where we are building a module with Java 6 and it won’t run on platform 2.0?
Trying to build uiframework (Java 1.6) against OpenMRS 2.0 (Java 1.8) fails when the module tries to compile against Concept. It seems the class layout versions Java 1.6 - ver 50 and Java 1.8 - ver 52 are incompatible. I suspect cross java builds will also have problems with any code relying on reflection if nothing else.
Test building with Java 1.7 has the following results: as @mogoodrich indicates most classes build but classes using reflection fail.
Why do we need to build UI Framework against platform 2.0?
We should only need to run it that way, not build it.
There have been some significant changes affecting uiframework.
The NameTemplate package has changed. Also, as part of TRUNK-4747 activelist.Problem has been removed from OpenMRS 2.0 platform, uiframework creates a converter bean based on this class.
I have to test an existing build against OpenMRS 2.0 platform, however these changes are likely to occasionally cause failures.
Generally speaking I would prefer that we try to do special-case hacks for these things (e.g. use reflection, the @OpenmrsProfile annotation, and dynamic bean definitions) but keep building the module with Java 6.
Just to be clear, we currently are NOT taking that approach, @darius. As RA-954 gets made to each module, I need to start building it with Java 7 instead of Java 6. So seemed like we need to put the brakes on / have a design call if you feel strongly about this. (Unfortunately, I haven’t been following the issue closely to understand the underlying issues, nor do I know if we are breaking running the modules with Java 6).
Mark
Some guidance is still needed on this topic in order to continue work RA-954 and child tickets…
Though some of the problems identified earlier in this thread was due to a wrong approach in building modules for platform 2.0, there has to be a decision on how best to approach this problem in general.
Is it the consensus that we should keep one trunk for all branches, build against java 1.6 and use conditional compilation (and reflection) to handle API changes, or do we want to branch out for various module versions to support different platform versions?
I don’t know enough about the issues to know if there is a generally applicable answer to this, or if it needs to be done on a case by case basis per module.
But my baseline expectation would be that most of the refapp-included modules continue being primarily built against platform 1.x, as long as we are supporting platform 1.x release lines, and that their platform-2.x components are added in a maven submodule.
I would generally expect that whoever is updating a module to work with platform 2.0 should chat with the module owner about how they want to approach it. If that has already happened, or if module owners don’t actually want to have this level of input, then I don’t want to slow things up.
Is there an illustrative example of a module that has already been updated, and this update is not huge, so we can start discussion from a real example?
@darius, the fact is many of the modules are now building fine along the guidelines you suggest anyway.
(A lot of the problems I was initially having was because of a misunderstanding I had about how to proceed with the build test.)
If I run into any difficulties requiring a different approach to what you are suggesting I will highlight the module then and the discussion can proceed from that example.
The approach we have been using is described at: https://wiki.openmrs.org/display/docs/Supporting+different+OpenMRS+versions
We could start this discussion with the coreapps module. The changes are mainly two as summarized below:
In platform 2.0, the AddressSupport and AddressTemplate classes were moved from the “org.openmrs.layout.web.address” to the “org.openmrs.layout.address” package.
EncounterService.getEncounters() was changed from one that takes very many parameters to one that take just one EncounterSearchCriteria parameter.
The full commit is at: https://github.com/openmrs/openmrs-module-coreapps/commit/216a570b94a7743da4e93b5345660cdd2e334ef7
After discussing the above, i can put up another with more changes until when we shall have the reporting module, which is one of those with the biggest changes. 
Are you saying that we removed a non-deprecated EncounterService method when we introduced EncounterSearchCriteria? That sounds like a mistake to me.
A few months back the old classes still existed but were deprecated. At that time I addressed the backwards compatibility issue by refactoring the Spring bean definitions and adding a a set of old-style templates. Looks like possibly someone has removed the deprecated classes already? One option to avoid lots of 2.0-specific builds would be going through a deprecation cycle.
Also in this particular case I thought the new classes had been backported to previous core versions. In which case the modules could simply be updated to build against the backported classes, no need to create a 2.0-specific build?