Home » Language IDEs » Java Development Tools (JDT) » JDT is not aware of classes compiled by another compiler
| JDT is not aware of classes compiled by another compiler [message #234897] |
Tue, 22 August 2006 17:04  |
Eclipse User |
|
|
|
Originally posted by: a.shneyderman.gmail.com
I have a builder and that calls upon a groovy compiler. The compiler is
spitting out .class files. I would like my JDT to be aware of the newly
produced .class files. How do I do that. Just placing .class files into the
output directory does not appear sufficient.
I have been looking for some similar code samples but unable to find any.
Anyone has an idea?
Thanks,
Alex.
|
|
| | | | |
| Re: JDT is not aware of classes compiled by another compiler [message #235076 is a reply to message #235050] |
Thu, 24 August 2006 06:51  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------010402080401020400040809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Alex,
The expectation is that there will be a builder that's hooked up to
produce these results for all the various tools that produce build
results. So at the beginning of the build, the bin directory can be
flushed and then the builders will populate it during the build. I'm
pretty sure AJDT does this too. I suspect that your reasoning about the
error markers implying AJDT has this problem too is flawed. I expect
that what you see is simply a reflection of the fact that Aspect source
code is not valid Java syntax and needs to be interpreted by an Aspect
aware processor/editor. Ask yourself this, could AJDT function at all
without having solved this problem?
How about compiling to a folder other than bin and putting that folder
on the classpath?
Alex Shneyderman wrote:
>> I don't think the JDT Java editor really look at the output directory.
>> It looks at the source folders, jars, and class folders. That is because
>> the output directory is for generated output that can be wiped, erased,
>> and recreated at any time.
>>
>
> That's a real pitty. There are a few tools I know that take a non java
> source
> and produce the .class files. One example comes to mind is AspectJ.
>
> I just checked how AspectJ deals with this and found out that it does not.
> So say
> you write an advice A. AJDT will produce A.class file in your output dir.
> Then in
> your java one could do A.aspectOf(). When I use java editor red markers pop
> up
> all over. In AJ editor auto-completion does not work but at least no
> complaints from
> the editor.
>
> I wonder if there is a way to make java editor understand the situation
> somehow.
>
>
>> Does your "groovy compiler" use java source, or does it use some other
>> kind of source that generates only a java .class file?
>>
>
> nope groovy source is a groovy source (groovy.codehaus.org), but groovyc
> will
> produce .class files. no intermediate .java are produced.
>
> Alex.
>
>
>
--------------010402080401020400040809
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Alex,<br>
<br>
The expectation is that there will be a builder that's hooked up to
produce these results for all the various tools that produce build
results. So at the beginning of the build, the bin directory can be
flushed and then the builders will populate it during the build. I'm
pretty sure AJDT does this too. I suspect that your reasoning about
the error markers implying AJDT has this problem too is flawed. I
expect that what you see is simply a reflection of the fact that Aspect
source code is not valid Java syntax and needs to be interpreted by an
Aspect aware processor/editor. Ask yourself this, could AJDT function
at all without having solved this problem? <br>
<br>
How about compiling to a folder other than bin and putting that folder
on the classpath?<br>
<br>
<br>
Alex Shneyderman wrote:
<blockquote cite="midecj0vr$usc$1@utils.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">I don't think the JDT Java editor really look at the output directory.
It looks at the source folders, jars, and class folders. That is because
the output directory is for generated output that can be wiped, erased,
and recreated at any time.
</pre>
</blockquote>
<pre wrap=""><!---->
That's a real pitty. There are a few tools I know that take a non java
source
and produce the .class files. One example comes to mind is AspectJ.
I just checked how AspectJ deals with this and found out that it does not.
So say
you write an advice A. AJDT will produce A.class file in your output dir.
Then in
your java one could do A.aspectOf(). When I use java editor red markers pop
up
all over. In AJ editor auto-completion does not work but at least no
complaints from
the editor.
I wonder if there is a way to make java editor understand the situation
somehow.
</pre>
<blockquote type="cite">
<pre wrap="">Does your "groovy compiler" use java source, or does it use some other
kind of source that generates only a java .class file?
</pre>
</blockquote>
<pre wrap=""><!---->
nope groovy source is a groovy source (groovy.codehaus.org), but groovyc
will
produce .class files. no intermediate .java are produced.
Alex.
</pre>
</blockquote>
<br>
</body>
</html>
--------------010402080401020400040809--
|
|
|
| Re: JDT is not aware of classes compiled by another compiler [message #235083 is a reply to message #235076] |
Thu, 24 August 2006 09:37 |
| Eclipse User |
|
|
|
Originally posted by: a.shneyderman.gmail.com
Ed, I think we are talking apples and oranges here,
or maybe I was not clear in my explanations.
Here is a second try:
I have an ApsectJ advice that looks like this:
public aspect ErrorCodeResolvingAspect {
protected pointcut errorResolvableJoinPoints () ..... ;
after () throwing (Throwable e) : errorResolvableJoinPoints () {
....
}
}
assuming that the aspect above is syntactically correct AJDT will
produce .class file in hte output directory. If I create .java file
and open it with Java editor, I can say something like
ErrorCodeResolvingAspect.aspectOf() in my java source - no AJ source
involved at this point - since aspectOf is a static method that aj compiler
generates for me and ErrorCodeResolvingAspect is valid bytecode.
In Java editor I see a bunch of markers saying that the
editor does not know anything about class ErrorCodeResolvingAspect. If I
run the code that contains the code that is marked as invalid by Java
editor it runs fine. Markers are not cleared even after I run the code.
So the java compiler knows about the class that has no Java source
behind it, the launcher finds it also but Java editor does not.
When I open the same java file with AJ editor (which is possible since
java source is a subset of aj source), the only thing that is different
about AJ editor is that it does not mark the statements with error markers.
The code assist does not work in aj either, so is auto import of classes.
> The expectation is that there will be a builder that's
> hooked up to produce these results for all the various tools
> that produce build results. So at the beginning of
the problem it seems that the builder has no way of notifying javamodel of
newly
produced classes that have no java source behind it. or maybe there is? I
would
love to know how.
I am pretty sure it is possible since java editor seems to be able to
extract
stuff from .jar files about its contained classes.
> the build, the bin directory can be flushed and then the
> builders will populate it during the build. I'm pretty sure
> AJDT does this too. I suspect that your reasoning about the
> error markers implying AJDT has this problem too is
I meant that java editor has problems while dealing with classes produced by
AJDT.
> source code is not valid Java syntax and needs to be interpreted by an
once again I did not try to view aj file with java editor, just java source
that uses classes
produced by AspectJ
> How about compiling to a folder other than bin and putting
> that folder on the classpath?
I tried that but that does not work either. I compiled all of my groovy
files in .groovy dir and placed
that directory on the classpath. Frankly, I do not see how that is different
from what is done now.
Thanks,
Alex.
|
|
| |
| Re: JDT is not aware of classes compiled by another compiler [message #235098 is a reply to message #235083] |
Thu, 24 August 2006 10:12 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------060705000207030008050800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Alex,
Well, I'll have to leave it to the experts to address (they seem quiet
these days), because I'm certainly no expert and I'm out of theories and
suggestions. Haven't other groovy users encountered this and solved
it? Maybe folks typically keep the groovy stuff in a separate project
and that way works?
Alex Shneyderman wrote:
> Ed, I think we are talking apples and oranges here,
> or maybe I was not clear in my explanations.
>
> Here is a second try:
>
> I have an ApsectJ advice that looks like this:
> public aspect ErrorCodeResolvingAspect {
> protected pointcut errorResolvableJoinPoints () ..... ;
> after () throwing (Throwable e) : errorResolvableJoinPoints () {
> ....
> }
> }
>
> assuming that the aspect above is syntactically correct AJDT will
> produce .class file in hte output directory. If I create .java file
> and open it with Java editor, I can say something like
> ErrorCodeResolvingAspect.aspectOf() in my java source - no AJ source
> involved at this point - since aspectOf is a static method that aj compiler
> generates for me and ErrorCodeResolvingAspect is valid bytecode.
> In Java editor I see a bunch of markers saying that the
> editor does not know anything about class ErrorCodeResolvingAspect. If I
> run the code that contains the code that is marked as invalid by Java
> editor it runs fine. Markers are not cleared even after I run the code.
> So the java compiler knows about the class that has no Java source
> behind it, the launcher finds it also but Java editor does not.
>
> When I open the same java file with AJ editor (which is possible since
> java source is a subset of aj source), the only thing that is different
> about AJ editor is that it does not mark the statements with error markers.
> The code assist does not work in aj either, so is auto import of classes.
>
>
>> The expectation is that there will be a builder that's
>> hooked up to produce these results for all the various tools
>> that produce build results. So at the beginning of
>>
>
> the problem it seems that the builder has no way of notifying javamodel of
> newly
> produced classes that have no java source behind it. or maybe there is? I
> would
> love to know how.
>
> I am pretty sure it is possible since java editor seems to be able to
> extract
> stuff from .jar files about its contained classes.
>
>
>> the build, the bin directory can be flushed and then the
>> builders will populate it during the build. I'm pretty sure
>> AJDT does this too. I suspect that your reasoning about the
>> error markers implying AJDT has this problem too is
>>
>
> I meant that java editor has problems while dealing with classes produced by
> AJDT.
>
>
>> source code is not valid Java syntax and needs to be interpreted by an
>>
>
> once again I did not try to view aj file with java editor, just java source
> that uses classes
> produced by AspectJ
>
>
>> How about compiling to a folder other than bin and putting
>> that folder on the classpath?
>>
>
> I tried that but that does not work either. I compiled all of my groovy
> files in .groovy dir and placed
> that directory on the classpath. Frankly, I do not see how that is different
> from what is done now.
>
> Thanks,
> Alex.
>
>
>
--------------060705000207030008050800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Alex,<br>
<br>
Well, I'll have to leave it to the experts to address (they seem quiet
these days), because I'm certainly no expert and I'm out of theories
and suggestions. Haven't other groovy users encountered this and
solved it? Maybe folks typically keep the groovy stuff in a separate
project and that way works?<br>
<br>
<br>
Alex Shneyderman wrote:
<blockquote cite="midecka3h$r0q$1@utils.eclipse.org" type="cite">
<pre wrap="">Ed, I think we are talking apples and oranges here,
or maybe I was not clear in my explanations.
Here is a second try:
I have an ApsectJ advice that looks like this:
public aspect ErrorCodeResolvingAspect {
protected pointcut errorResolvableJoinPoints () ..... ;
after () throwing (Throwable e) : errorResolvableJoinPoints () {
....
}
}
assuming that the aspect above is syntactically correct AJDT will
produce .class file in hte output directory. If I create .java file
and open it with Java editor, I can say something like
ErrorCodeResolvingAspect.aspectOf() in my java source - no AJ source
involved at this point - since aspectOf is a static method that aj compiler
generates for me and ErrorCodeResolvingAspect is valid bytecode.
In Java editor I see a bunch of markers saying that the
editor does not know anything about class ErrorCodeResolvingAspect. If I
run the code that contains the code that is marked as invalid by Java
editor it runs fine. Markers are not cleared even after I run the code.
So the java compiler knows about the class that has no Java source
behind it, the launcher finds it also but Java editor does not.
When I open the same java file with AJ editor (which is possible since
java source is a subset of aj source), the only thing that is different
about AJ editor is that it does not mark the statements with error markers.
The code assist does not work in aj either, so is auto import of classes.
</pre>
<blockquote type="cite">
<pre wrap="">The expectation is that there will be a builder that's
hooked up to produce these results for all the various tools
that produce build results. So at the beginning of
</pre>
</blockquote>
<pre wrap=""><!---->
the problem it seems that the builder has no way of notifying javamodel of
newly
produced classes that have no java source behind it. or maybe there is? I
would
love to know how.
I am pretty sure it is possible since java editor seems to be able to
extract
stuff from .jar files about its contained classes.
</pre>
<blockquote type="cite">
<pre wrap="">the build, the bin directory can be flushed and then the
builders will populate it during the build. I'm pretty sure
AJDT does this too. I suspect that your reasoning about the
error markers implying AJDT has this problem too is
</pre>
</blockquote>
<pre wrap=""><!---->
I meant that java editor has problems while dealing with classes produced by
AJDT.
</pre>
<blockquote type="cite">
<pre wrap="">source code is not valid Java syntax and needs to be interpreted by an
</pre>
</blockquote>
<pre wrap=""><!---->
once again I did not try to view aj file with java editor, just java source
that uses classes
produced by AspectJ
</pre>
<blockquote type="cite">
<pre wrap="">How about compiling to a folder other than bin and putting
that folder on the classpath?
</pre>
</blockquote>
<pre wrap=""><!---->
I tried that but that does not work either. I compiled all of my groovy
files in .groovy dir and placed
that directory on the classpath. Frankly, I do not see how that is different
from what is done now.
Thanks,
Alex.
</pre>
</blockquote>
<br>
</body>
</html>
--------------060705000207030008050800--
|
|
| |
| Re: JDT is not aware of classes compiled by another compiler [message #235205 is a reply to message #235168] |
Sat, 26 August 2006 17:55 |
| Eclipse User |
|
|
|
Alex Shneyderman a écrit :
> While it is a good progres, the solution seems to be one-sided.
> Any more ideas?
I will suggest something else.
Why don't you add a class folder on the classpath that would be the
output of the first builder. At the end of the first builder, you should
call a refresh on this class folder and this would make the .class
files from the first builder visible for the second builder.
I haven't tried, but you might want to give it a try.
--
Olivier
|
|
|
Goto Forum:
Current Time: Sun Jun 08 12:19:19 EDT 2025
Powered by FUDForum. Page generated in 0.04985 seconds |
Home