Re: Linux Kongress 2003 in Saarbruecken, Germany
Dalibor Topic [EMAIL PROTECTED] wrote on Mon, 14 Jul 2003 21:05:33 +0200: Mark Wielaard has already said that I'd like the next free software java develeper meeting to be in Saarbruecken, which hosts the Linux Kongress from October 14 to October 16, 2003. I hope we can use this Kongress as an oppportunity to present the current state of free java implementations to a broader audience. And of course to have a BOF session, a couple of drinks and a good time. Here's a draft for an extended abstract, see below. Any comments? Would anyone be interested in doing the talk together? (I think that would be good, because otherwise my contribution to Classpath might appear larger than it actually is). IMHO, it would be great if there also were separate talks about the VMs. Also, would anyone be interested in a BoF session about Java graphics? What other talks/BoFs do people have in mind? Best, -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ PS: Dalibor has sent the call for papers both to [EMAIL PROTECTED] and [EMAIL PROTECTED], which is why I am sending this to both. But I guess we probably should have the discussion on the classpath list. == GNU Classpath -- Freedom for Java [FIXME: Is the title too snappy?] Java has become the tool of choice for many software developers. Although good marketing was probably a big, if not the most important factor to Java's success, there also exist technical properties which make the combination of language and associated class libraries a very attractive platform. In this talk, we explain why we think that Java is good for writing free software. After briefly reviewing some projects for free Virtual Machines, the main section discusses the current state of GNU Classpath. The goal of GNU Classpath is to implement the class library of the Java platform. Due to the richness of that library, GNU Classpath is a very large and ambitious project. But this very richness also means that Free Software developers can use a reasonably well designed, object-oriented framework that covers more most needs of a typical application. Because Java is accepted by the mainstream, many developers are already familiar with the framework, which means that they can quickly write free software. GNU Classpath has made much more progress than many might think. In a live demonstration, we refute the widespread belief that it would not be possible to run large Java projects in an entirely free environment. Nonetheless, many important parts are still missing. The talk thus concludes by showing how volunteers can contribute to GNU Classpath, and in which areas help would be most appreciated. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath/native/jni/classpath jcl.c jcl.h
Hi, On Wed, 2003-07-16 at 11:39, Torsten Rupp wrote: Modified files: native/jni/classpath: jcl.c jcl.h Log message: Fixed some prototypes Besides the obviously correct const char fixes this includes the following: +/* do not move; needed here because of some macro definitions */ +#include jamaica_config.h Which clearly won't work with other VMs. Please fix. Thanks, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
JNI header files
Hi, We don't seem to have real build support for creating JNI header files but instead have pre-generated .h files in our include file. Why is that? We do seem to detect which javah like program the user has installed. On my system it correctly detects gcjh. I would like them to be generated at build time so they won't get out of sync by accident. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: JNI header files
Hi Mark, On Wednesday 16 July 2003 12:44, Mark Wielaard wrote: We don't seem to have real build support for creating JNI header files but instead have pre-generated .h files in our include file. Why is that? We do seem to detect which javah like program the user has installed. On my system it correctly detects gcjh. I would like them to be generated at build time so they won't get out of sync by accident. I assume gcjh is implemented in C? jamaicah is implemented in Java, so we have a bootstrap problem if we don't checkin the generated headers. We can solve this by checking in the JNI headers into our own repository only and remove it from the Classpath repository, but in case other VMs have similar problems, it might be better to check in the headers. Cheers, Andy. -- aicas GmbH /\ ASCII Ribbon Campaign Haid-und-Neu-Straße 18 * 76131 Karlsruhe \ / No HTML or RTF in mail http://www.aicas.com X No MS-Word in mail Tel: +49-721-663 968-24; Fax: +49-721-663 968-94 / \ Respect Open Standards ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: JNI header files
Mark Wielaard [EMAIL PROTECTED] writes: Hi, We don't seem to have real build support for creating JNI header files but instead have pre-generated .h files in our include file. Why is that? We do seem to detect which javah like program the user has installed. On my system it correctly detects gcjh. I would like them to be generated at build time so they won't get out of sync by accident. The native side wasn't changing much and keeping the header generation was more pain (to me) than just checking them in. I don't think it would be so bad if you added a target somewhere that regenerated them but wasn't part of the usual build. For distributions I wanted to distribute the headers as well. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: JNI header files
Hi, On Wed, 2003-07-16 at 13:26, Andy Walter wrote: I assume gcjh is implemented in C? jamaicah is implemented in Java, so we have a bootstrap problem if we don't checkin the generated headers. We can solve this by checking in the JNI headers into our own repository only and remove it from the Classpath repository, but in case other VMs have similar problems, it might be better to check in the headers. Good point. kaffeh and gcjh are indeed both C implementations. Brian said it would be a good thing to supply header files with the distribution. But a build target to regenerate the files would be nice. Then it would be easy to check if the checked in files are still correct. Any takers to hack the make files? Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Dependencies files
Dear Classpath members, I added some files with the names class-dependencies.conf in some Java package directories. These files describe dependencies of class/methods/fields as a property file. The data can be used if a VM tool want to link classes to an static linked application, like our JamaicaVM tool Builder can do. We use these dependencies to detect which classes/methods/fields have to be linked to the build application if some class/method/field is used. This is important if the dependencies to some classes/methods/fields are can be detected completely by a class-analysis, e. g. if some field in a class is accessed in some native-methods. Please have a look into the files and feel free to add dependencies which are still missing. If the dependency information is not needed in your VM, yust ignore the files. Sincerely, Torsten ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Linux Kongress 2003 in Saarbruecken, Germany
Hi, On Wed, 2003-07-16 at 10:51, Sascha Brawer wrote: Here's a draft for an extended abstract, see below. Any comments In general be careful of your use of the word java. We don't want to give the impression that we implement java, which is a trademarked word used to describe particular (proprietary) implementations. That is why we call the project GNU Classpath, essential libraries for the java language or something similar descriptive. See also http://www.fsf.org/prep/standards_5.html You should also mention that some dedicated people have been working on GNU Classpath for the last five years. That explains why we are as far as we are now. Consistently doing little steps for a couple of years does work to make progress. Would anyone be interested in doing the talk together? I can certainly act as the lovely assistant who does the demos :) IMHO, it would be great if there also were separate talks about the VMs. I would like to see talks about: - Kaffe, the NetBSD of VMs (we show you what portability means) - GCJ, doing it the traditional way (or how to generate the fasted code on earth) - JRVM, implementing the difficult stuff in an easy language. - IKVM.NET, cooperation and integration in the extreme. Also, would anyone be interested in a BoF session about Java graphics? What other talks/BoFs do people have in mind? I really want to spend some time the next couple of months on Mauve or just tests in general and on making the VM interface even more abstract. Both topics would be nice to evaluate with some people. And from the meeting in Karlsruhe I got the impression that people would be interested in some common (native) library format to reuse the output of a ahead of time or just in time compiler. (BTW found the paper that I mentioned: http://flint.cs.yale.edu/flint/publications/bincomp.html) GNU Classpath -- Freedom for Java [FIXME: Is the title too snappy?] Freedom to Innovate :) Seriously. I think GNU Classpath is the boring project. It is what it enables people do with it that makes it so exciting! Having people create big complex free programs on top of it like Eclipse (http://www.eclipse.org/) or XWT (http://www.xwt.org/) is nice. And writing application in an easy language for the GNOME framework is really productive. And we are also the catalyst for all these cool VM/Compiler projects mentioned above. Giving people the freedom to do these kinds of innovative things without them being controlled/sanctioned by someone is why I think GNU Classpath is meaningful. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Fixes for your native/target/generic/target_generic_file.h changes
Hi Torsten,
The following patches are required to get the most recent version of
target_generic_file.h to compile. Can you please check and apply them
to the Classpath CVS?
[Hint for others: it is necessary to rerun autoheader, automake,
autoconf and ./configure after apply this patch.]
Thanks,
-- Steve
Index: configure.in
===
RCS file: /cvsroot/classpath/classpath/configure.in,v
retrieving revision 1.126
diff -p -r1.126 configure.in
*** configure.in2 Jul 2003 09:16:52 - 1.126
--- configure.in16 Jul 2003 14:52:07 -
*** dnl Checks for programs.
*** 91,97
if test x${COMPILE_JNI} = xyes; then
AC_HEADER_STDC
! AC_CHECK_HEADERS(unistd.h sys/types.h sys/config.h sys/ioctl.h asm/ioctls.h
inttypes.h stdint.h)
AC_EGREP_HEADER(uint32_t, stdint.h, AC_DEFINE(HAVE_INT32_DEFINED, 1, [Define to 1
if you have uint32_t]))
AC_EGREP_HEADER(uint32_t, inttypes.h, AC_DEFINE(HAVE_INT32_DEFINED, 1, [Define to
1 if you have uint32_t]))
AC_EGREP_HEADER(u_int32_t, sys/types.h, AC_DEFINE(HAVE_BSD_INT32_DEFINED, 1,
[Define to 1 if you have BSD u_int32_t]))
--- 91,97
if test x${COMPILE_JNI} = xyes; then
AC_HEADER_STDC
! AC_CHECK_HEADERS(unistd.h sys/types.h sys/config.h sys/ioctl.h asm/ioctls.h
inttypes.h stdint.h utime.h sys/utime.h)
AC_EGREP_HEADER(uint32_t, stdint.h, AC_DEFINE(HAVE_INT32_DEFINED, 1, [Define to 1
if you have uint32_t]))
AC_EGREP_HEADER(uint32_t, inttypes.h, AC_DEFINE(HAVE_INT32_DEFINED, 1, [Define to
1 if you have uint32_t]))
AC_EGREP_HEADER(u_int32_t, sys/types.h, AC_DEFINE(HAVE_BSD_INT32_DEFINED, 1,
[Define to 1 if you have BSD u_int32_t]))
Index: native/target/generic/target_generic_file.h
===
RCS file: /cvsroot/classpath/classpath/native/target/generic/target_generic_file.h,v
retrieving revision 1.6
diff -p -r1.6 target_generic_file.h
*** native/target/generic/target_generic_file.h 16 Jul 2003 13:30:56 -
1.6
--- native/target/generic/target_generic_file.h 16 Jul 2003 14:52:08 -
*** extern C {
*** 624,632
#include sys/types.h
#include sys/stat.h
#include unistd.h
! #ifdef HAVE_UTIME
#include utime.h
! #elif HAVE_SYS_UTIME
#include sys/utime.h
#else
#error utime.h not found. Please check configuration.
--- 624,632
#include sys/types.h
#include sys/stat.h
#include unistd.h
! #ifdef HAVE_UTIME_H
#include utime.h
! #elif HAVE_SYS_UTIME_H
#include sys/utime.h
#else
#error utime.h not found. Please check configuration.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath ChangeLog
Hi, On Wed, 2003-07-16 at 17:18, Torsten Rupp wrote: Log message: 2003-07-16 Torsten Rupp [EMAIL PROTECTED] * configure.in: Some fixes for target native layer (reported by Stephen Crawley) 2003-07-16 Torsten Rupp [EMAIL PROTECTED] * native/target/generic/target_generic_file.h: Some fixes for target native layer (reported by Stephen Crawley) One little nit. You have to forgive me, as a new maintainer I am still a bit uptight. If that doesn't go away in a month or so please kick me or else I will probably burn up very quickly anyway :) A ChangeLog entry should be more precise then this. It doesn't have to explain everything about the change or why it changed (put that as a comment in the code if necessary). But it should explain exactly what has changed. That makes finding bugs later so much easier. Also the name in the ChangeLog entry does not have to be the person who actually committed the change, it can be the contributer that submitted the patch. So instead of the above I would have written: 2003-07-16 Stephen Crawley [EMAIL PROTECTED] configure.in (AC_CHECK_HEADERS): Add utime.h and sys/utime.h. native/target/generic/target_generic_file.h: Check includes for HAVE_UTIME_H or HAVE_SYS_UTIME_H. There is more on ChangeLogs in the GNU Coding Standards http://www.gnu.org/prep/standards_40.html And I like the essay by Jim Blandy Maintaining the ChangeLog: http://www.red-bean.com/cvs2cl/changelogs.html End of pedantic mode. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Dependencies files
Dr. Torsten Rupp [EMAIL PROTECTED] writes: Dear Classpath members, I added some files with the names class-dependencies.conf in some Java package directories. These files describe dependencies of class/methods/fields as a property file. The data can be used if a VM tool want to link classes to an static linked application, like our JamaicaVM tool Builder can do. We use these dependencies to detect which classes/methods/fields have to be linked to the build application if some class/method/field is used. This is important if the dependencies to some classes/methods/fields are can be detected completely by a class-analysis, e. g. if some field in a class is accessed in some native-methods. Please have a look into the files and feel free to add dependencies which are still missing. If the dependency information is not needed in your VM, yust ignore the files. Hmm, got any program to contribute that generates these .conf files? Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
