Skip to main content

Java source which meets the Java Code Style convension.

6 replies [Last post]
Joined: 2005-02-24

When submiting fixes/enhancements the submittion page suggests using the Java Code Style convesions and submitting a JUnit tests.

However many files in the source do not follow these convensions and I cannot find there JUnit test.

Perhaps the source code for be reformatted to meet the convensions and it should be made clearer where the JUnit tests are.

If we submit a JUnit test as an enhancement, will it be concidered to be part of the source.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2005-03-24

On Junit tests.

Why not create a folder named Tests or JUnit to put into all related Junit tets.

If you want a even more structured solution, you may create a JUNIT test folder for every existing source folder that is known to have JUNIT fixes added.

For example, under the main folder "Java" in the J2SE hierarche, you might add a folder named "JUNIT" and one level deeper in the "Share" folder or "Windows" folder have another JUNIT folder created.

This may be hard to track and plenty of work but i think its worth it to keep track later on on any specific Junit tests that submitted.

May be submitters of Junit tests should add information about their System, the File etc. to be more flexible dealing with Junit tests.

The NetBeans and Eclipse IDE automatically create Test packages to any newly created project, so why not create similar Test packages to the J2SE project. Usually, adding new packages is just a matter of mouseclicks and should not be too hard to achieve.

So, in the end, i envision each source folder to hold one extra folder - or package - with Junit tests files. This way, compiling the Junit tests is an easy and straightforward process because all major IDEs know how to look for the corresponding java files if the files are all in one package or the packages are all in one directory.

This directory just needs to be added to the classpath.

Joined: 2003-06-10

On tests, my preference is to place them in a test subpackage of the api they exercise. I've tried putting them in a separate heirarchy and found they were often forgotten, and it was always less convenient. Obviously it is trivial to filter out such packages from the distribution.

Joined: 2005-03-24

Thats what i actually meant with adding new packages/folders.

Joined: 2004-09-03

There are several activities going on related to this.

On the coding style, we are aware that many sources don't follow the coding conventions, in general as files are changed we tend to follow the style of the original code, which may explain some of this. But it's also true that some files just broke the rules and the reviewers didn't catch it. It's a bit of a judgement call on when to take the hit and re-format an entire file or set of sources, often for a small low-risk fix, it's ok to follow the existing style.

I'm working on some changes to the build system that could attempt to catch violations or the basic coding conventions at build time, essentially doing a scan of the source prior to compilation and emitting a warning message when the more obvious and easy to check conventions aren't followed. This may take a while to perfect, but it is a start. It's often true that the various teams aren't aware that the code in their domain hasn't followed the conventions, and those teams will probably be the first to react to such warnings and perhaps correct them. Other teams may not wish to edit every one of their source files to follow the conventions, it will depend on many things.

On the JUnit tests, any submitted will be part of the source bundle, so we will need to adjust our bundling to add any submitted JUnit tests. We haven't decided exactly where the JUnit tests will be yet. Any suggestions?

Our own unit regression tests will not become part of the bundles, we have some legal/license issues with many of those tests. However, we are still discussing how we can provide some base level Junit tests as part of the source, and maybe include those with the externally submitted JUnit tests. In the meantime, some of the demos can hit a large part of the JDK, like Java2Demo, and they may serve as a kind of 'brain-dead' test of any JDK changes for now.

Joined: 2004-09-14

Why not just create a code style with Eclipse, IntelliJ IDEA, or Netbeans (does it have "reformat code"), or in fact any of the tools out there?

Run it on all sources, use a nice graphical "diff" tool on each file, spot anything you don't like and fix it, and be done with it...

Joined: 2003-12-02

reformating existing code to follow some new or changed standard is a bit NONO.
It breaks diffs and version control systems, quite apart from introducing risk of errors (I've seen it, code working perfectly before reformating and applying some variable renaming to match guidelines failed misserably afterwards, diff of course mentioned every single line as changed).