Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Java (http://www.linux-archive.org/debian-java/)
-   -   Integrating the FOSDEM 06 Draft into the Java (http://www.linux-archive.org/debian-java/347531-integrating-fosdem-06-draft-into-java.html)

Matthew Johnson 03-26-2010 04:19 PM

Integrating the FOSDEM 06 Draft into the Java
 
On Fri Mar 26 17:37, Eric Lavarde wrote:
>> They should build-depend on default-jdk and depend on default-jre | javaN-runtime
> I have some problems with this:
>
> 1. the policy states something like "javaX-runtime fulfills the Java X
> specifications" (sorry, the patches are not reachable right now), but
> gcj/gij specifically does not fulfill the Java X specifications (else
> they wouldn't be incompatible with sun's Java resp. openjdk).

Well, that's not a useful definition for them in that case and should probably
be changed (in a future patch to policy)

> 2. On one side, in order to depend on default-j, programs and libraries
> must work both with openjdk and gcj, such programs/libraries should then
> depend on default-j, and only such programs/libraries can depend on
> javaX-runtime. The result is that javaX-runtime and default-jre are more
> or less interchangeable, and only confuse people (well, me at least).

No, default-jre is a concrete package pointing to specifically one JRE on a
given platform. javaX-runtime is a virtual package provided by mane packages.
Depending on default-jre says "I must have the default for this platform".
Depending on default-jre | javaX-runtime says "I can work with any JRE, but if
you don't already have one, please give me the default".

> 3. gcj's versioning doesn't follow Java's versioning (X), so that each
> new version of gcj is just a more and more complete version of any X
> version of Java.
> Example: package MyJavaProgram depends on gcj-jre (>= 4.4) |
> javaX-runtime because it doesn't work with gcj 4.3. But user already has
> gcj-jre=4.3, which also provides javaX-runtime --> failure.

Then you want Conflicts: gcj-jre (<< 4.4)

> 4. On the other hand, openjdk and sun's java are really interchangeable
> and would justify a javaX-runtime, as their own versioning/naming
> follows the X schema.
>
> Bottom-line, I would ask to either suppress javaX-runtime all together
> as being useless or even dangerous (as per point 3), or (my preferred)
> to reserve it for runtime environments which have passed the Java
> Compatibility Tests.

Personally now that we have openjdk I think we should drop Sun's JRE, at which
point you don't need a virtual package for them.

You _do_ need something for "Will work with whichever of openjdk/sun/gcj
happens to be installed", which is what javaX-runtime currently provides. The
versioning is mainly to ensure you have something which can read the classfile
version you compiled to.

Matt
--
Matthew Johnson

أحمد المحمودي 03-26-2010 06:44 PM

Integrating the FOSDEM 06 Draft into the Java
 
On Fri, Mar 26, 2010 at 05:19:24PM +0000, Matthew Johnson wrote:
> Personally now that we have openjdk I think we should drop Sun's JRE, at which
> point you don't need a virtual package for them.
---end quoted text---

I don't think this is possible, since (as far as I know) the only java
plugin for web browsers is sun-java6-plugin, which needs sun-java6-jre

--
‎أ*مد الم*مودي (Ahmed El-Mahmoudy)
Digital design engineer
GPG KeyID: 0xEDDDA1B7
GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100326194436.GB2249@ants.dhis.net">http://lists.debian.org/20100326194436.GB2249@ants.dhis.net

Eric Lavarde 03-26-2010 07:47 PM

Integrating the FOSDEM 06 Draft into the Java
 
OK, I'm not exactly enthusiastic, but I can live with this, as long as
the wording of the policy is adapted accordingly.


Why I'm not enthusiastic: should I manage to get into Debian yet another
Java runtime, which is not compatible with either gcj, nor with openjdk,
then the result could be that quite a lot of packages wouldn't be
policy compliant anymore, because they wouldn't work with "all" JRE anymore.
You might say that it's a constructed case, and it is, that's why I can
live with this, but it means still for me that the policy isn't fully
coherent.


Eric

Matthew Johnson wrote:

On Fri Mar 26 17:37, Eric Lavarde wrote:

They should build-depend on default-jdk and depend on default-jre | javaN-runtime

I have some problems with this:

1. the policy states something like "javaX-runtime fulfills the Java X
specifications" (sorry, the patches are not reachable right now), but
gcj/gij specifically does not fulfill the Java X specifications (else
they wouldn't be incompatible with sun's Java resp. openjdk).


Well, that's not a useful definition for them in that case and should probably
be changed (in a future patch to policy)

2. On one side, in order to depend on default-j, programs and libraries
must work both with openjdk and gcj, such programs/libraries should then
depend on default-j, and only such programs/libraries can depend on
javaX-runtime. The result is that javaX-runtime and default-jre are more
or less interchangeable, and only confuse people (well, me at least).


No, default-jre is a concrete package pointing to specifically one JRE on a
given platform. javaX-runtime is a virtual package provided by mane packages.
Depending on default-jre says "I must have the default for this platform".
Depending on default-jre | javaX-runtime says "I can work with any JRE, but if
you don't already have one, please give me the default".

3. gcj's versioning doesn't follow Java's versioning (X), so that each
new version of gcj is just a more and more complete version of any X
version of Java.
Example: package MyJavaProgram depends on gcj-jre (>= 4.4) |
javaX-runtime because it doesn't work with gcj 4.3. But user already has
gcj-jre=4.3, which also provides javaX-runtime --> failure.


Then you want Conflicts: gcj-jre (<< 4.4)

4. On the other hand, openjdk and sun's java are really interchangeable
and would justify a javaX-runtime, as their own versioning/naming
follows the X schema.


Bottom-line, I would ask to either suppress javaX-runtime all together
as being useless or even dangerous (as per point 3), or (my preferred)
to reserve it for runtime environments which have passed the Java
Compatibility Tests.


Personally now that we have openjdk I think we should drop Sun's JRE, at which
point you don't need a virtual package for them.

You _do_ need something for "Will work with whichever of openjdk/sun/gcj
happens to be installed", which is what javaX-runtime currently provides. The
versioning is mainly to ensure you have something which can read the classfile
version you compiled to.


Matt



--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BAD1D49.50808@zorglub.s.bawue.de">http://lists.debian.org/4BAD1D49.50808@zorglub.s.bawue.de

Niels Thykier 03-26-2010 08:24 PM

Integrating the FOSDEM 06 Draft into the Java
 
أ*مد الم*مودي wrote:
> On Fri, Mar 26, 2010 at 05:19:24PM +0000, Matthew Johnson wrote:
>> Personally now that we have openjdk I think we should drop Sun's JRE, at which
>> point you don't need a virtual package for them.
> ---end quoted text---
>
> I don't think this is possible, since (as far as I know) the only java
> plugin for web browsers is sun-java6-plugin, which needs sun-java6-jre
>

Personally I disagree here, openjdk-6 comes with a webplugin
(icedtea6-plugin) that works very well for me.

~Niels

Niels Thykier 03-26-2010 08:49 PM

Integrating the FOSDEM 06 Draft into the Java
 
> live with this, but it means still for me that the policy isn't fully
> coherent.
>=20
> Eric
>=20
> [...]

I can perfectly understand your point of view and I agree, we do have a
problem here. However, if I try to add this change to my current
patches, those patches (and their changes) would be stalled until we
have sorted this out. This is why I will not put your proposal / request
for change into the patches.
Nevertheless, I think we (the Team) should continue this debate
(possibly in a new thread). Once we come to a conclusion, I will more
than willing to help formulate and apply the policy change.

~Niels

Mehdi Dogguy 03-26-2010 09:03 PM

Integrating the FOSDEM 06 Draft into the Java
 
Niels Thykier wrote:
>
> Personally I disagree here, openjdk-6 comes with a webplugin
> (icedtea6-plugin) that works very well for me.
>

It may work with common Java applets but doesn't work well for
cryptographic stuff. Ask any french guy that pays his taxes online :)

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BAD2F4F.5090300@dogguy.org">http://lists.debian.org/4BAD2F4F.5090300@dogguy.org

Niels Thykier 03-26-2010 09:11 PM

Integrating the FOSDEM 06 Draft into the Java
 
Mehdi Dogguy wrote:
> Niels Thykier wrote:
>> Personally I disagree here, openjdk-6 comes with a webplugin
>> (icedtea6-plugin) that works very well for me.
>>
>
> It may work with common Java applets but doesn't work well for
> cryptographic stuff. Ask any french guy that pays his taxes online :)
>

I use it to access my Web-bank which (to the best of my knowledge) is
encrypted.

~Niels

Mehdi Dogguy 03-26-2010 09:43 PM

Integrating the FOSDEM 06 Draft into the Java
 
Niels Thykier wrote:
>
> I use it to access my Web-bank which (to the best of my knowledge) is
> encrypted.
>

That won't help to pay my taxes online :)

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BAD3899.4050203@dogguy.org">http://lists.debian.org/4BAD3899.4050203@dogguy.org

Matthew Johnson 03-26-2010 11:24 PM

Integrating the FOSDEM 06 Draft into the Java
 
On Fri Mar 26 21:47, Eric Lavarde wrote:
> OK, I'm not exactly enthusiastic, but I can live with this, as long as
> the wording of the policy is adapted accordingly.
>
> Why I'm not enthusiastic: should I manage to get into Debian yet another
> Java runtime, which is not compatible with either gcj, nor with openjdk,
> then the result could be that quite a lot of packages wouldn't be policy
> compliant anymore, because they wouldn't work with "all" JRE anymore.

I personally view adding more JREs as a bad plan. I believe we should be aiming
to reduce their number, ideally to one (at least, to one that behaves as
/usr/bin/java and that packages depend on; or - one that is _supported_ as
/usr/bin/java).

After all, despite multiple python interpreters, only one of them is supported
as /usr/bin/python.

Matt
--
Matthew Johnson

أحمد المحمودي 03-27-2010 02:38 AM

Integrating the FOSDEM 06 Draft into the Java
 
On Fri, Mar 26, 2010 at 10:24:40PM +0100, Niels Thykier wrote:
> Personally I disagree here, openjdk-6 comes with a webplugin
> (icedtea6-plugin) that works very well for me.
---end quoted text---

I didn't know about that one, thanks for the tip !

--
‎أ*مد الم*مودي (Ahmed El-Mahmoudy)
Digital design engineer
GPG KeyID: 0xEDDDA1B7
GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100327033828.GA6290@ants.dhis.net">http://lists.debian.org/20100327033828.GA6290@ants.dhis.net


All times are GMT. The time now is 02:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.