Formatting Java source code

[wfouche]

No description provided.

[jeff5]

spotless appears to do a perfectly fine job of formatting to project standards. Some comments on how this is implemented, scattered around the files, for your consideration.

[jeff5]

Gradle potentially confers some advantages in terms of editing and debugging from the IDE, which has always been a pain point when reviewing. VSCode recognises this as a Gradle project, which means the Gradle menu has just appeared, and the spotlessApply task may be run from it.

However, it is not properly set up as a Gradle Java project with the right structure and dependencies, so VSCode does not recognise the source as belonging to the project, and continues to give me red ink about the imports and won't debug the cli.

I think a little more work (and letting Gradle bully you into main and test source trees) will yield a lot.

[wfouche]

As an initial step, I've moved both Java files to src/main/java.

[jeff5]

Good first step. With that change, I find I can finally stop the IDE grumbling at me, with some additions to just this file, which I'll pass on next.

[wfouche]

@jeff5 , please review the changes. I implemented all the improvements that you recommended.

[jeff5]

In general this is looking good. I propose a few changes that make the Gradle and IDE experiences better.

[jeff5]

Good first step. With that change, I find I can finally stop the IDE grumbling at me, with some additions to just this file, which I'll pass on next.

[jeff5]

Then here, we need to specify these dependencies:

dependencies {
    implementation 'org.tomlj:tomlj:1.1.1'
    testImplementation 'org.junit.platform:junit-platform-console'
}

and to minimally configure the jvm-test-suite plug-in like this:

// Configure the jvm-test-suite plug-in
testing {
    suites {
        // The pre-defined test suite.
        test {
            useJUnitJupiter()
        }
    }
}

[wfouche]

Following a slightly different approach by using the JBang Gradle plugin

https://plugins.gradle.org/plugin/dev.jbang

and then just running TestJythonCli.java as we run it currently. Created new task runTests for this purpose.

tasks.register("runTests", JBangTask) {
    // Specify the script file to run
    script = "src/test/java/TestJythonCli.java"

    // Optional: Pass arguments to the script
    jbangArgs = ["--java", "17"]
    args = ["execute", "--disable-ansi-colors", "--select-class=TestJythonCli"]
}

[jeff5]

I think it is fine to have a target that runs the tests the way we do on GitHub. I confirm this target runs at the console for me.

It is not a substitute for the changes I suggested.

[jeff5]

To get the Gradle test target to work, add this plug-in (and config lower down).

id 'jvm-test-suite'

[wfouche]

Not needed in the revised implementation.

[wfouche]

@jeff5 , ready for review again.

I followed a different approach which is more natural for JBang script by adding a gradle JBang Task to run TestJythonCli.

It works really well.

tasks.register("runTests", JBangTask) {
...
}

[jeff5]

It has always been difficult to review PRs on this project because the IDE cannot find the libraries it references. The changes I suggested make it possible to work with the code in an IDE. Without them it looks like:

and we cannot get pop-up documentation, run unit tests, and so on in the expected way. Also the well-known Gradle tasks fail (like check).

[jeff5]

I think it is fine to have a target that runs the tests the way we do on GitHub. I confirm this target runs at the console for me.

It is not a substitute for the changes I suggested.

[wfouche]

It is not a substitute for the changes I suggested.

I agree. I'll try again.

[wfouche]

@jeff5, there is a new Java formatter availalbe that also uses the Eclipse Java Formatter.

https://github.com/bmarwell/jfmt

and does require Spotless or Gradle/Maven

[jeff5]

I looked, but I see no advantage to be gained from a change.

Probably the worst thing about Spotless and VSCode is shared by jfmt: bmarwell/jfmt#94 (comment) . (Except VSCode makes it slightly worse by not implementing some of it.)