[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [p2-dev] Extending classes with generics
|
Yes, it appears I was a little confused. I get the "red X" too, but there are *no* compile errors in my problems view.
However, I don't appear to be able to self host on a 1.4 VM. When I try and launch I get a variety of errors like:
Caused by: java.lang.UnsupportedClassVersionError: org/eclipse/equinox/p2/core/IAgentLocation (Unsupported major.minor version 49.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:183)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:576)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:546)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:477)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:465)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:445)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:211)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393)
So I have two questions:
1. Are we sure that this fix actually produces 1.4 byte code (from the workspace)
2. Should we work with the JDT team to try and improve this workflow for Eclipse 3.6? Hacking the .settings files will likely get us into trouble moving forward since each time we open the project properties dialog, we risk modifying these settings (note: when I open the project properties it shows that p2 is compiled for Java 1.7 since these dialogs don't know what jsr14 is). I don't know what happens if I make some (unrelated changes) and click apply.
I think this use case (using Java 1.5 syntax but producing Java 1.4 byte code) is valuable, but it seems like we are fighting the tooling.
cheers,
Ian
On Wed, Jan 6, 2010 at 8:41 AM, Curtis Windatt
<Curtis_Windatt@xxxxxxxxxx> 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:
| |
| 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
_______________________________________________
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
