Clarification of how GUI Designer works

Russell Egan wrote:

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.

I wasn't favorable with bytecode manipulation long ago, before the gui
designer came to life.
And I still do not like it too much - I very much prefer the option of
being able to explicitly insert a call to construct the UI.

call me conservative ;)

Edo

Ok, the main problem - is transparent for binding form. Is it?

Hhhmmm .. no; I think the main problem is sticking stuff into compiled bytecode ....

Currently.

Exactly.

Alexey Efimov wrote:

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?

Bytecode manipulation is not simple. It very easy to make a mistake or
insert bytecode that may be valid in one situation but not in another.

But the dangers of bytecode manipulation is not my only argument. The
invisibility of the connection between the class and the form also
bugs me. And just showing the connection somehow in the IDEA UI is not
satisfactory. I want a visible line of code that initializes the GUI so
that I can control when it happens and I can see it as a step when I
debug the application.

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

>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.

It too young to be commercial :) But i want to programming with aspects as soon as posible, i wait for AspectJ integration :))

>Just adding a single line to load the form is pretty
>much transparent as well.
And follow we have XML of form definition in compiled jar... And everyone can chage it for his purpose, for example make password field - just blanked text field for looking at password... etc. I guess it's not secure.

>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.
It difference between hacking bytecode and using it. IntelliJ used BCEL for parsing and manupulating with bytecode, so, even if bytecode format changed, changed and BCEL realization, but intellij will not changed.
If you have source of you application you just rebild it for new JVM.
Bytecode is standard, it can't be changes suddenly.

>If you don't like the IDEA GUIBuilder, simply don't
>install the plug in and use something else ...

I like it, and will be used only it!!! :)

It too young to be commercial :) But i want to programming with aspects as soon as posible, i wait for AspectJ integration :))

That may be true, but until it gets a commercial stamp and is part of the compiler, I think many of the big Java developers will steer clear of it.

And follow we have XML of form definition in compiled jar... And everyone can chage it for his purpose, for example make password field - just blanked text field for looking at password... etc. I guess it's not secure.

Then rather than fiddling with the bytecode, wouldn't it be much easier to just encrpyt the form definition file and obsfuscate the classes that read it?

+It difference between hacking bytecode and using it. IntelliJ used BCEL for parsing and manupulating with bytecode, so, even if bytecode format changed, changed and BCEL realization, but intellij will not changed.
If you have source of you application you just rebild it for new JVM.+

Not as simple as that, because you are dealing with different JVMs. Not everyone will upgrade at the same time. And the app you build using IDEABuilder may have to run on a different (older) version of the JVM. So now you need more bytecode injections to decide which JVM you're going to be running on.

Bytecode is standard, it can't be changes suddenly.

It can't change suddenly, but it can still change.

>Are you saying that it will change hard-coded strings?

No, it doesn't and this is the problem. The class and package
structure might change, but when using a string
"com.company.application.Form", it would not be found on running
anymore, because its called now "a.b.c.d" for instance.

Tom

I want a visible line of code that initializes the GUI so
that I can control when it happens and I can see it as a step when I
debug the application.

>

Yes, persuade :)
But i not agree with you about control when GUI is building. This line must
present in code becose we must have valid debug process. But now we have
diference between class bytecode and source code... Currently it's no
good....

--
Alexey Efimov, Software Engineer
Sputnik Labs,
http://www.spklabs.com
"Gordon Tyler" <gordon.tyler@quest.com> wrote in message
news:bc7i53$qpl$1@is.intellij.net...

Alexey Efimov wrote:

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?

>

Bytecode manipulation is not simple. It very easy to make a mistake or
insert bytecode that may be valid in one situation but not in another.

>

But the dangers of bytecode manipulation is not my only argument. The
invisibility of the connection between the class and the form also
bugs me. And just showing the connection somehow in the IDEA UI is not
satisfactory. I want a visible line of code that initializes the GUI so
that I can control when it happens and I can see it as a step when I
debug the application.

>

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

>

"Gordon Tyler" <gordon.tyler@quest.com> wrote:

But the dangers of bytecode manipulation is not my only argument. The
invisibility of the connection between the class and the form also
bugs me. And just showing the connection somehow in the IDEA UI is not
satisfactory. I want a visible line of code that initializes the GUI so
that I can control when it happens and I can see it as a step when I
debug the application.

I totally agree. I would much rather have an explicit call into the
framework that clearly shows this dependency.

Thomas

i added idea.jar and did a complete rebuild before running before posting
this mistake; just to make sure i now took out the idea.jar, added it again,
and did a fresh rebuild. Same error. Any other ideas?
-Jill

"Mark Derricutt" <pinhead@satinism.org> wrote in message
news:pan.2003.06.11.06.31.35.454126@satinism.org...

On Tue, 10 Jun 2003 18:21:42 -0400, kesh wrote:

>

Add idea.jar file to your project's classpath

>

/kesh

>

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

>

Thomas Singer wrote:

What has obfuscation to do with debugging? A decent obfuscator can
create nice stacktraces with line numbers (if this is what you meant).

The program crashes at a client and they send the log file which
contains the stacktrace. In an obfuscated application, that stacktrace
is useless. And even if the obfuscator has a utility which translates
from the obfuscated stacktrace back to the original, it's still extra
effort to debug and I don't see what advantage obfuscation gives that is
worth this extra effort.

Maybe for you obfuscation is a vital part of your application
development, but I would not be happy if IDEA makes design decisions
just to satisfy obfuscation requirements when those decisions do not
make sense for non-obfuscated applications.

>>And what's wrong with reflection?

1) It does not provide compile-time-safety.

Adequate testing should provide the necessary safety.

2) It breaks with obfuscation.

As you may have noticed, that doesn't bother me.

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 Wed, 11 Jun 2003 16:16:54 -0400, Jill wrote:

i added idea.jar and did a complete rebuild before running before posting
this mistake; just to make sure i now took out the idea.jar, added it
again, and did a fresh rebuild. Same error. Any other ideas? -Jill

Where abouts is the exception hitting? Maybe the problems somewhere else,
paste a stack trace...

--
...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

>The program crashes at a client and they send the log file which
>contains the stacktrace. In an obfuscated application, that stacktrace
>is useless.

Maybe it's time to take a look at decent obfuscators?

>> 1) It does not provide compile-time-safety.
>
>Adequate testing should provide the necessary safety.

Are you joking? This might work for simple projects, but not for large
ones. Having (unit) tests is fine, but having the compiler tell me
that there is an error is significantly better.

BTW, how often you get stacktraces from clients? I guess you
shouldn't because you have the "adequate tests".

Cheers,
Tom

Goron,

We itself obfuscate IDEA.

In an obfuscated application, that stacktrace is useless.

Do you think we are asking for stacktraces just print them out & pin at the
wall?
--
Best regards,
Mike Aizatsky.
-

JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"

:))))))
You have been in funny mood, lately, Mike.

"Mike Aizatsky" <mike@intellij.com> wrote in message
news:bc9s6a$ot9$1@is.intellij.net...

Do you think we are asking for stacktraces just print them out & pin at

the

wall?

Yes. Do you frame them? If you like, I will send you signed paper copies from now on, so you can start a collection of signed stack traces, just like all those restaurants with the celebrity photos on the wall.

Mike Aizatsky wrote:

We itself obfuscate IDEA.

Let me ask you this: Why? What are your reasons for obfuscating the IDEA
classes?

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

Thomas Singer wrote:
>>>1) It does not provide compile-time-safety.
>>
>>Adequate testing should provide the necessary safety.

Are you joking? This might work for simple projects, but not for large
ones. Having (unit) tests is fine, but having the compiler tell me
that there is an error is significantly better.

And having a QA department which tests that the class, which the
compiler thinks is correct, actually does what the end-user expects to
do is even better.

But whatever, reflection has its uses, this may not be one of them.

That still doesn't mean it's good design to use bytecode insertion. How
about this instead: The form is compiled to a class which can be
subclassed by the developer to call the setupGUI and call accessors for
fields. Swing as an API is based on subclassing and it makes sense that
a GUI builder framework follows that style.

BTW, how often you get stacktraces from clients? I guess you
shouldn't because you have the "adequate tests".

Tests, while vital, can never discover 100% of the bugs. That's why good
logging which includes full stracktraces is necessary. Often, the
stacktrace is the only information you have to go on because the
environment is impossible to reproduce in-house.

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

javac and aop are standard and free tools. Intellij IDEA is not. This binds us to your IDE for GUI editing unless you are using some non-proprietary XML format

Tobias wrote:

javac and aop are standard and free tools. Intellij IDEA is not. This binds us to your IDE for GUI editing unless you are using some non-proprietary XML format

As well as any other ui editors out there. Or are there any standards
for ui editors to follow?

/kesh

As well as any other ui editors out there. Or are there any standards for ui editors to follow?

Most ones I've come across use either an editable resource file (JBeaver) or generate Java code directly (NetBeans and JBuilder).

The problem isn't how the resource is stored, its the use of an external tool to build them. Fine, you have an Ant task. What if I don't use Ant; what if I want to build in NetBeans? What about the next great build tool after Ant?

1) It does not provide compile-time-safety.

No, it doesn't; that's the job of good design, defensive programming and adequate testing. Collections don't provide compile-time safety either; I take it you don't use them?

Actually, arrays don't provide compile-time safety either; so how do you go about storing lists of data?

2) It breaks with obfuscation.

Well since reflection is part of the Java standard, I think that it's more the case that "obfuscation doesn't support reflection".

Relax! JetBrains have said that the Ant task will be open source. I'm sure
you'll be able to port it to the Next Big Thing as and when required.

Vil.

Rayz wrote:

As well as any other ui editors out there. Or are there any standards for ui editors to follow?

Most ones I've come across use either an editable resource file (JBeaver) or generate Java code directly (NetBeans and JBuilder).

The problem isn't how the resource is stored, its the use of an external tool to build them. Fine, you have an Ant task. What if I don't use Ant; what if I want to build in NetBeans? What about the next great build tool after Ant?

--
Vilya Harvey, Consultant
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

Disclaimer

This e-mail and any attachments may be confidential and/or legally
privileged. If you have received this email and you are not a named
addressee, please inform the sender at Digital Steps Ltd by phone on
+44 (0)1483 469 480 or by reply email and then delete the email from
your system. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this email. Although
Digital Steps Ltd routinely screens for viruses, addressees should
check this email and any attachments for viruses. Digital Steps Ltd
makes no representation or warranty as to the absence of viruses in this
email or any attachments.

+Relax! JetBrains have said that the Ant task will be open source. I'm sure you'll be able to port it to the Next Big Thing as and when required.
+

Just what I need. Another project on top of my project.

... and this still doesn't answer folks' reservations about the bytecode hacking.

Rayz wrote:

As well as any other ui editors out there. Or are there any standards for ui editors to follow?

Most ones I've come across use either an editable resource file (JBeaver) or generate Java code directly (NetBeans and JBuilder).

The problem isn't how the resource is stored, its the use of an external tool to build them. Fine, you have an Ant task. What if I don't use Ant; what if I want to build in NetBeans? What about the next great build tool after Ant?

I'm sorry that doesn't make sense to me. Why should IDEA care about
NetBeans or JBuilder? Let NetBeans care about IDEA. :) As I said as
long as there's no standard for ui builders, you cannot expect that you
can create ui with one tools and you can port it to the other.

/kesh

Fine, there are no standards for editors. But there is a right and a wrong way to do things. I just happen to think that JBeaver and NetBeans do things the right way.
+you cannot expect that you
can create ui with one tools and you can port it to the other.+

Why not? I can port EJBs from one server to another ...

I can take GUIs from NetBeans and carry on working on them without NetBeans being involved at all.

Thomas,

What do you think are the good obfuscators on the market.
Which one is JetBrains using?

Jacques
"Thomas Singer" <thomas.singer@NOregnisSPAM.de> wrote in message
news:a3cgevsjkj1mspo6pdo7l0nam1p2fde5os@4ax.com...

>The program crashes at a client and they send the log file which
>contains the stacktrace. In an obfuscated application, that stacktrace
>is useless.

>

Maybe it's time to take a look at decent obfuscators?

>

>> 1) It does not provide compile-time-safety.
>
>Adequate testing should provide the necessary safety.

>

Are you joking? This might work for simple projects, but not for large
ones. Having (unit) tests is fine, but having the compiler tell me
that there is an error is significantly better.

>

BTW, how often you get stacktraces from clients? I guess you
shouldn't because you have the "adequate tests".

>

Cheers,
Tom

What do you think are the good obfuscators on the market.

Well, we are using ProGuard. It's not the best available, but maybe
the best free.

Tom

you cannot expect that you can create ui with one
tools and you can port it to the other.
/kesh

That is precisely and exactly what I expect. I've worked on common code on serveral projects where different developers have used different tools. It's not unusual. The idea that a UI should be development tool dependent is ridiculous!

Vince.