Any compliant JavaBean library would support Design Time semantics. In a nutshell, a bean (component) is understood to run in a container. In design time, that container is the editor 'canvas' and in runtime, the root of of (gui) container hierarchy. The author of the bean is expected to query this state flag and act appropriately e.g. change borders in designtime to include 'handles' to drag for resize, etc. And, naturally, the parent component (which is assumed to be a design canvas of sorts) is also expected to respect design changes e.g. modify the layout to handle the resized component.
That said, I don't believe any of the current offerings allow you to simply switch between designtime and runtime at whim in your app.
Effectively, you'll need to (a) pick a library and (b) bundle the necessary machinery to support designtime with your running app, and (c) in effect masquerade a design surface (canvas) as your runtime gui. Of course you will only need to support the design ops you are interested in, but bottom line, you are writing a GUI editor.
What's the benefit of this approach? Well, you are reusing "components" and mostly need to hack the container.
If I had to do something like this, I would seriously look at netbeans, keep this STO question in mind, and take it from there.
