Currently, JSFML lacks a way of implementing custom drawables. By that, I mean that there is no Drawable interface that declares a drawing method that can be implemented in pure Java and that defines how an object is drawn. It can, of course, be done by writing a draw method that takes a RenderTarget as an argument and will proceed to draw to it, but this practically inverts the common SFML semantics of RenderTarget.draw(Drawable) and is therefore not ideal.
The question is how to do it properly. Currently, org.jsfml.graphics.Drawable is a basic interface without any method definitions, the main reason for this being the private access of the draw method in sf::Drawable implementations. Therefore, my solution proposal is as follows:
For JSFML (which uses its own set of SFML headers), modify the draw methods of the stock sf::Drawable implementations to be public. This is the simplest of ways and there should not be any real drawback. Nobody will use the JSFML headers for writing SFML applications in C++, so this would break SFML's design for JSFML's internals only.
In RenderWindow and RenderTexture, the draw methods would no longer be implemented natively, but delegate to the draw method of the respective Drawable on a Java level, which then is delegated to native code, ie exactly like SFML does this itself (except it has access to the protected method). This would result in a single Drawable interface that is implemented natively for the native SFML classes and can be equally used by custom implementations. This would also fix another serious problem that currently exists in the JSFML API: the Drawable interface has to be public, but currently it must not be implemented by anything that is not an SFMLNativeObject and passed to RenderTarget.draw, because it assumes an underlying SFML object.
I'm open to other solutions, of course. I don't really like to touch the SFML headers in any way, but on the other hand, this is a minor change with a huge benefit for the binding.