Where is $JAVA_HOME/lib ?
I have a java application [0] that runs fine x86 linux with sun java, but I would like to run this on sparc linux where there is no sun java :( So I would like to try using debian/unstable java-gcj-compat The application is in csi.jar and is launched from command line or from the web browser and requires files to be placed as follows $JAVA_HOME/lib/ext/csi.jar $JAVA_HOME/lib/security/local_policy.jar $JAVA_HOME/lib/security/jce1_2_2.jar $JAVA_HOME/lib/security/US_export_policy.jar The application starts from the browser or directly by: $JAVA_HOME/bin/java au.gov.bafcsi.clapi.crypto.CsiManager Can this work with java-gcj-compat? What would be the proper location for the files? I have: /etc/java/security /usr/share/xulrunner/chrome/en-US/locale/en-US/global/security /usr/share/iceweasel/chrome/en-US/locale/en-US/global/security /usr/include/c++/4.1.2/java/security /usr/include/c++/4.1.2/javax/security /usr/include/c++/4.1.2/gnu/java/security /usr/include/c++/4.1.2/gnu/javax/security /usr/include/security /usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre/lib/security /usr/lib/security [EMAIL PROTECTED]:~$ java GetJVMInfo java.version= 1.4.2 java.vendor= Free Software Foundation, Inc. java.home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre gnu.classpath.home=/usr gnu.classpath.home.url=file:///usr/lib/../lib any hints would be appreciated.. thanks jim [0] http://csi.business.gov.au/CSI/CsiInstallForLinux.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tomcat4 and apache1.3.x not talking to each other
You might need to uncomment the servlet mapping for the invoker servlet in /etc/tomcat4/web.xml . hth, jim At precisely Sun, 16 Nov 2003 01:23:57 -0700 "J. R. Westmoreland" <[EMAIL PROTECTED]> wrote: > I'm running apache 1.3.29-1 with tomcat4 and I have the connector installed but they > don't seem to be working together. > I get a server internal error and can't see anything in the logs. > I'm using the libapache-mod-jk package for the connector. > I had to change the java-home path in the workers.properties file and removed the > virtualhost line from the sample httpd.conf snippet. > Any ideas? > > > -- > J.R. Westmoreland (W7JR) > E-mail: [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- /** * Jim McLaughlin * Senior Software Engineer * Stonewater Control Systems, Inc * (847) 864 1060 x107 */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
JIKES and Xemacs
Hi folks I was wondering if anyone knew how to parse debugger messages when using JIKES in Xemacs? Jim Franklin
[Fwd: [phxjug-java] PVCj 1.2 released (Open Source)]
--- Begin Message --- Hi folks, Just a quick announcement to let you know that there's a new version of PVCj available which works with the newest versions of Java Plugin (1.2). For those who have no idea what I am talking about, PVCj (Plugin Version Control for Java) is a free tool which enables client side installation of .jar files within Sun's Java Plugin. These means that you can run large applets in Java Plugin and have the corresponding .jar files "cached" on the client machine. So when the applet starts, everything's local and startup is very rapid; .jar files are only downloaded from the server if a newer version is available. PVCj in production for almost a year now and has enjoyed widespread use and acclaim. Most notably in this new version, we've added workarounds for several bugs introduced in Plugin 1.2 (like URLConnection not returning correct dates for .jar and .exe files) and we've released PVCj as Open Source (GNU license). Other licensing options are available as needed. Here's the link for all the details... http://granitepeaks.com/pvcj Feel free to holler with questions. Christian Christian Cryder Software Engineer - UHR Infrastructure REALM Information Technologies - http://www.realminfo.com Plugin Version Control for Java (PVCj 1.2) - http://granitepeaks.com/pvcj Adventures in UHR - http://realm.granitepeaks.com "What a great time to be a geek" -- To unsubscribe, send a message to [EMAIL PROTECTED] with "unsubscribe" in the *subject line*. If you have problems, send a message to '[EMAIL PROTECTED]'. --- End Message ---
Re: Debian Java outlook
Hi folks, I am also a lurker and fairly new to the Java-debian scene(watching the mailing list for a number of months). I am by profession an engineer and have worked startups for the last 15 years. Perhaps the question of a "Debian Java Policy" might be handled as part of the creation of a nonexistent non-profit debian-java fellowship/organization/sub-debian_organization. I would like to point out first that there are approximately 50 days to potato freeze. In creating any non-profit business there are certain optimum guidelines to follow: )create a steering committee of volunteers to create the infrastructure of the group -anyone who volunteers should be welcomed cause one can never have to much assistance. )communication and documentation - we have the basis of this with the mailing list. I would like to point out that we could have real-time get togethers on IRC, say on one of the #debian-... where there are only a couple of bots hanging out. Documentation could be donated by some kind individuals who have free space on their servers. )create a mission statement -this is usually a positive upbeat statement of where you would like to see yourselves going(opening as many directions for as many people as possible). )take an inventory of what you have at this moment -businesses that don't occasionally take inventory usually go bankrupt. The inventory should include people/members and product(packages). )create a "Debian Java Policy" -policies by nature are usually restrictive, and should be kept as small as possible. An example of policy would be "Packages must adhere to the GPL to be included in main." )public relations and customer relations -without PR there won't be an influx of new debian-java developers and I have heard complaints on the mailing list that there aren't enough developers at java-debian. PR can be as simple as the statement "debian-java rocks" at the bottom of your email signature card when corresponding with local JUGs. Customer relations would be for instance a system of handling bugs as quickly and effectively as possible. Why have just a maintainer to a package? Why not a maintainer and a couple of apprentice developers that the maintainer trusts, etc. This is just a simple form of possibles. I'm sure you all know variations of the same. I hope I have been of service to you Jim "Cris J. Holdorph" wrote: > > Bernd Kreimeier Writes: > > Of course, your goals might differ, and with a different > > roadmap, a different policy makes sense. The question I > > tried to ask when the policy proposal came up originally > > was: what is your vision of "Java in Debian"? Is it just > > a bunch of packages to put somewhere, a different compiler > > and runtime environment to manage? Or is it an integral > > part of your ideas of what free, *portable* software should > > look like in 5 or 10 years? > > This is a great question. And one I've been waiting to answer > on this list for a long time. Thank you for giving me the perfect > opportunity. > > The debian-java list and Debian's interaction with Java has been > the only thing that has come close to pushing me away from Debian > entirely. For the last 2 full years, I've been doing Java > development full time. Excluding a couple months, I've done all > of that development on Solaris and Linux. *MY* vision is one where > a java compiler and jvm are installed by a package system, and run > as part of the "default path" (e.g., there is some kind of > /usr/bin/java and /usr/bin/javac). Next, I would like to see the > ability to install "development" and "runtime" libraries. I do > a LOT of work with servlets. So a "servlets.jar" that contained > the servlet api might be good, Apache JServ would be even better. > > I have virtually no need for java programs most of the time. A > java version of ls, find, tar, etc, would not help me at all. > Something libc-like besides 'java.*' class libraries might or might > not help me. (I find Sun's Java libraries, sufficient for most of > my needs.) > > I understand how Sun's proprietary license is in very direct > opposition to Debian policy. If kaffe or Japhar ever progress to > something I can use, I will. (And yes, I've tried Kaffe recently > and it does NOT WORK for my application.) I have finally decided > that I will continue to use Debian, because of all the other reasons > I have used it for years. As far as doing Java stuff. I just > install all my Java utilities/libraries by hand. > > I mostly lurk on debian-java, because I have an interest in both. > However, I have no immediate hope of those two ever meeting. If > they do, great. If not, I'll continue to install the JDK and Jserv > myself. > > Cris J H > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Java outlook
Hi Stephane,
It has been my experience that there are two types of engineers in the
world. The ones who tell you why something can't be done and the ones
who make the concept happen. My letter to you folks was to open up
possibilities. Good luck.
Jim
Stephane Bortzmeyer wrote:
>
> On Friday 10 September 1999, at 10 h 50, the keyboard of Jim Franklin
> <[EMAIL PROTECTED]> wrote:
>
> > Perhaps the question of a "Debian Java Policy" might be handled as
> > part of the creation of a nonexistent non-profit debian-java
> > fellowship/organization/sub-debian_organization.
>
> Well, this is quite far-fetched. May be smaller goals first?
>
> > )take an inventory of what you have at this moment -businesses that
> > don't occasionally take inventory usually go bankrupt. The inventory
> > should include people/members and product(packages).
>
> Jules Bean suggested to do such a list but gave in, by lack of free time.
> Volunteers are welcome.
>
> > )create a "Debian Java Policy" -policies by nature are usually
> > restrictive, and should be kept as small as possible.
>
> We are working on it. See the java-common package. I agree it is a good thing
> for it to be small: some issues ae clearly unresolved (core classes...) and
> are therefore left out.
>
> It is always possible that someone is stupid enough to mock the proposed
> policy from its size ("All this time for a page and a half!") but we'll ignore
> him.
>
> > An example of
> > policy would be "Packages must adhere to the GPL to be included in
> > main."
>
> On this specific point, there is nothing related with Java. Policy (Debian
> general policy, not Java policy) just say you have to be DFSG-free to get into
> main, wether you are written in Java, Ruby or Scheme.
>
> > )public relations and customer relations -without PR there won't be an
> > influx of new debian-java developers and I have heard complaints on the
> > mailing list that there aren't enough developers at java-debian. PR can
> > be as simple as the statement "debian-java rocks"
>
> At the present time, it is false. debian-java more or less sucks. Until we
> (note the plural) change it, I will not write a Press Release "Debian is the
> best Java platform". I abide by the social contract and I am therefore
> entitled to realism, modesty and telling the truth to the users.
Re: JFORK: Or a reasonable response to the Sun SCSL
Hi John, I've been following debian-hurd myself the last few months. If you could send some URLs, other than the usual hurd ones, on the hurd architecture(translators,etc) and perhaps detail your thoughts on a HURD VM (eg cross-platform, structure, etc), I would be very interested. Jim John Foster wrote: > > I have been watching this thread for some time and feel that some > reality is in order for anyone interested in this subject. > > My 2 cents worth: > > 1. Sun and all other commercial ventures exist solely for the purpose of > making money. They will sometimes do some things that seem to be for the > "good of mankind", but those things generally have some "lucrative" > aspect to them (read SCSL). > > 2. The aspect of making money is not "a bad thing" in itself. The > acquisition of profit by using deceptive tactics is "a bad thing". > 3. The owner of any original patent/copyright license has the right to > alter that patent at will. For instance if Sun decides to not make > StarOffice available under the SCSL they do have the right, because they > bought it, to make StarOffice a commercial package. They can do so at > will. > > 4. Technically/legally Sun or Microsoft, or AOL and many others, could > alter the terms of the current license structures so that "open source" > "free" software ceases to exist. If Linas Torvalds decided that the next > kernel version of Linux was not to be GPL software, he has the right to > do it. Does that shock you? If it does then you need to read up on the > U.S. patent and trademark guidelines as they apply to intellectual > property, especially software. > > 5. There is a huge movement in Europe to keep software patents out of > the legal system. I do not think they will be successful. However, > "THE ACTIONS TAKEN BY ALL INTERESTED PEOPLE WITH REGARD TO SUN'S SCSL > AND THE APPLICATION OF IT'S GUIDELINES WILL SET A PRECEDENT FOR YEARS TO > COME" > > 6. In my opinion "the best interests of free open source software will > be served by pushing forward with development of the GNU HURD system and > the implementation of a HURD Virtual Machine language that has all the > capabilities of Java as it is now, but is more likely to remain free. > > 7. If Debian and all the other Linux communities continue to put forth > free software that is portable to all hardware systems they represent a > serious threat to all commercial software. > > 8. A HURD VM is possible due to the nature of its message passing system > and would be the most reasonable course to pursue for the development of > portable software. This course would basically make Java obsolete, and > would allow the use of many types of inexpensive hardware solutions to > replace Sun's expensive servers and workstations. This is what they are > concerned about. > > All my best wishes to the people who assist in the "Free Software" > movement, and especially to those of you that do the actual development > of applications. > -- > John Foster > AdVance-Computing Systems > [EMAIL PROTECTED] > ICQ# 19460173 > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JFORK: Or a reasonable response to the Sun SCSL
Hi Seth, I think HURD has potential from the fact that it is an operating system rather than a language. Implementation of the java 2.0 specs may not be constrained by sun's license, although I'm not sure. Jim Seth R Arnold wrote: > > John, there is one point you raised I am not sure I agree with: > > > 8. A HURD VM is possible due to the nature of its message passing system > > and would be the most reasonable course to pursue for the development of > > portable software. This course would basically make Java obsolete, and > > would allow the use of many types of inexpensive hardware solutions to > > replace Sun's expensive servers and workstations. This is what they are > > concerned about. > > Java is being taught in many schools, mine included, as the default > language. Our profs do not mind if we use other languages, but all example > code, all example everything, the default IDE in the labs, EVERYTHING, is > java. That makes for a few years of CS students that know nothing but Java. > (Depressing..) > > Java has spread to Mac, to os/2 (I hope), win32, win3.1, free unix, > commercial unix, practically every platform. > > I have a hard time believing that one GNU Hurd VM module will suddenly cause > all that momentum to go away. (Especially, if Ean has it right -- building a > VM for Hurd, if built from the java 2.0 specs, is going to fall under the > Derivitive Works section of SCSL. And be not free.) > > Some very nice points, but I doubt the hurd will be able to serve as the > magic bullet. > > comments? > > On Wed, Sep 15, 1999 at 05:44:56PM -0500, John Foster wrote: > > I have been watching this thread for some time and feel that some > > reality is in order for anyone interested in this subject. > > > > My 2 cents worth: > > > > 1. Sun and all other commercial ventures exist solely for the purpose of > > making money. They will sometimes do some things that seem to be for the > > "good of mankind", but those things generally have some "lucrative" > > aspect to them (read SCSL). > > > > 2. The aspect of making money is not "a bad thing" in itself. The > > acquisition of profit by using deceptive tactics is "a bad thing". > > 3. The owner of any original patent/copyright license has the right to > > alter that patent at will. For instance if Sun decides to not make > > StarOffice available under the SCSL they do have the right, because they > > bought it, to make StarOffice a commercial package. They can do so at > > will. > > > > 4. Technically/legally Sun or Microsoft, or AOL and many others, could > > alter the terms of the current license structures so that "open source" > > "free" software ceases to exist. If Linas Torvalds decided that the next > > kernel version of Linux was not to be GPL software, he has the right to > > do it. Does that shock you? If it does then you need to read up on the > > U.S. patent and trademark guidelines as they apply to intellectual > > property, especially software. > > > > 5. There is a huge movement in Europe to keep software patents out of > > the legal system. I do not think they will be successful. However, > > "THE ACTIONS TAKEN BY ALL INTERESTED PEOPLE WITH REGARD TO SUN'S SCSL > > AND THE APPLICATION OF IT'S GUIDELINES WILL SET A PRECEDENT FOR YEARS TO > > COME" > > > > 6. In my opinion "the best interests of free open source software will > > be served by pushing forward with development of the GNU HURD system and > > the implementation of a HURD Virtual Machine language that has all the > > capabilities of Java as it is now, but is more likely to remain free. > > > > 7. If Debian and all the other Linux communities continue to put forth > > free software that is portable to all hardware systems they represent a > > serious threat to all commercial software. > > > > 8. A HURD VM is possible due to the nature of its message passing system > > and would be the most reasonable course to pursue for the development of > > portable software. This course would basically make Java obsolete, and > > would allow the use of many types of inexpensive hardware solutions to > > replace Sun's expensive servers and workstations. This is what they are > > concerned about. > > > > All my best wishes to the people who assist in the "Free Software" > > movement, and especially to those of you that do the actual development > > of applications. > > -- > > John Foster > > AdVance-Computing Systems > > [EMAIL PROTECTED] > > ICQ# 19460173 > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- > Seth Arnold | http://www.willamette.edu/~sarnold/ > Hate spam? See http://maps.vix.com/rbl/ for help > Hi! I'm a .signature virus! Copy me into > your ~/.signature to help me spread! > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
["Ben Bederson" ] ANNOUNCE: Jazz 0.6beta (Pad++ successor)
Hi, I remember playing with Pad++ back in the early days of Gnome - it was really cool (but proprietary). Somebody should check this out - it's been rewritten in Java and it's now under the MPL. Cheers, - Jim --- Begin Message --- Hello Pad++ friends, It has been a long time since we have sent any mail about Pad++. While we have not continued working on Pad++, the good news is that we have been working hard for the past year on a successor to Pad++ called Jazz. Jazz is now available (Version 0.6 beta) at: http://www.cs.umd.edu/hcil/jazz/ Jazz is a 100% Java 2 platform for building Zoomable User Interfaces. It supports all of the features that Pad++ does, but does so in a much more open and extensible manner. While Pad++ was designed to be a simple prototyping system, Jazz is designed to be a serious system for reliable application development. Jazz is built on a "scenegraph" model that comes from the world of 3D graphics. It supports embedded Swing widgets, multiple cameras, internal cameras (i.e., portals and lenses), extensible internal structure, running as an applet, and more. Jazz was recently featured on Sun's Java web site at: http://java.sun.com/features/1999/09/bederson.html The best news is that Jazz is completely Open Source. We are not making any proprietary claims. We hope that a community of developers and users will develop, and this will be the base of a software platform that many people will use and benefit from. Note that this list will not be used anymore, and so please do not send requests to be removed from it. If you would like to hear further announcements about Jazz, please register and add yourself to the Jazz mailing lists at: http://www.cs.umd.edu/hcil/jazz/download/register.shtml If you'd like to discuss Jazz with a small but growing community, send mail to mailto:[EMAIL PROTECTED] - Ben +-+ | Prof. Ben BedersonComputer Science Department | | [EMAIL PROTECTED] Human-Computer Interaction Lab (HCIL) | | www.cs.umd.edu/~bederson 3171 A.V. Williams Building | | (301) 405-2764University of Maryland| | (301) 405-6707 (FAX) College Park, MD 20742| +-+ --- End Message ---
[Fwd: IBM Announces New Java 1.1.8 for Linux]
--- Begin Message --- Thought you should know... Now there's Java performance on Linux that's as fast as on Windows IBM has released its latest Java port for Linux, the Java 1.1.8 IBM Developer Kit for Linux. An alpha version of the Developer Kit has been available for download from alphaWorks for several months. This final version, available for free, is a stable, high-performance implementation of Java that enhances IBM's Linux-enabled middleware such as DB2, and WebSphere. Try it yourself... its super-fast! Read on and download http://www.ibm.com/developer/linux/papers/java-118.html?loc=180,t=g,p=linux000 --- End Message ---
[Fwd: Plugged In Releases Open Source Web RAD Tool]
--- Begin Message --- Hi all, Those of you who are into the Enhydra Java/XML application server might also be interested in Plugged In's new project. We released our Platypus Toolset (basically a Java code generator for Enhydra) under the GNU LGPL license today. Please see http://www.PIsoftware.com/platypus/ for details. -- Regards, Dave -- David Wood | Telephone: +61 7 3876 7140 mailto:[EMAIL PROTECTED] | Facsimile: +61 7 3876 7142 http://www.PIsoftware.com| PGP Key available via finger -- Technical Director, Plugged In Software --- End Message ---
[Fwd: Microkernel advocacy]
The microkernel OS they are speaking of is the HURD. Jim--- Begin Message --- On Fri, Oct 29, 1999 at 07:00:17AM -0400, Leimy wrote: > Does all of this mean that JAVA could run closer to the kernel (at least > relative to other languages in different operating systems) in a > microkernel OS than Linux or Windows? Of course, just add java magic to the exec server, and java programs are run as transparent as hash bang scripts or elf files. It will (is?) possible to have different exec servers for different users. Marcus -- "The purpose of Free Software is Free Software. The End and the Means are the same." -- Craig Sanders Marcus Brinkmann <[EMAIL PROTECTED]> --- End Message ---
Hurd and Java[FW]
--- Begin Message --- Nic Ferrier wrote: > > Does the Hurd support Java yet? It's the other way round: Does any Java Interpreter does support the Hurd? I don't know. > via Kaffe? I suggest get the source and try it out, then let us know. Thanks, Marcus --- End Message ---
Re: Hurd and Java[FW]
Hi Ean, Thanks for the response, I figured you be moving like crazy getting Kaffee ready for the potato freeze. I've been passing info as it relates to the Hurd and java along to debian-java in the hopes that it might be of benefit to the debian-java developers as well as the Hurd developers. For the debian-java developers I was thinking it might be a way around the Sun license problem on the java 2 virtual machine as was discussed as a possibility a few months ago. Cris J H responded to a query a short while ago saying he thought that the java vm would need to be modified to run under the Hurd. Perhaps this could be of benefit to the debian java developers. I don't know enough to make that kind of call. For the the Hurd developers the benefit would be in a higher profile for the Hurd as well as bringing in some real cool capabilities to the Hurd. I believe Marcus B, one of the Hurd developers mentioned that java could be run as a transparent layer with the Hurd translators. Hopefully this correspondence can continue and be of benefit to all involved. Luck to all. Jim > > Subject: Re: Hurd and Java[FW] > Resent-Date: 6 Nov 1999 23:04:05 - > Resent-From: debian-java@lists.debian.org > Resent-CC: recipient list not shown: ; > Date: Sat, 6 Nov 1999 17:03:59 -0600 > From: "Ean R . Schuessler" <[EMAIL PROTECTED]> > To: Jim Franklin <[EMAIL PROTECTED]> > CC: debian-java@lists.debian.org > References: <[EMAIL PROTECTED]> > > I'm interested in this but have simply not had time to get a HURD machine > rolling. I would be willing to set up a dedicated machine for HURD > development here at Novare if someone can help me get through the install > and setup. Perhaps we can do something with a serial-console dual boot > system. Does GRUB do serial console? I can get Debian installed easily > enough, HURD sounded more difficult. > > On Fri, Nov 05, 1999 at 08:32:12AM -0700, Jim Franklin wrote: > > > > Nic Ferrier wrote: > > > > > > Does the Hurd support Java yet? > > > > It's the other way round: Does any Java Interpreter does support the > > Hurd? > > I don't know. > > > > > via Kaffe? > > > > I suggest get the source and try it out, then let us know. > > > > Thanks, > > Marcus > > > > -- > ___ > Ean SchuesslerDirector of Strategic Weapons Systems > Novare International Inc.A Devices that Kill People company > *** WARNING: This signature may contain jokes. > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Java on HURD, success[Fwd: ]
--- Begin Message --- I've attempted to run a Java Virtual Machine under the Hurd, i chose Kaffe which appeared to be the most advanced of the open source JVMs. I got the Kaffe-1.0.5 source from www.transvirtual.com, and of course it didn't compile right out of the box. First I had to get configure to recognise the i386-gnu system type. Then I tried to prallel the architecture dependent initalization code from linux. Since Kaffe requires threads and Hurd lacks a pthreads implementation, i had to settle for it's own jthreads implementaion, however something more native like cthreads or a future implementation of pthreads would be better. After that the compile went through, however Kaffe hung my box hard whenever it tried to run any java program. The problem was in that it was trying to put the stdin, stdout and stderr file descriptors into asynchronous mode (using fctnl and O_ASYNC, i think). Since I'm no expert on async-IO and that part of code wasn't essential to exectution I just commented it out. BTW, how does one go about putting file descriptors in async mode? After that it actually worked fine. I've been able to run several console java programs. And most of the self checks that come with the code passed as well, except a couple that were dealing with threading and stacks overflows. I didn't try and AWT programs yet since I don't have X install (btw, is X actually working now?). The important thing is that it's working!!! Being able to run java apps greatly increases Hurd's application base. So, any suggestions as to the problems stated above? especially about threads, how's that pthreads implementation coming? Igor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] --- End Message ---
Re: Java on HURD, success[Fwd: ]
--- Begin Message --- On Fri, Jan 07, 2000 at 10:26:24PM -0500, Igor Khavkine wrote: > However, I also tried compiling jikes and jikespg packages for the Hurd. > jikespg compiled without problems and jikes needed a patch which has already > been merged with the upstream source (Marcus, you can add those packages to > the binaries archive). Is the jikes patch in the current Debian version of the package? Anyway, I will add both to the list, thanks! > As for using unix-pthreads, again I haven't tried that > but I don't think the Hurd's glibc includes thread support since Linuxthreads > is linux specific. Indeed. We have Mach C threads only. Mark is working on pthread support, but this will take some time. > I'll still try to work out a patch for the CVS version of Kaffe and try > compiling it with unix-pthreads. Will not work on the Hurd... Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] --- End Message ---
someone could port libgc[Fwd: ]
--- Begin Message --- Marcus Brinkmann wrote: > On Wed, Jan 12, 2000 at 10:15:58AM -0500, Derek L Davies wrote: > > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > [snip] > > > I don't know what gcj is, have to check, but we will have kaffee someday > > > sooner or later. I am not sure what you mean with "it has java", > > > I will look into that later today. If it causes trouble, deactivating it > > > until we are ready should be fine. > > > > I believe gcj compiles java directly to native machine code. > > Oh I see. I will look into it. > > > Seems to me there's merits to having both kaffe > > and gcj so, I think, porting both should be encouraged. I was hoping that gdj was another subset of gcc; I have seen something about java in the source of later gcc. Though I have built gcc on many UNIX boxes I have not succeeded on Hurd yet. OK. Will have a good look at what the java and C++ does. Will also find out what this gcj is; (the build does javac=gcj. Will report back this weekend Many thanks Chris > > As long as it's Debian GNU/Hurd, everything that comes as a Debian package > is considered. > > Marcus > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] --- End Message ---
someone could port libgc[Fwd: 2]
--- Begin Message --- Marcus Brinkmann wrote: > On Wed, Jan 12, 2000 at 10:18:43AM -0700, Jim Franklin wrote: > > Hi Chris, > > here a quick URL to gcj > > In Debian, gcj is part of gcc 2.95. So I think we should take a look at that > soon. > gcc 2.95.2 built OK (native Hurd) complete with gcj, and many others. You should see gcj compiling on the Hurd! Will look at libgc; it has a test suite; so if I get anywhere near, I will post a mail to the package maintainers and to you. Chris > > thanks, > Marcus > > -- > `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server > Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key > [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 > http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED] > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] --- End Message ---
panic: zalloc[Fwd:]
--- Begin Message --- I've been testing my Kaffe build under the Hurd. Most simple java programs run fine, however there still are plenty ones that dont. While trying to debug test cases, one program once run consistently make gnumach issue a "panic: zalloc" and crash. I've been able to place the panic call in gnumach-1.2/kern/zalloc.c line 486 (source taken from the debian archive). However if run under gdb, this only gives a SEGV in a seemingly unrelated place. Any clue to what's causing the problem? BTW, if gnumach hangs, is this a bug? Igor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] --- End Message ---
ignore panic: zalloc
Sorry folks, This seems to be a microkernel problem as opposed to java problem. Once again my apologies for sending this through. Jim
Kaffe on GNU Hurd[Fwd: ]
This is a multi-part message in MIME format. --- Begin Message --- --- End Message ---
Forte for Java Open source announcement[Fwd: [phxjug-java] Fwd: ]
--- Begin Message --- X-Sender: [EMAIL PROTECTED] X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 14 Mar 2000 14:50:28 -0800 To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] From: "Cecile Roux" <[EMAIL PROTECTED]> Subject: Forte for Java Open source announcement Hello, Sun issued the following announcement yesterday afternoon about releasing the Forte for Java code to the open source community. -Cecile FOR IMMEDIATE RELEASE FOR MORE INFORMATION Sun Microsystems, Inc. Russ Castronovo (408) 863-3306 [EMAIL PROTECTED] CHEN PR for Sun Microsystems, Inc. Cecile Roux (650) 357-8749 [EMAIL PROTECTED] SUN MICROSYSTEMS ANNOUNCES PLANS TO RELEASE CROSS-PLATFORM JAVA(TM) DEVELOPMENT TOOL CODE TO OPEN SOURCE COMMUNITY Forte(TM) for Java(TM), Community Edition Source to Form Foundation for Java Technology-Based Open Tools Framework Initiative PALO ALTO, Calif., March 13, 2000 -- Sun Microsystems, Inc. today announced its plans to release the source code for Forte(TM) for Java(TM), Community Edition 1.0, its cross-platform integrated development environment (IDE) for Java technology. This product will be made available under the Mozilla public licensing model, which is recognized by the open source community as practical and compliant with the Open Source Definition. This announcement underscores Sun's commitment to open source technologies, and marks the first step in a major new Sun initiative to make Java tools and components available more broadly to drive innovation. "In a dot-com economy, the developer rules," said Patricia C. Sueltz, president of Software Products and Platforms at Sun Microsystems. ""Developers have the power to deliver on two major requirements that determine success in a Web-based world: time to market and business differentiation. Our open tools framework will enable developers to attain new levels of productivity and reliability for dot-com development." Forte for Java, Community Edition 1.0 is the entry-level product in Sun's Forte for Java product line of Java technology IDEs. The binary code for this product, available at no charge for download through Sun Microsystems, is slated for release by end of month. The source code is targeted to be made available within the next 90 days. "I applaud Sun's expanding support of the open source movement," said Brian Behlendorf, president of The Apache Software Foundation. "This initiative will make a new generation of development tools and components available to the Java developer community, addressing a huge gap in the market." "This is encouraging", said Eric Raymond, president of the Open Source Initiative. "I'm happy to see Sun exploring a true open source license." Today's announcement is the next step in Sun's evolving dot-com development and integration strategy. Forte for Java, Community Edition will form the foundation of Sun's new Java technology-based open tools framework. This framework will support the entire development lifecycle, improve reliability through re-use, eliminate vendor lock-in and dramatically cut costs and time to market. Based on this open tools framework, Sun, other vendors and the development community at large can collaborate to develop a complete set of interoperable Java components to accelerate the development of dot-com systems. Access to source code provides individual developers, independent software vendors (ISVs) and application providers a new level of control and confidence. It helps ensure that their software will remain open and interoperable with other technologies. The Forte for Java, Community Edition source code release creates an open community of developers and ISVs to enhance Java technology development tools based on open standards. The Forte for Java, Community Edition source code will also provide the development community with complete access to a core application programming interface (API) from which to develop plug-in modules to enhance the open tools framework. The Forte for Java, Community Edition 1.0 binary product offers an integrated, extensible, cross-platform development environment for the Java 2 Platform, Standard Edition. This fully modular development environment delivers integrated visual design, editing, compilation and debugging capabilities for development on Solaris(TM) operating environment, Linux and Microsoft Windows platforms. With more than 200,000 downloads to date, Forte for Java, Community Edition has gained strong adoption among the Java development community participating in the rapid enhancement of this core IDE technology through early access programs. Forte for Java, Community Edition binary product is available at no charge for download through Sun Microsystems, http://www.sun.com/forte. For more information related to Sun's Java technology-based open tools framework initiative, please visit: http://www.sun.com/forte/tools4dot
JSP error on simple page.
I have been running apache for a while now. Today I installed gnujsp, jserv, kaffe, jikes, and ??? (any other default dependency selection for gnujsp). All of this was installed from woody (unstable) using dselect. I did not play with the gnujsp configuration at all. When browsing the below file, called /var/www/index.jsp, with Internet Explorer: Test Test JSP page This is a date test: <%= new java.util.Date() %>. I get the following error in the browser: Error compiling source file: file:/var/www/index.jsp sun/tools/javac/Main Any ideas on why this is occurring? It seems to me that I might be missing a Java jar file, but shouldn't that have been installed by the dselect? I would be happy to RTFM if you could point me to the manual that would cover this error. I have checked out the debian.org mail list archives. I did not seen anything relevant. Thanks in advance for any info, Jim Brennan
Java error in Mozilla
Could somebody here kindly check out Debian Bug #114265 INTERNAL ERROR on Browser End: Could not load /usr/lib/j2re1.3/lib/i386/libjavaplugin_oji.so: linking error=/usr/lib/j2re1.3/lib/i386/libjavaplugin_oji.so: undefined symbol: XtShellStrings System error?:: Invalid argument The Mozilla maintainer claims it's a Java error. Thanks, js
Re: Java error in Mozilla
Upgraded Mozilla to 0.9.5-5_i386.deb Upgraded JAVA to j2sdk1.3.3.1-1_i386.deb Everything appears to be working fine now ... Browser boots and Java loads. Thanks Juergen, Jim On 2001.11.08 08:51 Juergen Kreileder wrote: Please upgrade to 1.3.1 and see if the problem still exists. Juergen -- Juergen Kreileder, Blackdown Java-Linux Team http://www.blackdown.org/java-linux.html
Re: deb for netbeans
> I thought that the build process of OpenOffice depended on [I'm being > vague here :-(] "some bundle of Java2 stuff," which would have the > result that despite OpenOffice itself being "free software," since a > build requires distinctly nonfree stuff, it can't go in "free." > > It's almost enough to make you want to throw up your hands and say, "why > bother trying?" Is there any chance it could be built with kaffe? Even if it can't be built with kaffe, as the kaffe maintainer, I'd like to know what's missing from kaffe so I can update the "projects" page on the website. Cheers, - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Kaffe and Java2
Hi, I just noticed in the Debian Java FAQ that it says that Kaffe is not going to be implementing Java2 (for legal reasons). I don't think that's correct. I want to see as much of the Java2 APIs implemented as possible in Kaffe. It will probably be a long time before we have all of Java2 implemented, because Sun threw everything and the kitchen sink in there. Sure, Sun's lawyers put some silly, confusing, unenforceable stuff in their legal wording accompanying their docs, but I don't think it's worth repeating. In fact, I think it's important to take a stand on the legal issues from time to time, and not just roll over dead everytime somebody starts playing lawyer games. It would be counter-productive and really bad for Sun to even think about trying to enforce such a clause against a free software project -- and I doubt that there is even a basis for it in copyright law (although the DMCA is quite scary in how drastically it scales back fair use rights). However, Sun could probably stick anybody with unrelated patents if they really wanted to. I'll gladly accept patches for free implementations of Java APIs that match the Java2 spec (but technically, we're not Java, since that's a registered trademark of Sun, and neither are we Java2). Kaffe already has some Java2 stuff implemented in it. Cheers, - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java Policy.
On Sun, 2002-05-12 at 08:11, Nic Ferrier wrote: > Ola Lundqvist <[EMAIL PROTECTED]> writes: > > > Hi > > > > When we now have (almost) got woody out of the door I think it > > is time to give the Proposed Java Policy a more official state > > (i.e. not proposed anymore). > > > > It is available at: > > > > http://people.debian.org/~opal/java/policy.html/ > > The actual policy is avalable at: > > http://people.debian.org/~opal/java/policy.html/policy.html > > > > Some of it have to be rewritten so it states that it is no > > longer a proposed policy (when it is accepted). > > > > It anyone have comments on it please let me know. > > 2.5. Main, contrib or non-free > > > > If your binary package can run only with non-free virtual machines > (the only free Java virtual machine seems to be kaffe - and the one > included in libgcj), it cannot go to main. If your package itself is > free, it must go to contrib. > > There are many other free JVMs now: ORP, KissMe, etc... The Classpath > page at GNU references them: > >http://www.gnu.org/software/classpath Also, as the upstream kaffe maintainer, I'd really like it if for each package that was stuck in contrib because kaffe can't run it (eg. unimplemented APIs, etc), there was a "wishlist" bug filed against kaffe stating how it fails. I suppose that goes for the other JVMs too. Maybe that could be worked into the policy? Cheers, - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java Policy.
Sounds like Debian could use the same solution for gcj that Debian uses for emacs -> just distribute the .java files and do the ahead-of-time compilation (.java to .so) at install time. Is this automatic enough under gcj so that this could that work? Granted, the emacs solution is currently a bit klunky for the users, who have to put up with long compiles during install, but it does take the load off of the maintainers to have to precompile their stuff for multiple targets. Cheers, - Jim On Sun, 2002-05-12 at 16:28, Stephen Zander wrote: > >>>>> "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes: > Andrew> To clarify, I'm talking about Java code compiled (eg, by > Andrew> gcj) into architecture-specific machine code. These > Andrew> libraries are still meant to be used by Java code (also > Andrew> compiled with gcj), not C code. So I think java should > Andrew> still be part of the name. > > That statement is true iff you can use the gjc produced .so files with > kaffa/jdk/etc without *any* additional coding/configuratiojn/whatever. > I don't think that condition is satisfiable right now. > > .java => gjc => executable/shared object is a one-way function. > > -- > Stephen > > "A duck!" > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java Policy.
> > There are many other free JVMs now: ORP, KissMe, etc... > > I am not very happy with trying to compile some Java code (e.g. Jmol > jmol.sf.net) with every free JVM to see wether it can be done with that... You should only have to compile the class files once (the classes should still work, even if they were compiled against a non-free JVM - if you're lucky). Based on the list of VMs I compiled for Kaffe website, there are maybe 20 free JVM implementations out there. I don't think it's reasonable to expect maintainers to have to try out their software on all the JVMs that might eventually wind up in Debian. > Thus confirming that Jmol only runs with non-free VMs is a bit hard to > tell... Ofcourse, the statement should say that the software does only > support to work with non-free VMs, or along that line... (Is it worthwhile to > change the text accordingly?) > > Something like: > > Only if your binary package can run with free virtual machines (like kaffe, > libgcj, ORP and KissMe), it may go into main. Otherwise, it must go into > non-free, or in contrib if your package itself is free. > > Does this sound ok? There are still going to be problems though - a Java application that runs on one VM might not run on another, because they are at different levels of maturity. But I guess that really is the fault of the VM and class libraries for not being compatible enough. > Anyway, about kaffe... it has been a very long time since I gave it a try... > Is it hard to port code from Sun's/Blackdown's JVM to kaffe? Do I need to > recompile or can kaffe run classes? Kaffe can just run the you build classes. You shouldn't have to "port" anything to it. Usually, the main problems you will see are with incomplete or missing API implementations, and the occasional bug. Kaffe hasn't had a new release in 2 years, but there has been work on the CVS version. As I'm the new guy running the project, I'm going to try to get a release out in the next month or so. I want to get a release candidate out in the next few days. Cheers, - jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java Policy.
On Sun, 2002-05-12 at 18:29, Per Bothner wrote: > Jim Pick wrote: > > Sounds like Debian could use the same solution for gcj that Debian uses > > for emacs -> just distribute the .java files and do the ahead-of-time > > compilation (.java to .so) at install time. Is this automatic enough > > under gcj so that this could that work? > > > I think it would be too slow. After all you don't do the .c to .so > compilation at installation time, so why should .java to .so be > different? I agree it would be slow. Just like Debian's emacs solution is slow. :-) I primarily wanted to say that it seemed like it was a similar type of problem. > Also, what happens if you install a Java package, and then install > gcj later? Shuld that so the compilation to .so when you install > gcj? Yep, the compilation would have to happen then, all the .class files would then get compiled to .so files (just like how the .el files get compiled to .elc files when installing xemacs/emacs). If the .class -> .so conversion process can be 100% automated, then maybe somebody can develop a system using the buildd servers that would automatically upload a package containing the converted .so files whenever a Java package is uploaded that conforms to the spec, so that the end users don't have to do the compiling. (Debian could do the same thing for the emacs packages too) Cheers, - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java Policy.
On Sun, 2002-05-12 at 17:16, Adam Heath wrote: > On 12 May 2002, Jim Pick wrote: > > > Also, as the upstream kaffe maintainer, I'd really like it if for each > > package that was stuck in contrib because kaffe can't run it (eg. > > unimplemented APIs, etc), there was a "wishlist" bug filed against kaffe > > stating how it fails. I suppose that goes for the other JVMs too. > > Maybe that could be worked into the policy? > > Er, no, this should not be part of policy. > > Policy should not mention any software, unless absolutely nescessary. And > this is not a nescessary reason. > > Ie, if this was done, it should be done for all free virtual machines, not > just kaffe. Kaffe, while being the one of the first, if not the first, is > just another vm, amoung several others. I guess my point was that I just don't like the status quo - where some software doesn't work, so it gets stuck in contrib, and the people trying to make the JVMs work don't get a bug report. Since one of the things I want to do with Kaffe is to try to run it against as much software as possible, I'd really love to get the bug reports. Cheers, - jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Free Java specifications (was Re: Java Policy.)
t so they could fix the problem. Now, I want to essentially do this work anyways, as part of documenting Kaffe and it's class libraries, and trying to pull in elements of Classpath, libgcj, ORP, etc. So you've got a volunteer. :-) I'd like to see it done as a standalone specification, useful to the free software community, which doesn't depend on Sun's specification. Again, that might anger Sun, even if the specification doesn't diverge from their specification. So it would be nice to have an established free software project "stand up" for the spec, and publish it for us. Somebody like Debian, or the GNU project, or perhaps Apache or maybe even FreeStandards.org. Theoretically, I suspect even the JCP could be used to host such a project, right under Sun's nose, but I suspect that there would be issues with the whole premise of the project (to promote free software implementations and APIs that in some cases, compete with Sun's offerings). So, what do people think? Cheers, - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [ANNOUNCE] JBoss 2.4.7 debs for public consumption
Cool. Looks like a lot of work. :-) I'll have to give 'em a try (and eventually, with Kaffe). Cheers, - Jim On Fri, 2002-06-28 at 18:33, Adam Heath wrote: > I am proud to announce that I have finally finished(well, close enough, > anyways) the debs of JBoss(www.jboss.org). You can fetch them by adding the > appropriate line(1) to /etc/apt/sources.list. > > These debs are modular, and broken up into semi-logic parts. To install > jboss, with catalina(tomcat4) support, and postgres integration, the following > command should be given: > > apt-get install jboss jboss-server jboss-dev jbossmq jbosssx > jboss-transaction jboss-catalina-service jboss-common jboss-contrib > jboss-contrib-oswego jboss-contrib-castor jboss-contrib-hsqldb > jboss-mail jboss-jdbc-postgresql jboss-client jbosssx-client > jbossmq-client jnp-client > > These packages also depend on sun jars. However, there are packages available > for these as well(jsse.deb, libactivation-java.deb, libmail-java.deb). We all > know the license for these is bad, but for time sakes, we(my work) have > decided to make them available. > > If someone were to make a deb of jetty, I could get jetty to work with jboss. > I have already done the work locally, but because no deb exists, there is no > standard support for it. > > There is also a deb to make mysql work, but that depends on a non-existant(in > debian anyways) mysql-java library. If someone is interested in making > packages of it, let me know, and I'll tell you were to get the files. > > Additionally, JBoss upstream redistributes lots of external software in their > source archive. I have not attempted to make packages of these. For the most > part, these libraries exist in jboss-contrib-* and jboss-contrib. If someone > wants to make packages of those, then go ahead. However, you should notify me > when you do, so I can update the JBoss packages to not include the software > anymore. > > The documentation on these packages is not the best(it's quite light). I'm > not that great at writing it. Volunteers for writing better docs on how JBoss > functions in Debian would be appreciated. > > So, install the debs, and tell me what you think. After those on this list > have had a chance to digest them, I will inform JBoss upstream of this > accomplishment. Until that time, I want those that are more familiar with > Java and Debian to test them. > > 1: deb http://mirror.brainfood.com/brainfood-public sid main contrib non-free > > ps: Several people have sent me private emails, asking for debs of JBoss. I > have bcc'd them with this mail. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
OpenOffice?
Hi, Here's a little project for somebody. The Debian people want to put OpenOffice in their distribution, but in order to build it, they need to use Java. But their free software guidelines prevent them from using Sun's version in the building of the software because it's non-free (so OpenOffice can't be build with the core set of Debian packages). I don't have time to look at it, but it would be nice to know if Kaffe could be used instead... Cheers, - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [kaffe] Re: OpenOffice?
Rene Engelhard wrote: Jim Pick wrote: Here's a little project for somebody. ... I don't have time to look at it, but it would be nice to know if Kaffe could be used instead... Well, I assume you mean "little" in jest. Building OpenOffice is never a small thing (the full build runs about 20 hours). It has 109K lines in 482 files of Java alone. Anyhow, the following is a list of the "import" lines from OpenOffice 1.0 source. This build assumes JDK 1.3, and they are moving (or have already) to conditionally support JDK 1.4 for the Accessibility API. This list is not broken down to sort out what modules need what Java features. OpenOffice uses Java in at least three major areas: Setup, Help, and UNO (OpenOffice's networked object interface) and will be four with the addition of Accessibility. But it does give an idea of the scope of the work. jim white - import com.jclark.xsl.dom.Transform; import com.jclark.xsl.dom.TransformEngine; import com.jclark.xsl.dom.TransformException; import com.jclark.xsl.dom.XSLTransformEngine; import com.jclark.xsl.om.*; import com.jclark.xsl.om.Name; import com.jclark.xsl.om.NamespacePrefixMap; import com.jclark.xsl.om.Node; import com.jclark.xsl.om.XSLException; import com.jclark.xsl.sax.*; import com.jclark.xsl.sax.Driver; import com.jclark.xsl.sax.OutputStreamDestination; import com.jclark.xsl.sax.XSLProcessor; import com.jclark.xsl.tr.LoadContext; import com.jclark.xsl.tr.OutputMethod; import com.jclark.xsl.tr.Result; import com.sleepycat.db.*; import com.sun.jini.admin.DestroyAdmin; import com.sun.jini.discovery.LookupLocatorDiscovery; import com.sun.jini.lease.LeaseRenewalManager; import com.sun.jini.lookup.JoinManager; import com.sun.jini.lookup.ServiceIDListener; import com.sun.jini.lookup.entry.BasicServiceType; import com.sun.xml.parser.Parser; import com.sun.xml.parser.Resolver; import com.sun.xml.parser.ValidatingParser; import com.sun.xml.tree.*; import com.sun.xml.tree.XmlDocument; import java.applet.*; import java.applet.Applet; import java.applet.AppletContext; import java.applet.AppletStub; import java.applet.AudioClip; import java.awt.*; import java.awt.BorderLayout; import java.awt.Button; import java.awt.Color; import java.awt.Container; import java.awt.Dialog; import java.awt.Dimension; import java.awt.FlowLayout; import java.awt.Frame; import java.awt.Graphics; import java.awt.GridBagConstraints; import java.awt.GridBagLayout; import java.awt.GridLayout; import java.awt.Image; import java.awt.Insets; import java.awt.List; import java.awt.MenuBar; import java.awt.Panel; import java.awt.Rectangle; import java.awt.TextArea; import java.awt.Toolkit; import java.awt.Window; import java.awt.event.*; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.awt.event.ComponentEvent; import java.awt.event.ComponentListener; import java.awt.event.FocusEvent; import java.awt.event.FocusListener; import java.awt.event.InputEvent; import java.awt.event.ItemEvent; import java.awt.event.ItemListener; import java.awt.event.KeyEvent; import java.awt.event.KeyListener; import java.awt.event.MouseEvent; import java.awt.event.MouseListener; import java.awt.event.MouseMotionListener; import java.awt.event.WindowAdapter; import java.awt.event.WindowEvent; import java.awt.image.ImageConsumer; import java.awt.image.ImageObserver; import java.awt.image.ImageProducer; import java.beans.Beans; import java.io.*; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; import java.io.BufferedReader; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.DataInput; import java.io.DataInputStream; import java.io.DataOutput; import java.io.DataOutputStream; import java.io.EOFException; import java.io.File; import java.io.FileDescriptor; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.FileOutputStream; import java.io.FileReader; import java.io.FileWriter; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; import java.io.LineNumberReader; import java.io.OutputStream; import java.io.PipedInputStream; import java.io.PipedOutputStream; import java.io.PrintStream; import java.io.PrintWriter; import java.io.RandomAccessFile; import java.io.Reader; import java.io.Serializable; import java.io.StreamTokenizer; import java.io.StringBufferInputStream; import java.io.StringWriter; import java.io.UnsupportedEncodingException; import java.lang.ClassCastException; import java.lang.Exception; import java.lang.Object; import java.lang.Object; import java.lang.ref.WeakReference; import java.lang.reflect.Array; import java.lang.reflect.Constructor; import java.lang.reflect.Field; import java.lang.reflect.InvocationTargetException; import java.lang.reflect.Method; import java.lang.reflect.Modifier; import java.net.*; import java.net.InetAddress; import java.net.MalformedURLException; i
JSP error on simple page.
I have been running apache for a while now. Today I installed gnujsp, jserv, kaffe, jikes, and ??? (any other default dependency selection for gnujsp). All of this was installed from woody (unstable) using dselect. I did not play with the gnujsp configuration at all. When browsing the below file, called /var/www/index.jsp, with Internet Explorer: Test Test JSP page This is a date test: <%= new java.util.Date() %>. I get the following error in the browser: Error compiling source file: file:/var/www/index.jsp sun/tools/javac/Main Any ideas on why this is occurring? It seems to me that I might be missing a Java jar file, but shouldn't that have been installed by the dselect? I would be happy to RTFM if you could point me to the manual that would cover this error. I have checked out the debian.org mail list archives. I did not seen anything relevant. Thanks in advance for any info, Jim Brennan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Java error in Mozilla
Could somebody here kindly check out Debian Bug #114265 > INTERNAL ERROR on Browser End: > Could not load /usr/lib/j2re1.3/lib/i386/libjavaplugin_oji.so: > linking error=/usr/lib/j2re1.3/lib/i386/libjavaplugin_oji.so: > undefined symbol: XtShellStrings > System error?:: Invalid argument The Mozilla maintainer claims it's a Java error. Thanks, js -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: deb for netbeans
> I thought that the build process of OpenOffice depended on [I'm being > vague here :-(] "some bundle of Java2 stuff," which would have the > result that despite OpenOffice itself being "free software," since a > build requires distinctly nonfree stuff, it can't go in "free." > > It's almost enough to make you want to throw up your hands and say, "why > bother trying?" Is there any chance it could be built with kaffe? Even if it can't be built with kaffe, as the kaffe maintainer, I'd like to know what's missing from kaffe so I can update the "projects" page on the website. Cheers, - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Kaffe and Java2
Hi, I just noticed in the Debian Java FAQ that it says that Kaffe is not going to be implementing Java2 (for legal reasons). I don't think that's correct. I want to see as much of the Java2 APIs implemented as possible in Kaffe. It will probably be a long time before we have all of Java2 implemented, because Sun threw everything and the kitchen sink in there. Sure, Sun's lawyers put some silly, confusing, unenforceable stuff in their legal wording accompanying their docs, but I don't think it's worth repeating. In fact, I think it's important to take a stand on the legal issues from time to time, and not just roll over dead everytime somebody starts playing lawyer games. It would be counter-productive and really bad for Sun to even think about trying to enforce such a clause against a free software project -- and I doubt that there is even a basis for it in copyright law (although the DMCA is quite scary in how drastically it scales back fair use rights). However, Sun could probably stick anybody with unrelated patents if they really wanted to. I'll gladly accept patches for free implementations of Java APIs that match the Java2 spec (but technically, we're not Java, since that's a registered trademark of Sun, and neither are we Java2). Kaffe already has some Java2 stuff implemented in it. Cheers, - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java Policy.
On Sun, 2002-05-12 at 08:11, Nic Ferrier wrote: > Ola Lundqvist <[EMAIL PROTECTED]> writes: > > > Hi > > > > When we now have (almost) got woody out of the door I think it > > is time to give the Proposed Java Policy a more official state > > (i.e. not proposed anymore). > > > > It is available at: > > > > http://people.debian.org/~opal/java/policy.html/ > > The actual policy is avalable at: > > http://people.debian.org/~opal/java/policy.html/policy.html > > > > Some of it have to be rewritten so it states that it is no > > longer a proposed policy (when it is accepted). > > > > It anyone have comments on it please let me know. > > 2.5. Main, contrib or non-free > > > > If your binary package can run only with non-free virtual machines > (the only free Java virtual machine seems to be kaffe - and the one > included in libgcj), it cannot go to main. If your package itself is > free, it must go to contrib. > > There are many other free JVMs now: ORP, KissMe, etc... The Classpath > page at GNU references them: > >http://www.gnu.org/software/classpath Also, as the upstream kaffe maintainer, I'd really like it if for each package that was stuck in contrib because kaffe can't run it (eg. unimplemented APIs, etc), there was a "wishlist" bug filed against kaffe stating how it fails. I suppose that goes for the other JVMs too. Maybe that could be worked into the policy? Cheers, - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java Policy.
Sounds like Debian could use the same solution for gcj that Debian uses for emacs -> just distribute the .java files and do the ahead-of-time compilation (.java to .so) at install time. Is this automatic enough under gcj so that this could that work? Granted, the emacs solution is currently a bit klunky for the users, who have to put up with long compiles during install, but it does take the load off of the maintainers to have to precompile their stuff for multiple targets. Cheers, - Jim On Sun, 2002-05-12 at 16:28, Stephen Zander wrote: > >>>>> "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes: > Andrew> To clarify, I'm talking about Java code compiled (eg, by > Andrew> gcj) into architecture-specific machine code. These > Andrew> libraries are still meant to be used by Java code (also > Andrew> compiled with gcj), not C code. So I think java should > Andrew> still be part of the name. > > That statement is true iff you can use the gjc produced .so files with > kaffa/jdk/etc without *any* additional coding/configuratiojn/whatever. > I don't think that condition is satisfiable right now. > > .java => gjc => executable/shared object is a one-way function. > > -- > Stephen > > "A duck!" > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java Policy.
> > There are many other free JVMs now: ORP, KissMe, etc... > > I am not very happy with trying to compile some Java code (e.g. Jmol > jmol.sf.net) with every free JVM to see wether it can be done with that... You should only have to compile the class files once (the classes should still work, even if they were compiled against a non-free JVM - if you're lucky). Based on the list of VMs I compiled for Kaffe website, there are maybe 20 free JVM implementations out there. I don't think it's reasonable to expect maintainers to have to try out their software on all the JVMs that might eventually wind up in Debian. > Thus confirming that Jmol only runs with non-free VMs is a bit hard to > tell... Ofcourse, the statement should say that the software does only > support to work with non-free VMs, or along that line... (Is it worthwhile to > change the text accordingly?) > > Something like: > > Only if your binary package can run with free virtual machines (like kaffe, > libgcj, ORP and KissMe), it may go into main. Otherwise, it must go into > non-free, or in contrib if your package itself is free. > > Does this sound ok? There are still going to be problems though - a Java application that runs on one VM might not run on another, because they are at different levels of maturity. But I guess that really is the fault of the VM and class libraries for not being compatible enough. > Anyway, about kaffe... it has been a very long time since I gave it a try... > Is it hard to port code from Sun's/Blackdown's JVM to kaffe? Do I need to > recompile or can kaffe run classes? Kaffe can just run the you build classes. You shouldn't have to "port" anything to it. Usually, the main problems you will see are with incomplete or missing API implementations, and the occasional bug. Kaffe hasn't had a new release in 2 years, but there has been work on the CVS version. As I'm the new guy running the project, I'm going to try to get a release out in the next month or so. I want to get a release candidate out in the next few days. Cheers, - jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java Policy.
On Sun, 2002-05-12 at 18:29, Per Bothner wrote: > Jim Pick wrote: > > Sounds like Debian could use the same solution for gcj that Debian uses > > for emacs -> just distribute the .java files and do the ahead-of-time > > compilation (.java to .so) at install time. Is this automatic enough > > under gcj so that this could that work? > > > I think it would be too slow. After all you don't do the .c to .so > compilation at installation time, so why should .java to .so be > different? I agree it would be slow. Just like Debian's emacs solution is slow. :-) I primarily wanted to say that it seemed like it was a similar type of problem. > Also, what happens if you install a Java package, and then install > gcj later? Shuld that so the compilation to .so when you install > gcj? Yep, the compilation would have to happen then, all the .class files would then get compiled to .so files (just like how the .el files get compiled to .elc files when installing xemacs/emacs). If the .class -> .so conversion process can be 100% automated, then maybe somebody can develop a system using the buildd servers that would automatically upload a package containing the converted .so files whenever a Java package is uploaded that conforms to the spec, so that the end users don't have to do the compiling. (Debian could do the same thing for the emacs packages too) Cheers, - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java Policy.
On Sun, 2002-05-12 at 17:16, Adam Heath wrote: > On 12 May 2002, Jim Pick wrote: > > > Also, as the upstream kaffe maintainer, I'd really like it if for each > > package that was stuck in contrib because kaffe can't run it (eg. > > unimplemented APIs, etc), there was a "wishlist" bug filed against kaffe > > stating how it fails. I suppose that goes for the other JVMs too. > > Maybe that could be worked into the policy? > > Er, no, this should not be part of policy. > > Policy should not mention any software, unless absolutely nescessary. And > this is not a nescessary reason. > > Ie, if this was done, it should be done for all free virtual machines, not > just kaffe. Kaffe, while being the one of the first, if not the first, is > just another vm, amoung several others. I guess my point was that I just don't like the status quo - where some software doesn't work, so it gets stuck in contrib, and the people trying to make the JVMs work don't get a bug report. Since one of the things I want to do with Kaffe is to try to run it against as much software as possible, I'd really love to get the bug reports. Cheers, - jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Free Java specifications (was Re: Java Policy.)
t so they could fix the problem. Now, I want to essentially do this work anyways, as part of documenting Kaffe and it's class libraries, and trying to pull in elements of Classpath, libgcj, ORP, etc. So you've got a volunteer. :-) I'd like to see it done as a standalone specification, useful to the free software community, which doesn't depend on Sun's specification. Again, that might anger Sun, even if the specification doesn't diverge from their specification. So it would be nice to have an established free software project "stand up" for the spec, and publish it for us. Somebody like Debian, or the GNU project, or perhaps Apache or maybe even FreeStandards.org. Theoretically, I suspect even the JCP could be used to host such a project, right under Sun's nose, but I suspect that there would be issues with the whole premise of the project (to promote free software implementations and APIs that in some cases, compete with Sun's offerings). So, what do people think? Cheers, - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
OpenOffice?
Hi, Here's a little project for somebody. The Debian people want to put OpenOffice in their distribution, but in order to build it, they need to use Java. But their free software guidelines prevent them from using Sun's version in the building of the software because it's non-free (so OpenOffice can't be build with the core set of Debian packages). I don't have time to look at it, but it would be nice to know if Kaffe could be used instead... Cheers, - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [kaffe] Re: OpenOffice?
Rene Engelhard wrote: > Jim Pick wrote: > >>Here's a little project for somebody. >>... >>I don't have time to look at it, but it would be nice to know if Kaffe >>could be used instead... Well, I assume you mean "little" in jest. Building OpenOffice is never a small thing (the full build runs about 20 hours). It has 109K lines in 482 files of Java alone. Anyhow, the following is a list of the "import" lines from OpenOffice 1.0 source. This build assumes JDK 1.3, and they are moving (or have already) to conditionally support JDK 1.4 for the Accessibility API. This list is not broken down to sort out what modules need what Java features. OpenOffice uses Java in at least three major areas: Setup, Help, and UNO (OpenOffice's networked object interface) and will be four with the addition of Accessibility. But it does give an idea of the scope of the work. jim white - import com.jclark.xsl.dom.Transform; import com.jclark.xsl.dom.TransformEngine; import com.jclark.xsl.dom.TransformException; import com.jclark.xsl.dom.XSLTransformEngine; import com.jclark.xsl.om.*; import com.jclark.xsl.om.Name; import com.jclark.xsl.om.NamespacePrefixMap; import com.jclark.xsl.om.Node; import com.jclark.xsl.om.XSLException; import com.jclark.xsl.sax.*; import com.jclark.xsl.sax.Driver; import com.jclark.xsl.sax.OutputStreamDestination; import com.jclark.xsl.sax.XSLProcessor; import com.jclark.xsl.tr.LoadContext; import com.jclark.xsl.tr.OutputMethod; import com.jclark.xsl.tr.Result; import com.sleepycat.db.*; import com.sun.jini.admin.DestroyAdmin; import com.sun.jini.discovery.LookupLocatorDiscovery; import com.sun.jini.lease.LeaseRenewalManager; import com.sun.jini.lookup.JoinManager; import com.sun.jini.lookup.ServiceIDListener; import com.sun.jini.lookup.entry.BasicServiceType; import com.sun.xml.parser.Parser; import com.sun.xml.parser.Resolver; import com.sun.xml.parser.ValidatingParser; import com.sun.xml.tree.*; import com.sun.xml.tree.XmlDocument; import java.applet.*; import java.applet.Applet; import java.applet.AppletContext; import java.applet.AppletStub; import java.applet.AudioClip; import java.awt.*; import java.awt.BorderLayout; import java.awt.Button; import java.awt.Color; import java.awt.Container; import java.awt.Dialog; import java.awt.Dimension; import java.awt.FlowLayout; import java.awt.Frame; import java.awt.Graphics; import java.awt.GridBagConstraints; import java.awt.GridBagLayout; import java.awt.GridLayout; import java.awt.Image; import java.awt.Insets; import java.awt.List; import java.awt.MenuBar; import java.awt.Panel; import java.awt.Rectangle; import java.awt.TextArea; import java.awt.Toolkit; import java.awt.Window; import java.awt.event.*; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.awt.event.ComponentEvent; import java.awt.event.ComponentListener; import java.awt.event.FocusEvent; import java.awt.event.FocusListener; import java.awt.event.InputEvent; import java.awt.event.ItemEvent; import java.awt.event.ItemListener; import java.awt.event.KeyEvent; import java.awt.event.KeyListener; import java.awt.event.MouseEvent; import java.awt.event.MouseListener; import java.awt.event.MouseMotionListener; import java.awt.event.WindowAdapter; import java.awt.event.WindowEvent; import java.awt.image.ImageConsumer; import java.awt.image.ImageObserver; import java.awt.image.ImageProducer; import java.beans.Beans; import java.io.*; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; import java.io.BufferedReader; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.DataInput; import java.io.DataInputStream; import java.io.DataOutput; import java.io.DataOutputStream; import java.io.EOFException; import java.io.File; import java.io.FileDescriptor; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.FileOutputStream; import java.io.FileReader; import java.io.FileWriter; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; import java.io.LineNumberReader; import java.io.OutputStream; import java.io.PipedInputStream; import java.io.PipedOutputStream; import java.io.PrintStream; import java.io.PrintWriter; import java.io.RandomAccessFile; import java.io.Reader; import java.io.Serializable; import java.io.StreamTokenizer; import java.io.StringBufferInputStream; import java.io.StringWriter; import java.io.UnsupportedEncodingException; import java.lang.ClassCastException; import java.lang.Exception; import java.lang.Object; import java.lang.Object; import java.lang.ref.WeakReference; import java.lang.reflect.Array; import java.lang.reflect.Constructor; import java.lang.reflect.Field; import java.lang.reflect.InvocationTargetException; import java.lang.reflect.Method; import java.lang.reflect.Modifier; import java.net.*; import java.net.InetAddress; im
Re: as the worst
Notice ALERT: This is your Second Notification, there now are two potential deals for your review. Please note that past credit history is a non-issue as long as you respond in a timely fashion. Verify your information with our secure form to ensure our records are accurate. http://www.fundingtalk.com/index.php?refid=windsor We look forward to helping you secure your future. --Jim Jarvis Financial Analyst - LRA Inc. Did this reach you in error? please let us know so you won't recieve again: http://www.fundingtalk.com/r.php -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
