drjava-hackers

[DrJava] ack re jsr14 1.2

[Brian S. <bs...@bs...>]

I poked a lot and think I've got most of what I need to do the jsr14
v1.2/javac 1.4.1 compiler adapter. There's just one huge problem: There is
a somewhat unresolvable build dependency problem! Here's the catch: To
compile the old compiler adapter, we need jsr14 1.0 (or javac < 1.4.1) in
the classpath. But to compile the newer compiler adapter, we need jsr14
1.2 in the classpath. Yikes!

So, I can see a couple of ways out of this situation:

1) Set up a framework like I used to talk about for having sub-projects
that were compilable only sometimes. This same framework would apply to
problems like this, as well as to OS-specific code. The idea is that the
separate subprojects would be broken off into their own directories, and
that on commit the class files would be committed as well as the source
files. Then, the main project build system would take the committed class
files and use them to compile. Thus, the main build would not need to
satisfy the weird build-time dependencies of the various sub-modules.

or, for just this problem:

2) Force all developers to have both JSR14 v1.0 and JSR14 v1.2 in their
lib directory. Then, compile each's compiler adapter separately as a part
of the compilation process, adding the relevant compiler to the classpath
just for that compilation. I think this should work reasonably.

What do you guys think? As I said, the actual issue of making a JSR14 v1.2
compiler adapter is not really that hard, but it brings up this tough
issue. :)

BTW, one side tiny problem that's easy to fix is the fact that if you try
to compile DrJava via Ant using JSR14 v1.2, it doesn't work. The reason is
that JSR14 v1.2 seems to default to having generics off unless you pass
"-gj" on the compiler command line. Anyhow, this can be done trivially in
the build-common.xml task by putting a <compilerarg value="-gj" /> inside
the <javac>. This will keep the build script working on JSR14 1.0 as
well, but the one small catch is that it requires Ant 1.5 to execute. No
big deal I guess.

Anyway ... .

-brian

PS: As you can see, I'm still playing a bit with DrJava in my spare time.
:) Another side project I'm beginning to investigate is creating a REPL
module to put into Oracle's IDE JDeveloper. JDeveloper, by the way, is
actually not bad (and they're not paying me to say this!). I mean, it
helps a lot for making big goofy apps like Web applications, but it's also
got some nice stuff like good code completion, etc. It is, however, a
memory hog and pretty slow on my home P2/350. Also, the new version that's
not out yet (9.0.3) is much better.

Anyhow ... :)

Re: [DrJava] ack re jsr14 1.2

[Theo Y. <ot...@ri...>]

What ab

On Sun, 11 Aug 2002, Brian Stoler wrote:

> Date: Sun, 11 Aug 2002 20:29:37 -0700 (PDT)
> From: Brian Stoler <bs...@bs...>
> To: drj...@li...
> Subject: [DrJava] ack re jsr14 1.2
>
> I poked a lot and think I've got most of what I need to do the jsr14
> v1.2/javac 1.4.1 compiler adapter. There's just one huge problem: There is
> a somewhat unresolvable build dependency problem! Here's the catch: To
> compile the old compiler adapter, we need jsr14 1.0 (or javac < 1.4.1) in
> the classpath. But to compile the newer compiler adapter, we need jsr14
> 1.2 in the classpath. Yikes!
>
> So, I can see a couple of ways out of this situation:
>
> 1) Set up a framework like I used to talk about for having sub-projects
> that were compilable only sometimes. This same framework would apply to
> problems like this, as well as to OS-specific code. The idea is that the
> separate subprojects would be broken off into their own directories, and
> that on commit the class files would be committed as well as the source
> files. Then, the main project build system would take the committed class
> files and use them to compile. Thus, the main build would not need to
> satisfy the weird build-time dependencies of the various sub-modules.
>
> or, for just this problem:
>
> 2) Force all developers to have both JSR14 v1.0 and JSR14 v1.2 in their
> lib directory. Then, compile each's compiler adapter separately as a part
> of the compilation process, adding the relevant compiler to the classpath
> just for that compilation. I think this should work reasonably.
>
> What do you guys think? As I said, the actual issue of making a JSR14 v1.2
> compiler adapter is not really that hard, but it brings up this tough
> issue. :)
>
> BTW, one side tiny problem that's easy to fix is the fact that if you try
> to compile DrJava via Ant using JSR14 v1.2, it doesn't work. The reason is
> that JSR14 v1.2 seems to default to having generics off unless you pass
> "-gj" on the compiler command line. Anyhow, this can be done trivially in
> the build-common.xml task by putting a <compilerarg value="-gj" /> inside
> the <javac>. This will keep the build script working on JSR14 1.0 as
> well, but the one small catch is that it requires Ant 1.5 to execute. No
> big deal I guess.
>
> Anyway ... .
>
> -brian
>
> PS: As you can see, I'm still playing a bit with DrJava in my spare time.
> :) Another side project I'm beginning to investigate is creating a REPL
> module to put into Oracle's IDE JDeveloper. JDeveloper, by the way, is
> actually not bad (and they're not paying me to say this!). I mean, it
> helps a lot for making big goofy apps like Web applications, but it's also
> got some nice stuff like good code completion, etc. It is, however, a
> memory hog and pretty slow on my home P2/350. Also, the new version that's
> not out yet (9.0.3) is much better.
>
> Anyhow ... :)
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>

Re: [DrJava] ack re jsr14 1.2

[Charles R. <cr...@ri...>]

Rather than compiling against the JSR-14 v1.0/v1.2 compilers directly, 
couldn't we just invoke their compile, etc, methods using reflection? 
Then we don't have to worry about this if the compiler interface changes 
yet again-- we just "invoke" a different method...

I'm not entirely against the other method (some classes only compile in 
some environments), but I'd like to allow everyone to be able to compile 
everything as long as we can, if possible...

Of course, if reflection isn't an option, I think we'd have to do that 
anyway-- JSR-14 v1.0 isn't available anymore, so only people who have an 
old copy could compile DrJava if we went the route of requiring both. 
(And we've already gotten complaints from people outside Rice who want 
to compile.  Rightfully so...)

Charlie

Re: [DrJava] ack re jsr14 1.2

[Brian S. <bs...@bs...>]

> Rather than compiling against the JSR-14 v1.0/v1.2 compilers directly,
> couldn't we just invoke their compile, etc, methods using reflection?

Nope, don't think so. We have to subclass one of their classes (Log) to be
able to catch the errors, and you can't synthesize that reflectively. (I
can't think of a way anyhow!)

> Of course, if reflection isn't an option, I think we'd have to do that
> anyway-- JSR-14 v1.0 isn't available anymore, so only people who have an
> old copy could compile DrJava if we went the route of requiring both.
> (And we've already gotten complaints from people outside Rice who want
> to compile.  Rightfully so...)

Well, you could just technically break the license from Sun and just check
both versions into CVS in the lib directory. Sure, Sun says you're not
allowed to redistribute, but I doubt anyone would notice, and anyhow, it's
only for other developers to be able to compile against it.

Actually, I wonder if you couldn't just use some sort of stubs. Hmm ...
:). Wouldn't it be cool if there was a program to take a set of class
files and create dummy stubs of just their public/protected interfaces?
This would give you a freely redistributable set of classes to satisfy a
build-time dependency. Wouldn't even be so hard to create this. :)

-brian

Re: [DrJava] ack re jsr14 1.2

[Theo Y. <ot...@ri...>]

Sorry about the previous truncated post.

I was thinking something similar along Charlie's lines, but in a subtlely
different way (and subsequently had proposed this design to help drjava register
Apple-specific handlers, so we can build on non-apple machines).

So... JSR14 (whichever version) wants us to subclass a class Foo, in their
codebase...

What if we create a dummy subclass (say, AFoo) that delegates to our proprietary
interface, that has identical methods (that way we could always swap out our
implementation).  Let's just use IFoo, for hypothetical reasons.

Thus we have an AFoo class with no logic, and we can compile it *once* with the
proprietary JSR14 classes, and zip it up into our lib directory, never to be
touched again.

In the meanwhile, we write and test whatever necessary IFoos that we wish... and
we can instantiate AFoo (a full-fledged subclass of Foo) with reflection.

So... we follow their rules and subclass -- but we don't dynamically load our
"Foo adapter" to allow us to cooperate with their silly rules.

Apple's event handlers also want us to subclass/implement Apple's proprietary
event interfaces, so I had thought maybe this mechanism would enable us to do
that without requiring the original interfaces to be on the classpath.

However, this does pose an interesting dilemma still for testing.  We would
still need to have both versions of JSR14 available if we were to write
testcases to handle each situation, no?  (Eric?)  What do we presently do to
ensure that platform specific bugs don't propogate?

Just some thoughts before bed...

theo:)

p.s. I had sent that previous message because it's evil how close Ctrl-X and
Ctrl-C are on the keyboard (Pine shortcuts).  I had originally meant to cancel
the message and draft one later... but you guys saw what happenned :-D

On Sun, 11 Aug 2002, Charles Reis wrote:

> Date: Sun, 11 Aug 2002 22:49:33 -0500
> From: Charles Reis <cr...@ri...>
> To: Brian Stoler <bs...@bs...>
> Cc: drj...@li...
> Subject: Re: [DrJava] ack re jsr14 1.2
>
> Rather than compiling against the JSR-14 v1.0/v1.2 compilers directly,
> couldn't we just invoke their compile, etc, methods using reflection?
> Then we don't have to worry about this if the compiler interface changes
> yet again-- we just "invoke" a different method...
>
> I'm not entirely against the other method (some classes only compile in
> some environments), but I'd like to allow everyone to be able to compile
> everything as long as we can, if possible...
>
> Of course, if reflection isn't an option, I think we'd have to do that
> anyway-- JSR-14 v1.0 isn't available anymore, so only people who have an
> old copy could compile DrJava if we went the route of requiring both.
> (And we've already gotten complaints from people outside Rice who want
> to compile.  Rightfully so...)
>
> Charlie
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>

Re: [DrJava] ack re jsr14 1.2

[Eric E. A. <eri...@ma...>]

> However, this does pose an interesting dilemma still for testing.  We 
> would
> still need to have both versions of JSR14 available if we were to write
> testcases to handle each situation, no?  (Eric?)  What do we presently 
> do to
> ensure that platform specific bugs don't propogate?

My understanding is that we would then have two implementations of IFoo 
(one for each version of JSR14), and each implementation would be a 
simple adapter, right? In that case, the methods in the adapters would 
be simple forwarding methods, and they should never change, so I think 
it's okay if we don't include unit tests for them (we should be able to 
verify when they're written that they can't possibly break). Then we can 
test the rest of the code with just one of the two adapters, or even a 
mock object adapter if we want to test some of the client code in 
isolation. Of course, the mock object would not help to test the logic 
for reflectively instantiating an adapter...

-- Eric


>
> Just some thoughts before bed...
>
> theo:)
>
> p.s. I had sent that previous message because it's evil how close 
> Ctrl-X and
> Ctrl-C are on the keyboard (Pine shortcuts).  I had originally meant to 
> cancel
> the message and draft one later... but you guys saw what happenned :-D
>
> On Sun, 11 Aug 2002, Charles Reis wrote:
>
>> Date: Sun, 11 Aug 2002 22:49:33 -0500
>> From: Charles Reis <cr...@ri...>
>> To: Brian Stoler <bs...@bs...>
>> Cc: drj...@li...
>> Subject: Re: [DrJava] ack re jsr14 1.2
>>
>> Rather than compiling against the JSR-14 v1.0/v1.2 compilers directly,
>> couldn't we just invoke their compile, etc, methods using reflection?
>> Then we don't have to worry about this if the compiler interface 
>> changes
>> yet again-- we just "invoke" a different method...
>>
>> I'm not entirely against the other method (some classes only compile in
>> some environments), but I'd like to allow everyone to be able to 
>> compile
>> everything as long as we can, if possible...
>>
>> Of course, if reflection isn't an option, I think we'd have to do that
>> anyway-- JSR-14 v1.0 isn't available anymore, so only people who have 
>> an
>> old copy could compile DrJava if we went the route of requiring both.
>> (And we've already gotten complaints from people outside Rice who want
>> to compile.  Rightfully so...)
>>
>> Charlie
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> drjava-hackers mailing list
>> drj...@li...
>> https://lists.sourceforge.net/lists/listinfo/drjava-hackers
>>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers

Re: [DrJava] ack re jsr14 1.2

[Eric E. A. <eri...@ma...>]

Does JDeveloper handle generics? Any chance of adding support for 
them? ;-)

-- Eric

On Sunday, August 11, 2002, at 10:29  PM, Brian Stoler wrote:

> I poked a lot and think I've got most of what I need to do the jsr14
> v1.2/javac 1.4.1 compiler adapter. There's just one huge problem: There 
> is
> a somewhat unresolvable build dependency problem! Here's the catch: To
> compile the old compiler adapter, we need jsr14 1.0 (or javac < 1.4.1) 
> in
> the classpath. But to compile the newer compiler adapter, we need jsr14
> 1.2 in the classpath. Yikes!
>
> So, I can see a couple of ways out of this situation:
>
> 1) Set up a framework like I used to talk about for having sub-projects
> that were compilable only sometimes. This same framework would apply to
> problems like this, as well as to OS-specific code. The idea is that the
> separate subprojects would be broken off into their own directories, and
> that on commit the class files would be committed as well as the source
> files. Then, the main project build system would take the committed 
> class
> files and use them to compile. Thus, the main build would not need to
> satisfy the weird build-time dependencies of the various sub-modules.
>
> or, for just this problem:
>
> 2) Force all developers to have both JSR14 v1.0 and JSR14 v1.2 in their
> lib directory. Then, compile each's compiler adapter separately as a 
> part
> of the compilation process, adding the relevant compiler to the 
> classpath
> just for that compilation. I think this should work reasonably.
>
> What do you guys think? As I said, the actual issue of making a JSR14 
> v1.2
> compiler adapter is not really that hard, but it brings up this tough
> issue. :)
>
> BTW, one side tiny problem that's easy to fix is the fact that if you 
> try
> to compile DrJava via Ant using JSR14 v1.2, it doesn't work. The reason 
> is
> that JSR14 v1.2 seems to default to having generics off unless you pass
> "-gj" on the compiler command line. Anyhow, this can be done trivially 
> in
> the build-common.xml task by putting a <compilerarg value="-gj" /> 
> inside
> the <javac>. This will keep the build script working on JSR14 1.0 as
> well, but the one small catch is that it requires Ant 1.5 to execute. No
> big deal I guess.
>
> Anyway ... .
>
> -brian
>
> PS: As you can see, I'm still playing a bit with DrJava in my spare 
> time.
> :) Another side project I'm beginning to investigate is creating a REPL
> module to put into Oracle's IDE JDeveloper. JDeveloper, by the way, is
> actually not bad (and they're not paying me to say this!). I mean, it
> helps a lot for making big goofy apps like Web applications, but it's 
> also
> got some nice stuff like good code completion, etc. It is, however, a
> memory hog and pretty slow on my home P2/350. Also, the new version 
> that's
> not out yet (9.0.3) is much better.
>
> Anyhow ... :)
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> drjava-hackers mailing list
> drj...@li...
> https://lists.sourceforge.net/lists/listinfo/drjava-hackers

Re: [DrJava] ack re jsr14 1.2

[Brian S. <bs...@bs...>]

> Does JDeveloper handle generics? Any chance of adding support for
> them? ;-)

Right now? Presumably no, or not really at least. I bet you could get
JDeveloper to invoke jsr14 for compilation, but syntax highlighting/code
completion/etc would be all messed up. When I get a chance I'll poke
around and see how hard it would be to hack a mode to support it. (I've
been poking at the source lately investigating my REPL addin.) I'll also
ask the JDev team (of which I am not a member, I'm in a group that makes
some pieces they use/distribute) if they have any plans re generics.

Of course, if they ever become part of the standard SDK I imagine they'd
have support.

-brian