Stream: implementers
Topic: FHIR 1.4.0 Java / HAPI
Igor Sirkovich (Apr 12 2016 at 20:22):
In the FHIR 1.4.0 Java models, there are lots of references to uhn/HAPI, which didn't exist in 1.0.2. I'm wondering if this is a generation error or the intent is to use HAPI in the official FHIR Java code.
Grahame Grieve (Apr 12 2016 at 21:10):
we are gradually merging the two code bases; the current code has dependencies on general hapi libraries
Grahame Grieve (Apr 12 2016 at 21:10):
HAPI in turn uses the the RI java classes as the core model
Grahame Grieve (Apr 12 2016 at 21:11):
so your question about HAPI vs the FHIR java code is no longer a binary choice
Grahame Grieve (Apr 12 2016 at 21:11):
it's more - this is the code that you use, how do you wrap it?
Igor Sirkovich (Apr 12 2016 at 21:28):
Thank you Grahame. This merge actually causes lots of headache to our developers. They used Java models only and didn't plan to use HAPI. Now with 1.4.0 they've got lots of unnecessary (from their perspective) dependencies, coupled with HAPI Rest implementation, which is different from Rest we've been implementing. Also, our Swagger implementation stopped working because of the move to the polymorphic setter methods, for example, from "public void setValueAsInteger(int theValue)" to "setValue(int theValue)".
Grahame Grieve (Apr 12 2016 at 21:55):
you should only get dependent on a single HAPI low level library
Grahame Grieve (Apr 12 2016 at 21:56):
and we didn't take the setValue() method out. So I'm not sure that I follow
Igor Sirkovich (Apr 13 2016 at 14:17):
I mean the methods like setValueAsInteger(int theValue), setValueAsLong(long theValue), etc. were replaced in a new version with polymorphic methods setValue(int theValue), setValue(long theValue), etc. This caused our Swagger implementation to stop working as apparently Swagger can’t handle overloaded methods.
James Agnew (Apr 13 2016 at 14:55):
I'm curious about how the HAPI inclusion is causing pain? It's true that the hapi core library contains the REST framework, and you need that library in order to use the RI structures now, but that doesn't mean you need to use HAPI's rest framework.
I'm assuming you may need to pull in SLF4j as well, but that would be it I would think?
Igor Sirkovich (Apr 13 2016 at 17:55):
The concern is that HAPI REST is tightly coupled with the FHIR models rather than being a separate module and that since REST framerwork has multiple dependencies, loading all these dependencies might bloat the compilation and potentially cause some naming conflicts. Right now we can live with this, but our suggestion for the next release would be to decouple the REST framework from the models.
James Agnew (Apr 13 2016 at 17:56):
What coupling are you referring to? The HAPI REST framework depends on the model, but the model has no dependency on the REST framework that I'm aware of
James Agnew (Apr 13 2016 at 17:58):
In other words, yes you need to include the HAPI JAR if you're using RI structures, but unless you want to use the REST framework, it will never get touched by the classloader.
Igor Sirkovich (Apr 13 2016 at 18:04):
I believe they were referring to "ca.uhn.fhir.rest.gclient..." in models, e.g. in MedicationDispense model.
James Agnew (Apr 13 2016 at 18:05):
Ahh right, yes those are in there now. Those do not actually invoke any of the rest framework though, they will not cause conflicts, or bloat other than 6 extra classes being loaded by the classloader
Igor Sirkovich (Apr 13 2016 at 20:05):
Then this should be fine. Thank you for the explanation @James Agnew .
Grahame Grieve (Apr 13 2016 at 20:26):
Still, @James Agnew, their presence in the jar causes the jar to get big, even if the class loader doesn't load them; it would at least cache thir identity too, wouldn't it?
James Agnew (Apr 13 2016 at 21:09):
Not in a meaningful way. The JVM might cache the existance of extra classes, but until the classloader actually asks for them it wouldn't have a significant impact on memory...
The imact this change has is that a server app being deployed to an app server (e.g. a WAR file being deployed to JBoss) will be a few Mb bigger. But that's a few Mb of disk space, not of memory consumption... which I wouldn't personally consider significant in the context of a server app.
It is definitely significant in the context of an Android bundle though, which is something we're working on getting smaller...
Last updated: Apr 12 2022 at 19:14 UTC
