Re: Java tools
Alexandre Petit-Bianco <[EMAIL PROTECTED]> writes: > Per Bothner writes: > > > If someone wants a javap replacement in Java, you can use > > gnu.bytecode.dump > > OT: Is the libjava tree the primary tree? I've been looking for an > implementation of gnu.tools.gcj (something equivalent to sun.tools.javac.) Are you referring to gnu.bytecode? If so, the answer is no - that package is in the Kawa cvs tree, and not in libjava. If someone wants to import classes from gnu.bytecode into libgcj, I'd be happy to donate it. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Java tools
Per Bothner writes: > If someone wants a javap replacement in Java, you can use > gnu.bytecode.dump OT: Is the libjava tree the primary tree? I've been looking for an implementation of gnu.tools.gcj (something equivalent to sun.tools.javac.) ./A ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Java tools
Tom Tromey <[EMAIL PROTECTED]> writes: > javap: look at jcf-dump in gcj. > ... > I don't know if Sun's java[hp] are extensible from Java. If they are > then you'll be disappointed by jcf-dump and gcjh; they are written in > (sometimes poor) C. The goal of jcf-dump is write out all the information in a .class file, in a way useful for implementors. So it has more detail and a different format that the output freom javap. There is a --javap flag whose goal is to produce the same output as javap - but we haven't put much effort into that. I think it is mainly that someone has to care enough and have the time to sit down and do it. It should be an easy beginner project, and shouldn't take more than a couple of days. Another problem with jcf-dump is that the disassembler part of it uses macros in a way that may be hard to understand. A simple switch statement might in retrospect have been better. The disassembler in gnu.bytecode.CodeAttr (see http://www.gnu.org/software/kawa/api/gnu/bytecode/CodeAttr.html) does a rough but simple binary search of the opcodes, plus various tricks for a compact and fast disassembler. If someone wants a javap replacement in Java, you can use gnu.bytecode.dump -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Java tools
> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes: Brian> Copyright assignment is useful for making the core libraries Brian> legally defensible in whole from a single party, the FSF. I do Brian> think that it has slowed the progress of the project, but I do Brian> not know why this is so. I think one reason is because it is a huge pain. Sometimes if you work at a company, getting them to let you sign is a major obstacle. Also the process itself needs streamlining. It regularly takes a month for the paperwork to happen. People often lose interest when nothing happens for a month. (And a month is pretty good -- sometimes it takes much longer.) Brian> To date I don't think we've refused to accept code under a Brian> different license for tools. Certainly a simple javap, javah, Brian> and javadoc would be nice to have. javap: look at jcf-dump in gcj. javah: look at gcjh in gcj. Installing gcj just for these tools is a bit heavy. But hopefully these things will start showing up in Linux distributions as standard tools very soon. I don't know if Sun's java[hp] are extensible from Java. If they are then you'll be disappointed by jcf-dump and gcjh; they are written in (sometimes poor) C. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Java tools
> "Nic" == Nic Ferrier <[EMAIL PROTECTED]> writes: Tom Tromey <[EMAIL PROTECTED]> 10-Jul-01 4:29:31 PM >>> Tom>I don't have a real objection. But I think that adding Tom>a new project every time does make things more difficult. Nic> In what way? A new project means new mailing lists to track, a new cvs repository to remember, etc. It also means that if I want to build everything the build is more complex. Keeping it all in sync is harder -- a unified tree is easier to keep working, as every developer can build it frequently. Nic> The only trouble with Classpath is that it requires (c) Nic> assignment and the 'exception' licence. Actually only the core parts of Classpath require the odd license. For host tools like javadoc, I'm sure any license is acceptable. The goal for libgcj is that it be usable on embedded systems (which is actually a pretty big range; don't necessarily think "small"). This means that we would like the libraries and such to have the special GPL+exception license. This ensures that embedded developers can continue to use gcj and libgcj. For a host-side tool like javadoc, something like the GPL is great. For instance, gcj is GPL. Now, should javax.* be GPL+exception? Or new libraries? Well, obviously we would prefer that. The possibility exists that, if we need one of these libraries, then we would have to rewrite it if the license is different. And we've decided in the past to exclude other libraries (AWT) from libgcj on this basis. Obviously the licensing and potential for duplication of effort is our problem. If we have to do it, then we have to do it. It would be less efficient, and of course we'd rather share efforts, but whether we can also depends on your goals and requirements. Classpath already has two licenses in it, and I personally don't want to be in the position of saying "let's reject java.foo from Classpath because it is LGPL and not GPL+exception". For one thing RMS would reject this. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Patch: SHA1PRNG fix
I believe that these two array copies have source and destination
operands mixed up. This random number generator produces a never
ending streamn of zeros otherwise.
Ok to commit?
AG
2001-07-09 Anthony Green <[EMAIL PROTECTED]>
* gnu/java/security/provider/SHA1PRNG.java (engineNextBytes): Fix
order of memory copies.
Index: gnu/java/security/provider/SHA1PRNG.java
===
RCS file: /cvs/gcc/gcc/libjava/gnu/java/security/provider/SHA1PRNG.java,v
retrieving revision 1.1
diff -u -p -r1.1 SHA1PRNG.java
--- SHA1PRNG.java 2000/06/28 11:24:05 1.1
+++ SHA1PRNG.java 2001/07/11 02:58:22
@@ -76,7 +76,7 @@ public class SHA1PRNG implements Seriali
{
if( bytes.length < (20 - datapos) ) {
- System.arraycopy( bytes, 0, data, datapos, bytes.length);
+ System.arraycopy( data, datapos, bytes, 0, bytes.length);
datapos += bytes.length;
return;
}
@@ -85,7 +85,7 @@ public class SHA1PRNG implements Seriali
byte digestdata[];
while( bpos < blen ) {
i = 20 - datapos;
- System.arraycopy( bytes, bpos, data, datapos, i);
+ System.arraycopy( data, datapos, bytes, bpos, i);
bpos += i;
datapos += i;
if( datapos >= 20) {
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
BreakIterator.getSentenceInstance() deviations
The javadoc drop-in I am working on relies on
BreakIterator.getSentenceInstance() for detecting the end of the first
sentence of a javadoc comment, as suggested by
http://java.sun.com/j2se/1.3/docs/tooldocs/javadoc/doclet/com/sun/javadoc/Ta
g.html#firstSentenceTags()
In this context I encountered some inconsistencies in various free core
libs (Classpath, libgcj.zip and Klasses.jar) with regard to JRE
behaviour.
A program demonstrating the problem is attached. Here are the results
when run in different environments (true linefeeds replaced by \n's for
clarity):
JRE 1.3.1:
1 first sentence of 'Foo.\nBar.' is 'Foo.\n'
2 first sentence of 'Foo. bar.' is 'Foo. bar.'
3 first sentence of 'Foo. 123 Bar.' is 'Foo. 123 Bar.'
ORP 1.0.3, Kissme 0.13, Kaffe 1.0.6:
1 first sentence of 'Foo.\nBar.' is 'Foo.\nBar.' (inconsistent)
2 first sentence of 'Foo. bar.' is 'Foo. ' (inconsistent)
3 first sentence of 'Foo. 123 Bar.' is 'Foo. ' (inconsistent)
GIJ 0.0.7:
1 first sentence of 'Foo.\nBar.' is 'Foo.\nBar.' (inconsistent)
2 first sentence of 'Foo. bar.' is 'Foo. bar.' (ok)
3 first sentence of 'Foo. 123 Bar.' is 'Foo. ' (inconsistent)
Line #2 reveals that both JRE and libgcj.zip ignore "period followed by
whitespace followed by lowercase letter" when looking for the end of a
sentence, but Classpath and Klasses.jar don't.
As demonstrated by line #3, JRE also ignores "period followed by
whitespace followed by digit", but all free implementations don't.
Finally, line #1 shows that JRE correctly identifies ".\n" as
end-of-sentence token, while other implementations ignore it. I assume
this is due to an incomplete definition of
LocaleInformation.sentence_breaks
private static final String[] sentence_breaks = { ". " };
... which should be
private static final String[] sentence_breaks
= { ". ", ".\t", ".\r\n", ".\r", ".\n" };
(I'm not sure about element [3], please check this.)
With regard to Classpath, both gnu/java/locale/LocaleInformation_en.java
and .../LocaleInformation_nl.java need be touched for this.
Julian
SentenceTest.java
Patch: EncodedKeySpec implements KeySpec
EncodedKeySpec is supposed to impement KeySpec.
Ok to commit?
AG
2001-07-09 Anthony Green <[EMAIL PROTECTED]>
* java/security/spec/EncodedKeySpec.java: This interface
implements KeySpec.
Index: java/security/spec/EncodedKeySpec.java
===
RCS file: /cvs/gcc/gcc/libjava/java/security/spec/EncodedKeySpec.java,v
retrieving revision 1.1
diff -u -p -r1.1 EncodedKeySpec.java
--- EncodedKeySpec.java 2001/04/25 15:45:13 1.1
+++ EncodedKeySpec.java 2001/07/11 02:47:33
@@ -1,5 +1,5 @@
/* EncodedKeySpec.java --- Encoded Key Specificaton class
- Copyright (C) 1999 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -35,7 +35,7 @@ package java.security.spec;
@author Mark Benvenuto
*/
-public abstract class EncodedKeySpec
+public abstract class EncodedKeySpec implements KeySpec
{
private byte[] encodedKey;
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Patch: SecureRandom
The Random constructor calls setSeed() at a time when SecureRandom has
not yet initilialized secureRandomSpi, resulting in a
NullPointerException. This tweak fixes..
Ok to commit?
2001-07-09 Anthony Green <[EMAIL PROTECTED]>
* java/security/SecureRandom.java: Store the seed array until
we're ready to use it.
Index: java/security/SecureRandom.java
===
RCS file: /cvs/gcc/gcc/libjava/java/security/SecureRandom.java,v
retrieving revision 1.2
diff -u -p -r1.2 SecureRandom.java
--- SecureRandom.java 2001/04/25 15:45:12 1.2
+++ SecureRandom.java 2001/07/11 02:32:56
@@ -1,5 +1,5 @@
/* SecureRandom.java --- Secure Random class implmentation
- Copyright (C) 1999 Free Software Foundation, Inc.
+ Copyright (C) 1999, 2001 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -36,7 +36,8 @@ import java.util.Enumeration;
@author Mark Benvenuto <[EMAIL PROTECTED]>
*/
-public class SecureRandom extends Random
+public class SecureRandom
+ extends Random
{
//Serialized Field
long counter = 0;//Serialized
@@ -87,6 +88,10 @@ public class SecureRandom extends Random
try
{
+ Class c = Class.forName (classname);
+
+ SecureRandomSpi srspi = (SecureRandomSpi) c.newInstance ();
+
this.secureRandomSpi =
(SecureRandomSpi) Class.forName(classname).newInstance();
@@ -105,6 +110,12 @@ public class SecureRandom extends Random
{
//throw new NoSuchAlgorithmException("Illegal Access");
}
+
+if (state != null)
+ {
+ setSeed (state);
+ state = null;
+ }
}
/**
@@ -172,6 +183,10 @@ public class SecureRandom extends Random
try
{
+ Class c = Class.forName (classname);
+
+ SecureRandomSpi srspi = (SecureRandomSpi) c.newInstance ();
+
return new SecureRandom((SecureRandomSpi) Class.forName(classname).
newInstance(), p[i]);
}
@@ -187,7 +202,6 @@ public class SecureRandom extends Random
{
throw new NoSuchAlgorithmException("Illegal Access");
}
-
}
/**
@@ -267,12 +281,18 @@ public class SecureRandom extends Random
*/
public void setSeed(long seed)
{
-byte tmp[] = { (byte) (0xff & (seed >> 56)), (byte) (0xff & (seed >> 48)),
- (byte) (0xff & (seed >> 40)), (byte) (0xff & (seed >> 32)),
- (byte) (0xff & (seed >> 24)), (byte) (0xff & (seed >> 16)),
- (byte) (0xff & (seed >> 8)), (byte) (0xff & seed)
-};
-secureRandomSpi.engineSetSeed(tmp);
+state = new byte[8];
+state[0] = (byte) (0xff & (seed >> 56));
+state[1] = (byte) (0xff & (seed >> 48));
+state[2] = (byte) (0xff & (seed >> 40));
+state[3] = (byte) (0xff & (seed >> 32));
+state[4] = (byte) (0xff & (seed >> 24));
+state[5] = (byte) (0xff & (seed >> 16));
+state[6] = (byte) (0xff & (seed >> 8));
+state[7] = (byte) (0xff & seed);
+
+if (secureRandomSpi != null)
+ secureRandomSpi.engineSetSeed(state);
}
/**
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [Classpathx-discuss] Re: Java tools
>>> David Brownell <[EMAIL PROTECTED]> 10-Jul-01 9:29:37 PM >>> And perhaps creating desires to move subprojects around. Like the ClasspathX "jaxp" support, as JDK 1.4 incorporates such facilities directly into the standard libraries... A short note on this... The GNU project's internal organization should not be a victim of Sun Marketing. Even though it is included in 1.4, the jaxp stuff is still a java extension, a javax package and should remain within Classpathx. All GNU projects can then use the code equally. For example, GCJ and Kaffe may choose to distribute the jaxp stuff to make something that looks like 1.4. In some areas Sun's decisions do affect us, for example the inclusion of regexps in core 1.4 call into question the utility of having a seperate regexp project. But we should not be pushed into duplicating effort or diluting the clarity of our structure (which is actually quite sensible) because Sun choose to do some bundling. Nic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Classpathx-discuss] Re: Java tools
> >I don't have a real objection. But I think that adding > >a new project every time does make things more difficult. > > > > In what way? > > It is convenient if related/dependent projects can share a > cvs repository. They could still be separate "projects", > but each project does add its own overhead. Like multiplication of mailing lists ... :) And perhaps creating desires to move subprojects around. Like the ClasspathX "jaxp" support, as JDK 1.4 incorporates such facilities directly into the standard libraries... - Dave ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
the pic of today.. :)
the finest girls and models over the net http://www.Layed.NET/ FOR FREE!!! give them a look.. what can lose? i dont have much to say.. its not needed.. you will like them, beliveme att. Eleanor http://www.layed.net/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Java tools
>>> Brian Jones <[EMAIL PROTECTED]> 10-Jul-01 7:24:44 PM >>> Copyright assignment is useful for making the core libraries legally defensible in whole from a single party, the FSF. I don't think that there's a particular problem with (c) assignment. The reasons for requiring it can be easily explained (protection for developers more than anything). On the other hand, the onus is then on us to ensure that the programmers we're accepting from have done everything right (ie: not copied Sun (or any non-free) code). To date I don't think we've refused to accept code under a different license for tools. Certainly a simple javap, javah, and javadoc would be nice to have. Well then. It seems the best thing to do would be to create a module for javadoc and ask Julian to join you. Let me know privately if you want me to do it (in which case you'll have to set me up on Classpath's savannah) or if you'll talk to him yourself. His mail address is: [EMAIL PROTECTED] There is at least one other person who hacks on the texidoclet. Nic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Java tools
"Nic Ferrier" <[EMAIL PROTECTED]> writes: Tom Tromey <[EMAIL PROTECTED]> 10-Jul-01 4:29:31 PM >>> > >I'd prefer to see us simply expand the mandate of, say, >Classpath and then just put more things in it. > > I'd be happy with that too, perhaps Classpath would need a seperate > CVS module for each tool but I don't see a major organizational > problem either way. > > The only trouble with Classpath is that it requires (c) assignment > and the 'exception' licence. Classpath uses the exception license on the core libraries (except for AWT). Tools can certainly exist under a different license. Copyright assignment is useful for making the core libraries legally defensible in whole from a single party, the FSF. I do think that it has slowed the progress of the project, but I do not know why this is so. Perhaps the assignment process or its effects are misunderstood. I decided long ago that assigning copyright to the FSF for my contributions to this project was in my best interests and theirs. What is appropriate for the core libraries may not be necessary for these tools. > A large part of this problem could be obviated if the Classpath > administrators choose to accept tools under non-exception licences, > eg: plain GPL or LGPL. To date I don't think we've refused to accept code under a different license for tools. Certainly a simple javap, javah, and javadoc would be nice to have. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Java tools
"Nic Ferrier" <[EMAIL PROTECTED]> writes: > >>> Tom Tromey <[EMAIL PROTECTED]> 10-Jul-01 4:29:31 PM >>> > >I don't have a real objection. But I think that adding >a new project every time does make things more difficult. > > In what way? It is convenient if related/dependent projects can share a cvs repository. They could still be separate "projects", but each project does add its own overhead. >I'd prefer to see us simply expand the mandate of, say, >Classpath and then just put more things in it. > > I'd be happy with that too, perhaps Classpath would need a seperate > CVS module for each tool but I don't see a major organizational > problem either way. > > The only trouble with Classpath is that it requires (c) assignment > and the 'exception' licence. > > A large part of this problem could be obviated if the Classpath > administrators choose to accept tools under non-exception licences, > eg: plain GPL or LGPL. GCC and related projects has traditionally distinguished "host tools" vs "target libraries". The latter may run on embedded systems, and may be linked in with user (customer) applications, and so need the exception. The host tools are not linked with application code, and they don't run on embedded systems, so traditionally have been GPL. Sometimes code falls into both categories. The libiberty library is an example. A regex library or getopt are other possible examples. The GCC project emcompasses both kinds of code; classpath focuses on "target libraries". -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Java tools
>>> Tom Tromey <[EMAIL PROTECTED]> 10-Jul-01 4:29:31 PM >>> I don't have a real objection. But I think that adding a new project every time does make things more difficult. In what way? I'd prefer to see us simply expand the mandate of, say, Classpath and then just put more things in it. I'd be happy with that too, perhaps Classpath would need a seperate CVS module for each tool but I don't see a major organizational problem either way. The only trouble with Classpath is that it requires (c) assignment and the 'exception' licence. A large part of this problem could be obviated if the Classpath administrators choose to accept tools under non-exception licences, eg: plain GPL or LGPL. What do the Classpath people think? Nic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Java tools
> "Nic" == Nic Ferrier <[EMAIL PROTECTED]> writes: Nic> It seems that the code doesn't really fit into any of the current Nic> GNU projects: Nic> - not kaffe, japhar or GCJ because it's not a compiler or VM Nic> - not Classpath because it's not core libs Nic> - not Classpathx because it's not an extension Nic> I have proposed to Julian that a new GNU project be setup called: Nic> java-tools. We can put things like javadoc and jar-tool Nic> implementations under that project. Nic> Does anyone have any objections to that? I don't have a real objection. But I think that adding a new project every time does make things more difficult. I'd prefer to see us simply expand the mandate of, say, Classpath and then just put more things in it. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
