Skip to content

A Dependency Injection framework designed for JVM and Android applications with an Open-Ended API and Submit-Callback features and a specialized implementation for the jMonkeyEngine Applications.

License

Notifications You must be signed in to change notification settings

Electrostat-Lab/Jector

Repository files navigation

Jector Codacy Badge

An advanced DI framework for JVM and Android applications based on the Java Reflection API with a specialized implementation for jMonkeyEngine Applications. Jector provides a programming concurrent (order-parallelism/sync) model for best practices by injecting functions' stacks into schedulable tasks, and in turn into their designated threads. Threads can be activated and controlled to achieve either parallelism or synchronicity.

Software specification:

Item Description
Problem The problem is doing multi-threaded/concurrent code in games is overwhelming and will require you to use synchronization or locks at some point in your application which might disrupt the architecture in your final software product.
Jector Approach Jector solves this by making good use of the DI pattern to bind your proposed function stack frame as a WorkerTask to a TaskExecutor instance, a TaskExecutor instance could be a Thread, a Game State, an Android Task,...etc.
DI Mechanism DI stands for Dependency Injection, as the name implies, it consists of 3 objects, a dependency object, a dependent object, and an injector object, the dependency object contains the delegation code that is utilized by a dependent object, the injector object role is to pass the dependency object to the actual dependent to complete its job.
DI in Jector DI in Jector works by injecting a method as a WorkerTask (dependency) into a TaskExecutor (dependent object) using a TaskExecutorManager (injector object).
Jector in practice Loading game assets asynchronously is now easier, by enabling some tasks to be executed at some point on their respective threads.
Synergism with virtual threads WIP

Building:

┌─[pavl-machine@pavl-machine]─[/home/twisted/GradleProjects/Jector]
└──╼ $./gradlew :jector:build && \
      ./gradlew :jector:generateSourcesJar && \
      ./gradlew :jector:generateJavadocJar && \
      ./gradlew :jector-monkey build && \
      ./gradlew :jector-monkey generateSourcesJar && \
      ./gradlew :jector-monkey generateJavadocJar

Quick Testing:

┌─[pavl-machine@pavl-machine]─[/home/twisted/GradleProjects/Jector]
└──╼ $./gradlew :jector-examples:run

Utilizing in jMonkeyEngine Applications

  • build.gradle:
repositories {
    mavenCentral()
}
dependencies {
    implementation "io.github.software-hardware-codesign:jector:1.0.0-pre-alpha"
    implementation "io.github.software-hardware-codesign:jector-monkey:1.0.0-pre-alpha"
    implementation "org.jmonkeyengine:jme3-core:3.6.1-stable"
    implementation "org.jmonkeyengine:jme3-desktop:3.6.1-stable"
    implementation "org.jmonkeyengine:jme3-lwjgl3:3.6.1-stable"
}

Features:

  • Jector Dependencies are Functional Java Worker methods tasked in a TaskExecutor instance.
  • Multi-threaded async dependency tasking.
  • Single-threaded dependency tasking.
  • Non-threaded tasking.
  • Supports dependency arguments.
  • Supports dependency return objects to the caller (the parent task executor).
  • Supports OO Polymorphism over the Worker classes (need to add all the workers statically to the TaskExecutorManager).
  • Supports Android and jMonkeyEngine Applications.

Featuring the DI pattern:

  1. Dependencies are defined by some Method objects as WorkerTasks.
  2. Dependencies created from Worker Method objects only.
  3. Dependencies are bound to their Executors (threads, states, ...) interfaces via WorkerTasks (which enclose those low-level worker Methods).
  4. Dependencies could be only instantiated from Worker Methods (annotated methods inside Worker classes).
  5. A Worker interface is a marker interface for the Jector Framework.
  6. A Worker implementation signifies a runtime environment for the DI actions.
  7. A TaskExecutorManager implementation has a Worker instance and is the injector object that creates WorkerTasks from Worker Methods and injects them into annotated TaskExecutors.
  8. A TaskExecutor implementation is a wrapper to a collection of WorkerTasks to be executed, TaskExecutor could be a State, a Thread, a Server Container,...etc.