Weekly progress news (10-16 of May, 2003)

This is a short progress report of what was going on in the development team
this week.

1. AspectJ support. Some first working implementation of make with AspectJ
support has been implemented. We'll test it a bit internally and open
AspectJ support to EAP (we have some AspectJ support in editor already).

2. GUI designer.
We have completed an Ant task which replaces the 'javac' task and should be
used to build applications containing GUI forms. It's now used to build IDEA
builds (we use our GUI designer to develop IDEA for some time already).
Now we are redesigning our undo/redo management to support the GUI designer
(as well as other custom editors that might be written). After we finish it
and also make some changes to the GUI form file format, we'll open the GUI
designer to EAP.

3. We have completely rewritten the implementation of the editor management.
Now it supports arbitrary custom editors (JComponent) inside the tabbed pane
where all editors are located. This allowed us to put our GUI designer into
the editor pane.
The API of this subsystem should be reviewed and after that we'll make the
first public draft of "custom editor" API.

4. Generics support. We have started the work to support generics. Some
changes in working with the source code tree have been done through the
whole code base. Part of the support in the parser has been done.

4. We are working on multiple debuggers per one project. We have made some
refactorings of the debugger to achieve it.

5. We have started working on "Packages View".

6. CVS. 'Ext' connection method is now supported. Some support for branches
has been done. Added actions: Edit, Unedit, Commit for directory.

7. We were working on switching Local VCS to the new module architecture.
It's almost completed.

8. We were experimenting on Look&Feel changes. They are in progress yet
(that might cause inconsistencies).

9. Optimization has been done not to scan JDK and library sources on startup
(only classes are scanned). It will be available in #816.



51 comments
Comment actions Permalink

Only parts for now


--
Eugene Belyaev, CTO
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"



"Michael Seele" <mseele@guh-software.de> wrote in message
news:2270907.1053345379862.JavaMail.jrun@is.intellij.net...

+8. We were experimenting on Look&Feel changes. They are in progress yet
(that might cause inconsistencies).+

>

do you change the whole look&feel or only parts of it?



0
Comment actions Permalink

I'll give the JetBrains developers some benefit of the doubt, mostly because they have come through in the past.

However, I really must voice my concern over the choice to modify the compilation of EVERY class, just to accomodate some modified behavior in form classes. I really don't mind having a separate ANT task to use for form classes, but going down the road of a custom build process is a rocky one.

I hope you'll give me the choice to use a standard build and my own GUI designer if I have a situation which needs to maintain a non-dependent build process.

PS - I'll probably love the GUI designer and not mind the custom build steps....but I'd like the choice.

0
Comment actions Permalink

why don't you support an ant commando(or only a button in IDEA) that generates a source file from the xml-file?! so nobody must change his build process... i remind me that you said in a earlier thread IDEA makes a source file internally!? if this predication is right, what's the problem in generating a .java file instead of generating a .class file???

0
Comment actions Permalink

IDEA does not generate any source files from GUI forms and I did not say
that it does. Anyway the problem (see above) is that it should also modify
your classes to work with the form.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"

"Michael Seele" <mseele@guh-software.de> wrote in message
news:16292084.1053352413660.JavaMail.jrun@is.intellij.net...

why don't you support an ant commando(or only a button in IDEA) that

generates a source file from the xml-file?! so nobody must change his build
process... i remind me that you said in a earlier thread IDEA makes a source
file internally!? if this predication is right, what's the problem in
generating a .java file instead of generating a .class file???


0
Comment actions Permalink

will your gui designer support jsr-57 long term persistence for java beans...

regards
gary

0
Comment actions Permalink

>IDEA does not generate any source

files from GUI forms and I did
not say that it does.


you said it in a thread(http://www.intellij.net/forums/thread.jsp?forum=22&thread=25031) ;)

GUI form is stored in an xml file.
It's compiled to the .class files when
you compile the project.
No source code is generated into
user's sources (although it's
generated internally).


but it's not important, because the solution isn't practicable if you must modify the .class files!!!

0
Comment actions Permalink

On Mon, 19 May 2003 13:53:33 +0000, Michael Seele wrote:

a source file internally!? if this predication is right, what's the
problem in generating a .java file instead of generating a .class file???


One problem I could see with that, is that it could lead to someone
tweaking the .java file, and causing problems with sync when the .ui file
is later changed.

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


0
Comment actions Permalink

do you change the men?s into a better design???

0
Comment actions Permalink

That still causes a lot of confusion for me too, but I'd suggest waiting for the first draft of the GUI designer and comment on it.

0
Comment actions Permalink

but it's not important, because the solution isn't practicable if you must

modify the .class files!!!

Why?

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"

"Michael Seele" <mseele@guh-software.de> wrote in message
news:11600335.1053411834717.JavaMail.jrun@is.intellij.net...

>IDEA does not generate any source

files from GUI forms and I did
not say that it does.

>

you said it in a

thread(http://www.intellij.net/forums/thread.jsp?forum=22&thread=25031) ;)

GUI form is stored in an xml file.
It's compiled to the .class files when
you compile the project.
No source code is generated into
user's sources (although it's
generated internally).

>

but it's not important, because the solution isn't practicable if you must

modify the .class files!!!


0
Comment actions Permalink

Having messed with jsr-57 implementation a lot in the past (August 2002), I would not recommend using it. It generates absolutely unreadable XML representation of serialized objects. The serialization/deserialization is very slow and inefficient. The implementation is not extensible. My overall impression is like it was done by a group of students as a homework.

0
Comment actions Permalink

i mean it's not important that you've said in a earlier thread, that IDEA generate source code internally. if you must modify the .class files, my idea with the .java files is useless!

0
Comment actions Permalink

Sergei S. Ivanov wrote:

Having messed with jsr-57 implementation a lot in the past (August 2002), I would not recommend using it. It generates absolutely unreadable XML representation of serialized objects. The serialization/deserialization is very slow and inefficient. The implementation is not extensible. My overall impression is like it was done by a group of students as a homework.


as usual... :) Personally I didn't expect aything else from SUN...

With best wishes,
Vladimir Kondratyev
___________________
JetBrains

0
Comment actions Permalink

I've just recently had to dig into XmlEncoder and XmlDecoder classes. I
would agree that the code is messy (of course, one pass with IDEA's
inspection and code layout tools would solve that! :) but I don't think it
is terribly slow or inefficient. Essentially the decoder is a SAX parser
that uses Java reflection to create objects and call methods, and reflection
is relatively slow, but not unworkable. Most of the warts seem to lie on
the encoding side -- handling objects with non-nullary constructors, or
other less common characteristics. But for encoding a typical JavaBean, it
seems pretty straightforward.

I'm not sure what you mean when you say it is not extensible; there is the
concept of a PersistenceDelegate which allows you to override their default
method of persistence. There are a number of examples kindly provided in
the J2SE 1.4 source to illustrate the technique (OK, so they're buried in
source code.. :)

I'm sure you've seen the schema description at
http://java.sun.com/products/jfc/tsc/articles/persistence3/index.html. It
does an acceptable job of explaining the XML representation, I think.

-Dave


"Sergei S. Ivanov" <jiveadmin@jetbrains.com> wrote in message
news:27204524.1053427191682.JavaMail.jrun@is.intellij.net...

Having messed with jsr-57 implementation a lot in the past (August 2002),

I would not recommend using it. It generates absolutely unreadable XML
representation of serialized objects. The serialization/deserialization is
very slow and inefficient. The implementation is not extensible. My overall
impression is like it was done by a group of students as a homework.


0
Comment actions Permalink

It was long time ago, so I cannot remember all the details, but nevertheless we had at least two major problems with XML serialization:

1. It was impossible to provide a custom extension to the serialization mechanism, because some important methods were declared private and could not be overridden. We had to duplicate a part of the framework to solve this problem. When we submitted bugs/requests to Bugparade, we got no definitive answers, and all our attempts to initiate a discussion were simply ignored.

2. It was impossible to specify a custom classloader for serialization/deserialization (we wanted the classes, unmarshalled from XML, to be instantiated within a specific classloader). encode()/decode() methods do not accept classloader as an argument. We had to resort to adjusting ThreadContextClassLoader before calling encode() and reverting it back later on.

0
Comment actions Permalink

as usual... :) Personally I didn't expect aything
else from SUN...


It may be my personal feeling, but the quality of JDK code, coming from Sun, has severely degraded during last years.

The situation is even worse, because:
- they are not always very keen on implementing the requests, coming from users. Neither do they like to discuss. Sometimes they close bugparade entries without explaining reasons.
- the release cycle is extremely long. In order to see important fixes to JDK/JRE, you have to wait for several months.

0
Comment actions Permalink

Good points. And that does seem to be the common response to bugs in the
Bug Parade. (If it ever comes up again, maybe a direct appeal to the author
of jsr 57 would be more productive?)

"Sergei S. Ivanov" <jiveadmin@jetbrains.com> wrote in message
news:27748407.1053521695658.JavaMail.jrun@is.intellij.net...

It was long time ago, so I cannot remember all the details, but

nevertheless we had at least two major problems with XML serialization:
>

1. It was impossible to provide a custom extension to the serialization

mechanism, because some important methods were declared private and could
not be overridden. We had to duplicate a part of the framework to solve this
problem. When we submitted bugs/requests to Bugparade, we got no definitive
answers, and all our attempts to initiate a discussion were simply ignored.
>

2. It was impossible to specify a custom classloader for

serialization/deserialization (we wanted the classes, unmarshalled from XML,
to be instantiated within a specific classloader). encode()/decode() methods
do not accept classloader as an argument. We had to resort to adjusting
ThreadContextClassLoader before calling encode() and reverting it back later
on.


0
Comment actions Permalink

You should only compile the forms themself and all
classes "associated" with
them. (For each form, there is one class associated
with it which has fields
binded to form controls. Instantiating of this class
automatically
instantiates the form and fill the fields.)


Wouldn't it be easier to populate the fields using reflection instead? For example by requiring the form-class to be instantiated through a factory:

MyCustomForm myCustomForm = (MyCustomForm) FormFactory.getInstance().newForm(MyCustomForm.class);

This would trigger your framework to load the associated XML-file and populate the fields of the class using reflection. The FormFactory would be located in your runtime-jar.

I've used this idiom succesfully in many other similar situations.

Code generation is a complicated thing and if possible it is best to avoid it. As you can see from this thread most people are not comfortable with the idea of using a custom compiler. For example how would this work with things like clover, aspect/J and other preprocessors/compilers?

0
Comment actions Permalink

Wouldn't it be easier to populate the fields using reflection instead? For

example by requiring the form-class to be instantiated through a factory:

How about obfuscating classes?

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


"Jon Tirsen" <jon_tirsen@yahoo.com> wrote in message
news:25659337.1053614232709.JavaMail.jrun@is.intellij.net...

You should only compile the forms themself and all
classes "associated" with
them. (For each form, there is one class associated
with it which has fields
binded to form controls. Instantiating of this class
automatically
instantiates the form and fill the fields.)

>

Wouldn't it be easier to populate the fields using reflection instead? For

example by requiring the form-class to be instantiated through a factory:
>

MyCustomForm myCustomForm = (MyCustomForm)

FormFactory.getInstance().newForm(MyCustomForm.class);
>

This would trigger your framework to load the associated XML-file and

populate the fields of the class using reflection. The FormFactory would be
located in your runtime-jar.
>

I've used this idiom succesfully in many other similar situations.

>

Code generation is a complicated thing and if possible it is best to avoid

it. As you can see from this thread most people are not comfortable with the
idea of using a custom compiler. For example how would this work with things
like clover, aspect/J and other preprocessors/compilers?


0
Comment actions Permalink

Wouldn't it be easier to populate the fields using

reflection instead? For
example by requiring the form-class to be
instantiated through a factory:

How about obfuscating classes?


That's true. Obfuscated classes wouldn't work unless there were some way for the obfuscater to obfuscate the field-names in the xml-file too.

Maybe both alternative could be supported? Custom compiler for people who use obfuscation and runtime reflection for people that simply cannot use a custom compiler (unfortunately there seems to be a lot of these). This would be resemble some AOP implementations that support both dynamic (online, class-loader based) and static (offline, pre/post-processor based) instrumentation.

A hack to support obfuscation would be to insert byte-code attributes in the class-file by some class-file post-processor. The attribute would associate a field with a control. This would be marginally better than a compiler (source is not needed, you can still use any compiler you like), but unfortunately it's not perfect (build-time processing is still required) and it's a bit complicated to implement.

Mark Pollack and Ted Neward experimented a bit with this in: http://attrib4j.sourceforge.net/
...but I don't remember how far they actually got.

0
Comment actions Permalink

Maybe both alternative could be supported? Custom compiler for people who

use obfuscation and runtime reflection for

We'll think of it. Let's return to this question later when we open the GUI
builder to the comminity at least.

--
Valentin Kipiatkov
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"


"Jon Tirsen" <jon_tirsen@yahoo.com> wrote in message
news:5686568.1053619687689.JavaMail.jrun@is.intellij.net...

Wouldn't it be easier to populate the fields using

reflection instead? For
example by requiring the form-class to be
instantiated through a factory:

>

How about obfuscating classes?

>

That's true. Obfuscated classes wouldn't work unless there were some way

for the obfuscater to obfuscate the field-names in the xml-file too.
>

Maybe both alternative could be supported? Custom compiler for people who

use obfuscation and runtime reflection for people that simply cannot use a
custom compiler (unfortunately there seems to be a lot of these). This would
be resemble some AOP implementations that support both dynamic (online,
class-loader based) and static (offline, pre/post-processor based)
instrumentation.
>

A hack to support obfuscation would be to insert byte-code attributes in

the class-file by some class-file post-processor. The attribute would
associate a field with a control. This would be marginally better than a
compiler (source is not needed, you can still use any compiler you like),
but unfortunately it's not perfect (build-time processing is still required)
and it's a bit complicated to implement.
>

Mark Pollack and Ted Neward experimented a bit with this in:

http://attrib4j.sourceforge.net/

..but I don't remember how far they actually got.



0

Please sign in to leave a comment.