RE: [PATCH] Field position attribute handling
Dalibor Topic wrote: 7 is the largest prime, that's still an iconst, iconst_7, afaik. That makes it take less bytecode. Actually, iconst_5 is the maximum, but this seems like a little too low level view of the problem space ;-) If two objects are not equal, they should have different hashCodes. No this isn't true, however, if two objects are equal, they must have identical hashCodes. It would be nice if unequal objects had different hashCodes, but this is not a requirement. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] Field position attribute handling
Jeroen Frijters wrote: Dalibor Topic wrote: 7 is the largest prime, that's still an iconst, iconst_7, afaik. That makes it take less bytecode. Actually, iconst_5 is the maximum, but this seems like a little too low level view of the problem space ;-) Thanks, I'll make it 5, then ;) If two objects are not equal, they should have different hashCodes. No this isn't true, however, if two objects are equal, they must have identical hashCodes. It would be nice if unequal objects had different hashCodes, but this is not a requirement. Note that I used *should* in my sentence instead of *must*, and reparse what I said ;) cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: new jalopy available
On Mon, Nov 17, 2003 at 06:19:02PM -0700, Tom Tromey wrote: Raif Naffah sent me a couple nice jalopy patches to implement things from my last wish-list. I wrote a new patch myself, to get jalopy to use tabs for indentation in the way we expect. I made a new release with these improvements. Once again, it is here: ftp://sources.redhat.com/pub/java/jalopy-console-1.0.4.tar.gz You'll also want this file, which is the GNU.xml style: ftp://sources.redhat.com/pub/java/GNU.xml This is somewhat different from the last one. This version seems to be much better. The strange Point.java change has disappeared (I didn't try to find out why). At this point I think we are ready to try this version of jalopy for real. I propose we pick a package to reformat and check in. Preferably we'd pick something where active work is going on, so we could more easily notice whatever jalopy doesn't handle well. Long term, we need to find a cvs repository for this version. We should also put GNU.xml into the classpath repository; I'll do this if we're all on board for the test drive. I used this Jalopy version and got a weird indentation in an if construct: if (way == X_AXIS || (way == LINE_AXIS component.getComponentOrientation().isHorizontal()) || (way == PAGE_AXIS !component.getComponentOrientation().isHorizontal())) With XEmacs I got the more correct indention: if (way == X_AXIS || (way == LINE_AXIS component.getComponentOrientation().isHorizontal()) || (way == PAGE_AXIS !component.getComponentOrientation().isHorizontal())) I think this should be fixed before we use jalopy. Michael ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] Field position attribute handling
Dalibor Topic wrote:
Hi Tom,
thanks for the comment. I agree that's more readable. I'll change that
in another revision.
Done. Please review the next revision, and check in if it's o.k.
2003-11-18 Guilhem Lavaux [EMAIL PROTECTED]
* java/text/FieldPosition.java (field_attribute): New field.
(FieldPosition (Format.Field), FieldPosition(Format.Field, int),
getFieldAttribute): New methods.
2003-11-18 Dalibor Topic [EMAIL PROTECTED]
* java/text/FieldPosition.java (equals): Adapted to handle
field_attribute. Added fast-circuit check for comparison to self.
Replaced use of instanceof by getClass to fix symmetry for derived
types.
(toString): Adapted to handle field_attribute. Improved readability.
(hashCode): New method.
Index: java/text/FieldPosition.java
===
RCS file: /cvsroot/classpath/classpath/java/text/FieldPosition.java,v
retrieving revision 1.5
diff -u -r1.5 FieldPosition.java
--- java/text/FieldPosition.java22 Jan 2002 22:27:01 - 1.5
+++ java/text/FieldPosition.java19 Nov 2003 11:04:54 -
@@ -65,6 +65,38 @@
private int end;
/**
+ * This is the field attribute value.
+ */
+ private Format.Field field_attribute;
+
+ /**
+ * This method initializes a new instance of codeFieldPosition/code
+ * to have the specified field attribute. The attribute will be used as
+ * an id.
+ *
+ * @param field The field format attribute.
+ */
+ public FieldPosition (Format.Field field)
+ {
+this.field_attribute = field;
+ }
+
+ /**
+ * This method initializes a new instance of codeFieldPosition/code
+ * to have the specified field attribute. The attribute will be used as
+ * an id is non null. The integer field id is only used if the Format.Field
+ * attribute is not used by the formatter.
+ *
+ * @param field The field format attribute.
+ * @param field_id The field identifier value.
+ */
+ public FieldPosition (Format.Field field, int field_id)
+ {
+this.field_attribute = field;
+this.field_id = field_id;
+ }
+
+ /**
* This method initializes a new instance of codeFieldPosition/code to
* have the specified field id.
*
@@ -85,6 +117,11 @@
return field_id;
}
+ public Format.Field getFieldAttribute ()
+ {
+return field_attribute;
+ }
+
/**
* This method returns the beginning index for this field.
*
@@ -132,8 +169,8 @@
* ul
* liThe specified object is not codenull/code.
* liThe specified object is an instance of codeFieldPosition/code.
- * liThe specified object has the same field identifier and beginning
- * and ending index as this object.
+ * liThe specified object has the same field identifier, field attribute
+ * and beginning and ending index as this object.
* /ul
*
* @param obj The object to test for equality to this object.
@@ -143,15 +180,40 @@
*/
public boolean equals (Object obj)
{
-if (! (obj instanceof FieldPosition))
+if (this == obj)
+ return true;
+
+if (obj == null || obj.getClass() != this.getClass())
return false;
FieldPosition fp = (FieldPosition) obj;
return (field_id == fp.field_id
+(field_attribute == fp.field_attribute
+ || (field_attribute != null
+field_attribute.equals(fp.field_attribute)))
begin == fp.begin
end == fp.end);
}
+
+ /**
+ * This method returns a hash value for this object
+ *
+ * @return A hash value for this object.
+ */
+ public int hashCode ()
+ {
+int hash = 5;
+
+hash = 31 * hash + field_id;
+hash = 31 * hash + begin;
+hash = 31 * hash + end;
+hash = 31 * hash +
+ (null == field_attribute ? 0 : field_attribute.hashCode());
+
+return hash;
+ }
+
/**
* This method returns a codeString/code representation of this
* object.
@@ -160,7 +222,11 @@
*/
public String toString ()
{
-return (getClass ().getName () + [field= + getField () + ,beginIndex=
- + getBeginIndex () + ,endIndex= + getEndIndex () + ]);
+return (getClass ().getName ()
+ + [field= + getField ()
+ + ,attribute= + getFieldAttribute ()
+ + ,beginIndex= + getBeginIndex ()
+ + ,endIndex= + getEndIndex ()
+ + ]);
}
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] small fix for ServerSocket close
On Thu, Nov 13, 2003 at 03:35:47PM +0100, Dalibor Topic wrote:
Hi all,
attached is a small fix for ServerSocket's close method. It fixes a
NullPointerException when attempting to close a ServerSocket twice.
2003-11-13 Guilhem Lavaux [EMAIL PROTECTED]
* java/net/ServerSocket.java:
(close) Check if server socket has already been released,
before attepting to close it.
--- /var/tmp/PROJECTS/classpath//./java/net/ServerSocket.java Fri Oct 17 19:05:29
2003
+++ java/net/ServerSocket.javaWed Oct 22 21:32:21 2003
@@ -339,7 +339,8 @@
*/
public void close () throws IOException
{
-impl.close ();
+if (impl != null)
+ impl.close ();
if (getChannel() != null)
getChannel().close ();
After thinking about this patch, its more and more bogus in my eyes as
impl never may be null. I provided a better fix to libgcj. When its
approved I will merge it into classpath too.
What would really interest me is the testcase from Guilhem that
triggered this.
Michael
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] small fix for ServerSocket close
Dalibor Topic wrote:
Hi Michael,
Michael Koch wrote:
--- /var/tmp/PROJECTS/classpath//./java/net/ServerSocket.javaFri
Oct 17 19:05:29 2003
+++ java/net/ServerSocket.javaWed Oct 22 21:32:21 2003
@@ -339,7 +339,8 @@
*/
public void close () throws IOException
{
-impl.close ();
+if (impl != null)
+ impl.close ();
if (getChannel() != null)
getChannel().close ();
After thinking about this patch, its more and more bogus in my eyes as
impl never may be null. I provided a better fix to libgcj. When its
approved I will merge it into classpath too.
Not yet, but soon it will.
ServerSocket is still broken with respect to how it behaves when it's
closed. When the socket is closed, access to methods like accept()
should throw an IOException that it's closed. Currently, no such checks
It should throw a SocketException, actually ;) I got carried away by my
implementation details from java.io. fixes to kaffe. But you get the idea.
cheers,
dalibor topic
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] attributed string fixes
graydon hoare wrote: hi, this fixes some arithmetic and semantic errors with attributed strings. -graydon 2003-11-18 Graydon Hoare [EMAIL PROTECTED] * java/text/AttributedString.java: Fix arithmetic. * java/text/AttributedStringIterator.java: Likewise. PLease take a look at Guilhem's patches to java.text first. Your patch fails with kaffe's version of the file for 3 hunks: patching file java/text/AttributedString.java Hunk #3 FAILED at 407. Hunk #4 FAILED at 217. Hunk #5 FAILED at 266. 3 out of 5 hunks FAILED -- saving rejects to file java/text/AttributedString.java.rej cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] swing frame fixes
Hi Graydon, this patch implements JLayeredPane and makes some minor adjustments to JFrame and JRootPane. Thanks for having written some documentation for the class! Just a suggestion: Please separate paragraphs by p tags. Also, it IMHO would be better to describe attributes like position with the respective methods (e.g., getPosition), but this may be a matter of personal taste. Do you have any Mauve test code for your class? This question may sound malicious, but I really think that we all should writing more test cases. (This includes myself, I finally should clean up my test suite for java.util.logging). Of course it is boring and takes a lot of time to write stupid test cases. But if anyone evaluated Classpath in its current state, they'd probably get quite suspicious about the lack of test cases. Personally, I wouldn't trust Classpath for anything critical -- not because it's incomplete, but because so little code is tested by Mauve. -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] swing frame fixes
On Wed, Nov 19, 2003 at 05:04:32PM +0100, Sascha Brawer wrote: Hi Graydon, this patch implements JLayeredPane and makes some minor adjustments to JFrame and JRootPane. Thanks for having written some documentation for the class! Just a suggestion: Please separate paragraphs by p tags. Also, it IMHO would be better to describe attributes like position with the respective methods (e.g., getPosition), but this may be a matter of personal taste. Why adding stupid p ? Doesnt javadoc/gcjdoc add them automatically ? If javadoc does and gcjdoc doesnt we should fix the bug in gcjdoc and not use workarounds. Michael ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Mauve tests [was: Re: [PATCH] swing frame fixes]
On Wed, 19 Nov 2003 17:04:32 +0100 Sascha Brawer [EMAIL PROTECTED] wrote: Do you have any Mauve test code for your class? This question may sound malicious, but I really think that we all should writing more test cases. (This includes myself, I finally should clean up my test suite for java.util.logging). I'd like to know where are the mauve tests? ./test? ./testsuite? And maybe how can I write a mauve test for a awt or swing class? Sorry if it's a dumb question ;) Cheers, -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation. pgp0.pgp Description: PGP signature ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] swing frame fixes
On Wed, 19 Nov 2003 17:16:40 +0100 Michael Koch [EMAIL PROTECTED] wrote: Why adding stupid p ? Doesnt javadoc/gcjdoc add them automatically ? If javadoc does and gcjdoc doesnt we should fix the bug in gcjdoc and not use workarounds. I don't remember javadoc does that. But as javadoc is in html, it's not really a workaround. Maybe we can write ptext/p. Cheers, -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation. pgp0.pgp Description: PGP signature ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Mauve tests [was: Re: [PATCH] swing frame fixes]
Arnaud == Arnaud Vandyck [EMAIL PROTECTED] writes: Arnaud I'd like to know where are the mauve tests? ./test? ./testsuite? http://sources.redhat.com/mauve/ Arnaud And maybe how can I write a mauve test for a awt or swing Arnaud class? For AWT, I know Tom Fitzsimmons put the Acunia visual tester into a mauve module. We could write something similar for the visual parts of Swing. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] Field position attribute handling
Dalibor == Dalibor Topic [EMAIL PROTECTED] writes: Dalibor Done. Please review the next revision, and check in if it's o.k. Looks ok to me, I checked it in. Do you not have classpath write access? Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: new jalopy available
Hi,
have we decided to have tabs in the source code ?
It seems that my tabs are olny half the size of the tabs that jalopy
assumes. In the snippet below I have replaced the the tabs with spaces
to resemble the look that I get. Could we stick to a space only setting?
switch (e.getID())
{
case PaintEvent.UPDATE:
case PaintEvent.PAINT:
Graphics g = getComponent().getGraphics();
paint(g);
g.dispose();
default: }
Also note the closing curly braces on the wrong line.
Thanks.
ingo
Tom Tromey wrote:
Raif Naffah sent me a couple nice jalopy patches to implement things
from my last wish-list. I wrote a new patch myself, to get jalopy to
use tabs for indentation in the way we expect.
I made a new release with these improvements. Once again, it is here:
ftp://sources.redhat.com/pub/java/jalopy-console-1.0.4.tar.gz
You'll also want this file, which is the GNU.xml style:
ftp://sources.redhat.com/pub/java/GNU.xml
This is somewhat different from the last one.
This version seems to be much better. The strange Point.java change
has disappeared (I didn't try to find out why).
At this point I think we are ready to try this version of jalopy for
real. I propose we pick a package to reformat and check in.
Preferably we'd pick something where active work is going on, so we
could more easily notice whatever jalopy doesn't handle well.
Long term, we need to find a cvs repository for this version. We
should also put GNU.xml into the classpath repository; I'll do this if
we're all on board for the test drive.
Tom
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] attributed string fixes
Hi, On Wed, 2003-11-19 at 16:03, Dalibor Topic wrote: graydon hoare wrote: 2003-11-18 Graydon Hoare [EMAIL PROTECTED] * java/text/AttributedString.java: Fix arithmetic. * java/text/AttributedStringIterator.java: Likewise. PLease take a look at Guilhem's patches to java.text first. Your patch fails with kaffe's version of the file for 3 hunks: patching file java/text/AttributedString.java Hunk #3 FAILED at 407. Hunk #4 FAILED at 217. Hunk #5 FAILED at 266. 3 out of 5 hunks FAILED -- saving rejects to file java/text/AttributedString.java.rej Dalibor is referring to following Classpath bugs: https://savannah.gnu.org/bugs/?func=detailbugbug_id=4968group_id=85 https://savannah.gnu.org/bugs/?func=detailbugbug_id=4118group_id=85 The first one has already been partly merged in and for the second bug Stephen Crawley already created some Mauve tests for the second case. I didn't have time to go through the complete patches yet and they don't apply cleanly anymore so updated patches are very welcome. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] small fix for ServerSocket close
Hi,
On Wed, 2003-11-19 at 14:13, Michael Koch wrote:
--- /var/tmp/PROJECTS/classpath//./java/net/ServerSocket.java Fri Oct 17
19:05:29 2003
+++ java/net/ServerSocket.java Wed Oct 22 21:32:21 2003
@@ -339,7 +339,8 @@
*/
public void close () throws IOException
{
-impl.close ();
+if (impl != null)
+ impl.close ();
if (getChannel() != null)
getChannel().close ();
After thinking about this patch, its more and more bogus in my eyes as
impl never may be null. I provided a better fix to libgcj. When its
approved I will merge it into classpath too.
You are right. I saw your patch on the java-patches mailinglist to make
sure impl will never be null. Sorry for not investigation the root cause
before committing it. But it looked like having an extra sanity check
here wouldn't hurt.
I hope to propose a bit more formal patch/commit strategy in the next
couple of weeks (like libgcj already has). Now that we are attracting
more and more developers with different background it would be nice to
have more formal procedure so that a) patches are not lost, b) all
patches are actually reviewed.
What would really interest me is the testcase from Guilhem that
triggered this.
Yes, that would be nice.
I did test it against Mauve with Kissme before checking in (please never
check something in if you cannot test it against Mauve and some VM). But
since there were multiple tests broken already
I hope that I can cleanup Mauve enough before next week (when we will
create the 0.07 snapshot release) to activate a autobuilder which we can
use to track failures. But Currently Mauve is still to fragile for this.
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] Field position attribute handling
Dalibor == Dalibor Topic [EMAIL PROTECTED] writes: Dalibor So if you want to offer me write access again, I'd take it ;) I think it would be a good idea. You can make a savannah account yourself, if you don't already have one. Then Mark has to do some admin thing to give you access. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] Field position attribute handling
Tom Tromey wrote: Dalibor == Dalibor Topic [EMAIL PROTECTED] writes: Dalibor Done. Please review the next revision, and check in if it's o.k. Looks ok to me, I checked it in. Do you not have classpath write access? Nope, not yet ;) Bryce asked back when I sent in my paperwork if I wanted it, and I didn't, as I had no use for it back then. It wasn't clear whether kaffe would switch to GNU Classpath completely, so I didn't want to risk potentially polluting Classpath with GPLd code from kaffe as I wasn't sure how to do the merge properly. Now that I know how to merge stuff properly (drop kaffe's implementation for a class, chuck in Classpath's, review, fix, submit a patch to Classpath) I have no such fear anymore, so that's changed a bit. So if you want to offer me write access again, I'd take it ;) cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] Field position attribute handling
Tom Tromey wrote: Dalibor == Dalibor Topic [EMAIL PROTECTED] writes: Dalibor So if you want to offer me write access again, I'd take it ;) I think it would be a good idea. You can make a savannah account yourself, if you don't already have one. Then Mark has to do some admin thing to give you access. I've got a savannah account already[1], mostly for filing bugs patches on Classpath ;) cheers, dalibor topic [1] under the unobvious name of robilad. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] small fix for ServerSocket close
Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark I hope that I can cleanup Mauve enough before next week (when we Mark will create the 0.07 snapshot release) to activate a autobuilder Mark which we can use to track failures. But Currently Mauve is still Mark to fragile for this. FWIW, I run Mauve as part of my nightly builds. I don't think Mauve is all that fragile, it hardly ever seems to be the part of the process that has trouble. These days the nightly tester is doing quite a bit: * Build gcc from scratch. Run the test suite including Mauve and Jacks * Build classpath from scratch with new gcj and jikes * Build rhug with new gcj * Build GNU Crypto and Kawa with gcj * Run Classpath/libgcj comparison and JAPI comparison Also I run the test suites for all of these things. Some of it doesn't work that reliably... rhug hasn't built completely in months, classpath fails with gcj. Of course, I wouldn't know that without the nightly tester :-) I'm not publishing the info anywhere, I just have it send me email. And the scripts to do all this are a little ugly. Still, as long as the builds are done when I start work in the morning, I'm happy to add stuff... ideally I'd have a recipe (so I don't have to think :-). I'd be happy to send the reports somewhere, too, if there were agreement on where. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] attributed string fixes
Mark Wielaard wrote:
Hi,
On Wed, 2003-11-19 at 16:03, Dalibor Topic wrote:
graydon hoare wrote:
2003-11-18 Graydon Hoare [EMAIL PROTECTED]
* java/text/AttributedString.java: Fix arithmetic.
* java/text/AttributedStringIterator.java: Likewise.
PLease take a look at Guilhem's patches to java.text first. Your patch
fails with kaffe's version of the file for 3 hunks:
patching file java/text/AttributedString.java
Hunk #3 FAILED at 407.
Hunk #4 FAILED at 217.
Hunk #5 FAILED at 266.
3 out of 5 hunks FAILED -- saving rejects to file
java/text/AttributedString.java.rej
Dalibor is referring to following Classpath bugs:
https://savannah.gnu.org/bugs/?func=detailbugbug_id=4968group_id=85
https://savannah.gnu.org/bugs/?func=detailbugbug_id=4118group_id=85
The first one has already been partly merged in and for the second bug
Stephen Crawley already created some Mauve tests for the second case.
I didn't have time to go through the complete patches yet and they don't
apply cleanly anymore so updated patches are very welcome.
I have quickly hacked a merge between current implementation and mine.
The patch has been built using today's classpath CVS. If anybody can review it...
;-) I remind that this collator implements everything but one feature of Java's API
('!' and some puzzling behaviour highlighted by 2 Mauve tests).
The new patch is available at:
https://savannah.gnu.org/bugs/?func=detailbugbug_id=4118group_id=85
The other one is following tomorrow or on friday...
Regards,
Guilhem.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] text layout implementation
Sascha Brawer [EMAIL PROTECTED] writes:
But why do you need to create the string at all? Could't you set up a
CharacterIterator so it points to a single font run, and use the method
java.awt.Font.createGlyphVector(FontRenderContext, CharacterIterator)?
This should be much more efficient, because you'd save all those object
allocations. A local class could implement CharacterIterator, but also
have setter methods (or accessible fields), so only a single instance
needs to be allocated.
ok, changed to do this.
Also, does the proposed implementation work if there are changes in any
attributes other than font, such as TextAttribute.UNDERLINE? It seems
that all these attributes are lost by passing Strings.
well, the CharacterIteratorProxy I've implemented (modified patch
below) doesn't do the whole AttributedCharacterIterator interface, but
there's no method on Font to create a glyph vector with an
AttributedCharacterIterator anyways. I think we'd have to interpret
extra attributes as calls to deriveFont or something, no?
Please don't feel offended if I'm a bit picky here; I'm just trying to
ensure that we have efficient and good code.
not at all, this is precisely the sort of polishing that code review
fosters, I'm glad to get the suggestions (as I was, belatedly, with
the graphics2d suggestions).
-graydon
--- java/awt/font/TextLayout.java 17 Feb 2003 08:05:50 - 1.1
+++ java/awt/font/TextLayout.java 19 Nov 2003 20:34:57 -
@@ -43,8 +43,12 @@
import java.awt.Shape;
import java.awt.geom.AffineTransform;
import java.awt.geom.Rectangle2D;
+import java.text.CharacterIterator;
import java.text.AttributedCharacterIterator;
+import java.text.AttributedString;
import java.util.Map;
+import java.awt.font.TextAttribute;
+
/**
* @author Michael Koch
@@ -67,24 +71,26 @@
}
}
+ private AttributedString attributedString;
private FontRenderContext fontRenderContext;
public TextLayout (AttributedCharacterIterator text, FontRenderContext frc)
{
-// FIXME
-this.fontRenderContext = frc;
+attributedString = new AttributedString (text);
+fontRenderContext = frc;
}
public TextLayout (String string, Font font, FontRenderContext frc)
{
-// FIXME
-this.fontRenderContext = frc;
+attributedString = new AttributedString (string);
+attributedString.addAttribute (TextAttribute.FONT, font);
+fontRenderContext = frc;
}
public TextLayout (String string, Map attributes, FontRenderContext frc)
{
-// FIXME
-this.fontRenderContext = frc;
+attributedString = new AttributedString (string, attributes);
+fontRenderContext = frc;
}
protected Object clone ()
@@ -100,9 +106,139 @@
}
}
+
+ protected class CharacterIteratorProxy
+implements CharacterIterator
+ {
+public CharacterIterator target;
+public int begin;
+public int limit;
+public int index;
+
+public CharacterIteratorProxy (CharacterIterator ci)
+{
+ target = ci;
+}
+
+public int getBeginIndex ()
+{
+ return begin;
+}
+
+public int getEndIndex ()
+{
+ return limit;
+}
+
+public int getIndex ()
+{
+ return index;
+}
+
+public char setIndex (int idx)
+ throws IllegalArgumentException
+{
+ if (idx begin || idx = limit)
+throw new IllegalArgumentException ();
+ char ch = target.setIndex (idx);
+ index = idx;
+ return ch;
+}
+
+public char first ()
+{
+ int save = target.getIndex ();
+ char ch = target.setIndex (begin);
+ target.setIndex (save);
+ return ch;
+}
+
+public char last ()
+{
+ if (begin == limit)
+return this.first ();
+
+ int save = target.getIndex ();
+ char ch = target.setIndex (limit - 1);
+ target.setIndex (save);
+ return ch;
+}
+
+public char current ()
+{
+ return target.current();
+}
+
+public char next ()
+{
+ if (index = limit - 1)
+return CharacterIterator.DONE;
+ else
+{
+ index++;
+ return target.next();
+}
+}
+
+public char previous ()
+{
+ if (index = begin)
+return CharacterIterator.DONE;
+ else
+{
+ index--;
+ return target.previous ();
+}
+}
+
+public Object clone ()
+{
+ CharacterIteratorProxy cip = new CharacterIteratorProxy (this.target);
+ cip.begin = this.begin;
+ cip.limit = this.limit;
+ cip.index = this.index;
+ return cip;
+}
+
+ }
+
+
public void draw (Graphics2D g2, float x, float y)
{
-throw new Error (not implemented);
+AttributedCharacterIterator ci = attributedString.getIterator ();
+CharacterIteratorProxy proxy = new CharacterIteratorProxy (ci);
+Font defFont = g2.getFont ();
+
+for (char c = ci.first ();
+ c != CharacterIterator.DONE;
+ c = ci.next ())
+ {
Re: [PATCH] Field position attribute handling
On Wednesday 19 November 2003 11:38, Dalibor Topic wrote: Jeroen Frijters wrote: Dalibor Topic wrote: [...] If two objects are not equal, they should have different hashCodes. No this isn't true, however, if two objects are equal, they must have identical hashCodes. It would be nice if unequal objects had different hashCodes, but this is not a requirement. Note that I used *should* in my sentence instead of *must*, and reparse what I said ;) In general it's impossible to ensure that non-equal objects have different hashcodes - just think for a moment about java.lang.Long. So IMHO even should is going too far ... -- Chris Gray/k/ Embedded Java Solutions Embedded Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Graphical Algorithm documents
Hi, On Mon, 2003-11-17 at 20:16, S. Meslin-Weber wrote: I stumbled on some interesting algorithm documents today and thought others implementing low-level primitives in Java (Graphics and/or Java2D) might find them useful. I emailed the author and we are welcome to use the documents at: http://www.magic-software.com/Documentation/ Hope some other than I will find this useful! Thanks for that info. It looks very useful. It is of course OK to read about those algorithms and create an implementation of them for inclusion in GNU Classpath. But please contact me before you use/copy any code snippets. The commercial-use restrictions in their license look confusing to me and when we want to use it in GNU Classpath (which may be used commercially) we certainly have to contact the author about it (and check with fsf-licensing). Thanks, Mark paranoia maintainer Wielaard signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
