Java support?

[josephcagle]

Are you planning to have this plugin work with Java anytime soon?

I would imagine you could probably just copy stuff from the JavaScript or C parts of the plugin and have things work fairly well. I saw in issue #33 the recommendation was to copy things from C to get C++ support.

(I would even volunteer to help add Java support, but I am currently busy with other things.)

[AndrewRadev]

I don't have any specific plans for Java, because I don't write any myself, but I'm happy to add support. For now, I've copied the C support in the branch java-support, so maybe you could check it out and let me know how it feels?

I don't really know any modern Java, so it's hard for me to pick what would be convenient. You could also take a scroll through the documentation for what the other languages provide and see if any one of them would make sense. Rust could also have some useful tools, since there's generics there as well, but I think they might be quite different. If anything looks good, but doesn't work right, there might be differences in syntax, structure, etc, and I could write a custom handler, so let me know.

[josephcagle]

This is great! I would also suggest adding:

• one-line if conditionals
• Java's lambda expressions, which are just JS fat arrow functions, except it's a skinny arrow (->).

It looks to me as though you could basically just copy those two from the JavaScript part of the plugin.

[AndrewRadev]

I've now implemented both of the above, I think -- let me know how well they work in the branch.

[josephcagle]

Thanks! Here are my suggestions.

• if statements
  • I think the plugin should not require if one-liners to use curly braces. (I.e., something like if (condition) return true; should be splittable.) This seems to be the way it is implemented for e.g. JS.

• Lambdas

  • It works well mostly, but I think there is some leftover "smart" JavaScript functionality that needs changing. When splitting, the plugin is "intelligently" omitting a semicolon both (1) after the inserted return statement and (2) after the closing parenthesis, when it notices there was no semicolon at the end of the original line. Java always uses a semicolon after a statement, of course, so the "smart" semicolon placement should only occur after the closing parenthesis.

    • For example:

      
      // This works
      someFunction(a -> a.b());

    someFunction(a -> { return a.b(); });

    // but this doesn't someList.stream() .map(x -> x.toString()) // no semicolon here -- the statement continues onto next line .collect(toList());

    someList.stream() .map(x -> { return x.toString() // <-- needs semicolon here, no matter what }) // <-- this is correct. You can keep "smart" semicolon placement here .collect(toList());

• Documentation
  • The Java help info needs these changes, in addition to updates for any other plugin changes you make:
    • There needs to be a section about splitting long if conditions (a la the first part of the C plugin docs).
    • A couple of semicolons need moving around in "if clauses." Just copy the JS docs for One-line if conditionals and it will be fine.

Thanks for your help!

[lfb0801]

Is it a choice for the first parameter not to be split? because I would prefer if the insides of the parathesis would all be split in the same way.

Click the arrows for images that explain of what I would like splitjoin to do.

Example method

Here is a simple code example that I will be using for my request.

What splitjoin currently does

Currently it seems like every element after the first one gets split.

How I would like the split to behave

Would it be possible to make it so that all parameters are Split.

Please excuse me for the lazy code example

[AndrewRadev]

@DarthFloopy

I think the plugin should not require if one-liners to use curly braces. (I.e., something like if (condition) return true; should be splittable.) This seems to be the way it is implemented for e.g. JS.

JS only works correctly for bracketless cases, if (condition) return true;, it actually breaks for cases with brackets, considering them an object. This might work correctly by accident, but if you add a trailing comma, it becomes apparent. This is not great, and I should really fix it, but for now, I'm wondering -- should the plugin focus only on if (condition) return true; or is it also common to encounter cases with brackets, like if (condition) { return true; }?:

It works well mostly, but I think there is some leftover "smart" JavaScript functionality that needs changing.

Makes sense, this should be fixed now, but let me know if I've missed some case.

There needs to be a section about splitting long if conditions (a la the first part of the C plugin docs).

This doesn't actually work for java right now, though, that's why there's no docs on it. I'm assuming you'd like it to work? :) It's probably a good idea for me to overhaul if-clause handling in general, C only supports that kind of split and doesn't support splitting bodies of if-clauses. It might be best for me to sit down and build a combined solution.

@lfb0801

Is it a choice for the first parameter not to be split? because I would prefer if the insides of the parathesis would all be split in the same way.

I'll see what I can do about making it configurable.

[AndrewRadev]

@DarthFloopy I've pushed some improvements to the if-clauses, could you take a look? I think they should work well now, but let me know.

@lfb0801 I've added two flags for argument-splitting. Try putting these two in your vimrc:

let g:splitjoin_java_argument_split_first_newline = 1
let g:splitjoin_java_argument_split_last_newline = 1

Change these between 0 and 1 to control whether splitting would leave a newline before the first and after the last item. I'm not 100% sure about the names yet -- open to suggestions. You could also consider whether it's better to control the first/last element, or whether it's common to either consistently have newlines in both places, or not. I think most languages pick one or the other as a convention, so it might just be one flag java_argument_split_newlines or something.

[josephcagle]

Everything seems to be working now.

I might suggest putting in one more case in the docs under "Lambda functions" to mention the case when the line to be split doesn't end with a semicolon. (It's not really necessary, but I figure it would make things clearer.)

I like the idea of configurable newlines after and before the parentheses. The new added functionality is good as-is for now.

Also, I think that feature would be valuable for if conditions and for other languages (C, JS, etc.). You might want to add some language-agnostic settings dealing purely with parentheses (though now that I think about it, you will still need language- and language-feature-specific settings). You may of course want a new issue / feature branch if you decide to work on something like this.

[AndrewRadev]

I might suggest putting in one more case in the docs under "Lambda functions" to mention the case when the line to be split doesn't end with a semicolon. (It's not really necessary, but I figure it would make things clearer.)

I don't think there's a lot of practical use for it -- ideally, the plugin should always produce syntactically valid code, so not adding a semicolon is just the correct thing to do in cases like the one you point out. If I left an example, the only thing I could comment on it is something to the effect of "notice that it works correctly in this case", but it should always work correctly. If there's a situation where the plugin does the wrong thing and I can't fix it (which is definitely a possibility), I'd leave a note as a warning.

Also, I think that feature would be valuable for if conditions and for other languages (C, JS, etc.).

Do you mean the newline configuration? I'd rather not tackle this right now. Configuration is a tricky business and different languages tend to have specific idioms. I agree there's probably generalizations that could be made, but I'd rather work with specific use cases, even within the limits of the language. Say, if somebody comes into this issue and says "well, I like to indent things in this way", I'd consider how I can fit people's preferences together.

For now, I'll merge my branch and close this issue. If you or @lfb0801 run into problems, feel free to reopen, or open a new issue.