Re: Some object serialization problems for discussion(3)-ObjectInputStream
"Wu, Gansha" wrote: > libgcj implements callReadObject, callWriteObject in java, but classpath >demands native to > do them; Yes, In this case I dont see why it shouldn't be done in Java unless there is a compelling performance advantage in doing otherwise. In fact I suspect that all of Serialization can be implemented in pure Java, it is probably just for legacy reasons that we have native methods in there at all. This would require some significant reworking of the code but I think it would be worthwhile. > BTW, because of legacy problems, we couldn't port to libgcj's implementation >so easily. > We really like those changes like BigInteger, libgcj removed native dependency >in BigInteger, and > we hope BigInteger (and the like) in classpath will be merged back into classpath >ASAP; It should be trivial to merge the BigInteger stuff into classpath. For java.util.zip as you know it is more difficult for us due to the native code dependency. I believe there is now a pure-Java implementation of this which we should look at for classpath if copyright assignment etc can be taken care of. > We also like libgcj will add those parts classpath haven't implemented into >classpath, e.g, > java.util.zip.*, it's very important to run some biz apps; > But to those which involved changes of native interfaces, it's a burden for us >to change VM part. One thing I know we'd love to do is to port ORP to run on the libgcj runtime. This would mean using the ORB JIT with libgcj's GC etc. This will allow JIT'ed bytecode to be mixed with pre-compiled object code. We already do this with libgcj's interpreter so in principle it should not be hard to implement, but we'd need to change ORP to be compatible with GCJ's object and vtable layouts, and I don't know how difficult that would be. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Java 1.1 compliance?
> "Patrick" == Patrick Doyle <[EMAIL PROTECTED]> writes: Patrick> How close is Classpath to Java 1.1 compliance now? Does anybody know? We've occasionally compared libgcj against JDK 1.1 here (internally at Red Hat). It is pretty close. (Offhand I don't recall what is missing.) Well, it is pretty close if you only look at the packages we actually implement. If you look at something like AWT you'll be disappointed. Patrick> Is that the only criterion for calling it the "Classpath 1.0" Patrick> release? I doubt it. I have no idea what the release criteria are though. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.lang.reflect.Proxy
On 2 Aug 2001, Tom Tromey wrote: > I don't know about anyone else, but I don't have a strong preference. > How big is gnu.bytecode? Is it feasible to import it? > Maybe that would influence things. I would also worry about speed. Creating even a simple class with gnu.bytecode creates a lot of temporary objects. Proxy class could be possibly done with quite small number of bytecodes following some semi-fixed format. But it is better to have correct slow implementation than to have nothing or buggy one... Artur ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
The "InnerClasses" attribute
Thanks to everyone who replied regarding the handling of inner classes. The answer is in section 4.7.5 of the JVM spec, which defines the "InnerClasses" attribute to contain all the information the JVM needs to work out all the inner class relationships. I'm not sure how I missed that particular attribute, since I did rememeber to put all the others in my classfile parser. -- Patrick Doyle [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.lang.Class inner class methods
Not so. '$' is a legal identifier character, so I can compile a non-inner
class as follows:
class X$Y {}
In order to detect inner classes in the VM (or in a compiler when reading
.class files), you MUST read the attributes, rather than relying on the
naming convention in the inner class specification.
It would be nice if Sun would give compilers a guaranteed namespace that
cannot conflict with user identifiers, but that has not happened yet...
Original message:
Thu, 2 Aug 2001 11:22:54 +0200 (MET DST)
The inner class "Y" of class "X" is compiled as "X$Y".
So if a class name contains "$", it must be an innerclass.
This is documentend in the Innerclass specification,
http://java.sun.com/products/jdk/1.1/docs/guide/innerclasses/spec/innerclass
es.doc.html
in section "Class Name Transformation"
http://java.sun.com/products/jdk/1.1/docs/guide/innerclasses/spec/innerclass
es.doc7.html
-Patrik
--
Eric Blake, Elixent, Castlemead, Lwr Castle St., Bristol BS1 3AG, UK
[EMAIL PROTECTED] tel:+44(0)117 917 5611
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Java 1.1 compliance?
Just some idle thoughts... How close is Classpath to Java 1.1 compliance now? Is that the only criterion for calling it the "Classpath 1.0" release? (Also, have you considered renumbering the Classpath releases to coincide with, or at least correspond to, the Java version numbers?) -- Patrick Doyle [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Java 1.1 compliance?
Patrick Doyle wrote: > Just some idle thoughts... > > How close is Classpath to Java 1.1 compliance now? Is that the only > criterion for calling it the "Classpath 1.0" release? > > (Also, have you considered renumbering the Classpath releases to coincide > with, or at least correspond to, the Java version numbers?) Its a bit hard to do that I think. There are no doubt some parts of Classpath that are not complete (eg AWT) even to the JDK 1.1 spec, while others (eg Collections) are complete through to 1.3 or maybe even 1.4. The extent to which different packages, even if API-complete, are tested and debugged also varies substantially. Also, the JDK/J2SE releases are growing very large these days and its doubtful that we'd be able to implement everything thats in them in the forseeable future. regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Some object serialization problems for discussion(3)-ObjectInputStream
Hi, Bryce, I heard of a pure-java implementation of java.util.zip.* named jazzlib, but I never tried it. Would you like to try it? > It should be trivial to merge the BigInteger stuff into classpath. For >java.util.zip as you know it is more > difficult for us due to the native code dependency. I believe there is now a >pure-Java implementation of this > which we should look at for classpath if copyright assignment etc can be taken care >of. Best regards... Gansha ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
java.lang.reflect.Proxy
Unless anyone else speaks up, I will start implementing java.lang.reflect.Proxy and related classes, added in JDK 1.3. I believe I can write it entirely in native Java, by using existing reflection methods, so that it will integrate seamlessly into existing VMs without requiring any additional native methods. Hopefully, my copyright assignment will be cleared within the next month, so that by the time I finish, I can commit it directly into CVS. To do this in pure Java, I plan to generate a byte[] on the fly that will then be loaded as a class by the appropriate ClassLoader. Should I use the functionality already in gnu.bytecode, or should I write my dynamic class-generator from scratch? Benefits of writing my own: - Smaller footprint: only needs minimal feature set, tailored to the problem - Self-contained within classpath: users do not need to have gnu.bytecode installed Benefits of gnu.bytecode: - Code reuse - Less likely to have bugs in generated code - Already under GPL+exception, so license is compatible Recommendations? -- Eric Blake, Elixent, Castlemead, Lwr Castle St., Bristol BS1 3AG, UK [EMAIL PROTECTED] tel:+44(0)117 917 5611 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.nio.charset
> "Takashi" == Takashi Okamoto <[EMAIL PROTECTED]> writes: Takashi> Yes, I am. What should I do? Takashi> I have never contributed the code to FSF. I will send you the paperwork off-list. >> Any chance of you changing this into a Mauve test? Takashi> I don't know about Mauve so much. Takashi> Which directory should I place it? Takashi> Is it test/java.nio or testsuite/java.nio? Mauve is a separate project that is writing a test suite for the Java Class Libraries: http://sources.redhat.com/mauve/ The web page is not updated frequently. (As in, in years :-) The Mauve layout is straightforward, I think. Also, writing a test for Mauve is pretty easy. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Comment bug in Constructor.java
> "Patrick" == Patrick Doyle <[EMAIL PROTECTED]> writes: Patrick> In vm/reference/java/lang/reflect/Constructor.java, there is Patrick> the following comment: Patrick> Never mind that there should be no constructors in an Patrick> abstract class. Patrick> I'm not sure why the author of this comment thought this was Patrick> the case Me neither. I've deleted that part of the comment. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: APR/NSPR
> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes: Brian> APR seems most likely given the terms of the Apache license, Brian> but I have no idea what Tom's thoughts are on this. Maybe it Brian> doesn't matter, the CNI and JNI code are completely different Brian> anyway. As long as the CNI and JNI remain different, it doesn't much matter to me what the JNI code uses. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Some object serialization problems for discussion(3)-ObjectInputStream
> "Bryce" == Bryce McKinlay <[EMAIL PROTECTED]> writes: Bryce> Yes, In this case I dont see why it shouldn't be done in Java Bryce> unless there is a compelling performance advantage in doing Bryce> otherwise. In fact I suspect that all of Serialization can be Bryce> implemented in pure Java, it is probably just for legacy Bryce> reasons that we have native methods in there at all. This would Bryce> require some significant reworking of the code but I think it Bryce> would be worthwhile. I completely agree. And, if there are performance reasons that we might want native code in libgcj, I'd still like to see us merge as much code as possible. Bryce> One thing I know we'd love to do is to port ORP to run on the Bryce> libgcj runtime. This would mean using the ORB JIT with libgcj's Bryce> GC etc. This will allow JIT'ed bytecode to be mixed with Bryce> pre-compiled object code. We already do this with libgcj's Bryce> interpreter so in principle it should not be hard to implement, Bryce> but we'd need to change ORP to be compatible with GCJ's object Bryce> and vtable layouts, and I don't know how difficult that would Bryce> be. I looked at this a bit a while back (more than a year ago, I think). These comments are based on that look; I haven't followed ORP closely enough to know whether these things still hold. ORP has the nice feature that the JIT asks the VM for information about object layout, GC interface, etc. So interfacing the JIT to libgcj mostly requires writing a bunch of wrapper functions with the right names. Right now in libgcj we have an ad-hoc method for associating interpreter data with a class and/or method. We would need to generalize this (a good idea anyway) so that ORP can also do something intelligent. Exception handling is the one problematic area I know of. Well, there's also debugging. That is much harder though. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.util.Locale problem
> "Stuart" == Stuart Ballard <[EMAIL PROTECTED]> writes: Stuart> Forwarding this to the list; I don't know whether this is a Stuart> classpath or gcj issue (ie, whether these classes are merged Stuart> yet). They aren't. Stuart> PLEASE could somebody remove my name from the maintainer's Stuart> list on the classpath website? I don't know how to modify the web site. Hopefully Brian or Paul can do this. Antonio> wwping/agent/central/InvoiceAgent.java:1602: Class 'java.util.Locale' Antonio> has no method named 'getDisplayCountry' matching signature Antonio> '(Ljava/util/Locale;)Ljava/lang/String;' Antonio> Aren't these methods supported? Nobody has written these methods yet :-(. So the libgcj Locale implementation is still incomplete. Sorry. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: partial 1.4 Throwable compatiblity
> "Colin" == Colin Walters <[EMAIL PROTECTED]> writes: Colin> I may have a few people from my school's open source club who Colin> are interested in working on java.util.logging and Colin> java.util.prefs implementations, and we needed a few 1.4 bits Colin> like the new Throwable stuff to start getting stuff to compile Colin> with GCJ. Colin> Is anyone else working on these packages at the moment? I haven't heard of anyone working on them. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.util.Locale problem
Forwarding this to the list; I don't know whether this is a classpath or gcj issue (ie, whether these classes are merged yet). PLEASE could somebody remove my name from the maintainer's list on the classpath website? I don't mind answering questions that I can answer, but I don't think I've ever actually been asked a classpath question I can answer based on the maintainers list. I know the stock answer is "we're redoing the website and it'll be up soon", but how hard would it be to just remove one name in the meantime? It makes Classpath itself look bad, because the listed maintainer is unable to answer questions about what he's listed as maintaining. Stuart. Antonio Fiol Bonnín wrote: > > Hello, > > I am very interested on using gcj for our company's applications, but I > found this problem: > > wwping/agent/central/InvoiceAgent.java: In class > `wwping.agent.central.InvoiceAgent': > wwping/agent/central/InvoiceAgent.java: In method > `wwping.agent.central.InvoiceAgent.invoiceLatexFile(int,java.util.Locale)': > > wwping/agent/central/InvoiceAgent.java:1602: Class 'java.util.Locale' > has no method named 'getDisplayCountry' matching signature > '(Ljava/util/Locale;)Ljava/lang/String;' > > And I have also seen this one: > > wwping/servlet/ContactServlet.java: In class > `wwping.servlet.ContactServlet': > wwping/servlet/ContactServlet.java: In method > >`wwping.servlet.ContactServlet.prefs(javax.servlet.http.HttpServletRequest,javax.servlet.http.HttpServletResponse,java.util.ResourceBundle,java.util.Locale,wwping.db.Customer)': > > wwping/servlet/ContactServlet.java:612: Class 'java.util.Locale' has no > method named 'getDisplayLanguage' matching signature > '(Ljava/util/Locale;)Ljava/lang/String;' > wwping/servlet/ContactServlet.java:615: Class 'java.util.Locale' has no > method named 'getDisplayCountry' matching signature > '(Ljava/util/Locale;)Ljava/lang/String;' > > Aren't these methods supported? > > Thank you for your time! > > Antonio Fiol ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
