Re: VMInterface addition: Make native library names part ofVMInterface
Hi, On Wed, 2003-11-05 at 21:31, Bryce McKinlay wrote: > On Nov 5, 2003, at 5:56 AM, Jeroen Frijters wrote: > > > I think that is in fact what Mark was suggesting and I think this is > > definitely a good idea. There are a lot of VMs that don't (want to) use > > JNI for their "native" methods. Having all native methods in the VM* > > classes makes this much easier. I was suggesting that. Sorry for not responding earlier. But having you and Patrik affirm that it is a good thing is more valuable then when 'the guy without his own VM' says it :) > I think its a mistake for classpath to try to be everything for > everyone, even at the expense of elegance and efficiency. At some > point, most implementations are going to have to modify it in some way > in order to suit their special/custom needs. Hopefully we won't do it at the expense of elegance 'and' efficiency, but I agree that sometimes it won't be possible to achieve both. As our Hacker Guide puts it (even though it leaves out elegance): When you write code for Classpath, write with three things in mind, and in the following order: portability, robustness, and efficiency. If efficiency breaks portability or robustness, then don't do it the efficient way. If robustness breaks portability, then bye-bye robust code. Of course, as a programmer you would probably like to find sneaky ways to get around the issue so that your code can be all three ... And I am also sure that there might be better designs then the grouping of platform dependent methods into their own VMInterface classes for some VMs. But just marking some methods 'native' to indicate that they are platform dependent is not it. A more efficient (and probably more flexible) approach might be to introduce some preprocessor that munges the java source files. But doing that in a clean way will be tricky. One of the big plus points of defining all platform dependent methods in VMInterface classes is that it makes clear when you are about to break Classpath any VM, so you must explicitly document your change. And such documenting and clear marking of 'special' VM classes makes it a lot easier for VMs that don't follow classpath CVS all the time, but just import a new version when we create a new snapshot release. What I hoped was that by having the VMInterfaces classes clearly marked as 'special', by being package local, final, having (mostly) static methods, and starting the name with VM (*), would make it easy for VMs and compilers to just inline all call to them. Especially if you treat the Classpath core classes as 'sealed' and compile them as complete packages. Maybe this is much harder then I imagined. What would be very beneficial would be if we took the script that gcj uses to display the changes between current Classpath CVS and gcc CVS and apply it to all current VMs that use a modified Classpath. http://gcc.gnu.org/java/libgcj-classpath-compare.html It has a way to mark changes as 'local' to the VM implementation which would be very helpful for all Classpath/VM integrators. And if more VMs used it then it gives the Classpath developers a better clue about what kind of things have to be adapted for every VM anyway. I was pleased to hear at the GNU Classpath workshop that at least Kissme, IKVM and Jaos use an unmodified GNU Classpath as core library implementation (and I believe JikesRVM also uses a unmodified Classpath). So we are not doing that bad. But maybe those VM/Compilers are not as aggressive about efficiency and elegance as gcj is (which does produce some very fast code!). But I still like to hear how we can improve the VM/Compiler/Platform specific parts of GNU Classpath without making life much harder for the gcj hackers. Cheers, Mark (*) Maybe VMInterface was wrong and we should actually call these classes Platform_Interface classes. signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part ofVMInterface
Mark Wielaard writes: > > Hopefully we won't do it at the expense of elegance 'and' efficiency, > but I agree that sometimes it won't be possible to achieve both. As our > Hacker Guide puts it (even though it leaves out elegance): > > When you write code for Classpath, write with three things in > mind, and in the following order: portability, robustness, and > efficiency. > > If efficiency breaks portability or robustness, then don't do it > the efficient way. If robustness breaks portability, then > bye-bye robust code. Of course, as a programmer you would > probably like to find sneaky ways to get around the issue so > that your code can be all three ... And clearly these guidelines are at odds with those of libgcj, where (and this is just my opinion) we favour robustness, maintainability, efficiency, portability. My goal is to improve gcj's speed to the point where it matches all of its competitors. I will be very cross indeed if while I am improving the compiler someone is concurrently pessimizing the library, > What I hoped was that by having the VMInterfaces classes clearly > marked as 'special', by being package local, final, having (mostly) > static methods, and starting the name with VM (*), would make it > easy for VMs and compilers to just inline all call to > them. Especially if you treat the Classpath core classes as > 'sealed' and compile them as complete packages. Maybe this is much > harder then I imagined. It's not particularly difficult to do, but at the moment we don't do it. gcj is perfectly capable of whole-program Java optimization but we have to follow Java rules, and one of those rules is that you cannot inline final methods because it breaks binary compatibility. We could teach gcj that VM classes are an exception to that rule, but I think you would agree that's not a pretty solution. Alternatively, we could perhaps have a compiler switch that allows final methods to be inlined, so gcj -finline-final foo.class VMfoo.class inlines all calls to final methods between foo and VMfoo. However, this would force us to rewrite the libgcj build scripts to handle VMfoo classes in a special way. However, none of this addresses Bryce's valid point that "too much abstraction increases the complexity of the classes, making maintenance more difficult." I've worked on systems with too much abstraction. They are very hard to understand and debug. Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part ofVMInterface
Andrew Haley <[EMAIL PROTECTED]> wrote on Thu, 6 Nov 2003 10:28:24 +: >> [having the VMInterfaces classes clearly marked as 'special' >> would make it easy for VMs and compilers to just inline all calls >> to them] >It's not particularly difficult to do, but at the moment we don't do >it. gcj is perfectly capable of whole-program Java optimization but >we have to follow Java rules, and one of those rules is that you >cannot inline final methods because it breaks binary compatibility. >We could teach gcj that VM classes are an exception to that rule, >but I think you would agree that's not a pretty solution. Apparently, Java 1.5 will have "meta-data" (arbitrary, uninterpreted declarations for language constructs that are represented in bytecode and accessible via reflection), similar to CLI/.NET. This might be a much cleaner approach for declaring such exceptions. Of course, the free compilers would need to support it first. -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part ofVMInterface
On Thursday 06 November 2003 12:04, Sascha Brawer wrote: > Andrew Haley <[EMAIL PROTECTED]> wrote on Thu, 6 Nov 2003 10:28:24 +: > >> [having the VMInterfaces classes clearly marked as 'special' > >> would make it easy for VMs and compilers to just inline all calls > >> to them] > > > >It's not particularly difficult to do, but at the moment we don't do > >it. gcj is perfectly capable of whole-program Java optimization but > >we have to follow Java rules, and one of those rules is that you > >cannot inline final methods because it breaks binary compatibility. > >We could teach gcj that VM classes are an exception to that rule, > >but I think you would agree that's not a pretty solution. > > Apparently, Java 1.5 will have "meta-data" (arbitrary, uninterpreted > declarations for language constructs that are represented in bytecode and > accessible via reflection), similar to CLI/.NET. This might be a much > cleaner approach for declaring such exceptions. Of course, the free > compilers would need to support it first. You could do it already using the "Attributes" mechanism - Java implementations are supposed to silently ignore attributes they don't understand. The attributes could be inserted by a tool using BCEL, so you wouldn't actually need to modify the compiler ... -- 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: Code formatting
On Mon, 27 Oct 2003 16:20:23 -0700 Tom Tromey <[EMAIL PROTECTED]> wrote: > > "Michael" == Michael Koch <[EMAIL PROTECTED]> writes: > > Michael> From what I understood what Tom said to me our style would be to write: > Michael> getToolkit().create (this); > Michael> Empty brackets have no space before it, non-empty brackets have a > Michael> space before it. > > Oops, I didn't mean to give that impression. > My understanding was that, in theory, for method calls we never had a > space before the parens. (In practice we often do, we're kind of > random about it.) So... what's up with this? ;) Do I have to re-write my patch? Was it already committed? Cheers, -- .''`. ** Debian GNU/Linux ** : :' : Arnaud Vandyck `. `' http://people.debian.org/~avdyk/ `- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.io.DataInputStream.readLine misbehaviour
Hi, On Sun, 2003-11-02 at 21:11, Guilhem Lavaux wrote: > Mark Wielaard wrote: > > >OK. Let me try to summarize the behavior we want so we can at least > >create some good tests: > > > >DataInputStream.readLine(): > >- Should not block when it has seen at least a \r but return as soon as > > possible even when it cannot be sure that the next character is or > > isn't a \n to prevent programs from blocking/deadlocking. > >- If there is a unconsumed \n in the stream right after a readLine() > > then that \n should be transparently consumed for all these cases: > > - readLine() is called again. > > - another DataInputStream read method is called. > > - a non-overridden (Filter)InputStream is called. > > - a method in the originally wrapped InputStream is called. > > > >That will be an ugly nut to crack. Especially how to guarantee that last > >requirement is nasty. And the method is (rightly) deprectated since > >programmers should BufferedReader.readLine() anyway (specified since > >1.1). Sigh. > > > >But having a good test case will be very valuable start. > >Any volunteers :) > > > Well ! You described entirely the behaviour of the test. So it should be > considered as done. ;-) I assume you are talking about test/regression/InputStreamTest.java from kaffe. I only briefly looked at it when the thread started and assumed it was only some strange corner case since it was also using the deprecated StringBufferInputStream (which has its own share of problems). Does that test really show all the (corner) cases that were discussed? (Especially when to wrapped InputStream is blocking just in the middle of a \r\n pair. Which seems to be the tricky case.) > But JDK won't pass this test (I've just tested > one or two pieces of the ideas). Actually if DataInputStream can detect > the '\n' it eats it directly in the call to readLine(). That is interesting. So that implementation probably just does some heuristics on the end of line if it can do it by looking ahead in the stream, but not otherwise. That is a very sneaky thing todo, but probably works in most cases that people care about. Sigh. What a bunch of yuck needed for such an ugly and deprecated method. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part ofVMInterface
Sascha Brawer writes:
> Andrew Haley <[EMAIL PROTECTED]> wrote on Thu, 6 Nov 2003 10:28:24 +:
>
> >> [having the VMInterfaces classes clearly marked as 'special'
> >> would make it easy for VMs and compilers to just inline all calls
> >> to them]
>
> >It's not particularly difficult to do, but at the moment we don't do
> >it. gcj is perfectly capable of whole-program Java optimization but
> >we have to follow Java rules, and one of those rules is that you
> >cannot inline final methods because it breaks binary compatibility.
> >We could teach gcj that VM classes are an exception to that rule,
> >but I think you would agree that's not a pretty solution.
>
> Apparently, Java 1.5 will have "meta-data" (arbitrary, uninterpreted
> declarations for language constructs that are represented in bytecode and
> accessible via reflection), similar to CLI/.NET.
So we'd have something like
public final class VMfoo
{
@Inline void native bar (int i);
@Inline void baz (int i) {
I could make that work.
Andrew.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part ofVMInterface
Jikes RVM uses a mostly unmodifed classpath. We don't require users to patch any classpath sources, but there are currently 12 non-VM classes for which we provide our own implementation. java.lang.ref: PhantomReference, Reference, SoftReference, WeakReference java.lang: Class, Object, Runtime, Thread, Throwable java.lang.reflect: Constructor, Field, Method Some of this is historical (we had the classes already and haven't had the bandwidth to try to integrate our versions with classpath). In the case of java.lang.ref.* we really needed to do something different than what classpath provided, and I don't see that changing (and the classes are tiny anyways). There may be hope for merging some of the java.lang and java.lang.reflect classes eventually. Jikes RVM cares a lot about efficiency, but we have different constraints than gcj. It's very easy for us to inline across classes without breaking any semantics. The VM itself is also written in Java (with some extensions to allow the VM to do type unsafe things like implement a GC), so for us efficiency usually means avoiding native methods and staying in Java+VM_Magic (this is what motivated the VMFloat/VMDouble changes I contributed to classpath a while back...Jikes RVM can do these operations much more efficiently by staying in Java instead of calling a native method). But, an extra level of final methods is harmless for us, we inline it all away. --dave___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part ofVMInterface
Mark Wielaard wrote: I think that is in fact what Mark was suggesting and I think this is definitely a good idea. There are a lot of VMs that don't (want to) use JNI for their "native" methods. Having all native methods in the VM* classes makes this much easier. I was suggesting that. Sorry for not responding earlier. But having you and Patrik affirm that it is a good thing is more valuable then when 'the guy without his own VM' says it :) I am also strongly in favor of putting all VM-specific native methods in VM* classes, and all library-specific native methods outside of VM* classes. It even helps for code maintenance, and you can then use automated tools to look for missing native implementations in the VM very easily. Same applies to class library. Hopefully we won't do it at the expense of elegance 'and' efficiency, but I agree that sometimes it won't be possible to achieve both. As our Hacker Guide puts it (even though it leaves out elegance): When you write code for Classpath, write with three things in mind, and in the following order: portability, robustness, and efficiency. If efficiency breaks portability or robustness, then don't do it the efficient way. If robustness breaks portability, then bye-bye robust code. Of course, as a programmer you would probably like to find sneaky ways to get around the issue so that your code can be all three ... And I am also sure that there might be better designs then the grouping of platform dependent methods into their own VMInterface classes for some VMs. I habve yet to find time for it, but I should within the upcoming months. I see the possibility to use m4-like macros so that most VMs would share VM*.java implementations, but be able to apply changes to them without disrupting other VMs. Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part ofVMInterface
> I am also strongly in favor of putting all VM-specific native methods in > VM* classes, and all library-specific native methods outside of VM* classes. I suspect the notion of a VM-specific native method vs. a library-specific native method is pretty fuzzy. One example is VMFloat, most VM's would probably view those as library specific, but Jikes RVM wants to think of them as VM-specific because we can do a better job of implementing them in a VM-specific way than the native method does (and we don't want to have to provide our own complete implementation of Float.java just to change a couple methods). But, the native method is VM neutral and works just fine on Jikes RVM, it is just much less efficient for us. There are also obviously Java methods that are (or can be) VM specific. Some of these have been moved to VM* classes, others have not. I don't think there is an easy solution to this as it is unlikely that a single VMInterface will fit the needs of all VMs perfectly. In some cases (java.lang.ref.* for example), I don't think that it is reasonable for classpath to try to provide an implementation that will actually work unchanged on all VMs. The details of this class are pretty closely tied into the details of the GC system and there is very little code that isn't VM specific. --dave___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part ofVMInterface
David P Grove writes: > I don't think there is an easy solution to this as it is unlikely > that a single VMInterface will fit the needs of all VMs perfectly. > In some cases (java.lang.ref.* for example), I don't think that it > is reasonable for classpath to try to provide an implementation > that will actually work unchanged on all VMs. Exactly. Classpath should provide a reference implementation, we but shouldn't expect every core class to be used unchanged. Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
Stuart Ballard wrote:
Nobody spoke up, so could someone apply the patch (attached)?
Anybody? :)
Stuart.
--
Stuart Ballard, Senior Web Developer
FASTNET - Web Solutions
(215) 283-2300, ext. 126
www.fast.net
Index: HashMap.java
===
RCS file: /cvsroot/classpath/classpath/java/util/HashMap.java,v
retrieving revision 1.24
diff -u -r1.24 HashMap.java
--- HashMap.java1 Aug 2003 03:31:32 - 1.24
+++ HashMap.java25 Sep 2003 18:16:52 -
@@ -381,8 +381,7 @@
public void putAll(Map m)
{
Iterator itr = m.entrySet().iterator();
-int msize = m.size();
-while (msize-- > 0)
+while (itr.hasNext())
{
Map.Entry e = (Map.Entry) itr.next();
// Optimize in case the Entry is one of our own.
@@ -709,10 +708,10 @@
void putAllInternal(Map m)
{
Iterator itr = m.entrySet().iterator();
-int msize = m.size();
-size = msize;
-while (msize-- > 0)
+size = 0;
+while (itr.hasNext())
{
+size++;
Map.Entry e = (Map.Entry) itr.next();
Object key = e.getKey();
int idx = hash(key);
Index: Hashtable.java
===
RCS file: /cvsroot/classpath/classpath/java/util/Hashtable.java,v
retrieving revision 1.28
diff -u -r1.28 Hashtable.java
--- Hashtable.java 7 May 2002 05:13:05 - 1.28
+++ Hashtable.java 25 Sep 2003 18:16:52 -
@@ -510,7 +510,7 @@
{
Iterator itr = m.entrySet().iterator();
-for (int msize = m.size(); msize > 0; msize--)
+while (itr.hasNext())
{
Map.Entry e = (Map.Entry) itr.next();
// Optimize in case the Entry is one of our own.
@@ -859,11 +859,11 @@
void putAllInternal(Map m)
{
Iterator itr = m.entrySet().iterator();
-int msize = m.size();
-this.size = msize;
+size = 0;
-for (; msize > 0; msize--)
+while (itr.hasNext())
{
+size++;
Map.Entry e = (Map.Entry) itr.next();
Object key = e.getKey();
int idx = hash(key);
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Patch: image loading fixes
Hi,
This patch fixes various problems related to image loading. It also
implements Component.imageUpdate, GtkToolkit.prepareImage and the
byte-array GtkToolkit.createImage method.
Comments?
Tom
2003-11-06 Thomas Fitzsimmons <[EMAIL PROTECTED]>
* Makefile.am: Add GdkPixbufDecoder.java and
gnu_java_awt_peer_gtk_GdkPixbufDecoder.c
* Makefile.in: Regenerate.
* gnu/java/awt/image/ImageDecoder.java (ImageDecoder(byte[],int,int)):
New constructor.
(startProduction): Create ByteArrayInputStream when url and filename
are
null.
(produce): Declare stream parameter as InputStream.
* gnu/java/awt/image/XBMDecoder.java (produce): Declare stream
parameter
as InputStream.
* gnu/java/awt/peer/gtk/GdkPixbufDecoder.java
(GdkPixbufDecoder(byte[],int,int)): New constructor.
(produce): Declare stream parameter as InputStream.
* gnu/java/awt/peer/gtk/GtkComponentPeer.java (prepareImage): Throw NPE
if image is null. Set image's observer before running PrepareImage
thread. Pass image to startProduction.
* gnu/java/awt/peer/gtk/GtkImage.java: Add null checks before calls to
source's member functions.
(observer): New field.
(setObserver): New method.
(setDimensions, setPixels, imageComplete): Call observer's imageUpdate.
* gnu/java/awt/peer/gtk/GtkToolkit.java (checkImage, getImage): Return
new GtkImage.
(prepareImage): Implement.
* java/awt/Component.java (imageUpdate): Implement.
(createImage): Call Toolkit's createImage if peer is null.
(prepareImage): Throw NPE if image is null.
* java/awt/MediaTracker.java: Fix return value.
Index: Makefile.am
===
RCS file: /cvs/gcc/gcc/libjava/Makefile.am,v
retrieving revision 1.334
diff -u -r1.334 Makefile.am
--- Makefile.am 29 Oct 2003 16:07:58 - 1.334
+++ Makefile.am 6 Nov 2003 19:46:29 -
@@ -170,6 +170,7 @@
gtk_c_source_files = \
jni/gtk-peer/gnu_java_awt_peer_gtk_GdkFontMetrics.c \
jni/gtk-peer/gnu_java_awt_peer_gtk_GdkGraphics.c \
+jni/gtk-peer/gnu_java_awt_peer_gtk_GdkPixbufDecoder.c \
jni/gtk-peer/gnu_java_awt_peer_gtk_GtkButtonPeer.c \
jni/gtk-peer/gnu_java_awt_peer_gtk_GtkCanvasPeer.c \
jni/gtk-peer/gnu_java_awt_peer_gtk_GtkCheckboxMenuItemPeer.c \
@@ -206,6 +207,7 @@
gtk_awt_peer_sources = \
gnu/java/awt/peer/gtk/GdkFontMetrics.java \
gnu/java/awt/peer/gtk/GdkGraphics.java \
+gnu/java/awt/peer/gtk/GdkPixbufDecoder.java \
gnu/java/awt/peer/gtk/GtkArg.java \
gnu/java/awt/peer/gtk/GtkArgList.java \
gnu/java/awt/peer/gtk/GtkButtonPeer.java \
Index: gnu/java/awt/image/ImageDecoder.java
===
RCS file: /cvs/gcc/gcc/libjava/gnu/java/awt/image/ImageDecoder.java,v
retrieving revision 1.1
diff -u -r1.1 ImageDecoder.java
--- gnu/java/awt/image/ImageDecoder.java 9 Aug 2002 04:32:43 - 1.1
+++ gnu/java/awt/image/ImageDecoder.java 6 Nov 2003 19:46:31 -
@@ -48,6 +48,10 @@
Vector consumers = new Vector ();
String filename;
URL url;
+ byte[] data;
+ int offset;
+ int length;
+ InputStream input;
public static ColorModel cm;
@@ -69,6 +73,13 @@
this.url = url;
}
+ public ImageDecoder (byte[] imagedata, int imageoffset, int imagelength)
+ {
+data = imagedata;
+offset = imageoffset;
+length = imagelength;
+ }
+
public void addConsumer (ImageConsumer ic)
{
consumers.addElement (ic);
@@ -90,11 +101,22 @@
Vector list = (Vector) consumers.clone ();
try
{
- FileInputStream is = (url == null) ? new FileInputStream (filename) :
- (FileInputStream) url.openStream();
-
- produce (list, is);
- }
+ // Create the input stream here rather than in the
+ // ImageDecoder constructors so that exceptions cause
+ // imageComplete to be called with an appropriate error
+ // status.
+ if (url != null)
+ input = url.openStream();
+ else
+ {
+ if (filename != null)
+ input = new FileInputStream (filename);
+ else
+ input = new ByteArrayInputStream (data, offset, length);
+ }
+
+ produce (list, input);
+ }
catch (Exception e)
{
for (int i = 0; i < list.size (); i++)
@@ -109,5 +131,5 @@
{
}
- abstract void produce (Vector v, FileInputStream is) throws IOException;
+ abstract void produce (Vector v, InputStream is) throws IOException;
}
Index: gnu/java/awt/image/XBMDecoder.java
===
RCS file: /cvs/gcc/gcc/libjava/gnu/java/awt/image/XBMDecoder.java,v
retrieving revision 1.1
diff -u -r1.1 XBMDecoder.java
--- gnu/java/awt/image/XBMDecoder.java 9 Aug 2002 04:32:43 - 1.1
+++ gnu/java/awt/image/XBMDecoder.java 6 Nov 2003 19:46:31 -
@@ -62,7 +62,7 @@
super (url);
}
- public void produce (Vector v,
Q: Classpath and Eclipse
Hi! Has anybody already tried to import classpath under Eclipse? I tried to create a project and import the files, but then Eclipse is far too intelligent: * gnu/java/lang classes are imported into package java.lang * vm/reference/java/lang classes are imported into package vm.java.lang Probably I'm just doing something wrong (I'm using Eclipse 3.0M4) Thanks, Patrik --- Patrik Reali http://www.reali.ch/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Q: Classpath and Eclipse
Patrik Reali <[EMAIL PROTECTED]> writes: > Hi! > > Has anybody already tried to import classpath under Eclipse? I tried to > create a project and import the files, but then Eclipse is far too > intelligent: > * gnu/java/lang classes are imported into package java.lang > * vm/reference/java/lang classes are imported into package vm.java.lang > > Probably I'm just doing something wrong (I'm using Eclipse 3.0M4) Never tried it. Most IDEs do not expect people to try to work on core java, especially not a "different" core java. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
