Integrating with Platform and Library Dependencies is a Developer Hell for Coding, Integration and Testing. You must overcome million obsticles , dive deep into technical details to come up with solutions or at least workarounds. Long time ago – in a galaxy far, far away – I’ve integrated into Liferay Portlet, Struts 2 Framework, Google Web Toolkit and ExtJS. But. let’s get to more recent stuff.
The Java ecosystem is enormous. You could find libraries for:
- Desktop, Mobile, Web.
- Compilers and Cross-Translations
- Cryptography, Image Manipulation
- PDF reading/writing, JSON Parsing and Writing
My problem is there are million platforms the the code runs on with their own personal limitations. Write once – run enywhere – some other time.
Quarkus and Reflection
I’ve scratched Quarkus lately. It runs NOT on a standard Java Runtime, but on modified one (GraalVM). It has the advantage of super-fast start-up, but, your app must not use reflection. There are alternative implementations or extensions for everything:
- Dependency Injection
- JPA
- JSON
- REST Annotations
- etc
Where you could – you must reuse the existing library from the Java Ecosystem and just add an extension. Where there is not yet an extension – you are out of luck.
GWT and NextJS
Similar to Quarkus, in Google Web Toolkit – out of the box you could use a some part of the Java Libraries on the client side. It is a framework the compiles Java code to JavaScript – much like dart, typescript, or the JavaScript templating used in React. Only, the logic that is translated – must not include something from outside of the box – where GWT has the ability to cross-compile.
Vaadin API to Web
I’ve picked Vaadin (with combination of Spring) – as it lifts a lot of the complexity of the Web and makes you focus more on the true business logic. But, I/you must never forget you are coding inside a bubble. If you plug in in you app:
- a REST endpoint
- standard web page or web servlet
Whatever that is not Vaadin Managed – you must bridge the result of the logic to the Vaadin components and not depend on its APIs in the outside world. Vaadin has static methods to get
- to the Http Request
- to the Session
- the client-side JavaScript logic and variables.
But, all of them are not-null – only if accessed from Vaadin Components.
I’m personally using Vaadin Framework: https://programtom.com/dev/product-category/technologies/vaadin-24/
Spring Context
Spring Framework manages beans of components that it could Inject in each other. This was just the basis:
- bring convension over configuration to the top
- to promote strict component layering and SOLID principles
- to allow extensibility, mockability (by switching the implementation during tests) etc
If you are using Spring Framework, all logic must and better be inside some component, if you have something external, you must handle it yourself.
I’m personally using Spring Boot Framework: https://programtom.com/dev/product-category/technologies/spring-boot-framework/?orderby=date-desc
Hibernate/JPA
Hibernate and JPA create a layer above the database. In most of the cases you tell the layer to save your data and it translates to the database – when it finds appropiate or fetch from it. It brings performance app – when it is feched from the app cache. There are additional methods – to skip and do the logic directly. I’ve seen cases – where a single database is accessed by multiple software components. In these cases:
- You either use the JPA methods that execute the logic directly onto the database
- Or you use Messaging systems like Kafka or RabitMQ
Other thing to care is taking into account into your logic – where did the Database Models have been created. If they were created outside of JPA – they are dirty.
Android Context
The Android Context is crucial point of your app. You must take into account from where you have accessed it
- Applicaction,
- Service
- Activity or Fragment
- etc
In all cases you must take care if it is alive, because a mobile app life could be very dynamic.
Flutter State
Flutter has StatefulWidgets that have changable state during its lifecycle.
- It is similar to the Context of Android Activity or Context.
- And Similarly to Android LiveData Components, You could use some of the many State Management Solutions that protect you to shoot yourself in the foot and make the code platform independently testable.
And off course this means using Provider (or some other library) for dependency injection. You must take care of the tree of defintions, otherwise – the framework will not be able to access the beans.
OS level differences
From my experience in Android and Flutter development, you code your app inside the APIs given by the Platform or the Framework Developers. These APIs translate the logic to the below low level libraries and hardware. But, unfortunately – the world is not perfect. Especially in Android – that is open source – there are million variations of Hardware and beyond that – Changes to Anrdoid and ultimately – to Google Services – that you need to take care. Not all devices have Google Services. The versions of the Operating System change like the blink of an eye.