Re: Generics

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Generics

adepue
Response at end...


On Sunday 24 July 2005 08:38 pm, Jesse Wilson wrote:

> Hey guys ---
>
> I thought I might as well add my two cents to the conversation:
>
> 1. Compatibility is king. This means that since we want to continue
> to support Java 1.4, we should do it with using tools that are fully
> supported.
> I think that developers who are building 1.4 projects will be turned
> off of Glazed Lists if we use 5.0 syntax. This sucks, but I think
> it's realistic.
> It's risky enough adopting an open source project, and depending on
> an open source project that uses VM-version voodoo is just craziness.
> Going to Java 5.0 syntax impacts our Javadocs and will surely scare
> away potential users!
>
> 2. Java 5.0 syntax is awesome. We need to support generics as quickly
> as possible! Generics are much more pleasant to develop with. They
> allow us to avoid ambiguities about what is inside Collection X. When we
> decide to change a type, say from List<String> to List<CharSequence>,
> generics catch a bunch of ClassCastExceptions that would otherwise
> make their way to the end user!
>
> So we have a clear technical problem. No perfect solution exists:
> A: Retroweaver. This requires us to include retroweaver.jar, which
> includes
>      their replacement for Iterable. Yuck.
> B: -target jsr14. Who knows how well this works? Its not supported by
>      Sun and it's surely not guaranteed to exist in future releases
> of Java.
> C: Jesse's funky source tree munging idea. This is completely unproven,
>      it may take a long time to develop and it requires an external
> tool.
>
> It looks like we're hosed.
>
> Purely as a technical exercise, let me explain Imperfect Solution C.
> Premise: Java 5 source can be mechanically converted into equivalent
> Java 1.4 source
> Example:
>      List<String> myBuddies = new ArrayList<String>();
>      myBuddies.add("Hani");
>      myBuddies.add("Rob");
>      for(String buddy : myBuddies) {
>          System.out.println("Hello " + buddy + ", do you have any
> pringles?");
>      }
> ... can be mechanically converted into the following, replacing <X>
> with casts to (X):
>      List<Object> myBuddies = new ArrayList<Object>();
>      myBuddies.add("Hani");
>      myBuddies.add("Rob");
>      for(Object buddy : myBuddies) {
>          String buddy_AS_java_lang_String = (String)buddy;
>          System.out.println("Hello " + buddy + ", do you have any
> cheetos?");
>      }
> ... can be mechanically converted into the following, replacing
> (Object x : Iterable) with java.util.Iterators:
>      List<Object> myBuddies = new ArrayList<Object>();
>      myBuddies.add("Hani");
>      myBuddies.add("Rob");
>      for(Iterator buddy_ITERATOR = myBuddies.iterator();
> buddy_ITERATOR.hasNext(); ) {
>          Object buddy = buddy_ITERATOR.next();
>          String buddy_AS_java_lang_String = (String)buddy;
>          System.out.println("Hello " + buddy + ", do you have any
> doritos?");
>      }
>
> To implement this, a person would need a fairly decent understanding
> of Javacc, which is a really neat tool, and about 16-40 hours of
> coding time.
> Such a tool would work using a best-effort approach, and flame out if
> it ran into some generics code that it couldn't understand. We don't
> need
> to support all of Java 5.0 stuff, but we would need to support what
> we used.
>
> Of course, this idea isn't original. I am particularly inspired by a
> Joel on software
> article, where he discusses their ASP to PHP compiler:
> http://www.joelonsoftware.com/articles/FogBugzIII.html
>
> Anyway, I'm not dying to implement this solution, but I do think it's
> pretty cool.
> For now, I vote to stay with status quo and not go to Generics. We're
> going
> to 1.0 soon, and then we can make some generics decisions.

Jesse,
  I see a lot of projects (both open source and non open source) wanting to
move to generics (and some other 1.5 features), but being unable to move for
these very reasons.  As a side rant, it boggles my mind why Sun tried so hard
to make generic bytecode backward compatible with older JVMs (erasures, no
runtime generic information, etc), and then provide no way to actually write
code with generics and compile it for use on older JVMs.. grr.. if they
weren't going to make it really backward compatible, then they should have at
least given us a full generics implementation complete with runtime
introspection.
  Anyway, your option C is enticing, if someone could actually pull it off (so
that it works well).  If there were an open source project for such a thing,
I could see many other projects utilizing it in their builds to provide 1.4
compatible binaries while enjoying some of the new 1.5 syntax sugars.
  Retroweaver is very promising, but falls short just enough to make it
impractical.  However, one other option is to combine both option A (from
your message) and option C.  One could "munge" the source code enough so that
you could use 1.5 style for-each (and anything else Retroweaver doesn't
handle well), and then use Retroweaver to handle everything else.

  - Andy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Generics

Hani Suleiman

On Jul 26, 2005, at 5:03 PM, Andy Depue wrote:

> Response at end...
>
<lots of stuff snipped>

I don't think writing YAT (yet another tool) is pertinent or wise.  
It's one more thing to maintain and is likely to be a PITA, as well  
as a distraction from the main focus of glazedlists.

Personally, I think using the undocumented -jsr14 target is the best  
bet if you really want to support generics now. it's the least work  
for the maximum gain.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Generics

adepue
On Tuesday 26 July 2005 09:08 am, Hani Suleiman wrote:
>
> I don't think writing YAT (yet another tool) is pertinent or wise.
> It's one more thing to maintain and is likely to be a PITA, as well
> as a distraction from the main focus of glazedlists.
>
> Personally, I think using the undocumented -jsr14 target is the best
> bet if you really want to support generics now. it's the least work
> for the maximum gain.

I see your point as far as glazedlists is concerned.  I was just dreaming out
loud in regard to many other projects - projects that would not feel
comfortable relying on an undocumented/unsupported feature. :)  Not just a
tool for glazedlists, but one tool for many projects... if there were such a
beast, it would make this decision quite easy for other projects.

  - Andy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Generics

Hani Suleiman
On Jul 26, 2005, at 5:18 PM, Andy Depue wrote:

> On Tuesday 26 July 2005 09:08 am, Hani Suleiman wrote:
>
>>
>> I don't think writing YAT (yet another tool) is pertinent or wise.
>> It's one more thing to maintain and is likely to be a PITA, as well
>> as a distraction from the main focus of glazedlists.
>>
>> Personally, I think using the undocumented -jsr14 target is the best
>> bet if you really want to support generics now. it's the least work
>> for the maximum gain.
>>
>
> I see your point as far as glazedlists is concerned.  I was just  
> dreaming out
> loud in regard to many other projects - projects that would not feel
> comfortable relying on an undocumented/unsupported feature. :)  Not  
> just a
> tool for glazedlists, but one tool for many projects... if there  
> were such a
> beast, it would make this decision quite easy for other projects.

Yeah but the problem isn't restricted to generics. It'd be quite hard  
for example to be disciplined enough to use generics, but not use  
foreach. Before long you'll find you have users who are clamouring  
for more and more 5.0 features, and in the usual way of developers,  
forgetting that there's a perfectly functional 5.0 JDK they can  
migrate to instead.

If you want to support 1.4 as a first class citizen, then do so and  
accept the downside of that. In this case, there simply isn't a  
silver bullet.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Generics

adepue
On Tuesday 26 July 2005 09:23 am, Hani Suleiman wrote:

>
> Yeah but the problem isn't restricted to generics. It'd be quite hard
> for example to be disciplined enough to use generics, but not use
> foreach. Before long you'll find you have users who are clamouring
> for more and more 5.0 features, and in the usual way of developers,
> forgetting that there's a perfectly functional 5.0 JDK they can
> migrate to instead.
>
> If you want to support 1.4 as a first class citizen, then do so and
> accept the downside of that. In this case, there simply isn't a
> silver bullet.

I guess I'm thinking mainly of library/framework projects that need to support
multiple platforms... glazedlists, Spring, etc.  Such projects currently
cannot use 1.5 syntax in their core code for the reasons Jesse originally
outlined.  Also, the idea *is* to provide full 1.5 syntax support (for-each,
etc) as indicated by option "C" (and maybe a little "A") in Jesse's original
message, so the developer would not have to worry about being disciplined
enough to use some but not all 1.5 syntax.  Anyway, no point in debating this
endlessly, as it is just a dream and I certainly don't have time to make it
happen. :)

  - Andy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Generics

Rob Eden
Hani/Andy -

Yeah, we'll need to do more research on what the best approach will  
be. I think the plan at the moment is for Jesse to tinker with his  
idea enough to get a feel for what the potential issues might be and  
then we can make a more information decision. In general I agree with  
you, Hani. If we can avoid making another tool, that would be best.  
We'll just have to see.

For the moment, the plan is to continue full support for 1.4, so  
generics are on hold for the moment. Hopefully we'll find a  
(relatively) nice solution soon, at which point we will support  
generics ASAP.

Rob


On Jul 26, 2005, at 11:34 AM, Andy Depue wrote:

> On Tuesday 26 July 2005 09:23 am, Hani Suleiman wrote:
>
>>
>> Yeah but the problem isn't restricted to generics. It'd be quite hard
>> for example to be disciplined enough to use generics, but not use
>> foreach. Before long you'll find you have users who are clamouring
>> for more and more 5.0 features, and in the usual way of developers,
>> forgetting that there's a perfectly functional 5.0 JDK they can
>> migrate to instead.
>>
>> If you want to support 1.4 as a first class citizen, then do so and
>> accept the downside of that. In this case, there simply isn't a
>> silver bullet.
>>
>
> I guess I'm thinking mainly of library/framework projects that need  
> to support
> multiple platforms... glazedlists, Spring, etc.  Such projects  
> currently
> cannot use 1.5 syntax in their core code for the reasons Jesse  
> originally
> outlined.  Also, the idea *is* to provide full 1.5 syntax support  
> (for-each,
> etc) as indicated by option "C" (and maybe a little "A") in Jesse's  
> original
> message, so the developer would not have to worry about being  
> disciplined
> enough to use some but not all 1.5 syntax.  Anyway, no point in  
> debating this
> endlessly, as it is just a dream and I certainly don't have time to  
> make it
> happen. :)
>
>   - Andy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--

"Let your heart soar as high as it will.
  Refuse to be average."
                            - A. W. Tozer


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...