Re: GCJ ------ file type not supported by system
On 09/03/2014 09:35 AM, Guillermo Rodriguez Garcia wrote: What would you like me to do? How can I help ? More useful than updating Classoath per se would be creating a version of GCJ that uses OpenJDK's javac for compiling to bytecodes, and OpenJDK classes (or at least mostly so). This is a big project, but has a chance of being useful and maintained. There may be licensing issues that should be considered before charging full steam ahead. I'm out of the loop, so I don't know if anything like that is happening. I'd start with switching to using javac. When I'd add/replace whatever non-core classes that don't wouldn't conflict with GCJ/Classpath core classes. Maybe this wold be a fork or branch of Classpath, or maybe the mainline - depends on the changes. In general, the sanest way to update classpath is to merge in OpenJDK code. (Again, assuming licensing and other policy issues have been evaluated.) However, the OpenJDK classes may depend on recent Java language features. Which is why projects using Classpath should switch to using OpenJDK's javac. (I don't believe Eclipse's compiler is as solid or complete, though that may be my bias from having worked with javac engineers. It's probably good enough for at least the initial stages of merging in OpenJDK classes.) -- --Per Bothner p...@bothner.com http://per.bothner.com/
Re: ASM and gnu.bytecode
RMS wrote: That license is GPL-compatible, so it is ok to use the code and ok to import it as a package that is not part of GCC but distributed with it. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: ASM and gnu.bytecode
Andrew Haley wrote: Per, if you're listening: may we incorporate gnu.bytecode within classpath? Absolutely. Might as well get the most recent version from svn: http://www.gnu.org/software/kawa/Getting-Kawa.html However, Tom does have a point that sticking with ASM is probably easier. Kawa probably does make it easier to generate quality code for a compiler (and can do it very fast), but I doubt you'd get much gain using it for rmic, especially since the ASM version more-or-less works. Here is an article I wrote on using gnu.bytecode: http://per.bothner.com/compiling-regexps.html It surely makes more sense there than as part of Kawa. Huh? Kawa needs gnu.bytecode amd can't assume Classpath - at least not yet! -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: ASM and gnu.bytecode
Andrew Haley wrote: Having gcj depend not only on ASM but also on a *specific version* of ASM is intolerable. If gnu.bytecode will do the job, we should use it. While gnu.bytecode (along with gnu.math) has been fairly stable for quite a while, and it probably has been the most stable part of Kawa, I have not guaranteed backward compatibility in the past. Of course if other projects start depending on gnu.bytecode, I'll try to not break things! One bonus of using gnu.bytecode: the class gnu.bytecode.dump is a direct clone on jcf-dump. (However, it doesn't have all the features of jcf-dump, and jcf-dump is fast and compact.) -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
inetlib
http://www.gnu.org/software/classpath/inetlib.html talks about inetlib. However, I don't see any links to download the code, nor any detailed (api or tutorial) documentation. The left sidebar has a Download link, but that only has links for downloading Classpath proper. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: ATTENTION: Prospect of merging HEAD with the generics branch
Andrew John Hughes wrote: Forwarded Message From: Per Bothner [EMAIL PROTECTED] To: GCC Mailing List gcc@gcc.gnu.org, [EMAIL PROTECTED] Subject: Re: GCC SC request about ecj Date: Fri, 02 Jun 2006 10:59:58 -0700 Richard stallman write last night: I agree to the use of the Eclipse front end to generate Java byte codes. Note this does not mean importing Eclispe code into the gcc source or release tree. We need to decide on a practical way to have people grab a compatible version of ecj. From the above e-mail, it looks as if gcj will shortly be linking in ecj as its front end. With this, gcj will be able to handle 1.5 constructs. Depends what you mean by linking. The plan is for the gcj driver to invoke ecj as a separate program, instead of currently invoking jc1. When compiling source to native, it would invoke ecj followed by jc1. I.e. ecj is not going to be linked into the same executable as other applications, though of course it will normally be linked in with libgcj or some other Free Classpath-base Java run-time. (For bootstrapping, people can use any working java.) -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: New OpenSource AWT/Swing Implementation by Intel
Michael Koch wrote: I would recommend not doing this. GPLv3 is not out. Our current license is not compatible with the ASLv2. We cannot combine the code currently. BTW tracking what lines in the code are licensed under ASL and what are licensed under GPL is not that easy. We don't want to merge in Intel's code *via* Harmony. But what we could do is talk *directly* to Intel, and ask if they're well to donate it to ClassPath *as well*. Or if not then dual-license it both Apache licenxse and GPL+exception. The latter would mean merging in a non-FSF-copyrighted code which should be cleared with the FSF. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Moving tools (Was: [cp-patches] FYI: Comitting the RMI daemod (RMID))
Dalibor Topic wrote: As for bytecode libraries, I'd prefer ASM, again since it seems to be already packaged by Debian, while oddly enough neither Kawa not gnu bytecode seem to be, so I'd go with the more ubiquitous option. Well, Kawa is packaged by Fedora 5 now ... There is no inherent reason why duplication is a problem - after all the standard Java libraries are chock-full of duplication: java.io vs nio; Java2 format vs Java 5 format; StringBuffer vs StringBuilder; collections framework vs lots of other things; sax vs dom vs stax; etc etc. I don't know ASM very well, but does seem to provide an elegant streaming model suitable for various transformation. It might also be a good for printing the content of class files - I don't know. (As a developer, I want something that allows me to print *all* the information in a class file, including constant pool, all the attributes, etc.) The strength of gnu.bytecode is code generation. I don't think any other framework comes close in terms of its combination of speed, low memory overhead. ease-of-use, ability to generate excellent code including debugging information, and other convenient features for compiler-writers. (As it should, since I depend on it for Kawa.) Now whether that justifies its inclusion in classpath-tools somebody else will have to judge. Mark Wirlaard wrote: And it seems we need very specific/altered versions of both (!). If there are classpath-specific patches in gnu.bytecode I would be happy to either merge them in or propose alternative solutions. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Where's the love?
Dalibor Topic wrote: The only way GNU Classpath would be acceptable for Apache Harmony, afaict from our dicussions in the past year, would be if the FSF contributed it to the ASF, and had the ASF manage the project, under the Apache license. Anything else is non-option for ASF, for a variety of reasons. Harmony appears to be basically an attempt at a hostile takeover of the Free Java movement. They're all in favor of cooperation - as long as it is 100% on their terms. Complete surrender is all they will accept. I hope I'm wrong, but nothing I've heard suggests otherwise. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Where's the love?
Dalibor Topic wrote: On Fri, Mar 10, 2006 at 12:20:02AM -0800, Per Bothner wrote: Harmony appears to be basically an attempt at a hostile takeover of the Free Java movement. They're all in favor of cooperation - as long as it is 100% on their terms. Complete surrender is all they will accept. I am sorry if I gave that impression, since that's not the way I experienced it. My impression was that the ASF simply has certain ways to do things, and does not want to change those, since their way basically works fine for them, and they don't think GNU Classpath is worth changing their ways of doing things, as apparently, that's all very tedious and so on. I wouldn't want to imply malice, where buerocratic inertia is a sufficient explanation. I used hostile takeover in the sense of a corporate takeover. Malice is usually not involved - just an unwillingness to negotiate with the old management and board. That seems to be descriptive. I think it goes beyond bureaucratic inertia. You agree that they seem to have no interest in co-operating with the rest of the Free Software movement, unless it is done on their terms. Rather like the attitude of the current US government to the rest of the world ... And of course there is the Orwellian name Harmony - reminds you of Ministry of Peace, doesn't it? -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Where's the love?
Brian Jones wrote: I don't really see the FSF backing down from the point of view that the users of free software should have the right to modify and release the software and Apache is unlikely to change either, as they have benefited enormously (in terms of brand at least) from letting anyone embed their software without having to divulge the source code to users. Huh? This is not the issue. Both licenses are compatible with the software being embedded/linked with non-Free code. So, given these things and my love for this project, I would really like the FSF to allow the developers to provide Classpath under an Apache compatible license in addition to the current licensing scheme, The FSF's hope is that GPL3 will be such a license. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: idl to java compiler:There is the IDL language description file under BSD. Can we use it?
Audrius Meskauskas wrote: There is the IDL language desciption for the JavaCC parser generator at https://javacc.dev.java.net/files/documents/17/2916/IDLjj, inside JavaCC project The license is not stated explicitly (also not stated in the file header), but the license of the whole javacc project is BSD. However, a lot of the javacc source files contain copyright notices that contradict it being Free Software. Arguably, the top-level license overrides, but the situation is a mess long ignored by javacc developers: https://javacc.dev.java.net/issues/show_bug.cgi?id=69 It seems javacc is very lackadaisical when it comes to licensing issues, so ClassPath (as a GNU project) needs to be very cautious about including javacc code. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: idl to java compiler:There is the IDL language description file under BSD. Can we use it?
Audrius Meskauskas wrote: It is a kind of not a very honest behavior, to put the BSD on the top and something incompatible in the file headers. I don't think it is dishonest - just sloppy. However, I complained about the problem a year ago, and they still released 4.0 without fixing it (or at least said they would), though said they'd work on fixing the problem for 4.1. Until this is fixed, I don't think jpackage or Fedora or Debian (for example) should be distributing javacc, unless they put it under non-free. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Next release
theUser BL wrote: I think the best wold be, if GNU Classpath 1.0 is 100% compatible to Java 1.4 and GNU Classpath 2.0 would be 100% compatible to Java 1.5. Why not take a lesson from Sun: Classpath 1.0 implements JDK 1.1 Classpath 2.0 implements Java 2 aka JDK 1.2 Classpath 3.0 implements JDK 1.3 (does anyone remember what was new in 1.3?) Classpath 4.0 imlements JDK 1.4 Classpath 5.0 implements Java 5 aka JDK 1.5 Classpath 6.0 implements Java 6 aka JDK 1.6 So we can release Classpath 1.0 now (after a little more testing) and Classpath 2.0 in half a year, maybe. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: GNU classpath contribution question
Ken Larson wrote: Let's say for example standard Java defines some constant like FileFormat.BINARY. The Javadoc does not specify the value of this constant. Actually, it probably does: http://java.sun.com/j2se/1.5.0/docs/api/constant-values.html -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: New native layer
Casey Marshall wrote: We have the responsibility, as contributors to a GNU project, to maintain the project for the GNU system. GNU is sorta-POSIX, as are a lot of other interesting platforms, and targeting them earns us, as free software contributors -- not necessarily other groups or companies that want to use Classpath -- a lot. I see these native portability layers as being counter to that goal, and they especially don't make sense given that there's no other free implementations for platforms other than what we are targeting. An alternative take with similar conclusion: There is a standard native portability layer. It is called Posix. There are multiple implementations of this layer available for MS-Windows. Other platforms we are likely to support (such as OS-X) already support Posix. I.e. there is no need for an extra portability layer. That is not to say we cannot add hooks and conditional compilation in modest doses to support Windows and other non-Posix platforms. But any extra indirection that hurts performance on Posix (even trivially), or anything that makes the code harder to maintain and understand is generally inappropriate. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Win CE port
Roman Kennke wrote: Hi there, Am Freitag, den 20.01.2006, 13:05 -0800 schrieb Per Bothner: Mark Wielaard wrote: Hi Phillipe, On Fri, 2006-01-20 at 15:03 +0100, Philippe Laporte wrote: It is our understanding that a GPL VM can't be freely redistributed in a commercial product. There should be no trouble at all freely redistributing such a thing in a commercial product. Just make sure you distribute the source code for it to your users. Just to clarify: Depends what you mean by it. If you mean the VM, that may not be enough, since in an embedded environment it is likely the VM is linked in with the commercial product. In that case you may also have to freely redistributing source for the commercial product. AFAICS this is true for the GPL, but not so with the GPL+linking exception under which GNU Classpath is distibuted. Maybe someone with more insight in the license (Mark? Dalibor?) could clarify this? Correct, but the comment was GPL VM. I assumed he was talking about a VM that was GPL'd - not the Classpath libraries - which do not include a VM. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Win CE port
Mark Wielaard wrote: Hi Phillipe, On Fri, 2006-01-20 at 15:03 +0100, Philippe Laporte wrote: It is our understanding that a GPL VM can't be freely redistributed in a commercial product. There should be no trouble at all freely redistributing such a thing in a commercial product. Just make sure you distribute the source code for it to your users. Just to clarify: Depends what you mean by it. If you mean the VM, that may not be enough, since in an embedded environment it is likely the VM is linked in with the commercial product. In that case you may also have to freely redistributing source for the commercial product. (Of course we know that Free (open-source) Software is not incompatible with it being commercial (i.e. for-profit) - but it is incompatible with it being proprietary (closed-source).) -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: hashCode question (was Re: Silly Java question)
Michael Barker wrote: Given that the toString() must be the same in order to be equal Huh? I don't believe there is any such requirement. One would normally expect toString to match for equal objects, but it is not required. Atter all, the default toString will not satisfy this requirement if equals has been redefined. And I often put in a sequence number in the toString result, for debugging. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: hashCode question (was Re: Silly Java question)
Michael Barker wrote: From the equals() code, its applicable in this case: // The toString output must match. if (! toString().equals(((KerberosPrincipal)that).toString())) return false; In your message you did phrase things in terms of general contracts. More to the point: Using toString in the implementation of equals seems like a bad idea. The only rationale I can think of is as a hack to try to catch that the actual classes match. But it seems an unreliable and inefficient method to do so. I'd go further: Implementing equals in terms of toString is a bug. One should be able to change toString before better output or debuggability without breaking equals. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: XML parsing problems
Chris Burdess wrote: As I understand it, the problem can occur when the position in the buffer is near the end. If the mark is set at position 2047 in the buffer, then we read 2 bytes and reset, then refill() will have been called and the position is actually reset to position 2047 in the new buffer, 2K further along in the original stream. ... If anyone has a robust solution to this problem please apply it; I will try to address it but may not have much free time before the new year/release. Three choices, assuming the mark is active and at position M in a buffer of size S: (1) Move S-M bytes to the start of the buffer and read upto M bytes. Advantage: doesn't need to grow the buffer. Disadvantage: we lose buffer alignment, which probably doesn't matter except with a highly tuned (an nio-based?) implementation. Also, can fail if the readAheadLimit S. (2) Grow the buffer to S+(S-M). Disadvantage: Same alignment issue as (1). (3) Use two buffers, one old and a new buffer. The old buffer doesn't need to be full-size, as long as it can handle the readAheadLimit (in the general case) or at least S-M in this case. Advantage: Preserves alignment. Disadvantage: More complex. After a reset, then a read(byte[],int, int) will only get S-M bytes. Assuming buffer alignment isn't an issue, then I'd say use a combination of (1) if possible and (2) if needed. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: lists.gnu.org and savannah.gnu.org (CVS) updates
Nic Ferrier wrote: Subversion seems to be another of those gnu vs apache things. gnu people *tend* to prefer CVS (and to a lesser extent arch) because they offer more centralized control. CVS is most popular because it is very stable and well understood. I think you're got things mixed up. Subversion is basically a better cvs, centralized in the same way, arch is oriented towards a more distributed setup. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: Graphics2D rewrite branch
David Gilbert wrote:
Regarding 3) and BufferedImages, I think I recall Sven saying he was
mistaken about the DataBuffer classes. As far as I could tell (from
writing some Mauve tests for them) they use real Java arrays.
It should be possible to have a hybrid implementation that can use
native buffers or Java arrays. If constructed using (say)
DataBufferInt(int size, int numBanks)
then it can allocated a native buffer.
The complicatation is getData and getBankData. If using native buffers,
these would have to allocate new buffers, copy the data of of the
native buffers, release the native buffers, and switch to using the
Java arrays for future references.
This isn't too bad if you're using CNI and a non-copying gc, since
you can use a native pointer in all cases, and just have the
natve pointer point into the Java arrray in the Java case.
If using a copying GC, you can use a delta. For simplicity, I
assume a single bank:
DataBufferInt {
int[] array;
native size_t offset;
int getElem(int i) { return *(int*)((char*) array + offset + 4 * i); }
DataBufferInt(int size) {
void* buf = allocate_native_buffer(size);
array = null;
offset = buf;
}
DataBufferInt(int[] arr) {
array = arr;
offset = SIZE_OF_ARRAY_HEADER;
}
int[] getData () {
int[] ar = new int[size];
copy_form_native_buffer_into(ar);
array = ar;
offset = SIZE_OF_ARRAY_HEADER;
}
}
This works even if the array is moved by the gc.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: Patches to java.util.zip by Christian Schlichtherle
Christian Schlichtherle wrote: More specifically, the size and compressed size field in the ZipEntry class are causing the problems as some comparisons are happening on these. The issue is that once a big integer equal or greater than 2*1024^3 and smaller than 4*1024^3 is stored into a Java int, it is hard to use this int as if it were unsigned. You would have to do something like this on an int (untested): ... This is way too much computational overhead To compare two unsigned ints just invert their sign bits: I.e. (using C syntax): unsigned int32 i, j; signed int32 is = (signed int32) i; signed int32 js = (signed int32) j; Then (i COMP j) if and only if ((signed int32) (is ^ 0x80) COMP (signed int32) (js 0x8000)). Which is probably faster than: ((long) (is 0x) COMP (long) (js 0x)) -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: String.equals optimisation
Stephen Crawley wrote: [EMAIL PROTECTED] said: I'd be interested to hear of other reasons for Java's requirement to intern all literal strings and constants. Backwards compatibility. At this point we can only conjecture as to why Java was originally defined this way. My guess is that this decision was made in the early days when the language was being targeted at embedded computing and machines with not a lot of memory. Having the JVM do interning of literals could save enough memory to matter. Er, no. String literals in JDK 1.0 were *not* interned. That was changed in JDK 1.1. The world has moved on, and nobody thinks much about conserving string space these days. I don't believe saving space was the motivation, but consistency. Assume: static String x = a; static String y = a; Then you had (x==y) if x and y were defined in the same class, but (x!=y) in they were defined in different classes. People expect that (a==a). -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[cp-patches] Re: Absolute URL parsing bug
Andrew Haley wrote:
The case that we get wrong is this one:
$ java TestURLs 'jar:file:/ejbjars/ws.jar!/META-INF/wsdl/ssbEndpoint.wsdl'
'jar:file:ejbjars/ws.jar!/META-INF/wsdl/ssbEndpoint.wsdl'
jar:file:ejbjars/ws.jar!/META-INF/wsdl/ssbEndpoint.wsdl
None of these are valid URLs as documented in the javadoc. It matches
the URI specification if you view everything after the scheme (i.e.
file:/ejbjars/ws.jar!/META-INF/wsdl/ssbEndpoint.wsdl) as an
'opaque_part'. There is no concept of a nested URL and jar:file: is
not a valid scheme.
$ gij TestURLs 'jar:file:/ejbjars/ws.jar!/META-INF/wsdl/ssbEndpoint.wsdl'
'jar:file:ejbjars/ws.jar!/META-INF/wsdl/ssbEndpoint.wsdl'
jar:file:/ejbjars/ws.jar!/META-INF/wsdl/file:ejbjars/ws.jar!/META-INF/wsdl/ssbEndpoint.wsdl
So, in that case the context should be ignored.
In fact, it seems like the context is ignored for all jar:file and file:
URLs:
We should ignore the context for *all* absolute URLs - i.e. any URL that
has a scheme - accordingto the URI spec. But the Javadoc doc URL(URL,
String) says If the scheme component is defined in the given spec and
does not match the scheme of the context, then the new URL is created as
an absolute URL based on the spec alone.I assume the and does not
match clause is documenting a hack (bug) in the implementation - which
doesn't match the URI spec. (Hacks like this may be one reason why they
decided to start from scratch with a new URI class.)
I.e. java TestURLs http:/a/b/c http:d/e
prints:
http:/a/b/d/e
but according to the RFC spec it should be:
http:d/e
The URI.resolve method gets this right.
A suggested (untested) fix might be something like:
int colon = spec.indexOf(':');
int slash = spec.indexOf('/');
if (colon 0
(colon slash || slash 0)
(protocol == null
|| protocol.length() = colon
|| ! protocol.equalsIgnoreCase(spec.substring(0, colon
context = null;
But in the case of a URL that is not qualified with any protocol at
all we need the context:
Er, no. See the 'TestURLs http:/a/b/c http:d/e' example.
$ java TestURLs 'jar:file:/ejbjars/ws.jar!/META-INF/wsdl/ssbEndpoint.wsdl' foo
jar:file:/ejbjars/ws.jar!/META-INF/wsdl/foo
Classpath gets that right too. So, the only thing we seem to get
wrong is the parsing of a 'jar:file:' URL when a 'jar:' context is
supplied.
Do you have any reason to believe that jar: or file: URLs get any
special treatment? I see none.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Re: Absolute URL parsing bug
Andrew Haley wrote: Per Bothner writes: Andrew Haley wrote: [ An absolute file URL can look like: absoluteURI = file : abs_path abs_path = / path_segments That is, there is no need for //. I don't see that in any of the specs. I got it from RFC 2396. Which I might have read wrongly, of course. I read more carefully. In practice, it looks like // is optional. I.e. file:///foo/bar is the same as file:/foo/bar. There is a subtle difference is the the former has an empty authority, while the latter has a missing (undefined) authority. Thus resolving the relative URIs /tmp/help vs //gcc.gnu.org/help against the base URI file://gnu.org/foo/ will yield file://gnu.org/foo/help vs file://gcc.gnu.org/foo/help respectively. In practice, people seldom use non-empty authority components with file: URIs and I'm not sure it's well-defined. Perhaps when using NFS? Technically, file:/tmp/foo.html is not a valid URI, as far as I can tell. I notice that firefox rewrites it (in the navigation bar) to file:///tmp/foo.html. Now in practice we may want to allow file:/tmp/foo.html, but it should be viewed as an unofficial short-hand for file:///tmp/foo.html. And indeed, the URL spec in the SDK docs says 'If the spec's path component begins with a slash character / then the path is treated as absolute...' ] The *path* is absolute, but the URI isn't. This matters when resolving a relative URL against a base URI, such as he URL of the containing document. If we have a base URI http://bar.com/baz/index.html; and a reference /tmp/foo.html then the resolved URI is http://bar.com/tmp/foo.html;. But we parse the spec looking for // to determine if a URL is absolute, A URL is absolute *only* if it has a scheme. I don't really understand what you're suggesting. My comments are mostly applicative to the URI class rather than the URL class. (I'm not sure why they're separate. I believe all URLs are URIs, accdoring to the IEFT, but not the Java class hierarchy.) The URI class has a bunch of methods like resolve and isAbsolute, which require more care about these fine points. Would it be OK to special-case file URIs so that file:/ is rewritten to file:/// ? Maybe for the URL class, but I don't think so for the URI class. The difference is the getAuthority method. My reading is that it should return null for file:/ and for file:///. But I haven't tested what JDK does - and it wouldn't surprise me if the URI and URL classes are different in this respect. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Re: Absolute URL parsing bug
Andrew Haley wrote: This URL is an absolute URL because its path begins with a /: jar:file:/usr/src/redhat/BUILD/jonas-4.3.3/jonas/output/JONAS_4_3_3/examples/webservices/beans/ws/temp/ejbjars/ws.jar!/META-INF/wsdl/ssbEndpoint.wsdl [ An absolute file URL can look like: absoluteURI = file : abs_path abs_path = / path_segments That is, there is no need for //. I don't see that in any of the specs. Technically, file:/tmp/foo.html is not a valid URI, as far as I can tell. I notice that firefox rewrites it (in the navigation bar) to file:///tmp/foo.html. Now in practice we may want to allow file:/tmp/foo.html, but it should be viewed as an unofficial short-hand for file:///tmp/foo.html. And indeed, the URL spec in the SDK docs says 'If the spec's path component begins with a slash character / then the path is treated as absolute...' ] The *path* is absolute, but the URI isn't. This matters when resolving a relative URL against a base URI, such as he URL of the containing document. If we have a base URI http://bar.com/baz/index.html; and a reference /tmp/foo.html then the resolved URI is http://bar.com/tmp/foo.html;. But we parse the spec looking for // to determine if a URL is absolute, A URL is absolute *only* if it has a scheme. ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
An Eclispe style for GNU
Here is my attempt at expressing the GNU Java formatting style in Eclipse. This is tested in Eclipse 3.1M7. Perhaps we can develop this into a standard GNU/Classpath format - and perhaps have it shipped with Eclipse. I'm not endorsing this as my *preferred* formatting style, but as a modest encoding and fine-tuning of existing styles. (I still mostly use Emacs.) -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ?xml version=1.0 encoding=UTF-8? profiles version=8 profile name=GNU version=8 setting id=org.eclipse.jdt.core.formatter.align_type_members_on_columns value=false/ setting id=org.eclipse.jdt.core.formatter.alignment_for_arguments_in_allocation_expression value=18/ setting id=org.eclipse.jdt.core.formatter.alignment_for_arguments_in_enum_constant value=16/ setting id=org.eclipse.jdt.core.formatter.alignment_for_arguments_in_explicit_constructor_call value=18/ setting id=org.eclipse.jdt.core.formatter.alignment_for_arguments_in_method_invocation value=18/ setting id=org.eclipse.jdt.core.formatter.alignment_for_arguments_in_qualified_allocation_expression value=16/ setting id=org.eclipse.jdt.core.formatter.alignment_for_binary_expression value=16/ setting id=org.eclipse.jdt.core.formatter.alignment_for_compact_if value=20/ setting id=org.eclipse.jdt.core.formatter.alignment_for_conditional_expression value=48/ setting id=org.eclipse.jdt.core.formatter.alignment_for_enum_constants value=0/ setting id=org.eclipse.jdt.core.formatter.alignment_for_expressions_in_array_initializer value=16/ setting id=org.eclipse.jdt.core.formatter.alignment_for_multiple_fields value=16/ setting id=org.eclipse.jdt.core.formatter.alignment_for_parameters_in_constructor_declaration value=16/ setting id=org.eclipse.jdt.core.formatter.alignment_for_parameters_in_method_declaration value=16/ setting id=org.eclipse.jdt.core.formatter.alignment_for_selector_in_method_invocation value=16/ setting id=org.eclipse.jdt.core.formatter.alignment_for_superclass_in_type_declaration value=16/ setting id=org.eclipse.jdt.core.formatter.alignment_for_superinterfaces_in_enum_declaration value=16/ setting id=org.eclipse.jdt.core.formatter.alignment_for_superinterfaces_in_type_declaration value=64/ setting id=org.eclipse.jdt.core.formatter.alignment_for_throws_clause_in_constructor_declaration value=16/ setting id=org.eclipse.jdt.core.formatter.alignment_for_throws_clause_in_method_declaration value=16/ setting id=org.eclipse.jdt.core.formatter.blank_lines_after_imports value=1/ setting id=org.eclipse.jdt.core.formatter.blank_lines_after_package value=0/ setting id=org.eclipse.jdt.core.formatter.blank_lines_before_field value=0/ setting id=org.eclipse.jdt.core.formatter.blank_lines_before_first_class_body_declaration value=0/ setting id=org.eclipse.jdt.core.formatter.blank_lines_before_imports value=0/ setting id=org.eclipse.jdt.core.formatter.blank_lines_before_member_type value=0/ setting id=org.eclipse.jdt.core.formatter.blank_lines_before_method value=1/ setting id=org.eclipse.jdt.core.formatter.blank_lines_before_new_chunk value=1/ setting id=org.eclipse.jdt.core.formatter.blank_lines_before_package value=0/ setting id=org.eclipse.jdt.core.formatter.blank_lines_between_type_declarations value=1/ setting id=org.eclipse.jdt.core.formatter.brace_position_for_annotation_type_declaration value=end_of_line/ setting id=org.eclipse.jdt.core.formatter.brace_position_for_anonymous_type_declaration value=next_line/ setting id=org.eclipse.jdt.core.formatter.brace_position_for_array_initializer value=end_of_line/ setting id=org.eclipse.jdt.core.formatter.brace_position_for_block value=next_line_shifted/ setting id=org.eclipse.jdt.core.formatter.brace_position_for_block_in_case value=next_line_shifted/ setting id=org.eclipse.jdt.core.formatter.brace_position_for_constructor_declaration value=next_line/ setting id=org.eclipse.jdt.core.formatter.brace_position_for_enum_constant value=next_line/ setting id=org.eclipse.jdt.core.formatter.brace_position_for_enum_declaration value=next_line/ setting id=org.eclipse.jdt.core.formatter.brace_position_for_method_declaration value=next_line/ setting id=org.eclipse.jdt.core.formatter.brace_position_for_switch value=next_line_shifted/ setting id=org.eclipse.jdt.core.formatter.brace_position_for_type_declaration value=next_line/ setting id=org.eclipse.jdt.core.formatter.comment.clear_blank_lines value=true/ setting id=org.eclipse.jdt.core.formatter.comment.format_comments value=false/ setting id=org.eclipse.jdt.core.formatter.comment.format_header value=false/ setting id=org.eclipse.jdt.core.formatter.comment.format_html value=true/ setting id=org.eclipse.jdt.core.formatter.comment.format_source_code value=true/ setting id=org.eclipse.jdt.core.formatter.comment.indent_parameter_description value=false/ setting id=org.eclipse.jdt.core.formatter.comment.indent_root_tags value=false/ setting id=org.eclipse.jdt.core.formatter.comment.insert_new_line_before_root_tags value=do not insert/ setting id
Re: XML strictness
Robert Schuster wrote: You get the same message with all proprietary JDKs prior to 1.5 . The latest incarnation however accepts creating the new node and generates the following XML upon calling 'echo a/ | /opt/sun-jdk-1.5.0/bin/java xmlfilter.XMLFilter': ?xml version=1.0 encoding=iso-8859-1? a/ new/ AFAIK there should/must be only one top-level node which is named xml. I am confused ... Is Sun breaking the rules here? Depends on which set of rules. The XQuery 1.0 and XPath 2.0 Data Model is a bit more general: See http://www.w3.org/TR/xpath-datamodel/#DocumentNode Of course an *XML document* is somewhat more restricted, but if you want to use DOM to support XQuery/XPath/XSLT objects it makes sense to allow more generality. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Free jsr reference implementations?
I just got off the phone with the spec lead (Mike Grogan) for JSR 223, which I've been a litle bit involved with. We'd like to find a way to license the Reference Implementation under an acceptable classpath-compatible license. Some Prior Art may be helpful in convincing the Sun powers-that-be. * Which existing JSR have classpath-compatible RIs? Maybe JAXP? * Which of these, if any, are shipped as part of J2SE or J2EE? * Which of these, if any, have Sun as the Spec Lead? My understanding is Doug Lea worked hard on getting the new concurrency framework Free, but didn't quite manage it. It might be useful to get his story too. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: benchmarks (was Re: Progress on a Classpath mauve suite?)
David P Grove wrote: I think you need to understand the point of the benchmark suite. The whole goal is reproducible science, so if someone doesn't cite the exact version of the benchmarks, then it isn't useful (in an academic sense). That can be achieved without the DaCapo restrictions. For example TeX has fairly strict requirements on naming and versioning. But DaCapo license is extremely restrictive. It's not clear that a company could use DaCapo to benchmark their products - even open-source products, since that might be defined as for-profit. Forbidding one to alter, modify, improve, decompile, disassemble or otherwise reverse-engineer has nothing to do with reproducible science, and in fact is contrary to acadmic openness and reproducible sciece. The license forces that plus proper academic credit (ie a citation) for the benchmark suite, which personally I think is quite fair given how much work was put into putting it together (much more than the typical academic paper). A requirement for credit isn't inherently incompatible with Free Software: The old BSD license with the notorious advertising clause may have been awkward and GPL-incompatible, but it was accepted as Free. I know some of the people who put together the benchmark suite fairly well and it was a massive effort (think person-years, not person-weeks; good, usable, portable, benchmark suites are a lot of work). It would be a shame if your politics prevented you from using it, but that's life I suppose. You're rather missing the point, methinks. I know some of the people at Redmond who've spent person-decades to put together quite a nice operating system. I also know some people in Santa Clara who've spent person-decades putting together a very nice Java implementation. It's a shame that politics are preventing us from using either. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: javax.swing.text.rtf.RTFEditorKit
Dalibor Topic wrote: Their licensing on JavaCC seems to be all over the place, really. I reported this as an issue: https://javacc.dev.java.net/issues/show_bug.cgi?id=69 No response of any kind. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: OT: Eclipse Additions
Tom Tromey wrote: * Make sure code formatting can complete handle Classpath's style. In 3.0 this wasn't true. 3.1M4 looked better here, but perhaps not perfect (I didn't try exhaustively). Not only that, but add a pre-defined GNU formatting style. So you just select that in your preferences, and you don't have to manually tweak dozens of options. Until that is done, we can have a standard GNU Java style template that that people can import, but it's better to have it be builtin. The biggest reason (besids convenience) is that it is easier to update the the style; contra-wise, it's probably easier to update the Eclipse formatting engine and not have it break the GNU style, since you can add new style options to a builtin style without breaking things. We might consider deprecating using of tabs, since they cause portability problems: people using Windows IDEs are used to one indentation level = one tab stop and then setting the display width of a tab as a personal display preference. The way we indent using a mix of tabs and spaces isn't compatible with this model. Perhaps there should be two stanadrd GNU styles: GNU, with tabs and GNU, without tabs. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: OT: Eclipse Additions
Andrew Overholt wrote: Now comes the fun part: making Eclipse better for your needs. One problem I have is using Eclipse in a project with complex dependencies, which needs Ant (or make). E.g. generated source files or where one tool must be built before other parts are built. I'm thinking specifically of Kawa (http://www.gnu.org/software/kawa) development. This build a compiler, which is then used to compile files in Scheme to .class files, and they're all part of the resulting run-time environment and distributed as a single jar. Of course I know Eclipse as a lot of Ant support, but it seems to be separate sub-system, not integrated into the default build action. The problem may be with my lack of understanding, or how I've set things up, but what I seem to need is a Java Ant project: when I edit a file, and it wants to rebuild, it should use the Ant dependencies; not just try to willy-nilly do the equivalent of javac `find . -name '*.java'` Compiler messages compiling via Ant should be handled smoothly, the same way they are done when building without Ant. Etc. When Eclipse creates a Java project, and it sees a top-level build.xml, it should (after asking) Do The Right Thing to set up a Java Ant-based project rather than a plain Java project. If I'm doing things wrong, I'd very much appreciate a cookbook for how this is supposed to be done. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: OT: Eclipse Additions
Archie Cobbs wrote: 3. No newline at end of file. The XML editor seems to forget to put newlines at the end of files. This causes unnecessary repository differences with the ugly No newline at end of file message. (vi always adds a newline). This may have gotten fixed, at least for Java. I haven't tested M5a yet. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=68506 (Though this bug was about the formatter, not the editor.) -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
David Daney wrote: How would a bug be marked that is fixed in libgcj and not fixed in classpath? It sounds a bit questionable to merge the bug tracking system before we have a single merged code base. Maybe we shuld treat libgcj and classpath as branches of a common virtual repository. This does not necessaily mean using the same cvs (or snv) repository, though that is an option. It does mean marking bugs in bugzilla in as *if* they were branches. It would require thinking about naming convention for target milestones etc. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Eclipse command line formatter
Tom Tromey wrote:
What we really need to do is make sure we can really handle Classpath
style. With Eclipse 3.0 I think we fail to re-indent inside a block,
so we end up with:
if (foo)
{
code here;
}
Instead of:
if (foo)
{
code here;
}
I think this is fixed.
However, note that Eclipse up to 3.1M4 does not handle the GNU/Unix
conventions for tabs: Using 8-column tabs, but indenting by a different
amount. 3.1M4 is actually a regression in this respect.
I reported a bug/enhancement request, and in the last few days Tom
Eicher posted some patches:
htts://bugs.eclipse.org/bugs/show_bug.cgi?id=73104
Hopefully we'll have something usable soon.
I also suggest we submit a standard GNU coding style, and ask them
to include it as a standard formatting style.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: Eclipse
Tom Tromey wrote: In fact, I think a release that is compatible with just JDK 1.0 is kind of laughable at this date. I agree. If complete-TCK-passing compatibility with something is desirable, at least go for 1.1.x, since that matches what MS used to ship (except for evil extensions, of course), and since we already implement most (all?) of what 1.1 added. I suspect the main thing missing at this point is a dependable security implementation, including the verifier and the SecurityManager, most of which realy isn't Classpath per se. (On the other hand, if Tom's new verifier can share code between the gcj compiler and runtime, maybe it can be parameterized further so it can be plugged into other VMs?) -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: clickthrough license
David Holmes wrote: The JCP also doesn't require the (final) specifications to be provided under a click-wrap. Being involved in this at present with another JSR I can assure you that the JCP does require a click-through license for downloading specs. I'm not saying you're wrong, but I think it would be useful if you could point to a specific document that states such a requriement. Notice also that the JCP and related agreement/processes ahve changed over the years. I don't believe that not saying the Java word when describing what GNU Classpath is lets you off the hook here. If nothing else the classes and API's in the java* namespaces would fall under Sun's copyright. You mean Sun's trademark, not copyright, of course. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: clickthrough license
David Holmes wrote: I should said PMO rather than JCP. The JCP document itself doesn't cover this, however the PMO seems to require it. If you look at the Spec lead Guide on jcp.org you'll see that for Proposed Final Draft The PMO will provide the spec license ... and then for Final Approval Ballot The PMO hosts the Final Approval Ballot for you, and uses Sun's general FCS license unless you provide your own FCS license.. On other words, the specification licenses are provided by the PMO not the JCP itself. (Note that the specification license is distinct from the RI and TCK licenses.) You'd need to contact the PMO directly to clarify this and to see what possible licenses exist. You're quoting from a section on the Proposed Final Draft. It is not unreasonable that the draft would have a more restrictive license than the actual final spec. However, the final release does say the spec must be set up with a click-through license. However, I'm sure Spec Leads can pick their license terms, at least within certain limits. And some JSRs are open-source, at least the implementation. But JCP is all very complicated, with a huge amount of process, and I can't pretend to what extent Classpath might have problems. I don't believe that not saying the Java word when describing what GNU Classpath is lets you off the hook here. If nothing else the classes and API's in the java* namespaces would fall under Sun's copyright. You mean Sun's trademark, not copyright, of course. I do? The API's are not as far as I am aware trademarked. It seems to me that defining a set of API's that match Sun's Java API's would be copying them - hence infringing on copyright. Implementing a specification is *not* copying the specification. However, I assume (as a non-lawyer) that copyright law does allow Sun to place restrictions on downloading/reading (i.e. copying) the specification, and hence there is a specification license. Interpreting the license is I understand more an issue of contract law than of copyright law. If you don't read the official specification and haven't agreed to the license, then you can implement whatever you want without concern about Sun's copyright, assuming you use public documents, such as books and magazine articles. However, avoiding the official Sun-licensed specification doesn't protect you from patent or trademark issues. And Sun has trademarked Java, so if you implement a class called java.lang.String then you could conceivably be infringing on Sun's trademark. That's why I believe Sun's trademarks and patents are a more fundamental concern that the copyright. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: bug 10491 was Re: More astonishing progress in japi scores
Sven de Marothy wrote: Actually.. That's where the bug was! :-) strtod (by ANSI C99) should handle Infinity and NaN. The problem is the #ifdef on lines 268-273: #ifdef KISSME_LINUX_USER val = strtod (p, endptr); #else val = _strtod_r (reent, p, endptr); #endif The former calls the standard library strtod function, the latter calls the included fdlibm function. This appears to be an redundant construct. I don't quite see the reason here for using the fdlibm strtod. So the fix for this would be to just replace this with: val = strtod (p, endptr); This works. Of course, this might not work on every C compiler. But it does work with gcc. The general reason for the _r forms of various functions is that the non-_r forms aren't reentrant - i.e. threadsafe. I don'tknow why/if that is an issue for strtod. That other issue is that system strtod may not be accurate. Note that parseDouble is required to return the *closest* double. This is a difficult requirement to meet, and cannot be done by simple (i.e. traditional) implementations. If the strtod in glibc is threadsafe *and* accurate, then we should probably use it, at least as a default. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: bug 10491 was Re: More astonishing progress in japi scores
Archie Cobbs wrote: Sven de Marothy wrote: If the strtod in glibc is threadsafe *and* accurate, then we should probably use it, at least as a default. Dalibor Topic said on IRC that it has some problems on Irix. So it might not be a good idea. So perhaps adding a special case would be best, or you could solve it upstream by adding support for NaN and infinity to newlib. Not everybody uses Linux, so what glibc does is not entirely relevant.. glibc is the *GNU* C library, so it's obviously not Linux-specific. Classpath is the *GNU* Java library, so it isn't unreasonable to optimize for the glibc case. If on non-glibc platforms floating-point conversion isn't quite as exact as the spec requires, fixing that is not a priority. Of course if somebody wants to work on a more portable solution, that is great, as lang as it doesn't penalize the glibc case. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: clickthrough license
Mark Wielaard wrote: Programmers will use published books or publicly published articles to write their programs, so we better make sure we are at least compatible with what they use/expect. Programmers will use Sun's JavaDoc-generated API documents. If anyone reports a bug, that is what they will refer to. It is pretty clear. Use public documentation, which doesn't need you to consent to any additional click-through terms, as primary source when working on GNU Classpath, preferably books. There is often no such documentation. Most book are tutorial, not reference works that are anywhere close to comprehensive, or are out of date. There is one Swing book I know (O'Reilly's) that attempts to cover the APIs systematicaly, for example, but even it is surely insufficient for a useful independent implementation. Sun's documentation license for 1.5 is quite unclear in what it covers. For example a literal reading seems to prohibit writing books or articles about the JDK. (It is neither developing application or an independent implementation.) In that case, is it safe to depend on books and articles that may be the result of unpermitted actions? It seems to me the license restricts how you use and distribute the specification itself. However, it cannot as a matter of copyright law restrict the ideas or concepts of the specification, or prevent us from learning from it. It could make such restrictions under trade secret law, but it would be nonsense to claim as a trade secret something freely available on the web. So the real concerns are any patents Sun may have, plus the trademarks Sun may have. But none of those are affected by whether or not we read Sun's specifications. Of course I would like a lawyer (and specifically Eben Moglen) to evaluate this analysis. Perhaps I'm wrong in dismising the specification as a trade secret, for example. FSF Legal will always advise not to take any unnessecary risks that might endanger the (perceived) free software status of a GNU project. Right, but even if reading the specification is a risk, I suspect it falls into the necessary category. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: redundant field initializers
Mark Wielaard wrote:
Why would a compiler emit extra initialization code for default values
for fields? Not that I object to removing them, but it looks like the
compiler emits unnecessary code in this case.
One can construct torture cases where the semantics are different, for
both static and instance fields, if some code change the field value
before the initialization is assigned.
For exmple:
class Z {
static int peek() { return j++; }
static int i = peek();
static int j = 0;
}
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
Re: Working On Classpath
Thomas Fitzsimmons wrote: Modified versions of ant and tomcat that work with GCJ are available from the RHUG project: They are now also Fedora (http://fedora.redhat.com/) - if you install everything in Fedora Core, you get a bunch of Java packages, with .jar files, documentation, and gcj-compiled .so files. I'd like to make a compatible kawa-NNN.rpm ... -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
Anthony Green wrote: I did an exotic port, and this was my solution (which I still think is a good idea!): http://mail.gnu.org/archive/html/classpath/2003-04/msg00092.html which says: My basic plan is to move all of these package private methods to a new abstract class called gnu.java.io.PlatformFileDescriptor (for lack of a better name). java.io.FileDescriptor will have one new package private method for returning the PlatformFileDescriptor associated with that FileDescriptor. One of the advantages of the new FileChannel-based implementation is that we no longer need a separate PlatformFileDescriptor. The FileChannelImpl serves that need, without the need for an extra object and extra indirection. Right now FileChannelImpl is not sub-classed, but it would be perfectly reasonable and a minor change to use implementation-specific FileChannel[Impl] classes. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
Steven Augart wrote: Michael Koch wrote: What if someone wants to port GNU classpath to an Operating System with totally different semantics like Windows ? If someone does that kind of port, he'll have more problems than just than the size of a file descriptor. I think Michael was being ironic. I haven't checked the current Classpath, libcj (which shares most of its code with Classpath) certainly supports Windows. I think the cleanest solution is to allows FileChannelImpl to be subclassed, or to uses different classes that implement FileChannel. But the current code works fine for now. For JNI performance I don't see any reason not to not to have the Java code pass the native fd field to the native method - just realize that if/when Classpath gets ported to a system that uses 64 pointers we may have to redo things. One solution may be to use the Posix API. The Posix IO functions (open/read/write etc) are available on Windows. I don't know why they're not used - performance? -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Etienne Gagnon wrote: I am starting to have difficulty understanding Classpath's goals and motivations. When I proposed to add to Classpath some mechanism to allow it to be customized to each VM, I was told that it would be a heresy to encode any VM-specific thing into Classpath, as the vision was: a single Classpath installation would be shared by many VMs on a single system, e.g. common class libraries, common JNI libraries, etc. Now, what you are proposing is that JNI libraries would be compiled specifically for each VM. What have I missed? That I do not speak for Classpath, and that different people have different goals and opinions. Personally, I don't see much point in common class libraries, common JNI libraries. It might be neat, but: (a) it complicates getting good performance, and (b) coordinating Classpath and VM releses would be too difficult. Yes, it's more elegant to install a single copy of Classpath, but GCJ is not going to use the system installation of Classpath, and I wouldn't expect others to do so either. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath build process and VM-specific issues
Jeroen Frijters wrote:
That's why I'm very much in favor of using RawData. ...
public abstract class RawData {}
public final class RawData32 extends RawData
{
private int pointer;
}
public final class RawData64 extends RawData
{
private long pointer;
}
All the Java code would ever see are RawData references, but the JNI
layer knows that all RawData references are actually 32 or 64 bit (or
whatever that platform requires).
But this is a completely different model than the CNI RawData,
since you're adding an extra layer of indirection.
In CNI, a RawData is not an object that *contains* a pointer;
the pointer is the RawData reference itself.
I.e.
inline void* RawData_to_pointer (RawData *rd)
{
return (void*) (rd);
}
*not*
inline void* RawData_to_pointer (RawData *rd)
{
return (void*) (rd-pointer);
}
Adding the extra indirection seems like a bad idea to me.
I'd rather use jlong. But I don't see any real reason not to
use RawData. I can see on a few JVMs it may cause problems,
but they can easily sed the source to convert RawData to long.
Just think of RawData has a macro.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [Article] Sun Fires Back over Open Source Java Accusations
Tom Tromey wrote: IMO, while it would be helpful if Sun opened their source, we don't really need it. On the other hand, I'm sure Red Hat would rather spend their development resources on *not* having to re-implement Swing, or all the new features of JDK 1.5 ... It seems a waste to duplicate Sun's work, but of course Sun is under no obligation to us. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: JIT pluggability (ABI Issues)
Patrik Reali wrote: Calling Convention * left-to-right (as in java) or right-to-left (as in C) Huh? Argument evaluation order is not really part of the ABI. C has *unspecified* evaluation order, so many implementations have evaluated them right-to-left because that's the way the stack grows (on most C implementations). But this is less relevant with optimizing compilers and register-based calling conventions. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
PATCH for Date.parse
One of the Kawa tests was failing because our implementation of
Date.parse was buggy. A sensible person might have changed the
testcase (since it was just to test calling static Java methods from
Scheme).
Alas, I'm not a sensible person, so I fixed Date.java instead. There were
a number of problems with it. There are almost certainly still bugs in it,
but now it shouldn't fail quite so easily.
I checked the attached patch into libjava.
It should also go into Classpath.
I also have a Mauve test case.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
2004-01-03 Per Bothner [EMAIL PROTECTED]
* java/util/Date.java (parse): Fix a number of problems.
(skipParens): Remove no-longer-needed method.
Index: Date.java
===
RCS file: /cvs/gcc/gcc/libjava/java/util/Date.java,v
retrieving revision 1.11
diff -u -r1.11 Date.java
--- Date.java 24 Mar 2003 13:56:57 - 1.11
+++ Date.java 4 Jan 2004 00:27:05 -
@@ -304,34 +304,6 @@
return format.format(this);
}
- private static int skipParens(String string, int offset)
- {
-int len = string.length();
-int p = 0;
-int i;
-
-for (i = offset; i len; ++i)
- {
- if (string.charAt(i) == '(')
- ++p;
- else if (string.charAt(i) == ')')
- {
- --p;
- if (p == 0)
- return i + 1;
- // If we've encounted unbalanced parens, just return the
- // leftover one as an ordinary character. It will be
- // caught later in parsing and cause an
- // IllegalArgumentException.
- if (p 0)
- return i;
- }
- }
-
-// Not sure what to do if `p != 0' here.
-return i;
- }
-
private static int parseTz(String tok, char sign)
throws IllegalArgumentException
{
@@ -408,20 +380,25 @@
// Trim out any nested stuff in parentheses now to make parsing easier.
StringBuffer buf = new StringBuffer();
-int off = 0;
-int openParenOffset, tmpMonth;
-while ((openParenOffset = string.indexOf('(', off)) = 0)
+int parenNesting = 0;
+int len = string.length();
+for (int i = 0; i len; i++)
{
- // Copy part of string leading up to open paren.
- buf.append(string.substring(off, openParenOffset));
- off = skipParens(string, openParenOffset);
+ char ch = string.charAt(i);
+ if (ch = 'a' ch = 'z')
+ ch -= 'a' - 'A';
+ if (ch == '(')
+ parenNesting++;
+ else if (parenNesting == 0)
+ buf.append(ch);
+ else if (ch == ')')
+ parenNesting--;
}
-buf.append(string.substring(off));
+int tmpMonth;
// Make all chars upper case to simplify comparisons later.
// Also ignore commas; treat them as delimiters.
-StringTokenizer strtok =
- new StringTokenizer(buf.toString().toUpperCase(), \t\n\r,);
+StringTokenizer strtok = new StringTokenizer(buf.toString(), \t\n\r,);
while (strtok.hasMoreTokens())
{
@@ -436,56 +413,59 @@
{
while (tok != null tok.length() 0)
{
- // A colon or slash may be valid in the number.
- // Find the first of these before calling parseInt.
- int colon = tok.indexOf(':');
- int slash = tok.indexOf('/');
- int hyphen = tok.indexOf('-');
- // We choose tok.length initially because it makes
- // processing simpler.
- int punctOffset = tok.length();
- if (colon = 0)
- punctOffset = Math.min(punctOffset, colon);
- if (slash = 0)
- punctOffset = Math.min(punctOffset, slash);
- if (hyphen = 0)
- punctOffset = Math.min(punctOffset, hyphen);
- // Following code relies on -1 being the exceptional
- // case.
- if (punctOffset == tok.length())
- punctOffset = -1;
-
- int num;
- try
- {
- num = Integer.parseInt(punctOffset 0 ? tok :
- tok.substring(0, punctOffset));
- }
- catch (NumberFormatException ex)
- {
- throw new IllegalArgumentException(tok);
- }
-
- // TBD: Spec says year can be followed by a slash. That might
- // make sense if using YY/MM/DD formats, but it would fail in
- // that format for years = 70. Also, what about 1900? That
- // is interpreted as the year 3800; seems that the comparison
- // should be num = 1900 rather than just 1900.
- // What about a year of 62 - 70? (61 or less could be a (leap)
- // second). 70/MM/DD cause an exception but 71/MM/DD is ok
Re: [Little Off Topic] Revolution is on ;)
Arnaud Vandyck wrote: Tom Tromey GCJ is a free Java front end for EGCS. This new front end is integrated into the EGCS project. EGCS? New front end? Tom, you're living in the past ... -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: new jalopy available
David P Grove wrote: It also creates a minor annoyance when you get patches from users that created them in an ide where spaces per tab is often set equal to indent level. This seems to be common in the Windows world. It has the advantage that you can adjust indentation width according to personal preference by changing a display parameter (the tab width) without changing any source files. Unfortunately, it's incompatible with the Unix tab-is-8-column standard. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: org.omg link on Classpath homepage
Stuart Ballard wrote: b) If they are free but aren't GPL-compatible, shouldn't there be a prominent warning because (if I understand the issues correctly) that would make anything that's simultaneously a derived work of Classpath and the org.omg packages completely unredistributable? I don't think so. Classpath uses GPL+exception and can be linked with proprietary applications. So someone could almost certainly distribute Classpath + org.omg. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Jeroen Frijters wrote: I'm certainly not throwing in the towel ;-) I think it should be an error, but I can live with NYIException being an Exception, what I cannot accept is (ab)using UnsupportedOperationException. I still don't see any real problem with UnsupportedOperationException, but I don't care that much. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
David Holmes wrote: Seems to me that this is a RuntimeException then. Only an application that is being written for Classpath will be able to take alternative action if core functionality is missing. Any other application will just have to throw up its hands. On the other hand, if the exception is UnsupportedOperationException then it is possible for a portable application to try an alternative approach - which may work. If the exception is a new class, then that is not possible. If it doesn't catch it, then nothing is lost. It should *NOT* be a subclass of an existing exception type that has well defined semantics and is likely to be caught in general applications - like UnsupportedOperationException. I agree with Jeroen that not being implemented when it should be, is quite distinct from not supporting an optional operation. The latter is true, but the former does not follow. I think creating a new non-portable sub-class is solving a non-existent problem. But more important is throwing *some* exception. We *must* fix the current situation where unimplemented methods silently do nothing or return null. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
David Holmes wrote: - UnsupportedOperationException + semantically close in meaning + allows simple use of try/catch in portable programs - not uniquely defining ie grepping for it will give false results The proposal from March takes care of this: throw new UnsupportedOperationException(not implemented[ - optional reason]); This makes grep easy. + No new classes needed. + No dependency on non-standard classes. I.e. somebody can contribute an incomplete implementation of a class that without having to depend on ClassPath. - NYIException + semantically exact in meaning True. However to what extent is this useful? -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
We discussed this in March, and there was agreement that we should use use UnsupportedOperationException. See http://gcc.gnu.org/ml/java/2003-03/msg00016.html -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Michael Koch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 26. September 2003 19:29 schrieb Per Bothner: We discussed this in March, and there was agreement that we should use use UnsupportedOperationException. See http://gcc.gnu.org/ml/java/2003-03/msg00016.html Its never too late to rethink something. But unless one is aware of previous discussion (and even if one is), much time may be wasted. So far I haven't seen any reason why we need to re-consider the previous consensus. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath 0.06 created
Mark Wielaard wrote: Although I don't have access yet to alpha.gnu.org to publish the release I have already created the 0.06 release tarball. I also tagged the CVS tree as 'classpath-0_06-release'. You don't put releases on alpha.gnu.org - you put them on ftp.gnu.org. You can put pre-releases on alpha.gnu.org, but if you already have a release there seems little point. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath 0.06 created
Mark Wielaard wrote: My thinking was that the 0.0x releases are actually the pre-releases while we work towards the first real GNU Classpath 1.0 release. People can combine these pre-releases with their own VMs like gcj, kissme, jikesRVM, Jaos, etc already do. But as long as we don't have at least a minimum of functionality to offer (we are hoping that 1.0 will have the equivalent functionality as core libraries that come with some proprietary 1.1 JDKs) and a stable/maintainable VM interface we cannot call it a real release. If you've created a cvs tag, and given it a real version number, I'd call it a release, even if it's not a 1.0 relase. alpha.gnu.org has outlived its usefulness (evidenced by the fact that it is little used) now that alpha code is available in CVS for most projects. Note that alpha.gnu.org is not mirrored the way ftp.gnu.org is. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath Linuxtag meeting minutes
Mark Wielaard wrote: - We should have a standard NotYetImplementedException. Just returning something random (like null) from stubs is really not acceptable. Kaffe for example has one. In the gcj list I suggested UnsupportedOperationException, with a refinement: throw new UnsupportedOperationException (REASON); where REASON is a string literal that includes not implemented and all on a single line (to make it easy to grep for). See http://gcc.gnu.org/ml/java/2003-03/msg00016.html -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: javax.swing.plaf; next steps
Sascha Brawer wrote: For all text-editing, including a simple JTextField, we need a working implementation of javax.swing.text. This is a hairy beast, but it would be quite interesting to do, and very useful for other applications. I have a gnu.lists.CharBuffer and a gnu.jemacs.swing.BufferContent class. The latter implements javax.swing.text.AbstractDocument.Content. These are used in the JEmacs implementation that comes with Kawa. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Want to help in integrating swing. Really last question.
Brian Jones wrote: Clemens Eisserer [EMAIL PROTECTED] writes: Ey Clemens, do you have some shared webspace somewhere? Want to work together on this? Otherwise we'd be working in parallel on the same areas: waste of time. Hmmm, what do you think about soureforge? Btw, you can have access to Classpath's CVS after we've taken care of assignment paperwork. How does that sound? We want to avoid sourceforge, especially for GNU projects. Better to use savannah.gnu.org (not just for GNU projects). Btw, you can have access to Classpath's CVS after we've taken care of assignment paperwork. How does that sound? Which sounds like the best solution. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: More finalize woes
Stephen Crawley wrote: I'd say yes. A compiler cannot know what the target VM's implementation of java.lang.Object.finalize() does, and hence whether calling it is necessary. It can know that any *correct* implementation of Object.finalize is a no-op, so there is no reason it call it. It is hard to imagine any use for a non-empty Object.finalize; any VM-specific actions on object cleanup should be part of the run-time system instead. An unnecessary call to java.lang.Object.finalize() won't hurt anyone. Well, there is always performance ... Besides, this would only be a compiler warning, and the user would be free to ignore it. Many projects, including gcc itself, prohibit warnings. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: More finalize woes
Stephen Crawley wrote:
[* Calling super.finalize in a finalizer for a direct subclass of Object
insulates the programmer from problems if he/she changes the inheritance
structure.
That's a reasonable point. However ...
Insignificant, IMO. The number of objects that have finalizers is very
small.
IIRC all objects technicaly have finalizer. The question is which
objects have non-trivial finalizers. If (to allow changing class
hierarchies as above) you require all classes to contain:
public void finalize () { super.finalize(); }
(which is a logical extension of what you said), then it becomes
more difficult to detect non-trivial finalizers. Not very
difficulat, mind you, just a little less trivial, if I may say so.
Besides, even if the application programmer went mad and put
finalizer methods in lots of classes, the cost of calling
Object.finalize would be swamped by the cost of setting up the stacks
etcetera to call the most-derived finalizer.
I'm not sure what setting up the stacks etcetera refers to.
However, objects with (non-trivial) finalizers are quite expensive
in many Java implementations.
The JLS also goes on to say the following:
...
We encourage implementations to treat such objects as having a finalizer
that is not overridden, and to finalize them more efficiently, as
described in ยง12.6.1.
I think it is arguable that a JVM could optimize away all calls to
super.finalize() that bind to Object.finalize(). This would make the
performance question moot ... for such JVMs.
True.
If project policy strictly prohibits warnings, it must wear the cost of
code to circumvent the warnings. In this case, the cost will be
vanishingly small, at least in realistic examples.
Yes, but only if the JVM does the recommended optimization.
I don't know if GCJ does.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
unimplemented methods
I just looked at a couple of classes (java.net.URI
and java.awt.GridBagLayout) and noticed lots of
unimplemented methods just do nothing or return null.
This has to stop. If an method does not do what it
is supposed to do, then it must throw an exception.
I'll make an exception for a method where you might
get semi-useful results if it isn't implemented
correctly, but if a class isn't anywhere close to
useful, it shouldn't pretend to be.
That raises the question: What exception to throw?
We could add a special gnu exception, but I suggest
UnsupportedOperationException. E.g:
public URI (String scheme, String ssp, String fragment)
throws URISyntaxException
{
throw new UnsupportedOperationException();
}
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath / GCJ java.io Merge
Brian Jones wrote: I have noticed that for a good deal of CNI code it is quite straight forward to turn it into C or C++ based JNI instead. There was a Perl script that someone purported to do some of this a while ago. I'm tempted to play with it a bit. That would be great, but surprising. I would think you'd need a fair bit of analysis to convert CNI to JNI. If we could maintain native methods in readable CNI, possibly with some annotations/conventions to ease the script's job, and generate JNI automatically from that, it might solve much of the CNI vs JNI problems. For the hard bits, we could use #ifdef CNI sections. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath / GCJ java.io Merge
Brian Jones wrote: I'd like to see our I/O implementation handle 64-bit filesystems and all the native libs be 64-bit compatible (i.e. no assuming pointers are ints, file handles are ints, etc.). GCJ uses the magic class type gnu.gcj.RawData as essentially a non-GC'd 'void *' pointer. This may not be portable to other VMs directly, but you could have a script convert gnu.gcj.RawData to int or long, depending on the target word size. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.net.URI implementation
Giannis Georgalis wrote: I agree with you. I found JFlex http://www.jflex.de, that is *much* faster than a hand-written scanner, as the benchmarks below show. I think space is *much* more important than speed when it comes to parsing URIs. How big is the generated scanner? I'm also skeptical as to how JFlex is faster. The only thing I can think of is that a generated parser might use fewer method calls that most hard-written parsers. But unless you show a hand-written parser next to the JFlex parser, I can't tell whether the hand-written parser is just poorly written. Of course a complicated Perl-style regular expression with backtracking will be very difficult to implement by hand, but parsing URIs shouldn't need that. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.net.URI implementation
Giannis Georgalis wrote: The generated scanner is not big (about 300 loc). A more interesting measure is .class file size. As you note, generated scanners are faster because they save a lot of function calls, have lookup tables, Lookup tables are difficult when using Unicode - a simple one-element-per-character table is too wasteful, at least for a non-critical helper class like URI. and as far as I remember they work like FSMs (finite state machines). That does not say anything about the implementation. A hand-written scanner is also a FSM. Additionally don't forget that the URI objects are immutable. That means that as soon as the parsing is complete, the parser object is *dead*. But you still have to allocate the parser object(s), which a hand-written parser doesn't have to. And object allocation is relatively expensive, in the context of parsing a URI. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Wonka Classpath
Chris Gray wrote: However it still seems to me that GPL+exception excludes the possibility of binary-only distributions, something which we do not wish to exclude. My reading is that it excludes binary-only distribution of modified libraries, which we *do* want to exclude. Admittedly there seems to be little reason why a systems integrator would need to make proprietary modifications to a core package such as java.awt (as opposed to wonka.rudolph.peers), but still I can imagine cases where the GPL would impose on the system integrator the obligation to provide source code to anyone who asked. I think that is a feature, not a bug in the license. We want to encourage people to submit improvements. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: japize
Brian Jones wrote: Btw, there are entirely too many bytecode libraries out there... Jode, gnu.bytecode, Apache's version of the same, and on and on... anyone know what the best GPL and BSD compatible ones are? It depends what you're trying to do. gnu.bytecode is optimized for low-overhead code generation, plus basic slurping of the contents of .class files, and it is less suited (at least in its current incarnation) for heavy-duty instruction analysis, peephole optimization, etc. Most similar libraries seem to use one object for each instruction, which is flexible, but expensive. gnu.bytecode just appends instructions into a byte array, using a large set of convenience methods that pick the correct instructions. (Simplified of course. For example, you can reference undefined labels, so you have to be able to back-patch the array. And there is limited support for re-ordering code.) (I would like change it to use basic blocks as the fundamental unit, using the algorithms I wrote for gcc/java/jcf-write.c, but I haven't had time.) gnu.bytecode is compatible with the GPL. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: OT: GPL and jar file
Andreas Rueckert wrote: That would mean it depends on the JVM? If you have a JVM, that loads all the classes at once, B becomes GPLed, if the JVM loads the classes on demand, B keeps it's license? I don't see how that makes a difference. Let be elaborate a bit further on my question. My problem is a Installer called izPack ( http://www.izforge.com/izpack/ ), that is under GPL. It creates a single Jar with the installer classes (under GPL) and the app to be installed. Julien Ponge (izPack author) says, you can install even closed source apps with the tool, while I'm uncertain. Well, if he owns the copyright, he gets to decide, a he is the one who has standing to sue. And maybe his interpretation is right, fo his code. But he should make it clear, in the license, if he hasn't already. Sorry for the OT discussion, but the same problem would occur, if anyone would include classpath code in a non-GPLed project, so I thought you might have an answer. But Classpath is not GPL - it is GPL with an extra exception allowing you to link it with proprietary code. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: OT: GPL and jar file
Andreas Rueckert wrote: I have a licensing question, that you might be able to answer: are 2 classes in a jar file 'linked' in a GPL way? I mean, if class A is under GPL and I put it in a jar file with class B, does it restrict the license of B to GPL? Or could B still be closed source? This is a legal question, and I don't think anyone here can really answer it. My guess is that just placing the classes in a jar doesn't link them, but loading both classes into the same JVM does. However, this is like the old user-does-the-link ploy which (I believe) NeXT tried (for the Objective-C compiler). The FSF sicced their lawyers on them and NeXT ended up Free'ing their Objective-C compiler. A determining factor is likely to be to what extent B depends on A. If they are completely independent, it is probably ok (mere aggregation); but if B depends on A, I wouldn't try it. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.lang.StrictMath
Eric Blake wrote: StrictMath is required to be implemented in pure Java, not in native code; Where is this peculiar requirement stated? No proper specification would make any such requirement (not to suggest that Java has a proper specification) - most standards have an as-if rule: The implementation must behave *as if* it used the specified algorithm or code, but as long as no valid program can tell the difference, the implementation is free to use some other algorithm. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.lang.StrictMath
Eric Blake wrote: But maybe it is worth it after all for StrictMath to have native implementations, Note I am not saying that StrictMath should have native implementations, only that it *may*, *if* the results are the same. Is the overhead of calling a native method offset by the speed of doing this number crunching without going through bytecode? It depends. For GCJ, there is no overhead for calling a native method, beyond the normal method calling overhead, which is the same as in C++. (For virtual calls. Interface calls are a different matter.) For JDK, or other system with a good JIT, it is probably faster to use Java code. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.awt status LGPL - GPL?
I would not be too hasty about changing any files quite yet. I (in my capacity as a member of the Gcc steering comittee) am pushing for a better resolution of this issue. --Per ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.math.*
Brian Jones wrote: I'd like to adopt the gcj java.math.BigInteger/BigDecimal classes and the related gnu.gcj.math.MPN. This latter class is from Kawa so I'd like to make sure we can use this. Are there any problems or objections? You have my blessing (as author of Kawa and the MPN class). It would be nice if someone cleaned up the serialization. Right now BigInteger has a bunch of extra fields which are only used temporarily during serialization, to match Sun's format. It would be great if someone who knows the serialization format (or wants to learn) could write the code to generate the correct serilaization direcectly without using temporary fields. (Even better would be to avoid generating temporary objects when serializing, but I'll settle for getting rid of the extra fields.) --Per Bothner ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Fw: java.beans.beancontext.BeanContextSupport
Anthony Green wrote: Hey Per -- Perhaps you're not on the classpath list... No. BeanContextSupport is used by Jetty. I believe Per had Jetty working with GCJ, No, I don't recall working on Jetty. I've played with Jigsaw and gnu-paperclips; I believe i got the former basically working. ___ 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 pages: project on savannah
"Nic Ferrier" [EMAIL PROTECTED] writes:
I'm ccing this to:
...
- per bothner because he runs another major GNU java project (Kawa)
I'm also on the Gcc steering committee with special interest in
Java and Gcj (which by the way can now compile Kawa, and Kawa-compiled
Scheme code, to native code).
My question is: would anyone getting this have an objection to me
setting up a savannah project to manage the GNU java web pages?
I recently started up a discussion on Java "packaging" in a different
sense - i.e. how Java packages should be installed, with the hope that
this would be an update to GNU and Linux standards, but with no
resolution yet. This savannah project should also include or link
to a document specifying GNU installation recommendations.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [Savannah-hackers] Re: Java pages: project on savannah
"Nic Ferrier" [EMAIL PROTECTED] writes: I'd like you to consider what I'm talking about though. The current system is accepting java programs and listing them on our website as a service to the java community... it's not making them part of the GNU project. The other parts of this is acting as a clearing-house for the gnu.* hierarchy of Java package names. We obviously need some kind of clearing-house to avoid clashes, and we also need a registry of packages under gnu.*. (Of course packages *not* under gnu.* can still be GNU software.) At one point I thought that http://www.gnu.org/software/java/java-software.html was to be that registry of gnu.* packages. But is it being used that way? Is it being updated? In February I sent mail to [EMAIL PROTECTED] asking whether I could "have" the gnu.lists package name. I've gotten no answer, so I don't really know if it ok or not to call my package gnu.lists. I finally decided to go ahead. I now have another new package containing XML utilities (for now a parser, printer, namespace-resolver, and xpath evaluator). This builds on gnu.lists and is in many ways different from traditional xml implementations. I'd like to call this gnu.xml. Nic's proposal came about because of a discussion we had about whether I could/should call my package gnu.xml, and how to "register" the gnu.xml package. I still think java-software.html or a similar catalog is a good mechanism, but we need some kind of policy for how new packages can be approved and added. The [EMAIL PROTECTED] list may be a good place to discuss proposed packages, but perhaps it needs to be expanded to more people. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/~per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: gnu.* namespace discussion
Warren Levy [EMAIL PROTECTED] writes: My feeling at this point is that a gnu.classpath hierarchy would be more appropriate than a gnu.java one. I realize that would mean a change to the existing structure and that is not fun. Is there a better approach? I'm sure that there are other aspects to this that I'm not bringing out here. Please bring out any issues you see associated with this for discussion. It depends on how we view the relationship between libgcj and Classpath. If we want to emphasize that these classes are specific to the classpath implementation then we can use gnu.classpath. But personally I see nothing wrong with gnu.java for library-implementation-specific classes that are not specific to gcj. Classes that are not dependent on the specific vm or gcj compiler technology should be in gnu.java (or whatever name we choose). Classes that are specific to libgcj should remain gnu.gcj. My opnion is quite tentative. My suggestion is to keep things is gnu.java and gnu.gcj for now. We can move things around later when we've got some more feeling for what makes sense. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/~per/
Re: gnu.* namespace discussion
Brian Jones wrote:
In what way is anyone else using gnu.java.* which conflicts with GNU
Classpath? Maybe that's the real problem. No central name space
controller has been forthcoming from the FSF.
I didn't see this message (it doesn't seem to have made it to
java-discuss), so I don't know what the "real problem" referred to is.
The central name space controller is supposed to be
http://www.gnu.org/software/java/java-software.html
Stuart Ballard [EMAIL PROTECTED] writes:
Not to beat a dead horse, but I think that's why Sun chose to use the
reverse-domain-name scheme - the central namespace controller is already
established and Sun didn't need to do any work on controlling the
namespace.
No, but each organization still does. You may notice that Sun does
not appears to be folliwing their reverse-domain-name scheme *within*
the com.sun package. That seems to be generally true: People follow
the reverse-domain-name scheme for the first two parts, but beyond
that they tend to pick more common-sense names. In other works: They
just pay lip-service to the reverse-domain-name scheme, and I don't
blame them: It's a bad solution, and there is no reason why Gnu should
follow it. See: http://www.gnu.org/software/java/why-gnu-packages.txt
In that case, we could be using org.classpath and do whatever we wanted
to within that space.
Sure, but what problem would that solve?
I once heard someone say that if a convincing case could be made to the
FSF in favor of moving to the reverse-domain scheme from the gnu.*
scheme, they would maybe consider it. Perhaps the
central-namespace-controller issue is the basis for a convincing case?
Adding a "org." in front does not make the problem any easier or harder.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
Re: Proposal for CNI/JNI problems
Bernd Kreimeier [EMAIL PROTECTED] writes: ANTLR? ANRLR is not a compiler; it is parser-generator. It does not handle C++ name resolution, for example, as far as I know. What do you mean by annotated-CNI? CNI with macros that are no-ops when using CNI, but that help whatever tools is used to convert to JNI. Is a modification of gcjh a good way to simplify the task for the parser/converter? I.e. marking Java-turned-C++ classes, enforcing naming schemes/prefixes etc.? I don't see how it helps. The problem is analyzing the user's C++ native code. Having parts of the toolchain being pure Java (along with the ability to compile them to native code for bootstrap) is the foundation for much more portability. But why is this an inportant goal for GNU Classpath? -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/~per/
Re: Proposal for CNI/JNI problems
Paul Fisher [EMAIL PROTECTED] writes: This sounds like a good solution, and it's certainly better than the pure-C++ solution that I was working on. Do you, or anyone else in the gcc/gcj camp, have time to work on such a feature? I don't think I have time to actually do the work. I can help out, in pointing to where I think things need to be done. Though the specific case of changing the method header might be best to ask the gcc mailing list, because I've heard rumours about plans to clean up the code that does name mangling. They might also be the best to suggest the cleanest place to fix this. (Adding support to re-writing field references and method invocation is probably easier, because it is more obvious what needs to be changed: It basically needs to be done when the tree nodes are generated.) -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/~per/
Re: Proposal for CNI/JNI problems
Paul Fisher [EMAIL PROTECTED] writes:
While it's important that Classpath continue to support JNI,
The first question is why? What is the goal? (Obviously JVMs
should support JNI; that is not my question.) Presumably, the
goal is that Classpath can be used as the standard Java library
for non-Gcj JVMs. The question then is how portable do we
need to/want to be?
(1) Is it OK to write Classpath in C++ rather than C? Doing so rules
out architectures that don't have a C++ compiler. If a platform does
not support C++, then it doesn't support Gcc. From a GNU point of
view, I don't think it is important to support such platforms. So C++
is it, as it makes it easier to use CNI or a JNI/CNI hybrid.
(2) Is it OK for Classpath to depend on G++ extensions? For example,
G++ has some special knowledge of Java, to support CNI. Whether
these extensions are going to help with JNI is another matter.
Tom Tromey suggested that the ideal way to let people write code
that is both JNI and CNI-compliant is to have a compiler that can
read CNI and emit JNI. See:
http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00570.html
My first reaction was that this was too difficult. But it becomes
simpler if we remember that JNI is an Application *Binary* Interface.
All we need do is have G++ have an option to generate JNI calls.
For example, let is call this option -femit-jni. First, note that
G++ already has the concept that certain classes have the "Java
property". (In practice, thes are the classes that inherit from
java::lang::Object.) If the compiler sees a field reference
VAL-FIELDNAME
*and* -femit-jni has been specified *and* the type of VAL is a
pointer to a class that has the Java property, *then* the compiler
instead generates (code *as if* it had seen):
static jfieldID f1 =
(*__jnienv)-GetFieldID(__jnienv, CLS, "FIELDNAME", ...);
(*__jnienv)-GetObjectField(__jnienv, VAL, f1);
Method invocation can be handled similarly.
What about the __jnienv mentioned before? That is the JNIEnv pointer
needed by JNI. It is provided by the JNI call. The compiler
has to translate the CNI method declaration to a JNI method.
For example:
jclass java::lang::Object::getClass()
{
return ...
}
would get translated by the compiler to:
jclass Java_java_lang_Object_getClass(JNIEnv* __jnienv, jobject this)
{
return ...;
}
That is not a big deal. Basically, it's a special name mangling,
plus an extra hidden argument.
Finally, consider the body of Object::getClass(). We want to be able to
write:
return Jv_GetObjectClass(this);
We want to have the compiler generate:
return (*__jnienv)-GetObjectClass(__jnienv, this);
We don't want to teach the compiler about all these CNJ/JNI methods.
Instead, we put it in the cni.h header file:
#ifdef __JNI
#define Jv_GetObjectClass(OBJ) \
(*__jnienv)-GetObjectClass(__jnienv, OBJ)
#else
#define Jv_GetObjectClass(OBJ) _Jv_GetObjectClass(OBJ)
#endif
Now all we have to do if make sure -femit-jni causes __JNI to be defined.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
Re: Algorithm used by BigInteger prime generator?
"D'Arcy Smith" [EMAIL PROTECTED] writes:
[crypto] is what [BigInteger] is was written for in the first place
apparently...
I had the (unsubstantiated) impression was that it was written for
JDBC (i.e. a needed SQL data type). Certainly, I can't imagine
BigDecimal being useful for crypto, but big decimal integers
(at least 18 digits) are needed for database applications.
--Per Bothner
Cygnus Solutions [EMAIL PROTECTED] http://www.cygnus.com/~bothner
Re: Algorithm used by BigInteger prime generator?
No my assumption was based on a conversation I had with the original author a couple of years ago... Well, JDBC does use BigDecimal, and was presumably a motivator for including it in JDK1.1. I agree that geneating random primes suggests crypto, and may have been a motivator for the "original author" of BigInteger. What you did not explain was whether by "orginal author" you mean the person who wrote a BigInteger class that java.math.BigInteger was based on, if this pre-dates JDK1.1, or you mean the person at JavaSoft who "owned" java.math in JDK1.1, or if they are the same person. In any case, big numbers are useful for various applications, inlcuding crypto. It is important that the generated "random" values be the same on all platforms, and that is difficult with Sun's missing specifications. (Even the specifications of java.io in the JLS is incomplete; classes not specified on the JLS often are way under-specified. And the Class Libraries books, in additions to *not* being specifications, have lots of mistakes.) --Per Bothner Cygnus Solutions [EMAIL PROTECTED] http://www.cygnus.com/~bothner
Re: Free Java @ JavaOne 1999
Sounds reasonable. One format is 5-10 presentation from each group, followed by 5-10 minutes questions to a specific group, followed by open floor. However, 60 minutes in length may not be enough for all the groups. Two back-to-back sessions would be better, if we could get it. Alternatively, just having separate sessions may make more sense. I suspect we could fill a 60-minute session on our own! --Per Bothner Cygnus Solutions [EMAIL PROTECTED] http://www.cygnus.com/~bothner
