Show HN: mister.jar – Modular MRJAR Files Made Easy(lingocoder.com)
lingocoder.com
Show HN: mister.jar – Modular MRJAR Files Made Easy
http://lingocoder.com/mrjar/mrjar.usage.html
1 comments
Say what you will about "Agentic Coding". But it deserves credit where credit is due.
I'm not the fanniest of fanboys there is for AI agent-assisted coding. Not hardly. I have an AGENTS.md in every single project. The directives in it strictly forbid agents from ever presenting unsolicited diffs to change my code. If any ever do and I haven't explicitly requested them, I reject them.
That said, the deafening crickets from this post led me to discover a valuable use case for Cline (formerly Claude Dev) [1]. Namely: verifying the clarity and correctness of usage instructions.
I copied and pasted the usage instructions that I provide on the com.lingocoder:mrjar plugin's Git Hub Pages [2]
Apart from me having to tell it where to find a Gradle binary, the agent understood the usage instructions without me having to change anything in them.
That gives me confidence that the steps themselves are clear. And, if followed faithfully, they result in Gradle successfully building a project that applies the plugin. The example configurations in the instructions produce a successfully initialized project.
Most overextended software engineers who want reproducible builds, would appreciate the value in handing off that kind of proofreading task to a robut.
[1] https://g2ww.short.gy/IfSoInClined [2] http://lingocoder.com/mrjar/
I'm not the fanniest of fanboys there is for AI agent-assisted coding. Not hardly. I have an AGENTS.md in every single project. The directives in it strictly forbid agents from ever presenting unsolicited diffs to change my code. If any ever do and I haven't explicitly requested them, I reject them.
That said, the deafening crickets from this post led me to discover a valuable use case for Cline (formerly Claude Dev) [1]. Namely: verifying the clarity and correctness of usage instructions.
I copied and pasted the usage instructions that I provide on the com.lingocoder:mrjar plugin's Git Hub Pages [2]
Apart from me having to tell it where to find a Gradle binary, the agent understood the usage instructions without me having to change anything in them.
That gives me confidence that the steps themselves are clear. And, if followed faithfully, they result in Gradle successfully building a project that applies the plugin. The example configurations in the instructions produce a successfully initialized project.
Most overextended software engineers who want reproducible builds, would appreciate the value in handing off that kind of proofreading task to a robut.
[1] https://g2ww.short.gy/IfSoInClined [2] http://lingocoder.com/mrjar/
TL;DR: Like the 'M' in JPMS suggests, it let's you compose a system using collaborating chunks of functionality.
It's fair to say that Java modules are designed mainly with the JDK itself in mind. The JDK itself is JPMS' most gung ho user. Modules' main goal in life seems to mostly be to keep riff raff system programmers from poking around in the JDKs internals.
Java modules are a killer idea in my opinion. So it surprises me that it's been adopted by so few in the Java ecosystem beyond the Java platform itself.
I wrote the com.lingocoder.mrjar Gradle plugin [2] as a hobby project. Mostly because I get a kick out of designing and building modular applications.
I'm under no illusions that this plugin will have any impact whatsoever on adoption of Java modules. I'm just putting it out there as a demonstration.
I'm hoping it shows how developing JPMS-based libraries doesn't have to be as onerous as many application programmers at most Java shops seem to think.
[1] https://openjdk.java.net/jeps/261 [2] http://lingocoder.com/mrjar/