Dangberg Software Solutions has released Jindent 4.0. A major milestone has been achieved by supporting all language features of Java 5.0 including generics and all other language extensions as well as more than 300 formatting options.

A trial version is available for download.

Additionally Jindent 4.0 introduces an improved GUI design and native installers for all major operation systems.

The Jindent 4.0 formatting engine has also been significantly enhanced and now includes important new functionality as full-control sorting support for all Java source code fragments. Important algorithms for line wrapping and comment handling have been redesigned and improved substantially.

Another enhancement is the new integration API that allows addition of Jindent 4.0 to third party application as part of development environments and versioning systems. Completely new integrations for all major Java IDEs (JBuilder, Eclipse, NetBeans, IntelliJ IDEA, JDeveloper) are already included in the release or will be released in the near future.

Useless tool since IntelliJ, Eclipse and most other IDE's already does a *very* good job at formatting source.

he's blunt, but he got a point :-)

Useless tool since IntelliJ, Eclipse and most other IDE's already does a *very* good job at formatting source.

Unless you want to run a formatting tool against your code unattended. For example some teams have a trigger in their version control system that runs the formatter everytime a file is checked in. This ensures that all code in the repository is formatted the same way. If you're displaying your code in WebCVS or whatnot, that might be useful.

Useless tool since IntelliJ, Eclipse and most other IDE's already does a *very* good job at formatting source.

Unless you want to run a formatting tool against your code unattended. For example some teams have a trigger in their version control system that runs the formatter everytime a file is checked in. This ensures that all code in the repository is formatted the same way. If you're displaying your code in WebCVS or whatnot, that might be useful.

not sure how my message got mucked up, but what i was trying to say is that if you format the code automatically you'll hose source control and history so that you can't do a diff on files anymore. thus formatting code should NEVER be done unattended

also, i agree that paying for a code formatter is silly, yet the free code formatters out there aren't great either, so if you're a spare-no-expense outfit, go for it i guess (ugh, one more thing to integrate into the IDE/dev environment)

How about setting up the cvs such that formatter is applied before the the source code is checked in. It should keep everyone happy.

not sure how my message got mucked up, but what i was trying to say is that if you format the code automatically you'll hose source control and history so that you can't do a diff on files anymore. thus formatting code should NEVER be done

The idea is you do the formatting as a trigger run just before a file is checked in. This helps with diffs and merges, because you don't get spurious differences due to formatting.

Without such a trigger, if two developers work on the same project with slightly different formatter settings in their IDE's, one guy can check something out, make no changes except for a reformat, and check in.

Useless tool since IntelliJ, Eclipse and most other IDE's already does a *very* good job at formatting source.

Unless you want to run a formatting tool against your code unattended. For example some teams have a trigger in their version control system that runs the formatter everytime a file is checked in. This ensures that all code in the repository is formatted the same way. If you're displaying your code in WebCVS or whatnot, that might be useful.

No. All our Eclipse and IntelliJ developers, for instance, use the same template file. We never have problems with CVS or Subversion...

No. All our Eclipse and IntelliJ developers, for instance, use the same template file. We never have problems with CVS or Subversion...

All your Eclipse and your IntelliJ developers? Do you have developers using Eclipse and IntelliJ on the same project? And can you get Eclipse and IntelliJ to format the same way?

Well, maybe you can, I don't know. Anyway it sounds like it's not a product that would be useful for you. Which doesn't necessarily mean it wouldn't be useful for others.

(I've never used JIndent; I'm not vouching for it one way or another.)

No. All our Eclipse and IntelliJ developers, for instance, use the same template file. We never have problems with CVS or Subversion...

All your Eclipse and your IntelliJ developers? Do you have developers using Eclipse and IntelliJ on the same project? And can you get Eclipse and IntelliJ to format the same way?

Yes, Yes and Yes.

Besides, Eclipse/JBuilder developers work on client code, IntelliJ developers on server code.

Which doesn't necessarily mean it wouldn't be useful for others.

They have an impressive customer lists, so "others" obviously think they need it. Too me, this product seems meaningless. It would make sense 5 or 6 years ago, but not today.

I'm sure the product is high quality and all, but every single IDE out there these days does a tremendous job at code formatting (many offer as-you-type-formatting as well)

<blockquoteI'm sure the product is high quality and all, but every single IDE out there these days does a tremendous job at code formatting (many offer as-you-type-formatting as well)
I think, relying on the IDEs code formatting capabilities is a bad practice. If you use different IDEs within a single project, you have to maintain different IDE configurations consitently (or doe IDEA, Eclipse, JBuilder, ...) all use the same formatting config files? Further, it is not assured, that the formatting config, that you currently have, is also supported in future versions of your IDE. This is espacially bad, if you have some kind of company-wide formating "standard". So, you not only have to maintain formatting configurations for different IDEs, but also for different IDE versions. Further, you might have tools within your SW development process, that automatically generate code (or some other artifacts). You don't want to format that with your IDE by hand every time you re-generate. Further, you may have different types of artifacts that should be formatted (XML, Java source, C source, ...). I wonder if you can find any IDE that is capable of formatting all your relevant atrifacts.

Regards,
    Dirk

<blockquoteI'm sure the product is high quality and all, but every single IDE out there these days does a tremendous job at code formatting (many offer as-you-type-formatting as well)

I think, relying on the IDEs code formatting capabilities is a bad practice.
I think it is the only sensible practice and it is used by all companies I work with. No need to do things harder than necessary.

If you use different IDEs within a single project, you have to maintain different IDE configurations consitently (or doe IDEA, Eclipse, JBuilder, ...) all use the same formatting config files?

There is not need, because different IDE's consistently means different source files. As I said, it is very common to have, say, JBuilder or Eclipse for client side stuff and IDEA for the server.

So there is no real need for all IDE's to have the same config files. Besides, if there was a need, making Eclipse, JBuilder and IDEA format the code equally is a no-brainer.

Further, you may have different types of artifacts that should be formatted (XML, Java source, C source, ...). I wonder if you can find any IDE that is capable of formatting all your relevant atrifacts.

This is a false dilemma. Why would I want a Java IDE format my C code? My C/C++ IDE does that just as excellently as the Java IDE's formats Java code. And I use XmlSpy and IDEA for XML hacking, and the formatting capabilities are excellent for that as well.

[...] it is very common to have, say, JBuilder or Eclipse for client side stuff and IDEA for the server

That's the first time I heard of this ... guess I'll never complete learning :-)

[...] making Eclipse, JBuilder and IDEA format the code equally is a no-brainer

So, you have different coding styles, depending on the type of source files (client vs server)? Now, that's what I would call a no-brainer (or I'm just too dumb to understand).

Regards,
    Dirk

[...] it is very common to have, say, JBuilder or Eclipse for client side stuff and IDEA for the server

That's the first time I heard of this ... guess I'll never complete learning :-)

[...] making Eclipse, JBuilder and IDEA format the code equally is a no-brainer

So, you have different coding styles, depending on the type of source files (client vs server)? Now, that's what I would call a no-brainer (or I'm just too dumb to understand).Regards,&nbsp;&nbsp;&nbsp;&nbsp;Dirk

Yup, you probably are.

[...] it is very common to have, say, JBuilder or Eclipse for client side stuff and IDEA for the server

That's the first time I heard of this ... guess I'll never complete learning :-)

[...] making Eclipse, JBuilder and IDEA format the code equally is a no-brainer

So, you have different coding styles, depending on the type of source files (client vs server)? Now, that's what I would call a no-brainer (or I'm just too dumb to understand).Regards,&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;Dirk

Yup, you probably are.

_VERY_ qualified comment, han theman. These kind of things really get me angry ... and I have only two of those sedation pills left for the month.

Animosities aside, I'm interested to know why you prefer IDEA over JBuilder and Eclipse for coding server-side components. Or, vice-versa, what "disqualifies" IDEA for coding client-side components?

Regards,
    Dirk

Animosities aside, I'm interested to know why you prefer IDEA over JBuilder and Eclipse for coding server-side components. Or, vice-versa, what "disqualifies" IDEA for coding client-side components?Regards,&nbsp;&nbsp;&nbsp;&nbsp;Dirk

Eclipse has a nice GUI editor, IDEA has not. IDEA is a superior coding tool, Eclipse is not. So, the only reason I don't use IDEA on the client side is that the GUI designer sucks.

Capice?

[...] it is very common to have, say, JBuilder or Eclipse for client side stuff and IDEA for the server

That's the first time I heard of this ... guess I'll never complete learning :-)

[...] making Eclipse, JBuilder and IDEA format the code equally is a no-brainer

So, you have different coding styles, depending on the type of source files (client vs server)? Now, that's what I would call a no-brainer (or I'm just too dumb to understand).Regards,&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;&amp;amp;nbsp;Dirk

Yup, you probably are.

_VERY_ qualified comment, han theman. These kind of things really get me angry ... and I have only two of those sedation pills left for the month.Animosities aside, I'm interested to know why you prefer IDEA over JBuilder and Eclipse for coding server-side components. Or, vice-versa, what "disqualifies" IDEA for coding client-side components?Regards,&nbsp;&nbsp;&nbsp;&nbsp;Dirk

I don't blame you for getting angry, Dirk. It's a very rude and unusual style from Han. By the way, I've worked in many, many java projects, and I have never ever seen an environment where they have standardised on a different IDE for the server vs the client.

I've seen teams where people choose to use one IDE over the other based on personal preference, and they usually use Ant as the standard build mechanism. On various large projects I've worked on for large-ish corporations, mostly they standardise on a single tool with the best feature hit. (Even if this means losing good developers). This "tool of choice" used to be jbuilder, but the landscape has changed quite rapidly here.

Andrew

I don't blame you for getting angry, Dirk. It's a very rude and unusual style from Han

Is it, Andy?

Problem is, Dirk didn't bother to read my reply properly when he claimed "So, you have different coding styles, depending on the type of source files (client vs server)? Now, that's what I would call a no-brainer"

... which is _not_ what I said at all.

I'm sure Dirk is a nice chap, but I have to react to sarcasm and lazy posters :-)

By the way, I've worked in many, many java projects, and I have never ever seen an environment where they have standardised on a different IDE for the server vs the client.

My experience is the exact opposite.

...and they usually use Ant as the standard build mechanism

Which just simplifies the process of using multiple IDE's...

This "tool of choice" used to be jbuilder, but the landscape has changed quite rapidly here.

Well, the tool of choice IMO used to be VisualAge / WSAD, JBuilder and Eclipse, in that order. Especially Telco's seems to love WSAD... as a marriage of open source and commercial support, I guess.

These days, I find almost nothing but IDEA and Eclipse (and some Netbeans and WSAD)

Problem is, Dirk didn't bother to read my reply properly when he claimed "So, you have different coding styles, depending on the type of source files (client vs server)? Now, that's what I would call a no-brainer"

... which is _not_ what I said at all.

I'm sure Dirk is a nice chap, but I have to react to sarcasm and lazy posters :-)

Well, my posting wasn't meant to be sarcastic, sorry it sounded that way to you.

I did read your reply, and I think I did it properly (at least I bothered to). It's true that you did not explicitly say that you use different coding styles for different types of sources files. But let me explain how I came to that assumption:

First you said

[...] it is very common to have, say, JBuilder or Eclipse for client side stuff and IDEA for the server

You further said

[...] making Eclipse, JBuilder and IDEA format the code equally is a no-brainer

So, from the first statement, my conclusion was, that there are source files for client-side components, which are formatted with JBuilder or Eclipse, and there are server-side source files, which are formatted with IDEA. I further understood the second statement that way, that JBuilder, Eclipse, and IDEA format the code differently (since "equally is a no-brainer"). So, I assumed different coding styles for client and server-side components, since the client-side artifacts (JBuilder, Eclipse), would be formatted differently, than the server-side artifacts (IDEA).

Regards,
    Dirk

Problem is, Dirk didn't bother to read my reply properly when he claimed "So, you have different coding styles, depending on the type of source files (client vs server)? Now, that's what I would call a no-brainer"... which is _not_ what I said at all.I'm sure Dirk is a nice chap, but I have to react to sarcasm and lazy posters :-)

Well, my posting wasn't meant to be sarcastic, sorry it sounded that way to you.

This is potentially just a language familiarity problem. To an English reader, Dirk's message clearly came across as self-deprecation, which is a strategy people sometimes use when they are unsure of their opinion or experience. The message's tone was conciliatory. It was not sarcastic, which is why your rebuke came across as harsh.

Ce'st la vie,
Andrew

I just talked to a colleague of mine, who told me that I misunderstood the term "no-brainer". I thought it would mean "total nonsense", like "doing so means that you have no brain".

Sorry,
    Dirk

I just talked to a colleague of mine, who told me that I misunderstood the term "no-brainer". I thought it would mean "total nonsense", like "doing so means that you have no brain".Sorry, Dirk

That, err, explains a lot.

Peace ;-)

I guess it is a matter of control. While the IDE formatters are pretty darn good. Jindent gives you more options to fine tune your output. Is it a waste of money? I don't think so but other people might.

-Pete

use the formatter brought with eclipse, "Ctrl+A", and then "Ctrl + Shift+ F". finish! but too many 'stair-code' like that:

xxxxx.
     xxxxx.
          .xxxx
               .xxx

wow! Be careful, use it partly!

I agree with posters that Eclipse already does a nice job of source formatting (lots of progress here in 3.0). However, one area it is really lacking is generating / fixing Javadocs, such as adding / removing / renaming @param, adding / removing @throws, creating a Javadoc skeleton to start with and so on. That is one of the reasons I use (the commercial) Jalopy (not to be mixed up with the open source project that was started by the same author). It does all the Javadoc fixes while formatting the code - very convenient.

The only other tool I found is the Javadoc Repair tool. But it must be installed as part of the (commercial) CodePro Studio (where it remains active even if the CodePro Studio trial expired) and it doesn't seem to work in batch mode.

So, does anybody out there know an open source Eclipse plug-in that can fix Javadocs automatically?

Netbeans has a very good javadoc widget (it's called Auto Comment in the tools menu). :-) Finds broken javadocs, puts in javadoc stubs, provides nifty editing features, etc.

I also find no use for "external" code formatter. What i've done in some projects is define the code style guidelines that everyone should follow when coding. Then use something like checkstyle to generate a report at build time so that all style related issues are reported and can be corrected as such. No messy automatic formating this way. I'm very happy with the outcome of this strategy.

We recently went through this discussion at my company where we have distributed developers working on the same code base(s) (both front end and back end) in multiple IDEs (Eclipse and IDEA). We also have a consulting company who does not use our CVS repository for development but simply commits their sources when they have a release. I do not know which IDE they are using.
It is true that you can manage formatting within an IDE, but this does have to be maintained as developers come and go. Somebody has to keep the new developers informed of the coding standards and make sure they install the code formatting templates, and remember to format their code before checking in. Though these aspects of team integration will eventually happen regardless, enforcement of these standards is managerial overhead that is better left to automation. The fact is, it is simply easier to enforce coding standards by integrating automatic code formatting with CVS rather than walk around to each developer reminding them to run their IDE formatter before committing.
Also, if developers are so inclined they can now format their code locally however they choose, knowing that the CVS commit will reformat to the standard.
One feature of the code formatter we are using that I particularly liked was its ability to automatically add and update header comment blocks. At my last company which produced a CMS product, at the start of the new year, a developer would manually checkout all the repository files, update the copyright year, and commit. The code formatter handles this automatically and can intelligently add or replace headers based on string-matching. This also comes in very handy with our consulting company who does not include headers in their code. Maybe we should force the consulting company to add the proper headers, but again, this is managerial overhead. Why not let the formatter robot do the work?
To ease the introduction of automatic code formatting to our team, we have first introduced the tool and pointed them to the IDE plugins, so they can get comfortable with them and understand that the formatter will not "mess up" their code. The next step is to apply automatic formatting to select CVS modules. Once all developers are comfortable with the process you can just apply it to the whole repository.

Also, if developers are so inclined they can now format their code locally however they choose, knowing that the CVS commit will reformat to the standard.

Which means the diff is always different... that's just a horrible approach.

Maybe we should force the consulting company to add the proper headers, but again, this is managerial overhead. Why not let the formatter robot do the work?

Because that means the origin of the formatting is outside the IDE. This has several implications, such as the auto-formatting abilities getting screwed up and the local history (supported by at least IDEA and Eclipse) doesn't show the correct result.

IDE's change every 2 or 3 years. Although Eclipse could be the long term winner, as it's free. But having worked with Emacs, Visual Cafe, Age, JBuilder, Intellij, Eclipse...
AND with PVCS, Sourcesafe, JavaSafe (!), ClearCase, CVS and Subversion
THEN
It would be dead handy to have a formatting layer to synch everyone up independant of the components that change over and over again. Developers don't need to use this format when they are coding, but it does mean the repository doesn't suffer from individual styles.

Now make it free and the java folks will all embrace it - because we are cheap.

Jonathan

at last,Jindent 4.0!

crossword puzzle games

Jindent 4.0 is awesome

graphic designer holiday gifts