Clarification of how GUI Designer works
I've been reading the various GUI designer threads here and I want to
see if I understand correctly how the GUI Designer works:
1. I create a GUI form with some buttons and stuff on it.
2. I create a class which contains some fields for the buttons and stuff
in the GUI form.
3. I bind the GUI form to the class.
4. I bind the buttons and stuff to fields in the class.
5. I compile all this and IDEA inserts bytecode into the class
constructor which creates the Swing components according to the GUI form
and assigns them to the fields.
Right?
I don't know about the rest of you, but I'm rather uncomfortable about
bytecode being magically inserted into my classes. Is this the only
feasible solution? I was under the impression, that the GUI would be
constructed dynamically at runtime by the framework using the form
description. The whole point about doing the GUI designer the _right
way_ is to get away from code generation, whether it be source or bytecode.
Ciao,
Gordon
--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: 416-643-4846 | Fax: 416-594-1919
Please sign in to leave a comment.
On Tue, 10 Jun 2003 16:53:08 -0400, Gordon Tyler wrote:
It is - the only byte code thats being inserted is a call to the framework
to load/parse/build the gui from the XML. If its only one or two lines,
it would be nice if we added it ourselves, or extended some base GUIForm
control.
Later - I could see this being done with AOP.
--
...turn to the light - don't be frightened by the shadows it creates,
...turn to the light - turning away could be a terrible mistake
...dream theater - the great debate
Gordon Tyler wrote:
What is so magical about inserting bytecode into a class? :) javac does it, aop
does it and nobody complains :)
--
Dmitry Skavish
-
Boston, MA, USA
tel. +1 781 910-3810
http://www.jzox.com
http://www.flashgap.com
For our product, we do the nightly/production builds using ANT.
If we do a clean build, how will this bytecode get inserted into our .class files? Would our build have to run IDEA to do this? That would be a serious problem for us.
Also, if we built some GUI with IDEA GUI Designer, what would we have to ship other jars with our product?
-Alex
Alex wrote:
Intellij guys will provide ant task for us (the extension of javac).
That what they said at least. You have to ship a small jar file, which I
guess will be opensourced.
/kesh
What am i doing wrong - I'm trying to compile a class that uses a form that
just has one JPanel (myJP) within which a JComboBox (myCB) resides - and get
an error. Details below.
-J
====
//newUI.java
public class newUI extends JFrame {
JPanel myJP;
JComboBox myCB;
public static void main(String[] args) {
new newUI();
}
public newUI() {
super("UI Test");
this.getContentPane().add(myJP, BorderLayout.CENTER);
this.setBounds(200,200,400,400);
this.setEnabled(true);
this.setVisible(true);
}
}
====
when i run it it returns:
====
java.lang.NoClassDefFoundError:
com/intellij/uiDesigner/core/GridLayoutManager
at newUI.$$$setupUI$$$(newUI.java)
at newUI.(newUI.java:22) at newUI.main(newUI.java:18) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:68) Exception in thread "main" Process terminated with exit code 1 ==== "Gordon Tyler" ]]> wrote in message
news:bc5gfk$umk$1@is.intellij.net...
>
>
>
bytecode.
>
>
>
Add idea.jar file to your project's classpath
/kesh
Jill wrote:
>>I've been reading the various GUI designer threads here and I want to
>>see if I understand correctly how the GUI Designer works:
>>
>>1. I create a GUI form with some buttons and stuff on it.
>>2. I create a class which contains some fields for the buttons and stuff
>>in the GUI form.
>>3. I bind the GUI form to the class.
>>4. I bind the buttons and stuff to fields in the class.
>>5. I compile all this and IDEA inserts bytecode into the class
>>constructor which creates the Swing components according to the GUI form
>>and assigns them to the fields.
>>
>>Right?
>>
>>I don't know about the rest of you, but I'm rather uncomfortable about
>>bytecode being magically inserted into my classes. Is this the only
>>feasible solution? I was under the impression, that the GUI would be
>>constructed dynamically at runtime by the framework using the form
>>description. The whole point about doing the GUI designer the _right
>>way_ is to get away from code generation, whether it be source or
>>Ciao,
>>Gordon
>>
>>--
>>Gordon Tyler (Software Developer)
>>Quest Software <http://java.quest.com/>
>>260 King Street East, Toronto, Ontario M5A 4L5, Canada
>>Voice: 416-643-4846 | Fax: 416-594-1919
>>
Dmitry Skavish wrote:
>> I don't know about the rest of you, but I'm rather uncomfortable about
>> bytecode being magically inserted into my classes.
Bytecode manipulation is not simple. Believe me, I know this. I
trust Javac (mostly) to get it right, but (I hate to say this) I don't
know if I trust IDEA to get it right all the time. And for the record,
I'm not too wild about AOP either ;)
Not only am I wary of the dangers of bytecode manipulation, I also don't
like that the class which I create has no visible connection to the form
that a developer can see, "Oh this line here creates the GUI". I would
much prefer having to add a line of code to my class which says
something like:
GUIFactory.createGUI("com.acme.gui.MyFunkyFrame");
... where MyFunkyFrame is the form that I've created. Then I'm in
control of what's going on. With the bytecode insertion, I have no
control over where it's inserted.
Ciao,
Gordon
--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: 416-643-4846 | Fax: 416-594-1919
On Tue, 10 Jun 2003 21:17:12 +0000, Alex wrote:
Jetbrains are providing ant Ant task to handle this.
--
...turn to the light - don't be frightened by the shadows it creates,
...turn to the light - turning away could be a terrible mistake
...dream theater - the great debate
On Tue, 10 Jun 2003 18:53:51 -0400, Gordon Tyler wrote:
Yup - I somewhat aggree with this, at least if the class implemented some
interface that showed it was a GUI form would be good as well.
--
...turn to the light - don't be frightened by the shadows it creates,
...turn to the light - turning away could be a terrible mistake
...dream theater - the great debate
On Tue, 10 Jun 2003 18:21:42 -0400, kesh wrote:
And also do a "build all" before running. There seems to be a bug in that
just hitting run doesn't do the byte code manipulation, thus not setting
your instance fields ( this is one of the downfalls of the byte code
manipulation method ).
Mark
--
...turn to the light - don't be frightened by the shadows it creates,
...turn to the light - turning away could be a terrible mistake
...dream theater - the great debate
>I would
>much prefer having to add a line of code to my class which says
>something like:
>
>
>... where MyFunkyFrame is the form that I've created. Then I'm in
>control of what's going on. With the bytecode insertion, I have no
>control over where it's inserted.
How you obfuscate the application (essentially for commercial desktop
applications) when using reflection-bllsht?
Tom
We'll provide ant task and runtime jar (which you will ship with your
application). Also we are planning to open source of the ant task and UI
Designer runtime to let you know (if you want to) what is going on.
--
Best regards,
Dmitry Peshehonov
JetBrains, Inc, http://www.intellij.com
Hello,
I posted my sample in IntelliJ Twiki site, maybe some one have interest to it simple test of UI designer and this help to unterstand how it work.
http://www.intellij.org/twiki/bin/view/Main/IntelliJUIDesigner
Thanks!
Yeah, this seems like a complicated way of doing things. I see the advantage that my source code file isn't cluttered, but wow, this seems like a risky, radical way of achieving that goal.
It seems to me that most projects would be very wary to adopt a framework that works this way, especially when there seem to be so many well-worn, conservative ways to build a gui builder. Ways that most people would think consider unimaginative, but would feel more comfortable with.
Now I don't believe Intellij didn't think about this, so they must have had some reasons for doing it this way.
So Intellij, here's a question: I'm down with the xml definitions. But your answer to the task of constructing the gui and giving my code access to it seems a little extreme. Why did you choose to do it this way? Why not create data structures at runtime, or gen the code in a class with getters/setters for the fields or something? You could have even done the binding thing with reflection. I understand there is some performance impact to all these approaches, but I wouldn't expect it to be dire enough to resort to bytecode manipulation.
Thanks very much for your time.
Russell Egan wrote:
With this approach, if you need an obfuscation, you are out of business.
Right?
/kesh
Couldn't obfuscation be performed after the bytecode manipulation?
What I'd like to see in the GUI Designer is some options.
For layout, I'd like to be able to choose to either generate an init() method with my layout or to perhaps load the form file dynamically. The generation would be less dynamic but also less intrusive....kind of like OculusLayout (a very cool layout product).
For binding, the current method of binding widgets to classes is OK, but I'd also like to see some ability for me to configure widget populate and action events via OGNL (aka. Struts, Tapestry, etc) allowing me to control the granularity of my controller classes, or map population to a JavaBean property. Binding assistance is important because it should not be a difficult chore to prepopulate the UI or connect my action handlers.
Sure, but it must be ensured, that everything works without
reflection.
Tom
Even, if bytecode works with refletion by hardcoded string name, this string can be changed while obfuscating.
Obfuscating can't be performed only in case of unknow (or parameterable) string value for reflection operations.
i guess :)
+Not only am I wary of the dangers of bytecode manipulation, I also don't
like that the class which I create has no visible connection to the form
that a developer can see, "Oh this line here creates the GUI". I would
much prefer having to add a line of code to my class which says
something like:
GUIFactory.createGUI("com.acme.gui.MyFunkyFrame");+
Have to agree.
.. and what happens if Sun decides to tweak the bytecode format?
>Even, if bytecode works with refletion by hardcoded string name, this string can be changed while obfuscating.
>Obfuscating can't be performed only in case of unknow (or parameterable) string value for reflection operations.
>i guess :)
I guess, it depends on the obfuscator. And I don't like it if a
tool/library prevents me from using tools I used before -- just for
technical reasons.
Tom
But if you look at BCEL project you have see that bytecode manipulation is very strong mechanizm for aspect programming and for plugins realization. This project used and IntelliJ, i think so, for UI initialization integration to bytecode.
Where are two ways - generate source code after form disign into you existing swing class, and perform bytecode operation on compiled class. I think that second way is more transparensy for developer, and i think is so good.
But that is dangerios in this way? The XML definitions leave in sources, in you class added just one method - $$$setupUI$$$. If you like - you can obfuscate it, becose reflection not used.
So, what is danger of bytecode manipulations?
Thanks!
Sure! i agree with you.
But if somebody like obfuscate - UIDesigner will not make any troubles with it. I wrong?
Manipulating byte code, bypassing compiler optimizations, post-build steps, a new ant task...
Seems like an awful lot of trouble to go through just to save me writing a couple extra lines of code.
In addition, those lines of code would explicitly tell another developer looking at my class that the class is bound to the form. If you look at my class now, there's no indication of the binding, and the class looks pretty wierd. Here I am using all these attributes without initializing them to anything. It would be a little confusing to me if I didn't already no wants going on.
I'm not really criticizing, I'm just wondering what I'm missing here...
Thomas Singer wrote:
>>I would
>>much prefer having to add a line of code to my class which says
>>something like:
>>
>> GUIFactory.createGUI("com.acme.gui.MyFunkyFrame");
>>
>>... where MyFunkyFrame is the form that I've created. Then I'm in
>>control of what's going on. With the bytecode insertion, I have no
>>control over where it's inserted.
Manners, Thomas...
I don't believe in obfuscation. We don't use it on our products because
it provides little benefit compared with the headache when trying to
debug the system.
And what's wrong with reflection?
Ciao,
Gordon
--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: 416-643-4846 | Fax: 416-594-1919
But if you look at BCEL project you have see that bytecode manipulation is very strong mechanizm for aspect programming and for plugins realization. This project used and IntelliJ, i think so, for UI initialization integration to bytecode.
I don't know of many commercial apps that use aspects yet, and I don't think you will see them widely used until they're actually built into the standard Java compiler.
Where are two ways - generate source code after form disign into you existing swing class, and perform bytecode operation on compiled class. I think that second way is more transparensy for developer, and i think is so good.
Just adding a single line to load the form is pretty much transparent as well.
So, what is danger of bytecode manipulations?
The danger is that the danger is unclear. What happens if the byte code format does change? Then you will need more bytecodes inserted to work out which version of the JVM you are running on. Sorry, but I don't believe that hacking bytecodes is a good idea, in much the same way that I don't try to enhance C++ programs by taking a hex editor and fiddling with the .exe file.
Fortunately, it isn't that much of a problem. If you don't like the IDEA GUIBuilder, simply don't install the plug in and use something else ...
The only optimization compiler performs is inclining of final static fields
with constant initializes.
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
How you obfuscate the application (essentially for commercial desktop applications) when using reflection-bllsht?
I don't know much about obsfucation to be honest, but now I'm a bit curious.
Are you saying that it will change hard-coded strings?
Ok, the main problem - is transparent for binding form. Is it?
Then we must ask for it in next build. IntelliJ can show this link by interface, like and structure view.
It not requred put link with UI form into code. I think more likely see link with form at classes tree.
>I don't believe in obfuscation. We don't use it on our products because
>it provides little benefit compared with the headache when trying to
>debug the system.
What has obfuscation to do with debugging? A decent obfuscator can
create nice stacktraces with line numbers (if this is what you meant).
>And what's wrong with reflection?
1) It does not provide compile-time-safety.
2) It breaks with obfuscation.
Tom