JBook is a Java study project that is explicit about not being finished

A knowledge base, and the outline is the product

JBook covers algorithms, patterns, interview preparation, articles and materials on Java, and the repository title names the format, a book. It is a set of notes, not a codebase, and the top level of the repository is the evidence.

There is a table_of_contents.md that the README calls the guide to the project, which is where a reader should start, and around it sit the topic directories: algorithms/, patterns/, frameworks/, interview/, course/, testing/, serialization/, db/, logging/, kafka/, zookeeper/, web/, jcore/, build/ and other/. There are also images/, the design_requirements.md that contributors are told to follow, and and a pull request form.

That directory listing is the honest description of the project's coverage. Algorithms, patterns and interview preparation are the three things the description leads with, and the rest of the tree shows a working engineer's notes rather than a course: framework internals, databases, logging, Kafka, ZooKeeper, web work, testing, serialization, and a build directory.

The name jcore, sitting next to kafka/ and zookeeper/, suggests a section on the Java core libraries, and the course/ directory alongside interview/ suggests that the project treats a structured course and interview preparation as related but separate bodies of material.

The audience is therefore a Java developer preparing for interviews or filling a specific gap, and the usage mode is reading rather than running. There is nothing to install and nothing to import, which is also why the absence of code in the tree is not a gap in the project but the project itself.

The method is to explain until you understand

The Why this is written section gives two goals, and they are the reason the project is structured the way it is. The first is systematising the author's own knowledge, and the second is helping people learn various areas of Java.

The stance on cost is stated as a principle rather than a promise: learning programming should not be paid for by those who want to learn. The motto that follows is a compact description of the method: learn something, then try to explain it until you understand it yourself.

That sentence explains the project's character better than any feature list could. A note that is written to be explained is not the same artefact as a note that is written to be read once. It means the material is organised around the author's own route through the subject, with the detours and the parts he had to work through, which is a different thing from a syllabus and a better thing for the reader who is stuck on a specific topic.

The invitation to contribute follows the same logic, and the request for feedback is placed in the middle of the introduction rather than in a contribution section, which is consistent with a project whose main product is the quality of the explanations.

The acknowledgement section names two contributors, cac03 and mikhailchuryakov, and the copyright line runs from 2016 to 2026 for Aleksandr Kuchuk, which puts the project's span at a decade of writing.

The project tells you it is unstable

There is a warning near the top of the README, and it is unusual to see it stated this plainly. Remember: the project is in development and both the contents of the articles and the structure of the project itself may change.

For a knowledge base that is the most useful sentence on the page, and it cuts both ways. For a reader it is an honest warning that the table of contents is a snapshot rather than a contract, so a link that worked last month may point somewhere else now, and a topic that looks covered may be three paragraphs long.

For a contributor it is an invitation with a condition attached, and the condition is the design_requirements.md file. Contributors are told to follow the formatting recommendations when writing, which implies a house style for how a note is structured, not just what it contains.

The pull request form in the repository root is the other half of that apparatus, and it is the difference between a repository that accepts patches and one that accepts contributions. Asking about structure and language keeps the collection coherent as more people write in it, and the README's request to become a reviewer rather than only a star is an explicit ask for that kind of help.

So the warning and the structure are two halves of the same decision. The content is a moving target, and the process around it is what keeps it usable while it moves.

The licence is not an open source licence

The copyright section is the part of this repository that an engineering organisation should read before anything else, and it is deliberately restrictive.

The copyright line says that copying and reproducing the materials of this project is possible only with the consent of the author, and that it is not allowed to use this in paid services or to charge any fee for teaching based on these materials. The copyright is held by Aleksandr Kuchuk for 2016 to 2026, and the notice ends with All Rights Reserved.

That is not an open source licence, and the licence field on the repository is recorded as unknown, which is consistent. The practical reading is that the material is free to read and to learn from, and free to fork and contribute to, but it is not free to redistribute as a course, a paid product, a training package or a commercial service.

The distinction matters because knowledge bases are exactly the kind of artefact that gets republished. A company assembling an internal curriculum from a set of articles is republishing, and the terms here say that needs the author's permission. A reader in a company that is considering that should email the address given in the README, [email protected], which is also the contact for contributions.

This is not a criticism of the choice. A personal study project that took a decade to write, with an explicit rule against commercialising it, is a coherent position, and the fact that the restriction is stated at the top of the README rather than buried in a licence file is a courtesy. The one weakness is that the machine readable licence field says unknown, which is what a scanning tool will report, and a tool cannot read the paragraph in the README.

How to help, and what a contribution looks like

The README gives three ways to support the project, in increasing order of usefulness.

The first is a star. The text explains why in a way that is worth repeating because it is unusual in a README: a star adds motivation to keep developing the project and serves as a beacon showing the author is not doing this for nothing. The second is to become a reviewer, and the third is to become a contributor, which the README calls the better option.

The mechanics of contributing are simple. Write to the author at the address given, or fork the project and send pull requests. The README says any feedback is welcome, and it asks that people follow the formatting recommendations in design_requirements.md when writing.

The two named contributors are thanked separately in a section of their own, which suggests the project has grown past a single author while keeping the voice of one. For a knowledge base, that is the interesting part, because the quality of a personal set of notes depends on the author's own understanding being sound, and a project that takes contributions from others has to give those others a format to write in, which is what design_requirements.md and the pull request form are for.

For a reader, the practical first step is the table of contents. The repository is a decade of notes, so the question is never whether there is material on Java here, it is whether the material on the specific area you are stuck in is finished, and the honest way to find out is to open the directory and read.

A useful archive, with the caveats that come with it

The licence field on the repository reads MIT, while the README states a restrictive copyright. Those two statements disagree, and the README is the more specific one, so a reader should treat the material as all rights reserved and ask before redistributing it. A licence scanning tool will only see the field, which is a good reason to read the README before running one.

Beyond the licence, the caveats are about content rather than permissions. There are no releases and no version tags, so there is nothing to pin and no changelog to read, and the last push was on 2026-08-30, with the repository not archived. The work is therefore continuous and unpinned, which is normal for a notes repository and inconvenient for anything that wants to reference a specific version of a specific article.

The primary language is recorded as unknown, because the source is a mix of prose and code, but the writing is Russian and the topic list includes russian explicitly, as well as jvm-languages. So this is a resource for Russian speaking Java developers, and an English speaking reader should expect to use a translator for the prose.

The strongest case for it is the one the author makes for himself: a set of notes written by someone learning the subject and explaining it back. For a developer preparing for interviews, that is closer to the material that helps than a reference manual is, because it carries the shape of the questions that get asked and the answers that actually satisfy them, in the order one person came to them.

And the caveat that comes with that: a personal study project has uneven coverage. Some directories will be thorough and others will be thin, and the README's own warning about the structure changing is the reader's signal to expect a directory listing to shift between visits. Read it as a working notebook, which is what it is.

Editorial conclusion

JBook suits a Java developer who reads Russian, is preparing for interviews, and wants another engineer's notes on algorithms, patterns and framework internals to compare against their own understanding. It does not suit a team looking for a library, a curriculum with certification, or content they can republish commercially, because the licence requires the author's consent for copying and forbids using the material in paid services. Verify first which of the topic directories match the areas you actually need, since the outline is large and the coverage per area is not uniform, and treat the structure as unstable, because the README says the contents and the layout may be changed while the project is in development.

Frequently asked questions

Official sources

1. Issues
2. qcha/JBook on GitHub
3. README