Eclipse 3.0 and java.nio

2004-08-26 Thread Steven Augart
This letter is to note that Eclipse 3.0, with Classpath, still requires that we disable file locking, since Classpath 0.10's java.nio implementation does not support it. There was a brief thread on this in November, 2003: http://lists.gnu.org/archive/html/classpath/2003-11/msg00119.html

Re: Eclipse 3.0

2004-07-12 Thread Arnaud Vandyck
Mark Wielaard [EMAIL PROTECTED] writes: [...] Then we hit: javax.xml.transform.TransformerFactoryConfigurationError: Factory class com.icl.saxon.TransformerFactoryImpl not found at javax.xml.transform.ClassStuff.createFactory (ClassStuff.java:141) Since they decided not to

RE: Eclipse 3.0

2004-07-06 Thread Jeroen Frijters
Eric Blake wrote: The compiler must always allow you to invoke a public method from Object from a qualifying type of an interface (since in JLS 9, interfaces implicitly have all public methods from Object), but the compiler's responsibility according to JLS 13.1 is to flatten that to a call

running eclipse 3.0 with classpath...

2004-07-04 Thread Valentin Chira
is it possible? if yes with which VM has been tested and which classpath version? thx. regards, Vaentin ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath

RE: Eclipse 3.0

2004-07-04 Thread Mark Wielaard
Hi, On Sat, 2004-07-03 at 13:14, Mark Wielaard wrote: On Sat, 2004-07-03 at 10:43, Jeroen Frijters wrote: BTW, what Eclipse version are you using? eclipse-SDK-3.0-linux-gtk.zip from http://download2.eclipse.org/downloads/drops/R-3.0-200406251208/index.php I am still just using what is

Re: Eclipse 3.0

2004-07-03 Thread Anthony Green
On Fri, 2004-07-02 at 17:09, Mark Wielaard wrote: Since they decided not to automagically include their own XML stuff since M9... So you need libxmlj or something like xalan added to your bootclasspath. I tried that, but I now have jamvm crashing. Rebuilding libgcj with the above patches now.

RE: Eclipse 3.0

2004-07-03 Thread Jeroen Frijters
Mark Wielaard wrote: OK, finally found it. Eclipse does some really nasty URLStreamHandler tricks. It seems to depend on us NOT trying to find a new URLStreamHandler when the URL.set() method is called. Kind of makes sense if the protocol isn't changed. So doing something like: if

Re: Eclipse 3.0

2004-07-03 Thread Mark Wielaard
Hi Anthony, On Sat, 2004-07-03 at 08:00, Anthony Green wrote: On Fri, 2004-07-02 at 17:09, Mark Wielaard wrote: Since they decided not to automagically include their own XML stuff since M9... So you need libxmlj or something like xalan added to your bootclasspath. I tried that, but I now

RE: Eclipse 3.0

2004-07-03 Thread Jeroen Frijters
Mark Wielaard wrote: Thanks! This allows M9 to start up successfully for me! Inspired by this success I downloaded the 3.0 release, but unfortunately that still doesn't work and bizarelly enough it dies with the exact same NullPointerException that M9 died with before this fix. Sigh...

Re: Eclipse 3.0

2004-07-02 Thread Roman Kennke
Ok, back to the problem: Caused by: java.lang.NullPointerException at org.eclipse.osgi.framework.adaptor.core.BundleResourceHandler.openConnection (BundleResourceHandler.java:138) at java.net.URL.openConnection (URL.java:658) I bet, that there is no URLStreamHandler set (instance

Re: Eclipse 3.0

2004-07-02 Thread Roman Kennke
Am Fr, den 02.07.2004 schrieb Roman Kennke um 13:57: Ok, back to the problem: Caused by: java.lang.NullPointerException at org.eclipse.osgi.framework.adaptor.core.BundleResourceHandler.openConnection (BundleResourceHandler.java:138) at java.net.URL.openConnection (URL.java:658)

RE: Eclipse 3.0

2004-07-02 Thread Jeroen Frijters
Roman Kennke wrote: Am Fr, den 02.07.2004 schrieb Roman Kennke um 13:57: Ok, back to the problem: Caused by: java.lang.NullPointerException at org.eclipse.osgi.framework.adaptor.core.BundleResourceHandler. openConnection (BundleResourceHandler.java:138) at

Re: Eclipse 3.0

2004-07-02 Thread Dalibor Topic
Andrew John Hughes wrote: Sounds good to me. I wouldn't actually throw out any methods, simply because eventually someone will have to put it back in and that's just more time -- there's usually also a good reason a method hook has been put in, I imagine. I can see the situation where someone

Re: Eclipse 3.0

2004-07-02 Thread Mark Wielaard
Hi, On Fri, 2004-07-02 at 21:46, Roman Kennke wrote: ... another possibility is, that we should not go into the else branch in BundleResourceHandler.openConnection, but instead into the if branch: if (bundleEntry != null) { return (new BundleURLConnection bla) } else { some stuff

Re: Eclipse 3.0

2004-07-02 Thread Mark Wielaard
Hi, On Fri, 2004-07-02 at 23:38, Mark Wielaard wrote: Found this one. For some reason the code looks like this: if (url.getPath() != null) // A call to a URL constructor has been made // that uses an authorized URL as its context.

Re: Eclipse 3.0 and unimplemented methods proposal

2004-07-02 Thread Andrew John Hughes
On Fri, 2004-07-02 at 14:15, Dalibor Topic wrote: Andrew John Hughes wrote: Sounds good to me. I wouldn't actually throw out any methods, simply because eventually someone will have to put it back in and that's just more time -- there's usually also a good reason a method hook has been

Re: Eclipse 3.0 and unimplemented methods proposal

2004-07-02 Thread Casey Marshall
Andrew == Andrew John Hughes [EMAIL PROTECTED] writes: Andrew Anyway, the floor is over to you guys. Be gentle ;-) -- Andrew Andrew :-) I think this got as close to an authoritative answer/consensus as we can expect to get on this issue: