StringBuffer.substring sharing
After I checked in Ralph Loader's fix for StringBuffer.substring the
other day, Ralph pointed out that my modification had changed the
meaning of the patch slightly:
On Monday, Sep 22, 2003, at 20:45 Pacific/Auckland, Ralph Loader wrote:
My interpretation of the original code was that it was meant to prevent
the possibility that a small substring of a large StringBuffer would
prevent the large array being gc'd.
The patch you checked in breaks this. Consider:
String Foo()
{
StringBuffer b = new StringBuffer();
... put a megabyte of stuff into b ...
String ignored = b.toString(); // sets b.shared
return b.substring (0, 1);
}
The 1 character String returned from Foo now has it's contents stored
in
a megabyte char[], and that array has no other references.
Passing ((len << 2) >= value.length) rather than StringBuffer.shared to
the String constructor prevented this.
Its hard to say what is optimal here, as you can also argue that if the
string is already shared then its reasonable to share even if the
substring is small. However, having to copy a small string
unnecessarily doesn't seem as bad as potentially wasting a lot of
memory in the scenario above. So, I'm checking in the following patch,
which reverts to the behaviour of Ralph's original patch.
2003-09-24 Bryce McKinlay <[EMAIL PROTECTED]>
* java/lang/StringBuffer.java (substring): Don't set `shared' on
small Strings, even if buffer is already shared.
Index: StringBuffer.java
===
RCS file: /cvs/gcc/gcc/libjava/java/lang/StringBuffer.java,v
retrieving revision 1.16
diff -u -r1.16 StringBuffer.java
--- StringBuffer.java 22 Sep 2003 08:17:48 - 1.16
+++ StringBuffer.java 24 Sep 2003 06:02:00 -
@@ -564,11 +564,12 @@
throw new StringIndexOutOfBoundsException();
if (len == 0)
return "";
-// Share unless substring is smaller than 1/4 of the buffer.
-if ((len << 2) >= value.length)
- shared = true;
+// Don't copy unless substring is smaller than 1/4 of the buffer.
+boolean share_buffer = ((len << 2) >= value.length);
+if (share_buffer)
+ this.shared = true;
// Package constructor avoids an array copy.
-return new String(value, beginIndex, len, shared);
+return new String(value, beginIndex, len, share_buffer);
}
/**
Regards
Bryce.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: auto-formatting: no more jalopy
> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes: Brian> Bug: Printer Java: GNU brace style does not indent beyond braces Brian> http://sourceforge.net/tracker/index.php?func=detail&aid=716393&group_id=45216&atid=442212 I tried adding gnu-style indent to jalopy today. Unfortunately the result dies while trying to parse our javadoc. So, I'm giving up. I can send my hack if somebody wants it. The real "GNU.xml" style file is attached to the above PR. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
I think this makes sense (as long a java implementation is available).
I can see only one limitation at the moment: if someone wants to construct a
free J2ME (CLDC) API from Classpath.
The CLDC API contains only java.io; there, PrintStream writes to the
underlying stream according to the locale and VM configuration. There is no
explicit encoder (as far as I can see), but I guess it would rely on
something like the current encoders (maybe just hardcoded, because a generic
implementation it just too expensive on a small device).
-Patrik
Patrik Reali
http://www.oberon.ethz.ch/jaos
> Brian Jones <[EMAIL PROTECTED]> wrote on Tue, 23 Sep 2003 07:17:07 -0400:
>
> >Is there a reason to keep gnu.java.io.{encode,decode}.* around when it
> >looks like the nio versions could be used?
>
> It probably would make sense to switch to java.nio.charset.
>
> Some of us (Dalibor Topic; Mark Wielaard; Andy Walter; James Hunt; Ingo
> Proetel; Sascha Brawer) had discussed this during our meeting at LinuxTag
> in Germany.
>
> Quoting from Mark's meeting minutes (http://mail.gnu.org/archive/html/
> classpath/2003-07/msg00040.html):
>
> > The plan for character encodings is to move to the java.nio.charset
> > interface. We already have required encodings for this. But GNU
> > Classpath and gcj both still also have their old implementations
> > (which are actually used in most places). gcj also has a libiconv
> > provider (but not as java.nio.charset provider). A java.nio.charset
> > libiconv provider would be nice to have for those systems that
> > have that library.
>
> -- Sascha
>
> Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/
>
>
>
>
> ___
> Classpath mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/classpath
>
>
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Kaffe and gjdoc
Hi everybody, [I do Cc: classpath because I'm not on cp-tools but someone can maybe forward] The good news: -- kaffe can run ant and build something (but maybe everyone already know! ;)) The bad news: - gjdoc from cvs is broken because of java.util.jar.JarFile.OPEN_READ. Here is the log: [EMAIL PROTECTED]:~/debian/gnu/gjdoc/src$ kaffe -classpath $CLASSPATH -Dant.home=/usr/share/ant -Dbuild.compiler=kjc org.apache.tools.ant.Main Buildfile: build.xml init: [mkdir] Created dir: /home/arnaud/debian/gnu/gjdoc/tmp/build [mkdir] Created dir: /home/arnaud/debian/gnu/gjdoc/dist compile: [javac] Compiling 64 source files to /home/arnaud/debian/gnu/gjdoc/tmp/build [javac] /home/arnaud/debian/gnu/gjdoc/src/gnu/classpath/tools/gjdoc/ClassDocProxy.java:37: caution:Assignment of an expression to itself [KOPI] [javac] /home/arnaud/debian/gnu/gjdoc/src/gnu/classpath/tools/doclets/xmldoclet/FileSystemClassLoader.java:103: error:Cannot find type "java/util/jar/JarFile/OPEN_READ" [javac] /home/arnaud/debian/gnu/gjdoc/src/gnu/classpath/tools/doclets/xmldoclet/doctranslet/DocTranslet.java:294: error:Cannot find type "java/util/jar/JarFile/OPEN_READ" BUILD FAILED file:/home/arnaud/debian/gnu/gjdoc/src/build.xml:73: Compile failed; see the compiler error output for details. Total time: 34 seconds [EMAIL PROTECTED]:~/debian/gnu/gjdoc/src$ -- I'll re-try in some days... I think integrating gjdoc in kaffe may be a target for 1.1.2... if it can be built! ;) sorry but I do not have so much time this month and the next one... Cheers, -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
David> The EncodingManager expects the system property file.encoding
David> to be set but I couldn't find any indication of who was
David> responsible for setting this property, when and where.
I think the VM must set it during startup. That's what libgcj does.
Brian> gnu/java/io/EncodingManager uses System.getProperty("file.encoding",
Brian> "8859_1");
Brian> java/net/URLEncoder.java uses System.getProperty("file.encoding",
Brian> "8859_1");
Brian> java/util/logging/XMLFormatter.java uses
Brian> System.getProperty("file.encoding") and later defaults to "UTF-8" if
Brian> null
I wonder if the default setting should be in gnu.classpath.Configuration.
Tom
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
NYIException
Hi,
I would like to again propose a standard NYIException to be used in
Classpath.
I have taken earlier postings this list and copied them into a
java-file. I have attached the result.
I would like your comments. If nobody complains I will put it in.
One open issue with this approach is that we are not able to
differentiate between features of different Java releases.
To solve this we could have subclasses of this exception:
NYI14Exception -- new feature in release 1.4
NYI13Exception -- new feature in release 1.3
...
This would make a grep really easy.
--ingo
/* NYIException.java -- Exception signaling not yet implemented methods
Copyright (C) 2003 Free Software Foundation
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. */
package gnu.org.classpath;
/**
* This Exception is used to signal that a particular method has not
* been implemented yet. The use of a specific exception throught the
* complete source code will help to localize and implement missing
* functionality.
* Usage:
*
* public notYetImplementeMethod()
*{
*throw new gnu.classpath.NYIException();
*}
*
*
*/
public class NYIException extends UnsupportedOperationException
{
private static final String NYI =
"This method has not yet been implemented in GNU Classpath.\n\n"
+ " The GNU Classpath project would appreciate receiving"
+ " an implementation for it.\n"
+ " If you intend to contribute, please take a look at"
+ " http://www.gnu.org/software/classpath/docs/hacking.html and"
+ " get in touch with other developers on [EMAIL PROTECTED]";
/**
* Create new NYIException.
*/
public NYIException()
{
super(NYI);
}
/**
* Create new NYIException with detailed message.
* @param message more detailed description.
*/
public NYIException(String message)
{
super(message + "\n" + NYI);
}
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
Sascha Brawer wrote:
Brian Jones <[EMAIL PROTECTED]> wrote on Tue, 23 Sep 2003 07:17:07 -0400:
Is there a reason to keep gnu.java.io.{encode,decode}.* around when it
looks like the nio versions could be used?
It probably would make sense to switch to java.nio.charset.
Some of us (Dalibor Topic; Mark Wielaard; Andy Walter; James Hunt; Ingo
Proetel; Sascha Brawer) had discussed this during our meeting at LinuxTag
in Germany.
Quoting from Mark's meeting minutes (http://mail.gnu.org/archive/html/
classpath/2003-07/msg00040.html):
The plan for character encodings is to move to the java.nio.charset
interface. We already have required encodings for this. But GNU
Classpath and gcj both still also have their old implementations
(which are actually used in most places). gcj also has a libiconv
provider (but not as java.nio.charset provider). A java.nio.charset
libiconv provider would be nice to have for those systems that
have that library.
So I guess the first step would be to take the libiconv provider and
make it work in the nio framework, and then to convert the rest to it as
well, before switching, as it would make the switch most painless for
the libgcj guys, I guess. For kaffe, switching to Classpath's style
charsets also depends on the availability of libiconv based conververters.
cheers,
dalibor topic
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: request for comment on java2d stuff
Hi Graydon,
graydon hoare <[EMAIL PROTECTED]> wrote on Tue, 2 Sep 2003 20:25:19 -0400:
>http://gcc.gnu.org/ml/java-patches/2003-q3/msg00493.html
Some more observations...
(1) Shouldn't rotate, scale & friends install new AffineTransforms if
transform == null? Otherwise, getTransform() will return wrong values.
Why don't you simply create an identity transform in the constructor? The
code would become cleaner (no checks for null transforms), and
constructing an AffineTransform should be a rather inexpensive operation.
(2) getTransform() should return a clone.
(3) setClip(Shape) should replace the current clip, while clip(Shape)
should set the new clip to the intersection of the current clip with the
specified shape. The current assignment 'clip = s' in clip(Shape) is not
correct.
public void clip(Shape s)
{
Area area;
area = new Area(s);
if (clip != null)
area.intersect(new Area(clip));
setClip(area);
}
However, there is the unfortunate problem that Classpath does not yet
provide java.awt.geom.Area.
(4) clipRect can be implemented by passing a java.awt.Rectangle to
clip(Shape). The current implementation seems incorrect if the current
clip is not rectangular.
Best regards,
-- Sascha
Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
Brian Jones <[EMAIL PROTECTED]> wrote on Tue, 23 Sep 2003 07:17:07 -0400:
>Is there a reason to keep gnu.java.io.{encode,decode}.* around when it
>looks like the nio versions could be used?
It probably would make sense to switch to java.nio.charset.
Some of us (Dalibor Topic; Mark Wielaard; Andy Walter; James Hunt; Ingo
Proetel; Sascha Brawer) had discussed this during our meeting at LinuxTag
in Germany.
Quoting from Mark's meeting minutes (http://mail.gnu.org/archive/html/
classpath/2003-07/msg00040.html):
> The plan for character encodings is to move to the java.nio.charset
> interface. We already have required encodings for this. But GNU
> Classpath and gcj both still also have their old implementations
> (which are actually used in most places). gcj also has a libiconv
> provider (but not as java.nio.charset provider). A java.nio.charset
> libiconv provider would be nice to have for those systems that
> have that library.
-- Sascha
Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
Sascha Brawer <[EMAIL PROTECTED]> writes:
> Brian Jones <[EMAIL PROTECTED]> wrote on Tue, 23 Sep 2003 00:28:16 -0400:
>
> >A grep through the source confirms many complaints about Sun not
> >[...] providing a standard means of getting at the
> >available encodings.
>
> They have added this with 1.4. See
>
> http://java.sun.com/j2se/1.4.2/docs/api/java/nio/charset/Charset.html
Is there a reason to keep gnu.java.io.{encode,decode}.* around when it
looks like the nio versions could be used?
Brian
--
Brian Jones <[EMAIL PROTECTED]>
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath java/awt/AWTEvent.java minor documentation patch.
Hi, On Tue, 2003-09-23 at 06:30, Brian Jones wrote: > Do we need paperwork to commit all of Ricky's documentation patches? Yes, for all non-trivial contributions we require that. I have already contacted Ricky about it. Sorry for the bureaucracy, but we really want to prevent anyone ever claiming that any part of GNU Classpath is not free software (not that you can ever really protect yourself from dubious legal claims, see the recent dubious claims of SCO, but we try to minimize the chance people even try). People should feel that they will always be free to use FSF distributed software. And having the FSF as main copyright holder also makes it easier for the FSF to protect the copyleft parts of the Classpath license terms. For people interested into contributing to GNU Classpath, please see http://www.gnu.org/software/classpath/docs/hacking.html#SEC2 If there are any questions about these requirements please feel free to contact me about it. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
Brian Jones <[EMAIL PROTECTED]> wrote on Tue, 23 Sep 2003 00:28:16 -0400: >A grep through the source confirms many complaints about Sun not >[...] providing a standard means of getting at the >available encodings. They have added this with 1.4. See http://java.sun.com/j2se/1.4.2/docs/api/java/nio/charset/Charset.html -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath java.nio.charset.CharsetDecoder documentation.
Ricky Clarkson <[EMAIL PROTECTED]> wrote on Sun, 21 Sep 2003 23:42:45 +0100: >Please find attached a patch which is the result of diff -u CharsetDecoder.java> . > >Also please find attached a similar patch for Changelog. > >Feedback on this would be welcome, and would mean less time would be >wasted when I get around to CharsetEncoder and others. I find your documentation very legible. If someone wanted to contribute a charset decoder to Classpath, they now should be able to do this just from your docs. Very many thanks for your hard work! Just a few minor remarks: The default implementation of CharsetDecoder.isAutoDetecting() returns false, not true (line 683). The 'Copyright (C) 2002' should be changed to 'Copyright (C) 2002, 2003' (line 2), and you'd want to include a before "Instances of this class..." (line 124). Best regards, and thanks again, -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
