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.to

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 ___

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 informat

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.

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 mailin

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 i

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

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 b

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 > CV

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

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 thin

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 no

Re: Java tools

"Nic Ferrier" <[EMAIL PROTECTED]> writes: > >>> Stuart Ballard <[EMAIL PROTECTED]> 09-Jul-01 4:00:18 PM >>> > >Sun might - they don't like people using the name >"Java" for things. > > The FSF doesn't use the word either. It was a mistake for me to call > the project that. > > The pro

Re: Java tools

>>> Stuart Ballard <[EMAIL PROTECTED]> 09-Jul-01 4:00:18 PM >>> Sun might - they don't like people using the name "Java" for things. The FSF doesn't use the word either. It was a mistake for me to call the project that. The project wouyld actually be called something like "class-tools" b

Re: Java tools

Nic Ferrier wrote: > > I have proposed to Julian that a new GNU project be setup called: > java-tools. We can put things like javadoc and jar-tool > implementations under that project. > > Does anyone have any objections to that? Sun might - they don't like people using the name "Java" for thin

RE: Java Tools

> John Keiser wrote: > > Sun currently distributes Java in JDK versions and JRE versions. Not > including the tools is fine if you plan on making Classpath part of a JRE > implementation. The problem is a JDK distribution contains the > tools and these > tools depend on the class libraries. Mo

Re: Java Tools

John Keiser wrote: > > From: Aaron M. Renn > > > > Hmm. If you're 90% done, it doesn't look like you need any help! > > Your free > > version is probably good enough. I'm not sure that we need to distribute > > tools as part of Classpath anyway. I was thinking that there might be a > > pack

RE: Java Tools

> From: Aaron M. Renn > > Moses DeJong wrote: > > I am also working on a jar replacement program for the Kaffe project. My > > version is about 90% done and does some of the new 1.2 style jar stuff > > (like the -C argument to change dirs). The jar update and creation of > > uncompressed archives

Re: Java Tools

>Minor correction; >gnu.bytecode does support >disassembly (see >gnu.bytecode.dump). It isn't >the same output format as >javap, but I >don't think that's an issue. It could be if someone else's development tool relies on format.

Re: Java Tools

On Fri, 12 Feb 1999, Aaron M. Renn wrote: > Moses DeJong wrote: > > Well, sharing is always good. Perhaps I have run into something you have > > not and vice versa. The Jar stuff is really nasty because the > > java.util.zip is so badly implemented and documented (this is Sun's > > fault). This l

Re: Java Tools

Moses DeJong wrote: > Well, sharing is always good. Perhaps I have run into something you have > not and vice versa. The Jar stuff is really nasty because the > java.util.zip is so badly implemented and documented (this is Sun's > fault). This last 10% is much more difficult to get working than >

Re: Java Tools

Moses DeJong wrote: > I am also working on a jar replacement program for the Kaffe project. My > version is about 90% done and does some of the new 1.2 style jar stuff > (like the -C argument to change dirs). The jar update and creation of > uncompressed archives is till broken but it is "very clo

Re: Java Tools

On Fri, 12 Feb 1999, Wes Biggs wrote: > The ClassTool thingamajig I wrote a while back covers the non-disassembly parts > of javap, though I'm not sure how well it works with JDK 1.2 (it uses > reflection, and the Javadocs state that reflection only gives you public methods > now.) Can someone r

Re: Java Tools

"Aaron M. Renn" <[EMAIL PROTECTED]> writes: > > javap - needed > > Once gnu.bytecode supports disassembly, > javap will be a since. (It could mostly be written now, just without the > disassembly option). Minor correction; gnu.bytecode does support disassembly (see gnu.bytecode.dump). It isn't

Re: Java Tools

Mark Benvenuto <[EMAIL PROTECTED]> writes: > Java 1.1 Tools > javac - jikes is faster We will have a 100% java compiler RSN (although it won't be nearly as fast). > java - VM/OS specific > jre - VM/OS specific > jdb - important > Java 1.1 jdb uses the sun.tools.debug package > >

Re: Java Tools

The ClassTool thingamajig I wrote a while back covers the non-disassembly parts of javap, though I'm not sure how well it works with JDK 1.2 (it uses reflection, and the Javadocs state that reflection only gives you public methods now.) Can someone running 1.2 try it with '--private'? It's at htt

Re: Java Tools

Mark Benvenuto wrote: > Nicolaou. Unfortunately, a lot of tools are still missing that are part > of the standard Java 1.1 and 1.2 distributions. Since the goal of I've been thinking about this as well. In fact, I've already started work on some things. > javah - needed > javap - needed > javad