You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <fm...@adobe.com> on 2012/01/04 13:16:23 UTC

[WebConsole] Dropping 1.4 builds ?

Hi,

I recently converted the Web Console code to use Generics and added the target jsr14 flag for the compiler to build Java 1.4 compatible class files. All fine and well.

until ... JDK 7 comes along ...

I just learned that the JDK 7 compiler does not support jsr14 compiled class files any longer and runs havock...

So, there are basically three options:

  (a) drop Java 1.4 support completely compiling to Java 5 class files
  (b) drop generics (and have Java 1.4 sources again)
  (c) have multiple build profiles

I would like to keep generics. They make a lot of things nicer. But then we alienate the embedded market ...

Where shall we go ? 

Regards
Felix

Re: [WebConsole] Dropping 1.4 builds ?

Posted by Felix Meschberger <fm...@adobe.com>.
Hi,

Am 04.01.2012 um 13:55 schrieb Marcel Offermans:

> On Jan 4, 2012, at 13:44 PM, 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).
> 
> 
> That does make sense. How do they name and version these artifacts?

Don't know yet. This is all brand new (I just heard about this this morning ;-) ).

> 
> I am a bit reluctant to ask, but how does this fit into the Maven pom, and our whole release process?

I didn't want to spell out. But I fear horror and nightmare.

I would prefer dropping generics ;-)

Regards
Felix

Re: [WebConsole] Dropping 1.4 builds ?

Posted by Marcel Offermans <ma...@luminis.nl>.
On Jan 4, 2012, at 13:44 PM, 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).


That does make sense. How do they name and version these artifacts?

I am a bit reluctant to ask, but how does this fit into the Maven pom, and our whole release process?

Greetings, Marcel


Re: [WebConsole] Dropping 1.4 builds ?

Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
>

Re: [WebConsole] Dropping 1.4 builds ?

Posted by Marcel Offermans <ma...@luminis.nl>.
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 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 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.

> 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. :)

Greetings, Marcel


Re: [WebConsole] Dropping 1.4 builds ?

Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.

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.

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.

-> richard


Re: [WebConsole] Dropping 1.4 builds ?

Posted by Marcel Offermans <ma...@luminis.nl>.
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"?

Greetings, Marcel


Re: [WebConsole] Dropping 1.4 builds ?

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/4/12 07:44 , Felix Meschberger wrote:
> Hi,
>
> 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.

-> richard

>
> Regards
> Felix

Re: [WebConsole] Dropping 1.4 builds ?

Posted by Felix Meschberger <fm...@adobe.com>.
Hi,

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).

Regards
Felix

Re: [WebConsole] Dropping 1.4 builds ?

Posted by jerome moliere <je...@gmail.com>.
Sounds very wise Marcel....
I guess that we (you) could examine another way with a branch using
old source style (with may be less features ?) but it raises all
maintenance problems that everybody knows ...


jerome
J.MOLIERE - Mentor/J
auteur Eyrolles
blog: http://romjethoughts.blogspot.com

Re: [WebConsole] Dropping 1.4 builds ?

Posted by Marcel Offermans <ma...@luminis.nl>.
On Jan 4, 2012, at 13:16 PM, Felix Meschberger wrote:

> I recently converted the Web Console code to use Generics and added the target jsr14 flag for the compiler to build Java 1.4 compatible class files. All fine and well.
> 
> until ... JDK 7 comes along ...
> 
> I just learned that the JDK 7 compiler does not support jsr14 compiled class files any longer and runs havock...
> 
> So, there are basically three options:
> 
>  (a) drop Java 1.4 support completely compiling to Java 5 class files
>  (b) drop generics (and have Java 1.4 sources again)
>  (c) have multiple build profiles
> 
> I would like to keep generics. They make a lot of things nicer. But then we alienate the embedded market ...
> 
> Where shall we go ? 


Let's start by concluding that this problem is a lot bigger in scope than just web console. As Holger recently pointed out on this list, the OSGi Alliance relied on an appearantly unsupported and (since Java 7) dead "-target jsr14" option. 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.

If I personally had to make a decision between supporting Java 1.4 or using generics, I would keep support for Java 1.4. In the end we build our software for our users and I know there are quite a few of them that run on embedded platforms that don't yet support Java 5.

Greetings, Marcel


Re: [WebConsole] Dropping 1.4 builds ?

Posted by je...@gmail.com.
Felix I am very happy and proud to help....
Kind regards
Jerome
---- Envoyé avec BlackBerry® d'Orange ----

-----Original Message-----
From: Felix Meschberger <fm...@adobe.com>
Date: Wed, 4 Jan 2012 12:58:30 
To: dev@felix.apache.org<de...@felix.apache.org>
Reply-To: dev@felix.apache.org
Subject: Re: [WebConsole] Dropping 1.4 builds ?

Hi Jerome,

Thanks for your elaborate answer. This is exactly the kind of feedback, I was trying to get.

Regards
Felix

Am 04.01.2012 um 13:24 schrieb jerome moliere:

> Hi Felix and other Felix members,
> the following is just the expression of my personal experience nothing more....
> i am working on a project where part from the application runs on
> embedded device with a J9 1.4.2 like JVM and WebConsole is the only
> way to get some valuable information about the application and the
> system because on Windows Mobile getting threading information and
> processus health is not so easy (no ps-grep java possible) so from my
> point of view it would be really a pity to loose such powerful tool
> ...
> I really understand that generics are good programming tools but ....
> 
> J.MOLIERE - Mentor/J
> auteur Eyrolles
> blog: http://romjethoughts.blogspot.com


Re: [WebConsole] Dropping 1.4 builds ?

Posted by Felix Meschberger <fm...@adobe.com>.
Hi Jerome,

Thanks for your elaborate answer. This is exactly the kind of feedback, I was trying to get.

Regards
Felix

Am 04.01.2012 um 13:24 schrieb jerome moliere:

> Hi Felix and other Felix members,
> the following is just the expression of my personal experience nothing more....
> i am working on a project where part from the application runs on
> embedded device with a J9 1.4.2 like JVM and WebConsole is the only
> way to get some valuable information about the application and the
> system because on Windows Mobile getting threading information and
> processus health is not so easy (no ps-grep java possible) so from my
> point of view it would be really a pity to loose such powerful tool
> ...
> I really understand that generics are good programming tools but ....
> 
> J.MOLIERE - Mentor/J
> auteur Eyrolles
> blog: http://romjethoughts.blogspot.com


Re: [WebConsole] Dropping 1.4 builds ?

Posted by jerome moliere <je...@gmail.com>.
Hi Felix and other Felix members,
the following is just the expression of my personal experience nothing more....
i am working on a project where part from the application runs on
embedded device with a J9 1.4.2 like JVM and WebConsole is the only
way to get some valuable information about the application and the
system because on Windows Mobile getting threading information and
processus health is not so easy (no ps-grep java possible) so from my
point of view it would be really a pity to loose such powerful tool
...
I really understand that generics are good programming tools but ....

J.MOLIERE - Mentor/J
auteur Eyrolles
blog: http://romjethoughts.blogspot.com

Re: [WebConsole] Dropping 1.4 builds ?

Posted by Felix Meschberger <fm...@adobe.com>.
Hi,

Thanks for all the comments so far.

Reading through all this, I think I will revert my conversion to generics (and improved for loops) and go back to pure Java 1.4 code and use the normal source and target of "1.4". To still ensure only using Java 1.4 API I already have added the animal sniffer plugin enforcing Java 1.4 API use (it is not 100% safe but probably close enough).

This is a major plus for our friends of the embedded world (still depending on Java 1.4) and Java 7 world (not supporting generics in Java 1.4 class files) and requires only a handful of web console developers to limit ourselves.

Regards
Felix

Am 04.01.2012 um 13:16 schrieb Felix Meschberger:

> Hi,
> 
> I recently converted the Web Console code to use Generics and added the target jsr14 flag for the compiler to build Java 1.4 compatible class files. All fine and well.
> 
> until ... JDK 7 comes along ...
> 
> I just learned that the JDK 7 compiler does not support jsr14 compiled class files any longer and runs havock...
> 
> So, there are basically three options:
> 
>  (a) drop Java 1.4 support completely compiling to Java 5 class files
>  (b) drop generics (and have Java 1.4 sources again)
>  (c) have multiple build profiles
> 
> I would like to keep generics. They make a lot of things nicer. But then we alienate the embedded market ...
> 
> Where shall we go ? 
> 
> Regards
> Felix