- Jalopy's configuration is extremely
high-granularity which is great for a code-formatter.
- Our internal code formatter has been stagnent
for a while.
So I propose we simply integrate Jalopy as
*the* standard formatter. This should be pretty
easy except for one thing:
- If the code is not in a compilable form, Jalopy
complains; we should retain the
internal-formatter's silent behavior and handle
this condition gracefully.
Changing subcomponent to formatting.
Tried it out in Netbeans 5.0 and Mustang :-
1) It is far too complex to comprehend, esp since all its presets are
different (and intrusive enough) from what I am used to, hence I am forced to
look through the settings one by one; and with all its terminology and
settings I am all the more confused.
2) May be I have not figured out a way to do this, but I cannot get jalopy to
leave blank lines between Class brackets and the rest of the code, but not to
leave blank lines between Method brackets - so although it is high-granularity
(hence perhaps a valid excuse for its user-unfriendliness) it is not good
Are all stakeholders satisfied that this is fixed by the new 6.0 code formatter? If I don't hear otherwise I plan on
closing this issue as FIXED in the near future.
I guess I am not a "stakeholder". But to me this should not be closed until this matching feature in Jalopy is
implemented in the new formatter: 103830
That is the one key feature that makes the Jalopy formatter "surgical" enough to re-organize "totally messed up" classes
in terms of format: It re-organizes the entire class purely based on the format configuration while ignoring user
specific touch. This is very useful if one needs to present a company's entire code base in a uniformed manner - no
developer specific formatting.
Of course this had better be an option that can be turned on and off in case some users/shops prefer not to have it that
Are you asking for a way to batch-reformat files across an entire file based on some external formatting configuration
file? I tried looking up issue #103830 but it was unrelated. Is there an open RFE for this?
Sorry if I was not being clear. No, I did not mean a batch formatting on multiple files (although that is a desired
feature that exists in other IDEs).
What I asked for is just the RFE 103830 itself ("sense-making line wrap"). It's very crucial to have that feature in
order to format one Java file purely basing on format configuration while eliminating all developer specific touches:
All developer typed wrapping will be ignored/eliminated, and the whole Java file wrapping is re-done based ONLY on
I thought the new code formatter already does this. That is, so long as you set your configuration to anything other
that "leave as is" it will always reformat the code regardless of the original format. Isn't this what you are asking for?
FYI: I'm not a Netbeans developer, I'm just a normal user.
I see. If the new format really does that already (last time I checked with M10? it still didn't), that's great news.
Yes, I'd be satisfied with that feature available: Rest of the unmatched features can be taken care of by individual
RFEs, as long as this key feature is in place.
Please check the latest dev build and let us know whether it meets your requirements.
Yes, I checked and it does that already. That's great.
I'd be nice to have the option of "removing extra blank lines" if there are more than 1 (or any configured threshold
number) blank line between 2 statements/expressions. But that's something I can live with for now compared to the line
Thanks for opening this RFE. I think it's a great one although it was never implemented - It might've saved some effect
on the dev side compared to write something new as in 6.0. Anyways...
Can we close this FEATURE in light of the 6.5 feature-set?
I'd say close it as it evidently will not be done.
However there are a large number of features that Jalopy provides that have no equivalent in the current formatting
Netbeans own formatting features are reliable but basic. It seems a pity that this module which provides an excellent
basis for extending this is left behind. I have attempted to work on it myself from time to time but haven't the
requisite skills or experience on the NB platform to be successful.
@Dusan: I propose to close this issue as invalid/wontfix.
The OSS variant of jalopy is stuck in 2005. 
Even the commercial jalopy is stuck in 2010. 
So neither will currently support the new syntax elements (diamond syntax in JDK7/lambdas in JDK8)
I agree, mostly because Netbeans' built-in formatter has advanced by leaps and bounds over the past 10 years. I think it's good enough now to forget about Japoly.
I'm going to go ahead and close this issue for the aforementioned reasons.