The goodjava library is independent of Luan. Luan calls goodjava but goodjava never calls Luan code. So goodjava can be used as a Java library. goodjava is included in the Luan jar file.
As western programming became depraved, it became more and more difficult to find good libraries. So rather than use modern depraved libraries, I wrote my own. I will describe the most important libraries.
This includes goodjava.logger which replaces log4j, and goodjava.logging which replaces slf4j. You can see some examples of how to use my logger. Configuration is in Java, where it should be.
slf4j is a typical modern mess. Just look at slf4j's logger and compare to the interface of my logger. log4j isn't horrible but has significant problems. This project was abandoned by its author so that he could create a horrible depraved logger called Logback to fit with his depraved culture. log4j's biggest problem is that it doesn't handle logging separation properly. Its RepositorySelector is a hack. goodjava.logger's ThreadLocalAppender solves the problem properly.
I implemented full bridging with slf4j, both slf4j to goodjava.logging and goodjava.logging to slf4j. This way my code is completely compatible with depraved modern code.
In computer science, parsing is a big deal. They make it complicated, of course. But it shouldn't be. I developed a new approach to parsing which is implemented here. It is based on a simple stack of integers that are positions in what is effectively recursive descent parsing. I use this idea to compile Luan but also to parse JSON, Lucene queries, HTTP requests, BBCode, CSS, CSV, HTML, and other things.
When I wrote the JSON parser, it worked on the first run. It is so much simpler than any other JSON parser. I dare you to look for any JSON parser as simple as this one. All my other parsers are similar. My approach to parsing reflects my anti-modern values. I hate theoretical nonsense and I hate needless complexity. Think deeply about a problem (like parsing) until you see the essence of it. Then write clean simple code to solve the problem.
Found here, this lets you parse or create JSON easily.
Yet another case where all existing libraries are horrible, so I wrote my own.
Most RPCs (remote procedure calls) these days use REST which is really absurd because HTTP was never meant for this, so it is inefficient. So I made a simple socket-based RPC that just uses JSON here. I use this to manage my luan hosting service.
This is a better implementation of Lucene's QueryParser which has serious defects like only being able to query text fields. My implementation fixes all the defects.
This is the first part of the library that I wrote. I wrote it after studying all available java webservers and being horrified by them. My hatred of modern software and modern culture was fully developed by this time, so I wrote this code intending to violate every rule of modern software, and I am rather pleased with the result. The code is very clean and simple. Here is the source.
The core interface is Handler. Note the simplicity. This takes a Request and returns a Response (or null if the request wasn't handled). Note how these classes are simple structs with no "get" and "set" methods. They are structs that directly represent the true underlying data in the HTTP protocol. No stupid obscuring layers (like servlets). Keep it raw and simple.
To write a server, write your own Handler or chain together existing handlers. See this example.
I use this webserver by itself for development, and behind nginx for production. I have only implemented what I need as I need it. I haven't tried to make this a production-ready stand-alone webserver. That is much more work.
The last horrible modern library that I replaced is java.mail. My code to send mail is a little over 200 lines. It is a thin layer on top of SMTP and MIME.