Skip to content
Skills Library
Programming · Building & coding

neqsim-java8-rules

/neqsim-java8-rules

Java 8 compatibility rules for NeqSim. USE WHEN: writing or reviewing any Java code for NeqSim, including tests. Covers forbidden Java 9+ features, replacement patterns, API verification, and JavaDoc requirements. All NeqSim Java code MUST compile with Java 8.

Repository
neqsim ↗
Licence
Apache-2.0
Last repository change
27.10.2026

Assessment and security

100/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability25 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content35 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
Files in this package
1
Scripts
0
HTML comments
0
URLs in SKILL.md
0
Deprecation

No signals detected. Repository changed on 27.10.2026, without references to retired models or APIs.

Licence

Apache-2.0, otwarta: można używać i zmieniać, z zachowaniem licencji i informacji o zmianach.

What it does and when to use it

Java 8 compatibility rules for NeqSim. USE WHEN: writing or reviewing any Java code for NeqSim, including tests. Covers forbidden Java 9+ features, replacement patterns, API verification, and JavaDoc requirements. All NeqSim Java code MUST compile with Java 8.

Original author description

Java 8 compatibility rules for NeqSim. USE WHEN: writing or reviewing any Java code for NeqSim, including tests. Covers forbidden Java 9+ features, replacement patterns, API verification, and JavaDoc requirements. All NeqSim Java code MUST compile with Java 8.

How it works

  1. Forbidden Java 9+ Features
  2. Common var Replacements
  3. Required Import for String Repeat
  4. Code Formatting (Spotless) — MANDATORY
  5. API Verification (MANDATORY)
  6. JavaDoc Requirements
  7. Build Commands
  8. Serialization — SEBADFIELD Rule (MANDATORY)
Original SKILL.md headings · 129 lines, 632 words
SKILL.md preview
---
name: neqsim-java8-rules
description: "Java 8 compatibility rules for NeqSim. USE WHEN: writing or reviewing any Java code for NeqSim, including tests. Covers forbidden Java 9+ features, replacement patterns, API verification, and JavaDoc requirements. All NeqSim Java code MUST compile with Java 8."
last_verified: "2026-07-04"
---

# Java 8 Compatibility Rules for NeqSim

All NeqSim Java code — including test classes in `src/test/java/` — **MUST** compile with Java 8. The CI build will FAIL if you use Java 9+ features.

## Forbidden Java 9+ Features

| Forbidden | Java 8 Alternative |
|-----------|-------------------|
| `var x = ...` | Explicit type: `String x = ...`, `Map<String, Object> map = ...` |
| `List.of(a, b)` | `Arrays.asList(a, b)` or `Collections.singletonList(a)` |
| `Set.of(a, b)` | `new HashSet<>(Arrays.asList(a, b))` |
| `Map.of(k, v)` | `Collections.singletonMap(k, v)` or `new HashMap<>()` |
| `"str".repeat(n)` | `StringUtils.repeat("str", n)` (Apache Commons) |
| `str.isBlank()` | `str.trim().isEmpty()` |
| `str.strip()` | `str.trim()` |
| `str.lines()` | `str.split("\\R")` or BufferedReader |
| `Optional.isEmpty()` | `!optional.isPresent()` |
| Text blocks `"""..."""` | Regular strings with `\n` |
| Records | Regular class with fields, constructor, getters |
| Pattern matching `instanceof` | Traditional `instanceof` + cast |
| `Stream.toList()` | `.collect(Collectors.toList())` |

## Common `var` Replacements

```java
// WRONG (Java 10+):
var map = someMethod.toMap();
var list = getItems();
var result = calculate();

// CORRECT (Java 8):
Map<String, Object> map = someMethod.toMap();
List<String> list = getItems();
CalculationResult result = calculate();
```

## Required Import for String Repeat

```java
import org.apache.commons.lang3.StringUtils;
// Usage: StringUtils.repeat("=", 70)
```

## Code Formatting (Spotless) — MANDATORY

AI-generated Java is NOT auto-formatted. After creating or editing ANY `.java`
file, reformat it before committing — do not rely on local pre-commit hooks
being installed:

```bash
./mvnw spotless:apply    # reformats Java to the project style (Eclipse profile)
./mvnw spotless:check    # verifies formatting — this is what CI runs
```

- Formatter profile: `.config/neqsim_formatter.xml` (configured in `pom.xml`),
  applied to `src/main/java` and `src/test/java`.
- CI runs `./mvnw spotless:check` and FAILS the build on any unformatted file.
- Run `spotless:apply`, then `git add` the reformatted files, then commit.
- NEVER bypass the gate with `git commit --no-verify`.

## API Verification (MANDATORY)

Before using any NeqSim class in code or examples:

1. **Search** for the class: `file_search("**/ClassName.java")`
2. **Read** constructor and method signatures from the actual source
3. **Use only methods that actually exist** with correct parameter types
4. Do NOT assume convenience overloads — check first

Common API mistakes:
- Assuming `getXxx95()` when actual is `getXxx(int percentile)`
- Assuming 1-arg constructors when 2+ args are required
- Calling methods on wrong class
- Assuming `calculate()` when actual is `calculateRisk()` or `run()`

## JavaDoc Requirements

All classes and methods (public, protected, AND private) require complete JavaDoc:
- Class-level: description, `@author`, `@version`
- Method-level: description, `@param` for every parameter, `@return` for non-void, `@throws` for each exception
- HTML5 compatible: use `<caption>` in tables (no `summary` attribute)
- No `@see` with plain text — only valid Java references
- No lambda arrows (`->`) in JavaDoc code examples

## Build Commands

```bash
./mvnw install                            # full build
./mvnw test -Dtest=ClassName              # single test class
./mvnw test -Dtest=ClassName#methodName   # single method
./mvnw checkstyle:check spotbugs:check pmd:check  # static analysis
./mvnw javadoc:javadoc                    # verify JavaDoc
```

## Serialization — SE_BAD_FIELD Rule (MANDATORY)

SpotBugs enforces that all instance fields in `Serializable` classes are either
serializable themselves or marked `transient`. This applies to any class extending
`ProcessEquipmentBaseClass`, `MeasurementDeviceBaseClass`, `MechanicalDesign`,
thermo phase classes, or any other `Serializable` class.

### When to use `transient`

Mark a field `transient` when its type does NOT implement `Serializable`:
- Functional interfaces: `Function`, `BiConsumer`, `Consumer`, `Supplier`
- JDBC: `Connection`, `Statement`, `ResultSet`
- Threads: `Thread`, `ExecutorService`
- Apache Commons Math: `BicubicInterpolator`, `BicubicInterpolatingFunction`, `LinearInterpolator`
- Inner classes that don't implement `Serializable` (e.g., `NetworkNode`, `GibbsComponent`)
- External library types not designed for serialization

### Correct modifier order

```java
// private fields
private transient MyType field;
private final transient List<NonSerializableInner> items = new ArrayList<>();

// package-private fields
transient SomeType field;
```

### Verify with SpotBugs

```bash
./mvnw spotbugs:check 2>&1 | Select-String "SE_BAD_FIELD"  # should return empty
```

Versions

The database has no other skills named neqsim-java8-rules.

Database snapshot: 13.11.2026 · package version d6c8aad7a1fc (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

  • 100neqsim-code-hygiene
    Fix formatting, Checkstyle, Spotless, and JavaDoc build failures in NeqSim Java code. USE WHEN: the build fails on spotless:check, checkstyle:check, or javadoc:javadoc; a PR shows formatting/import-order/JavaDoc violations; or you edited any .java file and need to make it…
  • 90java-docs
    Java Javadoc best practices. Use when adding or reviewing documentation for Java types, methods, packages, and public APIs.
  • 96neqsim-code-review
    Independently review NeqSim source-code changes for correctness, maintainability, API compatibility, numerical stability, state ownership and performance. Use for code PR review and refactoring acceptance; engineering report review remains separate.
  • 100170-java-documentation
    Use when you need to generate or improve Java project documentation — including README.md files, package-info.java files, and Javadoc enhancements — through a modular, step-based interactive process that adapts to your specific documentation needs. This should trigger for…
  • 96add-public-api
    Add a public type, method, factory or error to this Java library with its Javadoc, example, tests, consumer call and API notes. Use when the user asks the library to expose something new, accept a new setting, or report a new kind of failure.
  • 100java-21-to-java-25-upgrade
    Comprehensive best practices for adopting new Java 25 features since the release of Java 21. Triggers on: ['*']

Feedback and reports

Your message goes to Bartosz Sokoliński. An email address is needed only for a reply. See the privacy policy.