Many Times in Software Development, Coders get into a Dependency Hell. Figuring out the working versions of one source code library with another is one big unproductive moment. Instead of focusing on meaningful, visible business logic, we [developers] are often fighting the tech stack itself.
From one hand – there are source code repositories that – a lot of times reason for the success of a library, platform or programming language. When you are requested a feature and you have where to look, you save time. Unfortunately, many times the newer versions break the working dependencies with others, if you just bump up the number and update. So a search starts of the minimum amount of incompatibility that will not break the whole software down.
The other aspect is the endless and continuous development of the software. Many times packages switch structure, names and even programming languages. Here I’m gonna point out the Platforms I’ve scratched over the years.
Java
The Java programming platform is using two major dependency systems – Maven and Gradle. They have their own settings for Java Version, for building organization, for dependency repos and settings. Problems start to arise when a software expands and two modules depend on different versions of a same package. One solution over the years was class loading isolation, so version don’t mix. Tech like OSGI and Jigsaw are trying to fix this. They have probably resolved it at the corporate level and products. As a new starting project, I’ve not seen yet their use – from scratch, so dependency problems to not appear.
JavaScript
JavaScript has NPM dependency management system. The hard part here comes from that – JavaScript is interpreted language and bugs may appear at runtime in their edge cases and usages. I for example tried React Native in 2017 – that sits on top the JS community and the result was hell. Unknown errors and bad developer experience. They may have improved it, but, I am away from it at the moment and I don’t have any desire to go back.
Android
Android sits on top of subset of Java. It is using Gradle as a build system. The problem resolving, but many times – also – creating elements here are:
- Dependency Injection
- Integration of Code Generation Utilities
- View and Code Binding
- Mixing too much – Java and Kotlin code and having them both as choices. I’ve abandoned one ORM in my GeneratorApp for example, because of issues that were in status “Cannot Be Resolved at the moment”.
- Migration of library packages from support to androidx naming system.
Just, have all of these bullets in one project and start having “fun”.
Flutter
The Cross-Platform Framework Flutter sits on many chairs simultaneously. Dart – the language used for programming it has a pub.dev source code repository.
If it was only itself, it would be similar to Java, but better. Unfortunately, it depends on all native platforms and inherits their problems.
- It has the iOS problems – when building for the Apple Platform (dependencies, native code /c++, objective c, swift/, permissions and other custom Cupertino stuff.
- Some of the Android problems also appear here.
- The Desktop targets are currently babies so, await compatibility issues. Many of the code is generated, some of it is native (c/c++), and who knows what more.
- The Web has the JavaScript and the Browser Compatibility issues.
Above all that, Google Dart/Flutter team introduced null safety mode in the language. Now, there are endless number of legacy projects and setups, and some migrated to null-safety and have some of the rest pains. If you feel adventurous, you could try also some of the non-master dev channels of Flutter, where things are not yet so polished.
So, good luck escaping the problems and being able to focus on pure business logic and algorithmic and meaningful for the user – source code.