On 08/04/2012 01:48 PM, Vincent Fourmond wrote:
> Hi,
>
> On Sat, Aug 4, 2012 at 4:37 PM, Damien Raude-Morvan
> wrote:
>>> Le 04/08/2012 09:59, Thomas Koch a écrit :
do you think we should change the java policy and relax the requirement
to
install java libraries to /usr/share/j
Hi,
On Sat, Aug 4, 2012 at 4:37 PM, Damien Raude-Morvan wrote:
>> Le 04/08/2012 09:59, Thomas Koch a écrit :
>>> do you think we should change the java policy and relax the requirement
>>> to
>>> install java libraries to /usr/share/java in favour of
>>> /usr/share/maven-repo?
>>>
>>> At least
Le 04/08/2012 10:10, Sylvestre Ledru a écrit :
Le 04/08/2012 09:59, Thomas Koch a écrit :
Hi,
do you think we should change the java policy and relax the requirement to
install java libraries to /usr/share/java in favour of /usr/share/maven-repo?
At least I'd like to see a very strong recommen
Le 04/08/2012 09:59, Thomas Koch a écrit :
> Hi,
>
> do you think we should change the java policy and relax the requirement to
> install java libraries to /usr/share/java in favour of /usr/share/maven-repo?
>
> At least I'd like to see a very strong recommends to install to /u/s/m-r. I
> feel li
On Sun Mar 21 15:31, Eric Lavarde wrote:
> Niels Thykier wrote:
>> Yes, I am guilty here. On a related note, does anyone know if the draft
>> [1] has been ratified or it is just a "proposed" change? If it is the
>> latter then lets get (the parts of) it (we want) approved so I can
>> integrate them
* Matthew Johnson <[EMAIL PROTECTED]> [2008-10-28 11:34]:
> On Tue Oct 28 11:15, Andrew Overholt wrote:
> > * Matthew Johnson <[EMAIL PROTECTED]> [2008-10-28 11:15]:
> > > I'm also still convinced we need to mandate the use of Class-Path:
> > > entries in manifests to avoid transitions in rdeps whe
On Tue Oct 28 11:15, Andrew Overholt wrote:
> * Matthew Johnson <[EMAIL PROTECTED]> [2008-10-28 11:15]:
> > I'm also still convinced we need to mandate the use of Class-Path:
> > entries in manifests to avoid transitions in rdeps when you update
> > your dependencies.
>
> This goes against the Fed
* Matthew Johnson <[EMAIL PROTECTED]> [2008-10-28 11:15]:
> I'm also still convinced we need to mandate the use of Class-Path:
> entries in manifests to avoid transitions in rdeps when you update
> your dependencies.
This goes against the Fedora and JPackage guidelines, FWIW.
Andrew
--
To UNSU
On Tue Oct 28 14:19, Sylvestre Ledru wrote:
> > Wouldn't it make sense to "police" this? i.e. to state that all packages
> > should be explicitly compiled with 1.5 source/target unless they use 6's
> > features?
> It is a good idea. Some information are missing in the current Java
> Policy.
>
> A
Matthew Johnson wrote:
>- #363165 mentions the version number in jar names. The parallel with C
> libraries is .so name.
No, our version numbers are very different - they are upstream release
numbers, whereas sonames are ABI versions.
> When compiling the symlink is use and at
>
On Saturday May 26 2007, Andrew Haley wrote:
> [EMAIL PROTECTED] writes:
> > Hm. All this is a bit extreme. Even the Linux kernel changes its
> > API all the time and things are working okay.
>
> This really is grossly unfair to the kernel deveopers, who go to
> great lengths to avoid breaking t
Marcus Better writes:
> Andrew Haley wrote:
> > In my opinion, Java libraries without stable interfaces shouldn't be
> > deployed in free OSes.
>
> That's a nice goal but unfortunately the world is not so perfect,
> because users occasionally require new software with shiny new
> bells and
[EMAIL PROTECTED] writes:
> Quoting Andrew Haley <[EMAIL PROTECTED]>:
> > In my opinion, Java libraries without stable interfaces shouldn't be
> > deployed in free OSes. If they are to be used, you're going to have
> > to change the jar name, but even that may not work: if you use such a
> >
* Marcus Better:
> I think the Java policy needs to be tweaked to allow for multiple versions
> of the same library. The problem is much easier than for C libraries, since
> we don't have a dynamic linker, so the user is responsible for adding the
> correct library to the classpath.
Not quite tru
[EMAIL PROTECTED] wrote:
> I could not agree more. I assume you mean the packager needs to
> reference the right version of a library.
That too, but also the _user_ who runs third-party code using the library,
and needs to set the classpath.
> I actually have a question about that. What do we nee
Quoting Marcus Better <[EMAIL PROTECTED]>:
Andrew Haley wrote:
In my opinion, Java libraries without stable interfaces shouldn't be
deployed in free OSes.
That's a nice goal but unfortunately the world is not so perfect, because
users occasionally require new software with shiny new bells and
Andrew Haley wrote:
> In my opinion, Java libraries without stable interfaces shouldn't be
> deployed in free OSes.
That's a nice goal but unfortunately the world is not so perfect, because
users occasionally require new software with shiny new bells and whistles.
Besides we cannot control upstrea
Quoting Andrew Haley <[EMAIL PROTECTED]>:
Mike Hommey writes:
> I have a java library package, called libmozillainterfaces-java,
> that is provided by xulrunner. I'm currently working on a new
> upstream release of xulrunner which changed the java interfaces:
> some interfaces changed names
Mike Hommey writes:
> I have a java library package, called libmozillainterfaces-java,
> that is provided by xulrunner. I'm currently working on a new
> upstream release of xulrunner which changed the java interfaces:
> some interfaces changed namespaces, so you have to do changes to
> your s
Matthias Klose wrote:
> Tom Marble writes:
>> Jeroen van Wolffelaar wrote:
>>> Currently, there is update-java-alternatives in java-common to manage
>>> the various java commands and how they refer to which implementation.
>>> People can however ignore it and update-alternatives themselves, things
Tom Marble writes:
> Jeroen van Wolffelaar wrote:
> > Currently, there is update-java-alternatives in java-common to manage
> > the various java commands and how they refer to which implementation.
> > People can however ignore it and update-alternatives themselves, things
> > can get out-of-sync,
Jeroen van Wolffelaar wrote:
> Currently, there is update-java-alternatives in java-common to manage
> the various java commands and how they refer to which implementation.
> People can however ignore it and update-alternatives themselves, things
> can get out-of-sync, and how to set priorities is
Jeroen van Wolffelaar writes:
> and how to set priorities is unclear and not easy to decide on.
IIRC that we decided on the priorities. See
http://lists.debian.org/debian-java/2006/05/threads.html
> In the current Debian Java policy, java libraries are required to
> properly document how to modif
Pierre Métras writes:
> > Wolfgang Baer wrote:
> > [...]
> > > Beside that I recognize the value a Java Developer Guide could have.
>
> > I definitely agree, many thanks Pierre for volunteer :-D
>
> OK, I volunteer but I'll start small, improving the wiki content when I find
> some time.
> Wolfgang Baer wrote:
> [...]
> > Beside that I recognize the value a Java Developer Guide could have.
> I definitely agree, many thanks Pierre for volunteer :-D
OK, I volunteer but I'll start small, improving the wiki content when I find
some time...
Perhaps my thought has been mis-interprete
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Hawkins wrote:
> Hope that helps,
A lot, thanks.
- --
.''`.
: :' :rnaud
`. `'
`-
Java Trap: http://www.gnu.org/philosophy/java-trap.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wolfgang Baer wrote:
[...]
> Beside that I recognize the value a Java Developer Guide could have.
I definitely agree, many thanks Pierre for volunteer :-D
- --
.''`.
: :' :rnaud
`. `'
`-
Java Trap: http://www.gnu.org/philosophy/java-trap.html
On Thu, Mar 09, 2006 at 09:28:36PM +0100, Arnaud Vandyck wrote:
[...]
> [EMAIL PROTECTED] wrote:
[...]
> > Just my 5 cents: the policy about javadoc doesn't say where the javadoc
> > should be registered in doc-base. I would suggest something like
> > Programming/Java, in order to avoid have link
Hi,
Arnaud Vandyck wrote:
> Pierre Métras wrote:
>
>>>Hello list,
>
>
> Salut Pierre,
>
>
>>>Having read the new Draft page, read again another time many pages on the
>>>wiki, in the Java FAQ and in the Java Policy, the java-common bugs, I still
>>>stay with the feeling that there is no cle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pierre Métras wrote:
> Hello list,
Salut Pierre,
> Having read the new Draft page, read again another time many pages on the
> wiki, in the Java FAQ and in the Java Policy, the java-common bugs, I still
> stay with the feeling that there is no clea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
> Hi,
>
>>>I just finished reading http://wiki.debian.org/Java/Draft
>>
>>Me too. :-)
>
> Yep.
>
> Just my 5 cents: the policy about javadoc doesn't say where the javadoc
> should be registered in doc-base. I would suggest s
Hello list,
Having read the new Draft page, read again another time many pages on the
wiki, in the Java FAQ and in the Java Policy, the java-common bugs, I still
stay with the feeling that there is no clear roadmap for Java in Debian,
beginning with the Java Policy.
Information is available, h
Hi,
>> I just finished reading http://wiki.debian.org/Java/Draft
>
> Me too. :-)
Yep.
Just my 5 cents: the policy about javadoc doesn't say where the javadoc
should be registered in doc-base. I would suggest something like
Programming/Java, in order to avoid have links all over the place in dhelp
Hi You,
Sanghyeon Seo wrote:
I just finished reading http://wiki.debian.org/Java/Draft
Me too. :-)
Some comments:
[Virtual packages]
Please define, what it means to provide a virtual package. From the
context of the document, the only *garantee* this provides makes is "you
can develop java
Andrew Haley writes:
> Re debugging info -- I put this patch into ecj on Fedora:
>
> https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg00086.html
>
> This patch means that no matter what broken debug options are in Ant
> scripts, every Java program in an RPM has full de
Re debugging info -- I put this patch into ecj on Fedora:
https://www.redhat.com/archives/fedora-devel-java-list/2006-January/msg00086.html
This patch means that no matter what broken debug options are in Ant
scripts, every Java program in an RPM has full debuginfo.
Essentially, this turns a rule
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mon, 25 Apr 2005 12:18:48 -0300,
Martin Ferrari - DECIDIR Argentina <[EMAIL PROTECTED]> wrote:
> I would want to know if
> http://www.debian.org/doc/packaging-manuals/java-policy/ is still
> authoritative and if there is some repository of documenta
?
> -Original Message-
> From: Barry Hawkins [mailto:[EMAIL PROTECTED]
> Sent: Lunes, 25 de Abril de 2005 12:57 p.m.
> To: [EMAIL PROTECTED]
> Cc: debian-java@lists.debian.org
> Subject: Re: java policy
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Ferrari - DECIDIR Argentina wrote:
> I would want to know if
> http://www.debian.org/doc/packaging-manuals/java-policy/ is still
> authoritative and if there is some repository of documentation for
> debian-java. I'm still confused about what is
Sat, 20 Nov 2004 21:46:38 -0800,
Shyamal Prasad <[EMAIL PROTECTED]> wrote:
> "Shyamal" == Shyamal Prasad <[EMAIL PROTECTED]> writes:
>
> "Arnaud" == Arnaud Vandyck <[EMAIL PROTECTED]> writes:
>
> Arnaud> I'm not sure beanshell needs tools.jar.
>
> Shyamal> The Emacs JDEE tries re
"Shyamal" == Shyamal Prasad <[EMAIL PROTECTED]> writes:
"Arnaud" == Arnaud Vandyck <[EMAIL PROTECTED]> writes:
Arnaud> I'm not sure beanshell needs tools.jar.
Shyamal> The Emacs JDEE tries really hard to find tools.jar to
Shyamal> start beanshell
Shyamal> [...]
Shya
"Arnaud" == Arnaud Vandyck <[EMAIL PROTECTED]> writes:
Arnaud> I'm not sure beanshell needs tools.jar.
The Emacs JDEE tries really hard to find tools.jar to start beanshell
(including special code to deal with the Apple/Darwin file naming). I
don't know if that is because very few people
Joerg Wendland wrote:
Barry Hawkins, on 2004-11-17, 09:29, you wrote:
That's what I have been doing, I just don't know if that's how we want
the Eclipse 3 package to work. Is that what other Java applications
that need JAVA_HOME are doing? It seems a bit of a kludge, but that
could be my inexp
Barry Hawkins, on 2004-11-17, 09:29, you wrote:
> That's what I have been doing, I just don't know if that's how we want
> the Eclipse 3 package to work. Is that what other Java applications
> that need JAVA_HOME are doing? It seems a bit of a kludge, but that
> could be my inexperience with Debi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Upayavira wrote:
| Barry Hawkins wrote:
[...]
|> Many thanks for the reply and the links; I will read those. I can see
|> where the policy is going, I just wonder how practical it is. If I am
|> not mistaken, the Eclipse executable also depends upon J
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tue, 16 Nov 2004 13:13:22 -0800,
Shyamal Prasad <[EMAIL PROTECTED]> wrote:
> Will do. But I'm just trying to see how to get JDE to work when
> JAVA_HOME is not set ;-)
If you can, please, post. I really like JDE but I can't use completion
with bean
Barry Hawkins wrote:
Shyamal Prasad wrote:
[...]
| Debian executables "must not depend on environment variables to get
| reasonable defaults" is the actual statement.
[...]
| You can't require that a user sets JAVA_HOME for a default
| installation of a java application to run in a reasonable
| man
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shyamal Prasad wrote:
[...]
| Debian executables "must not depend on environment variables to get
| reasonable defaults" is the actual statement.
[...]
| You can't require that a user sets JAVA_HOME for a default
| installation of a java application to
Barry> Shyamal Prasad wrote:
>| I just noticed that both JDE versions in Debian (jde and
>| xemacs21-basesupport) are partially broken: if you don't set
>| JAVA_HOME (which is not allowed by Debian policy) some of the
>| most useful tools don't work.
Barry> This is news t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shyamal Prasad wrote:
[...]
| I just noticed that both JDE versions in Debian (jde and
| xemacs21-basesupport) are partially broken: if you don't set JAVA_HOME
| (which is not allowed by Debian policy) some of the most useful tools
| don't work.
[...]
T
"Arnaud" == Arnaud Vandyck <[EMAIL PROTECTED]> writes:
Arnaud> Mon, 15 Nov 2004 21:42:49 -0800, Shyamal Prasad
Arnaud> <[EMAIL PROTECTED]> wrote:
>> I do not do any Java development anymore, and I've only ever
>> used Blackdown on Debian, so any input would help.
Arnaud>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mon, 15 Nov 2004 21:42:49 -0800,
Shyamal Prasad <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a system that is installed according to the Debian policy
> documents (including Java policy). On this system I am trying to find
> the "base Java directory"
Ola Lundqvist <[EMAIL PROTECTED]> wrote:
> Hello
>
> On Mon, Jun 30, 2003 at 11:40:20PM +0200, Arnaud Vandyck wrote:
[...]
> > According to the Debian policy[1], I think I do not need. I also did
> > not find anything in the java-policy...
>
> Java packages do not differ from "normal" packages. S
Ola Lundqvist <[EMAIL PROTECTED]> wrote:
> Hello
>
> On Mon, Jun 30, 2003 at 11:40:20PM +0200, Arnaud Vandyck wrote:
[...]
> > According to the Debian policy[1], I think I do not need. I also did
> > not find anything in the java-policy...
>
> Java packages do not differ from "normal" packages. S
Hello
On Mon, Jun 30, 2003 at 11:40:20PM +0200, Arnaud Vandyck wrote:
> Hi!
>
> I'm packaging fileupload and other small librairies from jakarta-commons
> and I was wondering if I have to make a separate documentation (api)
> package for such small packages?
>
> According to the Debian pol
Hello
On Mon, Jun 30, 2003 at 11:40:20PM +0200, Arnaud Vandyck wrote:
> Hi!
>
> I'm packaging fileupload and other small librairies from jakarta-commons
> and I was wondering if I have to make a separate documentation (api)
> package for such small packages?
>
> According to the Debian pol
> "Alex" == T Alexander Popiel <[EMAIL PROTECTED]> writes:
>>> I havent tried any other jvm. Java profilers are coded according to the
>>> jvmpi specification.
>>> http://java.sun.com/j2se/1.4.1/docs/guide/jvmpi/jvmpi.html
Alex> You might want to try gij, too... the other jvm in debian main
In message: <[EMAIL PROTECTED]>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
>> Jmp works well with the jvms from sun(1.3.x, 1.4.x), blackdown (1.3.x,
>> most probably 1.4.x) and ibm (1.3.x).
>> I havent tried any other jvm. Java profilers are coded according to the
>> jvmpi specifica
> "Alex" == T Alexander Popiel <[EMAIL PROTECTED]> writes:
>>> I havent tried any other jvm. Java profilers are coded according to the
>>> jvmpi specification.
>>> http://java.sun.com/j2se/1.4.1/docs/guide/jvmpi/jvmpi.html
Alex> You might want to try gij, too... the other jvm in debian main
In message: <[EMAIL PROTECTED]>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
>> Jmp works well with the jvms from sun(1.3.x, 1.4.x), blackdown (1.3.x,
>> most probably 1.4.x) and ibm (1.3.x).
>> I havent tried any other jvm. Java profilers are coded according to the
>> jvmpi specific
On Mon, Sep 16, 2002 at 10:00:22PM +0200, Robert Olofsson wrote:
> Ola Lundqvist wrote:
>
> >>I currently develop jmp (http://www.khelekore.org/jmp/) a java profiler.
> >>Java profilers are written in C/C++ and compiled to shared libraries,
> >>libjmp.so for jmp. Many profilers today have a java
On Mon, Sep 16, 2002 at 10:00:22PM +0200, Robert Olofsson wrote:
> Ola Lundqvist wrote:
>
> >>I currently develop jmp (http://www.khelekore.org/jmp/) a java profiler.
> >>Java profilers are written in C/C++ and compiled to shared libraries,
> >>libjmp.so for jmp. Many profilers today have a java
Ola Lundqvist wrote:
I currently develop jmp (http://www.khelekore.org/jmp/) a java profiler.
Java profilers are written in C/C++ and compiled to shared libraries,
libjmp.so for jmp. Many profilers today have a java front end, jmp does
not (it uses a gtk front end).
What exactly is a java pr
Hi
On Sun, Sep 15, 2002 at 01:56:01PM +0200, Robert Olofsson wrote:
> Hello!
>
> I read http://www.debian.org/doc/packaging-manuals/java-policy/
> There is one thing that I cant find covered by that policy.
Hmm ok.
> I currently develop jmp (http://www.khelekore.org/jmp/) a java profiler.
> Jav
This sounds reasonable. Could you file a wishlist bug against
java-common with this? It would really be nice.
Regards,
// Ola
On Mon, Sep 02, 2002 at 11:53:30AM -0700, Per Bothner wrote:
> gcj also by default searches in jars in /usr/share/java/ext.
> The policy could add in 2.4:
>
> Java libr
This sounds reasonable. Could you file a wishlist bug against
java-common with this? It would really be nice.
Regards,
// Ola
On Mon, Sep 02, 2002 at 11:53:30AM -0700, Per Bothner wrote:
> gcj also by default searches in jars in /usr/share/java/ext.
> The policy could add in 2.4:
>
> Java lib
gcj also by default searches in jars in /usr/share/java/ext.
The policy could add in 2.4:
Java libraries packages *may* add a sympolic link from
/usr/share/java/ext/packagename[-extraname].jar to
/usr/share/java/packagename[-extraname]-fullversion.jar.
In 2.1 Virtual machines:
If a virtual mach
gcj also by default searches in jars in /usr/share/java/ext.
The policy could add in 2.4:
Java libraries packages *may* add a sympolic link from
/usr/share/java/ext/packagename[-extraname].jar to
/usr/share/java/packagename[-extraname]-fullversion.jar.
In 2.1 Virtual machines:
If a virt
Hi again.
I have not seen very much complains on the policy. Actually none
on fact.
So what further steps should I take in order to make this an
official policy?
On Sat, Aug 31, 2002 at 01:56:15PM +0200, Robert Bihlmeyer wrote:
> Ola Lundqvist <[EMAIL PROTECTED]> writes:
>
> > There are some th
Hi again.
I have not seen very much complains on the policy. Actually none
on fact.
So what further steps should I take in order to make this an
official policy?
On Sat, Aug 31, 2002 at 01:56:15PM +0200, Robert Bihlmeyer wrote:
> Ola Lundqvist <[EMAIL PROTECTED]> writes:
>
> > There are some t
Ola Lundqvist <[EMAIL PROTECTED]> writes:
> There are some things that might want to be added before it
> becomes truly official.
>
> See the policy at:
> http://www.debian.org/doc/packaging-manuals/java-policy/
>
> * gcj and how to handle that (should it be mentioned at all?).
I don't have the
Ola Lundqvist <[EMAIL PROTECTED]> writes:
> There are some things that might want to be added before it
> becomes truly official.
>
> See the policy at:
> http://www.debian.org/doc/packaging-manuals/java-policy/
>
> * gcj and how to handle that (should it be mentioned at all?).
I don't have th
> "Grzegorz" == Grzegorz Prokopski <[EMAIL PROTECTED]> writes:
Grzegorz> Blackdown released 1.4.1 beta - it may be good time to
Grzegorz> give them strict advice on how they should prepare
Grzegorz> packages for Debian.
Updated j2se packages are making their slow way onto the Black
Some comments on what Conrad Wood sent to me.
On Sun, May 26, 2002 at 10:14:06PM +0100, Conrad Wood wrote:
> The current java policy does not appear to discuss many of the
> useful tools that come with the jdk from sun. ie javadoc, keygen, jdb
> and so forth. No mentioning on how that should be ha
Some comments on what Conrad Wood sent to me.
On Sun, May 26, 2002 at 10:14:06PM +0100, Conrad Wood wrote:
> The current java policy does not appear to discuss many of the
> useful tools that come with the jdk from sun. ie javadoc, keygen, jdb
> and so forth. No mentioning on how that should be h
On Wed, May 15, 2002 at 10:09:14PM -0700, T. Alexander Popiel wrote:
*SNIP* (my own things)
> I'm rather new with debian, and don't know much about debian
> packaging. As such, I may be misinterpreting some of the
> references in the Policy... but some things seem a tad off
> to me.
>
> Other pe
On Wed, May 15, 2002 at 10:09:14PM -0700, T. Alexander Popiel wrote:
*SNIP* (my own things)
> I'm rather new with debian, and don't know much about debian
> packaging. As such, I may be misinterpreting some of the
> references in the Policy... but some things seem a tad off
> to me.
>
> Other p
Does any existing linux-java group working on porting the complete API
from SUN?
The question I have is always down to what standard can we counting on.
If you pick
out the "Good" API from SUN and will that still being too "Large" for us
to bite it off.
I have a couple different VMs, different v
Does any existing linux-java group working on porting the complete API
from SUN?
The question I have is always down to what standard can we counting on.
If you pick
out the "Good" API from SUN and will that still being too "Large" for us
to bite it off.
I have a couple different VMs, different
itz> If you permit an outsider to intrude... :)
Ola> What did you mean with this?
Java is not my cup of tea (coffee?), or at least hasn't been up to
now. I am interested in it, but I really don't like the
incompatibility of diverse JVMs and consequent uncertainty about
dependencies (and even f
itz> If you permit an outsider to intrude... :)
Ola> What did you mean with this?
Java is not my cup of tea (coffee?), or at least hasn't been up to
now. I am interested in it, but I really don't like the
incompatibility of diverse JVMs and consequent uncertainty about
dependencies (and even
On Mon, May 13, 2002 at 01:07:07PM -0700, Ian Zimmerman wrote:
> Why must all lib*-java packages depend on java-virtual-machine? gcj
> is supposed to be able to compile class files into native code, isn't
> it? So these class libraries are, in theory, usable by people who
> just use them for gcj
On Mon, May 13, 2002 at 01:07:07PM -0700, Ian Zimmerman wrote:
>
> Andrew> Both are shipped as Java bytecode (*.class files, packaged in
> Andrew> a *.jar archive) and with an "Architecture: all" since Java
> Andrew> bytecode is supposed to be portable.
>
> Andrew> seems to forbid both code with
On Mon, May 13, 2002 at 04:51:02PM -0600, Tom Tromey wrote:
> > "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
>
> Andrew> seems to forbid both code with native parts, and Java code
> Andrew> compiled to machine binaries with gcj. It seems reasonable to
> Andrew> me to allow both of t
On Mon, May 13, 2002 at 01:07:07PM -0700, Ian Zimmerman wrote:
> Why must all lib*-java packages depend on java-virtual-machine? gcj
> is supposed to be able to compile class files into native code, isn't
> it? So these class libraries are, in theory, usable by people who
> just use them for gcj
On Mon, May 13, 2002 at 01:07:07PM -0700, Ian Zimmerman wrote:
>
> Andrew> Both are shipped as Java bytecode (*.class files, packaged in
> Andrew> a *.jar archive) and with an "Architecture: all" since Java
> Andrew> bytecode is supposed to be portable.
>
> Andrew> seems to forbid both code with
On Mon, May 13, 2002 at 04:51:02PM -0600, Tom Tromey wrote:
> > "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
>
> Andrew> seems to forbid both code with native parts, and Java code
> Andrew> compiled to machine binaries with gcj. It seems reasonable to
> Andrew> me to allow both of
> 3. Netscape: The BIG MYSTERY. Why does 4.7x still ship with
> JRE 1.1?!! Who even controls NS nowadays, Time Warner/
> AOL? (Translate as -- who do we bug to get this fixed?)
> Does Sun have some influence with Netscape? If so, why
> do they permit 4.7x to at
David Jardine wrote:
>
> > 2. Drop all Sun-deprecated classes and methods; conform only to the
> >latest non-deprecated version of an API spec
>
> But wouldn't a lot of browsers out there be unable to handle
> some of the "newer" things?
Browsers have been stuck at JRE 1.1 for years. Time t
> "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
Andrew> seems to forbid both code with native parts, and Java code
Andrew> compiled to machine binaries with gcj. It seems reasonable to
Andrew> me to allow both of these.
Does this really need to be part of the java policy? I thought
> 3. Netscape: The BIG MYSTERY. Why does 4.7x still ship with
> JRE 1.1?!! Who even controls NS nowadays, Time Warner/
> AOL? (Translate as -- who do we bug to get this fixed?)
> Does Sun have some influence with Netscape? If so, why
> do they permit 4.7x to a
David Jardine wrote:
>
> > 2. Drop all Sun-deprecated classes and methods; conform only to the
> >latest non-deprecated version of an API spec
>
> But wouldn't a lot of browsers out there be unable to handle
> some of the "newer" things?
Browsers have been stuck at JRE 1.1 for years. Time
> "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
Andrew> seems to forbid both code with native parts, and Java code
Andrew> compiled to machine binaries with gcj. It seems reasonable to
Andrew> me to allow both of these.
Does this really need to be part of the java policy? I though
Andrew> Both are shipped as Java bytecode (*.class files, packaged in
Andrew> a *.jar archive) and with an "Architecture: all" since Java
Andrew> bytecode is supposed to be portable.
Andrew> seems to forbid both code with native parts, and Java code
Andrew> compiled to machine binaries with gcj.
On Mon, May 13, 2002 at 09:21:00AM -0500, Rick Lutowski wrote:
> 2. Drop all Sun-deprecated classes and methods; conform only to the
>latest non-deprecated version of an API spec
But wouldn't a lot of browsers out there be unable to handle
some of the "newer" things?
David
--
To UNSUBSCR
Andrew> Both are shipped as Java bytecode (*.class files, packaged in
Andrew> a *.jar archive) and with an "Architecture: all" since Java
Andrew> bytecode is supposed to be portable.
Andrew> seems to forbid both code with native parts, and Java code
Andrew> compiled to machine binaries with gcj.
On Mon, May 13, 2002 at 09:21:00AM -0500, Rick Lutowski wrote:
> 2. Drop all Sun-deprecated classes and methods; conform only to the
>latest non-deprecated version of an API spec
But wouldn't a lot of browsers out there be unable to handle
some of the "newer" things?
David
--
To UNSUBSC
On Mon, May 13, 2002 at 02:25:22PM +0100, Geoff Beaumont wrote:
> On Sun, 2002-05-12 at 21:05, Egon Willighagen wrote:
> > On Sunday 12 May 2002 21:32, Ola Lundqvist wrote:
> > > Well. It is even better to remove this paragraph entirelly. It is clearly
> > > stated in the normal debian policy.
> >
Jim Pick wrote:
>
> Because the set of Java APIs is so large, trying to develop a set of
> class libraries that works as a drop in replacement for Sun's libraries
> is a very large task. In reality, it's going to be a long time before
> the free java class library projects manage to reimplement 1
On Sun, May 12, 2002 at 09:15:31PM -0700, Jim Pick wrote:
> I think the Debian Java policy, as currently stated, is slightly flawed,
> as it tries to satisfy two goals that aren't completely orthogonal:
>
> 1) To get as much free Java software into Debian as possible, that runs
> without non-
1 - 100 of 200 matches
Mail list logo
