since borland jbuilder and oracle jdeveloper don't use
special comments for the gui, it is generally possible to
import into these ides a form designed in netbeans,
however the reverse isn't possible at all.
please can you add a wizard to import the form from other
ide so that can be used in netbeans form editor?
*** Issue 35647 has been marked as a duplicate of this issue. ***
*** Issue 49563 has been marked as a duplicate of this issue. ***
We'd like to have such import wizard. Just not decided yet to go and implement
it. But this is clearly a highly requested and strategic feature.
Related to issue 35849.
The absence of any ability to migrate existing source code (GUI forms) to
NetBeans is the only reason my software shop has not made the transition to
NetBeans. Management simply refuses to support two IDE's and since our codebase
is written in JBuilder, that is where we will stay even if NetBeans is a better
product for our needs. Please implement this feature - my team wants to use
(By migrate, I obviously mean that we need to be able to visually edit/update
gui forms written in JBuilder and/or other IDE's. Everyone knows that simple
code level migration/editing/compilation can be done in any editor including
Perhaps the following could be used in some way to accomplish this:
*** Issue 60421 has been marked as a duplicate of this issue. ***
This issue has also been reported in:
*** Issue 67950 has been marked as a duplicate of this issue. ***
FWIW, I recently wrote some analysis code for the Wicket module that examines the closure of a Wicket panel's constructor, finds all the adds and builds a
tree of data from that. It's not very hard to do (for inspiration, see the javac package in http://nbwicketsupport.dev.java.net ).
The point being, with the javac APIs it wouldn't be very hard to:
- Scan for constructors; for each constructor
- Visit each method invocation and its closure. For each method invocation
- See if it's an invocation of add() or something that calls add() and if the thing it's being called on is a subclass of java.awt.Container (you could
borrow my code and change a couple of strings for this).
- If yes, add it to the component metadata tree you're building
- If no, see if it's a method on a component or subclass. If yes, remember this info to see if it is the setting of a property later
Random code that can't be identified in the constructor could either be left there, or converted to pre/post-init blocks.
Eventually, generate a new Java source file + form file, use the data gathered tree to populate the form XML file and trigger generating the
initComponents() the same way the form editor does when you change something.
The hard part for me to try to do this is that AFAIK the form XML format is undocumented. I don't think something like this has to (or can) work in 100% of
the cases, but 80-90% would make a lot of people pretty happy - being able to use Matisse with existing UI code is a big deal.