dropping JDK 1.4 support

[Holger Brands]

Hey guys,

I started to work on this:
I removed the 'java14' target from our build,
added missing @Override annotations,
removed unnecessary casts and simplified
calls to Arrays.asList.

Just FYI,
Holger

____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[philk]

Please do not forget to fix the OSGi Manifests Execution-Environment accordingly then :)

Holger Brands wrote:

Hey guys,

I started to work on this:
I removed the 'java14' target from our build,
added missing @Override annotations,
removed unnecessary casts and simplified
calls to Arrays.asList.

Just FYI,
Holger

____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123


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

[Holger Brands]

As far as I know, we currently do not include an
Execution-Environment in the manifest.

I guess, we would have something like this in the manifest:
Bundle-RequiredExecutionEnvironment: J2SE-1.5

What advantages/disadvantages has the
specification of an execution environment?

For example, the spring jars do not contain an execution environment.

Thanks,
Holger

>
> Please do not forget to fix the OSGi Manifests Execution-Environment
> accordingly then :)
>
>
> Holger Brands wrote:
> >
> > Hey guys,
> >
> > I started to work on this:
> > I removed the 'java14' target from our build,
> > added missing @Override annotations,
> > removed unnecessary casts and simplified
> > calls to Arrays.asList.
> >
> > Just FYI,
> > Holger
> >
> > ____________________________________________________________________
> > Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
> > Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/dropping-JDK-1.4-support-tp22524074p22557668.html
> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[W.B. Garvelink]

It's an additional deployment-time compatibility check. In this case,
it doesn't add much benefit because JDK 1.4 will fail to load "-target
1.5" classes anyway. In other cases, it may conceivably give you a
fail-fast at deployment that would have been a NoSuchMethodError a
week later.

Barend


On Tue, Mar 17, 2009 at 8:18 PM, Holger Brands <hbrands@...> wrote:

> As far as I know, we currently do not include an
> Execution-Environment in the manifest.
>
> I guess, we would have something like this in the manifest:
> Bundle-RequiredExecutionEnvironment: J2SE-1.5
>
> What advantages/disadvantages has the
> specification of an execution environment?
>
> For example, the spring jars do not contain an execution environment.
>
> Thanks,
> Holger
>
>>
>> Please do not forget to fix the OSGi Manifests Execution-Environment
>> accordingly then :)
>>
>>
>> Holger Brands wrote:
>> >
>> > Hey guys,
>> >
>> > I started to work on this:
>> > I removed the 'java14' target from our build,
>> > added missing @Override annotations,
>> > removed unnecessary casts and simplified
>> > calls to Arrays.asList.
>> >
>> > Just FYI,
>> > Holger
>> >
>> > ____________________________________________________________________
>> > Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
>> > Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@...
>> > For additional commands, e-mail: dev-help@...
>> >
>> >
>> >
>>
>> --
>> View this message in context: http://www.nabble.com/dropping-JDK-1.4-support-tp22524074p22557668.html
>> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
> ____________________________________________________________________
> Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
> Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Holger Brands]

Thanks for the info.
I conclude that we don't need to add the execution environment setting.

Holger

> It's an additional deployment-time compatibility check. In this case,
> it doesn't add much benefit because JDK 1.4 will fail to load "-target
> 1.5" classes anyway. In other cases, it may conceivably give you a
> fail-fast at deployment that would have been a NoSuchMethodError a
> week later.
>
> Barend
>
>
> On Tue, Mar 17, 2009 at 8:18 PM, Holger Brands <hbrands@...> wrote:
> > As far as I know, we currently do not include an
> > Execution-Environment in the manifest.
> >
> > I guess, we would have something like this in the manifest:
> > Bundle-RequiredExecutionEnvironment: J2SE-1.5
> >
> > What advantages/disadvantages has the
> > specification of an execution environment?
> >
> > For example, the spring jars do not contain an execution environment.
> >
> > Thanks,
> > Holger
> >
> >>
> >> Please do not forget to fix the OSGi Manifests Execution-Environment
> >> accordingly then :)
> >>
> >>
> >> Holger Brands wrote:
> >> >
> >> > Hey guys,
> >> >
> >> > I started to work on this:
> >> > I removed the 'java14' target from our build,
> >> > added missing @Override annotations,
> >> > removed unnecessary casts and simplified
> >> > calls to Arrays.asList.
> >> >
> >> > Just FYI,
> >> > Holger
> >> >
> >> > ____________________________________________________________________
> >> > Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
> >> > Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@...
> >> > For additional commands, e-mail: dev-help@...
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context: http://www.nabble.com/dropping-JDK-1.4-support-tp22524074p22557668.html
> >> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> For additional commands, e-mail: dev-help@...
> >>
> >>
> >
> >
> > ____________________________________________________________________
> > Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
> > Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Endre Stølsvik-8]

Besides the more explicit reasoning and error reporting that such a
compatibility check gives, I can envision different development tools
that introspect such information, and coding repository websites that
display such information. This as opposed to having to basically
either hunt this information down on the webpages, or running some
test code and see that it fails - or not fails, and not be certain.
What is the benefit of not including it?

Endre.

On Thu, Mar 19, 2009 at 21:44, Holger Brands <hbrands@...> wrote:

> Thanks for the info.
> I conclude that we don't need to add the execution environment setting.
>
> Holger
>
>> It's an additional deployment-time compatibility check. In this case,
>> it doesn't add much benefit because JDK 1.4 will fail to load "-target
>> 1.5" classes anyway. In other cases, it may conceivably give you a
>> fail-fast at deployment that would have been a NoSuchMethodError a
>> week later.
>>
>> Barend
>>
>>
>> On Tue, Mar 17, 2009 at 8:18 PM, Holger Brands <hbrands@...> wrote:
>> > As far as I know, we currently do not include an
>> > Execution-Environment in the manifest.
>> >
>> > I guess, we would have something like this in the manifest:
>> > Bundle-RequiredExecutionEnvironment: J2SE-1.5
>> >
>> > What advantages/disadvantages has the
>> > specification of an execution environment?
>> >
>> > For example, the spring jars do not contain an execution environment.
>> >
>> > Thanks,
>> > Holger
>> >
>> >>
>> >> Please do not forget to fix the OSGi Manifests Execution-Environment
>> >> accordingly then :)
>> >>
>> >>
>> >> Holger Brands wrote:
>> >> >
>> >> > Hey guys,
>> >> >
>> >> > I started to work on this:
>> >> > I removed the 'java14' target from our build,
>> >> > added missing @Override annotations,
>> >> > removed unnecessary casts and simplified
>> >> > calls to Arrays.asList.
>> >> >
>> >> > Just FYI,
>> >> > Holger
>> >> >
>> >> > ____________________________________________________________________
>> >> > Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
>> >> > Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
>> >> >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@...
>> >> > For additional commands, e-mail: dev-help@...
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context: http://www.nabble.com/dropping-JDK-1.4-support-tp22524074p22557668.html
>> >> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@...
>> >> For additional commands, e-mail: dev-help@...
>> >>
>> >>
>> >
>> >
>> > ____________________________________________________________________
>> > Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
>> > Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@...
>> > For additional commands, e-mail: dev-help@...
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
> ____________________________________________________________________
> Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
> Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Holger Brands]

I'm still trying to fully grasp the concept of execution environments
and the implications of specifying them in the manifest.
I also wonder, why major players in the OSGi space like SpringSource,
don't specify them in their own jars.

Here is my current understanding (referring to OSGi 4.1):
Disclaimer: I'm no OSGi expert, so I could talk a lot of nonsense ;-)

Here are some defs from the spec:

"The Bundle-RequiredExecutionEnvironment contains a comma-separated
list of execution environments that must be present on the Service Platform."

"A bundle that is restricted to one or more execution environments must
carry a header in its manifest file to indicate this dependency."

"If a bundle includes this header in the manifest then the bundle must only
use methods with signatures that are contained within a proper subset of all
mentioned execution environments. Bundles should list all (known) execution
environments on which it can run the bundle."

"The org.osgi.framework.executionenvironment property [...]
must contain a comma-separated list of execution environment names
implemented by the Framework."

So the actual OSGi Service Plattform implementation gets the set of
supported environments from this property value.
If none of the execution environments listed by a bundle
is supported by the plattform implementation, the bundle is not able to execute.

The spec goes on and explains the naming of execution environments and lists
some examples of the most common execution environments.

In the OSGi 4.1 compendium specification 999, two concrete execution environments
are specified (OSGi/Minimum-1.1 and CDC-1.1/Foundation-1.1). There are also
further defs:

"An Execution Environment consists of a set of public and protected signatures.
A signature is defined to be a unique identifier for a field or method
with class and type information."
"An Execution Environment consists of a set of classes and interfaces with
their access qualifiers. Each class consist of a set of signatures."
"An Execution environment is solely based on the signatures of the methods
and fields."

So, to sum up:
An Execution Environment has a (unique) name to identify it.
It is mainly defined in terms of the set of public and protected signatures of
fields and methods of the included classes and interfaces.
I didn't find any explicit reference to bytecode compatibility.
But I guess that is implied by the sentence:
"Bundles should list all (known) execution environments on
which it can run the bundle."

But wait, according to the above sentence
"Bundle-RequiredExecutionEnvironment: J2SE-1.5"
would be incomplete for GL 1.9. We know it runs on J2SE-1.6, too,
so we should (must?) also list it:
Bundle-RequiredExecutionEnvironment: J2SE-1.5, JavaSE-1.6

With this, we'd say: Our code only uses the intersection of all defined
signatures included in these two execution environments.

Hm, what about JavaSE-1.7? I guess it isn't defined yet. But it's very
likely that GL will run on 1.7, isn't it?
Did we forget other execution environements? Where is the full list
of known execution environments? Who defines them?
I don't know.

So I guess, it's not mandated but only recommended to list more
than one required execution environment for a bundle.
The setting of one execution environment seems to be interpreted
like the "minimum required execution environment" for a bundle.
But this implies a defined relationship between the known
environments, e.g. "J2SE-1.5 is a subset of JavaSE-1.6".
These are not defined explicitly in the spec. But they can be
derived from the set of signatures each environment defines.
For example: The set of signatures contained in J2SE-1.5 is a subset of the
signatures contained in JavaSE-1.6, so JavaSE-1.6 is compatible with J2SE-1.5.

So a plattform implementation running on JRE 1.6 will have to include
not only JavaSE-1.6 in its org.osgi.framework.executionenvironment property,
but also all other compatible execution environments like J2SE-1.5,  J2SE-1.4
and so on.

So here comes the crux:
I guess this mechanism will only work as long as future Java Editions stay
compatible with their predecessors, e.g. don't remove deprecated
fields and methods. Is this guaranteed?

Assume for example, that JavaSE-1.8 will remove some deprecated methods.
As a consequence, a plattform implementation running on JRE 1.8 can't support
older environments like JavaSE-1.7 and JavaSE-1.6.
So, it will be able to execute only those bundles, which explicitly list JavaSE-1.8 as
required environment.
Existing bundles, that were deployed before the existence of JavaSE-1.8, obviously
don't include JavaSE-1.8 as required execution environment. Even if they don't use
any of the deprecated methods, that were removed in JavaSE-1.8, they will not
be allowed to run on that plattform implementation - even if they could.

To cut a long story short, i think this concept will only work, if the Java Editions
stay compatible with each other for all times, e.g. if they will never remove
any deprecated members.
Is this really guaranteed?

Another thing to consider is the upcoming modularization of the JRE itself.
In this context, the dependency upon an execution environment as a whole
seems to be to coarse-grained?
Instead, I could imagine that in the future a bundle will only declare
it's *actual* dependencies on the execution environment, e.g. the *used* API,
which would be only a subset of the *available* API.

Again, may be I'm missing something. But that's how I see it, currently.
Of course, we could just ignore these "academic problems" and just
include this damned flag in our manifest ;-)

Holger

> Besides the more explicit reasoning and error reporting that such a
> compatibility check gives, I can envision different development tools
> that introspect such information, and coding repository websites that
> display such information. This as opposed to having to basically
> either hunt this information down on the webpages, or running some
> test code and see that it fails - or not fails, and not be certain.
> What is the benefit of not including it?
>
> Endre.
>
> On Thu, Mar 19, 2009 at 21:44, Holger Brands <hbrands@...> wrote:
> > Thanks for the info.
> > I conclude that we don't need to add the execution environment setting.
> >
> > Holger
> >
> >> It's an additional deployment-time compatibility check. In this case,
> >> it doesn't add much benefit because JDK 1.4 will fail to load "-target
> >> 1.5" classes anyway. In other cases, it may conceivably give you a
> >> fail-fast at deployment that would have been a NoSuchMethodError a
> >> week later.
> >>
> >> Barend
> >>
> >>
> >> On Tue, Mar 17, 2009 at 8:18 PM, Holger Brands <hbrands@...> wrote:
> >> > As far as I know, we currently do not include an
> >> > Execution-Environment in the manifest.
> >> >
> >> > I guess, we would have something like this in the manifest:
> >> > Bundle-RequiredExecutionEnvironment: J2SE-1.5
> >> >
> >> > What advantages/disadvantages has the
> >> > specification of an execution environment?
> >> >
> >> > For example, the spring jars do not contain an execution environment.
> >> >
> >> > Thanks,
> >> > Holger
> >> >
> >> >>
> >> >> Please do not forget to fix the OSGi Manifests Execution-Environment
> >> >> accordingly then :)
> >> >>
> >> >>
> >> >> Holger Brands wrote:
> >> >> >
> >> >> > Hey guys,
> >> >> >
> >> >> > I started to work on this:
> >> >> > I removed the 'java14' target from our build,
> >> >> > added missing @Override annotations,
> >> >> > removed unnecessary casts and simplified
> >> >> > calls to Arrays.asList.
> >> >> >
> >> >> > Just FYI,
> >> >> > Holger
> >> >> >
> >> >> > ____________________________________________________________________
> >> >> > Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
> >> >> > Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
> >> >> >
> >> >> >
> >> >> > ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@...
> >> >> > For additional commands, e-mail: dev-help@...
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context: http://www.nabble.com/dropping-JDK-1.4-support-tp22524074p22557668.html
> >> >> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> >> For additional commands, e-mail: dev-help@...
> >> >>
> >> >>
> >> >
> >> >
> >> > ____________________________________________________________________
> >> > Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
> >> > Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@...
> >> > For additional commands, e-mail: dev-help@...
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> For additional commands, e-mail: dev-help@...
> >>
> >>
> >
> >
> > ____________________________________________________________________
> > Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
> > Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...