Re: any free JDKs not using jikes as compiler?

Andrew Vaughan wrote: Hi The subject line says it all. Anyone know of any free JDK packages not using jikes as a compiler? I don't. I've been investigating free java compilers recently, and unfortunately jikes really seemed like the only candidate as a drop-in javac replacement. This might chan

Re: gcj4 changes : Please Comment

2) There is a middle ground position which would be to provide natively compiled version of a few select applications. Eclipse comes immediately to my mind, Daniele mentioned Tomcat. The question is, to we want that for any single java library in Debian? If not, where do we draw the line? That is

Re: [dsi-list] Re: Looking for the right Java solution

Well then, I'll try to go my way using the free alternatives. Eventually I'll send in some feedback if something should not work as expected. That's the spirit! Thanks. Daniel -- The Nice programming language: http://nice.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsub

Re: gcj4 changes : Please Comment

I hear the arguments for providing natively compiled versions too. This looks like it's not going to be a clear cut choice. A few thoughts: 1) There is a kind of parallel with other languages in Debian. I think of at least python and emacs-lisp. If I understand correctly, modules in these langu

Re: gcj4 changes : Please Comment

Dan Weber wrote: The libraries should be built on the user's machine. This can be done via the postinst, and by and a debconf option to turn it off or on. It maybe a good idea to come up with a debconf script to automatically add it to your postinst. Dan I tend to agree. If we manage to handl

Re: Replacing packaged libraries with standard libraries

Hi Eric, that brought me a good step forward (js.jar part of rhino, how obvious! :> ). What you might be missing is the apt-file tool. It will help you find files in all packages available in your apt sources: $ apt-file search js.jar jmeter: usr/share/jmeter/lib/js.jar jmeter: usr/share/jmeter/

Re: apt and java

However I guess most Dabian users are in fact using the i386 version of Debian. (Are there any figures about that?) http://popcon.debian.org/ (middle of the page) Daniel -- The Nice programming language: http://nice.sf.net

Re: RFH: how to really assemble java packages

How many classes does libgnumail-java miss? It might be quite easy to at least include stub classes that would allow your app to be compiled with free tools. Well, compile would be ok, but how someone would run it? But to answer your question, I think at least 20 classes are missing, mostly com

Re: RFH: how to really assemble java packages

Laszlo 'GCS' Boszormenyi wrote: Parlez-vous Hongroise? Csok kicsit! No it doesn't, and it cannot for licensing reasons. I tought there is some kind of wrapper, which downloads SUN's J2SDK and installs it for the user; so Debian does not violates the license, still can support the users. I stand co

mpkg-j2se (was: Re: tomcat4 dependencies)

Ricky Clarkson wrote: I don't know whether this has reached testing or backports.org yet, but mpkg-j2se is another way to do this (formerly j2se-package). It's not in testing because it has an RC bug. #262196 is right: mpkg-j2se should be in contrib, not in main. Hubert or Takashi, could you fix t

Re: RFH: how to really assemble java packages

Szia Laszlo! I read the Java policy, but I has not became more wise. Say, I have a complex application, which licensed under GPL v2. But it does not compile with free tools. The JVM is not a problem, as Debian has j2sdk1.4 No it doesn't, and it cannot for licensing reasons. You can still depend on

Looking for a one-time sponsor

Hi, I'm the pacakger for the 'nice' package (a compiler for a Java-like language). I'm still in the new maintainer process, so I cannot upload to the archives yet. The current nice package is quite outdated, and somebody filed a wishlist big report (#262246) to get it updated. The problem is tha

Re: jmp in testing

OpenSourcing Java? :-D Maybe they are shorter-term solutions, like j2re1.4-dummy? I know there is a way to generate local dummy packages, but that will not help packages migrating into testing... Daniel

Re: jmp in testing

#231818. Takashi just downgraded it from serious to normal. Why hasn't the changelog closed it? This bug is for m68k and jmp couldn't be builded. As FTBFS shouldn't be RC bug for contrib package, I just changed bug status. Should I close it? The bug was that jmp needs a sdk to build, and did not

Re: jmp in testing

First, there is this RC bug. It should have been closed by Takashi's last upload, but it somehow didn't happen. Anybody understands this? Which one? I see a manpage problem and a j2sdk dep missing but no RC bug. (maybe it's been closed?) #231818. Takashi just downgraded it from serious to normal.

jmp in testing

Hi, I would be happy to see jmp in testing/sarge. Here is the package page: http://packages.qa.debian.org/j/jmp.html First, there is this RC bug. It should have been closed by Takashi's last upload, but it somehow didn't happen. Anybody understands this? Then there is the powerpc version, which

Re: Signal 11 running Eclipse

Hi, Have you search the archives of this list? I think this was already reported... I have some trouble using Eclipse, on a Debian Sid. Software versions: j2sdk : 1.4.1-6 (Blackdown) If I remember correctly, this is specific to that JVM. You could try installing Sun's version (using j2se-packa

Re: What is the ant-launcher.jar?

I still think that ant should stop depending on jython and antlr, since that's a policy violation (depends on non-necessary packages) and brings I agree with the first part, but not the second (i.e. IMHO it's not a Policy violation). But the latest Ant package (uploaded yesterday) does not d

Re: What is the ant-launcher.jar?

Well, we got ant, ant1.5 and ant1.6 and maybe the plugins could exist for the three different ant... What is the rationale for /usr/share/ant1.X/lib ? Is it designed for plugins that would only work with a certain version of ant? what happens if you don't have ant1.6 but already have a lot of p

Re: When is a package ready to go into main?

Since the 1.1.4 release of kaffe, eclipse runs reasonable well with kaffe. Good news! Reasonable well means, that I successfully did some java coding with it. I couldn't call it very good, since the second editor (XML plugin) I tryed to open crashed the whole thing. So what is the treeshold (sp?)

Re: What is the ant-launcher.jar?

Salut Arnaud, What I do (in the package 'nice') is to setup a symlink from /usr/share/ant/lib/nice.jar to the jar containing the actual plugin. Maybe we should discuss on that. Maybe it's good but I think we should have a common way of doing it. Agreed. Maybe a shell script update-antlib or som

Re: What is the ant-launcher.jar?

Is there a standard Debian way to add ant plugins libraries? I don't think this is documented anywhere. What I do (in the package 'nice') is to setup a symlink from /usr/share/ant/lib/nice.jar to the jar containing the actual plugin. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a s

Re: Report from the Debian Java developers meeting at FOSDEM

So, as Kaffe is licensed under the GPL, the combination of Kaffe + Classpath must be licensed under the terms of the GPL (as per Kaffe's license). No exception for linking (a la Classpath) may be allowed. But that's not the question at hand. The question is whether you are allowed to run a GPL-in

Re: eight packages could possibly go to main!

If a debian package can only be built using Kaffe, then it depends on Kaffe and thus should be GPL compatible, according to both the debian-legal concensus and the FSF interpretation. Unless I am missing something? I think you are mixing the debian package with the upstream program. Upstream pro

Re: eight packages could possibly go to main!

Hello Etienne, I repeat: I am simply pointing you to the relevant documentation, Thanks for the pointers. I am aware of those discussions, having followed some of them on this list. but I am not willing to discuss the issue. I don't want to restart that discussion either ;-) I was asking yo

Re: eight packages could possibly go to main!

Etienne Gagnon wrote: The biggest problem is that Kaffe is licensed under the GNU GPL, so if an application/library can only be compiled with Kaffe, it must be licensed under the GPL too (or at least be "license compatible" with the GPL). By "only compiled with Kaffe", you mean "and not with Sun's

Maven and Unix

It would be great if maven was part of the solution, and wouldn't turn into a road block. It has great potential in both directions, as far as I can see it. I completely agree with this. While I understand the griefs expressed in this thread about Maven not playing nicely with the OS, I also th

Re: Let Jikes (finally) go into testing on its own...

1. People installing a VM do not need to install jikes so first one is out. I agree with that, as I said before. 2. The entire point of putting wrappers in the source package of another package (like a compiler, or JVM), is to not bloat the /pool with stupid little 20 byte sources. True, b

Re: Building kaffe --with-threads=unix-pthreads [was: Re: bugwatcher problems]

Debian-specific: I think I'll have a version problem. Do I have to change the epoch to 2 as Adam wrote it in a previous mail. Thanks for a confirmation. You mean for the jikes-kaffe package? You can use an epoch, or any of the two other techniques mentioned in the thread "let jikes " (see

Re: Let Jikes (finally) go into testing on its own...

Stefan Gybas wrote: Daniel Bonniot wrote: One solution to this (which I found at http://www.mail-archive.com/[EMAIL PROTECTED]/msg10605.html) would be to temporily make new (empty) versions of the jikes-* packages with priority extra, and that only depend on the new jikes-with-* packages

Re: Let Jikes (finally) go into testing on its own...

Would it work if, say, classpath built a new package 'jikes-with-classpath' (whatever the name, but a new one), which 'Replaces: jikes-classpath' and 'Conflicts: jikes-classpath' ? Classpath could then keep its version number, and upgrades should still happen automatically. No they wouldn

Re: Let Jikes (finally) go into testing on its own...

If they are in separate packages which are then built by the JVM source packages, yes. However, I think they should just be in the "main package", e.g. directly in kaffe. jikes-kaffe depends on kaffe anyway so a separate package does not make a lot of sense IMHO. But jikes-kaffe also needs to d

Re: Let Jikes (finally) go into testing on its own...

Hi, Thus I'll upload a new version of jikes in a few hours without any wrappers. Great. Looking forward to a new jikes in testing. Everyone should make their packages either epoch 2 (ie. version 2:x.x.x) or make sure they are later or equal to 1:1.19 or so. Anything else would mess up the upgra

Re: question about tomcat

I want to ask you if there is any way to get tomcat does not start automatically when linux starts. I know I can delete all /etc/rcx.d/S20tomcat4 links, but, there is another way? (as editing parameter start_at_boot in /etc/tomcat/default, for example). use the command "update-rc.d" to properly

Re: Bug Status of Kaffe

However, Kaffe is the only thing that I maintain so I am loathe to give it up entirely. I would be happy to share the burden of maintaining Kaffe with a number of people in the same manner as the X-strike force. I'm also able to dedicate hardware, bandwidth and other facilities thanks to my rol

Re: ant dependency on jython and antlr

What do you mean "build files for jython projects"? Do you just mean it provides an editor with jython syntax highlighting/etc? Or do you mean it compiles jython files? The second one. Note that jython is an implentation of python, and so most jython scripts are run directly (with no compila

Re: ant dependency on jython and antlr

[I posted this on Dec 22nd, but it seems it never got through, so I repost it. Since then I found bug #211560, which raises a similar concern with ant. It was sent in mid September, and did not get any answer. We really need to address this issue.] Ben Burton wrote: Let me preface this by sta

Re: ant dependency on jython and antlr

On the other hand, having jython depend on (or recommend or suggest) ant is quite nonsensical as well, since ant is not really a tool for script writers - in fact jython is not enhanced by ant at all. The way I see things, it is: ant provides a different interface to call the jython interpreter.

Re: ant dependency on jython and antlr

I'm not sure about jython (haven't looked), but optional.jar has the glue for junit (->junit task). Junit knows nothing about ant. I think the dependency on junit sort of makes sense since it can be considered a basic tool for java developers. The same cannot be said of jython and antlr. AFA

Re: ant dependency on jython and antlr

There is a problem with all this: The ant package has one big jar for all available tasks (the optional.jar has all the 'Task's, the junit, jython and so are only called from that task definitions). You mean that optional.jar has specific knowledge about jython? This means that if any package w

ant dependency on jython and antlr

Hi java maintainers, Since version 1.5.3-2, the package ant depends on jython and antlr. The justification was: * Depend on the previously suggested packages jython and antlr to avoid dangling symlinks in /usr/share/ant/lib The Debian policy, section 7.2, says: * Depends This declares an ab

Re: Java packaging

BTW: I will try to package the eclipse 3.0 stream after the next release That's great. Will you keep both 2.1 and 3.0 in parallel in Debian, or simply upgrade the packages to 3.0? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PRO

Re: Apache mod_jk

Hi, But if I do a 'apt-cache search libapache-mod-jk' I don't get any result. What is the mod-jk package name on debian? I have tried it on a testing and unstable debian. libapache-mod-jk is only in stable, it must have been replaced. I don't know anything about tomcat, but if you do 'apt-cache

Re: Kaffe in testing

could you do an update of 1.0.5 first, please? That RC bug[1] is one of the two[2] holding back kaffe from entering testing from what I see on [3]. An upload of 1.1.2 will not fix that bug, as it's a bug in stable, and 1.1.2 is has no chance going into stable until the next release, sarge, afa

Re: Kaffe in testing

The problem for me at this point isn't so much a lack of time as it is a lack of understanding about the release cycle underway. I've heard varying stories about whether we can or can't upgrade to new upstream versions. Given that kaffe is currently not in testing at all, that it has RC bugs

Re: Kaffe in testing

Hi, Thanks Dalibor for these great news (and his work on Kaffe itself). So it seems that upstream 1.1.2 fixes most of the releast-critical problems of kaffe (except the manpage bug). It would therefore be very important for Java-on-Debian to have a new package made soon. Ean, can you do it? If

Re: [ANN] New version of j2se-package (formerly mpkg-j2sdk)

Because the FTP admins abviously don't want to have a lot of small packages when these small scripts/binaries with the same target users can easily be put into a single package (that's also my opinion). Yes, but I don't see what existing package could hold this script. java-common certainly bel

Re: [ANN] New version of j2se-package (formerly mpkg-j2sdk)

I don't disagree but I think the FTP admins will reject the package after reading the "ftpmaster accepts packages that have been rejected a few days ago" thread in -devel, especially http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00766.html. And why do you think that? The ca

Re: Kaffe in testing

Two more important bugs (but I did not file it on the bts): - problem with xml entities (bug introduced by gnujaxp): resolved with 1.1.2 - java.util.TimeZone.SHORT does not exists: resolved with 1.1.2 These should actually be only one (minor/normal level) bug in Debian's BTS: "Upstream versi

Kaffe in testing

Hi, There are currently two release-critical bugs and architecture problems that keep kaffe from reentering testing. The details are at http://bjorn.haxx.se/debian/testing.pl?package=kaffe One of the bugs (the manpage location) seems trivial, and a patch is attached. Is there a reason why it ha

Re: Package for the proposed new java policy

Jan, thanks for the upload. * moved examples into /usr/share/doc/new-java-policy/examples -> to use the examples, do a 'export JAVA_CONFIG_DIR=/usr/share/doc/new-java-policy/examples' The manpage of findjava is not up to date with this. It does not mention the JAVA_CONFIG_DIR, but speaks

Package for the proposed new java policy

Hi, I would like to make a proposal about the evolution of the Java policy. I think there is an agreement that the policy cannot be changed at this point, both because there is a release coming (hopefully) soon, and because the new behaviour needs to be experimented and made common before it c

Bug#212863: finjava: a tentative summary

Hi all, There seems to be some misunderstanding going on. Having not taken sides, I thought I would try to help clarify the positions. 1) Necessity for findjava I think Jan explained this well in his last message. Package A might work with kaffe or gij but not sablevm, while package B works wi

Re: [PROPOSAL] 3. RfD on new debian java policy

I will neither propose nor agree with a debian java policy, which will ignore this facts and make out users patch debian packages to get this working. I don't see the point of making a policy that says that packages must work with some non-packaged non-free programs. It would be nice if t

Re: [PROPOSAL] 3. RfD on new debian java policy

A better way in my opinion is to allow the user to 'override' maintainer's choice of VM environment in some easy way (like putting another java executable in front of his path, or running a selectmyvm script). I agree this is a good solution: the default behaviour is going to work because the mai

Re: [PROPOSAL] 3. RfD on new debian java policy

I will neither propose nor agree with a debian java policy, which will ignore this facts and make out users patch debian packages to get this working. I don't see the point of making a policy that says that packages must work with some non-packaged non-free programs. It would be nice if t

Re: [PROPOSAL] 3. RfD on new debian java policy

A better way in my opinion is to allow the user to 'override' maintainer's choice of VM environment in some easy way (like putting another java executable in front of his path, or running a selectmyvm script). I agree this is a good solution: the default behaviour is going to work because the mai

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

FWIW, I think having a package build relying on /usr/bin/javac is a very bad idea. You want to be absolutely sure that a package builds out of the box, and IMHO this means you should explicitly build-depend upon *and* call a complier that you know will work. Note that just the build-depends is n

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

What interface do you suggest? The discussion her pretty much showed, that you can't rely on anything. This would mean: * -classpath is probably save (-cp already not...) I think we should define an interface in the Java policy, then write wrappers for the different compilers, and install the wra

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

FWIW, I think having a package build relying on /usr/bin/javac is a very bad idea. You want to be absolutely sure that a package builds out of the box, and IMHO this means you should explicitly build-depend upon *and* call a complier that you know will work. Note that just the build-depends is n

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

What interface do you suggest? The discussion her pretty much showed, that you can't rely on anything. This would mean: * -classpath is probably save (-cp already not...) I think we should define an interface in the Java policy, then write wrappers for the different compilers, and install the wra

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

IMO, /usr/bin/javac is mainly used for hello world programms and almost nowher ein scripts, so it's not really nessesary to have strictly the same comandline options (man pacges will be under update alternatives as well) javac can also be called during package building. Unless a specific compiler

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

IMO, /usr/bin/javac is mainly used for hello world programms and almost nowher ein scripts, so it's not really nessesary to have strictly the same comandline options (man pacges will be under update alternatives as well) javac can also be called during package building. Unless a specific compiler

Sponsor for the Nice compiler (Java extension)

Hi, I am the main upstream author of the Nice language, which is an extension of Java with many advanced features. It is released under the GPL. Homepage: http://nice.sourceforge.net A few month ago, I already asked for a sponsor (http://lists.debian.org/debian-mentors/2003/debian-mentors-2003

Sponsor for the Nice compiler (Java extension)

Hi, I am the main upstream author of the Nice language, which is an extension of Java with many advanced features. It is released under the GPL. Homepage: http://nice.sourceforge.net A few month ago, I already asked for a sponsor (http://lists.debian.org/debian-mentors/2003/debian-mentors-20030

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

Your scheme is sound in theory, but isn't a solution for Java under the Debian OS. It means that virtually all Java packages in Debian would sit in contrib. That's just not acceptable. I see two options to solve this: 1) Strict interpretation of javaN-runtime Indeed, probably no free JVM will be

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

Your scheme is sound in theory, but isn't a solution for Java under the Debian OS. It means that virtually all Java packages in Debian would sit in contrib. That's just not acceptable. I see two options to solve this: 1) Strict interpretation of javaN-runtime Indeed, probably no free JVM will be a

Re: Policy: java1-runtime

Deprecated features are still available. There are still tagged, so that their use is discouraged, since they might be removed in a later release. As far as I know, nothing has ever been removed yet. Technically, if a package requires the java1 API, it will run with a java2 implementation. So I

Re: Policy: java1-runtime

Deprecated features are still available. There are still tagged, so that their use is discouraged, since they might be removed in a later release. As far as I know, nothing has ever been removed yet. Technically, if a package requires the java1 API, it will run with a java2 implementation. So I

Re: Policy: java1-runtime

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 features are still available. There are still tagged, so that their use is discouraged, since they

Re: Policy: java1-runtime

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 features are still available. There are still tagged, so that their use is discouraged, since they

Re: Policy: java1-runtime

In which case fixing dpkg strikes me as far better than adding yet more byzantine workarounds. I'm all for somebody working on improving dpkg. At the same time, I know this is a limitation that has been known for a long time, so it might not be easy to fix, and will probably need some more time.

Re: Policy: java1-runtime

In which case fixing dpkg strikes me as far better than adding yet more byzantine workarounds. I'm all for somebody working on improving dpkg. At the same time, I know this is a limitation that has been known for a long time, so it might not be easy to fix, and will probably need some more time.

Policy: java1-runtime

Hi, I was reported that my package, which "Depends: java-virtual-machine, java1-runtime", could not be installed of a user's machine, who has blackdown's j2sdk1.4 and j2re1.4 installed. j2re1.4 "Provides: java-virtual-machine, java2-runtime". Something seems to be wrong, since the package should

Policy: java1-runtime

Hi, I was reported that my package, which "Depends: java-virtual-machine, java1-runtime", could not be installed of a user's machine, who has blackdown's j2sdk1.4 and j2re1.4 installed. j2re1.4 "Provides: java-virtual-machine, java2-runtime". Something seems to be wrong, since the package shoul

Re: What is Maven?

Does anyone uses Maven? Is there any interrest in Debian? I don't use it, but your post made me discover it, and it looks like a very interesting project. I would be glad to see it packaged for Debian. They link to the quilt coverage tool (http://quilt.sourceforge.net/overview.html) they plan

Re: kaffe-1.1.1 package available for tests

Doesn't a few days seem abnormally short notice for such a major NMU - not a bugfix but an entire new upstream release? Yes, maybe this is short. On the other hand, one can take into consideration that the last message of Ean about upgrading (at that time it was to kaffe 1.1.0) was almost two mo

Re: update-alternatives problem for java?

Hein, can you send the output of: update-alternatives --display java It would also probably useful to see the output when the problem is manifest. That is, according to the diagnostic, after deinstalling and reinstalling sablevm. This will additionally be a way to check that it's indeed thi

Re: What is Maven?

Does anyone uses Maven? Is there any interrest in Debian? I don't use it, but your post made me discover it, and it looks like a very interesting project. I would be glad to see it packaged for Debian. They link to the quilt coverage tool (http://quilt.sourceforge.net/overview.html) they plan

Re: update-alternatives problem for java?

Hein, can you send the output of: update-alternatives --display java It would also probably useful to see the output when the problem is manifest. That is, according to the diagnostic, after deinstalling and reinstalling sablevm. This will additionally be a way to check that it's indeed this

Re: kaffe-1.1.1 package available for tests

time would be better spent persuading the FSF and ASF to get together on their licenses and make either the GPL ASL compatible or the other way round. who kknows, maybe you won't waste the time and they get their ideals/egos out of the way and work out a compromise. I'm not following this stuff ac

Re: kaffe-1.1.1 package available for tests

And thus with a small amount of work I was able to adjust jython to use Makefiles and as a result jython was able to ship with woody, even though ant was not. This put the decision in a new light. Yes, your goal being to get Jython in woody, it made sense to work on that. Now that woody is relea

Re: kaffe-1.1.1 package available for tests

But ... the FSF doesn't think that code licensed under a GPL incompatible license can be allowed to run on a GPLd VM (i.e. kaffe). Could you give a link that details this point? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROT

Re: kaffe-1.1.1 package available for tests

And thus with a small amount of work I was able to adjust jython to use Makefiles and as a result jython was able to ship with woody, even though ant was not. This put the decision in a new light. Yes, your goal being to get Jython in woody, it made sense to work on that. Now that woody is relea

Re: kaffe-1.1.1 package available for tests

time would be better spent persuading the FSF and ASF to get together on their licenses and make either the GPL ASL compatible or the other way round. who kknows, maybe you won't waste the time and they get their ideals/egos out of the way and work out a compromise. I'm not following this stuff ac

Re: kaffe-1.1.1 package available for tests

But ... the FSF doesn't think that code licensed under a GPL incompatible license can be allowed to run on a GPLd VM (i.e. kaffe). Could you give a link that details this point? Daniel

Re: kaffe-1.1.1 package available for tests

Doesn't a few days seem abnormally short notice for such a major NMU - not a bugfix but an entire new upstream release? Yes, maybe this is short. On the other hand, one can take into consideration that the last message of Ean about upgrading (at that time it was to kaffe 1.1.0) was almost two mo

Re: Bug#203187: ITP: charva -- java windowing toolkit for text terminals

I was playing with this a few weeks ago. It's a shame it doesn't support mouse or keyboard. Taken from their main webpage: CHARVA now also has mouse support on terminal-emulators that report mouse events, such as "xterm" and "PuTTY " Actual

Re: [PROPOSAL] dh_ant

Ben Burton wrote: JAVA_HOME=/usr/lib/j2se/1.4 Would there be a way of making this bit magic? i.e. following the /usr/bin/java symlink? This is dangerous - even if you jave j2sdk1.4 installed, /usr/bin/java might still point to kaffe, gij, etc. I'd stick with a hard-coded path, especia

Re: Bug#203187: ITP: charva -- java windowing toolkit for text terminals

I was playing with this a few weeks ago. It's a shame it doesn't support mouse or keyboard. Taken from their main webpage: CHARVA now also has mouse support on terminal-emulators that report mouse events, such as "xterm" and "PuTTY " Actual

Re: [PROPOSAL] dh_ant

Ben Burton wrote: JAVA_HOME=/usr/lib/j2se/1.4 Would there be a way of making this bit magic? i.e. following the /usr/bin/java symlink? This is dangerous - even if you jave j2sdk1.4 installed, /usr/bin/java might still point to kaffe, gij, etc. I'd stick with a hard-coded path, especi

Re: Eclipse upgrade

Hi Jan, Thanks for you answer. The only thing, what someone could do, would be to package a eclipse-snapshot package. I somebody does it, plase announce it here. I looked at eclipse's internal "software upgrade" feature, but I take it that it will not upgrade across major versions like this,

Eclipse upgrade

Hi, Are there plans to upgrade the eclipse packages to a newer version of eclipse? The current ones (in 2.1-5) date back to march. I happen to use a plugin that requires the "Problems" views, which I can't find in eclipse in Debian. I suspect this was added in a newer version of eclipse (if an

Re: mpkg-j2sdk and Sun's license

Debian[1]. I think it's in the java faq. And another point is that the license does not allow someone who use one of the tools from the jdk to use a replacement tool!.. I think I am outlaw ;-) Are you refering to: 5.3.1.4 Can I use jdk1.2 while working with the free Java implementations? If i

Re: mpkg-j2sdk and Sun's license

Debian[1]. I think it's in the java faq. And another point is that the license does not allow someone who use one of the tools from the jdk to use a replacement tool!.. I think I am outlaw ;-) Are you refering to: 5.3.1.4 Can I use jdk1.2 while working with the free Java implementations? If it

Re: Java AWT for Debian?

cat > Test0.java << EOF class Test0 { static int foo { return 0; } } EOF I don't believe this is valid Java source, because of missing parentheses. It should be: ... static int foo () { return 0; } ... What error message do you get with the various compilers? Daniel -- To UNSUBSC

Re: Java AWT for Debian?

cat > Test0.java << EOF class Test0 { static int foo { return 0; } } EOF I don't believe this is valid Java source, because of missing parentheses. It should be: ... static int foo () { return 0; } ... What error message do you get with the various compilers? Daniel

Re: [maybe OT], .class -> .java

Hi, $ apt-cache search java decompiler jad - The fast Java Decompiler $ apt-cache show jad Description: The fast Java Decompiler Jad is a Java decompiler, i.e. program that reads one or more Java class files and converts them into Java source files which can be compiled again. Have you tried it?

Re: [maybe OT], .class -> .java

Hi, $ apt-cache search java decompiler jad - The fast Java Decompiler $ apt-cache show jad Description: The fast Java Decompiler Jad is a Java decompiler, i.e. program that reads one or more Java class files and converts them into Java source files which can be compiled again. Have you tried it? Da

Re: Sponsor for a bootstrapping Java++ compiler

To achieve this I use the "deb-makepkg" script below. Thanks a lot, I will look at this. Shouldn't this advertised publicly, and a package made for it? Or could it be integrated to cvs-buildpackage and/or dpkg-buildpackage, as appropriate? It would probably benefit the community, and help to h

  1   2   >