Re: Swing/Graphics2D
On Sun, 2003-01-12 at 01:23, Artur Biesiadowski wrote: > BTW, do you know about ANY real-world program which actually used custom > Composite implementation ? Or custom Paint implementation ? I'm really > angry at all this Raster stuff - it makes hardware acceleration of most > things really hard. > I believe any SVG rendering tool will have a RadialGradient implementation of the Paint interface, since only a linear gradient is included in the JDK. I've been playing around with Java2D and some applications that use it and I haven't seen other implementations of those interfaces yet outside the that one and the ones in the JDK. Btw, it's probably hard, but if you implement it with some sort of pipeline architecture like Sun claims to use, you can select hardware-accelerated implementations when this is possible and use software rendering when some component or rendering-hint that can't be accelerated is used. >From what I understand the main problem Sun has is making a hardware-accelerated operation look exactly the same as the software-rendered version, since the Graphics2D implementation doesn't know when you start drawing whether all operations can be hardware accellerated. But if you look at the rendering-hints, and the application has selected the speed-over-quality hint, you may get away with some minor inconsistencies. Erwin > Artur -- Erwin Bolwidt <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FileURLConnection
Nic Ferrier wrote: >Erwin Bolwidt <[EMAIL PROTECTED]> writes: > >>Why don't you use the javax.naming abstractions? I know Tomcat uses it >>with success. It is very extensible >> > >Using JNDI is not an option. > [...] >>and it seems better than changing the API of a standard API >>class... >> >I didn't propose that, see the next point. > >>you couldn't compile the code (without pre-processing) on >>any other implementation of Java's standard APIs; that doesn't feel >>quite right. >> >I could compile the code. > >What I said I wanted to do was change the FileURLConnection >class. This is an implementation class in package: > > gnu.java.net.protocol.file > Alright, my mistake. But note that I sent this e-mail to you personally, and not to classpath. I don't follow classpath as closely as I would like, one reason being that probably clicked on too many Sun licenses to contribute much. And since I e-mailed you privately in the past, I thought it would be alright to just mail you my comment. I didn't intend for the reply to be Cc:-ed to classpath... Best, Erwin ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Question on nested types
On Sun, 16 Sep 2001, Eric Blake wrote:
> I just noticed the JDK 1.4 documentation for java.util.Hashtable claims
> that Hashtable inherits the nested type Entry from Map:
> http://java.sun.com/j2se/1.4/docs/api/java/util/Hashtable.html
>
> This would mean that the following program should be legal, and output
> "true":
>
> import java.util.*;
> class Foo
> {
> public static void main(String[] args)
> {
> System.out.println(Hashtable.Entry.class == Map.Entry.class);
> }
> }
>
> However, it does not compile against Classpath, since the implementation
> of Hashtable defines a private nested class named Entry which hides
> Map.Entry, and Hashtable.Entry is not accessible (instead of being an
> alias for Map.Entry as the documentation claims). See JLS 8.5 for the
> specification of nested class hiding.
I think it is a bug in javac and jikes. Since Hashtable.Entry is private,
it is not visible to other classes, so it does not hide Map.Entry. So your
example should work, but the compilers are probably wrong.
It is not so strange though that Hashtable has its own Entry member class,
because Map.Entry is an interface that still needs to be implemented.
- Erwin
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: small patches for BigInteger, BigDecimal, Double
I don't know enough about these sources to comment on the patches, except
this small thing.
On Wed, 25 Apr 2001, J. Russell Smyth wrote:
> gnu/java/io/decode/DecoderEightBitLookup.javav - convertToChar wouldnt
> work with ascii values above 128 due to byte-char conversion
>
> public char[]
> convertToChars(byte[] buf, int buf_offset, int len, char[] cbuf,
>int cbuf_offset)
> {
>
> for (int i = 0; i < len; i++){
> - cbuf[cbuf_offset + i] = lookup_table[buf[buf_offset + i]];
> + cbuf[cbuf_offset + i]
> =lookup_table[buf[buf_offset+i]<0?256+buf[buf_offset+i]:buf[buf_offset+i]];
Why don't you write:
cbuf[cbuf_offset + i] = lookup_table[buf[buf_offset+i] & 0xff];
I think this is clearer and faster.
> }
>
> return(cbuf);
> }
Best,
Erwin Bolwidt
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
New KopiSusu beta 3 released
Hi, There is a new 1.9 beta 3 release of KopiSusu on http://www.klomp.org/KopiSusu/ It still compiles the classpath sources nicely, but it also detects more classes of errors at compile time and works better when compiling source against precompiled .class files that contain inner classes. The number of failures on the jacks testsuite is down to 34 from just over one hundred in the previous beta-2 release (if you use the Sun JDK1.3 to run the compiler, which creates an interesting baseline to compare against when running the tests with KopiSusu compiled with gcj or running on another VM.) ksusu: Total 1615Passed 1573Skipped 8 Failed 34 Regards, Erwin Bolwidt ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: KopiSusu beta release
On 16 Mar 2001, Brian Jones wrote: > Erwin Bolwidt <[EMAIL PROTECTED]> writes: > > > With the help of Mark Wielaard it has shown to compile the Classpath > > library right. Since I didn't get Japhar correctly installed, and the > > Classpath configure script seems to insist on japhar even with > > --with-japhar=no > > Yeah yeah... It's on my todo list. I'll accept patches! Well, it wasn't exactly a criticism. I just wondered why this is and if I'm making the error or the configure script. > > It's still a beta release until I'm sure that it can stand most tests, but > > those willing to try can download it from: > > > > http://www.klomp.org/KopiSusu/ > > What is the reason for forking kjc to create KopiSusu? I'll put it on the web page later today, you're not the first one to ask. Here's the blurp I'm going to put on it: What's the relation with KOPI? In response to a question I received about the relation between KopiSusu and KOPI, I'd like to say: I'm not sure how it is. When I started fixing some bugs in the original KOPI 1.4F release, I wrote a bug report and never got a response. That and the fact that the 'latest news' on the website at http://www.dms.at/kopi since may, 2000 led me to believe that the project was dead. After a few bugfixes to KJC to make it work for another project, I became interested to fix other problems I encountered, and after a while the changes accumulated into something that can be properly called a new release. A short while ago, I got in touch with Edouard Parmelan, who is/was responsible for bug reports and extensions for KJC, and learned that there are bugfix releases of KJC-1.4F at http://egp.free.fr/kaffe/ Unfortunately, I changed the code style. I use spaces instead of tabs, braces of method and type declarations on a new line, and an indent size of 4, and the order of member types, fields and methods according to Sun's code style. So it won't be easy to transfer patches from KJC-1.4F to KopiSusu, even though many parts of the code have changedbecause of refactoring and bugfixes. So, although I didn't really intend to make a split, it could be considered as just that. If somebody think this is a problem and has a constructive solution, I'm all ears. Erwin Bolwidt ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
KopiSusu beta release
Hi, I've made a new release of the KOPI/kjc compiler, and I've called the new package KopiSusu to indicate that it's not from the original authors of KOPI. It's a GPL-ed java compiler written in java. With the help of Mark Wielaard it has shown to compile the Classpath library right. Since I didn't get Japhar correctly installed, and the Classpath configure script seems to insist on japhar even with --with-japhar=no The way it worked for me was to go to the lib/ directory, run the gen-classlist script with standard.omit, and do ksusu -d out -nosystemlib -classpath Klasses.jar @classes (where ksusu is the script that calls the compiler) The compiler also does well on the jacks test suite. It's still a beta release until I'm sure that it can stand most tests, but those willing to try can download it from: http://www.klomp.org/KopiSusu/ Regards, Erwin Bolwidt ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
