On 1/4/12 13:33 , Marcel Offermans wrote:
On Jan 4, 2012, at 19:10 PM, Richard S. Hall wrote:
On 1/4/12 13:06 , Marcel Offermans wrote:
On Jan 4, 2012, at 15:13 PM, Richard S. Hall wrote:
On 1/4/12 07:44 , Felix Meschberger wrote:
Am 04.01.2012 um 13:39 schrieb Marcel Offermans:
It would be nice to learn how they intend to solve this issue before we do,
because it probably makes sense to align our decision with theirs.
They will create two builds. This would be my option (c).
I don't think that has been decided.
From my understanding (and preference), they will maintain 1.4 source compatibility by
compiling against foundation, but target Java 5 in binary. With this approach, the
majority of people using modern JVMs will be able to use the produced artifacts "as
is", while people running on 1.4 will need to recompile. You could do something
similar.
Then the question remains: do we provide more than one artifact, or do we tell everybody
that still wants 1.4 compatibility to "compile it themselves"?
Well, our binaries are only for convenience, right? We release source.
Agreed. However, you should also be able to create binaries from our source
code without actually having to modify anything.
To recompile for 1.4, you most likely need to make adjustments to the pom.xml,
which in turn leads to an artifact in Maven that has the exact same name and
version as the Java 5 one, but is different.
So? They are binary compatible at run time, they just pose issues at
compile time, no?
So should you then also start using a different bundle symbolic name? And if
you start doing that, how does that effect ripple through all your dependencies?
I wouldn't.
I would think that most people with special requirements (e.g., embedded
scenarios) are used to having to roll their own, so asking them to recompile is
not a major deal. We have limited resources, so we are better off directing
that effort at the majority of our users.
Given the trouble we get into, trying to provide more than one binary, I tend
to agree that we should not start doing that. However, I do feel for our users
that need to start doing this themselves, as it might not be so straightforward
to get this working.
Nothing prevents us from adding a profile in our poms compile it the
right way for 1.4...assuming they are even using Maven in the first place.
However, in the end, it doesn't really matter to me. I don't think that one way
is clearly better than the other, I just think that producing a single artifact
is less effort on our part, so that's the way I'd go.
Again, I tend to agree, I'm just exploring this a bit further so we can help
out people that want to do something different.
In hindsight, relying on some compiler magic to turn source code with generics
into binary code without was probably a bad choice by the OSGi Alliance, but we
cannot change that anymore. Maybe some of the companies that are also involved
in OpenJDK can reintroduce that compiler option and properly fix this. If not,
we will probably have a new and lengthy FAQ item on our website about this. :)
I don't think that was the issue precisely. If I understand correctly,
the issue is not that we have a missing -jsr14 flag, but that Java7 now
ignores the generic information embedded in class files generated for
that target (i.e., version 48 class files):
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078419
-> richard
Greetings, Marcel
