Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Stefano Mazzocchi schrieb: It's called quicktime for java and has been there for years :-) Sure, Quicktime for Java is not that bad, but unfortunately using heavyweight native GUI widgets, which are difficult to integrate without side effects in a Swing application. If platform dependency is accepted, there are also a lot of e.g. ActiveX-bridges allowing ActiveX-enabled media components (also GUI or video widgets) to be integrated in a Java application. Tor
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Fernando Cassia schrieb: Which defeats the whole purpose of cross-platform java in the first place. So why not do it win32 / linux /Gtk then? Because Java as a programming language has other advantages than platform independence. Tor
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Fernando Cassia wrote: I'm still scratching my bald head thinking why hasn't Google embraced desktop java yet. Google Talk would be a killer app written in Swing / 100% Pure Java. It's never stupid to stay realistic. There is no JavaSound implementation giving you enough control of e.g. the sound card latency to allow a usable telephone application to be implemented. H*ck, there's even a pure-java mpeg4 implementation Which doesn't work for me. A few still frames are being shown and updated every few seconds and then the player hangs. Apart from that, due to other problems with JavaSound is it not possible to implement reasonable quality video players in Java. The JavaSound API has functions to read the current position of the audio playback, to sync the video accordingly, but the accuracy and correctness of this function makes it unusable. Tor
Re: CLA issues Was: java.sql.*
Leo Simons wrote: I'll also request everyone tries to ensure that you do not try and represent anything as legal fact unless its been thoroughly verified that it is indeed rather certain that what is being said is undisputable. Also, always try and provide as much references as possible. The problem root lies back in the times when the first laws where written to protect intellectual property. In UK, copyright laws were written, which originally only regulated reproduction and publishing rights, while in France the laws were centered around the droite d'auteur or author's right. Later, copyright laws were only adopted in the countries most strongly influenced by the UK, e.g. USA and probably Canada, while most other countries adopted the French idea of generally protecting the author as a static owner of his intellecutal property. In Germany, the author's rights are so strong, that they even to some extend apply for works produced by an employee or as part of a paid assignment. The issues I'm pointing out are regulated like this in the German Gesetz über Urheberrecht und verwandte Schutzrechte (Law on author's rights and related protective rights): §29(1): Das Urheberrecht ist nicht übertragbar, es sei denn, es wird in Erfüllung einer Verfügung von Todes wegen oder an Miterben im Wege der Erbauseinandersetzung übertragen. The author's right is not transferable, unless it is transfered to an inheritor in connection with the author's death. §§ 41 and 42 are regulating the author's Rückrufsrecht or revokation right. §41 is regulating the case, in which an exclusive usage right is not being practised, while §42 is regulating the author's right to revoke a usage right, in case of gewandelter Überzeugung, however that is to be translated properly to English. Modified/changed belief or conviction is a brave attempt. §42(2) regulates that the author's right to exercise his revokation right can not be excepted. §34 regulates the transfer of usage rights and sublicensing (Übertragung von Nutzungsrechten). Any such transfer must be agreed upon by the author, although it is restricted in which cases he may deny such transfer to take place. At least the way I interpret these regulations, it is not possible for the author to agree to a blanket sublicensing grant, as his rights depends on the exact conditions around the license transfer. Regulations on derivative works are spread across several paragraphs (§§14, 23, 39, etc). As in the issue with §42, derivative works may not be produced or published if they are against the author's belief (which may change with time). Tor
Re: NDA issues and acceptable use of sun source
Geir Magnusson Jr schrieb: I'm not so sure - the fact that there's been that exposure under NDA means there can be no contribution in that area until the NDA problem is resolved. Which means? Do I have to solve it or are you willing to solve it? Geir Magnusson Jr wrote: Are you kidding? Of course I am not kidding. I am willing to offer a contribution, you say that an issue has to be resolved to allow that and I ask who is going to do that. Do you expect from your contributors to pay for legal advice to be allowed to do non-profit work for you? Tor
Re: CLA issues Was: java.sql.*
Geir Magnusson Jr schrieb: I would further argue that if the author must retain right to revoke the license or have control over derivative works, then open source is impossible in Germany. Obiously it is not, as long as the software users accept the potenial risk of having to replace the software with something else. The revokation right is not my interpretation, but very clearly stated in the law. Given that there is plenty of open-source activity in Germany - and serious efforts - I think that we're misunderstanding something fundamental about German copyright law. It is unfortunately not very uncommon that German companies have a policy not to use OS software at all, partly because of the unclear legal status and potential problems, which may arise with a legal dispute, partly because of other issues, e.g. not having anyone to sue if something goes wrong. As I was working for Siemens 5-6 years ago, this limitiation was so strict, that we were not even allowed to use open source text editors (e.g. vi or Emacs) to write code, but were forced to use a very poor and annoying product, as there were not really many options when you have to find a commercial text editor for HP-UX. Tor
Re: CLA issues Was: java.sql.*
Geir Magnusson Jr wrote: It's not OSS if the author can do that arbitrarily. Think about it - you could wait until something is really popular, and then go shake down every user using it... Not necessarily the users directly, but at least the enity, which is managing the reproduction and distribution rights. The point is to guarantee the author an adequate commision if e.g. more copies of his work are published than the author was able to expect when he granted the original publishing license. The idea does not match very well with free as in free beer, but this is indeed the legal situation in most countries. Heh. Double heh. Yes, heh. Tor
Re: CLA issues Was: java.sql.*
Geir Magnusson Jr wrote: I thought I better split this, to prevent the discussion from getting too confusing. One thing I already pointed out with the Apache CLA is that it is very biased towards US copyright law. Well, the ASF is a US Corporation (non-profit) so those are the laws under which we operate. Yes, but US laws are not the laws under which probably most of the contributors are operating and not the laws applicable in most locations where Apache software is being used. Copyright is a legal area where US and British law deviate quite a lot from most other countries and assuming or expecting that US law is relevant if it comes to a legal dispute between e.g. a non-US contributor and a non-US software user or a non-US owner of related intelletual rights, is IMHO rather naive. License. First problem is, that I can't grant you anything I currently don't have, a copyright on my work. The German counterpart, my Urheberrecht is not transferable and any license I give to use, redistribute, modify etc. the work may under some conditions be revoked. Any contract diverging from these principles is in Germany legally void. We aren't asking for a copyright transfer. You still retain any and all copyright on the work. What you are doing is granting a license to the work under the Apache License. Well, you skip the most important part, that some statements in the paragraph are legally void in Germany, and probably most countries, not having an Anglo-Saxon style copyright law. Most problematic are probably the claims for an perpetual, irrevocable license and the claim for sublicensing rights and rights to produce derivative works. I really don't like to bother with legal regulations, but wether you or I like it, this agreement won't hold if proven in a German court and a German court will be responsible, if a German contributor for some reason should decide to take legal actions against some other German entity, which e.g. is producing, distributing or using a derivate work of the contributor's original work. The word German in the last sentence may be replaced with many other nationalities, without invalidating the content :-/ Tor
Re: NDA issues and acceptable use of sun source
Geir Magnusson Jr wrote: I'm not so sure - the fact that there's been that exposure under NDA means there can be no contribution in that area until the NDA problem is resolved. Which means? Do I have to solve it or are you willing to solve it? It is of course silly of me not to keep legal agreements I have signed, but as Leo pointed out, is Sun not anymore requiring an NDA for other people to get access to the JDK source code. If what you were exposed to under the NDA has no tie to what you are offering, then the NDA is irrelevant for this. For other things, you still have a problem, but if you've never seen Sun code in and around the sound API, then you are fine. I do of course not remember anything of any source code I had in my hands ten years ago. I even quite often forget in the afternoon what I did before lunch. I am not sure however, if Sun's lawyers believe that and I rather don't want to find out. Tor
Re: Using Cairo for Harmony graphic stuff? [was Re: Using APR for Harmony's native link to the OS?]
Stefano Mazzocchi wrote: Another think that I wonder, for the windowing stuff, why don't we use Cairo[1]? Isn't Cairo just a rendering library? AFAIK, it does not offer any kind of e.g. portable widget access, which is probably the most tricky thing to implement for AWT. Swing can be implemented in pure Java, based on some simple native support by AWT (open window and supply a Graphics object into which the content can be rendered). I don't see where Cairo can offer much help in that area? Tor
Re: java.sql.*
Jeremy Huiskamp schrieb: Would I be correct in assuming that the majority of java.sql would be trivial to implement by reading the javadocs (everything except DriverManager)? I can take a whack at the low hanging fruit this weekend. The java.sql package mostly contains interfaces, so it shouldn't be too much work, but what's so difficult about the DriverManager. It only has to manage a list of registered Driver implementations and the getConnection methods should only iterate through the available drivers, check if the URL is supported and if yes, delegate the call to Driver#connect. Tor
Re: java.sql.*
Jeremy Huiskamp wrote: Didn't say it was difficult, just that it's not trivial ;-) As in, the javadocs don't tell me everything I could possibly need to know to implement it. I'd love to take a crack at it, but I figured I'd start with the really easy stuff. If you beat me to it then so much the better :) I already thought about contributing some other stuff, but I am unsure if I fulfil the requirements for contributing (especially regarding exposure to Sun's source code). I sent a mail to Geir Magnusson about JavaSound implementation a few weeks ago, but didn't get any reaction. Perhaps it's better to discuss this here on the mailing list. Tor
Re: java.sql.*
Geir Magnusson Jr wrote: Yes, this would be the place. Sorry about that - I am in the middle of a machine change, and email switch, so I've been an email blackhole at times... So, I sent you a partial implementation of JavaSound and a Vorbis SPI, any interest? One problem is of course, that I more than once have taken a look at Sun's source code for different reasons and even signed an NDA some ten years ago to get access to the source code for JDK 1.1. Your requirements in the contributor license agreement and questionnaire are IMHO rather vague. Tor
JavaSound Was: java.sql.*
Geir Magnusson Jr wrote: Lets discuss that here. :) I didn't mean to ignore you - but two mail machines were hard to follow. I'm ready to join them into one, and hopefully I'll stop dropping the ball :) Ok, here are a snippet from the mail I sent you: (Win32 partial implementation of JavaSound): http://jarnbjo.de/HJavaSound.zip Installation is quite simple, just copy the following files to jre\lib\ext: dist/sound.jar, dist/vorbis-spi.jar and the following files to some directory in the dll path (e.g. jre\bin\default): dist/sound.dll The ant build file will build the HJavaSound Java source code and the C source using Borland's CBuilderX. I know it's not pretty, using hard coded paths etc., but it was just a quick hack to simplify the build process. The source code for the SPI and player are included in the vorbis-spi and spiplayer directories, for which no build files are included. Hope you don't mind that I already chose to put implementation specific classes in the org.apache.harmony.sound.sampled package. Ogg/Vorbis files should now play with java -jar dist/spiplayer.jar filename. The Vorbis SPI for JavaSound and the SpiPlayer itself are actually parts of my project J-Ogg (ww.j-ogg.de), which is already released under an Apache-style license (http://www.j-ogg.de/core/main?/download-libraries.html). Another issue with this is of course that the current VMs working with Harmony are not able to use Java 5 class files and implementing JavaSound for 1.4 and later extending it for Java 5 would be at least some unnecessary work. Are there any current plans for extending the VMs for Java 5 code? Which code, and what were the terms of the NDA? The CLA is fairly lightwieght. Good questions, I honestly don't know. Working as a Java developer, I now and then need to trace into the original source code or take a look or two at the API implementation to realize why something is not working as I expect. As far as I can remember, I have not done this with Sun's JavaSound implementation. I don't have the NDA anymore, or am at least not able to find it, having moved around several times the last ten years. For working on a JavaSound implementation, it is probably irrelevant anyway, as JavaSound was not introduced until Java 1.3 and ought not to be covered by any agreement in Sun's NDA. Tor
CLA issues Was: java.sql.*
Geir Magnusson Jr wrote: Which code, and what were the terms of the NDA? The CLA is fairly lightwieght. What questions do you have for both? I thought I better split this, to prevent the discussion from getting too confusing. One thing I already pointed out with the Apache CLA is that it is very biased towards US copyright law. I am not a lawyer and I really have no clue if US copyright law, German Urheberrecht or both applies if I, living in Germany, am signing a contract with a US entity. The most serious legal crash is probably section 2: Grant of Copyright License. First problem is, that I can't grant you anything I currently don't have, a copyright on my work. The German counterpart, my Urheberrecht is not transferable and any license I give to use, redistribute, modify etc. the work may under some conditions be revoked. Any contract diverging from these principles is in Germany legally void. Another specific issue related to my proposed Vorbis SPI for JavaSound donation, is if you regard third party source code to be classified as format documentation . To be more exact, the Vorbis format specification from the Xiph Foundation proved to contain several errors and their attitude when me pointing it out was, that the reference decoder is the only thing to be considered as a formal specification. This means of course, that at least when it comes to some estimated 20-40 lines of code, my Vorbis decoder implementation is at least based on the reference decoder from Xiph, which is AFAIK released under a BSD license. Patent issues are also unclear to me. At this point the CLA is really vague (§5), only demaning me to represent that my contribution is free of any patents that I am personally aware of. I have absolutely no ability to judge on that, which of course fulfils, that I am not personally aware of any claims, but depending on the contributors knowledge on patent and license law, this paragraph lies somewhere between meaningsless and very dependent on which country's patents and licenses are to be considered. Tor
Re: ntwin32.mak dependency
Geir Magnusson Jr schrieb: Please, feel free to take a whack at it. Just don't break us that are using the non-free toolchain. I was just curious if I was doing something wrong and generally the opinion, that it would make sense to not require a rather expensive compiler suite to build the Harmony VM. I am not sure however if I can be of much help fixing the issue. I haven't been writing much C for several years and honestly have no clue what is necessary to tweek the source to be buildable by other compilers. Tor
ntwin32.mak dependency
Hi, when building Harmony on Windows, the makefile in native-src\win.IA32\makefile includes ntwin32.mak. Could it be that this utility file is only included with the commercial versions of Visual C++/Studio? If so, and if this is the only dependency on the commercial version, would it be easily feasible for someone to replace the file with someone else, making it possible to compile Harmony with the freely available MS C++ compiler and nmake? Or is it just something here, that I haven't understood? Tor
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: [arch] VM/Classlibrary interface
Rodrigo Kumpera wrote: Last time I checked, no one, nether me or you, is developing code agains the TCK, but to a real JVM. And as hard as we may try, sometimes we end with software that depends on unspecified behavior. So it's better try to be bug compatible too. No, I don't agree on this either. Dalibor already mentioned several good reasons why Harmony should not try to be implementation compatible with any other VM and another good reason is that the usage of com.sun-classes is also version or release dependent of Sun's VM. If Sun decides to rename, repackage or somehow change the internal classes in a new VM release, e.g. 1.5.0_04, code relying on these classes will break as well. The implementors of such code should fix their part and no other VM vendor seem to find a reason to implement their VMs in such a fashion that broken code will run on them. Tor
Re: [arch] VM/Classlibrary interface
Geir Magnusson Jr. wrote: (Tomcat : I'd bet they fixed that (or will fix...)) It doesn't seem so. The SSL code has been in Tomcat versions 4.1.x to 5.5.9 and I just saw that also the LDAP code in Tomcat 5.5.9 uses classes in com.sun. Well, can't the VM just prevent non-kernel code from using them? Maybe overhead too high? How do you distinguish kernel code and non-kernel code? From the VM point of view, the classes in the java(x).* packages do not differ from user code classes and it is also possible to bootstrap the VM and replace java(x).* classes with own implementations. Been there, done that. Tor
Re: [arch] VM/Classlibrary interface
Geir Magnusson Jr. wrote: I meant execution context. Is there a clear boundary between code thats executing in the context of the VM and code that's executing in the context of the 'user' app? Usually not, but it might be possible to emulate something similar using several classloaders or implement the necessary mechanisms in the default classloader. One similar example can be taken from Java applets. They are of course not allowed to load and execute native code, as the VM can't enforce any privilege checks on what the native code is doing, still though, the applet must of course be allowed to indirectly execute native code through the standard API, e.g. to gain allowed network access. In this case, the applet classes are loaded by a restricted classloader, which does not allow direct access to native code, while the standard API classes are loaded by a privileged classloader, which grants all privileges on kernel level and relies on the implementation of the classes to enforce the necessary security checks. All this magic is however implemented using the mechanisms in the security manager and since an application must be allowed to use its own security manager, I don't see how it could be possible to prevent an application to break through such a protection either. Tor
Re: [arch] The Third Way : C/C++ and Java and lets go forward
Geir Magnusson Jr. wrote: (for the record, this isn't about not doing Java or not doing JikesRVM, but rather my understanding that we'll need a small C/C++ kernel to host the modules, no matter how they are written, and this is a way to get that going...) Excuse me if I'm missing something, but wouldn't it be necessary to implement parts of the VM or the class library in native code anyway? I'm thinking about code to access e.g. resources like I/O devices, sound etc.? Or is this discussion C vs Java restricted to the bytecode executing part of the VM? Tor
