Cross-compiling error
Hi, Off on a tangent here so apologies for hitting the list up. I thought I might try to get Classpath + JamVM running on the iPhone ARM platform, cross-compiled from Cygwin. I'm far from a cross-compiling expert, though, so any help would be appreciated. I'm not trying anything too crazy with GTK/X for now (will consider it a success if I can execute command line HelloWorld.java), I cribbed this configure line from online instructions from someone who'd done similar for their ipaq, though with an early version of Classpath: $ ../configure --host=arm-apple-darwin --target=arm-apple-darwin \ --without-x --disable-gtk-peer --with-jni \ --disable-gconf-peer --disable-plugin --prefix=/usr/local/share This ran seemingly fine (I am working with a clean 0.96.1 Classpath download), though I suspect some of those options are no longer valid. make did pretty well also, but eventually hit the following error while building libjavaio: [...] (cd .libs/libjavaio.lax/libclasspathnative.a arm-apple-darwin-ar x /c/java/classpath-0.96.1/build/native/jni/java-io/../../../native/jni/native-lib/.libs/lib classpathnative.a) arm-apple-darwin-gcc -dynamiclib -o .libs/libjavaio.0.0.0.dylib .libs/java_io_VMFile.o .libs/java_io_VMObjectInputStream.o .libs/java_io_VMObjectStreamClass.o ../../../native/jni/classpath/.libs/jcl.o .libs/libjavaio.lax/libclasspathnative.a/cpio.o .libs/libjavaio.lax/libclasspathnative.a/cpnet.o .libs/libjavaio.lax /libclasspathnative.a/cpproc.o-install_name /usr/local/share/lib/classpath/libjavaio.0.dylib -compatibility_version 1 -current_version 1.0 /usr/local/bin/arm-apple-darwin-ld: Undefined symbols: ___eprintf collect2: ld returned 1 exit status make[3]: *** [libjavaio.la] Error 1 make[3]: Leaving directory `/c/java/classpath-0.96.1/build/native/jni/java-io' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/c/java/classpath-0.96.1/build/native/jni' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/java/classpath-0.96.1/build/native' make: *** [all-recursive] Error 1 It's the ___eprintf that seems to have thrown it. Has anyone seen something similar? Did my ./configure miss a symbol? Thanks in advance, Wes
Re: Imported gnu.regexp and java.util.regex wrappers
Mark Wielaard wrote: Hi all, I finally imported gnu.regexp and added java.util.regex wrappers for it. At the moment our gnu.regexp is the same as the original gnu.regexp version, except for a few files and added copyright notices. If this doesn't break things then I want to ship this as is with the 0.08 release. Then we can see how it works in practice. Some thing to consider is that Wes might want to have a separate release of this, then we have to think about how to avoid name/classloading-clashes (since the integration means it is now part of the core/bootclasspath). Wes, do you have ideas about how we can coordinate releases? And/Or do you want to make releases from/in combination with new classpath releases? Mark -- thanks again for doing all this. I don't foresee myself doing any active development on gnu.regexp in the near future, so I'd prefer to slave to your changes. The development has been relatively quiet in terms of patches coming in, etc., for the last couple of years. So maybe if you and Dalibor get to a good release point for Classpath, I can sync up with your sources at that point and do a release on savannah. Wes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: status of java.util.regex support
Dalibor Topic wrote: Hi, I read a while ago that support for java.util.regex was to come into GNU Classpath, so I'm interested to know what came out of it? I know there are stubs in the CVS, but I've also read Wes wrote a java.util.regex wrapper around his gnu.regex package, so I'm wondering if there was any progress on getting this into Classpath. I believe I have completed paperwork for past and future contributions to Classpath, and I have working (if not totally spec compliant) bridge code that I can contribute now. My sense from the Classpath team was that they didn't want bridge code that relied on code (gnu.regexp) that has not been copyright-assigned to the FSF. I'm willing to do this assignment, but I can't contribute the gnu.regexp classes themselves without doing some due diligence and contacting past contributors and getting them to waive their individual copyrights. I'll take a stab at doing this. In the meantime I can give you the bridge code (implementation of java.util.regex) if you want to use it in conjunction with the LGPLed gnu.regexp code (latest CVS from savannah is compatible). The reason why I'm asking is that Saxon 7.2/7.3 needs java.util.regex, and a working java.net.URI implementation. Parsing URIs should be quite easy if there is a working regex implementation, given that the RFC specifying URIs gives a regular expression showing how to parse them. Please CC: me on replies as I'm not subscribed to the classpath list currently. Thanks, Wes ___ 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
Re: java.util.regex
Nic Ferrier wrote: Is there any reason why Classpath couldn't include your source code in the CVS? If you hosted the CVS for gnu regexp on subversions (via the savannah system) we would be able to create a link from the Classpath CVS to your source code directories to make it seem as if Classpath included your source code (but it would still be maintained separately). That would work. I've been making slow progress on getting set up on Savannah (there's a project created, but I don't yet have CVS access working). I think to do that you'd need to hand over (c) to the GNU project. As well as getting all past contributors to do so, I would presume, which might take some time. Alternately Classpath could start to deliver jar files with the distribution. I personally think we should make Aaron's getopt stuff available with Classpath. I see gnu.regexp as something analogous to a RPM dependency, so that might be appropriate in the near term. Embrace and extend. Now where have I heard that before..? :-) Wes P.S. Nic, did you ever find the javax.servlet.jsp.tagext classes? I received confirmation from FSF last week that they have my (c) assignment on file, so you should be able to add them to classpathx. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: org.gnu vs. gnu (was Re: Congratulations)
Hey, I've got a great solution. We start a "gnu" TLD to go along with "com", "org", etc. Problem solved, everyone's happy, we all find more constructive things to debate and/or get on with writing code. Wes
Re: Congratulations
Thomas J Lukasik wrote: it certainly **is** arrogant to think that they own the three letters 'GNU'. How can anyone own anything that's just a bunch of symbols? A word, say, or perhaps a computer program? A programming language? I don't think anyone is arguing that the abstract, conceptual entity known as the Free Software Foundation owns, or even CAN own, such an abstract, conceptual entity as a namespace -- in fact quite the opposite. I'm for using gnu.* because it makes opaque the irrelevance of ownership. Cheers, Wes
Re: Congratulations
Thomas J Lukasik wrote: Wes, You are obviously unaware of the document at: http://www.gnu.org/software/java/why-gnu-packages.txt I'm quite aware of it. Allow me to quote from it: Really, you'd have to ask Per for permission, but we'll assume, on the basis of his publicly stated opinions, that he won't go after you for copyright infringement. :-) "There is no measurable benefit of using org.gnu instead of gnu. I refuse to be concerned over anybody who might use gnu as a package prefix without co-ordinating with gnu.org - that's their problem, not ours." What does the statement "..that's there problem not ours." say about arrogance and ownership of 'GNU'? A "refusal to be concerned" is not a statement of ownership. I read it the other way -- go ahead and put your package under "gnu.*", if it causes a conflict, you figure it out. Per and I, we don't care one way or the other. Apathy's not the same as arrogance. You're entitled to your own opinion, and you're entitled to use "gnu.*" or "org.gnu.*" as you wish. Last time I checked, no one had filed a lawsuit for breach of Java package namespace. If you're paranoid, encrypt and seal your JAR. Wes
Re: javac.servlet.* javax.servlet.http.*
Paul, I see that classpath still has no javax/servlet directory. I'd be interested in using/testing your packages. Could you mail me a tarball? If the JSDK stuff is stable, it would gain classpath a lot of visibility if we were to announce that on the Apache JServ and java-linux lists. I guess the issue is still whether non-standard extensions should be part of classpath. In RPM style, I would say we could put out multiple distributions-- classpath-base classpath-gtk classpath-servlet etc. Wes "P. Siegmann" wrote: hi, The servlet classes are currently in a working and documented state. Could they be added to the cvs repository? And preferably in their own module?
Evil water droplet
Hey, is this guy the classpath mascot, or the GNU j*va dude? Can I put him on my gnu.regexp site? (OK, OK, I know this isn't really contributing anything to the discussion, but I'm all for meme propagation...) Wes
Re: JDK source code
In the case of Jini at least (I don't know the specifics of the JDK) the royalty is something like $0.10. So if you sell 100 copies of your software Sun makes $1. quipAre you using Microsoft Calculator again?/quip :-)
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 http://www.cacas.org/java/gnu/tools/ I've hacked pieces of JacORB (a LGPLed Java CORBA implementation) to have a running idltojava for linux, but ideally that tool should be template-file based, which I will work on when I get some time. Wes "Aaron M. Renn" wrote: 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 javadoc - Aaron M. Renn wrote some stuff Japhar has a javah replacement. I also wrote one in order to play around with the gnu.bytecode package. Once gnu.bytecode supports disassembly, javap will be a since. (It could mostly be written now, just without the disassembly option). My javadoc API code is checked in. serialver - I thought I saw it in the web CVS which has now disappeared? We've got one. CVS web access is temporarily gone. Paul is working on restoring it. jar - desperately needed I'm 50% done with jar. It is on hold until Classpath supports java.util.zip and java.util.jar. extcheck - checks for jar conflicts - needed I've already written this. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
Re: Substitute for javap
Geoff Berry wrote: Brian Jones [EMAIL PROTECTED] writes: [snip] Does anyone think we need a free software replacement for javac which isn't already accomplished by using Kiev? Regardless of whether it is needed or not, I am (actively) working on such a thing right now. It should be finished by the end of the semester (or I'm in trouble). It's for a class so I have to do it alone, but at the end of the semester I should be able to let it loose. -- Geoff Berry Geoff, What's the source language for this project? I'd like to see a javac replacement written in Java (Kiev is written in Kiev and has a few limitations on java code that it will accept). It sounds like it will definitely be useful. Wes
Re: better javap comparisons
John Keiser wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Stuart Ballard FWIW, I strongly agree with John about protected classes. Protected members of a class *ARE* part of the public API in Java. I think you guys are debating different points. I hope no one's arguing that protected members shouldn't be included in classpath. But John is right, I can't think of an example of a protected _class_. Can you show one example of a protected class in the documentation? I think that would settle this for good. Paul asserted that there were no protected classes in JavaDoc and concluded based on that that Sun didn't intend for protected classes to be part of the public API. --John Keiser Wes
java.text
Hi all, As I'm not realistically producing much code at this point, I'm going to check in what I have vs. the source tree on java.text and let Aaron and the rest of you take a look. Essentially this is just SimpleDateFormat and DateFormatSymbols (I was using a locale scheme similar to Aaron's so it shouldn't be tough to switch the package to gnu.java.locale. re:Japhar and ResourceBundles This was working in 0.05 but if I recall correctly Japhar was a little loopy about what you needed to name the files (it would find FILE_en.properties, but not FILE.properties which is what it's supposed to check first). Now in 0.06 it looks like it can find FILE.class and FILE_en.class, but not .properties, in a ResourceBundle.getBundle() call. (maybe this is a problem with Blackdown's 1.1.5v7 implementation of java.util.ResourceBundle and not japhar?) Anyway, I may have more time at some point before/after the initial release but I can't make any promises. I'll commit what I can now and go from there. Wes
Re: What is compatible regarding inheritance?
At 05:32 PM 10/3/98 +0100, Stuart Ballard wrote: ~ Adding a package-private superclass in between a class and its specced superclass (for cases where code can be reused)? Would this affect serialization? If it breaks serialization we're probably in trouble. IMO the whole serialization spec stinks, and it's really a killer blow to us trying to write code that's better than Sun's (and the clueless goons they hired to write java.text, don't get me started...). While I think a 100% compatible implementation of java.* is important (and hence I'm working on this project), it's too bad we can't just do gnu.* (i.e. not use the existing API, just the java language) and do it right. :-) Wes
Re: Testing framework
Paul Fisher wrote: Wouldn't a simple inner classes setup do what you're asking? Yep. Just generates a lot of files as noted. I'll be interested in how the GUILE/JVM integration works. Wes
CORBA (was Re: What I'm up to)
Geoff, Aaron: I may have mentioned this before, I forget. I haven't used it, but JacORB is a partial implementation of the org.omg spec that goes far beyond what Sun has implemented and happens to be LGPLed. IMHO if we could get this guy involved it would work well for both sides (we get CORBA, he gets distribution). Who's wearing the diplomacy hat? URL --http://www.inf.fu-berlin.de/~brose/jacorb/ Note also that OMG hasn't finalized the Java API. There are definitely inconsistencies in various Java ORB implementations (e.g. in Java the use of the BOA has been deprecated -- Sun's 1.2beta doesn't include it, but JacORB and others do). The current Java/CORBA mapping spec is at ftp://www.omg.org/pub/docs/formal/98-02-29.pdf. Wes Aaron M. Renn wrote: I've basically finished java.io and was planning on looking at security next. (Keiser, you said something about this too, so if you were dying to do it, let me know). I think both RMI and CORBA are good things to look at. I'd stay away from anything that duplicates the Kaffe libs for the time being.
Re: 1.1 vs. 1.2 revisited
If we do explicit import statements for every class our class depends on we could easily generate a makefile in the way that the "mkmf" utility does for C(++). I think explicit imports help readability anyway, as long as classes are well-named and non-conflicting (general imports such as java.io.* could still work, just be a little more expensive in terms of the classes to check). The utility would look for "import x.y.z", check if the file x/y/z.java exists, and if so insert a make dependency line for x/y/z.class accordingly. Everything that needed it would have to import gnu.java.Config (replace with wherever Config.java lives). Do we want these utils to be java apps or does it matter? Wes Bernd Kreimeier wrote: John Keiser writes: The problem with the public static final boolean variable is, you have to edit the source every time you want to change it. Different classpaths, different Config.java first? Yeah, well - last time I tried, javac seemed to screw up dependencies to different packages (i.e. directories) or so... reminds me, any recommendations on how to do "make depend" for Java sources? -- /* USWeb Corporation, http://www.usweb.com/*/ /* A Strategic Partner for the Information Age */ /* Phone: 310-335-5200 Facsimile: 310-640-3264 */
Re: since JavaDoc
John Keiser wrote: What should we be using in place of JavaSoft's @since JDK1.0 and @since JDK1.1? CP1.0 and CP1.1? Or should we just use their convention? --John Keiser How about @since GNU Classpath 1.0, per JDK 1.1 Identifying (a) what version of Classpath it was implemented in (some packages will not be implemented in initial releases of Classpath, I'm guessing) and (b) what the reference implementation is. Wes
java.text status, some questions
Hi all -- briefly, java.text is underway. For those who haven't messed around with it (and really, I don't blame you), it's a set of classes to do text formatting and parsing into useful things like Date objects. A lot of it has to do with i18n in terms of collation elements (e.g. in Spanish, 'ch' and 'll' are considered single collation units even though they take two characters to represent) and date and number formatting conventions. Anyway, I've been working at getting the date stuff done first (for one, it's what gets used most), and that's going well. The factory methods and secondary classes are pretty much written, as are most of the format() methods. When that's done (soon) I'll work on SimpleDateFormat.parse() which converts a String into a Date, as if by magic. The other format types (Number, Choice) don't look too tough, so they'll probably come next. One thing that's come out of building the date stuff is that we need to decide how we want to deal with locale-specific resources. Right now I've got a DateFormatSymbolsResource.properties that lives in gnu/java/text and provides the names of the months, weekdays, default formats, and so on. It is referenced as a ResourceBundle, so a similar properties file could be provided for locale X. I wrote some JNI stuff earlier to call strftime() to get the month names and so on, but there's obviously no C functions to get Java SimpleDateFormat format strings (although we could get really clunky and try reading the raw locale-specific files and converting the C formats to Java formats, ouch). So the JNI stuff is scrapped for now, though I might build it as a utility for POSIX systems to extract data when creating a properties file. There is additional locale-specific data needed for NumberFormat, and for java.util.TimeZone (is anyone working on that?). I think we need the following: (1) a standard directory to put resource bundles in, maybe gnu.resource. It needs to be in the classpath. Resources might follow a naming convention like "PackageClass[_locale...]", where Class is not necessarily the only class that uses the data but the primary one associated with the resource, e.g. "JavaTextDateFormat_en.properties", "JavaUtilTimeZone_es_ES.properties". (2) A standard convention for property file formats. I've been doing things like this: shortMonths=Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec And then parsing the value with a StringTokenizer to split it into an array, which the API calls for. Suggestions are welcome. This obviously breaks for individual values that contain a comma, so maybe those would be escaped with a backslash. (3) an installation process (eventually!) that allows the user to choose which locales they want to install. I doubt everybody wants to lug around all the possible locale data whenever they install classpath. This gets a little complicated, as these resources are part of the JAR file, so we would have to run "jar uf" (and I think the [u]pdate command is an addition to 1.2). Space isn't really at premium on, say, my Linux box, but on an embedded system or something it might be a major issue. (unfortunately the unicode database is still too big to pursue my dream of running Java on the Commodore 64... maybe with some smart disk caching in the JVM implementation..) We might want to think about localizing exception messages and other static strings at some point, too. ResourceBundles are very easy to use.. One thing that's bugging me is how to implement getAvailableLocales(). Are there methods for accessing the (virtual) directory structure of the user's classpath, or do we need to provide a single Locales.properties files or something similar that just lists the names of installed locales? I'm kind of blazing my own trail for this right now, so any ideas on how to better organize are definitely welcome. When I finish the DateFormat stuff I'll start bugging Paul for CVS access and let the rest of you play with it. Wes
Reverse engineering?
Am I allowed to write Java code, run it on Sun's JDK, and use the
generated output to give me a feel for how my implementation should
work? e.g. the getZoneStrings() method of java.text.DateFormatSymbols
returns a String[][], but nothing in the API says anything about the
format of those arrays. Obviously, though, there's some kind of
convention that they're expecting, e.g. it's an array with a pair of
strings per time zone.
Can I write a program that does something like:
String[][] temp = dfs.getZoneStrings();
for (int i=0; itemp.length; i++) {
for (int j=0; jtemp[i].length; j++) {
System.out.println("["+i+","+j+"] = "+temp[i][j]);
}
}
or does that go against the principles here?
Wes
Dev. environment
What's a standard dev environment for classpath on linux? I'm having a hard time getting my JNI code to work under SBB's jdk1.1.6v2, so I'm going to try japhar. First call to a native method runs successfully, second one (even with same args) dumps with SEGV while calling strftime. Ideas? The only JNIEnv methods I'm using are (Get|Release)StringUTFChars and NewStringUTF. Just curious if this is my own damn fault or something the SBB port's JNI implementation is trashing. Wes
Re: Introduction/General questions
Aaron M. Renn wrote: Yes, I took a glance through the CORBA stuff and it looks pretty scary. I was looking around, and jacORB is a LGPL'ed ORB that implements much of the spec. I'll take a look at the source at some point and if it looks promising perhaps the author would be agreeable to using it for $classpath... Depending on how much time I can eke out of my week, java.text could be done in some half-assed fashion in a week or two. Wow. That would be superb. I wish I coded that fast. Don't underestimate the task, though. Merely getting locale specific date formats/parsing is going to be painful. Though the only thing we really need to support for right now is the US locale. I would look to leverage the code in glibc for this, even if it means we have to make native calls instead of a pure Java solution. Right, thus the "half-assed" above, implying U.S. only. I haven't worked much with the i18n stuff, but I guess we could just come up with a good scheme to have a properties file per locale (any brilliant ideas, anyone?) Wes
Re: Introduction/General questions
Hmm, didn't mean to open a can of worms here. I agree that it's more important to have the core stuff done, and to that end I volunteer to do java.text, which no one really wants to have to implement and/or use, but hey, it's part of the spec. After that, maybe I will have the time to combine Paul's 1.0 javax.servlet implementation with my 1.1 javax.servlet.http implementation and/or work on CORBA (which, even though I'm familiar with the subject matter, is going to be a major project.) Depending on how much time I can eke out of my week, java.text could be done in some half-assed fashion in a week or two. Wes Aaron M. Renn wrote: He mentioned the CORBA stuff. Even though it's 1.2, it needs to be done and I don't know of anyone else who has the expertise to write it. Yes, CORBA is important, but java.text is more important. :) I base the importance solely upon 1.1 vs. 1.2. Of course, it's up to Wes what he writes (we'll take most anything). True, but if Wes is interested in CORBA, I'd encourage him to do that. There are other people I know can code up java.text (like you, for example). Plus coding up the java.text class is likely to induce some sort of brain damage in the coder. Yes, and I'm afraid that java.text might be the next piece for me to work on. :) I'm glad someone wants to work on it! I will be done with java.io in a couple of weeks (depending on how much time I have to devote to it and the state of construction in my building). Is someone else finishing off java.util? I seem to recall Keiser or someone saying something about it. If not, I'll take that one. -- * * Aaron M. Renn * * Email: [EMAIL PROTECTED] * * Homepage: URL:http://www.urbanophile.com/arenn/ * * -- W E S B I G G S Sr. Software Engineer _ U S W e b Los Angeles - la.usweb.com p 310 335 5200 x 335 - f 310 640 3264
