Please provide a complete example. Also, in the 'should be' section, use markdown styling to retain your preferred spacing (use 3 grave accent AKA backtick ` chars in a row, before and after your output)

```java
public static final void someFunction(){
    // do something
}
```

generates

public static final void someFunction(){
    // do something
}

```json
{
    "int": 0,
    "string": "string",
    "bool": false
}
```

generates

{
    "int": 0,
    "string": "string",
    "bool": false
}

@stleary Here is a test case:

JSONObject jo = new JSONObject().put("TABLE", new JSONObject().put("yhoo", new JSONObject()));
assertEquals("toString(2)","{\n" + 
        "  \"TABLE\": {\n" + 
        "    \"yhoo\": {\n" + 
        "    }\n" + 
        "  }\n" + 
        "}", jo.toString(2));

and it currently fails like so:

org.junit.ComparisonFailure: toString(2) expected:<["{
  ]TABLE": {
    "yhoo"...> but was:<[{
  "]TABLE": {
    "yhoo"...>

The JUNIT error logging is making it look weird though. It's miss aligning it's surrounding brackets.

I believe that @RMelanson was expecting output like this:

{
  "TABLE": {
    "yhoo": {
    }
  }
}

however, in https://github.com/stleary/JSON-java/blob/master/JSONObject.java#L2260 we have a check for a single element in an object. If it's a single key object, no indenting happens

The following test passes on current master:

JSONObject jo = new JSONObject().put("TABLE", new JSONObject().put("yhoo", new JSONObject()));
assertEquals("toString(2)","{\"TABLE\": {\"yhoo\": {}}}", jo.toString(2));

@RMelanson If you read my last comment on GitHub directly (I edited it a lot which doesn't go through emails) you'll see that this looks like expected behavior. When a JSONArray or JSONObject has only one element or key, then the indentation does not take effect.

@stleary I don't mind changing this, but I think updating the toString and write javadocs would be sufficient to indicate the behavior.

@johnjaylward thanks for doing the analysis. Agree this is a case of works-as-designed, not an error. Javadoc update would be a reasonable way to address the issue.

@RMelanson thanks for making the issue known. No objection if someone wants to create a pull request to document the behavior.