Re: [cp-patches] Patch: Add security check to Class.getClasses()
Tom Tromey wrote: Gary == Gary Benson [EMAIL PROTECTED] writes: Gary Class.getClasses() was not performing the member access checks Gary like it ought. The attached patch fixes. I'm working on Gary mauve tests for all of Class's security calls so there will be Gary a check for this issue soonish. Class.getClasses is directly calling memberAccessCheck before it calls internalGetClasses. Also supposedly getClasses should call with Member.PUBLIC, not Member.DECLARED. So it seems to me that this patch is not needed. Ok, so I guess the documentation is inconsistent: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Class.html#getClasses() For this class _and_each_of_its_superclasses_, the following security checks are performed: If there is a security manager, the security manager's checkMemberAccess method is called with this and Member.PUBLIC http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html#PermsAndMethods For this class and each of its superclasses, checkMemberAccess(this, Member.DECLARED) is called... Presently Classpath checks Member.PUBLIC for this class but not for its superclasses. (Member.DECLARED is higher than Member.PUBLIC). FWIW Member.PUBLIC is consistent with getFields(), getMethods(), etc. Hmmm... Cheers, Gary ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
Tom Tromey wrote: Twisti == Christian Thalinger [EMAIL PROTECTED] writes: Twisti Yeah, i didn't take it personally :-) Of course i see your Twisti point, but what i'm trying to say is, if we ever want to Twisti catch up (or even be better) than sun or other proprietary Twisti JVMs, we should think about optimizing some core functions Twisti in classpath... Yeah. This is tricky for us since the various VMs differ. That said, I think we've seen a number of performance fixes go in during the last year, and for the most part these haven't been micro-optimizations. In this particular case, I think RandomAccessFile is not used very much. I would only bother looking at optimizations in this code if it showed up in a profile of some application. Ok, so I'll commit my original patch for now. Cheers, Gary ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] FYI: Opening RandomAccessFiles requires excessive permission
Hi all,
As promised, I committed my fix that means you don't need permission
to write file descriptors to open a java.io.RandomAccessFile in read-
only mode under a security manager.
Cheers,
Gary
Index: ChangeLog
===
RCS file: /cvsroot/classpath/classpath/ChangeLog,v
retrieving revision 1.5775
diff -u -r1.5775 ChangeLog
--- ChangeLog 7 Dec 2005 15:12:19 - 1.5775
+++ ChangeLog 7 Dec 2005 15:24:26 -
@@ -1,3 +1,9 @@
+2005-12-07 Gary Benson [EMAIL PROTECTED]
+
+ * java/io/RandomAccessFile.java (RandomAccessFile): Don't create
+ DataOutputStream for read-only files to avoid unnecessary security
+ manager check.
+
2005-12-07 Ito Kazumitsu [EMAIL PROTECTED]
Fixes bug #25273
Index: java/io/RandomAccessFile.java
===
RCS file: /cvsroot/classpath/classpath/java/io/RandomAccessFile.java,v
retrieving revision 1.47
diff -u -r1.47 RandomAccessFile.java
--- java/io/RandomAccessFile.java 2 Jul 2005 20:32:38 - 1.47
+++ java/io/RandomAccessFile.java 7 Dec 2005 15:24:26 -
@@ -124,7 +124,10 @@
ch = FileChannelImpl.create(file, fdmode);
fd = new FileDescriptor(ch);
-out = new DataOutputStream (new FileOutputStream (fd));
+if ((fdmode FileChannelImpl.WRITE) != 0)
+ out = new DataOutputStream (new FileOutputStream (fd));
+else
+ out = null;
in = new DataInputStream (new FileInputStream (fd));
}
@@ -766,6 +769,9 @@
*/
public void write (int oneByte) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.write(oneByte);
}
@@ -777,6 +783,9 @@
*/
public void write (byte[] buffer) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.write(buffer);
}
@@ -792,6 +801,9 @@
*/
public void write (byte[] buffer, int offset, int len) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.write (buffer, offset, len);
}
@@ -806,6 +818,9 @@
*/
public final void writeBoolean (boolean val) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.writeBoolean(val);
}
@@ -820,6 +835,9 @@
*/
public final void writeByte (int val) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.writeByte(val);
}
@@ -834,6 +852,9 @@
*/
public final void writeShort (int val) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.writeShort(val);
}
@@ -848,6 +869,9 @@
*/
public final void writeChar (int val) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.writeChar(val);
}
@@ -861,6 +885,9 @@
*/
public final void writeInt (int val) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.writeInt(val);
}
@@ -874,6 +901,9 @@
*/
public final void writeLong (long val) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.writeLong(val);
}
@@ -893,6 +923,9 @@
*/
public final void writeFloat (float val) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.writeFloat(val);
}
@@ -913,6 +946,9 @@
*/
public final void writeDouble (double val) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.writeDouble(val);
}
@@ -927,6 +963,9 @@
*/
public final void writeBytes (String val) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.writeBytes(val);
}
@@ -941,6 +980,9 @@
*/
public final void writeChars (String val) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.writeChars(val);
}
@@ -975,6 +1017,9 @@
*/
public final void writeUTF (String val) throws IOException
{
+if (out == null)
+ throw new IOException(Bad file descriptor);
+
out.writeUTF(val);
}
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Add security check to Class.getClasses()
Gary == Gary Benson [EMAIL PROTECTED] writes: Gary http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Class.html#getClasses() Gary For this class _and_each_of_its_superclasses_, the following Gary security checks are performed: If there is a security manager, the Gary security manager's checkMemberAccess method is called with this Gary and Member.PUBLIC Interesting. The 1.5 text is different. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Patch: Allow Security.setProperty(foo, null)
Hi,
At the moment Security.setProperty() will not allow the setting of
null property values. Since Security.getProperty() returns null for
unset properties this means that the following will fail:
String key = some.old.property;
Security.setProperty(key, Security.getProperty(key));
The javadoc is unclear: it says nothing about null values, but it
doesn't say anything about throwing NullPointerExceptions (which we
currently do). I tried it on a proprietary JVM and it accepted the
null pointer. On the principle of accepting what you emit I think we
should do the same.
Also included in this patch is the spelling correction
s/datnum/datum/.
Cheers,
Gary
Index: ChangeLog
===
RCS file: /cvsroot/classpath/classpath/ChangeLog,v
retrieving revision 1.5776
diff -u -r1.5776 ChangeLog
--- ChangeLog 7 Dec 2005 15:27:04 - 1.5776
+++ ChangeLog 7 Dec 2005 15:44:29 -
@@ -1,5 +1,10 @@
2005-12-07 Gary Benson [EMAIL PROTECTED]
+ * java/security/Security.java (setProperty): Spelling correction.
+ * java/security/Security.java (setProperty): Allow null values.
+
+2005-12-07 Gary Benson [EMAIL PROTECTED]
+
* java/io/RandomAccessFile.java (RandomAccessFile): Don't create
DataOutputStream for read-only files to avoid unnecessary security
manager check.
Index: java/security/Security.java
===
RCS file: /cvsroot/classpath/classpath/java/security/Security.java,v
retrieving revision 1.37
diff -u -r1.37 Security.java
--- java/security/Security.java 18 Sep 2005 03:06:39 - 1.37
+++ java/security/Security.java 7 Dec 2005 15:44:29 -
@@ -399,20 +399,23 @@
* /p
*
* @param key the name of the property to be set.
- * @param datnum the value of the property to be set.
+ * @param datum the value of the property to be set.
* @throws SecurityException if a security manager exists and its
* [EMAIL PROTECTED] SecurityManager#checkPermission(Permission)} method
denies access
* to set the specified security property value.
* @see #getProperty(String)
* @see SecurityPermission
*/
- public static void setProperty(String key, String datnum)
+ public static void setProperty(String key, String datum)
{
SecurityManager sm = System.getSecurityManager();
if (sm != null)
sm.checkSecurityAccess(setProperty. + key);
-secprops.put(key, datnum);
+if (datum == null)
+ secprops.remove(key);
+else
+ secprops.put(key, datum);
}
/**
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
David Daney wrote: Gary Benson wrote: ...I'll commit my original patch for now. I hate to sound like I have a burr under the saddle, but does anybody see any merit whatsoever in changing the exception text as I suggested in my previous response to the patch? What did you suggest? I saw your mail about exception handling, but that's all... Cheers, Gary ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] FYI: Opening RandomAccessFiles requires excessive permission
Gary == Gary Benson [EMAIL PROTECTED] writes: Gary +if (out == null) Gary + throw new IOException(Bad file descriptor); FWIW I also would have preferred a different message in these exceptions, like 'file not opened for writing' or similar. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Allow Security.setProperty(foo, null)
Gary == Gary Benson [EMAIL PROTECTED] writes: Gary The javadoc is unclear: it says nothing about null values, but it Gary doesn't say anything about throwing NullPointerExceptions (which we Gary currently do). I tried it on a proprietary JVM and it accepted the Gary null pointer. On the principle of accepting what you emit I think we Gary should do the same. If you do a further getProperty() does it return null? If so then this is fine. Adding the test to mauve would be good. Gary + * java/security/Security.java (setProperty): Spelling correction. Gary + * java/security/Security.java (setProperty): Allow null values. I would write just one entry like: * java/security/Security.java (setProperty): Allow null values. Spelling correction. How about adding a note to the javadoc about the handling of null values? Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
Gary Benson wrote: David Daney wrote: Gary Benson wrote: ...I'll commit my original patch for now. I hate to sound like I have a burr under the saddle, but does anybody see any merit whatsoever in changing the exception text as I suggested in my previous response to the patch? What did you suggest? I saw your mail about exception handling, but that's all... http://lists.gnu.org/archive/html/classpath-patches/2005-12/msg00042.html David Daney ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Patch: FYI: Double.toHexString and Float.toHexString
I'm checking this in on the trunk.
This adds the new 1.5 methods Double.toHexString and
Float.toHexString. I wrote Mauve tests for both of these. (BTW,
adding a new Mauve test file from Eclipse is super easy... I forgot
how easy it is when all the boilerplate is written for you, even
though I added the templates :-)
The code in both classes is pretty much identical, aside from a few
constants.
Tom
2005-12-07 Tom Tromey [EMAIL PROTECTED]
* java/lang/Float.java (toHexString): New method.
* java/lang/Double.java (toHexString): New method.
Index: java/lang/Double.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/Double.java,v
retrieving revision 1.40
diff -u -r1.40 Double.java
--- java/lang/Double.java 18 Sep 2005 23:00:24 - 1.40
+++ java/lang/Double.java 7 Dec 2005 20:08:13 -
@@ -173,6 +173,81 @@
}
/**
+ * Convert a double value to a hexadecimal string. This converts as
+ * follows:
+ * ul
+ * li A NaN value is converted to the string NaN.
+ * li Positive infinity is converted to the string Infinity.
+ * li Negative infinity is converted to the string -Infinity.
+ * li For all other values, the first character of the result is '-'
+ * if the value is negative. This is followed by '0x1.' if the
+ * value is normal, and '0x0.' if the value is denormal. This is
+ * then followed by a (lower-case) hexadecimal representation of the
+ * mantissa, with leading zeros as required for denormal values.
+ * The next character is a 'p', and this is followed by a decimal
+ * representation of the unbiased exponent.
+ * /ul
+ * @param d the double value
+ * @return the hexadecimal string representation
+ * @since 1.5
+ */
+ public static String toHexString(double d)
+ {
+if (isNaN(d))
+ return NaN;
+if (isInfinite(d))
+ return d 0 ? -Infinity : Infinity;
+
+long bits = doubleToLongBits(d);
+StringBuilder result = new StringBuilder();
+
+if (bits 0)
+ result.append('-');
+result.append(0x);
+
+final int mantissaBits = 52;
+final int exponentBits = 11;
+long mantMask = (1L mantissaBits) - 1;
+long mantissa = bits mantMask;
+long expMask = (1L exponentBits) - 1;
+long exponent = (bits mantissaBits) expMask;
+
+result.append(exponent == 0 ? '0' : '1');
+result.append('.');
+result.append(Long.toHexString(mantissa));
+if (exponent == 0 mantissa != 0)
+ {
+// Treat denormal specially by inserting '0's to make
+// the length come out right. The constants here are
+// to account for things like the '0x'.
+int offset = 4 + ((bits 0) ? 1 : 0);
+// The silly +3 is here to keep the code the same between
+// the Float and Double cases. In Float the value is
+// not a multiple of 4.
+int desiredLength = offset + (mantissaBits + 3) / 4;
+while (result.length() desiredLength)
+ result.insert(offset, '0');
+ }
+result.append('p');
+if (exponent == 0 mantissa == 0)
+ {
+// Zero, so do nothing special.
+ }
+else
+ {
+// Apply bias.
+boolean denormal = exponent == 0;
+exponent -= (1 (exponentBits - 1)) - 1;
+// Handle denormal.
+if (denormal)
+ ++exponent;
+ }
+
+result.append(Long.toString(exponent));
+return result.toString();
+ }
+
+ /**
* Returns a codeDouble/code object wrapping the value.
* In contrast to the codeDouble/code constructor, this method
* may cache some values. It is used by boxing conversion.
Index: java/lang/Float.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/Float.java,v
retrieving revision 1.33
diff -u -r1.33 Float.java
--- java/lang/Float.java18 Sep 2005 23:00:24 - 1.33
+++ java/lang/Float.java7 Dec 2005 20:08:13 -
@@ -183,6 +183,83 @@
}
/**
+ * Convert a float value to a hexadecimal string. This converts as
+ * follows:
+ * ul
+ * li A NaN value is converted to the string NaN.
+ * li Positive infinity is converted to the string Infinity.
+ * li Negative infinity is converted to the string -Infinity.
+ * li For all other values, the first character of the result is '-'
+ * if the value is negative. This is followed by '0x1.' if the
+ * value is normal, and '0x0.' if the value is denormal. This is
+ * then followed by a (lower-case) hexadecimal representation of the
+ * mantissa, with leading zeros as required for denormal values.
+ * The next character is a 'p', and this is followed by a decimal
+ * representation of the unbiased exponent.
+ * /ul
+ * @param f the float value
+ * @return the hexadecimal string representation
+ * @since 1.5
+ */
+ public static String toHexString(float f)
+ {
+if
Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
David == David Daney [EMAIL PROTECTED] writes: David I hate to sound like I have a burr under the saddle, but does anybody David see any merit whatsoever in changing the exception text as I suggested David in my previous response to the patch? Yes, I was in favor of this as well. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [GNU Crypto] RFC: merging GNU Crypto and Jessie
On Wednesday 07 December 2005 04:49, Casey Marshall wrote: On Dec 6, 2005, at 1:14 AM, Raif S. Naffah wrote: On Tuesday 06 December 2005 18:42, Casey Marshall wrote: A few of us have been throwing around the idea of merging GNU Crypto and Jessie into GNU Classpath, so Classpath will have full support for crypto and SSL out of the box. We've proposed this before, and I think this idea was mostly approved by the group, but no-one ever got around to doing it. I'd like to propose again that we do this. I'll try to get to this myself, but if I can't get this done, we'll at least have a plan of action. I propose that we - Rename the root package 'gnu.crypto' to 'gnu.javax.crypto' in GNU Crypto, and merge the current CVS sources into Classpath (not under external/). We then put GNU Crypto into a kind of stasis mode, and continue to develop these sources in Classpath. - Rename the root package 'org.metastatic.jessie' to 'gnu.javax.net.ssl' in Jessie, and merge the current sources. Then, I'll stop developing that branch on its own. does this mean that Classpath's crypto classes will be using the GNU Crypto assembly, cipher, hash, key, mac, mode, pad, prng and sig sub-packages with the jce wrappers? Basically yes. The goal is to merge everything with a JCE wrapper, because that will fill in many algorithms present in proprietary VMs, but currently missing in Classpath. cool. i can help with this task --can spend ~2hrs/day on this until it's done. Things without JCE wrappers don't really make sense for Classpath, because they aren't portably accessible. dont know exactly what you mean by this but i'll have a closer look at the Classpath classes; it may become evident then. Thanks. cheers; rsn pgpUyEMU00Zgc.pgp Description: PGP signature ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Security manager problem
Robert Lougher wrote:
On 12/6/05, Gary Benson [EMAIL PROTECTED] wrote:
...I was just looking at an some code in an
AccessController.doPrivileged() that was doing security checks.
Perhaps JamVM's AccessController.doPrivileged() is not in fact
doing anything.
What version of JamVM are you using?
I'm using cvs HEAD, with Classpath HEAD.
As far as I'm aware, JamVMs implementation of VMAccessController is
complete (it was provided by Casey Marshall, if I remember
correctly). I've made some recent changes to the native method that
obtains the stack, so it _could_ have broken in 1.4.1.
Do you have a testcase?
If you build and run the attached testcase you ought to see only one
checkPermission() between Calling checkRead() and Done. GCJ (for
example) makes this of it:
$ gij Test
Calling checkRead()
checkPermission((java.io.FilePermission / read))
Done
checkPermission((java.lang.RuntimePermission exitVM ))
checkPermission((java.lang.RuntimePermission exitVM ))
Based on what I'm seeing in Mauve you _should_ see a load of extra
stuff before the actual checkPermission you're interested in if you
run the testcase with JamVM:
$ jamvm Test
Calling checkRead()
checkPermission((java.io.FilePermission /path/to/JamVM.security read))
checkPermission((java.io.FilePermission /path/to/JamVM.security read))
checkPermission((java.io.FilePermission /path/to/classpath.security read))
checkPermission((java.io.FilePermission /path/to/classpath.security read))
checkPermission((java.io.FilePermission /path/to/classpath.security read))
checkPermission((java.util.PropertyPermission java.util.logging.manager
read))
checkPermission(null)
checkPermission(null)
checkPermission(null)
checkPermission(null)
checkPermission((java.util.PropertyPermission
java.util.logging.config.class read))
checkPermission((java.util.PropertyPermission java.util.logging.config.file
read))
checkPermission((java.util.PropertyPermission gnu.classpath.home.url read))
checkPermission((java.io.FilePermission /path/to/logging.properties read))
checkPermission((java.io.FilePermission /path/to/logging.properties read))
checkPermission((java.util.logging.LoggingPermission control ))
checkPermission((java.util.logging.LoggingPermission control ))
checkPermission((java.security.SecurityPermission
getProperty.package.access ))
checkPermission((java.io.FilePermission / read))
Done
...
In reality, JamVM chokes on it pretty hard. I _think_ what is
happening is that the System.out.println in checkPermission() is
itself doing some initialisation which causes security checks,
causing an infinite loop. It's hard to say, though, not knowing
JamVM or Classpath particularly well.
Cheers,
Gary
import java.security.Permission;
class Test
{
static class TestSecurityManager extends SecurityManager
{
public void checkPermission(Permission perm) {
System.out.println( checkPermission( + perm + ));
}
}
public static void main(String[] args) {
try {
SecurityManager sm = new TestSecurityManager();
System.setSecurityManager(sm);
System.out.println(Calling checkRead());
sm.checkRead(/);
System.out.println(Done);
}
catch (Throwable t) {
t.printStackTrace();
}
}
}
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: Free Swing runs with JGoodies Forms
On Tue, 2005-12-06 at 02:26 +0100, Robert Schuster wrote: Thanks to all Swing hackers!!! Hey! I'm a Swing Hacker! You're welcome! Took a look at the screenshots, that's awesome! --Tony ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
StatCVS runs free!
Hi all, Following my success getting JFreeChart to run against GNU Classpath and Cairo yesterday: http://www.object-refinery.com/jfreechart/free.html ...I decided it couldn't be too hard to get StatCVS[1] working the same way (StatCVS uses JFreeChart for the charts it generates). Here's the latest run for Mauve CVS generated, for the first time, with JamVM, GNU Classpath and cairo-java: http://www.object-refinery.com/classpath/mauve/statcvs/ Alas, the process is too memory hungry to process (on my machine) the 226MB log file generated for Classpath CVS. The changes to StatCVS were minimal, I'll write up the details shortly so that others can reproduce this. Regards, Dave [1] http://statcvs.sourceforge.net/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Proposal: Graphics2D rewrite branch
Hi, I'd like to propose a new branch in the GNU Classpath CVS repository: graphics2d-rewrite. Patches to this branch should be sent to classpath-patches@gnu.org with a subject line prefix of [g2d rewrite]. Commit policy is the same as GNU Classpath trunk. On this branch I'd like to do several things: 1) Make Graphics2D the default 2) Remove Graphics 3) Split Graphics2D according to http://developer.classpath.org/mediation/ClasspathGraphicsImagesText Once these items are done and tested to work as well or better than the current Graphics/Graphics2D implementations, I'll merge the branch into trunk and continue development there. Any objections? Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: Graphics2D rewrite branch
Tom == Thomas Fitzsimmons [EMAIL PROTECTED] writes: Tom I'd like to propose a new branch in the GNU Classpath CVS repository: Tom graphics2d-rewrite. Patches to this branch should be sent to Tom classpath-patches@gnu.org with a subject line prefix of [g2d rewrite]. Tom Commit policy is the same as GNU Classpath trunk. I say go for it. Furthermore I think we should adopt gcc-ish branch rules. These are pretty reasonable and have proven to work well in practice. Namely: * Any Classpath developer can make a branch for any purpose. All branches ought to be documented somewhere, so we can know which are live, who owns them, and when they die. I don't know where we would put this though (suggestions?) * Some rules can be changed on a branch. In particular the branch maintainer can change the review requirements, and the requirement of keeping things building, testing, etc, can also be lifted. (These should be documented along with the branch name and owner if they differ from the trunk.) Requirements for patch email to classpath-patches and for paperwork *cannot* be lifted. * Merges from the trunk to a branch are at the discretion of the branch maintainer. * A merge from a branch to the trunk is treated like any other patch. In particular, it has to go through review, it must satisfy all the trunk requirements (build, regression test, documentation). This rule prevents folks from working around trunk rules by making a branch :-) There may be additional timing requirements on merging a branch to the trunk depending on the release schedule, etc. For instance we may not want to do a branch merge just before a release. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: Graphics2D rewrite branch
Thomas Fitzsimmons wrote: Hi, I'd like to propose a new branch in the GNU Classpath CVS repository: graphics2d-rewrite. Patches to this branch should be sent to classpath-patches@gnu.org with a subject line prefix of [g2d rewrite]. Commit policy is the same as GNU Classpath trunk. On this branch I'd like to do several things: 1) Make Graphics2D the default 2) Remove Graphics 3) Split Graphics2D according to http://developer.classpath.org/mediation/ClasspathGraphicsImagesText Once these items are done and tested to work as well or better than the current Graphics/Graphics2D implementations, I'll merge the branch into trunk and continue development there. Any objections? Tom I'm looking forward to seeing this work proceed. I can certainly help with testing, but I'm not likely to be much help with the actual implementation (I know so little about the non-Java bits of GNU Classpath). Regarding 3) and BufferedImages, I think I recall Sven saying he was mistaken about the DataBuffer classes. As far as I could tell (from writing some Mauve tests for them) they use real Java arrays. And that makes using Cairo for BufferedImages more difficult, doesn't it? Regards, Dave ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Building classpath-0.19-generics
Hi! How would I go about building classpath-0.19-generics? I tried gcjx and ecj with various ./configure options, with no avail. Can somebody give me a working, minimal ./configure line (without native stuff), along with a compiler recommendation? Thanks! Regards, Andreas Eckstein ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: Graphics2D rewrite branch
David Gilbert wrote:
Regarding 3) and BufferedImages, I think I recall Sven saying he was
mistaken about the DataBuffer classes. As far as I could tell (from
writing some Mauve tests for them) they use real Java arrays.
It should be possible to have a hybrid implementation that can use
native buffers or Java arrays. If constructed using (say)
DataBufferInt(int size, int numBanks)
then it can allocated a native buffer.
The complicatation is getData and getBankData. If using native buffers,
these would have to allocate new buffers, copy the data of of the
native buffers, release the native buffers, and switch to using the
Java arrays for future references.
This isn't too bad if you're using CNI and a non-copying gc, since
you can use a native pointer in all cases, and just have the
natve pointer point into the Java arrray in the Java case.
If using a copying GC, you can use a delta. For simplicity, I
assume a single bank:
DataBufferInt {
int[] array;
native size_t offset;
int getElem(int i) { return *(int*)((char*) array + offset + 4 * i); }
DataBufferInt(int size) {
void* buf = allocate_native_buffer(size);
array = null;
offset = buf;
}
DataBufferInt(int[] arr) {
array = arr;
offset = SIZE_OF_ARRAY_HEADER;
}
int[] getData () {
int[] ar = new int[size];
copy_form_native_buffer_into(ar);
array = ar;
offset = SIZE_OF_ARRAY_HEADER;
}
}
This works even if the array is moved by the gc.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: [GNU Crypto] RFC: merging GNU Crypto and Jessie
On Dec 6, 2005, at 11:57 PM, Raif S. Naffah wrote: On Wednesday 07 December 2005 04:49, Casey Marshall wrote: On Dec 6, 2005, at 1:14 AM, Raif S. Naffah wrote: On Tuesday 06 December 2005 18:42, Casey Marshall wrote: A few of us have been throwing around the idea of merging GNU Crypto and Jessie into GNU Classpath, so Classpath will have full support for crypto and SSL out of the box. We've proposed this before, and I think this idea was mostly approved by the group, but no-one ever got around to doing it. I'd like to propose again that we do this. I'll try to get to this myself, but if I can't get this done, we'll at least have a plan of action. I propose that we - Rename the root package 'gnu.crypto' to 'gnu.javax.crypto' in GNU Crypto, and merge the current CVS sources into Classpath (not under external/). We then put GNU Crypto into a kind of stasis mode, and continue to develop these sources in Classpath. - Rename the root package 'org.metastatic.jessie' to 'gnu.javax.net.ssl' in Jessie, and merge the current sources. Then, I'll stop developing that branch on its own. does this mean that Classpath's crypto classes will be using the GNU Crypto assembly, cipher, hash, key, mac, mode, pad, prng and sig sub-packages with the jce wrappers? Basically yes. The goal is to merge everything with a JCE wrapper, because that will fill in many algorithms present in proprietary VMs, but currently missing in Classpath. cool. i can help with this task --can spend ~2hrs/day on this until it's done. Great! School's out for me right now, so I have my weekends back :-) Things without JCE wrappers don't really make sense for Classpath, because they aren't portably accessible. dont know exactly what you mean by this but i'll have a closer look at the Classpath classes; it may become evident then. By this I mean that if something can't be used through J2SE classes, then it probably shouldn't be merged, because otherwise we'd be introducing private, non-portable APIs into Classpath. Exceptions are things we know we'll need to use privately (e.g., if Jessie needs it). The assembly package is a good example: it's a neat, advanced API, but doesn't have any analogue in the J2SE spec. Thanks. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Building classpath-0.19-generics
Andreas == Andreas Eckstein [EMAIL PROTECTED] writes: Andreas Hi! How would I go about building classpath-0.19-generics? I tried Andreas gcjx and ecj with various ./configure options, with no avail. Can Andreas somebody give me a working, minimal ./configure line (without native Andreas stuff), along with a compiler recommendation? Thanks! Personally I just check it out in Eclipse, and that works fine. For the command line ... it looks like lib/Makefile.am needs to pass '-source 1.5 -target 1.5' to ecj. Could you try making that change? If it works for you I will check it in. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: StatCVS runs free!
David Gilbert wrote: Hi all, Following my success getting JFreeChart to run against GNU Classpath and Cairo yesterday: http://www.object-refinery.com/jfreechart/free.html ...I decided it couldn't be too hard to get StatCVS[1] working the same way (StatCVS uses JFreeChart for the charts it generates). Here's the latest run for Mauve CVS generated, for the first time, with JamVM, GNU Classpath and cairo-java: http://www.object-refinery.com/classpath/mauve/statcvs/ Alas, the process is too memory hungry to process (on my machine) the 226MB log file generated for Classpath CVS. The changes to StatCVS were minimal, I'll write up the details shortly so that others can reproduce this. Regards, Dave [1] http://statcvs.sourceforge.net/ As promised, here is the write-up of the setup I needed to make this work: http://www.object-refinery.com/classpath/statcvs.html If anything is unclear or incorrect, please let me know so I can fix it. Regards, Dave ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Building classpath-0.19-generics
On Wed, 2005-12-07 at 21:22 +, Andreas Eckstein wrote: Hi! How would I go about building classpath-0.19-generics? I tried gcjx and ecj with various ./configure options, with no avail. Can somebody give me a working, minimal ./configure line (without native stuff), along with a compiler recommendation? Thanks! Hmm, i just compile it with ecj shipped in debian. No problems with that... TWISTI ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[commit-cp] classpath ./ChangeLog java/text/DecimalFormat.java
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Ito Kazumitsu [EMAIL PROTECTED] 05/12/07 15:12:21 Modified files: . : ChangeLog java/text : DecimalFormat.java Log message: 2005-12-07 Ito Kazumitsu [EMAIL PROTECTED] Fixes bug #25273 * java/text/DecimalFormat.java(scanFormat): Don't set minimumIntegerDigits to 0. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5774tr2=1.5775r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/text/DecimalFormat.java.diff?tr1=1.24tr2=1.25r1=textr2=text
[commit-cp] classpath ./ChangeLog java/io/RandomAccessFile....
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Gary Benson [EMAIL PROTECTED] 05/12/07 15:27:05 Modified files: . : ChangeLog java/io: RandomAccessFile.java Log message: 2005-12-07 Gary Benson [EMAIL PROTECTED] * java/io/RandomAccessFile.java (RandomAccessFile): Don't create DataOutputStream for read-only files to avoid unnecessary security manager check. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5775tr2=1.5776r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/io/RandomAccessFile.java.diff?tr1=1.47tr2=1.48r1=textr2=text
[commit-cp] classpath java/lang/Double.java java/lang/Float...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Tom Tromey [EMAIL PROTECTED] 05/12/07 20:16:33 Modified files: java/lang : Double.java Float.java . : ChangeLog Log message: * java/lang/Float.java (toHexString): New method. * java/lang/Double.java (toHexString): New method. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/lang/Double.java.diff?tr1=1.40tr2=1.41r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/lang/Float.java.diff?tr1=1.33tr2=1.34r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5776tr2=1.5777r1=textr2=text
