useful-java-links: a curated Java link index with license tags and star badges

The problem: Java discovery is scattered across awesome lists, blogs and Stack Overflow

Finding a Java library for a specific job usually means reading several unrelated lists. The README of useful-java-links states plainly what it is: a fork of awesome-java with a new structure, additional license info and GitHub star info for every link, plus what it describes as a lot of new links. The stated inclusion rule is blunt. The project covers all non-mobile GitHub projects with 390 or more stars. That single sentence tells you both the audience and the filter. The audience is a Java developer who wants a shortlist rather than a search engine, and the filter is popularity measured on GitHub at the time the entry was added. The repository topics include awesome, awesome-list, java-libraries, java-frameworks and machine-learning, which matches the eight-part table of contents. This is not a dependency manager, not a BOM, and not a compatibility matrix. It is an index with annotations, and the annotations are the part worth examining.

Eight numbered parts, from common frameworks down to communities and books

The table of contents splits the material into eight top-level parts. Part I covers development: common frameworks and libraries, web development, GUI, business, game development, useful libraries, imagery and video, code generation and bytecode manipulation, distributed applications, science and OSGI. The useful libraries subsection is itself subdivided into collections, date and time, dependency injection and AOP, console and command line, functional programming, reactive programming, security and authentication, high performance, serialization and I/O, logging, and bean mapping and validation. Part II covers databases, search engines, big data and machine learning, with subcategories for distributed databases, data structures, search engines, client drivers, ORM, messy data, big data, machine learning, semantic web and linked data, constraint satisfaction, and NLP with speech recognition. Part III covers network and integration across eighteen subsections including servers, messaging, REST frameworks, JSON, CSV, Bitcoin, clouds, cluster management, document processing, native, XML and SOAP, geospatial integration and reverse proxy servers. Part IV is testing, coverage, continuous integration and formal verification. Part V is tooling: IDE, deploy and build, performance tools, code analysis, monitoring, runtime class redefinition, documentation and other. Part VI lists languages and applications written in Java, including parsers, interpreters, compilers, JavaScript tooling, open source applications and open source games. Part VII holds source code examples, benchmark results and git and GitHub material. Part VIII is resources: communities, influential books and websites. The granularity is uneven by design. Some subsections hold a handful of entries, others hold dozens, and the split between Part I and Part III for web-related tooling is not always obvious from the headings alone.

What the license tags and star badges actually record

Each entry follows a consistent shape. The Spring framework entry in section I.1 gives a link to the GitHub repository, a prose description, a license line reading License: Apache 2 with a link to the Apache 2.0 text, a shields.io star badge, a Stack Overflow question count, and an image labelled business friendly license. The Guava entry carries the same pattern with an Apache 2 license line and a note that it requires JDK 1.6 or higher as of version 12.0. Two things follow from this. First, the license field is a snapshot written into the README, not a live query against the project's repository or its package metadata. If a project relicenses after the entry was written, the README will not know. Second, the star badge is an image served by shields.io at render time, so it updates when GitHub updates, while the surrounding prose does not. The business friendly license marker is a human judgement about license category, and the README does not define its criteria in the material available. Treat it as a hint that points you at the license link, not as a substitute for reading that link. The repository itself carries a NOASSERTION license identifier, which means GitHub could not map the repository's license file to a recognised identifier. That is a fact about the index, not about the projects it lists, and it matters if you intend to reuse the list contents rather than read them.

Getting the list onto your machine and finding the hello worlds

There is nothing to install. The material shows no build file, no package manifest and no release artefacts, and the recent releases field is empty. The repository is consumed by cloning or by reading it on GitHub. The README points to two subdirectories by path. The Russian version lives at link-rus, and the hello worlds examples live at helloworlds. The README gives the full URLs: https://github.com/Vedenin/useful-java-links/tree/master/link-rus and https://github.com/Vedenin/useful-java-links/tree/master/helloworlds. A clone followed by a directory listing is the honest way to inspect what is there, because the README does not enumerate the contents of either folder. The default branch is master, so a clone without arguments gives you the branch the README describes. There are no configuration keys, no environment variables and no CLI flags documented in the material. If you were expecting a tool that resolves versions or checks for updates, this is not that. The only interface is the Markdown itself, and the only navigation aid is the Up link that appears under each section heading and returns you to the table of contents.

The 390-star threshold and the staleness it creates

The inclusion rule is stated once and never revisited in the material: all non-mobile GitHub projects with 390 or more stars. That has three consequences worth naming. It excludes useful libraries that are widely used inside companies but sparsely starred on GitHub, and it excludes projects hosted outside GitHub entirely. It also means the list inherits GitHub's biases, including language and region effects on starring behaviour. The more practical problem is time. A star count is a moving number and the README is a static document. An entry can fall below the threshold or a project can be abandoned, and the README will still present it next to actively maintained neighbours with no marker distinguishing the two. Nothing in the material describes an automated refresh job, a last-checked date per entry, or a deprecation marker. The star badge image will change on its own, which makes the page look maintained even where the prose is old. If you are choosing a library for a long-lived service, the README can start your search but it cannot end it. You still have to open the repository and look at its own activity.

How this differs from awesome-java, from which it was forked

The README is explicit that this repository is a fork of awesome-java, and it names three changes: a new structure, additional license info, and GitHub star info for every link, plus a large number of added links. The structural difference is the eight-part numbering with numbered subsections and an Up link after each heading. awesome-java is a flat category list with no numbering and no per-entry license line. That is the real distinction. If you want a short alphabetical browse by topic, the upstream flat list is faster to scan. If you want to see a license tag and a star badge next to each candidate before you click through, this fork saves you one round trip per project. The trade-off is that the fork carries more per-entry maintenance surface. Every additional field is another thing that can drift out of date, and the license line is the field most likely to matter when it does. A second difference is the Russian translation in link-rus, which the upstream list does not have and which doubles the surface area the maintainer has to keep in sync. The last push date on the repository is 2026-05-08, so the index is being touched, but the material does not show which sections received attention.

Who should use this index, and what to check before you commit

Use it as a first-pass shortlist when you are entering an unfamiliar area of the Java ecosystem, for example constraint satisfaction solvers or geospatial service integration, where you would otherwise start from a search engine. The license line and the business friendly marker give you a rough triage before you open each repository. Do not use it as a dependency source, as a version catalogue, or as evidence that a library is maintained. The 390-star threshold is a popularity filter, not a health check, and the README does not claim otherwise. If your project has a license policy, verify the license at the source repository rather than trusting the line in the list, because the line is a snapshot with no recorded date. If you need a runnable starting point, check the helloworlds folder first; the README links to it but does not promise coverage for every entry in the main list. Finally, note that the repository's own license identifier is NOASSERTION. If you plan to copy the list into your own documentation or tooling, resolve that question with whoever handles licensing on your side before you do, since the material here does not state the terms.

Editorial conclusion

Adopt useful-java-links if you need a starting shortlist of Java projects with license information already attached, and treat the star badges as a filter the maintainer applied rather than a quality signal. Skip it if you need per-entry freshness guarantees or a machine-readable dependency index, because nothing in the repository confirms either. Before relying on it, open the helloworlds folder and confirm the example you need actually exists, then check the license link on the specific entry you plan to use.

Official sources

1. Issues
2. README
3. Vedenin/useful-java-links on GitHub