I don't have a lot of experience with Jikes, but it appears
to be written in C++. In order for us to use it as an
available compiler in DrJava, we'd need to write an
interface to it to receive all the compiler errors, and
without a Java API to talk to, that could be very difficult.
I'll try to look into it, though-- feel free to let me know
if you have any suggestions how to go at it. (If you want
to see what we've been doing with compilers, take a look at
the edu.rice.cs.drjava.model.compiler package...)
Anyway, you're right that it takes a long time to start up
javac, but you should only have that overhead on the first
compile-- it tends to run faster for me on successive compiles.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've put together a quick Jikes adaptor (although I still can't
compile the application source -- do I see generics in
there? -- so it isn't tested). It's ugly code but it might give
you a feel for what it would take to add jikes support.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah-- yeah, I guess we could just exec it and parse the
result... Not exactly an ideal approach, but we might be
able to add support for it. I'll bring it up at our next
meeting.
Anyway, we are using generics in the source, and compiling
with Sun's JSR-14 (version 1.0) prototype compiler. It ties
in closely with the research we're doing on NextGen, another
Java compiler with generics. If you check out from CVS,
there should be instructions on how to set up Ant for
compiling in the src/edu/rice/cs/README file. (Make sure
all the jars in our lib directory are on your classpath.)
And thanks for the sample code-- we appreciate your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the main problems here are going to be maintainence
and support issues across platforms. Parsing output is a
fragile technique (especially between versions), and even
just finding and running the executable can run into
problems on different platforms. It is entirely possible to
support this, but for the time being, it's going to be low
priority-- we can't focus a lot of effort on testing and
maintaining this at the moment.
If you want to continue work on your own adaptor but are
still having troubles with setting up the environment, I'd
be happy to help-- just submit a support request. Sorry we
aren't able to look at this sooner...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm going to try once more to get the source working before
I submit a support request, but I do intend to implement
jikes support. I realize that this project is using XP (which
I fully support) and that you want stable, testable code.
While I don't expect very many problems with the Jikes
error message format (it's in their best interest to keep it
compatable, and I believe there is some sort of logic to the
Emacs format), certainly the location of executables would
be an issue. While Netbeans parses the output, I saw that
Ant just seems to print the output -- simple, yet effective
for batch purposes.
Anyway, if I can compile the source, I'll get something
working for my own use. I might bring up this topic again if
my code seems robust.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there a way to specify extra compiler interfaces in the
drjava configuration file? I could just compile against the
binaries and everything would be groovy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At the moment, there isn't support for specifying extra
compiler interfaces in the config file, but it turns out
that it's quite simple to add. I'm not sure whether we want
it in the main build right now (since it's not something
most users will know what to do with), but I can easily make
a custom build available for you.
When using this jar, you can specify the class name of any
valid CompilerInterface to use in your .drjava config file
using the "user.compiler" option. For example:
As long as that class is on your classpath when starting
DrJava, it should work fine. Note that this means you can't
run the jar with "java -jar", but rather with "java -cp".
For example:
Let me know if that works for you or not. In the future, we
might add it to the main build in some set of "developer
options"... Hope that helps!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks a lot. I managed to get everything working
(although I noticed the CompilerInterface has been evolving
quicker than the online javadocs). It's always great to find
a project where the developers are active and helpful.
Dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=429731
I don't have a lot of experience with Jikes, but it appears
to be written in C++. In order for us to use it as an
available compiler in DrJava, we'd need to write an
interface to it to receive all the compiler errors, and
without a Java API to talk to, that could be very difficult.
I'll try to look into it, though-- feel free to let me know
if you have any suggestions how to go at it. (If you want
to see what we've been doing with compilers, take a look at
the edu.rice.cs.drjava.model.compiler package...)
Anyway, you're right that it takes a long time to start up
javac, but you should only have that overhead on the first
compile-- it tends to run faster for me on successive compiles.
Quick implementation -- untested
Logged In: YES
user_id=182514
I've put together a quick Jikes adaptor (although I still can't
compile the application source -- do I see generics in
there? -- so it isn't tested). It's ugly code but it might give
you a feel for what it would take to add jikes support.
Logged In: YES
user_id=429731
Ah-- yeah, I guess we could just exec it and parse the
result... Not exactly an ideal approach, but we might be
able to add support for it. I'll bring it up at our next
meeting.
Anyway, we are using generics in the source, and compiling
with Sun's JSR-14 (version 1.0) prototype compiler. It ties
in closely with the research we're doing on NextGen, another
Java compiler with generics. If you check out from CVS,
there should be instructions on how to set up Ant for
compiling in the src/edu/rice/cs/README file. (Make sure
all the jars in our lib directory are on your classpath.)
And thanks for the sample code-- we appreciate your help.
Logged In: YES
user_id=429731
I think the main problems here are going to be maintainence
and support issues across platforms. Parsing output is a
fragile technique (especially between versions), and even
just finding and running the executable can run into
problems on different platforms. It is entirely possible to
support this, but for the time being, it's going to be low
priority-- we can't focus a lot of effort on testing and
maintaining this at the moment.
If you want to continue work on your own adaptor but are
still having troubles with setting up the environment, I'd
be happy to help-- just submit a support request. Sorry we
aren't able to look at this sooner...
Logged In: YES
user_id=182514
I'm going to try once more to get the source working before
I submit a support request, but I do intend to implement
jikes support. I realize that this project is using XP (which
I fully support) and that you want stable, testable code.
While I don't expect very many problems with the Jikes
error message format (it's in their best interest to keep it
compatable, and I believe there is some sort of logic to the
Emacs format), certainly the location of executables would
be an issue. While Netbeans parses the output, I saw that
Ant just seems to print the output -- simple, yet effective
for batch purposes.
Anyway, if I can compile the source, I'll get something
working for my own use. I might bring up this topic again if
my code seems robust.
Logged In: YES
user_id=182514
Is there a way to specify extra compiler interfaces in the
drjava configuration file? I could just compile against the
binaries and everything would be groovy.
Logged In: YES
user_id=429731
At the moment, there isn't support for specifying extra
compiler interfaces in the config file, but it turns out
that it's quite simple to add. I'm not sure whether we want
it in the main build right now (since it's not something
most users will know what to do with), but I can easily make
a custom build available for you.
For the time being, I've uploaded a Jar with support for
this to our web site:
http://drjava.sf.net/drjava-customcompiler.jar
When using this jar, you can specify the class name of any
valid CompilerInterface to use in your .drjava config file
using the "user.compiler" option. For example:
user.compiler =
edu.rice.cs.drjava.model.compiler.JSR14FromSetLocation
(all on one line)
As long as that class is on your classpath when starting
DrJava, it should work fine. Note that this means you can't
run the jar with "java -jar", but rather with "java -cp".
For example:
java -cp drjava-customcompiler.jar:/home/mycode
edu.rice.cs.drjava.DrJava
Let me know if that works for you or not. In the future, we
might add it to the main build in some set of "developer
options"... Hope that helps!
Logged In: YES
user_id=182514
Thanks a lot. I managed to get everything working
(although I noticed the CompilerInterface has been evolving
quicker than the online javadocs). It's always great to find
a project where the developers are active and helpful.
Dave