You want the code in front of you
Open the project you are already changing. AtlasArc builds its architecture model locally from JVM bytecode or the TypeScript artifacts you generated.
Compare
Architecture work, back inside the code
AtlasArc makes architecture a daily practice inside IntelliJ. Run it completely local on the code in front of you, move through five connected lenses, follow findings to source, and carry the cycle decisions that matter into reports and AtlasArc.io CI.
Coming from
Stan4J or Structure101
Bring serious local structure reading into a current IntelliJ workflow.
Comparing Sonar ArchitectureSee why a daily architecture practice needs more than a centralized governance map.
Comparing locally CodeMR or ArcTreeSee what changes when the investigation leads, instead of chart setup or one dependency view.
Screenshot: one AtlasArc investigation moving through Topology, Matrix, cycle evidence, and an Architecture Report
Fit
Which architecture workflow do you need?
You do not need every architecture tool to do the same job. You need the one that fits the question in front of you.
You want the question to move
Go from Topology to Matrix, Composition, Subsystems, or Hotspots without rebuilding the model or losing the investigation context.
You want the result to survive the session
Follow findings to source, record durable cycle decisions, and carry the evidence into a browsable or printable Architecture Report.
Advantage
Where AtlasArc earns its advantage
The products overlap. AtlasArc earns its advantage by keeping the investigation connected from the first question to the final decision.
| Architecture need | AtlasArc | Sonar Architecture | CodeMR | ArcTree | IntelliJ tools |
|---|---|---|---|---|---|
| Access | |||||
| Trying it without procurement | Permanent Free: graph, committed cycle decisions, Apache-2.0 CI gate, and one-page summary. Optional 30-day Full Workspace trial. | SonarQube Cloud includes Architecture on its Free plan; paid plans have a 14-day trial. | Community edition covers up to 50 source files and 60 classes; larger analyses use a trial or Enterprise license. | Two-week free evaluation; annual subscription afterward. | Free core IntelliJ IDEA; 30-day trial for the Ultimate feature set. |
| Daily working loop | |||||
| Where the work happens | The complete investigation stays inside IntelliJ. | Web architecture workspace, with issue feedback available in the IDE. | Local IDE plugin around an extracted model. | Local IntelliJ dependency explorer. | Native IDE inspections, diagrams, and navigation. |
| Feedback on current code | Run completely local on the project you are changing. | Refresh through another project analysis. | Refresh the local analysis model. | Rebuild the local dependency model. | Inspect the current project through each tool. |
| Investigation | |||||
| Ways to read the architecture | Five connected lenses over one shared model. | Current and intended web maps. | Several configurable metrics and structural views. | One focused dependency view. | Separate analysis and diagram surfaces. |
| Reframe the question | Root, Pin, Neighbourhood, Boundary, hierarchy expansion, and shared filters. | Map selection and high-level structural reads. | Filters, queries, and working sets. | Focus modes and dependency filters. | Scopes within the individual tool. |
| Find where attention belongs | Heatmaps, Hotspots, Galaxy, overlays, and metric evidence in context. | Architecture deviations and tangles. | Metrics dashboards and configured charts. | Dependency and cycle emphasis. | Separate inspections and analysis results. |
| Investigate a cycle | Select the group, inspect it in Graph and Matrix, separate structural loops from the problem graph, then decide. | Review tangles and turn selected relationships into centrally managed issues. | Read relationships through structural and graph views. | Highlight cycles in the dependency view. | Run cyclic-dependency analysis. |
| Evidence and outcomes | |||||
| Follow a finding to code | Open dependency and metric evidence, then jump directly to source. | Issue locations and IDE handoff. | Source navigation from local views. | Source navigation from dependencies. | Native IDE navigation. |
| Keep a decision | Use local Safe Havens or commit reviewable cycle decisions for the team and AtlasArc.io CI. | Central intended-structure policy and issue governance. | Saved models, configurations, and reports. | Local exploration remains the focus. | Dependency validation rules in the Dependency Viewer. |
| Carry evidence beyond the view | Browsable and printable Architecture Reports, plus PNG, TSV/CSV, and DOT. | Shared hosted results. | HTML reports. | PNG export. | Tool-specific exports. |
| Project coverage | |||||
| Architecture languages | Java, Kotlin, and TypeScript in one architecture workflow. | Java and TypeScript in the current Architecture list. | Java, Kotlin, and Scala. | Java and Kotlin. | Varies by analysis surface. |
Product claims reviewed on 28 July 2026; access terms rechecked against first-party material on 2 August 2026.
IntelliJ
Take the dependency question through an architecture review
IntelliJ answers the dependency question. AtlasArc answers the one it creates.
| Area | IntelliJ built-in dependency tools | AtlasArc contrast |
|---|---|---|
| Best fit | Inspect dependencies, module relationships, cyclic dependencies, usage paths, and package/class relationships inside the IDE. | Run a repeatable review: map, diagnose, expose, prioritize, govern cycles, and report. |
| Graph support | Module, package/class, and Gradle/Maven dependency diagrams for their supported project models. | Interactive Topology with scope, focus, package/source-folder expansion, cycle-group reads, and contained class/file evidence. |
| Matrix support | DSM support for matrix-style dependency exploration, with an Ultimate subscription and the relevant plugin. | Dedicated Dependency Matrix over the same model, subject, filters, and cycle posture used by the other structural lenses. |
| Cycle support | Cyclic-dependency analysis and visual highlighting of circular relationships. | Dedicated cycle investigation that distinguishes structural loops from the problem graph, holds a selected cycle group across Graph and Matrix, and keeps governed decisions visible. |
| Navigation | Strong IDE-native navigation: jump to source, find usages, and inspect dependencies. | Keep those navigation strengths, then pin a subject, inspect its boundary, and follow the evidence across connected lenses. |
| Decluttering and governance | Dependency validation rules classify relationships in the Dependency Viewer. | Local Safe Havens declutter a view. Repository scope and cycle decisions remain separate, reviewable inputs used by the IDE, reports, and AtlasArc.io CI. |
| Reporting and export | Dependency analysis and diagrams provide their own text, clipboard, or image export paths. | PNG, TSV/CSV, DOT, browsable HTML Architecture Reports, and Printable Version carry an investigation beyond the live view. |
| TypeScript | Module dependency diagrams. | TypeScript architecture exploration from user-generated dependency-cruiser artifacts. |
So when should I open AtlasArc?
Use IntelliJ's tools for the quick dependency question. Open AtlasArc when the answer creates the next question: how does this boundary behave, which packages carry the risk, where does the cycle really close, what should the team remember, and what evidence belongs in the report?
Sonar Architecture
Architecture you can work with before it becomes a gate
AtlasArc starts before architecture becomes a gate. Open the project you are changing, reshape the question across five lenses, and follow the evidence to source. No hosted project. No wait for another analysis result.
Sonar Architecture starts from centralized policy. A tech lead shapes intended relationships in a web workspace, and the workflow returns code-level findings to developers as issues. That is a governance loop. It is not the daily local architecture workbench AtlasArc is built to be.
AtlasArc carries its own decisions forward. Commit a cycle decision when it should outlive the session, include it in the Architecture Report, and let AtlasArc.io CI apply the same verdict. Local investigation and downstream feedback stay in one product loop.
See how AtlasArc.io CI carries decisions forward →CodeMR
Read the architecture, not the cockpit
AtlasArc organizes the experience around the investigation itself. Change scope, follow a dependency, switch lenses, inspect source evidence, triage the cycle, and report the result without changing models.
CodeMR offers a broad local metrics and visualization suite. AtlasArc keeps the architecture question moving across one connected model. Less chart setup, more time with the architecture itself.
Explore the five connected lenses →ArcTree
Keep going after the dependency appears
AtlasArc keeps the local dependency question moving. Inspect the boundary, test the cycle in Matrix, or bring metric evidence into Hotspots without leaving the shared model.
ArcTree focuses on local Java and Kotlin dependency exploration. AtlasArc carries that first view into a wider architecture investigation with connected lenses, reports, and cycle decisions.
See the complete investigation loop →Stan4J alternative
Coming from Stan4J
Stan4J served a real need: local Java structure analysis that made dependencies, cycles, tangles, and metrics visible. If that is what brought you here, the real comparison is not whether AtlasArc reproduces every old screen. It is whether the same architectural questions have a serious home in a current IntelliJ project.
AtlasArc brings direct structural visibility, interactive package exploration, cycle diagnosis, architecture metrics, and source navigation to Java and Kotlin bytecode. It applies the same investigation model to user-generated TypeScript dependency artifacts.
Structure101 replacement
Coming from Structure101
Structure101 was a serious architecture suite: LSM exploration, dependency matrices, authored structure specs, build checks, reports, and snapshot workflows. It is no longer sold, which leaves a real gap for teams that still need to inspect and explain architecture inside current codebases.
AtlasArc covers much of the daily work former users miss: Graph and Matrix navigation, subject and boundary reads, cycle triage, hotspot prioritization, repository cycle decisions, and Architecture Reports. It is not a clone of every historical Structure101 specification, repository, or build workflow.
Companions
Rules, TypeScript artifacts, and cycle governance
Turn evidence into the right kind of rule
AtlasArc's native governance stays focused on concrete cycle decisions. When broader JVM policy belongs in test code, AtlasArc gives you the visual and source evidence needed to understand what that rule should protect.
Use the AtlasArcArchUnit adapter →
Bring TypeScript artifacts into the same investigation
For TypeScript, AtlasArc reads dependency-cruiser JSON generated by your project. It turns that artifact into a navigable architecture model; it does not replace dependency-cruiser's parser, rules, or CI use.
TypeScript support →Carry AtlasArc cycle decisions into CI
The JUnit adapter puts the complete configured Java, Kotlin, TypeScript, or mixed-stack verdict into an ordinary test. Run the same evaluator as a standalone process for machine output, or add its native rule to an existing JVM ArchUnit suite.
JUnit adapter recipe → AtlasArc.io CI guide →
Scope
A focused promise, carried all the way through
- AtlasArc is an architecture investigation workbench, not a general code-quality or security platform.
- Repository governance and AtlasArc.io CI carry concrete cycle decisions, not an open-ended architecture-rule language.
- Java and Kotlin analysis is bytecode-backed. TypeScript analysis reads dependency-cruiser artifacts generated by your project.
Try it on your architecture
Run AtlasArc on the codebase you already know
The fastest way to judge an architecture tool is to give it a codebase you already understand. See what AtlasArc confirms, what it challenges, and where the first surprise leads.