[JCI] GSOC status

[Peter Konstantinov <pa...@iu6.ru>]

Dear JCI developers,

I'm Google SOC applied student, working on jci. Let's see what I made for
current 
moment, fell free to comment and aks questions. 

Implementation of support file-based compilers in jci is my main task now.
To example 
my approach I implicated support of javac (currently call only). I used
javasist 
library to replace file-working classes with my proxis. It's seems this
approch 
would work fine for every java-based java compiler. Yep, I know that
javasist is 
pretty fat and slow, but it's only technological preview, and I hope
implication 
would become more satisfactory in future. And of course, unavailability of 
fork-call, remain main problem of this approach. 

Support of maven is my second goal. It's pretty simple, and I already
developed 
main part of maven plugin. But problem of abstract configuration of
jci-compilers 
isn't steal solved. As you know, now every jci-compiler has own
configuration 
class, in the other hand we have only one compiler-configuration format in 
plexys. So, you can see what shall we aim to.

 

---------------------------

Peter Konstantinov

 

 

Re: [JCI] GSOC status

[Brett Porter <br...@apache.org>]

On 19/06/2006 8:45 PM, Torsten Curdt wrote:
>> I quite like the pattern of a little bootstrapper so that forking is the
>> same code as usual, just with a bootstrapper that runs the jvm in the
>> middle.
> 
> Care to elaborate? ;-)

I couldn't think of much more to explain it than that. Here's an example:
http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SurefireBooter.java
command line constructed here: 
http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkConfiguration.java

In the booter, look at the main method (which calls runSuitesInProcess), 
and the run() method (which either calls runSuitesInProcess, or calls 
fork*() which then calls main, which calls runSuitesInProcess). You 
don't need to worry about the properties and classloader construction, 
there are other ways to pass them around and you probably already 
construct those in JCI.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

RE: [JCI] GSOC status

[Peter Konstantinov <pa...@iu6.ru>]

> > > I though we had to use a very ugly work-around but Peter found a 
> > > very smart way around that. Really good!
> >
> > Care to elaborate?
>
> Bytecode rewriting and proxies involved.
> Peter, care to explain that yourself? :-)
Let's see, here is some solutions, that was considered:

    * The obvious way: just create files on temp FS on disk. But it would be
hard one, because ResourceReader cann't look through all resources. And it's
very slow and ugly as well.
    * In JavaС 1.6 we can replace FS using javax.tools.JavaFileManager. This
is the best solution - easy and fast, but compatible only with java 1.6. But
we can use anyway.
    * What if we use this approach for java 1.5-? What would we do to make
compiler think, that it works with files, but use sources in memory? We need
just create own ClassLoader, which will replace file-working classes with
our memory-working proxis. I do it through jboss:javasist, but we can use
any other library (asm, bcel), or handmade butecode replacer.

---------------------------
Peter Konstantinov





---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [JCI] GSOC status

[Torsten Curdt <tc...@apache.org>]

> > I have some work lined up that will include:
> >
> > o examples and documentation
> > o configuation management
> > o fixing an eclipse compiler issue
> > o class dependency awareness
> >
> > ...and at some stage adding jsr199 support.
>
> That's a lot of work :)

Well, at some stage I would like to see a release so... :)
But it's probably less work than it sounds.

<snip/>

> > I though we had to use a very ugly work-around but Peter found a very
> > smart way around that. Really good!
>
> Care to elaborate?

Bytecode rewriting and proxies involved.
Peter, care to explain that yourself? :-)

<snip/>

> > ...forking will become interesting - probably for all compilers though.
>
> I quite like the pattern of a little bootstrapper so that forking is the
> same code as usual, just with a bootstrapper that runs the jvm in the
> middle.

Care to elaborate? ;-)

<snip/>

> Yes, I think that's the right way to go about it, rather than starting
> from scratch.

Yepp

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [JCI] GSOC status

[Brett Porter <br...@apache.org>]

Torsten Curdt wrote:
>> Is there some code we can see for these?
> 
> Just have a browse here:
> 
> http://svn.apache.org/viewvc/jakarta/commons/sandbox/jci/trunk/

Ok, I'd missed that you'd applied those for him. Will do.

> 
> ...especially the maven plugin.

I'm at a bit of a loss as to why we need a whole new one. I can 
understand it might be a bit harder to work it into the "live" Maven 
plugin as this is experimental, but why don't we copy the existing one 
over to JCI (as if it were a branch), and modify it there? It can be 
merged back if it works out. That way you can aim for functional 
equivalence and backwards compatibility.

> 
> I have some work lined up that will include:
> 
> o examples and documentation
> o configuation management
> o fixing an eclipse compiler issue
> o class dependency awareness
> 
> ...and at some stage adding jsr199 support.

That's a lot of work :)

> 
> Brett, is there a way to exclude modules based on jdk versions? The
> jsr199 implementation will only compile with mustang. We probably will
> have to use profiles for that, right? Can you exclude whole modules
> based on that?

Yes.

> 
>> I'd generally recommend making small, incremental changes through a
>> series of small patches. That way you can get your work reviewed (and
>> applied!) sooner, and if anything needs changes or it's going in the
>> wrong direction, there's less impact.
> 
> yepp +1 ...at the moment I've asked to get a patch at least every
> week. But more often would be even better.

I'll try and filter the JCI ones separately so I actually see them :)

>> While I think I understand what you are doing here, the original
>> assumption was to use the code in Maven as a starting point. Was there a
>> reason not to do this? Javac is completely implemented there.
> 
> While I agree starting from the maven source code would have been
> better, the maven implementation is probably not good enough as jci
> features in memory compilation ...which is not directly supported by
> javac out-of-the-box.
> 
> I though we had to use a very ugly work-around but Peter found a very
> smart way around that. Really good!

Care to elaborate?

> ...forking will become interesting - probably for all compilers though.

I quite like the pattern of a little bootstrapper so that forking is the 
same code as usual, just with a bootstrapper that runs the jvm in the 
middle.

> Well, maybe my fault. I thought starting of from the
> maven-compiler-plugin code but building it in jci as maven-jci-plugin.
> Once stable it should be an easy replacement and we can move the code
> over to the maven-compiler-plugin codebase. WDYT?

Yes, I think that's the right way to go about it, rather than starting 
from scratch.

Cheers,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [JCI] GSOC status

[Torsten Curdt <tc...@apache.org>]

> Is there a description of what you are working on that has any more
> details than: http://wiki.apache.org/general/SummerOfCode2006? I
> couldn't find anything else.

Hm... for some reason the application is not linked at

 http://code.google.com/soc/asf/about.html

...but it does not provide really much more information than a roadmap
with dates and information about Peter. Everything else you should be
aware of ;-)

Plan is to at least port/implement a javac and jikes implementation
for jci and then get a maven plugin started based on the maven
compiler plugin code.

> Is there some code we can see for these?

Just have a browse here:

 http://svn.apache.org/viewvc/jakarta/commons/sandbox/jci/trunk/

...especially the maven plugin.

I have some work lined up that will include:

o examples and documentation
o configuation management
o fixing an eclipse compiler issue
o class dependency awareness

...and at some stage adding jsr199 support.

Brett, is there a way to exclude modules based on jdk versions? The
jsr199 implementation will only compile with mustang. We probably will
have to use profiles for that, right? Can you exclude whole modules
based on that?

> I'd generally recommend making small, incremental changes through a
> series of small patches. That way you can get your work reviewed (and
> applied!) sooner, and if anything needs changes or it's going in the
> wrong direction, there's less impact.

yepp +1 ...at the moment I've asked to get a patch at least every
week. But more often would be even better.

> > Implementation of support file-based compilers in jci is my main task now.
> > To example
> > my approach I implicated support of javac (currently call only). I used
> > javasist
> > library to replace file-working classes with my proxis. It's seems this
> > approch
> > would work fine for every java-based java compiler. Yep, I know that
> > javasist is
> > pretty fat and slow, but it's only technological preview, and I hope
> > implication
> > would become more satisfactory in future. And of course, unavailability of
> > fork-call, remain main problem of this approach.

Actually we would also need to verify that it is really release under
MPL version 1.1 ...otherwise we would have licensing problem. But I
suggest to use

 http://vafer.org/projects/dependency/

anyway. It should be good enough for at least how we use javassist at
the moment and we will have that dependency to "dependency" ;-)
anyway.

> While I think I understand what you are doing here, the original
> assumption was to use the code in Maven as a starting point. Was there a
> reason not to do this? Javac is completely implemented there.

While I agree starting from the maven source code would have been
better, the maven implementation is probably not good enough as jci
features in memory compilation ...which is not directly supported by
javac out-of-the-box.

I though we had to use a very ugly work-around but Peter found a very
smart way around that. Really good!

...forking will become interesting - probably for all compilers though.

> > Support of maven is my second goal. It's pretty simple, and I already
> > developed
> > main part of maven plugin. But problem of abstract configuration of
> > jci-compilers
> > isn't steal solved. As you know, now every jci-compiler has own
> > configuration
> > class, in the other hand we have only one compiler-configuration format in
> > plexys. So, you can see what shall we aim to.

That should be easy to implement through a factory pattern.

> I'm just seeing now that the original description would have been
> misleading - it's not desirable to write a new compiler plugin, but
> instead to integrate commons-jci into the existing one (instead of the
> plexus compiler).

Well, maybe my fault. I thought starting of from the
maven-compiler-plugin code but building it in jci as maven-jci-plugin.
Once stable it should be an easy replacement and we can move the code
over to the maven-compiler-plugin codebase. WDYT?

> Looking forward to hearing more about your work!

Same here! :)

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [JCI] GSOC status

[Brett Porter <br...@apache.org>]

Hi Peter,

Is there a description of what you are working on that has any more 
details than: http://wiki.apache.org/general/SummerOfCode2006? I 
couldn't find anything else.

Please bear in mind that while I'm a mentor, I actually haven't worked 
on JCI (yet), just Maven, so there's every chance I don't understand how 
it works and you can feel free to tell me I'm wrong :)

Peter Konstantinov wrote:
> Dear JCI developers,
> 
> I'm Google SOC applied student, working on jci. Let's see what I made for
> current 
> moment, fell free to comment and aks questions. 

Is there some code we can see for these?

I'd generally recommend making small, incremental changes through a 
series of small patches. That way you can get your work reviewed (and 
applied!) sooner, and if anything needs changes or it's going in the 
wrong direction, there's less impact.

> Implementation of support file-based compilers in jci is my main task now.
> To example 
> my approach I implicated support of javac (currently call only). I used
> javasist 
> library to replace file-working classes with my proxis. It's seems this
> approch 
> would work fine for every java-based java compiler. Yep, I know that
> javasist is 
> pretty fat and slow, but it's only technological preview, and I hope
> implication 
> would become more satisfactory in future. And of course, unavailability of 
> fork-call, remain main problem of this approach. 

While I think I understand what you are doing here, the original 
assumption was to use the code in Maven as a starting point. Was there a 
reason not to do this? Javac is completely implemented there.

> Support of maven is my second goal. It's pretty simple, and I already
> developed 
> main part of maven plugin. But problem of abstract configuration of
> jci-compilers 
> isn't steal solved. As you know, now every jci-compiler has own
> configuration 
> class, in the other hand we have only one compiler-configuration format in 
> plexys. So, you can see what shall we aim to.

I'm just seeing now that the original description would have been 
misleading - it's not desirable to write a new compiler plugin, but 
instead to integrate commons-jci into the existing one (instead of the 
plexus compiler).

Looking forward to hearing more about your work!

Cheers,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org