buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harish Krishnaswamy" <harishksw...@gmail.com>
Subject Re: Is there an easier way to use the Eclipse Java compiler
Date Tue, 03 Jun 2008 17:06:47 GMT
Yes, there were other times when I was able to get by with casts (defeats
the purpose of generifying though), but this particular example just has no
workaround for the Sun compiler.

-Harish

On Tue, Jun 3, 2008 at 12:54 PM, Daniel Spiewak <djspiewak@gmail.com> wrote:

> I too have faced similar issues with Sun's compiler, usually relating to
> inferred bounds.  The workaround is often to split statements into parts, or
> even use casting to get around the trouble spot.  It's nasty, but until Sun
> does something about it, we're stuck.
>
> Daniel
>
>
> Harish Krishnaswamy wrote:
>
>> Thanks for the pointers, I will go ahead create the extension and publish
>> it.
>>
>> As for the compiler issues, this is the second time I am faced with the
>> Sun
>> compiler issues wrt generics type inferences where the Eclipse compiler
>> can
>> infer the type correctly but the Sun compiler throws compile errors.
>> Here's
>> a quick example that should compile just fine.
>>
>> public interface ValueChangeListener<M extends ValueModel<?>>
>> {
>>     void valueChanged(M model);
>> }
>>
>> public class ValueModel<V>
>> {
>>     private Set<ValueChangeListener<? extends ValueModel<V>>>
>> _changeListeners;
>>
>>     public void registerChangeListener(ValueChangeListener<? extends
>> ValueModel<V>>  listener)
>>     {
>>         if (_changeListeners == null)
>>             _changeListeners = new HashSet<ValueChangeListener<? extends
>> ValueModel<V>>>();
>>
>>         _changeListeners.add(listener);
>>     }
>>
>>     public void removeChangeListener(ValueChangeListener<? extends
>> ValueModel<V>>  listener)
>>     {
>>         if (_changeListeners == null)
>>             return;
>>
>>         _changeListeners.remove(listener);
>>     }
>> }
>>
>> public abstract class BaseView<M extends ValueModel<?>>  implements
>> ValueChangeListener<M>
>> {
>>     private M _model;
>>
>>     public void setModel(M model)
>>     {
>>         if (_model != null)
>>             _model.removeChangeListener(this);
>>
>>         _model = model;
>>
>>         if (_model != null)
>>         {
>>             _model.registerChangeListener(this);
>>             valueChanged(_model);
>>         }
>>     }
>> }
>>
>> -Harish
>>
>> On Tue, Jun 3, 2008 at 11:46 AM, Alex Boisvert<boisvert@intalio.com>
>>  wrote:
>>
>>
>>
>>> On Tue, Jun 3, 2008 at 8:15 AM, Harish Krishnaswamy<
>>> harishkswamy@gmail.com>
>>> wrote:
>>>
>>>
>>>
>>>> As most of you know, the Sun Java compiler is quite buggy when it comes
>>>>
>>>>
>>> to
>>>
>>>
>>>> generics where the Eclipse compiler does a much better job; given that,
>>>>
>>>>
>>> is
>>>
>>>
>>>> there an easy way to substitute the Eclipse compiler? I have had to
>>>>
>>>>
>>> change
>>>
>>>
>>>> the Buildr::Compiler.compile method to get it to work, wondering if
>>>>
>>>>
>>> there's
>>>
>>>
>>>> a way to configurable it.
>>>>
>>>>
>>> I haven't heard about the generics bugs you're referring to; do you have
>>> any
>>> reference pointers on that?
>>>
>>> You can register your own compiler plugin with,
>>>
>>> Buildr::Compiler<<  YourExtensionModule::Compiler::Eclipse
>>>
>>> at the top of your buildfile and by doing,
>>>
>>> compile.using :eclipse
>>> test.compile.using :eclipse
>>>
>>> in your project to force using this compiler.    If you've already
>>> patched
>>> the Javac class from Builder, it's just a question of extracting it and
>>> renaming it.   You could also make it an extension (
>>> http://incubator.apache.org/buildr/extending.html#creating_extensions)
>>> to
>>> avoid the boilerplate.    And if you do all of this, it would be great if
>>> you could publish it so others can use your extension! :)
>>>
>>> alex
>>>
>>>
>>>
>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message