This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 37144 - Ship with Jalopy as default code formatter
Summary: Ship with Jalopy as default code formatter
Status: RESOLVED WONTFIX
Alias: None
Product: editor
Classification: Unclassified
Component: Formatting & Indentation (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker with 3 votes (vote)
Assignee: Dusan Balek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-11 15:26 UTC by _ gtzabari
Modified: 2014-05-01 05:01 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ gtzabari 2003-11-11 15:26:17 UTC
- 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.
Comment 1 Roman Strobl 2004-12-07 15:25:18 UTC
Changing subcomponent to formatting.
Comment 2 _ alexlamsl 2005-11-17 16:56:42 UTC
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 
enough.
Comment 3 _ gtzabari 2007-09-10 15:02:53 UTC
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.
Comment 4 wqtnetbeans 2007-09-10 16:36:58 UTC
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
way.

 
Comment 5 _ gtzabari 2007-09-10 19:32:30 UTC
wqtnetbeans,

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?
Comment 6 wqtnetbeans 2007-09-10 19:51:48 UTC
gtzabari,

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
pre-set configurations.

Thanks!

Comment 7 _ gtzabari 2007-09-10 20:00:13 UTC
wqtnetbeans,

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.
Comment 8 wqtnetbeans 2007-09-10 21:47:28 UTC
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.

Comment 9 _ gtzabari 2007-09-10 22:32:56 UTC
Please check the latest dev build and let us know whether it meets your requirements.
Comment 10 wqtnetbeans 2007-09-10 23:42:21 UTC
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
wrapping feature.

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...
Comment 11 _ gtzabari 2008-12-11 23:02:48 UTC
Can we close this FEATURE in light of the 6.5 feature-set?
Comment 12 facilityderek 2008-12-12 19:00:20 UTC
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
feature set.

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.
Comment 13 markiewb 2013-07-03 21:29:20 UTC
@Dusan: I propose to close this issue as invalid/wontfix.

The OSS variant of jalopy is stuck in 2005. [1]
Even the commercial jalopy is stuck in 2010. [2]

[1] http://jalopy.sourceforge.net/index.html
[2] http://www.triemax.com/products/jalopy/history.html

So neither will currently support the new syntax elements (diamond syntax in JDK7/lambdas in JDK8)
Comment 14 _ gtzabari 2013-07-03 22:10:39 UTC
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.
Comment 15 _ gtzabari 2014-05-01 05:01:40 UTC
I'm going to go ahead and close this issue for the aforementioned reasons.