Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Extending classes with generics


The PMC actually decided to drop 1.4 as a reference platform awhile ago and the plan update should be available this week (see Sept 17 entry on http://wiki.eclipse.org/Eclipse/PMC). This doesn't mean that every plug-in can suddenly move to Java 5, but on a case-by-case basis that's certainly possible. If you think that's interesting for PDE I suggest discussing with PDE project leads and they can bring it forward to the PMC. Personally I see no reason for PDE UI to still run on JDK 1.4...

John




Curtis Windatt/Ottawa/IBM@IBMCA
Sent by: p2-dev-bounces@xxxxxxxxxxx

01/06/2010 12:17 PM

Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>

To
P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc
Subject
Re: [p2-dev] Extending classes with generics





PDE is just following with the rest of the Eclipse platform.  To my knowledge, there is nothing in PDE requiring us to run on 1.4.  So this really is a question for eclipse-dev and the PMC.  I know the question gets raised every year as 1.5 is quite pervasive, but so far 1.4 support has been required.

>From the Eclipse plan:

In general, the 3.6 release of the Eclipse Project is developed on a mix

 of Java 1.4, Java 5 and Java 6 VMs. As such, the Eclipse SDK as a whole

 is targeted at all modern, desktop Java VMs. Full functionality is available for

 1.4 level development everywhere, and extended development capabilities are made

 available on the VMs that support them.


Curtis


From: Ed Merks <ed.merks@xxxxxxxxx>
To: P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date: 2010/01/06 11:05 AM
Subject: Re: [p2-dev] Extending classes with generics






One has to wonder why the PDE should be restricted to 1.4.  It's not as if it needs to run on small devices is it?  Isn't 1.4 End of Life already too?  It seems hard to argue that it's important for the full IDE to run on such an old JRE.  I suppose that's more of a pde-dev question...


Curtis Windatt wrote:

@Ian   Yes, the error has not been fixed by Pascal's changes.  The 1.4 binaries are available, so the error is not affecting my work, other than having an annoying red x in my file :)


@Thomas  The Eclipse Platform project is strictly 1.4.  Both PDE UI and PDE Build are using p2 apis.


Curtis

From: Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
To: P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date: 2010/01/06 10:32 AM
Subject: Re: [p2-dev] Extending classes with generics







Maybe I'm doing something wrong, but I have a Java 1.4 project that depends on p2 (much like PDE does) and I still get the same error that Curtis pointed out.  I have the p2 sources in my workspace.

Maybe this wasn't the problem we were trying to solve.

cheers,
ian

On Wed, Jan 6, 2010 at 12:05 AM, Daniel Le Berre <
leberre@xxxxxxxxxxxxxxxxxxx> wrote:
Thomas,

We should be able to make this work inside Eclipse Workspace because I
am using ECJ to build SAT4J bundles:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=286391

We just need to be careful about the version of eclipse (compiler) we
use (it must be at least 3.6M2 or 3.5.1 AFAIR).

You can see that in the current code: you use sat4j generics in the
Projector class for instance.

     Daniel

Thomas Hallgren a écrit :
>
> This was one of my worries too. I really want to use the p2 generics in
> Buckminster but I'm not too keen on having all the p2 source in my
> workspace.
>
> In my opinion, we should compile the p2 source for Java 1.4 for two
> purposes:
> 1. For testing that everything indeed can run on such a platform.
> 2. To provide 1.4 based bytecodes for platforms where no 1.5 alternative
> exists.
>
> Question is, what platforms is it that needs to remain on 1.4? Isn't
> that just a few embedded devices? If so, shouldn't the default be to
> compile for 1.5 and then to provide special down-compiled distros for
> those embedded devices? If I remember correctly, there are some
> significant gains (size and performance) when compiling for 1.5 compared
> to the 1.4.
>
> Just a thought. I realize that it goes beyond the p2 domain.
>
> - thomas
>
>
> On 2010-01-05 23:18, Daniel Le Berre wrote:
>> Indeed, it works.
>>
>> However, I am wondering if it is really a good idea: working that way
>> with generics prevents one project to see the generic classes of another
>> project, correct?
>> (If I apply the same technique for sat4j, I can no longer use the
>> generic classes of org.sat4j.core in org.sat4j.pb!!!!)
>>
>> It is the expected behavior for PDE people for instance reusing p2
>> bundles.
>>
>> But inside p2 projects, it would mean inability to share generic code
>> between bundles...
>>
>> Daniel
>>
>> Pascal Rapicault a écrit :
>>
>>> I have released the changes to the project preference settings in the p2
>>> projects to enable down compilation in the IDE.
>>>
>>>
>>> Inactive hide details for Curtis Windatt---04/01/2010 10:54:45
>>> PM---Recently a number of the query API were changed to use geneCurtis
>>> Windatt---04/01/2010 10:54:45 PM---Recently a number of the query API
>>> were changed to use generics, this causes some annoyances in PDE (as we
>>> are strictly 1.4), b
>>>
>>>
>>> From:
>>> Curtis Windatt/Ottawa/IBM@IBMCA
>>>
>>> To:
>>> P2 developer discussions<
p2-dev@xxxxxxxxxxx>
>>>
>>> Date:
>>> 04/01/2010 10:54 PM
>>>
>>> Subject:
>>> [p2-dev] Extending classes with generics
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> Recently a number of the query API were changed to use generics, this
>>> causes some annoyances in PDE (as we are strictly 1.4), but up until now
>>> I can work around them. However, I have a problem extending a class with
>>> generics, specifically MatchQuery
>>>
>>> IQuery query = new MatchQuery() {
>>> public boolean isMatch(Object candidate) {
>>> if (candidate instanceof IInstallableUnit) {
>>> if (P2Utils.isBundle((IInstallableUnit) candidate)) {
>>> return true;
>>> }
>>> }
>>> return false;
>>> }
>>> };
>>>
>>> The compiler complains that I need to extend the isMatch(T candidate)
>>> instead, but I am unable to use generics in PDE.
>>>
>>> As a side note, why was size() removed from IQueryResult? It was quite
>>> convenient for me when creating arrays of InstallableUnitDescriptions
>>> and other objects that get filled in based on the query result iterator.
>>> Now I have to grab one of the sets and ask it for the size. Not a big
>>> deal, but it felt natural to ask the result for its size, since you can
>>> ask it for an iterator.
>>>
>>> Curtis_______________________________________________
>>> p2-dev mailing list
>>>
p2-dev@xxxxxxxxxxx
>>>
https://dev.eclipse.org/mailman/listinfo/p2-dev
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> p2-dev mailing list
>>>
p2-dev@xxxxxxxxxxx
>>>
https://dev.eclipse.org/mailman/listinfo/p2-dev
>>>
>>
>>
>
>
> _______________________________________________
> p2-dev mailing list
>
p2-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/p2-dev
>
>


--
          Daniel Le Berre mailto:
leberre@xxxxxxxxxxxxxxxxxxx
          MCF,    CRIL-CNRS UMR 8188,    Universite d'Artois
         
http://www.cril.univ-artois.fr/~leberre
_______________________________________________
p2-dev mailing list

p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev



--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484

http://eclipsesource.com | http://twitter.com/eclipsesource_______________________________________________
p2-dev mailing list

p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev





_______________________________________________
p2-dev mailing list

p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/p2-dev

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev


Back to the top