OpenMRS 2019 Conference Hackathon - Tagging tickets

And here is another idea for the Hackathon: Having TRUNK-5113 for OMRS19 Hackathon.

@jwnasambu @herbert24

1 Like

Hi all,

Thanks for all the interesting ideas, more are welcome! I have come-up with a draft doc(not final), that lists all(I suppose) ideas raised by different community members, feel free to add or edit an entry:

2 Likes

In addition to the above , we can also include

cc @samuel34

1 Like

Will the core still be able to run on Java 8?

1 Like

Now those are some of the issues to consider , because ideally ,there are some backward incompatibilities between java 12 and java 8

@mozzy What advantages does Java 12 provide, which must absolutely be had? Are they worth leaving the rest of the community who cannot upgrade behind? Can the changes be made in a way that does not require JDK version upgrade?

@mozzy do you wanna add your ideas to the shared google doc??

@ssmusoke , ideally we have new great features in java12 ,that java 8 doesnt have, a few of them

  • Switch expressions (JEP 325)
  • Default CDS archives
  • Shenandoah
  • Microbenchmark suite
  • JVM constants API
  • One AArch64 port, not two
  • Abortable mixed collections for G1
  • Promptly return unused committed memory from G1

. We are currently strulgling with optimizing perfomance of the application , and upgrading our java version is one way to improve perfomance.

Usually ,benefits come at a cost. We can think about this starting with platform 2.4 , but am very sure this will be worth the cost.

@mozzy As you and the team think about costs it would be great to have some benchmark numbers is it 10%, 30%, 50% improvement?

1 Like

Just to mention, we’ve created a 2019 Implementers Conference Hackathon wiki page that lists out the topics and issues that have been raised so far, along with space to post notes and presentations that people can refer to after the event. If there’s anything missing or there are new topics/issues to add, please feel free to contribute to the wiki page. Thanks!

2 Likes

Code Commenting / Coding Convention / Refactoring

  • Enforce SOLID PRINCIPLES for upcoming ValillaJS projects(if any) , and some previous because “god objects” make it hard for Refactoring / Bug Fixing . (This Could probably fit in the Unconference sessions)

Hi all, to add on the context of using the DHIS2<>Bahmni integration, Possiblehealth is using the same approach since 1 years and is working perfectly fine (Government Reporting) . We can have the quick catch up session besides the Hackathon. cc @suruchi @laxman @anant.

@nthfloor this is great, am currently working on an ETL for openmrs using kettle for data integration. Meanwhile, you can share the success story with the community. Can i as well schedule a call to discuss this further?

Sure @ggomez , would be glad to share our experiences using PDI!

Are you going to be at the conference next week? We could chat there, or if there is enough interest from multiple parties, maybe even have it as a topic for one of the conference sessions?

@joaomachiana @psmatsinhe @amosh101

2 Likes

This is a great suggestion and for practical purposes, I support this approach @ssmusoke. As has always been agreed, priority should primarily be driven by implementations but also informed by complementary opportunities typically driven at the global leadership level - for example, adoption of new better ways of doing things

1 Like

@ssmusoke Actually, one of the changes in Java 9+ is the new module system which would allow us to write code targeted specifically at Java 12 (say) that would be safely ignored on earlier Java versions.

That said, I think the main improvements aren’t to the language per se, but to the run-time (especially the improvements to garbage collection).

1 Like

@ibacher thats true , most of the above features i mentioned are majorly improvements to the GC

@ibacher I am not against the upgrade, what I am saying is that there must be a compelling reason to do so which can be passed downstream to the implementors.

Taking an example the UgandaEMR team is managing 1k distributed implementations on Java 8 for example and we are running the latest Ref App alebit an older platform 2.0.6.

For us migration has to be planned at least a year in advance and added to budgets, however the reason must be compelling in saving lives not just technical

You are right @ssmusoke

@ibacher Thank you for the excellent discussion and I think we totally a middle ground

  1. Platform 2.x - make possible to run on the latest Java 11, the current LTS version while still compiling on Java 8

  2. Platform 3.x - target the Java 11, the LTS as a baseline compilation and running ability for new versions

Thoughts are welcome

Updated with Java versions with input from @burke