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
Keeping Social Dynamics in Mind [was Re: Building choices]
Tim Ellison wrote: [snip discussion on make vs ant] 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. Before this turns into a coloring my bikeshed argument, let me point out one thing: how the choice of tools impacts community dynamics. One of the goals of any project that wants to be successful is to attract diversity in the community interested in it. for diversity in apache we mean from different affiliations, walks of life, technical backgrounds, interests, needs, etc... We believe diversity in the social ecosystem plays a key role in both stability and adaptation of the software to environmental needs. This is really the 'secret sauce' of the ASF. At the same time, our experience teaches that there are gaps that people are unlikely to bridge, unless helped. In short, sometimes those who are promoting diversity and are in need for help and for sharing development costs, have to wash the dishes first. One argument that comes to mind to attract people is simplicity: of use, of installation, of configuration, of understanding, of modularization, of adapting it to ones needs, etc.. That is *not* the right way to spin it, because it wouldn't explain how stuff like the linux kernel can manage to attract so many people to work on it. It's not the investment that needs to be reduced, but it's the return on that investment that needs to be increased. Really, how much the investment is practically meaningless: there *is* somebody out there willing to do pretty much anything (in terms of energy/time/programming) if he can do what he wants. Now, for harmony what he wants is *crystal clear*: run java in a way that is not possible before. Faster on a Mac, shipped with Debian, workign on FreeBSD, working on their embedded device, avoid the OMG, microsoft bought sun and killed java syndrome, you name it. Do you *seriously* think that such a person would be stopped by having to use make and ant? In short, ask yourself: how likely is it to be able to attract the kind of people that could be interested in Harmony if I make this choice? ant vs. make, which one would be more palatable, attractive, maximize their ROI? And then, yes, you have to wash the dishes for a while and drag somebody's feets because somebody in your team is unhappy about the choice. Such is life: the day the unhappy guy in the team sees a patch coming out of nowhere for a problem he was not able to identify, he'll understand why he had to wash dishes for a while. ;-) -- Stefano.
Re: compiling JCHEVM with MSVC
Enrico Migliore wrote: I'm trying to figure out how far is your code from a successful build with MSVC on Win2000. That is, at the end of this work, I want to have a clear picture of which source files are 100% OS/architecture independent and which are OS/architecture dependent. One of the problem I'm facing right now, are the memory management functions you call. for example, Windows doesn't have the mmap() function, therefore, at the moment, I must supply a dummy mmap() implementation, in order to proceed. The other problem I got is that I don't have the files and the macros, generated by the automake and autoconf tools, and I need them as a reference. In order to for me to proceed I need to take a look at the source tree generated by automake and autoconf. Could anybody send me the tree built for Linux? Try this... I built a distribution tarball from the current SVN sources: http://people.freebsd.org/~archie/jchevm-1.0.tar.gz -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Keeping Social Dynamics in Mind [was Re: Building choices]
No disrespect stefano, but I have a much dumber way to frame this: automake is just easer for C/C++ code than Ant make is just faster for C/C++ code than Ant (not by much granted) ant is just easier/faster/better for Java code than make/automake Thus I propose the third way: 1. Master ant build which kicks off Automake/make for C/C++ parts (optional to use of course) 2. Automake/make for C/C++ 3. Ant stuff for Java stuff. Of course, I have a do-ocratic bias for this. Let those who are writing it do what makes sense and if it is a pain to build, then something is wrongbut thats my bias. -andy Stefano Mazzocchi wrote: Tim Ellison wrote: [snip discussion on make vs ant] 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. Before this turns into a coloring my bikeshed argument, let me point out one thing: how the choice of tools impacts community dynamics. One of the goals of any project that wants to be successful is to attract diversity in the community interested in it. for diversity in apache we mean from different affiliations, walks of life, technical backgrounds, interests, needs, etc... We believe diversity in the social ecosystem plays a key role in both stability and adaptation of the software to environmental needs. This is really the 'secret sauce' of the ASF. At the same time, our experience teaches that there are gaps that people are unlikely to bridge, unless helped. In short, sometimes those who are promoting diversity and are in need for help and for sharing development costs, have to wash the dishes first. One argument that comes to mind to attract people is simplicity: of use, of installation, of configuration, of understanding, of modularization, of adapting it to ones needs, etc.. That is *not* the right way to spin it, because it wouldn't explain how stuff like the linux kernel can manage to attract so many people to work on it. It's not the investment that needs to be reduced, but it's the return on that investment that needs to be increased. Really, how much the investment is practically meaningless: there *is* somebody out there willing to do pretty much anything (in terms of energy/time/programming) if he can do what he wants. Now, for harmony what he wants is *crystal clear*: run java in a way that is not possible before. Faster on a Mac, shipped with Debian, workign on FreeBSD, working on their embedded device, avoid the OMG, microsoft bought sun and killed java syndrome, you name it. Do you *seriously* think that such a person would be stopped by having to use make and ant? In short, ask yourself: how likely is it to be able to attract the kind of people that could be interested in Harmony if I make this choice? ant vs. make, which one would be more palatable, attractive, maximize their ROI? And then, yes, you have to wash the dishes for a while and drag somebody's feets because somebody in your team is unhappy about the choice. Such is life: the day the unhappy guy in the team sees a patch coming out of nowhere for a problem he was not able to identify, he'll understand why he had to wash dishes for a while. ;-)
RE: Contribution of security, crypto, and x-net libraries
Some folks at Intel spent some time over the last week trying to figure out whether or not it is going to work with the recent contribution of lang/util/io/net/nio packages by IBM, and the general consensus is that they, mostly, should be compatible. We have verified that it is already possible to run ant and the Eclipse compiler with this combination and we are committed to work with the community to get more complex workloads to work under Harmony. We will work closely with you to resolve any issues you have to ensure the two contributions work well together. Right now, we are sorting out the integration issues. We hope to summarize the problems shortly and mail them to harmony-dev list Thanks, Mikhail Loenko Intel Managed Runtime Division -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Saturday, November 19, 2005 2:35 AM To: harmony-dev@incubator.apache.org Subject: Re: Contribution of security, crypto, and x-net libraries This is very cool -- well done Mikhail and everyone at Intel involved in producing this contribution. The Harmony train(*) is leaving the station :-) (*) Ref: Geir's note to the list on Nov 8: I think of Harmony as a big freight train and [an earlier] 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. Loenko, Mikhail Y wrote: With pleasure I announce the first contribution to Harmony on behalf of Intel. The archive with the contribution is uploaded to the following location: http://issues.apache.org/jira/browse/HARMONY-16 The contribution includes the following things related to Java security: 1) Java Security Architecture (public API) 2) Java Cryptography Architecture (JCA) and Java Cryptography Extension (JCE) 3) Java Secure Socket Extension (JSSE) 4) Simple Authentication and Security Layer (SASL) 5) Java Authentication and Authorization Service (JAAS) 6) GSS-API (JGSS) 7) ASN.1 support framework and documentation for it. The contribution does not include security providers and login modules except for NT and UNIX login modules, provided as an example, and a Certificate Factory provider. We have tested this code with BouncyCastle, GNU-crypto, and JESSIE third-party security providers. The code is a result of efforts of Intel Managed Runtime Division team. One should be able to run this code with a 1.4+ compatible JRE/VM (we tested it with commercial JVMs). Classes that require special support from the VM are not included into the contribution. This is, for example, the reason why there isn't java.security.AccessController class. The implementation is done according to Java 5 specification, with the exception of where Java 5 specific language features, such as generics, are required. There are some package names starting with com.openintel.*, but, should the contribution be accepted, these are easy to rename. Most of the code is pure Java, but where the native parts are required, they are provided for Linux and Windows on IA-32 architecture. Some folks at Intel spent some time over the last week trying to figure out whether or not it is going to work with the recent contribution of lang/util/io/net/nio packages by IBM, and the general consensus is that they, mostly, should be compatible. We have verified that it is already possible to run ant and the Eclipse compiler with this combination and we are committed to work with the community to get more complex workloads to work under Harmony. We will work closely with you to resolve any issues you have to ensure the two contributions work well together. Regards, Tim The archive contains the README file that explains the things doable with this code, but should any additional clarification be required, I am ready to answer any questions. Please try this code out! Mikhail Loenko, Intel Managed Runtime Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Contribution of security, crypto, and x-net libraries
On Mon, Nov 21, 2005 at 09:08:28PM +0300, Loenko, Mikhail Y wrote: Some folks at Intel spent some time over the last week trying to figure out whether or not it is going to work with the recent contribution of lang/util/io/net/nio packages by IBM, and the general consensus is that they, mostly, should be compatible. We have verified that it is already possible to run ant and the Eclipse compiler with this combination and we are committed to work with the community to get more complex workloads to work under Harmony. We will work closely with you to resolve any issues you have to ensure the two contributions work well together. Right now, we are sorting out the integration issues. We hope to summarize the problems shortly and mail them to harmony-dev list This may be obvious, but you are more than welcome to do such sorting out on this mailing list rather than just send out summaries when its done. The sooner we get all of the we in that sentence above actively involved around here, the better! cheers! Leo
