Re: Building choices (was: Re: Code contribution to harmony)
On 11/23/05, Graeme Johnson [EMAIL PROTECTED] wrote: 'make' also simplifies the bootstrapping issue. When you are doing the initial port of the VM to a new platform, and you don't have java running yet, having your build instructions encoded in Ant is problematic. Well, good point. However, as it was suggested earlier in the thread, let's separate the building platforms and the target platforms. I would expect that one most likely will choose some conventional platform for the development and building. Hence, there is a high probability that Java is already available there. Bootstraping for Javaless platforms can be solved with C cross compiler. GCC does exactly the same to bootstrap. Relying on the availability of a previous java port to get the Harmony VM building seems like a questionable porting story. 'make' of one flavor or another is pretty much universally available, and seems like the pragmatic choice for building C code. I would agree that make is the preferred choice for any Unix developers. The problem actually comes when we start to develop on Windows (I believe, there still be a plenty of such developers). Let's consider the specific example – I'm building on Windows. I can use nmake, but, it is MSVC specific and is not available on Linux, hence it can't be our choice. Next, I'll try to use gmake – this, however, requires me to install cygwin in addition to MSVC. Note that I already have Java installed since I'm building the java sources with ant. Then the question comes, why do I have to install something else? The problem is that C development toolset isn't necessarily associated with the make toolset, and the make toolsets are not always compatible with each other. Make-based builds sometimes tend to do not work even between the different Linux distributions, if not specially hacked. Java luckily conforms to a single standard, hence works everywhere similarly, if only available. I'm currently working on preparing a prototype of a full ant-based build system which would allow to build the provided class libraries contributions. Perhaps it would make sense to return to this talk some time later if I get the prototype working. Thank you, Andrey Chernyshev Intel Managed Runtime Division
Re: Building choices (was: Re: Code contribution to harmony)
Tim Ellison [EMAIL PROTECTED] wrote on 11/21/2005 07:17:16 AM: Andrey Chernyshev wrote: On 11/15/05, Tim Ellison [EMAIL PROTECTED] wrote: In the end we decided to go with a 'conventional' native code tool set for the native source, and 'conventional' Java code tools for the Java source. People just felt more comfortable with that. Do you think we are missing out on something ;-) ? Well, I can see a few potential issues with such mixed approach: - In order to contribute, people would have to learn both building technologies - Ant and make, someone may give up. I don't see a great advantage to asking people to learn 'cpptask' rather than 'make'. I would suggest that many more C programmers are familiar with 'make' already, so we are not asking them to learn something new. [snip] 'make' also simplifies the bootstrapping issue. When you are doing the initial port of the VM to a new platform, and you don't have java running yet, having your build instructions encoded in Ant is problematic. Relying on the availability of a previous java port to get the Harmony VM building seems like a questionable porting story. 'make' of one flavor or another is pretty much universally available, and seems like the pragmatic choice for building C code. Graeme Johnson J9 VM Team, IBM Canada.
Re: Building choices (was: Re: Code contribution to harmony)
that is the most convincing argument till now. :-) bye :-) Ashish Ranjan India [EMAIL PROTECTED] On 11/23/05, Graeme Johnson [EMAIL PROTECTED] wrote: Tim Ellison [EMAIL PROTECTED] wrote on 11/21/2005 07:17:16 AM: Andrey Chernyshev wrote: On 11/15/05, Tim Ellison [EMAIL PROTECTED] wrote: In the end we decided to go with a 'conventional' native code tool set for the native source, and 'conventional' Java code tools for the Java source. People just felt more comfortable with that. Do you think we are missing out on something ;-) ? Well, I can see a few potential issues with such mixed approach: - In order to contribute, people would have to learn both building technologies - Ant and make, someone may give up. I don't see a great advantage to asking people to learn 'cpptask' rather than 'make'. I would suggest that many more C programmers are familiar with 'make' already, so we are not asking them to learn something new. [snip] 'make' also simplifies the bootstrapping issue. When you are doing the initial port of the VM to a new platform, and you don't have java running yet, having your build instructions encoded in Ant is problematic. Relying on the availability of a previous java port to get the Harmony VM building seems like a questionable porting story. 'make' of one flavor or another is pretty much universally available, and seems like the pragmatic choice for building C code. Graeme Johnson J9 VM Team, IBM Canada.
Re: Building choices (was: Re: Code contribution to harmony)
Matt Benson wrote: --- Ashish Ranjan [EMAIL PROTECTED] wrote: that is the most convincing argument till now. :-) +1 from an Ant PMC member. That logic is irrefutable. :) -Matt What about cross-compilation/cross-building ? If harmony is to be successful in its goal of wide portability I would expect that the build process would make cross-builds almost as easy as native builds. -- Robin bye :-) Ashish Ranjan India [EMAIL PROTECTED] On 11/23/05, Graeme Johnson [EMAIL PROTECTED] wrote: Tim Ellison [EMAIL PROTECTED] wrote on 11/21/2005 07:17:16 AM: Andrey Chernyshev wrote: On 11/15/05, Tim Ellison [EMAIL PROTECTED] wrote: In the end we decided to go with a 'conventional' native code tool set for the native source, and 'conventional' Java code tools for the Java source. People just felt more comfortable with that. Do you think we are missing out on something ;-) ? Well, I can see a few potential issues with such mixed approach: - In order to contribute, people would have to learn both building technologies - Ant and make, someone may give up. I don't see a great advantage to asking people to learn 'cpptask' rather than 'make'. I would suggest that many more C programmers are familiar with 'make' already, so we are not asking them to learn something new. [snip] 'make' also simplifies the bootstrapping issue. When you are doing the initial port of the VM to a new platform, and you don't have java running yet, having your build instructions encoded in Ant is problematic. Relying on the availability of a previous java port to get the Harmony VM building seems like a questionable porting story. 'make' of one flavor or another is pretty much universally available, and seems like the pragmatic choice for building C code. Graeme Johnson J9 VM Team, IBM Canada. __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
Re: Code contribution to harmony
On 11/15/05, Tim Ellison [EMAIL PROTECTED] wrote: In the end we decided to go with a 'conventional' native code tool set for the native source, and 'conventional' Java code tools for the Java source. People just felt more comfortable with that. Do you think we are missing out on something ;-) ? Well, I can see a few potential issues with such mixed approach: - In order to contribute, people would have to learn both building technologies - Ant and make, someone may give up. - Having make in addition to ant will introduce additional dependencies for the build. While make is available on Unix systems, it is not available on Windows by default, one would have to install it as a part of cygwin, MSVC or whatever. Another issue is that nmake that comes with MSVC and gmake are not compatible with each other. - Overall, ant possibly better suites the portability needs, at least between Windows and Linux As an example, I can suggest to look at Intel's contribution of the security package at http://issues.apache.org/jira/browse/HARMONY-16. Though the experts may say the example isn't ideal (the native part of security is really simple such that the build doesn't even utilize ant cpptask), it still may serve as illustration of the alternative approach, e.g. building a product using a single language. Thank you, Andrey Chernyshev Intel Managed Runtime Division
Building choices (was: Re: Code contribution to harmony)
Andrey Chernyshev wrote: On 11/15/05, Tim Ellison [EMAIL PROTECTED] wrote: In the end we decided to go with a 'conventional' native code tool set for the native source, and 'conventional' Java code tools for the Java source. People just felt more comfortable with that. Do you think we are missing out on something ;-) ? Well, I can see a few potential issues with such mixed approach: - In order to contribute, people would have to learn both building technologies - Ant and make, someone may give up. I don't see a great advantage to asking people to learn 'cpptask' rather than 'make'. I would suggest that many more C programmers are familiar with 'make' already, so we are not asking them to learn something new. However, the Ant cpptask wrappers the same platform compiler, so the complexity in terms of options etc. is equivalent. The resource dependency checking performed by Ant and make are both done 'behind the scenes' anyway. Was there some other part of Ant and make that you were thinking about? - Having make in addition to ant will introduce additional dependencies for the build. While make is available on Unix systems, it is not available on Windows by default, one would have to install it as a part of cygwin, MSVC or whatever. You are right, there is no C development environment shipped with Windows by default. I doubt we can fix that very easily :-) Everyone will need to install a C development environment to use cpptask too. Another issue is that nmake that comes with MSVC and gmake are not compatible with each other. Agreed. One of the many platform-specific areas we deal with everyday. At development time the differences include code and resource compilers, packaging and so on; at runtime the differences include resource management, OS APIs, etc. I see that in HARMONY-16 you have used break-out XML files (jaaswin.xml and jaasnix.xml) to deal with the build-time differences. That's fine. Some level of the tooling will have to bridge the differences. - Overall, ant possibly better suites the portability needs, at least between Windows and Linux There is a distinction to be drawn between the portability of the 'product' (i.e. the VM, class libaries, tools, etc.) that we are building, and the portability of the toolsuite that is used to build it. I'm not convinced of the need to make the development toolset portable across all platforms. I'd rather enable people to choose their development tooling within the broadest set of resources that we are prepared to support consistently. So if people want to use command-line tools (emacs, make), or IDEs (Eclipse CDT or VisualSudio) then they should be free to make that choice. As an example, I can suggest to look at Intel's contribution of the security package at http://issues.apache.org/jira/browse/HARMONY-16. Though the experts may say the example isn't ideal (the native part of security is really simple such that the build doesn't even utilize ant cpptask), it still may serve as illustration of the alternative approach, e.g. building a product using a single language. I think the discussion is simply at what point the Ant script does a platform-specific exec. When using 'make' the script calls-out early and uses make to manage the native code side dependencies; when using 'cpptask' the script calls-out later and uses Ant to manage the dependencies. We figured that 'make' was a more universal C build system than cpptask. Thank you, Andrey Chernyshev Intel Managed Runtime Division Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Building choices (was: Re: Code contribution to harmony)
On Mon, Nov 21, 2005 at 12:17:16PM +, Tim Ellison wrote: There is a distinction to be drawn between the portability of the 'product' (i.e. the VM, class libaries, tools, etc.) that we are building, and the portability of the toolsuite that is used to build it. Hmm. I'm not convinced of the need to make the development toolset portable across all platforms. Regardless of the relative merits of Ant and make and other alternatives (I tend to think both Ant and make are painful beyond a certain project size. Lately I've been a fan of scons (http://www.scons.org/)), having a stable, consistent, free, dependable, stable, easily accessible, stable (etc) build system is quite important for open source project success. I didn't say portable, but having a cross-platform (cross-make, cross-compiler, ...) build system means you only need to maintain one which might mean all those other factors are consistently taken care of. The build consistency of higher level tools such as Maven or the various setups for all the scripting languages (Ruby Gems comes to mind) is very valuable and if its attainable for us (really, I don't have a clue) then that is quite valuable. LSD
Re: Code contribution to harmony
Hello, First of all, good job with this class libraries contribution! Sorry for being late, but I have one question related to build. I noticed that make is used to build native sources. Did you try using ant cpptask? If yes, what kind of issues did you face that influenced the choice in favor of make? Andrey Chernyshev Intel Managed Runtime Division On Nov 8, 2005, at 5:49 AM, Tim Ellison wrote: I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. The code comprises a concrete implementation of the interface between virtual machine and class library that we have been discussing recently, together with a set of core Java classes. The aim is to ground the discussion in reality and provide an opportunity for people to collaborate on enhancements and improvements to actual code. The Java classes are a subset of Java SE 1.4.2 APIs sufficient to run Ant and the Eclipse Java compiler, to provide a basic self-hosting environment. Some of the types are simply stubs to enable full recompilation of the Java code. The ZIP also includes HTML documentation for the VM interface. I've uploaded the contribution here: http://issues.apache.org/jira/browse/HARMONY-14 The expected MD5 sums are: 73ade240df20dec481806130fc8b4875 *Harmony-contribution_Part-1-of-2.zip bc9117d9b4af113eaf5250883d1ce669 *Harmony-contribution_Part-2-of-2.zip A number of people were involved with getting the code ready for contribution (too many to name individually!), and they have done a fine job. There is still plently of work to do; for example, we renamed some code to Hy, but some still has a com.ibm prefix. The code needs bringing up to the project goal of supporting 5.0 APIs. It is targeted at Windows and Linux on Intel 32-bit machines. Now it is everyone's code, join in! In the meantime we are working on making a VM available for download (under a binary evaluation license) from IBM's DeveloperWorks site that implements the class library interface. By getting the VM and unzipping into the same directory you can run the contributed code and try out your changes. I'll post the URL for the VM download (as soon as I know it) as a follow-up to this mail -- it could take a couple of days to organize. Just to avoid confusion, the DeveloperWorks VM not a regular IBM JRE. It is a VM being made available to enable Harmony development and is _not_ a contribution. Regards, Tim - -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Code contribution to harmony
Andrey Chernyshev wrote: Hello, First of all, good job with this class libraries contribution! Thanks Andrey (on behalf of a wide group of people who worked hard to make it happen). Sorry for being late, but I have one question related to build. I noticed that make is used to build native sources. Did you try using ant cpptask? If yes, what kind of issues did you face that influenced the choice in favor of make? Yes, we had a brief encounter with the cpptask and we were using it for a while in our regular builds. The cpptask appears to be very powerful and I probably didn't do it any justice by having a quite large unwieldy script to cover a number of platforms. In the end we decided to go with a 'conventional' native code tool set for the native source, and 'conventional' Java code tools for the Java source. People just felt more comfortable with that. Do you think we are missing out on something ;-) ? Regards, Tim Andrey Chernyshev Intel Managed Runtime Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Code contribution to harmony
Hi Tim, On Wed, 2005-11-09 at 16:56 +, Tim Ellison wrote: Mark Wielaard wrote: Right! I have been thinking on how to move forward with this. And I am excited to see some core class library code since that is where my expertise is. Obviously we should be able to extend this easily with parts of the GNU Classpath library like awt, beans, corba, crypto, swing, sql, most of javax, imageio, naming, etc and the 1.5 additions we have plus the generic classes from the classpath-generics branch. Great. That will be a good opportunity to work together on a class library componentization story too! I am glad you see opportunities here. Note that there have been people doing such a combination of the old OTI libraries with GNU Classpath already inside IBM. They even wrote a nice paper about it that might be worth a read: http://www.research.ibm.com/journal/sj/442/alpern.pdf I agree that getting a resolution to the community/licensing differences would be fantastic. I don't see that happening quickly, and I don't want to see the success or failure of a development project gated upon it. IMHO resolving license issues is a board-level objective, not a J2SE-project objective. We can hack code and live in hope :-) I believe people are really reluctant to hack on the code while there is a legal limbo whether it can be included into the other code bases out there and whether it is meant as a project to enhance all the existing projects or just another project on the side. So I see resolving this issues as a high priority. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: Code contribution to harmony
Hi Geir, On Wed, 2005-11-09 at 11:27 -0500, Geir Magnusson Jr. wrote: On Nov 9, 2005, at 10:37 AM, Geir Magnusson Jr. wrote: On Nov 9, 2005, at 6:17 AM, Mark Wielaard wrote: Would IBM be willing to assign this code to the FSF for inclusion in GNU Classpath or contribute it under a GPL-compatible license like MIT/X, W3C, etc. so that it can be mixed and merged with the GNU Classpath core library and used in larger GPL-compatible works like gcj, kaffe, etc? Mark, speaking with my IBM hat on, I will say that as I promised yesterday to you, I'll certainly get a discussion started inside IBM, but can't answer this now. Also, please understand that sometimes things can move very slowly. I'd like to re-clarify my statement as I don't wish to create any false expectations or misinterpretations. What I was trying to say : I'm simply going to communicate this question inside IBM, and can promise no answer - we will go forward with what we have now under the terms we have now IBM's contribution was made only under the Apache License, and there are no plans for doing anything else with respect to a change or addition in licensing. OK, I can wait for a resolution. We have been going over this for the last 7 months, so I don't expect an immediate change. But it would be nice to finally move forward on this. I assume you did discuss this internally already since this has often been suggested on the list and you have said yourself that you encourage people to make their contributions (also) available under GPL-compatible terms. We should make it much more clear that this is an important project goal to make cooperation between all the different projects go smoother. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: Code contribution to harmony
George Harley1 wrote: Hi Jean-Frederic, It sounds like you do not have a compatible VM to run with (i.e. a VM that implements the proposed interface to the class libraries). As mentioned by Tim the other day you can obtain one from the IBM developerWorks site at http://www.ibm.com/developerworks/java/jdk/harmony If you unzip the archive from the above link into the same directory that you unzipped the code contribution to then the current problem should be sorted. Note that the VM is not part of the code contribution and is only available in binary form under an evaluation license. Hope this helps, Yep, that helps, but I still have to upgrade my installation: +++ [EMAIL PROTECTED]:~/harmony/Harmony ./deploy/jre/bin/java -help Failed to open JVM DLL: /home/jfclere/harmony/Harmony/deploy/jre/bin/default/clearvm (/lib/libpthread.so.0: version `GLIBC_2.3.2' not found (required by /home/jfclere/harmony/Harmony/deploy/jre/bin/default/libj9thr23.so)) +++ George Jean-frederic Clere [EMAIL PROTECTED] 09/11/2005 22:56 Please respond to harmony-dev@incubator.apache.org To harmony-dev@incubator.apache.org cc Subject Re: Code contribution to harmony Tim Ellison wrote: Jean-frederic Clere wrote: Note when doing ant I get the following: +++ cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -DHYPORT_LIBRARY_DEFINE -I../include -c -o hyvmem.o hyvmem.c hyvmem.c: In function `hyvmem_reserve_memory': hyvmem.c:311: `SHM_HUGETLB' undeclared (first use in this function) hyvmem.c:311: (Each undeclared identifier is reported only once hyvmem.c:311: for each function it appears in.) make[1]: Leaving directory `/home/jfclere/harmony/Harmony/native-src/linux.IA32/port' make[1]: *** [hyvmem.o] Error 1 make: *** [_port] Error 2 +++ So the requirements on Linux are a 2.6.x kernel, aren't they? No, should work ok on 2.4 (e.g. RHEL3) What are you compiling on? Suse 8.1: +++ [EMAIL PROTECTED]:~/harmony/Harmony more /etc/SuSE-release SuSE Linux 8.1 (i386) VERSION = 8.1 +++ I have added: #define SHM_HUGETLB 04000 /* segment will use huge TLB pages */ in native-src/linux.IA32/port/hyvmem.c to work-round the problem. The next problem is: +++ [EMAIL PROTECTED]:~/harmony/Harmony ./deploy/jre/bin/java --help Failed to open JVM DLL: /home/jfclere/harmony/Harmony/deploy/jre/bin/default/clearvm (/home/jfclere/harmony/Harmony/deploy/jre/bin/default/libclearvm.so: cannot open shared object file: No such file or directory) +++ The platforms we are using include: - Red Hat EL3 Update 5 - Red Hat EL4 Update 1 - SLES 9 SP1 (on Pentium III, Pentium 4, and Pentium Xeon processors). Regards, Tim Cheers Jean-Frederic
Re: Code contribution to harmony
George Harley1 wrote: Hi Jean-Frederic, My understanding is that while huge TLB pages support was new in the 2.6 kernel it was made available as a backport in the RHEL3 2.4 kernel. Not sure if this also made it into the 2.4 kernel for SuSE 8.1. Might be worthwhile checking the documentation for your distribution. for info: huge TLB pages support has not (yet) been backported to the 2.4 kernels of www.kernel.org. Best regards, George George Harley1/UK/[EMAIL PROTECTED] 09/11/2005 23:54 Please respond to harmony-dev@incubator.apache.org To harmony-dev@incubator.apache.org cc Subject Re: Code contribution to harmony Hi Jean-Frederic, It sounds like you do not have a compatible VM to run with (i.e. a VM that implements the proposed interface to the class libraries). As mentioned by Tim the other day you can obtain one from the IBM developerWorks site at http://www.ibm.com/developerworks/java/jdk/harmony If you unzip the archive from the above link into the same directory that you unzipped the code contribution to then the current problem should be sorted. Note that the VM is not part of the code contribution and is only available in binary form under an evaluation license. Hope this helps, George Jean-frederic Clere [EMAIL PROTECTED] 09/11/2005 22:56 Please respond to harmony-dev@incubator.apache.org To harmony-dev@incubator.apache.org cc Subject Re: Code contribution to harmony Tim Ellison wrote: Jean-frederic Clere wrote: Note when doing ant I get the following: +++ cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -DHYPORT_LIBRARY_DEFINE -I../include -c -o hyvmem.o hyvmem.c hyvmem.c: In function `hyvmem_reserve_memory': hyvmem.c:311: `SHM_HUGETLB' undeclared (first use in this function) hyvmem.c:311: (Each undeclared identifier is reported only once hyvmem.c:311: for each function it appears in.) make[1]: Leaving directory `/home/jfclere/harmony/Harmony/native-src/linux.IA32/port' make[1]: *** [hyvmem.o] Error 1 make: *** [_port] Error 2 +++ So the requirements on Linux are a 2.6.x kernel, aren't they? No, should work ok on 2.4 (e.g. RHEL3) What are you compiling on? Suse 8.1: +++ [EMAIL PROTECTED]:~/harmony/Harmony more /etc/SuSE-release SuSE Linux 8.1 (i386) VERSION = 8.1 +++ I have added: #define SHM_HUGETLB 04000 /* segment will use huge TLB pages */ in native-src/linux.IA32/port/hyvmem.c to work-round the problem. The next problem is: +++ [EMAIL PROTECTED]:~/harmony/Harmony ./deploy/jre/bin/java --help Failed to open JVM DLL: /home/jfclere/harmony/Harmony/deploy/jre/bin/default/clearvm (/home/jfclere/harmony/Harmony/deploy/jre/bin/default/libclearvm.so: cannot open shared object file: No such file or directory) +++ The platforms we are using include: - Red Hat EL3 Update 5 - Red Hat EL4 Update 1 - SLES 9 SP1 (on Pentium III, Pentium 4, and Pentium Xeon processors). Regards, Tim Cheers Jean-Frederic
Re: Code contribution to harmony
Hi, On Tue, 2005-11-08 at 16:13 +, Stefano Mazzocchi wrote: Tim Ellison wrote: I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. Let's the harmonization process begin :-) Right! I have been thinking on how to move forward with this. And I am excited to see some core class library code since that is where my expertise is. Obviously we should be able to extend this easily with parts of the GNU Classpath library like awt, beans, corba, crypto, swing, sql, most of javax, imageio, naming, etc and the 1.5 additions we have plus the generic classes from the classpath-generics branch. At the same time we can merge the kernel classes to get the best of both implementations. But it seems we still have the original roadblock to harmony cooperation, the incompatible licenses. Since this contribution is marked as ASLv2 which is incompatible with GPLv2 so we won't be able to share this easily. So lets try to get that away now. Would IBM be willing to assign this code to the FSF for inclusion in GNU Classpath or contribute it under a GPL-compatible license like MIT/X, W3C, etc. so that it can be mixed and merged with the GNU Classpath core library and used in larger GPL-compatible works like gcj, kaffe, etc? That would be really fun. I remember when I joined the GNU Classpath group and we merged the libgcj and classpath code bases. That was really a good way to lift up both projects since you can compare ideas and code to create something that is bigger then the original things. And you will always learn things from trying to merge two similar but slightly different code bases. I am looking forward to going through each of the core packages to see which implementation is best if we can get the this license issue out of the way. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: Code contribution to harmony
On Nov 9, 2005, at 6:17 AM, Mark Wielaard wrote: Hi, On Tue, 2005-11-08 at 16:13 +, Stefano Mazzocchi wrote: Tim Ellison wrote: I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. Let's the harmonization process begin :-) Right! I have been thinking on how to move forward with this. And I am excited to see some core class library code since that is where my expertise is. Obviously we should be able to extend this easily with parts of the GNU Classpath library like awt, beans, corba, crypto, swing, sql, most of javax, imageio, naming, etc and the 1.5 additions we have plus the generic classes from the classpath-generics branch. At the same time we can merge the kernel classes to get the best of both implementations. But it seems we still have the original roadblock to harmony cooperation, the incompatible licenses. Since this contribution is marked as ASLv2 which is incompatible with GPLv2 so we won't be able to share this easily. So lets try to get that away now. Would IBM be willing to assign this code to the FSF for inclusion in GNU Classpath or contribute it under a GPL-compatible license like MIT/X, W3C, etc. so that it can be mixed and merged with the GNU Classpath core library and used in larger GPL-compatible works like gcj, kaffe, etc? Mark, speaking with my IBM hat on, I will say that as I promised yesterday to you, I'll certainly get a discussion started inside IBM, but can't answer this now. Also, please understand that sometimes things can move very slowly. geir That would be really fun. I remember when I joined the GNU Classpath group and we merged the libgcj and classpath code bases. That was really a good way to lift up both projects since you can compare ideas and code to create something that is bigger then the original things. And you will always learn things from trying to merge two similar but slightly different code bases. I am looking forward to going through each of the core packages to see which implementation is best if we can get the this license issue out of the way. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Code contribution to harmony
On Nov 9, 2005, at 10:37 AM, Geir Magnusson Jr. wrote: On Nov 9, 2005, at 6:17 AM, Mark Wielaard wrote: Hi, On Tue, 2005-11-08 at 16:13 +, Stefano Mazzocchi wrote: Tim Ellison wrote: I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. Let's the harmonization process begin :-) Right! I have been thinking on how to move forward with this. And I am excited to see some core class library code since that is where my expertise is. Obviously we should be able to extend this easily with parts of the GNU Classpath library like awt, beans, corba, crypto, swing, sql, most of javax, imageio, naming, etc and the 1.5 additions we have plus the generic classes from the classpath-generics branch. At the same time we can merge the kernel classes to get the best of both implementations. But it seems we still have the original roadblock to harmony cooperation, the incompatible licenses. Since this contribution is marked as ASLv2 which is incompatible with GPLv2 so we won't be able to share this easily. So lets try to get that away now. Would IBM be willing to assign this code to the FSF for inclusion in GNU Classpath or contribute it under a GPL-compatible license like MIT/X, W3C, etc. so that it can be mixed and merged with the GNU Classpath core library and used in larger GPL-compatible works like gcj, kaffe, etc? Mark, speaking with my IBM hat on, I will say that as I promised yesterday to you, I'll certainly get a discussion started inside IBM, but can't answer this now. Also, please understand that sometimes things can move very slowly. And to really put a fine point on this, I work for IBM, work in things like this for IBM, represent our community interests inside IBM and IBMs interests here (to some degree), but I don't speak for or represent IBM in general, or on this matter specifically. geir geir That would be really fun. I remember when I joined the GNU Classpath group and we merged the libgcj and classpath code bases. That was really a good way to lift up both projects since you can compare ideas and code to create something that is bigger then the original things. And you will always learn things from trying to merge two similar but slightly different code bases. I am looking forward to going through each of the core packages to see which implementation is best if we can get the this license issue out of the way. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Code contribution to harmony
On Nov 9, 2005, at 10:37 AM, Geir Magnusson Jr. wrote: On Nov 9, 2005, at 6:17 AM, Mark Wielaard wrote: Would IBM be willing to assign this code to the FSF for inclusion in GNU Classpath or contribute it under a GPL-compatible license like MIT/X, W3C, etc. so that it can be mixed and merged with the GNU Classpath core library and used in larger GPL-compatible works like gcj, kaffe, etc? Mark, speaking with my IBM hat on, I will say that as I promised yesterday to you, I'll certainly get a discussion started inside IBM, but can't answer this now. Also, please understand that sometimes things can move very slowly. I'd like to re-clarify my statement as I don't wish to create any false expectations or misinterpretations. What I was trying to say : I'm simply going to communicate this question inside IBM, and can promise no answer - we will go forward with what we have now under the terms we have now IBM's contribution was made only under the Apache License, and there are no plans for doing anything else with respect to a change or addition in licensing. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Code contribution to harmony
Mark Wielaard wrote: Hi, On Tue, 2005-11-08 at 16:13 +, Stefano Mazzocchi wrote: Tim Ellison wrote: I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. Let's the harmonization process begin :-) Right! I have been thinking on how to move forward with this. And I am excited to see some core class library code since that is where my expertise is. Obviously we should be able to extend this easily with parts of the GNU Classpath library like awt, beans, corba, crypto, swing, sql, most of javax, imageio, naming, etc and the 1.5 additions we have plus the generic classes from the classpath-generics branch. Great. That will be a good opportunity to work together on a class library componentization story too! At the same time we can merge the kernel classes to get the best of both implementations. But it seems we still have the original roadblock to harmony cooperation, the incompatible licenses. Since this contribution is marked as ASLv2 which is incompatible with GPLv2 so we won't be able to share this easily. So lets try to get that away now. Would IBM be willing to assign this code to the FSF for inclusion in GNU Classpath or contribute it under a GPL-compatible license like MIT/X, W3C, etc. so that it can be mixed and merged with the GNU Classpath core library and used in larger GPL-compatible works like gcj, kaffe, etc? I agree that getting a resolution to the community/licensing differences would be fantastic. I don't see that happening quickly, and I don't want to see the success or failure of a development project gated upon it. IMHO resolving license issues is a board-level objective, not a J2SE-project objective. We can hack code and live in hope :-) That would be really fun. I remember when I joined the GNU Classpath group and we merged the libgcj and classpath code bases. That was really a good way to lift up both projects since you can compare ideas and code to create something that is bigger then the original things. And you will always learn things from trying to merge two similar but slightly different code bases. I am looking forward to going through each of the core packages to see which implementation is best if we can get the this license issue out of the way. I think we should actively seek out opportunities for collaboration. There is every reason to ensure that we don't end up with gratuitious architectural differences that prevent users combining code from GNU Classpath and Harmony. If it turns out that interoperability requires releasing some subset of code under a different license then that is a discussion to be had between the projects (independently of which way the code is flowing). I don't think that point has come. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Code contribution to harmony
Tim, Looks like the project team is going to be getting _very_ busy, and soon! Thanks for going the extra mile in putting together this contribution! Dan Lydick -Original Message- From: Tim Ellison [EMAIL PROTECTED] Sent: Nov 8, 2005 4:49 AM To: harmony-dev harmony-dev@incubator.apache.org Subject: Code contribution to harmony -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. The code comprises a concrete implementation of the interface between virtual machine and class library that we have been discussing recently, together with a set of core Java classes. The aim is to ground the discussion in reality and provide an opportunity for people to collaborate on enhancements and improvements to actual code. The Java classes are a subset of Java SE 1.4.2 APIs sufficient to run Ant and the Eclipse Java compiler, to provide a basic self-hosting environment. Some of the types are simply stubs to enable full recompilation of the Java code. The ZIP also includes HTML documentation for the VM interface. I've uploaded the contribution here: http://issues.apache.org/jira/browse/HARMONY-14 The expected MD5 sums are: 73ade240df20dec481806130fc8b4875 *Harmony-contribution_Part-1-of-2.zip bc9117d9b4af113eaf5250883d1ce669 *Harmony-contribution_Part-2-of-2.zip A number of people were involved with getting the code ready for contribution (too many to name individually!), and they have done a fine job. There is still plently of work to do; for example, we renamed some code to Hy, but some still has a com.ibm prefix. The code needs bringing up to the project goal of supporting 5.0 APIs. It is targeted at Windows and Linux on Intel 32-bit machines. Now it is everyone's code, join in! In the meantime we are working on making a VM available for download (under a binary evaluation license) from IBM's DeveloperWorks site that implements the class library interface. By getting the VM and unzipping into the same directory you can run the contributed code and try out your changes. I'll post the URL for the VM download (as soon as I know it) as a follow-up to this mail -- it could take a couple of days to organize. Just to avoid confusion, the DeveloperWorks VM not a regular IBM JRE. It is a VM being made available to enable Harmony development and is _not_ a contribution. Regards, Tim - -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDcILEQeoJoFeTSY8RAosaAJ4wnnCaMDb9faTA52UGfxUGLqEOEgCg4ByR lCoq7wUHcDbd/sJxWBiLs60= =E8W4 -END PGP SIGNATURE-
Re: Code contribution to harmony
Note when doing ant I get the following: +++ cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -DHYPORT_LIBRARY_DEFINE -I../include -c -o hyvmem.o hyvmem.c hyvmem.c: In function `hyvmem_reserve_memory': hyvmem.c:311: `SHM_HUGETLB' undeclared (first use in this function) hyvmem.c:311: (Each undeclared identifier is reported only once hyvmem.c:311: for each function it appears in.) make[1]: Leaving directory `/home/jfclere/harmony/Harmony/native-src/linux.IA32/port' make[1]: *** [hyvmem.o] Error 1 make: *** [_port] Error 2 +++ So the requirements on Linux are a 2.6.x kernel, aren't they? Cheers Jean-Frederic
Re: Code contribution to harmony
Jean-frederic Clere wrote: Note when doing ant I get the following: +++ cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -DHYPORT_LIBRARY_DEFINE -I../include -c -o hyvmem.o hyvmem.c hyvmem.c: In function `hyvmem_reserve_memory': hyvmem.c:311: `SHM_HUGETLB' undeclared (first use in this function) hyvmem.c:311: (Each undeclared identifier is reported only once hyvmem.c:311: for each function it appears in.) make[1]: Leaving directory `/home/jfclere/harmony/Harmony/native-src/linux.IA32/port' make[1]: *** [hyvmem.o] Error 1 make: *** [_port] Error 2 +++ So the requirements on Linux are a 2.6.x kernel, aren't they? No, should work ok on 2.4 (e.g. RHEL3) What are you compiling on? The platforms we are using include: - Red Hat EL3 Update 5 - Red Hat EL4 Update 1 - SLES 9 SP1 (on Pentium III, Pentium 4, and Pentium Xeon processors). Regards, Tim Cheers Jean-Frederic -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Code contribution to harmony
Tim Ellison wrote: Jean-frederic Clere wrote: Note when doing ant I get the following: +++ cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -DHYPORT_LIBRARY_DEFINE -I../include -c -o hyvmem.o hyvmem.c hyvmem.c: In function `hyvmem_reserve_memory': hyvmem.c:311: `SHM_HUGETLB' undeclared (first use in this function) hyvmem.c:311: (Each undeclared identifier is reported only once hyvmem.c:311: for each function it appears in.) make[1]: Leaving directory `/home/jfclere/harmony/Harmony/native-src/linux.IA32/port' make[1]: *** [hyvmem.o] Error 1 make: *** [_port] Error 2 +++ So the requirements on Linux are a 2.6.x kernel, aren't they? No, should work ok on 2.4 (e.g. RHEL3) What are you compiling on? Suse 8.1: +++ [EMAIL PROTECTED]:~/harmony/Harmony more /etc/SuSE-release SuSE Linux 8.1 (i386) VERSION = 8.1 +++ I have added: #define SHM_HUGETLB 04000 /* segment will use huge TLB pages */ in native-src/linux.IA32/port/hyvmem.c to work-round the problem. The next problem is: +++ [EMAIL PROTECTED]:~/harmony/Harmony ./deploy/jre/bin/java --help Failed to open JVM DLL: /home/jfclere/harmony/Harmony/deploy/jre/bin/default/clearvm (/home/jfclere/harmony/Harmony/deploy/jre/bin/default/libclearvm.so: cannot open shared object file: No such file or directory) +++ The platforms we are using include: - Red Hat EL3 Update 5 - Red Hat EL4 Update 1 - SLES 9 SP1 (on Pentium III, Pentium 4, and Pentium Xeon processors). Regards, Tim Cheers Jean-Frederic
Re: Code contribution to harmony
Hi Jean-Frederic, It sounds like you do not have a compatible VM to run with (i.e. a VM that implements the proposed interface to the class libraries). As mentioned by Tim the other day you can obtain one from the IBM developerWorks site at http://www.ibm.com/developerworks/java/jdk/harmony If you unzip the archive from the above link into the same directory that you unzipped the code contribution to then the current problem should be sorted. Note that the VM is not part of the code contribution and is only available in binary form under an evaluation license. Hope this helps, George Jean-frederic Clere [EMAIL PROTECTED] 09/11/2005 22:56 Please respond to harmony-dev@incubator.apache.org To harmony-dev@incubator.apache.org cc Subject Re: Code contribution to harmony Tim Ellison wrote: Jean-frederic Clere wrote: Note when doing ant I get the following: +++ cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -DHYPORT_LIBRARY_DEFINE -I../include -c -o hyvmem.o hyvmem.c hyvmem.c: In function `hyvmem_reserve_memory': hyvmem.c:311: `SHM_HUGETLB' undeclared (first use in this function) hyvmem.c:311: (Each undeclared identifier is reported only once hyvmem.c:311: for each function it appears in.) make[1]: Leaving directory `/home/jfclere/harmony/Harmony/native-src/linux.IA32/port' make[1]: *** [hyvmem.o] Error 1 make: *** [_port] Error 2 +++ So the requirements on Linux are a 2.6.x kernel, aren't they? No, should work ok on 2.4 (e.g. RHEL3) What are you compiling on? Suse 8.1: +++ [EMAIL PROTECTED]:~/harmony/Harmony more /etc/SuSE-release SuSE Linux 8.1 (i386) VERSION = 8.1 +++ I have added: #define SHM_HUGETLB 04000 /* segment will use huge TLB pages */ in native-src/linux.IA32/port/hyvmem.c to work-round the problem. The next problem is: +++ [EMAIL PROTECTED]:~/harmony/Harmony ./deploy/jre/bin/java --help Failed to open JVM DLL: /home/jfclere/harmony/Harmony/deploy/jre/bin/default/clearvm (/home/jfclere/harmony/Harmony/deploy/jre/bin/default/libclearvm.so: cannot open shared object file: No such file or directory) +++ The platforms we are using include: - Red Hat EL3 Update 5 - Red Hat EL4 Update 1 - SLES 9 SP1 (on Pentium III, Pentium 4, and Pentium Xeon processors). Regards, Tim Cheers Jean-Frederic
Re: Code contribution to harmony
Hi Jean-Frederic, My understanding is that while huge TLB pages support was new in the 2.6 kernel it was made available as a backport in the RHEL3 2.4 kernel. Not sure if this also made it into the 2.4 kernel for SuSE 8.1. Might be worthwhile checking the documentation for your distribution. Best regards, George George Harley1/UK/[EMAIL PROTECTED] 09/11/2005 23:54 Please respond to harmony-dev@incubator.apache.org To harmony-dev@incubator.apache.org cc Subject Re: Code contribution to harmony Hi Jean-Frederic, It sounds like you do not have a compatible VM to run with (i.e. a VM that implements the proposed interface to the class libraries). As mentioned by Tim the other day you can obtain one from the IBM developerWorks site at http://www.ibm.com/developerworks/java/jdk/harmony If you unzip the archive from the above link into the same directory that you unzipped the code contribution to then the current problem should be sorted. Note that the VM is not part of the code contribution and is only available in binary form under an evaluation license. Hope this helps, George Jean-frederic Clere [EMAIL PROTECTED] 09/11/2005 22:56 Please respond to harmony-dev@incubator.apache.org To harmony-dev@incubator.apache.org cc Subject Re: Code contribution to harmony Tim Ellison wrote: Jean-frederic Clere wrote: Note when doing ant I get the following: +++ cc -fpic -DLINUX -D_REENTRANT -O1 -march=pentium3 -DIPv6_FUNCTION_SUPPORT -DHYX86 -DHYPORT_LIBRARY_DEFINE -I../include -c -o hyvmem.o hyvmem.c hyvmem.c: In function `hyvmem_reserve_memory': hyvmem.c:311: `SHM_HUGETLB' undeclared (first use in this function) hyvmem.c:311: (Each undeclared identifier is reported only once hyvmem.c:311: for each function it appears in.) make[1]: Leaving directory `/home/jfclere/harmony/Harmony/native-src/linux.IA32/port' make[1]: *** [hyvmem.o] Error 1 make: *** [_port] Error 2 +++ So the requirements on Linux are a 2.6.x kernel, aren't they? No, should work ok on 2.4 (e.g. RHEL3) What are you compiling on? Suse 8.1: +++ [EMAIL PROTECTED]:~/harmony/Harmony more /etc/SuSE-release SuSE Linux 8.1 (i386) VERSION = 8.1 +++ I have added: #define SHM_HUGETLB 04000 /* segment will use huge TLB pages */ in native-src/linux.IA32/port/hyvmem.c to work-round the problem. The next problem is: +++ [EMAIL PROTECTED]:~/harmony/Harmony ./deploy/jre/bin/java --help Failed to open JVM DLL: /home/jfclere/harmony/Harmony/deploy/jre/bin/default/clearvm (/home/jfclere/harmony/Harmony/deploy/jre/bin/default/libclearvm.so: cannot open shared object file: No such file or directory) +++ The platforms we are using include: - Red Hat EL3 Update 5 - Red Hat EL4 Update 1 - SLES 9 SP1 (on Pentium III, Pentium 4, and Pentium Xeon processors). Regards, Tim Cheers Jean-Frederic
Re: Code contribution to harmony
Thanks Tim! A few comments, wearing my Apache hat of course (n.b I am an IBM employee as well). 0) We need to go through the bulk contribution process for this donation (of course). I have an outstanding to-do on that, which is to wrap up the bulk contrib rules. I have a proposal that I'll bring to the dev list later today. Many of the following statements are made with the assumption that we will work through this process successfully, and the project will vote to accept this contribution. 1) This is our most significant donation we have received to date (in terms of maturity and size, I think) and I encourage everyone to start to play with it. I think of Harmony as a big freight train and with this contribution builds on the contributions of Dan, Archie, David, and all the others and the train is starting to move. The nice thing about a lot of mass is that even small velocities result in very large momentum :) 2) Combined with the VM that IBM is making available _for evaluation_, there is a very low barrier to entry to get people up and working with this. Tim and his team have gone to great pains to make this easy to evaluate and use (only to be foiled at the end by our 10MB upload limit on JIRA, hence the two zip files...) so I encourage everyone to take some time to play, inspect and of course, ask questions. 3) I want to emphasize that IBM is making their VM available to help us evaluate and develop this further until we get our own open source VM underneath it. The VM (for which a link will be posted later) is not being contributed to the project, or licensed for any other use. It is proprietary software under a proprietary license. It is useful to us because it supports the VM/classlibrary interface that the IBM donation implements, so we can start evaluation and testing immediately. 4) To that end, I can think of a few things we can do to get started : a) Get our own current crop of VMs working with it - bootVM and jcheVM. b) Help to get Kaffe working with the library interface - see what it takes to get Kaffe to support this interface as well (if they want), so we have a more mature free VM that supports the interface. c) Help to get GNU Classpath supporting the interface (if they want) so that GNU Classpath can run on the evaluation VM. The point here is to continue to focus on our cross-project interoperability and modularity interests, with this important interface as a starting point. The other benefit of this is that we can start gump-ing this stuff ASAP :) I'm sure I'll have things I want to add once I hit send... Yay! geir On Nov 8, 2005, at 5:49 AM, Tim Ellison wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. The code comprises a concrete implementation of the interface between virtual machine and class library that we have been discussing recently, together with a set of core Java classes. The aim is to ground the discussion in reality and provide an opportunity for people to collaborate on enhancements and improvements to actual code. The Java classes are a subset of Java SE 1.4.2 APIs sufficient to run Ant and the Eclipse Java compiler, to provide a basic self-hosting environment. Some of the types are simply stubs to enable full recompilation of the Java code. The ZIP also includes HTML documentation for the VM interface. I've uploaded the contribution here: http://issues.apache.org/jira/browse/HARMONY-14 The expected MD5 sums are: 73ade240df20dec481806130fc8b4875 *Harmony-contribution_Part-1-of-2.zip bc9117d9b4af113eaf5250883d1ce669 *Harmony-contribution_Part-2-of-2.zip A number of people were involved with getting the code ready for contribution (too many to name individually!), and they have done a fine job. There is still plently of work to do; for example, we renamed some code to Hy, but some still has a com.ibm prefix. The code needs bringing up to the project goal of supporting 5.0 APIs. It is targeted at Windows and Linux on Intel 32-bit machines. Now it is everyone's code, join in! In the meantime we are working on making a VM available for download (under a binary evaluation license) from IBM's DeveloperWorks site that implements the class library interface. By getting the VM and unzipping into the same directory you can run the contributed code and try out your changes. I'll post the URL for the VM download (as soon as I know it) as a follow-up to this mail -- it could take a couple of days to organize. Just to avoid confusion, the DeveloperWorks VM not a regular IBM JRE. It is a VM being made available to enable Harmony development and is _not_ a contribution. Regards, Tim - -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG
Re: Code contribution to harmony
Tim Ellison wrote: I'll post the URL for the VM download (as soon as I know it) as a follow-up to this mail -- it could take a couple of days to organize. Hey, the DeveloperWorks download is available now: http://www.ibm.com/developerworks/java/jdk/harmony Any questions just shout. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Code contribution to harmony
AWESOME!! thanks guys. -- dims On 11/8/05, Tim Ellison [EMAIL PROTECTED] wrote: Tim Ellison wrote: I'll post the URL for the VM download (as soon as I know it) as a follow-up to this mail -- it could take a couple of days to organize. Hey, the DeveloperWorks download is available now: http://www.ibm.com/developerworks/java/jdk/harmony Any questions just shout. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Davanum Srinivas : http://wso2.com/blogs/
