SwingLabs Project Documentation

How to Write a Good Bug Report?

To increase the chances that the bug you're reporting will be addressed in a timely manner, you should adhere to the following guidelines:

  1. When you encounter a behavior which might potentially be a bug, try to collect as much relevant data as possible (e.g. take a screenshot in case of a UI problem, generate a thread-dump in case of a deadlock or serious performance degradation, create copies of relevant files, etc.) and try to recall and note the actions you performed right before the problem occurred.
  2. Try to restore the original state (if possible) and reproduce the incorrect behavior using the steps you noted. This should help you to determine whether the problem is reproducible and persistent or just intermittent. This is not to say intermittent problems shouldn't be reported, but it's always worth pointing it out in the bug report to make the evaluators aware of this fact.
  3. There is a chance that someone already reported the bug you've just encountered. Therefore, it's a good idea to search the bug database first. Go to the the project Issue Tracking page, fill-in the query parameters that seem relevant to your case, submit the form, and go through the returned list of issues to see if any of them match your problem. Typically, you'll want to search for issues of type DEFECT, in an open state (NEW, STARTED, REOPENED) with a specific string in the Summary and/or Description fields. If the bug already exists in the database and you still think you have some useful info to share, it is highly recommended to add this info to the existing issue instead of filing a new one.
  4. If you assume the bug hasn't been reported yet, it's time to enter a new bug. (Note: to be able to do so and to be able to add/update information in the issue database, you need to have a java.net account and be logged in. If you don't have an account yet, you'll have to register and then become a member of the appropriate project.).
    • The first thing you need to do is to select the Component to file the bug against.
    • After selecting the component, you'll be prompted to fill in the following fields:
      • Version - choose the version of the component in which you encountered the problem. In case of a problem found in a development build, select the next release version number, or current.
      • Subcomponent - select the subcomponent of a given component. If you're not sure, just select code.
      • Platform - select the platform you were using when the problem occured. If you were able to reproduce it on multiple platforms, or are positively sure the behavior is platform independent, use All.
      • OS - similar to the Platform.
      • Priority - use this field to indicate the urgency and severity of the issue. Refer to Bug Priority Guidelines for instructions how to set the priority level appropriately. If you're still in doubt, it's better to stick with the default P3 value.
      • Issue Type - select the type of issue you're reporting. In most cases, you'll probably want to use DEFECT (when reporting a bug) or ENHANCEMENT (when requesting an enhancement or feature).
      • Assigned To - unless you're absolutely sure who this issue should be assigned to, leave this field blank. The bug will be automatically assigned to the component (subcomponent) owner.
      • Cc - enter an optional comma-separated list of email aliases you want to be notified about this issue and any subsequent changes to its status. You as the reporter will be notified automatically, so there's no need to add yourself. The aliases must refer to valid netbeans.org accounts (e.g. jdoe@netbeans.org). Arbitrary email addresses are not accepted by the system.
      • URL - if there is a URL relevant to this issue, you can type it here. In most cases, this field will be blank.
      • Summary - a brief (one sentence) description of the issue. You should try to make it as specific as possible while keeping it short (70 characters at the most).
      • Description - a detailed description of the problem. The description should include the following information:
        • the build number
        • JDK version
        • observed behavior
        • expected behavior
        • exact steps to reproduce the problem
        • any other information potentially related to the issue

        Please note that you should not paste larger chunks of text (e.g. complete exception logs and thread dumps, source files, test data, etc.) into the Description field. You should always provide those files in the form of attachments (see below). There is one exception to this rule: although including complete exception logs in Description is not recommended, it is a good idea to copy the relevant part of the stack trace (usually 4-6 top lines to the field to allow for easy searching.

    • After completing the form, push the Commit button to send it to the database. As a confirmation you will see a number uniquely identifying the issue you've just filed.
    • If you have some additional files relevant to the issue, click on the Add Attachment link in the page you get after the previous step. You'll be asked to provide the following info:
      • the location of file to be sumbitted on your local machine
      • a one-line description of the attachment
      • the type of file being attached (plain text, diff, HTML, GIF, JPEG, PNG, binary)

    Push the Submit button to attach the file to the issue report.

Bug Priority Guidelines

P1

  • product feature (identifiable part of functionality) does not work, no workaround exists
  • user data is corrupted
  • reproducible, unavoidable crash or deadlock
  • blocks another developer's progress, no workaround exists
  • incorrect text of graphics with legal implications
  • regression in functionality or performance degradation

P2

  • product feature is significantly affected, a workaround may exist bug is difficult to use or impractical
  • intermittent crash or deadlock, happens fairly often
  • critical usability problem
  • severe performance problem
  • affects another developer's progress

P3

  • part of a product feature is affected, a viable workaround exists
  • performance is poor
  • highly visible usability problem

P4

  • incorrect behavior that doesn't affect functionality
  • minor usability problem
  • incorrect visual appearance

P5

  • causes unease, minor disturbance/annoyance

Forums and Mailing Lists

SwingLabs has a set of forums and mailing lists.

The SwingLabs forum is a subforum under the Java Desktop Technologies forum. This forum is for general discussion for end users and for developers to discuss project development issues and requirements.

In addition, each subproject may have it's own forums, and own mailing lists. You should visit the project pages for the project you are interested in for more information.

Received JCA/SCAs

This page lists the persons and companies (full name (java.net username)), who have signed and submitted Joint Copyright Assignment forms to Sun.

List of signatories of SCA can be found here

See How to Contribute for details.

  • Adam Barclay (echo)
  • Aleksandras Novikovas (alius)
  • Bidwai Sushrut (susbids)
  • Bill Snyder (wsnyder6)
  • Bryan Young (bryanyoung)
  • Dan Leuck (dleuck)
  • Daniel Lewis (drlewis)
  • Daniel Olivera (danielqo)
  • David Bolsover (bolsover)
  • David Hall (david_hall)
  • Diego Gil (dags)
  • Dirk Hillbrecht (dirkhillbrecht)
  • Doug Berkland (berkland)
  • Erik Vickroy (evickroy)
  • Fred Lavigne (l2fprod)
  • Gilles Philippart (gphilipp)
  • Haris Peco (snpe)
  • Jan Bosenberg (jansan)
  • Jan Haderka (rah003)
  • James Morgan (jmorgan)
  • Jeanette Winzenburg (kleopatra)
  • Karl Schaefer (kschaefe)
  • Mario Cesar (mario_cesar)
  • Mark Davidson (davidson1)
  • Mark Fortner (phidias)
  • Mark Thornton (mthornton)
  • Matt Nathan (mattnathan)
  • Michael Bush (michaelbushe)
  • Michael Swindle (mswindle)
  • Neil Weber (nweber)
  • Nicola Ken Barozzi (nicolaken)
  • Noel Grandin (grandinj)
  • Oleg Minukhin (minoleg)
  • Omprakash Visvanathan (ovisvana)
  • Paul Taylor (paultaylor)
  • Patrick Gotthardt (pago)
  • Patrick Wright (pdoubleya)
  • Pierre Le Lannic (weebib)
  • Ray Turnbull (rturnbull)
  • Ricardo Lopes (rlopes)
  • Richard Bair (rbair)
  • Richard Osbaldeston (osbald)
  • Robert Eden (reden)
  • Robert Stone (???)
  • Ronald Tetsuo Miura (ronaldtm)
  • Salvan Haas (syhaas)
  • Scott Delap (scottdelap)
  • Sean McNamara (allquixotic)
  • Simon Morris (javakiddy)
  • Shai Almog (vprise / shai.almog)
  • Thomas Bierhance (bierhance)
  • Wade Chandler (wadechandler)
  • Waldemar Klaczynski (wklaczynski)
  • Walter Wang (wangzaixiang)
  • Wolfgang Zilzelsberger (wzberger)
  • Xavier Hanin (xhanin)
  • Yannick Menager (ymenager)

If you have signed a JCA but are not listed on this page then please contact richard.bair@dev.java.net. This list is somewhat(!) out of date, and needs to be refreshed.