[Question] j2ee, classpath, kaffe.
Hi, Is there anyone/institute who ever developed application following j2ee spec that runs on free software such as kaffe and classpath? Because lately I involve a project that is going to be developed through free software. So I'm trying to evaluate such solution would be possible or not. (Though I know there're other solutions other than java; yet, first, I'm not familiar with other language; second, middleware is my consideration this moment.) I appreciate any suggestions, Sincerely. Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
I just thought of another argument for changing the Map.putAll implementations
to use hasNext(), rather than size(). Sun's proposal for JDK 1.5 includes
adding a foreach construct, documented in JSR 201. According to their
proposal, the syntax:
for (Object o : mymap.keys()) { /* use o */ }
will be short for
for (Iterator i = mymap.keys().iterator(); i.hasNext();)
{
Object o = i.next();
/* use o */
}
Sun seems to be blessing the use of hasNext() here, by not documenting that
this should optimize to calling size().
I also agree that correctly calculating size() for a list composed of two
other lists is easy, but for a set composed of two other sets is difficult,
because of the set property that duplicate elements be counted only once.
David Holmes wrote:
Stuart Ballard wrote:
because the code that's causing a problem is in HashMap,
not AbstractMap, and it applies
when a Map of my type is passed to putAll() on a HashMap.
^^^
Stuart I apologize. I had misunderstood the exact nature and source of
the problem. I agree that both Abstractmap and HashMap putAll methods
should use hasNext() of the target collections iterator, not it's
size() method. In fact those methods should use nothing other than the
target collection's iterator as specified in AbstractMap.
David Holmes
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
--
Someday, I might put a cute statement here.
Eric Blake [EMAIL PROTECTED]
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
Here's an implementation idea that might work for an accurate size() for your
case - maintain a single combined hash map which contains modified elements,
with the submaps being views into the giant map, rather than maintaining the
two submaps and having the combined map be a view.
Instead of key->value, you would have key->valueWrapper, where valueWrapper is
something like:
class valueWrapper {
private static final Object UNUSED = new Object();
Object front; // UNUSED if not in front
Object back; // UNUSED if not in back
}
The big map is maintains all three maps with independent size counts for the
three views, and the small maps would just need to be custom implementations
of AbstractMap that wrap the big map to provide the appropriate view,
modifying their particular size count as appropriate.
Of course, having the small maps as wrappers of the big adds another layer of
indirection, which may affect your performance, but at least size() would be
O(1) for all three maps.
Stuart Ballard wrote:
David Holmes wrote:
Sure, I can calculate the size. The problem is that doing so requires a
full iteration over the elements of both sets: you can't just sum the
sizes, because you have to correctly account for elements that are in
both sets.
That makes this "optimization" of just looping size() times actually a
pessimization, because you have to iterate over the elements twice
instead of once. I didn't provide a correct implementation of size() for
exactly this reason: I was afraid that it would get called a lot on the
assumption that it's fast, when it's not.
As for why I need this implementation: it's being used for a language
interpreter and provides an implementation of nested scoping of
variables. Performance is important because it gets used a LOT. I wanted
to make sure that creating a new scope was cheap and didn't affect the
parent scope (it does caching to make sure that gets are cheap too). The
reasons why both the front and back scope need to be able to change
directly are complicated but (as far as I've found so far) unavoidable.
--
Someday, I might put a cute statement here.
Eric Blake [EMAIL PROTECTED]
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
RE: Recent move of Plain[Datagram]SocketImpl
Michael Koch wrote: > > You recently moved PlainSocketImpl and PlainDatagramSocketImpl to > > the gnu package. Is there any particular reason for this? For me > > this change is very inconvenient, because my implementations of > > PlainSocketImpl and PlainDatagramSocketImpl are written in Java, so > > I would like them to be in the same package (to be able to set the > > protected fields of SocketImpl and DatagramSocketImpl without using > > reflection). > > Well the special reason was to use these two classes from > java.nio. To make this possible it was needed to make this classes > public. Making them public in java.net would violate the JDK API > compliance of classpath and libgcj. Thanks for explaining. I worked around it by having my own versions of the gnu.* classes that extend the java.* classes. BTW, I noticed that the nio classes use getNativeFD to get at the underlying handle, I think that at some point in the future this needs to be changed, because for platforms that don't have an int sized native handle, this doesn't work that well. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Agile2D licence change
Hello to the Classpath list, After a short discussion with Ben Bederson and Jon Meyer, co-developers of Agile2D, the implementation of Graphics2D based on Opengl, we decided that the licence will become BSD instead of a variant of the MPL 1.1 (see http://www.cs.umd.edu/hcil/agile2d). This will enable the Agile2D implementation to become the basis of a free native implementation of Graphics2D -- also based on OpenGL -- for Gnu classpath. I will change the licence in a couple of weeks, after I come back from several trips. -- Jean-Daniel Fekete [EMAIL PROTECTED] INRIA Futurs, LRI tel: +33 1 69153460 <-- NEW! 08Oct03 Bat 490, Université Paris-Sud fax: +33 1 69156586 F91405 ORSAY Cedex, France ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Fwd: Alan Moore assigns past and future changes
Hi, On Wed, 2003-10-15 at 01:49, Brian Jones wrote: > From: Ted Teah <[EMAIL PROTECTED]> > To: Brian Jones <[EMAIL PROTECTED]>, Paul Fisher <[EMAIL PROTECTED]> > Subject: Alan Moore assigns past and future changes Good. This was one of the gnu.regexp people which we had a bit of trouble locating. I will contact the FSF copyright-clerc to see if we now have all the paperwork for importing gnu.regexp into classpath. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Patch to Proxy -- ok?
Hi, On Wed, 2003-10-08 at 20:33, Tom Tromey wrote: > We're using this patch in libgcj already. I looked at the reference > VMClassLoader, and it seems to have the ProtectionDomain variant of > defineClass. Is there a reason to hold off checking this in? No, please check it in. Thanks, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Agile2D licence change
On Thursday 16 October 2003 21:33, Jean-Daniel Fekete wrote: > Hello to the Classpath list, > > After a short discussion with Ben Bederson and Jon Meyer, co-developers > of Agile2D, the implementation of Graphics2D based on Opengl, we decided > that the licence will become BSD instead of a variant of the MPL 1.1 > (see http://www.cs.umd.edu/hcil/agile2d). > This will enable the Agile2D implementation to become the basis of a > free native implementation of Graphics2D -- also based on OpenGL -- for > Gnu classpath. > > I will change the licence in a couple of weeks, after I come back from > several trips. Excellent! Thanks Jean-Daniel. -- Chris Gray/k/ Embedded Java Solutions Embedded & Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Question] j2ee, classpath, kaffe.
On Thursday 16 October 2003 05:07, jsona laio wrote: > Hi, > Is there anyone/institute who ever developed > application following j2ee spec that runs on free > software such as kaffe and classpath? Because lately I > involve a project that is going to be developed > through free software. So I'm trying to evaluate such > solution would be possible or not. (Though I know > there're other solutions other than java; yet, first, > I'm not familiar with other language; second, > middleware is my consideration this moment.) > I appreciate any suggestions, > Sincerely. Classpath is reported to run JBoss, so in theory such a solution is possible. In practice you may end up posting some bug reports on Classpath, but that's part of the fun. :) In the end your application will work, and all users of Classpath will be grateful to you. Note that Kaffe is not the only free Java using Classpath; among the many listed at www.classpath.org, gcj may be very interesting for your project. Open-source Java that runs as fast as native code, because it _is_ native code. Best wishes -- Chris Gray/k/ Embedded Java Solutions Embedded & Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Question] j2ee, classpath, kaffe.
jsona laio <[EMAIL PROTECTED]> writes: > Hi, Is there anyone/institute who ever developed application > following j2ee spec that runs on free software such as kaffe and > classpath? Because lately I involve a project that is going to be > developed through free software. So I'm trying to evaluate such > solution would be possible or not. (Though I know there're other > solutions other than java; yet, first, I'm not familiar with other > language; second, middleware is my consideration this moment.) I > appreciate any suggestions, Sincerely. I don't know if there are any success stories with running JBoss yet. Definitely would be very cool. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
