Re: question about vm/reference files

[Eric Blake]

> The thought was that Classpath either would not provide the classes
> that are VM dependent (leaving those to the VM) or that there would be
> multiple directories (vm/gcj, vm/orp, vm/kaffe, etc.)  The ugly
> complexity appears to be necessary.
> 
> Brian

That still doesn't explain why Object is in the top level when the other
core classes are not.  Even if these classes have no Java
implementation, it is still useful to have a .java file in Classpath for
making the .class file which jikes requires for compilation purposes.

-- 
This signature intentionally left boring.

Eric Blake [EMAIL PROTECTED]
  BYU student, free software programmer

___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: question about vm/reference files

[Brian Jones]

Eric Blake <[EMAIL PROTECTED]> writes:

> What is the reason that some of the VM dependent core .java files are
> not located directly in the top tree, while others are?  For example,
> java/lang/Object.java is in the main tree, but java/lang/Throwable.java
> is only in the vm/reference subtree.
> 
> I understand why things like VMClassLoader.java are not in the main
> tree, since that is not a public API, even if it does compile to the
> java.lang package.  But for compilation 3rd-party projects, jikes needs
> a .jar file with all the public APIs, even .class files for things like
> Object (where the VM probably never loads the .class file, because the
> it just uses native code).  It is annoying to have to look in two places
> to build this .jar file.
> 
> Would there be anything wrong with moving these .java files from
> vm/reference/java/lang to the main tree at java/lang?
> Class
> Runtime
> Thread
> Throwable
> reflect/Constructor
> reflect/Field
> reflect/Method

The thought was that Classpath either would not provide the classes
that are VM dependent (leaving those to the VM) or that there would be
multiple directories (vm/gcj, vm/orp, vm/kaffe, etc.)  The ugly
complexity appears to be necessary.

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>

___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

question about vm/reference files

[Eric Blake]

What is the reason that some of the VM dependent core .java files are
not located directly in the top tree, while others are?  For example,
java/lang/Object.java is in the main tree, but java/lang/Throwable.java
is only in the vm/reference subtree.

I understand why things like VMClassLoader.java are not in the main
tree, since that is not a public API, even if it does compile to the
java.lang package.  But for compilation 3rd-party projects, jikes needs
a .jar file with all the public APIs, even .class files for things like
Object (where the VM probably never loads the .class file, because the
it just uses native code).  It is annoying to have to look in two places
to build this .jar file.

Would there be anything wrong with moving these .java files from
vm/reference/java/lang to the main tree at java/lang?
Class
Runtime
Thread
Throwable
reflect/Constructor
reflect/Field
reflect/Method

-- 
This signature intentionally left boring.

Eric Blake [EMAIL PROTECTED]
  BYU student, free software programmer

___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: java.util

[Tom Tromey]

> "Eric" == Eric Blake <[EMAIL PROTECTED]> writes:

Eric> I currently don't have write access to libgcj.  Should I apply
Eric> for that, so that I can do the work of keeping the two in synch,
Eric> rather than leaving that responsibility on others like Tom?

Please do!  Use this form:

http://sources.redhat.com/cgi-bin/pdw/ps_form.cgi

Put my email address in the "approver" field.
It may take a few days to get an account right now.

Note that the process for getting libgcj patches in is a bit more
restrictive than the Classpath process.  You have to send the patch
(with ChangeLog and description) to [EMAIL PROTECTED] and get
approval (at least initially; this changes with time).

Tom

___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: build ideas

[Bryce McKinlay]

On Thursday, October 18, 2001, at 02:43  AM, Eric Blake wrote:

> What about the idea of both a Makefile and build.xml approach to
> building the .class files?

This sounds reasonable to me.

regards

Bryce.



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Missing AWT peer

[Bryce McKinlay]

On Thursday, October 18, 2001, at 02:22  AM, Andreas Rueckert wrote:

> Console apps seem to work. At a HelloWorldApp worked as expected. It 
> seems that it's just a problem with the GTK lib.

It could be a problem with ORP and the native part of its 
System.loadLibrary() implementation. I've never tried to load any JNI 
libraries in ORP.

regards

Bryce.



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: build ideas

[Bryce McKinlay]

On Thursday, October 18, 2001, at 02:19  AM, Brian Jones wrote:

> Eric Blake <[EMAIL PROTECTED]> writes:
>
>> By the way, I think developers should have the autotools installed on
>> their machine, so I see no reason for CVS to keep track of generated
>> files like configure and Makefile.in, only the originals like
>> Makefile.am.  The generated files should be part of the distribution,
>> though, since end users should not be required to have all the 
>> developer
>> tools just to use the final product.  Fortunately, automake does this
>> correctly.

I don't agree. It makes things much easier for people to build if 
Makefile.in and configure are included in the tree. Its hard to remember 
to regenerate them in your local tree every time they might have 
changed, and its a pain to have to install automake and autoconf on 
every machine you might want to develop on. On the other hand, its 
almost no additional effort to check in updated copies of the files 
whenever actual changes to them are made.

regards

Bryce.



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Error in FileInputStream?

[Bryce McKinlay]

On Wednesday, October 17, 2001, at 10:12  PM, [EMAIL PROTECTED] wrote:

> When the JVM boots, System.in is allocated using a file descriptor.
> If the security manager is already installed, then an exception
> is thrown.
>
> Is there a reason, for assuming that the security manager is not
> available at this point or is this only some forgotten code that,
> by chance, nobody else but me run into?

I agree that it looks wrong. My guess is that the SecurityManager wasn't 
working correctly at the time the FileInputStream was written so we 
ended up with some weird code.

In libgcj the implementation is simply:

   public FileInputStream(FileDescriptor fdObj)
   {
 SecurityManager s = System.getSecurityManager();
 if (s != null)
   s.checkRead(fdObj);
 fd = fdObj;
   }

Note that SecurityException is unchecked, so it does nto need to be 
declared in the throws clause.

regards

Bryce.



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Slowly adding javax.naming (JNDI) classes from libgcj

[Mark Wielaard]

Hi,

One of the biggest differences with the libgcj tree are the javax.naming
(JNDI) classes. See .
But what is in the libgcj tree has no comments and is mainly interfaces and
stubs. Since I have no experience with this package it will take some time
to clean up and document these classes. I have committed what I have now.

Note that I also cleaned up our standard.omit file. Now that we have the
java.util.zip package all Jar related classes should compile out of the box.
Please yell if I broke your compile with my build file changes.

* configure.in (AC_OUTPUT): removed gnu/classpath/tools/Makefile,
added javax/naming/Makefile, javax/naming/directory/Makefile and
javax/naming/spi/Makefile
* gnu/java/text/Makefile.in: removed
* javax/Makefile.am (SUBDIRS): add naming
* javax/naming/.cvsignore: new file
* javax/naming/BinaryRefAddr.java: ditto
* javax/naming/InvalidNameException.java: ditto
* javax/naming/Makefile.am: ditto
* javax/naming/Name.java: ditto
* javax/naming/NamingException.java: ditto
* javax/naming/RefAddr.java: ditto
* javax/naming/StringRefAddr.java: ditto
* javax/naming/directory/.cvsignore: ditto
* javax/naming/directory/Makefile.am: ditto
* javax/naming/spi/.cvsignore: ditto
* javax/naming/spi/Makefile.am: ditto
* lib/.cvsignore: add javax
* lib/gen-classlist.sh.in: ditto
* lib/standard.omit: removed java/net, java/lang, java/text and
java/util/jar classes, added javax/accessibility and javax/swing

Cheers,

Mark
-- 
Stuff to read:

  What's Wrong with Copy Protection, by John Gilmore

___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath