ACCESSIBILITY

Current image captchas tests are not very accessible, and this is a major concern for us.
There is currently no consensus around this issue, but some solutions are rising.
See :

Matt Presents: Escape from CAPTCHA
Inaccessibility of Visually-Oriented Anti-Robot Tests
[http://www.bestkungfu.com/index.php?s=captcha&submit=Go}
Logic puzzle solution, and Sound captchas are now available with JCaptcha

X11

Question :
Argh! :

com.octo.captcha.CaptchaException: java.lang.InternalError: Can"t connect to X11 window server using ":0.0" as the value of the DISPLAY variable.
Or
java.awt.HeadlessException:
No X11 DISPLAY variable was
set, but this program performed an operation which requires it.

Answer :
You have correcly find out what is wrong : by default, you need a XServer to use jcaptcha. the java Toolkit use it to build images.

First of all if jcaptcha running on a 1.4 or higher JDK be sure you run your jvm with the:

-Djava.awt.headless=true

option.
This should solve the problem.
Otherwise,
The captcha team (in fact mathieu) had a thought about this and designed a ToolkitFactory helper class.
It provides a way to avoid the installation of a xserver. This trick is documented
in the javadoc.
Extract:

/**
 * Description: This Factory is used in order to switch from the
 * java.awt.Toolkit component to other implementation like <a href="http://www.eteks.com/pja/en/">PJA Toolkit</a>. By default this factory
 * return the java.awt.Toolkit object.
 But if the the parameter
 * <code>toolkit.implementation</code> is fixed as a parameter of the virtual machine with
 * the value of the class name of another implementation of Toolkit, this
 * factory return an implementation of this class. For exemple if you set to
 * your virtual machine <code>-Dtoolkit.implementation=com.eteks.awt.PJAToolkit</code>, the
 * factory returns an implementation of com.eteks.awt.PJAToolkit
*/

Performance

Image generation is a very heavy process : it cost a lot of CPU and RAM.
A particular attention has been given to performance in the devellopement and test process of JCaptcha.
In order to achieve transparency on this subject, the framework is heavily load tested, and tests results are provided in the source distribution.
The tests are currently run on various plateforms including wintel, linux, and sparc/ux.
We encourage you to run and publish the load tests on your own production platform...
Load tests concerns :

JCaptcha engines integration load tests: to compare the CPU/RAM cost of a particular captcha test generation
JCaptcha services mocked load tests: to compare the CPU/RAM cost of a particular life cycle management strategy
JCaptcha services integration load tests: to compare the CPU/RAM cost of a particular life cycle management strategy with a particular
To run load tests, simply run maven having this line commented in the build.properties file :
```
 jcaptcha.load.test.exclude=**/*LoadTest*.*
```
see : http://fisheye1.cenqua.com/browse/jcaptcha/jcaptcha/build.properties?r=1.15#l7

Management and JMX

The jcaptcha service provide some jmx facilities.
A manageable service provides :

Runtime engine switch
Usage and success statistics
Cache and Buffer management
The current implementation of the ManageableCaptchaService interface is JMX enabled.
All modules includes a JMX registration parameter that automatically register the Jcaptcha Service
to a JMX server.
See modules documentation and java docs for details.

TODO : refactor the FAQ