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
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
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
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
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
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.
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
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
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...
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
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)
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
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
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
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.
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
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:
17 matches
Mail list logo