Re: BASE64Encoder class missing?
On Wed, 2006-08-09 at 17:58 -0400, Geir Magnusson Jr wrote: Yes- the idea is to provide that suncompat.jar for that reason with those clases in the sun.* namespace that user apps depend on. This way lies madness. I urge you to take a strong stand against bad applications. Experience tells us that application developers are happy to fix their programs once made aware of this issue. GNU Classpath users have already paved the way with the developers of many popular programs and libraries (Eclipse, OpenOffice.org, Azureus, a lot of Apache code like Batik and Tomcat, etc). This is the only solution that makes sense for users and developers. AG - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Cairo for Harmony graphic stuff?
On Mon, 2006-02-13 at 13:38 +0300, Sergey Soldatov wrote: In my opinion the only area to use Cairo is the Java2D part of AWT. Unfortunately any additional layer between 2D and native calls may dramatically affect the performance of UI, especially Swing. GNU Classpath is using Cairo, but I think a better plan now would be to use jogl (JSR231, whose reference implementation has a very liberal license). Sun has done some interesting work with their OpenGL single threaded rendering backend to address the JNI overhead issue. You get nice 2d/3d integration as well. AG
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
On Thu, 2006-02-09 at 13:41 -0500, Geir Magnusson Jr wrote: We were planning to just use the eclipse compiler. No reason to rewrite. Didn't you just write in this thread that you need all the tooling? What makes the compiler special? If you can non-Apache FOSS licensed tools, why not just use the excellent gjdoc for your javadoc tool? http://www.gnu.org/software/classpath/cp-tools/ AG
Re: NIO Component improvement
On Wed, 2006-01-18 at 21:51 +0300, Vladimir Strigun wrote: Attached document contains a proposal describing an approach which is trying to enforce portability of nio socket channels implementation by moving supporting functions up to java layer and by sharing the code between java.net's socket implementations and socket channels in java.nio package thus reducing the amount of java code and number of native methods in both packages. If I understand your document properly, this is similar to how we handle things in GNU Classpath (see gnu.java.net.PlainSocketImpl). One difference is that we throw exceptions in the JNI code. As you mention in your document, this has the disadvantage of resulting in a JNI class lookup -- but in your example, don't you have to do a second JNI call to get the error string? (BSDSocketErrors.getMessage(res)). (For GCJ, we implement this code in CNI - not JNI. It's simpler and there's zero overhead between the Java and C++ code - so we can throw exceptions in C++ code with no JNI name lookups.) AG
Re: ASF has been shipping GPL exception stuff for years and still is ;)
On Mon, 2005-12-05 at 00:13 -0500, Davanum Srinivas wrote: But even then, there is no guarantee that people will want to do it because they can't make a closed fork if they want to for whatever reason. (Which ASL allows and if people wanted to do that, they would already be participating in one of the existing VM's in the classpath galaxy). This is true. My feeling about this, as it relates to the core class libraries, is that this is no place for proprietary innovation. Let people innovate around JIT, GC or other technology, but we're all better off collaborating on a first class J2SE-certifiable core class library collection. The proprietary Java vendors seem to agree on this point since, as far as I can tell, they all use the same class libraries as well. AG
Re: ASF has been shipping GPL exception stuff for years and still is ;)
On Mon, 2005-12-05 at 11:53 -0500, Davanum Srinivas wrote: Anthony, for example, there is work done already on XSLTC (http://xml.apache.org/xalan-j/xsltc_usage.html) in Xalan. I'd like to be able to make *my* JRE distribution use this by default. To save space, i *don't* want to use the gnu xml stuff. why should i have to distribute that? see my point? I don't believe there's anything preventing you from doing that today. Fedora Core ships GNU Classpath (via libgcj) as well as Apache XML code. Users can choose to use the Apache code instead of the GNU with a command line option if they like. AG
Re: Testsuite (Was: Where to place the core classlib code?)
On Mon, 2005-12-05 at 20:34 +0100, Mark Wielaard wrote: On Thu, 2005-12-01 at 16:38 +, Tim Ellison wrote: Unless/until someone shows up with a comprehensive test suite we have to start by writing tests for everything that gets patched. Take a look at http://www.sourceware.org/mauve/ Speaking of Mauve (a project born of class library licensing frustrations!), there's some real interest amongst the Mauve community to migrate the test cases to JUnit. The Mauve infrastructure predates JUnit. This would be a universally useful task for some enthusiastic contributor. AG
Re: Full disclosure
On Thu, 2005-12-01 at 10:47 -0800, Dalibor Topic wrote: Yup. I think dual licensing with the LGPL should be sufficient for that to happen, and get us rolling forward in that aspect as well. Rather than dual license the code, maybe switching to LGPL+exception would be better. The GNU FOO+exception licenses say that you can redistribute using the FOO license at will. But what would be the point of a relicensing effort like this? AFAICT, many people here show no interest in collaborating on a single free class library project. AG
Re: Full disclosure
On Mon, 2005-11-28 at 07:16 -0800, Leo Simons wrote: I didn't take notes but one of the many things I took away from this is that it might be a real good idea to try and see if classpath can be LGPLed; Mark seemed to think that is not an unattainable goal. When I get my hands on some spare time (I hope it'll be under the christmas tree) I hope to push forward om some of that. I don't understand this. The GNU Classpath license was designed to be even more liberal than the LGPL. What makes relicensing GNU Classpath to LGPL a good idea? AG
Re: The Unofficial Harmony, Licensing, the Universe and everything FAQ
On Thu, 2005-11-17 at 14:50 -0800, Leo Simons wrote: As a special exception, for Classpath we have decided to make all the problems described at http://www.apache.org/licenses/GPL-compatibility.html go away. And then in proper lawyer terms. Heh. Very interesting, very pragmatic! Mark, do you think there's any chance of making this happen? IANAL, but my understanding is that there are two ways to make all the problems go away: a) Modify the Apache license to remove the additional restrictions, or b) Modify the GPL to remove the additional restrictions requirement. Only the copyright holders of the Apache licensed code can do (a), which doesn't seem to be what you're proposing. As for (b), this would effectively make GNU Classpath incompatible with GPL licensed code, because we still have Apache's additional restrictions to worry about. This is a non-starter for a GNU project. I like the creative thinking though. AG
Re: Third Way - implement the JVM in a new C/Java hybrid
On Fri, 2005-05-13 at 14:25 +0100, David Griffiths wrote: I thought GCJ was a static compilation system? Not quite. GCJ is an ahead-of-time (AOT) compiler for the Java programming language. However, the GCJ runtime execution environment supports all of the dynamic properties of the Java programming language (run-time loading/linking/verification, reflection, all of the binary- compatibility rules, etc) for both bytecode and AOT compiled code. AG
Re: I hope the JVM implements most using Java itself
On Wed, 2005-05-11 at 13:10 -0500, Archie Cobbs wrote: Those are good points.. I'm not saying JIT is bad, I'm just saying WAT has a place and can sometimes do things that JITs cannot because of time constraints. Yes - in the real world, JITs don't always necessarily win. Here's an example. Wikipedia is currently using a gcj-built version of Lucene to power their search feature. Here's some text describing a benchmark that help them make this decision: - cut here Crude, simple benchmark; does single-word fulltext search for pope 100 times sequentially. This is a fairly popular word, and returns 6890 results from the test database used (English Wikipedia, 2005-03-09 dump). Time returned is the average time spent for a request on the client, over the second set of 100 runs. GCJ 4.0 -O2: 588.3437 ms (fastest) Sun Java 1.5 -server: 636.9209 ms Sun Java 1.5: 695.5374 ms GCJ 4.0: 707.2302 ms Mono 1.1.6: 894.4488 ms (slowest) Each version of the daemon read from the same index set, which I had generated with the Mono-based version. (dotlucene 1.4 is index- compatible with the Java Lucene 1.4.) - cut here I'm fairly certain we can do much better with additional compiler options (-march=pentium4 and the like). In any case, this is a showcase app for Apache + FSF technology working together in an important real-world application. AG
Re: Contributing to project...
On Tue, 2005-05-10 at 21:45 +0200, Art - Arthit Suriyawongkul wrote: On 10 May 2005 13:30:45 -0600, Tom Tromey [EMAIL PROTECTED] wrote: Yeah. Also, note that all the missing parts of java.math are new in 1.5. It helps to look at the 1.4 comparison as well, to see what is historically missing and what is just new. I believed one among them is in BigDecimal, from JSR 13. JSR 13: Decimal Arithmetic Enhancement http://jcp.org/en/jsr/detail?id=13 Based on the work from IBM http://www2.hursley.ibm.com/decimal/ http://www2.hursley.ibm.com/decimalj/ (Java implementation with sources under IBM alphaWorks License Agreement) This code is also available in ICU4J sources, which have the liberal X license. I know Mike Cowlishaw, the IBM fellow who did the work and asked him his work. He wrote: The ICU4J BigDecimal (com.ibm.math.BigDecimal) is very close in principle to the Java 1.5 version, but was always just intended as a prototype for JSR 13. There are minor but subtle differences in the arithmetic (following details changed by IEEE 754 since then) and in the API. It would need some careful work to bring it into line (though of course very much less than writing it from scratch!). It never really became critical enough to get anywhere near the top of my TODO list. AG
Re: State of the World (it's security)
On Tue, 2005-05-10 at 21:43 -0400, Bob wrote: If Harmony security works only for applets, then it will not be useful for my needs. GNU Classpath implements java.lang.SecurityManager and related code which may be used in any application. I think we're just left with simple bugs to fix as opposed to big wide gaping holes with no plans to fill them. Moreover, it needs to be able to securely run Java code that wasn't specifically made for Harmony (i.e. the Java spec needs to be followed). That's what's been done. AG
