# G.O.D.E.M.I.C.H.E - Getting started {% hint style="info" %} G.O.D.E.M.I.C.H.E stands for Generic Object Data Execution Management Infrastructure Core Helper Engine. {% endhint %} {% hint style="success" %} More than just a library - it’s senior level satisfaction. {% endhint %} > Godemiche is a Java utility library for code that needs three things to be explicit: why an operation failed, where a shared object comes from, and how scheduled work is started, tracked, and cancelled. It is not a framework. It is a small set of APIs for problems that show up in ordinary Java code once a project stops being trivial. Use it when methods return `null` for normal failures, when the same executor or client is created in multiple places, or when background jobs are easy to start but awkward to inspect or stop. The library follows one rule: behavior that matters should be visible in code. If a method can fail, the failure should be part of the return type. If an object should be reused, that reuse should be one direct rule. If a task should repeat, it should have an identifier and lifecycle. That is what Godemiche provides. `Result` handles expected success and failure. `ObjectPool` handles one-time creation and shared reuse. `ScheduledTask` handles scheduled work with identity and control. This library is most useful for services, worker processes, bots, and applications with shared infrastructure objects or long-running tasks. If a codebase has all three problems, Godemiche keeps the solution style consistent. *** ### Install [![Maven Central](https://img.shields.io/maven-central/v/wtf.ranked/godemiche)](https://central.sonatype.com/artifact/wtf.ranked/godemiche) Use the latest version from Maven Central: ```kts repositories { mavenCentral() } dependencies { implementation("wtf.ranked:godemiche:") } ``` Replace `` with the version shown in the badge above. *** ### Operation results - `Result` `Result` is for methods that can fail for expected reasons. Returning `null` only says there is no value. It does not say why the method failed. That forces the caller to remember project-specific rules like "`null` means not found" or "this method throws when the input is invalid". #### Returning `null` ```java User user = userService.findByEmail(email); if (user == null) { IO.println("User not found"); } ``` This looks simple, but the method contract is weak. The caller must already know what `null` means here. #### Returning `Result` ```java enum UserFailure implements ResultReason.Failure { INVALID_EMAIL, USER_NOT_FOUND } Result userResult = userService.findByEmail(email); userResult .success(user -> IO.println("Loaded: " + user.getName())) .failure(reason -> IO.println("Failed: " + reason)); ``` Here the contract is explicit. The method returns either a `User` or a `UserFailure`. Use `Result` for validation, parsing, lookups, permissions, and service rules. The main gain is simple: expected failure stops being a hidden convention and becomes part of the API. Read [**Result**](/core-concepts/result.md) for creation, mapping, recovery, and async usage. *** ### Shared objects - `ObjectPool` `ObjectPool` is for objects that should be created once and reused by identifier. Without it, shared objects usually end up as repeated object creation, manual singleton classes, or static fields with unclear lifecycle. Use it for executors, HTTP clients, parsers, caches, and shared services. ```java ExecutorService executor = ObjectPool.get( "executor", () -> Executors.newFixedThreadPool(4) ); ExecutorService sameExecutor = ObjectPool.get( "executor", () -> Executors.newFixedThreadPool(4) ); IO.println(Objects.equals(executor, sameExecutor)); // true ``` The first call creates the object. The next call with the same identifier returns the same instance. The gain is one clear rule for shared object reuse instead of scattered construction logic. Read [**ObjectPool**](/core-concepts/objectpool.md) for retrieval and lifetime details. *** ### Scheduled work - `ScheduledTask` `ScheduledTask` is for code that must run later or repeatedly and still be controlled. Without it, scheduled work often has no name, cancellation depends on keeping the right `ScheduledFuture`, and active tasks are hard to inspect. Use it for cleanup jobs, refresh jobs, retries, and periodic maintenance work. ```java ScheduledTaskRegistry.common().start( ScheduledTask.builder() .identifier("cleanup") .delay(Duration.ofSeconds(5)) .repeat(Duration.ofMinutes(10)) .run(task -> { if (shouldStopCleanup()) { task.cancel(); return; } performCleanup(); }) .build() ); ``` The task gets an identifier and lives inside a registry. That makes start, cancel, and lookup explicit. The gain is predictable task lifecycle control instead of loose scheduler code. Read [**Scheduled Tasks**](/core-concepts/scheduled-tasks.md) for scheduling and cancellation details. *** ### Where to go next Start with the problem your code already has. Pick [**Result**](/core-concepts/result.md) when method failures are inconsistent. Pick [**ObjectPool**](/core-concepts/objectpool.md) when shared objects are created or stored badly. Pick [**Scheduled Tasks**](/core-concepts/scheduled-tasks.md) when recurring jobs have no clear lifecycle. You can adopt each part independently. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.ranked.wtf/getting-started/g.o.d.e.m.i.c.h.e-getting-started.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.