cvs commits and java.util.regex
I ran into a problem when compiling with Jikes. I had set the environment variable BOOTCLASSPATH to Sun's rt.jar, so that I could use jikes as a dropin replacement to javac, without specifying -classpath, for regular Java files (ie. not from the Classpath project). When I back went to compile Classpath, this sucked in files from rt.jar when they didn't appear in Classpath, and gave me a clean compile even though I was expecting failure (because I referenced java.util.regex, which is not yet in Classpath). Someone with a little more autoconf knowledge than me should figure out how to make the default command-line arguments to Jikes include an explicit -bootclasspath to override any environment variable. The cleanest way to guarantee that Jikes is only compiling Classpath files, and not mixing in some other library because of the environment, is to compile with these flags: jikes -bootclasspath '' -extdirs '' -sourcepath '' -classpath path to all Classpath files @classes How should we build Classpath without regex? John ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: cvs commits and java.util.regex
John Leuner wrote: they didn't appear in Classpath, and gave me a clean compile even though I was expecting failure (because I referenced java.util.regex, which is not yet in Classpath). How should we build Classpath without regex? I think the short answer right now is that Classpath doesn't support regex, so those classes would have to come from rt.jar. However, I am working on getting java.util.regex code into Classpath -- per the discussion last week I would like to check in the java.util.regex classes and update the build to use the gnu.regexp JAR to compile against. Email me if you want code right away. Wes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Please keep Classpath in a working state (Was: cvs commits andjava.util.regex)
Hi, On Fri, 2002-03-08 at 20:15, Wes Biggs wrote: John Leuner wrote: they didn't appear in Classpath, and gave me a clean compile even though I was expecting failure (because I referenced java.util.regex, which is not yet in Classpath). How should we build Classpath without regex? I think the short answer right now is that Classpath doesn't support regex, so those classes would have to come from rt.jar. Please no. Classpath is now at a point that it can be compiled with only free tools. Please keep it that way. I think the String changes should not have been checked in. For classes that are really standalone and that you want to have in the CVS repository you can add them to the lib/standard.omit file so they don't interfere with the build (although I would like to keep that file as small as possible, ideally it would be empty). If that is really not a option then you should either work on a branch or check in stub classes. Please, please, please, always keep the tree compiling and working with the VM-interface we currently have. Sometimes you have to break it to make progress, but in that case please warn everybody by posting your patch to the mailinglist first before you check in and explain what people should do to keep on working with their current setup. Maybe we could define a minimum setup that is easy for everybody to get working? I would propose using jikes (1.15+) and orp (1.0.9+) as the minimum setup that always needs to work for compiling/running Hello World with Classpath. That way someone can always fall back to Is Classpath/Jikes/Orp available on all platforms that the Classpath hackers currently use? Orp might be a bit x86 specific, but no other free VM is currently so easy to use with Classpath out of the box. Does the Classpath build work on a MSWindows/CygWin (sp?) system? However, I am working on getting java.util.regex code into Classpath -- per the discussion last week I would like to check in the java.util.regex classes and update the build to use the gnu.regexp JAR to compile against. Email me if you want code right away. How long before this work will be finished? Would it be possible to create stubs from your code at the moment? If yes, then please send them to me and I will do it and check them in so the tree at least builds again. Thanks, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: cvs commits and java.util.regex
they didn't appear in Classpath, and gave me a clean compile even though I was expecting failure (because I referenced java.util.regex, which is not yet in Classpath). How should we build Classpath without regex? I think the short answer right now is that Classpath doesn't support regex, so those classes would have to come from rt.jar. However, I am working on getting java.util.regex code into Classpath -- per the discussion last week I would like to check in the java.util.regex classes and update the build to use the gnu.regexp JAR to compile against. Email me if you want code right away. I wrote empty classes to allow compilation (I specifically don't want to compile against foreign classes for the stuff I'm doing). John Leuner ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Please keep Classpath in a working state (Was: cvs commits andjava.util.regex)
Mark Wielaard wrote: Please no. Classpath is now at a point that it can be compiled with only free tools. Please keep it that way. I think the String changes should not have been checked in. No String changes that depend on java.util.regex were checked in. My conversation started because I added the dependency in my local tree, and EXPECTED a failure, knowing that java.util.regex was non-existant, just to see what I would have to add. But I am not planning on committing anything which will break the build. For classes that are really standalone and that you want to have in the CVS repository you can add them to the lib/standard.omit file so they don't interfere with the build (although I would like to keep that file as small as possible, ideally it would be empty). If that is really not a option then you should either work on a branch or check in stub classes. If I check in anything, I will either leave the implementation in String.java as throw new InternalError(unimplemented); or else add stub classes in java.util.regex which do the same. Actually, now that I think about it, putting the error in a stub class is better, because then we won't have to go back and change String. Please, please, please, always keep the tree compiling and working with the VM-interface we currently have. Sometimes you have to break it to make progress, but in that case please warn everybody by posting your patch to the mailinglist first before you check in and explain what people should do to keep on working with their current setup. I agree with this (and if I've been guilty of breaking things in the past, I'm sorry). Maybe we could define a minimum setup that is easy for everybody to get working? I would propose using jikes (1.15+) 1.15b, actually, available from Jikes CVS - the jikes 1.15 release has problems. and orp (1.0.9+) as the minimum setup that always needs to work for compiling/running Hello World with Classpath. That way someone can always fall back to Is Classpath/Jikes/Orp available on all platforms that the Classpath hackers currently use? No, I'm on Cygwin, and have yet to compile a successful free VM (or for that matter gcj). However, I haven't really sat down and tried tweaking ORP, yet, so maybe I can get it to work if I put some effort into it. Orp might be a bit x86 specific, but no other free VM is currently so easy to use with Classpath out of the box. Does the Classpath build work on a MSWindows/CygWin (sp?) system? The build works out of the box, but only builds the .class files (no native support). At least, I haven't gotten native support to work. -- 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: Please keep Classpath in a working state (Was: cvs commits andjava.util.regex)
Hi, On Fri, 2002-03-08 at 21:36, Eric Blake wrote: But I am not planning on committing anything which will break the build. It came in with this commit although the changelog entry does not mention it, so you probably comitted from the wrong working directory: 2002-03-07 Eric Blake [EMAIL PROTECTED] * java/lang/String.java: Improve Javadoc and formatting. * java/lang/StringBuffer.java: Ditto. http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/lang/String.java.diff?tr1=1.37tr2=1.38r1=textr2=text now that I think about it, putting the error in a stub class is better, because then we won't have to go back and change String. This is exactly which John just checked in. Everything compiles again. Thanks John. and orp (1.0.9+) as the minimum setup that always needs to work for compiling/running Hello World with Classpath. That way someone can always fall back to Is Classpath/Jikes/Orp available on all platforms that the Classpath hackers currently use? No, I'm on Cygwin, and have yet to compile a successful free VM (or for that matter gcj). However, I haven't really sat down and tried tweaking ORP, yet, so maybe I can get it to work if I put some effort into it. Would it help if we got you off this non-free proprietary platform? I could sent you a copy of my Debian CDs :) Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Please keep Classpath in a working state (Was: cvs commits and java.util.regex)
On Fri, Mar 08, 2002 at 01:43:49PM -0800, Wes Biggs wrote: How long before this work will be finished? Would it be possible to create stubs from your code at the moment? If yes, then please send them to me and I will do it and check them in so the tree at least builds again. I'll check my stub classes in now. Hmm.. after reading that the build is not actually broken, does it really make sense to check in do-nothing code? Well ... Eric seems to think he hasn't checked his changes in, but he has :-) The only thing that accomplishes is matching the JDK 1.4 interface, it doesn't add any functionality. Can we wait on split() functionality for the real regex implementation? (I have to sign paperwork for copyright assignment). It's done already, it's really only a few lines. The dependency from String - Pattern is just one or two method calls. John Leuner ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: environment and compiling with jikes
Hi,
On Fri, 2002-03-08 at 17:53, Eric Blake wrote:
Someone with a little more autoconf knowledge than me should figure out
how to make the default command-line arguments to Jikes include an
explicit -bootclasspath to override any environment variable. The
cleanest way to guarantee that Jikes is only compiling Classpath files,
and not mixing in some other library because of the environment, is to
compile with these flags:
jikes -bootclasspath '' -extdirs '' -sourcepath '' -classpath path to
all Classpath files @classes
That was actually easy:
--- lib/Makefile.am 18 Feb 2002 20:52:17 - 1.41
+++ lib/Makefile.am 8 Mar 2002 23:51:20 -
@@ -45,7 +45,7 @@
# handling javac definition including programs like jikes here
#-
if FOUND_JIKES
-JAVAC = $(JIKES) +F $(ARG_CLASSPATH_JAVAC)
$(top_srcdir):$(top_builddir)/vm/current:.:$(USER_CLASSLIB) -d . @classes
+JAVAC = $(JIKES) +F -bootclasspath '' -extdirs '' -sourcepath ''
+$(ARG_CLASSPATH_JAVAC) $(top_srcdir):$(top_builddir)/vm/current:.:$(USER_CLASSLIB) -d
+. @classes
else
if FOUND_GCJ
JAVAC = $(GCJ) -C -d . @classes
So the actual jikes command that is run from lib during the build is:
/usr/bin/jikes +F -bootclasspath '' -extdirs '' -sourcepath ''
-classpath ..:../vm/current:.: -d . @classes
If I followed the gcj mailinglist correctly then the next version of gcj
will also know about these flags. And I believe the latest kjc also
handles them so we might want to do this for all compilers in the
future.
(Note to Debian loving people: Jikes Version 1.15b(CVS) - 9 Feb 2002
just entered unstable!)
I also added the following stub to Socket.java so java.util.logging can
actually compile:
--- java/net/Socket.java22 Jan 2002 22:27:00 - 1.11
+++ java/net/Socket.java8 Mar 2002 23:51:20 -
@@ -667,4 +667,13 @@
factory = fac;
}
+
+ public void shutdownInput() throws IOException
+ {
+ }
+
+ public void shutdownOutput() throws IOException
+ {
+ }
+
}
And this small reversal of a Class.java change that made it impossible
to use it with Orp 1.0.9.
--- vm/reference/java/lang/Class.java 23 Feb 2002 09:19:52 - 1.19
+++ vm/reference/java/lang/Class.java 8 Mar 2002 23:51:21 -
@@ -136,11 +136,15 @@
* @throws ExceptionInInitializerError if the class loads, but an exception
* occurs during initialization
*/
- public static Class forName(String name) throws ClassNotFoundException
+ //XXX This does not need to be native.
+ public static native Class forName(String name)
+throws ClassNotFoundException;
+ /*
{
return forName(name, true,
VMSecurityManager.getClassContext()[1].getClassLoader());
}
+ */
/**
* Use the specified classloader to load and link a class. If the loader
Cheers,
Mark
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
