JUnit 4 will be the first OpenSource release in the sense that other people's contributions will predominate over KentBeck and ErichGamma's.

Here are the features to be added in JUnit 4:

General goal
	* Define the deadline for the version 4.0 (VladimirBossicard)
	* Runs on standard JDK. Need to decide whether giving up JDK 1.1.7 compatibility.
	  The current status of the survey on SourceForge is 25 (JDK 1.1.7 compatible) 
	  to 60 (not JDK 1.1.7 compatible.
	* Encourage more developers.
	* 4.0 changes should come from someone else.

Features - framework
	* Classloader user problem : possibility to modify the list of reloaded classes dynamically, w/ user interaction (done - VladimirBossicard)
	
		The excluded filter mechanism in JUnit 3.7 is fragile. See the detailed analysis
		of the JAXP problem that was posted to the junit mailing list. We should look for
		for an alternative. The reloading 
		should work without having the user tweak the list of excluded filters. A "green"
		idea would be to load _all_ user classes by a new class loader instance for each test run.	
		In other words only system classes on the bootstrap class path will not be reloaded  
		in each run. The JDK 1.2 delegating class loader mechanism combined with the	
		URLClassLoader should enable this. However, this needs some experimentation (ErichGamma)

	* Multi-thread test support (I submitted a TestDecorator at sourceforge a few months ago that handles this via a ThreadGroup and the uncaughtException method -- GregVaughn)
	* Start architecting in the basics needed to allow others to support key features while still resting on-top of the current source tree. i.e. Look at the common patterns (if any) used of how people have implemented the special features of JXUnit/JakartaCactus(previously known as J2EEUnit)/ etc.. and start putting in place mechanisms to make them easier to do from the root tree.  The goal here is to minimize the number of branches out there for extensions that could have been done using some basic extensibility pattern.
	* Place messages in a resource bundle (ErichGamma)
	* Add a method to the TestCase interface Test.setUp( Properties p ), so that tests can be supplied relevant context information.  One example would be the contents of a .properties file containing identities of database records to use in tests.  A related example would be the same information, but supplied by a ServletTestRunner using properties harvested from the servlet's deployment descriptor.  The TestRunner is then free to obtain the properties in whatever manner makes sense to it. ( DavidBullock )
	* Add a method to the TestCase interafce Test.setUp( TestContext ctx ), so that the tests can have access to services such as logging.  An example of this is in the Servlet environment, where PrintWriter for trace statements are obtained from a ServletContext ( as are many other services ).  If you like, the Properties ( above ) can be obtained from the TestContext interface.  ( It is important that TestContext is a true interface, to give TestRunners maximum flexibility ).  ( DavidBullock )
	* ''I'd like to see TestSuite''''''s announce startup and completion, as well as test cases. --RobertWatkins''
	* ''I'd like to see the TestSuite constructor taking a Class object to first check whether the test class has a suite() method before using reflection to assemble the test methods. -- JbRainsberger''
	
Features - runner
	* Analyze a failure in detail.
	* Does the Jar loading really work? There are not enough tests!

		Rather than loading JARs manually we should leverage the JDK 1.2.2
		URLClassLoader class (ErichGamma)
Features - ui
	* UI (proposed and almost finished - VladimirBossicard)
	* Encourage other people to implement new GUIs (one new gui done - VladimirBossicard)
	* Add a new package with a UI we will include in the JUnit release.
	* Make the exclusion mechanism more accessible in the UI. (done - VladimirBossicard)
	* Help support (skeleton done - VladimirBossicard)
	* Make FAQ more accessible (in the doc or help - VladimirBossicard)

Features - misc
	* Test log in XML
	* Test evolution over time
	* Encapsulate the basic JUnit runner in a bean (-> define a borderline between the the core JUnit code and the applications (textui, swingui) using it).  It allows 3rd party applications to focus on the core functionalities of JUnit and give us more freedom to modify the textui and swingui runners.  We can then only guarantee backward compatibility for the bean and not the different application (VladimirBossicard).
	* Plug-in architecture for the bean (see proposition - VladimirBossicard)
	* Worldwide JUnit server with local variations
		What variations are you thinking of? (VladimirBossicard)

Development process
	* Stay IDE neutral
	* Set up a CVS tree to enable nightly build (VladimirBossicard)
	* Introduce beta version before official release
	* Set up a group of beta testers to have a wide panel of JUnit users and projects (VladimirBossicard)
	* Rules for contributing

To Do Items for 4.0 (from http://sourceforge.net/projects/junit)
	* [ #229959 ] Missing old functionality from the "Test Browser" window (on it's way - VladimirBossicard)
	* [ #231767 ] "Failure/Error" list not updated correctly (icons)
	* [ #404165 ] Add properties from command line (have propositions - VladimirBossicard)
	* Define a runner API for the TestRunners, currently there is no consistent API (have propositions - VladimirBossicard)

----

Here are features that will just have to wait until later:

----
See also: JavaUnit