In message: <[EMAIL PROTECTED]>
Alexander Schmehl <[EMAIL PROTECTED]> writes:
>
>on the Debian booth at the Linux World Exposition in Frankfurt /
>Germany, we had a visitor, whome you might find interessting.
>
>He offered 5000 Euro for an "satisfying sollution for Java in Debian".
>
In message: <[EMAIL PROTECTED]>
"Marco Bresciani" <[EMAIL PROTECTED]> writes:
>Messaggio di Michael Borko del 16/12/2003:
>
>> hi!
>
>Oops... I've forgot something. :-) Sun releases the .bin file for Linux
>of its J2SDK. Does it work on Debian?!
Yes, though you have to install a spe
In message: <[EMAIL PROTECTED]>
Jan Schulz <[EMAIL PROTECTED]> writes:
>Hallo Hubert,
>
>* Hubert Schmid wrote:
>>the package also be called 'mpkg-j2se'?
>
>BTW: what does "2se stand for?"
J2SE stands for Java2 Standard Edition in Sun-speak. Similarly,
J2EE is Java2 Enterprise Edit
In message: <[EMAIL PROTECTED]>
Dalibor Topic <[EMAIL PROTECTED]> writes:
>Hi Alexander,
>
>T. Alexander Popiel wrote:
>
>> I have not found any documented way of replacing the parser version.
>> Mangling bootclasspath to do it isn't docume
In message: <[EMAIL PROTECTED]>
Jan Schulz <[EMAIL PROTECTED]> writes:
[a minor rant about how there's not much progress on Java in Debian]
I don't anything particularly useful to reply to the points that Jan
makes, largely because I've given up on Java per se as part of Debian.
The
In message: <[EMAIL PROTECTED]>
Dalibor Topic <[EMAIL PROTECTED]> writes:
>T. Alexander Popiel wrote:
>> In message: <[EMAIL PROTECTED]>
>> Dalibor Topic <[EMAIL PROTECTED]> writes:
>>
>>>Things like -bootclassp
In message: <[EMAIL PROTECTED]>
Dalibor Topic <[EMAIL PROTECTED]> writes:
>
>Things like -bootclasspath are only used by broken by design
>applications, anyway. It's -X*bootclasspath nowadays with Sun's VM, and
>it's there for a single reason: debugging. Applications have no
>buisi
In message: <[EMAIL PROTECTED]>
Ean Schuessler <[EMAIL PROTECTED]> writes:
>I still don't like the findjava idea. What is the goal? It looks like
>this script provides a common interface to all of the java execution
>systems (compilers, JITs, interpreters or otherwise) by concentrati
In message: <[EMAIL PROTECTED]>
Ean Schuessler <[EMAIL PROTECTED]> writes:
>I still don't like the findjava idea. What is the goal? It looks like
>this script provides a common interface to all of the java execution
>systems (compilers, JITs, interpreters or otherwise) by concentrati
In message: <[EMAIL PROTECTED]>
"T. Alexander Popiel" <[EMAIL PROTECTED]> writes:
>
>Inserting and/or modifying does get complex; shift and unshift
>and modifying IFS quickly become instrumental.
That should be '...shift and set and modifying...&
In message: <[EMAIL PROTECTED]>
Ben Burton <[EMAIL PROTECTED]> writes:
>
>> FWIW, the black magic is "$*" (including the quotes).
>
>Do you mean "$@"? If so, this (and "$*") become somewhat more
>troublesome when you need to modify command-line arguments or insert
>your own.
Yes, I
In message: <[EMAIL PROTECTED]>
"T. Alexander Popiel" <[EMAIL PROTECTED]> writes:
>
>Inserting and/or modifying does get complex; shift and unshift
>and modifying IFS quickly become instrumental.
That should be '...shift and set and modifying...&
In message: <[EMAIL PROTECTED]>
Ben Burton <[EMAIL PROTECTED]> writes:
>
>> FWIW, the black magic is "$*" (including the quotes).
>
>Do you mean "$@"? If so, this (and "$*") become somewhat more
>troublesome when you need to modify command-line arguments or insert
>your own.
Yes, I
In message: <[EMAIL PROTECTED]>
Ben Burton <[EMAIL PROTECTED]> writes:
>
>[...] some piece of sh black magic
>that gets the quotes right and separates arguments - some of which
>may contain spaces - at exactly the right places [1]).
FWIW, the black magic is "$*" (including the quotes
In message: <[EMAIL PROTECTED]>
Ben Burton <[EMAIL PROTECTED]> writes:
>
>[...] some piece of sh black magic
>that gets the quotes right and separates arguments - some of which
>may contain spaces - at exactly the right places [1]).
FWIW, the black magic is "$*" (including the quotes
In message: <[EMAIL PROTECTED]>
Jan Schulz <[EMAIL PROTECTED]> writes:
>* Matt Zimmerman wrote:
>
>>I like some of the ideas in your proposal, but things like "Java Runtime
>>Environments, which are complient to the Java Spec of a specific Version,
>>have to provide the virtual packag
In message: <[EMAIL PROTECTED]>
Jan Schulz <[EMAIL PROTECTED]> writes:
>* Matt Zimmerman wrote:
>
>>I like some of the ideas in your proposal, but things like "Java Runtime
>>Environments, which are complient to the Java Spec of a specific Version,
>>have to provide the virtual packag
In message: <[EMAIL PROTECTED]>
Daniel Bonniot <[EMAIL PROTECTED]> writes:
>
>>>I would think that java2 is a superset of java1.
>>
>>Unfortunately, this is not the case; the deprecation of methods and
>>classes make java2 an intersecting set, not a superset of java1.
>
>Deprecated fe
In message: <[EMAIL PROTECTED]>
Daniel Bonniot <[EMAIL PROTECTED]> writes:
>
>>>I would think that java2 is a superset of java1.
>>
>>Unfortunately, this is not the case; the deprecation of methods and
>>classes make java2 an intersecting set, not a superset of java1.
>
>Deprecated fe
In message: <[EMAIL PROTECTED]>
Daniel Bonniot <[EMAIL PROTECTED]> writes:
>I would think that java2 is a superset of java1.
Unfortunately, this is not the case; the deprecation of methods and
classes make java2 an intersecting set, not a superset of java1.
>I propose the following
In message: <[EMAIL PROTECTED]>
Daniel Bonniot <[EMAIL PROTECTED]> writes:
>I would think that java2 is a superset of java1.
Unfortunately, this is not the case; the deprecation of methods and
classes make java2 an intersecting set, not a superset of java1.
>I propose the following
In message: <[EMAIL PROTECTED]>
Ben Burton <[EMAIL PROTECTED]> writes:
>
>> I agree with this. IMO a java jar should be handled the same as a
>> binary lib ad should get API Version (~SONAME) included in its name.
>
>The problem is that many java libraries don't have a concept of an A
In message: <[EMAIL PROTECTED]>
Ben Burton <[EMAIL PROTECTED]> writes:
>
>> I agree with this. IMO a java jar should be handled the same as a
>> binary lib ad should get API Version (~SONAME) included in its name.
>
>The problem is that many java libraries don't have a concept of an A
In message: <[EMAIL PROTECTED]>
Stefan Gybas <[EMAIL PROTECTED]> writes:
>
>Should Java programs or libraries that use a versioned JAR from another
>Java library have a versioned package dependency on this libraray? E.g.
>if I use the current /usr/share/java/xalan-2.5.0.jar in my pa
In message: <[EMAIL PROTECTED]>
Stefan Gybas <[EMAIL PROTECTED]> writes:
>
>Should Java programs or libraries that use a versioned JAR from another
>Java library have a versioned package dependency on this libraray? E.g.
>if I use the current /usr/share/java/xalan-2.5.0.jar in my pa
In message: <[EMAIL PROTECTED]>
Matt Zimmerman <[EMAIL PROTECTED]> writes:
>On Mon, Jun 02, 2003 at 07:54:38PM +0200, Juergen Kreileder wrote:
>
>> [EMAIL PROTECTED] writes:
>> > cat > Test.java << EOF
>> > class Test {
>> > public static void main(String[] args) {
>> >
In message: <[EMAIL PROTECTED]>
Matt Zimmerman <[EMAIL PROTECTED]> writes:
>On Mon, Jun 02, 2003 at 07:54:38PM +0200, Juergen Kreileder wrote:
>
>> [EMAIL PROTECTED] writes:
>> > cat > Test.java << EOF
>> > class Test {
>> > public static void main(String[] args) {
>> >
In message: <[EMAIL PROTECTED]>
Hubert Schmid <[EMAIL PROTECTED]> writes:
>On Sat, 31 May 2003, T. Alexander Popiel wrote:
>
>> I don't think you can have a package both provide and conflict with
>> the same thing (j2re).
>
>It works and is o
In message: <[EMAIL PROTECTED]>
Hubert Schmid <[EMAIL PROTECTED]> writes:
>On Sat, 31 May 2003, T. Alexander Popiel wrote:
>
>> I don't think you can have a package both provide and conflict with
>> the same thing (j2re).
>
>It works and is o
In message: <[EMAIL PROTECTED]>
Hubert Schmid <[EMAIL PROTECTED]> writes:
>On Sat, 31 May 2003, Jan Schulz wrote:
>
> - the 'blackdown way': four packages are created from the binary Java2
> SDK:
[...]
> - or build different packages from the Java2 RE and the Java2 SDK binary
> ar
In message: <[EMAIL PROTECTED]>
Hubert Schmid <[EMAIL PROTECTED]> writes:
>On Sat, 31 May 2003, Jan Schulz wrote:
>
> - the 'blackdown way': four packages are created from the binary Java2
> SDK:
[...]
> - or build different packages from the Java2 RE and the Java2 SDK binary
> ar
In message: <[EMAIL PROTECTED]>
Keegan Quinn <[EMAIL PROTECTED]> writes:
>On Saturday 05 April 2003 05:58 pm, Juan Alvarez wrote:
>> Looking to the debian meta-packages, I show the following packages:
>>
>> java-compiler
>> java2-compiler
>>
>> java1-runtime
>> java2-runtime
>>
>> Why
In message: <[EMAIL PROTECTED]>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
>Hello
>
>On Wed, Feb 26, 2003 at 08:16:01AM -0800, T. Alexander Popiel wrote:
>> In message: <[EMAIL PROTECTED]>
>> Ola Lundqvist <[EMAIL PROTECTED]>
In message: <[EMAIL PROTECTED]>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
>Hello
>
>On Wed, Feb 26, 2003 at 08:16:01AM -0800, T. Alexander Popiel wrote:
>> In message: <[EMAIL PROTECTED]>
>> Ola Lundqvist <[EMAIL PROTECTED]>
In message: <[EMAIL PROTECTED]>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
>
>Hi
>
>Well there seems to be some vauge statements in the policy. I assumed
>that blackdown should present both java1-runtime _and_ java2-runtime
>becuse it can fulfill both runtime requirements (in reasonabl
In message: <[EMAIL PROTECTED]>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
>
>Hi
>
>Well there seems to be some vauge statements in the policy. I assumed
>that blackdown should present both java1-runtime _and_ java2-runtime
>becuse it can fulfill both runtime requirements (in reasonabl
In message: <[EMAIL PROTECTED]>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
>
>> If AWT / GUI stuff is a particular problem (which is my understanding),
>> I think it would make sense to define virtual packages java1-awt-runtime
>> (and possibly java2-swing-runtime).
>
>This is not a ba
In message: <[EMAIL PROTECTED]>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
>
>> If AWT / GUI stuff is a particular problem (which is my understanding),
>> I think it would make sense to define virtual packages java1-awt-runtime
>> (and possibly java2-swing-runtime).
>
>This is not a ba
In message: <[EMAIL PROTECTED]>
Mark Howard <[EMAIL PROTECTED]> writes:
[on creating custom tasks for ant]
>When you say frequently, how often do you mean. I personally have never
>had to extend ant (and so never needed the api).
It really depends on what you're doing. If all you
In message: <[EMAIL PROTECTED]>
Mark Howard <[EMAIL PROTECTED]> writes:
[on creating custom tasks for ant]
>When you say frequently, how often do you mean. I personally have never
>had to extend ant (and so never needed the api).
It really depends on what you're doing. If all you
In message: <[EMAIL PROTECTED]>
Mark Howard <[EMAIL PROTECTED]> writes:
>Hi,
> I've just noticed that the user documentation package for ant (a tool,
>not a library) contains 15 MB of API references. I've since filed bug
>#174876 asking for this to be removed.
Sadly, having the API
In message: <[EMAIL PROTECTED]>
Mark Howard <[EMAIL PROTECTED]> writes:
>Hi,
> I've just noticed that the user documentation package for ant (a tool,
>not a library) contains 15 MB of API references. I've since filed bug
>#174876 asking for this to be removed.
Sadly, having the API
In message: <[EMAIL PROTECTED]>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
>On Sun, Oct 06, 2002 at 05:12:39PM +0200, Robert Bihlmeyer wrote:
>> As policy requires that all "binaries" (well, it's debatable whether
>> class files fall under this) should be built with debug info and
>> s
In message: <[EMAIL PROTECTED]>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
>On Sun, Oct 06, 2002 at 05:12:39PM +0200, Robert Bihlmeyer wrote:
>> As policy requires that all "binaries" (well, it's debatable whether
>> class files fall under this) should be built with debug info and
>>
In message: <[EMAIL PROTECTED]>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
>On Fri, Oct 04, 2002 at 02:19:17PM +0100, Mark Howard wrote:
>
>> - Generated output is standard java bytecode [as defined by ...??] and
>> stored in files of the form MyClass$MyInnerClass.class.
>
>Do anyone k
In message: <[EMAIL PROTECTED]>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
>On Fri, Oct 04, 2002 at 02:19:17PM +0100, Mark Howard wrote:
>
>> - Generated output is standard java bytecode [as defined by ...??] and
>> stored in files of the form MyClass$MyInnerClass.class.
>
>Do anyone
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
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
In message: <[EMAIL PROTECTED]>
"rahil vinod talwar" <[EMAIL PROTECTED]> writes:
>com.ms.security.SecurityException[filename.paint]:java.IO.Exception
>: bad path : d:\jdk1.2.2\bin\java\awt\Graphics2D.class
>
>java.lang.ClassNotFoundException: java.awt.Graphics2D
Yes, Microsoft's IE
In message: <[EMAIL PROTECTED]>
Kenneth Pronovici <[EMAIL PROTECTED]> writes:
>
>I maintain libnbio-java, which is a JNI non-blocking socket IO package
>for Java. My current .deb is for upstream version 1.5. The upstream
>maintainer has just released version 2.0, and the only differ
In message: <[EMAIL PROTECTED]>
Kenneth Pronovici <[EMAIL PROTECTED]> writes:
>
>I maintain libnbio-java, which is a JNI non-blocking socket IO package
>for Java. My current .deb is for upstream version 1.5. The upstream
>maintainer has just released version 2.0, and the only diffe
In message: <[EMAIL PROTECTED]>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
>
>A perfect (?) solution would be to first search for
>things in your CLASSPATH and then /usr/share/java/*.jar, and if
>possible (or useful) search other places.
>This can give results like the following, which
In message: <[EMAIL PROTECTED]>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
>
>A perfect (?) solution would be to first search for
>things in your CLASSPATH and then /usr/share/java/*.jar, and if
>possible (or useful) search other places.
>This can give results like the following, whic
Here's a first draft of dh_javadeps and makejar. dh_javadeps
has absolutely no documentation as yet, but should do the 'right'
thing (adding appropriate substvars lines) if invoked without
arguments after the install tree(s) have been made. makejar
(the tool for building a jar file given a list o
Here's a first draft of dh_javadeps and makejar. dh_javadeps
has absolutely no documentation as yet, but should do the 'right'
thing (adding appropriate substvars lines) if invoked without
arguments after the install tree(s) have been made. makejar
(the tool for building a jar file given a list
In message: <[EMAIL PROTECTED]>
Andrew Pimlott <[EMAIL PROTECTED]> writes:
>On Sat, May 18, 2002 at 10:53:29AM -0700, T. Alexander Popiel wrote:
>> 5. Would it be useful to folks if I made available a second dh_java*
>>tool for taking a list of entry
In message: <[EMAIL PROTECTED]>
Andrew Pimlott <[EMAIL PROTECTED]> writes:
>On Sat, May 18, 2002 at 10:53:29AM -0700, T. Alexander Popiel wrote:
>> 5. Would it be useful to folks if I made available a second dh_java*
>>tool for taking a list of entry
This is mostly directed to Ola Lundqvist, but I figure that
getting other people's opinions can't hurt. ;-)
I've gotten all the debhelper scripts and I've been pawing
through them, learning. However, in the process, I've come
up with a couple more questions...
1. Should dh_javadeps only identify
This is mostly directed to Ola Lundqvist, but I figure that
getting other people's opinions can't hurt. ;-)
I've gotten all the debhelper scripts and I've been pawing
through them, learning. However, in the process, I've come
up with a couple more questions...
1. Should dh_javadeps only identif
59 matches
Mail list logo
