Re: The Classpath VM interface. (Please read)
Sven de Marothy wrote: If you have downloaded Harmony, which intends to be a full JDK including a VM and class library, why would you want to be able to use that with the class library from a different JDK? In [arch] VM Interface on 6/06/2005 10:32 AM I wrote I assume that if the Harmony JVM gets half as good as is hoped there will be companys who want to adopt the JVM but continue to use Suns class library so that differences in libraries don't hurt their customers. Disregarding the illegality of distributing such a combo, I am not sure why it would be illegal if someone like IBM were to use the Harmony JVM but use Suns class library. Actually I think that this use case is one of the aims of the project. there is no good practical reason for wanting that either. I think we will have to agree to disagree about that point. -- Cheers, Peter Donald The first duty of a revolutionary is to get away with it. - Abbie Hoffman
Re: [arch] VM Interface
On Jun 6, 2005, at 10:03 AM, Ahmed Saad wrote: On 6/6/05, Peter Donald [EMAIL PROTECTED] wrote: The reason being that their customers do not want to be exposed to differences between rt.jar and GNU Classpath. oh well aren't both implemented according to a well-designed exported API. So how there would be differences that would hurt the clients of this API (assuming that the GUN Classpath got completed and they are both might be retrofitted to be easily installed in this modular architecture even if they depend on some native libraries). The differences come from implementation of that API. Conceivably :) there are bugs in implementations of class libraries. (Having one that we all share would be an excellent start to solving that problem.) geir regards, ahmed -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] VM Interface
On Jun 6, 2005, at 9:11 AM, Archie Cobbs wrote: Peter Donald wrote: I assume that if the Harmony JVM gets half as good as is hoped there will be companys who want to adopt the JVM but continue to use Suns class library so that differences in libraries don't hurt their customers. If that is a goal of Harmony then we've just made things a lot harder. First of all, Sun's class library - VM interface is proprietary and unpublished. How would people become experts in it without studying the Sun source code, with all the potential legal problems that entails? Because it's possible that Sun finds this aspect of Harmony valuable overall, and contributes information to help shape this. Secondly, you can no longer use Classpath as is, so Harmony will have to create a new fork of the Classpath code. Lots of work, zero forward progress. No, we won't fork GNU Classpath. I don't understand why you believe we have to do this. Thirdly, what's to stop Sun from changing things around every release? Their API is not standardized in any way. It involves sun.* classes, etc. Nothing. On the other hand, if down the road the various interested parties got together and said, Let's all agree on a common class library/JVM API then certainly Harmony should be involved and supportive. However somehow to me that seems about as likely as Toyota, Ford, and GM all agreeing to standardize the connection between engines and gearboxes. That agreement is one of the things we're trying to do here, remember. I don't know if the analogy is right though (although there is a bit of standardization in the auto industry). Maybe the computer industry would be a better example? :) geir -Archie __ Archie Cobbs *CTO, Awarix* http:// www.awarix.com -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: The Classpath VM interface. (Please read)
On Jun 6, 2005, at 2:29 PM, Sven de Marothy wrote: Hi, Ok, the amount of confusion going on is just amazing. I'll try to recapitulate what the actual situation and actual issues are. It is of course impossible to implement a java class library completely independently of the Virtual Machine. The VM must be able to provide certain basic, core things. Sun has not documented how their VM works with rt.jar. Therefore it is not possible to develop a Sun class library-compatible VM in a clean-room fashion. Not *now*, but Harmony has the potential to be a long-running, far- reaching project, and our interest from the beginning is to have Sun involved. So it's not unthinkable to assume that Sun might be interested in participating at some point in the future. That doesn't mean we'll hold things up waiting, but we also can't assume that they'll never be interested. [SNIP] The only real issues raised so far (that I've seen), are the following: 1) GNU Classpath's VM interface doesn't include things necessary for J2SE 5. (My take on it: There is no VM which needs them yet.) But you absolutely know we will. 2) GNU Classpath's VM interface uses language protection such as package-privacy to hide the VM classes. (My take on it: Why is that a problem?) You are misrepresenting the problem. it's not that it's language protection, but that you extend java.lang namespace and are hoping that you don't get tromped by the spec at some point in the future. (Nor is it clear that it's good citizenship working in that namespace as well...) 3) If Harmony commits itself to using the Classpath VM interface, it won't be able to use other class libraries. (My take on it: The alternative being one with an undocumented proprietary VM interface, and .. well, what else?) We want to be able to choose class library implementations. We want to work with GNU Classpath now, and work out an independent interface that starts w/ GNU CLasspath, is supported [enthusiastically] by GNU Classpath, and one that we can evolve together with GNU Classpath. But just as GNU Classpath thought it wise to keep the door open for multiple VM implementations, we are trying to do the same for mutiple class library implementations. geir /Sven [1] http://www.gnu.org/software/classpath/docs/vmintegration.html [2] http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/vm/ reference/java/ [3] Apparently I was wrong about this previously, David Grove corrected me. JikesRVM does use the Classpath VM interface. -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: The Classpath VM interface. (Please read)
On Tue, 2005-06-07 at 16:45 +1000, Peter Donald wrote: If you have downloaded Harmony, which intends to be a full JDK including a VM and class library, why would you want to be able to use that with the class library from a different JDK? In [arch] VM Interface on 6/06/2005 10:32 AM I wrote I assume that if the Harmony JVM gets half as good as is hoped there will be companys who want to adopt the JVM but continue to use Suns class library so that differences in libraries don't hurt their customers. If the Harmony JVM gets half as good as hoped, it will be fully J2SE 5 compatible. If it passes the TCK, it's compatible. If that still hurts people, then that code is broken. You've got to draw the line somewhere. And there is no reason to believe the VM part of Harmony will have higher quality than the class library. Especially not if the VM is written from scratch. Disregarding the illegality of distributing such a combo, I am not sure why it would be illegal if someone like IBM were to use the Harmony JVM but use Suns class library. Actually I think that this use case is one of the aims of the project. It is in violation of Sun's EULA. /Sven
Re: The Classpath VM interface. (Please read)
On Tue, 2005-06-07 at 08:15 -0400, Geir Magnusson Jr. wrote: On Jun 6, 2005, at 2:29 PM, Sven de Marothy wrote: Sun has not documented how their VM works with rt.jar. Therefore it is not possible to develop a Sun class library-compatible VM in a clean-room fashion. Not *now*, but Harmony has the potential to be a long-running, far- reaching project, and our interest from the beginning is to have Sun involved. So it's not unthinkable to assume that Sun might be interested in participating at some point in the future. I don't quite see what the one has to do with the other here. 1) GNU Classpath's VM interface doesn't include things necessary for J2SE 5. (My take on it: There is no VM which needs them yet.) But you absolutely know we will. Right. But because no VM needs them yet, nobody around (who's made themself known) has worked out *exactly* what demands that puts on the VM interface. And without that detail Harmony can't devise a Java 5 VM interface any more than GNU Classpath can. 2) GNU Classpath's VM interface uses language protection such as package-privacy to hide the VM classes. (My take on it: Why is that a problem?) You are misrepresenting the problem. it's not that it's language protection, but that you extend java.lang namespace and are hoping that you don't get tromped by the spec at some point in the future. (Nor is it clear that it's good citizenship working in that namespace as well...) I still don't see the problem. You may always get tromped by the spec in the future. And as for namespace issues; We're not extending the public namespace. I don't see the issue. And it's not just about the VM interface. In fact, I don't see how its possible to do a good implementation of the class library *at all* without adding package-private methods, or classes. (And while I can't be certain offhand like this, I think there are parts which are simply *impossible* to implement without adding package-private parts.) But just as GNU Classpath thought it wise to keep the door open for multiple VM implementations, we are trying to do the same for mutiple class library implementations. This is a job for the JCP. If you want a standard interface, get the JCP to create a spec for one. But if you develop your own interface and only GNU Classpath uses it, it's not keeping the door open. (And worse, if GNU Classpath doesn't use it, all you've got is yet another inofficial interface. And that'll be even worse for interoperability.) /Sven
Re: The Classpath VM interface. (Please read)
Sven de Marothy wrote: I really don't view it that way. I view it as 'Is it worth spending effort on this?'. I understand where Geir is coming from here: even more important then the implementation, one of Harmony objectives is to involve different groups as well as commercial companies, to define a modular architecture for a J2SE implementation. It could even be that a Harmony VM would be incorporated with Sun's classlibraries to create a product by some comercial vendor that could lawfully do that. In this view, it would be important to have a VM-library interface that could accomplish that. But I mostly agree with Sven: if we're going to support plugging different libraries, we must start from somewere that is available and documented (Classpath has such a beast) and then work with the interested parties to expand that. For us to include the existing (non documented/proprietary) Sun interface it would have to be contributed by Sun into the discussion. This could be a good way of starting to propose a Sun involvement. If this proves a good idea it could even turn into a JCP spec as it was suggested. If Sun is not interested, I don't see any reason to invest effort in doing it, since it will have no pratical value. I think it is more probable that IBM or other Sun licensee that wants to use Sun's class libraries will just do the effort in order for then to use the existing library, and if legally possble, contribute that back. Without Sun's involvement, that's the best we could hope for. And if we want a pluggable infrastructure, we would still be better off starting from Classpath, since it already plugs into many VMs, while Sun's library seams to not have this advantage to start with. Better change one than many :-) Bruno. /Sven -- Bruno. __ Bruno Peres Ferreira de Souza Brazil's JavaMan http://www.javaman.com.br bruno at javaman.com.br if I fail, if I succeed, at least I live as I believe
Re: [arch] VM Interface
On 6/7/05, Archie Cobbs [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: [..] Because it's possible that Sun finds this aspect of Harmony valuable overall, and contributes information to help shape this. I highly doubt that will happen (just my opinion though). Secondly, you can no longer use Classpath as is, so Harmony will have to create a new fork of the Classpath code. Lots of work, zero forward progress. No, we won't fork GNU Classpath. I don't understand why you believe we have to do this. Well, the alternative is to convince the Classpath developers to completely rewrite the existing API to match whatever Sun currently does (which is unknown, and would probably taint them), and also convince all the current VM implementers to change their implementations. As a Classpath developer and VM implementer, I even more highly doubt that. Thirdly, what's to stop Sun from changing things around every release? Their API is not standardized in any way. It involves sun.* classes, etc. Nothing. So you have a moving, undocumented API to support. Sounds fun :-) [..] From what i understood from the GNU Classpath VM Integration Guide, a classlibrary-VM interface is intended to provide implementation for some basic classes that are needed by this particular classlibrary to get the work done, correct me anybody, please? (are there any other requirements for such interface beyond some hooks? (maybe true for Sun rt.jar)) Jikes RVM, Kaffe, SableVM, etc [implement Classpath-required classes] can use Classpath Harmony VM [implement Classpath-required classes] can use Classpath Harmony VM [implement Sun rt.jar-required classes(??)] --- can use Sun rt.jar Harmony VM [implement X-required classes] can use X maybe Harmony would: 1. determine which classes are required by each classlibrary implementation: GNU, Sun (is this legal), are there any others? btw, how will we know about Sun's? is src.zip enough ? (i doubt there are any published docs about this) 2. work out a draft spec about what it takes for a common, well there was only GUN and Sun, classlibrary-VM interface based on what we found in Classpath and rt.jar 2. implement adpaters for Classpath and rt.jar (what i mean is that Harmony spec will introduce a layer to abstract current classlibrary-vm interfaces) Apache can take this spec to the JCP and till it's approved the adapaters will be enough (if sun changed the interface in the next version we would work on a new adapeter. maybe there would be some changes in the spec). i haven't been down to a VM before but can such a thing be achived? -ahmed
Re: [arch] VM Interface
On Jun 7, 2005, at 9:49 AM, Archie Cobbs wrote: Geir Magnusson Jr. wrote: I assume that if the Harmony JVM gets half as good as is hoped there will be companys who want to adopt the JVM but continue to use Suns class library so that differences in libraries don't hurt their customers. If that is a goal of Harmony then we've just made things a lot harder. First of all, Sun's class library - VM interface is proprietary and unpublished. How would people become experts in it without studying the Sun source code, with all the potential legal problems that entails? Because it's possible that Sun finds this aspect of Harmony valuable overall, and contributes information to help shape this. I highly doubt that will happen (just my opinion though). Secondly, you can no longer use Classpath as is, so Harmony will have to create a new fork of the Classpath code. Lots of work, zero forward progress. No, we won't fork GNU Classpath. I don't understand why you believe we have to do this. Well, the alternative is to convince the Classpath developers to completely rewrite the existing API to match whatever Sun currently does (which is unknown, and would probably taint them), and also convince all the current VM implementers to change their implementations. As a Classpath developer and VM implementer, I even more highly doubt that. I don't think anyone suggested that we should match what Sun does. Maybe get some insight into what they needed to do for J2SE 1.5 (since they have done it..), and what they learned building one of the finest VMs out there. But just do what they do? No. Thirdly, what's to stop Sun from changing things around every release? Their API is not standardized in any way. It involves sun.* classes, etc. Nothing. So you have a moving, undocumented API to support. Sounds fun :-) We don't have to support it. The question is what stops Sun? the answer is nothing. But we don't have to support it. On the other hand, if down the road the various interested parties got together and said, Let's all agree on a common class library/ JVM API then certainly Harmony should be involved and supportive. However somehow to me that seems about as likely as Toyota, Ford, and GM all agreeing to standardize the connection between engines and gearboxes. That agreement is one of the things we're trying to do here, remember. I don't know if the analogy is right though (although there is a bit of standardization in the auto industry). Maybe the computer industry would be a better example? :) I think it would be great to get there someday. The thing to do would be to create a JCP project to standardize the Class/VM API. However, the fact that this is a nice idea doesn't seem to have any impact on the current situation for Harmony. Are you saying Harmony should wait for such a JCP to be proposed, accepted, and standardized? That will take years. Come on - I think I [jokingly] suggested we take what *we* develop and bring to the JCP, not wait for it. Are you saying Harmony should adopt Sun's current, undocumented, proprietary, and subject-to-change-at-any-time API? That seems like a really bad idea for a large number of reasons. I'm starting to wonder if you read what I actually wrote. I suggested we try to figure out what Sun did to learn from them. Even the idea that there will be any interest in combining Sun's classes with a Harmony VM is suspect IMHO as well (would that even be legal?). Why not? If I had a license from Sun to do so? So in summary: I just don't get it. I suppose not - I thought the issue is really simple, and I'm sorry it's gotten a bit off track. We started with the idea that in part, we should look at modularization of a VM platform. One of the connection points is the VM-Class library interface, and since we have something to start with - the GNU Classpath interface - I suggested we start there, and see what additional information we can gather from those that have done more advanced and complete implementations (Sun, IBM, BEA, HP, etc) and with those considerations, produce an interface that works for where we are targeting to go. No one is suggesting we standardize on Sun's interface, wait until the JCP does something about this, or bundle our (or anyone else's) stuff w/ Suns libraries. (As for the latter, it would be nice if it was an option for those that choose to go that route... Freedom is good :) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] VM Interface
On Jun 7, 2005, at 4:03 PM, Archie Cobbs wrote: Geir Magnusson Jr. wrote: I assume that if the Harmony JVM gets half as good as is hoped there will be companys who want to adopt the JVM but continue to use Suns class library so that differences in libraries don't hurt their customers. If that is a goal of Harmony then we've just made things a lot harder. So in summary: I just don't get it. I suppose not - I thought the issue is really simple, and I'm sorry it's gotten a bit off track. We started with the idea that in part, we should look at modularization of a VM platform. One of the connection points is the VM-Class library interface, and since we have something to start with - the GNU Classpath interface - I suggested we start there, and see what additional information we can gather from those that have done more advanced and complete implementations (Sun, IBM, BEA, HP, etc) and with those considerations, produce an interface that works for where we are targeting to go. No one is suggesting we standardize on Sun's interface, wait until the JCP does something about this, or bundle our (or anyone else's) stuff w/ Suns libraries. (As for the latter, it would be nice if it was an option for those that choose to go that route... Freedom is good :) Learning from Sun et.al. and taking the best ideas is all good... My reaction was to the notion that a goal of Harmony should be to be API-compatible with Sun. Reading the first blurb quoted above, that seemed to be the suggestion (maybe I misread it). IMHO it's inappropriate to spend any (more) time worrying about API compatibility right now, when the possibility is so far off. Agreed. API compatibility with Sun isn't a goal right now - but having a VM/lib interface rich enough to support the semantics they (and anyone else w/ a modern, complete implementation) need isn't something we should ignore :) On the other hand, anyone who has any bright ideas for how the class/JVM API that Classpath has now might be improved please speak up (preferably on the Classpath mailing list, not this one?) Either one - if here, we can certainly suggest to classpath (and even provide some code... I'm dying to contribute to something under the GPL ;) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] Modules and interfaces (was: How much of java.* ...)
On Tue, 2005-06-07 at 07:35 +1000, Steve Blackburn wrote: It brings to mind some of the portability/modularity issues we've been wrestling with (at great length) with MMTk and the interdependence between the memory manager and the VM. Our solution is not earth shattering, but it evolved out of a very long struggle with issues like the one Geir is alluding to above. I will most probably be told why not very shortly, but is it not possible to use the class loader to solve this problem? My first solution would be too implement VM specific functions in their own library, but using existing the namespaces, not creating new ones. So you have your own java.lang.Thread, for example, that works with your VM. The class loader then uses the VM specific functionality to override the generic functionality. This acts like a mask, hiding functionality that the VM authors decide is specific to the VM, but leaving all the other generic functionality exposed. This has the advantage that it reduces the amount of re-work while allowing enormous flexibility. The only requirement is that the class libraries call the public API instead of internal implementation classes - i.e. make no assumptions about the implementation of any other class (as much as possible, anyway). This also makes it possible to inject, for example, a VM specific String class, or specially tuned Socket classes. But at the same time for other VM's to use the generic String class. The principal can be extended so that application specific classes can override the generic classes. Although this is wrong for so many other reasons. :( From a brief look at the classpath docs, it looks like classpath uses a similar approach - from what I can tell the one I am suggesting is just more generic. Or is the issue deeper than this? - Matthew
Re: [arch] VM Interface
On Jun 7, 2005, at 4:32 PM, Sven de Marothy wrote: On Tue, 2005-06-07 at 16:14 -0400, Geir Magnusson Jr. wrote: Either one - if here, we can certainly suggest to classpath (and even provide some code... I'm dying to contribute to something under the GPL ;) Geir, I know you were joking, but GNU Classpath isn't under the GPL. You know that. But there's been enough misconceptions about this on this list already. Let's not risk adding to them. I meant GPL + Exception. And I wasn't joking. I think it would be fun to contribute there. :) geir GPL+exception != LGPL != GPL /Sven -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
[Legal] Issue for Contribution Process
The standard Apache contribution process goes something like this : a) Any individual that is a committer must have on file an Individual Contributor License Agreement[1] This document is a statement from the individual that says that anything they contribute is their original work that they are free to license under the Apache License. b) Any other entity can make contributions to the project via a Software Grant[2] or through the modified Corporate Contributor License Agreement[3]. Through this, if accepted, the documentation is registered with the Apache Incubator, and the contribution goes into the SVN repository of the accepting project. We will continue with these processes, but due to the extremely sensitive legal and political nature of our project, I'd like to discuss adding some additional constraints and processes in order to ensure that from the beginning, the codebase we maintain and develop has especially good tracking and oversight. First, as part of the Apache Harmony project, we keep a registry of all 'bulk' contributions. This doesn't replace the tracking the incubator does for these, but augments it - I think we would be well served if we internally tracked where code came from, and where we used it. One of the lessons that I learned with Apache Geronimo is that for things like this, there never is too much information or careful oversight and screening, because even for things that are clean and clear, you want to avoid any confusion or FUD about materials later on. Second, any contribution by an individual committer that is bulk - a quantity of code that is re-purposed, re-licensed or re- contributed, e.g. any bit of code that had been used elsewhere - be also registered as such. We may or may not want to go as far as a software grant from that committer. I'm not sure that there is any purpose to asking for one, but am interested in what others think. For any bulk contribution, we could have a checklist like the following to help track where code is coming from, and help remind committers about our contribution rules. Contribution Checklist for Individual Bulk Contribution 1) Identification Please provide the following information - Name of the committer and apache ID - Names of all authors of the code or other material being submitted 2) Author's Permission If you did not write the material yourself, you would need to have a written agreement with those who did write the material that either gives you ownership of the material or otherwise provides you sufficient rights to submit this material to the project on their behalf? - If you do not have such an agreement, then do not submit this Contribution. - If you do have such an agreement, you should provide details of this agreement. 3) All Authors Are Committers If you did not write the material yourself, are all of the authors committers to Apache Harmony and authorized to participate in the related project component? If not, then you should not submit this Contribution, although the Corporate Contributor License Agreement may apply. 3) Re-purposed or Re-Licensed Did you submit this Contribution to another open source or proprietary project? - If so, then you should provide details with the submission. Comments? geir [1] http://www.apache.org/licenses/icla.txt [2] http://www.apache.org/licenses/software-grant.txt [3] http://www.apache.org/licenses/cla-corporate.txt -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [Legal] Requirements for Committers
Geir Magnusson Jr. wrote: 8) Employment Limitations Are you employed as a programmer, systems analyst, or other IT professional? If so, you may be an commiter only if your employer either: a) signs a Corporate Contribution License Agreement with Apache and lists you as a designated employee or b) submits a written authorization for your participation in this project and disclaims any copyright or confidentiality interest in your current or future contributions to this project. IANAL, but this is a really tricky part, as different laws apply depending on where the contributor lives. Most countries have a different approach on this subject than the anglo-american copyright, namely the author's right. For my part, living in Germany, there is no way for my employer (even though I'm employed as a software developer) to claim any rights on work I'm doing in my spare time and there is no legal way for me to disclaim or overdraw my author's right on any work I've done. Even the author's right on the work I'm doing for my employer stays with me, all they can claim is an exclusive right to _use_ the code. I have been working on a few smaller projects lately, which may be of interest to the Harmony project, and I would find it a pity, if your legal requirements makes it difficult for me to contribute. Tor
Re: [Legal] Requirements for Committers
Geir Magnusson Jr. wrote:
What are you working on?
It's a framework to ease JNI programming, or more precisely to make it
possible to call native, e.g. OS functions without writing wrapper code
in C to do type conversions etc.
For example, invoking the Windows MessageBox function in user32.dll can
be done like this:
EasyJni jni = EasyJni.getInstance();
NativeLibrary user32 = jni.loadNativeLibrary(user32);
long ctext = jni.createCString(Message box text, UTF-16LE);
long ctitle = jni.createCString(Message box title, UTF-16LE);
int res = (int)user32.invokeLong(
MessageBoxW, 0, ctext, ctitle, MessageBoxConstants.MB_OKCANCEL);
jni..free(ctext);
jni.free(ctitle);
C structs can be mapped to Java classes using annotations, as here with
the WAVEFORMAT struct used by the Windows audio API:
@NativeStruct(endian=Endian.little, size=16)
public class WaveFormat implements Modifiable {
@NativeField(type=FieldType.int16, offset=0)
private int formatTag;
@NativeField(type=FieldType.int16, offset=2)
private int channels;
@NativeField(type=FieldType.int32, offset=4)
private int samplesPerSecond;
@NativeField(type=FieldType.int32, offset=8)
private int avgBytesPerSecond;
@NativeField(type=FieldType.int32, offset=12)
private int blockAlign;
// getter and setter methods ...
}
I needed this for some audio functionality, which is not available
through JavaSound. The JNI library could probably be used in several
fields, and seeing that Classpath does not implement any parts of
JavaSound, my Windows media API wrappers are probably a good starting
point for a new JavaSound implementation (at least targetted for Windows).
Tor
Re: [Legal] Requirements for Committers
On 6/8/05, Tor-Einar Jarnbjo [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: What are you working on? It's a framework to ease JNI programming, or more precisely to make it possible to call native, e.g. OS functions without writing wrapper code in C to do type conversions etc. Tor, is it legal to for you to contribute the API of this JNI programming framework? IMHO the API is as valuable as the implementation. -- Best Regards Steven Gong
RE: The Classpath VM interface. (Please read)
＞It could even be that a Harmony VM would be ＞incorporated with Sun's classlibraries to create a product by some ＞comercial vendor that could lawfully do that. In this view, it would be ＞important to have a VM-library interface that could accomplish that. If people really want to do that, then they will have the $$$ to have it done. As far as I am concerned, what interests me in Harmony is to have a really free good Java 5 VM embeddable everywhere (including FreeDSB, OpenBSD and others, as well as embedded devices for instance) with a good support for real-time and number crunching too (which means it will scale well for distributed applications/multimedia-DBs and all those fancy things to come in the near future). The very first step: having support for java 5 as-in-the-available-standards (i.e. something usable to something for some people, and also something to play with so that people can build reasonable real-life test suites on top of it - because I only trust what I see) is already a good bunch of work. The next step: having good support (read performance) for multimedia(number crunching)/realtime for instance, or some set of applications that really matter[1] so is probably more fun and cooler than just trying to follow fuzzy, obscure, dark-side implementation choices (and what about plagiarism charges in courts?), without just considering the efforts it would take to do it. Besides, having to follow crap specs (inexistent specs) is the best way to have a product that has a plethora of security holes other funny bugs IMHO. Regards, RB [1] And all kinds of advanced GC techniques JIT technologies as exposed by the specialists of these fields that are in this group. What I mean here is that there is probably some concrete target application set to focus on at the beginning (say the kind of stuffs that are priorities to micro$oft and apple/intel etc.), no more, no less. -Original Message- From: Bruno F. Souza [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 2:31 AM To: harmony-dev@incubator.apache.org Subject: Re: The Classpath VM interface. (Please read) Sven de Marothy wrote: I really don't view it that way. I view it as 'Is it worth spending effort on this?'. I understand where Geir is coming from here: even more important then the implementation, one of Harmony objectives is to involve different groups as well as commercial companies, to define a modular architecture for a J2SE implementation. It could even be that a Harmony VM would be incorporated with Sun's classlibraries to create a product by some comercial vendor that could lawfully do that. In this view, it would be important to have a VM-library interface that could accomplish that. But I mostly agree with Sven: if we're going to support plugging different libraries, we must start from somewere that is available and documented (Classpath has such a beast) and then work with the interested parties to expand that. For us to include the existing (non documented/proprietary) Sun interface it would have to be contributed by Sun into the discussion. This could be a good way of starting to propose a Sun involvement. If this proves a good idea it could even turn into a JCP spec as it was suggested. If Sun is not interested, I don't see any reason to invest effort in doing it, since it will have no pratical value. I think it is more probable that IBM or other Sun licensee that wants to use Sun's class libraries will just do the effort in order for then to use the existing library, and if legally possble, contribute that back. Without Sun's involvement, that's the best we could hope for. And if we want a pluggable infrastructure, we would still be better off starting from Classpath, since it already plugs into many VMs, while Sun's library seams to not have this advantage to start with. Better change one than many :-) Bruno. /Sven -- Bruno. __ Bruno Peres Ferreira de Souza Brazil's JavaMan http://www.javaman.com.br bruno at javaman.com.br if I fail, if I succeed, at least I live as I believe
RE: [arch] Modules and interfaces (was: How much of java.* ...)
＞ It brings to mind some of the portability/modularity issues we've been ＞ wrestling with (at great length) with MMTk and the interdependence ＞ between the memory manager and the VM. Our solution is not earth ＞ shattering, but it evolved out of a very long struggle with issues like ＞ the one Geir is alluding to above. ＞ ＞I will most probably be told why not very shortly, but is it not ＞possible to use the class loader to solve this problem? Indeed if you add some "AOP-like" code at the right place (check the resource names, do something specific if it is VM-specific) it might just do (at least conceptually). After all it is just possible to instrument classes and add whatever code is required at runtime, so I guess the java.lang.* classes do not really need to have everything available in the jar that is exposed to users, except what is in the standards (the signatures, the code itself is another question, right?). Sound like mil. security principle: give people just what they need to do their jobs, not more. RB -Original Message- From: Matthew French [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 6:09 AM To: harmony-dev@incubator.apache.org Subject: Re: [arch] Modules and interfaces (was: How much of java.* ...) On Tue, 2005-06-07 at 07:35 +1000, Steve Blackburn wrote: It brings to mind some of the portability/modularity issues we've been wrestling with (at great length) with MMTk and the interdependence between the memory manager and the VM. Our solution is not earth shattering, but it evolved out of a very long struggle with issues like the one Geir is alluding to above. I will most probably be told why not very shortly, but is it not possible to use the class loader to solve this problem? My first solution would be too implement VM specific functions in their own library, but using existing the namespaces, not creating new ones. So you have your own java.lang.Thread, for example, that works with your VM. The class loader then uses the VM specific functionality to override the generic functionality. This acts like a mask, hiding functionality that the VM authors decide is specific to the VM, but leaving all the other generic functionality exposed. This has the advantage that it reduces the amount of re-work while allowing enormous flexibility. The only requirement is that the class libraries call the public API instead of internal implementation classes - i.e. make no assumptions about the implementation of any other class (as much as possible, anyway). This also makes it possible to inject, for example, a VM specific String class, or specially tuned Socket classes. But at the same time for other VM's to use the generic String class. The principal can be extended so that application specific classes can override the generic classes. Although this is wrong for so many other reasons. :( From a brief look at the classpath docs, it looks like classpath uses a similar approach - from what I can tell the one I am suggesting is just more generic. Or is the issue deeper than this? - Matthew
RE: [Legal] Requirements for Committers
It is quite similar in French law (soft copyright law being a derivative of usual author copyright law: author's right belongs to the author, period; usage right can be granted/sold/etc. but NOT the author's property). Not sure about Japanese law (I am living in Japan and France :-)). I guess we should not try to have legal stances that are just too obscure or absolute (and hence just not compatible with some countries laws). Sorry this is more like a problem than a solution, but it would be a pity to be deep in the because we ignore laws diversity. -Original Message- From: Tor-Einar Jarnbjo [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 8:01 AM To: harmony-dev@incubator.apache.org Subject: Re: [Legal] Requirements for Committers Geir Magnusson Jr. wrote: 8) Employment Limitations Are you employed as a programmer, systems analyst, or other IT professional? If so, you may be an commiter only if your employer either: a) signs a Corporate Contribution License Agreement with Apache and lists you as a designated employee or b) submits a written authorization for your participation in this project and disclaims any copyright or confidentiality interest in your current or future contributions to this project. IANAL, but this is a really tricky part, as different laws apply depending on where the contributor lives. Most countries have a different approach on this subject than the anglo-american copyright, namely the author's right. For my part, living in Germany, there is no way for my employer (even though I'm employed as a software developer) to claim any rights on work I'm doing in my spare time and there is no legal way for me to disclaim or overdraw my author's right on any work I've done. Even the author's right on the work I'm doing for my employer stays with me, all they can claim is an exclusive right to _use_ the code. I have been working on a few smaller projects lately, which may be of interest to the Harmony project, and I would find it a pity, if your legal requirements makes it difficult for me to contribute. Tor
Re: [Legal] Requirements for Committers
Good Best Regards, William Wu Software Engineer Sybase Shanghai RD Center Room 1202-1206, Building One, Zhangjiang Semiconductor Industry Park 3000 Longdong Avenue Pudong, Shanghai 201203 Tel: 8621-68799918 ext 3081 Fax: 8621-68790199 Email: [EMAIL PROTECTED]
Re: [Legal] Requirements for Committers
On Jun 7, 2005, at 9:34 PM, Renaud BECHADE wrote: It is quite similar in French law (soft copyright law being a derivative of usual author copyright law: author's right belongs to the author, period; usage right can be granted/sold/etc. but NOT the author's property). Not sure about Japanese law (I am living in Japan and France :-)). I guess we should not try to have legal stances that are just too obscure or absolute (and hence just not compatible with some countries laws). Sorry this is more like a problem than a solution, but it would be a pity to be deep in the because we ignore laws diversity. Which aspect? We're not ignoring diversity here. We're trying to get started figuring out what to do. We'll have to consult the ASF legal team, but the issues of the CCLA is universal at the ASF anyway. The issues won't go away if we just try and ignore them. geir -Original Message- From: Tor-Einar Jarnbjo [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 8:01 AM To: harmony-dev@incubator.apache.org Subject: Re: [Legal] Requirements for Committers Geir Magnusson Jr. wrote: 8) Employment Limitations Are you employed as a programmer, systems analyst, or other IT professional? If so, you may be an commiter only if your employer either: a) signs a Corporate Contribution License Agreement with Apache and lists you as a designated employee or b) submits a written authorization for your participation in this project and disclaims any copyright or confidentiality interest in your current or future contributions to this project. IANAL, but this is a really tricky part, as different laws apply depending on where the contributor lives. Most countries have a different approach on this subject than the anglo-american copyright, namely the author's right. For my part, living in Germany, there is no way for my employer (even though I'm employed as a software developer) to claim any rights on work I'm doing in my spare time and there is no legal way for me to disclaim or overdraw my author's right on any work I've done. Even the author's right on the work I'm doing for my employer stays with me, all they can claim is an exclusive right to _use_ the code. I have been working on a few smaller projects lately, which may be of interest to the Harmony project, and I would find it a pity, if your legal requirements makes it difficult for me to contribute. Tor -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: The Classpath VM interface. (Please read)
Sven de Marothy wrote: Geir.. I really don't get your position here. The way I read your arguments are: Harmony should spend time and energy implementing Sun's class library interface, which is proprietary, closed-source, unspecified, may change at any time and requires a licensing agreement with Sun to be practically useful. And if Harmony doesn't spend time on this, it'd be 'willfully restricting' the ability of users? I really don't view it that way. I view it as 'Is it worth spending effort on this?'. +1 I don't claim to know the final word on the subject by any means... but my gut feeling is that almost nobody is going to want/need to download Harmony and then use a different class lib that the one that's included. If we pass the TCK and make a quality product (VM + Classlib) I believe people will either download and use it, or not download and use it, as a whole. I have a very difficult time seeing the need for spending a lot of time worrying about allowing people to switch out classlibraries. I can see some very unlikely edge cases that might prompt somebody to mix-n-match classlibs and VMs, but it doesn't strike me as being a particularly important feature. TTYL, Phil -- North Carolina - First In Freedom Free America - Vote Libertarian www.lp.org
