Eclipse problems
Hi all, I have reinstall eclipse, and I am getting some errors. Eclipse says me that it crashs, and this is the log error: !SESSION -- !ENTRY org.eclipse.core.launcher 4 0 dic 03, 2003 13:23:47.42 !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.NoClassDefFoundError: org/eclipse/swt/widgets/Control at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:1590) why does eclipse crash now??? when I install the first time it was fine. Eclipse distribution (downloaded from eclipse page) works fine. Thx. -- Mariano García González :: Ingeniero de Sistemas Optiva MediaPGP 0x89E8E4CE O'Donnel 29 28009 Madrid (España) t. +34 91 577 80 57 www.optivamedia.com © This message is printed on 100% recycled electrons. signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Trouble with VM?
Brian, On Sat, 29 Nov 2003 17:16:20 -0700, Brian Gonzales wrote: > Installed a copy of j2se-common, j2sdk1.4 & j2re1.4 that I downloaded > from: http://jrfonseca.dyndns.org/debian/. It installed with no > problems. I wrote a simple HelloWorld.java that works, but when I access > the JVM test page at: http://www.java.com/en/download/help/testvm.jsp, I > get the infamous 'Red X'. > > I've tried accessing this page with Galeon, Mozilla, Mozilla-Firebird, > Konquerer and Netscape's browser but none works (I enabled Java on all > browsers). > > Thank you very much in advance. > > Here's the text from my Java Console: > java.lang.ClassFormatError: testvm/class (Bad magic number) > at java.lang.ClassLoader.defineClass0(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:502) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) > at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:148) > at > sun.plugin.security.PluginClassLoader.findClass(PluginClassLoader.java:168) > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:114) > at java.lang.ClassLoader.loadClass(ClassLoader.java:255) > at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:506) > at sun.applet.AppletPanel.createApplet(AppletPanel.java:566) > at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1775) > at sun.applet.AppletPanel.runLoader(AppletPanel.java:495) > at sun.applet.AppletPanel.run(AppletPanel.java:292) > at java.lang.Thread.run(Thread.java:536) > I'll be dropping that Blackdown-based java package soon. I was also experiencing crashes with eclipse which were solved by using Sun's latest 1.4.2-02 j2sdk. This time I used Hubert Schmid's excelent mpkg-j2sdk to make a Debian packaged from Sun's j2sdk-1_4_2_02-linux-i586.bin download, and I adivse people to do the same. Jose Fonseca PS: It's so sad that Java can't be included in standard Debian... :-( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trouble with VM?
Hi Jose, José Fonseca wrote: PS: It's so sad that Java can't be included in standard Debian... :-( You can help improve the quality of the free java runtimes included in debian by lending a hand to the various free java runtime efforts out there (kaffe, sablevm, gcj, ...) , if you meet certain clean-room conditions. They are getter better every day thanks to many people who decided to stop waiting for Sun to make java free and take the necessary steps themselves. You could be one of us. ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Free Java (Was: Trouble with VM?)
Hi Jose, José Fonseca wrote: But supposing I want to help one of the honorable efforts you mention above, just by testing it and submiting the bug-reports (or even take a stab at it myself), exactly which of those (kaffe, sablevm, gcj, ...) should I try to use? This is a question I had asked myself before. I'm obviosly biased, so I'd say kaffe ;) But I'm sure the developers of the other VMs would appreciate someone submitting bug reports as well. Regarding the classpath library there seems to be convergency towards the Gnu classpath library. But which VM (of the so many out there) is the open-source community backing in full-weight? None, as far as I can tell. The open-source community is busy making open source programs that work on Sun's JDK, and rarely cares enough about free runtimes to submit bug reports, or fixes. That's in large part caused by the (to an extent only perceived) incapabilities of the free runtimes to compete with Sun's offering in one way or another (features, stability, etc.). It's a bit of vicious circle thing: the free runtimes can only get good enough to run cool apps, if people running & writing the cool open-source apps bother to test their apps with the free vms, and report bugs and if possible provide fixes for the bugs they find. But as long as the free runtimes are not percieved as good enough for running some app, the user base of that app has little incentive to consider trying it out on a free VM. I know that competition is natural (and quite often favorable) in open-source. But I can't help thinking I may be backing the wrong horse, and my time spent on it be in vain. We're competing on some aspects, and cooperating on others. If you want to avoid spending time in vain, put your time behind GNU Classpath, and not behind a particular VM. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Eclipse keeps crashing
Hi, I'm attempting to run eclipse, but it keeps crashing after the Splash Screen is shown (which is sometimes twice) eclipse has been installed using apt-get and the following packages are installed: eclipse-platform (2.1.1-7) eclipse-javac (2.1.1-7) reinstallations (and clean-ups - automatic and manual) of both eclipse and java (Blackdown, 1.4) has been tried with no luck. Any input would be appreciated since google didn't help me much. Thanks. Jan Tvorup ~/eclipse/.metadata/.log gives: !SESSION Dec 03, 2003 16:11:16.806 - java.version=1.4.1 java.vendor=Blackdown Java-Linux Team BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US Command-line arguments: -ws gtk -os linux -arch x86 -data /home/tvorup/eclipse -addsite /home/tvorup/.eclipse/user.links -install file:/usr/share/eclipse/ !ENTRY org.eclipse.core.runtime 2 1 Dec 03, 2003 16:11:16.807 !MESSAGE Problems encountered loading the plug-in registry. !SUBENTRY 1 org.eclipse.core.runtime 2 1 Dec 03, 2003 16:11:16.808 !MESSAGE Plug-in "org.eclipse.jdt.junit.runtime" was disabled due to missing or disabled prerequisite plug-in "org.junit". !SUBENTRY 1 org.eclipse.core.runtime 2 1 Dec 03, 2003 16:11:16.808 !MESSAGE Plug-in "org.eclipse.jdt.junit" was disabled due to missing or disabled prerequisite plug-in "org.eclipse.jdt.junit.runtime". !SUBENTRY 1 org.eclipse.core.runtime 2 1 Dec 03, 2003 16:11:16.808 !MESSAGE Unknown extension point "org.eclipse.pde.core.source" specified in plug-in "org.eclipse.jdt.source". !SUBENTRY 1 org.eclipse.core.runtime 2 1 Dec 03, 2003 16:11:16.808 !MESSAGE Unknown extension point "org.eclipse.pde.core.source" specified in plug-in "org.eclipse.platform.source". !SUBENTRY 1 org.eclipse.core.runtime 2 1 Dec 03, 2003 16:11:16.809 !MESSAGE Unknown extension point "org.eclipse.pde.core.source" specified in plug-in "org.eclipse.platform.source". !ENTRY org.eclipse.core.runtime 4 2 Dec 03, 2003 16:11:17.165 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.runtime". !STACK 0 java.lang.NoSuchMethodError: org.eclipse.core.runtime.Platform.getJobManager()Lorg/eclipse/core/runtime/jobs/IJobManager; at org.eclipse.core.internal.resources.WorkManager.(WorkManager.java:55) at org.eclipse.core.internal.resources.Workspace.startup(Workspace.java:1673) at org.eclipse.core.internal.resources.Workspace.open(Workspace.java:1493) at org.eclipse.core.resources.ResourcesPlugin.startup(ResourcesPlugin.java:292) at org.eclipse.core.internal.plugins.PluginDescriptor$1.run(PluginDescriptor.java:736) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1006) at org.eclipse.core.internal.plugins.PluginDescriptor.internalDoPluginActivation(PluginDescriptor.java:748) at org.eclipse.core.internal.plugins.PluginDescriptor.doPluginActivation(PluginDescriptor.java:188) at org.eclipse.core.internal.plugins.PluginClassLoader.activatePlugin(PluginClassLoader.java:112) at org.eclipse.core.internal.plugins.PluginClassLoader.internalFindClassParentsSelf(PluginClassLoader.java:185) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.findClassParentsSelf(DelegatingURLClassLoader.java:490) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.loadClass(DelegatingURLClassLoader.java:882) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.access$000(DelegatingURLClassLoader.java:20) at org.eclipse.core.internal.boot.DelegatingURLClassLoader$DelegateLoader.loadClass(DelegatingURLClassLoader.java:90) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.findClassPrerequisites(DelegatingURLClassLoader.java:554) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.loadClass(DelegatingURLClassLoader.java:890) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.loadClass(DelegatingURLClassLoader.java:862) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:1590) at java.lang.Class.getConstructor0(Class.java:1762) at java.lang.Class.newInstance0(Class.java:276) at java.lang.Class.newInstance(Class.java:259) at org.eclipse.core.internal.plugins.PluginDescriptor.createExecutableExtension(PluginDescriptor.java:138) at org.eclipse.core.internal.plugins.PluginDescriptor.createExecutableExtension(PluginDescriptor.java:167) at org.eclipse.core.internal.plugins.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:103) at org.eclipse.core.internal.runtime.InternalPlatform.loaderGetRunnable(InternalPlatform.java:578) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Metho
Free Java (Was: Trouble with VM?)
On Wed, Dec 03, 2003 at 05:25:35PM +0100, Dalibor Topic wrote: > Hi Jose, > > José Fonseca wrote: > > > > >PS: It's so sad that Java can't be included in standard Debian... :-( > > You can help improve the quality of the free java runtimes included in > debian by lending a hand to the various free java runtime efforts out > there (kaffe, sablevm, gcj, ...) , if you meet certain clean-room > conditions. They are getter better every day thanks to many people who > decided to stop waiting for Sun to make java free and take the necessary > steps themselves. You could be one of us. ;) Unfortunately my time is limited, and much of it is already dedicated to help in other open-source efforts. My rant was really towards Sun's Java policy... (Where is that widely-available Java for Linux that Sun together with RedHat would bring to us?) But supposing I want to help one of the honorable efforts you mention above, just by testing it and submiting the bug-reports (or even take a stab at it myself), exactly which of those (kaffe, sablevm, gcj, ...) should I try to use? This is a question I had asked myself before. Regarding the classpath library there seems to be convergency towards the Gnu classpath library. But which VM (of the so many out there) is the open-source community backing in full-weight? I know that competition is natural (and quite often favorable) in open-source. But I can't help thinking I may be backing the wrong horse, and my time spent on it be in vain. Any thoughts about this? Jose Fonseca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trouble with VM?
On Wed, 2003-12-03 at 09:03, José Fonseca wrote: > Brian, > > On Sat, 29 Nov 2003 17:16:20 -0700, Brian Gonzales wrote: > > Installed a copy of j2se-common, j2sdk1.4 & j2re1.4 that I downloaded > > from: http://jrfonseca.dyndns.org/debian/. It installed with no > > problems. I wrote a simple HelloWorld.java that works, but when I access > > the JVM test page at: http://www.java.com/en/download/help/testvm.jsp, I > > get the infamous 'Red X'. > > > > I've tried accessing this page with Galeon, Mozilla, Mozilla-Firebird, > > Konquerer and Netscape's browser but none works (I enabled Java on all > > browsers). > > > > Thank you very much in advance. > > > > Here's the text from my Java Console: > > java.lang.ClassFormatError: testvm/class (Bad magic number) > > at java.lang.ClassLoader.defineClass0(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:502) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) > > at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:148) > > at > > sun.plugin.security.PluginClassLoader.findClass(PluginClassLoader.java:168) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:299) > > at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:114) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:255) > > at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:506) > > at sun.applet.AppletPanel.createApplet(AppletPanel.java:566) > > at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1775) > > at sun.applet.AppletPanel.runLoader(AppletPanel.java:495) > > at sun.applet.AppletPanel.run(AppletPanel.java:292) > > at java.lang.Thread.run(Thread.java:536) > > > > I'll be dropping that Blackdown-based java package soon. I was also > experiencing crashes with eclipse which were solved by using Sun's > latest 1.4.2-02 j2sdk. > > This time I used Hubert Schmid's excelent mpkg-j2sdk to make a Debian > packaged from Sun's j2sdk-1_4_2_02-linux-i586.bin download, and I adivse > people to do the same. > > Jose Fonseca > > PS: It's so sad that Java can't be included in standard Debian... :-( Thanks, José, keep us updated! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Free Java (Was: Trouble with VM?)
José Fonseca wrote: I know that competition is natural (and quite often favorable) in open-source. But I can't help thinking I may be backing the wrong horse, and my time spent on it be in vain. The different Free jvm's have different goals and constraints. I will describe my view of 3 jvm's I know. GCJ is mainly a GCC extension, targeting static compilation of Java to native code and/or bytecode. It includes a minimal, but incomplete interpreter (gij). Its main native interface is CNI (Cygnus Native Interface) which is convenient for linking with C++ code, but which is non standard (incompatible with JNI) and is also incompatible with precise and moving garbage collectors. It's class library is mostly GNU Classpath with some differences (both projects "libgcj" and "Classpath" are under an on going merge). License is GPL with a linking exception (which makes the whole license very weak, intentionally). Kaffe is the oldest of the Free jvm's. It has, currently, the best class library support (but implements quite old JDK versions; minimal support for latest libraries). Dalibor and others are currently working on making Kaffe to work with GNU Classpath class libraries. Kaffe has a JIT compiler and thus achieves very good performance, usually. Kaffe's primary native interface is gain a Kaffe-specific interface. JNI has been retrofitted to Kaffe; but Kaffe remains an unsuitable Free jvm to experiment with moving and precise garbage collectors. One of Kaffe's main "features" (or limitation, depending on you point of view), is that it is licensed under the GNU GPL, with NO exception whatsoever. This can have important consequences on an application that depends specifically on features of Kaffe. [WARNING WARNING WARNING: I AM BIASED TOWARD SABLEVM] SableVM is a newer project that was started from the ground up to build a robust, extremely portable, efficient, and fully specifications-compliant (JVM spec, JNI, Invocation interface, and soon to come: JVMDI, JVMPI(?), etc.) jvm that would be *EASY* to maintain and to extend. SableVM's core engine is an "interpreter: which uses state-of-the art techniques to deliver performance that can approach that of a "naive" just-in-time "JIT" compiler, while retaining the software engineering advantages of interpreters: portability, maintainability, simplicity. [Debugging a JIT can be a quite challenging problem in a multi-threaded environment]. SableVM's simplicity makes its source code very accessible, and easy to understand for new users/programmers. SableVM's internal design was engineered to be as flexible as possible. SableVM is compatible with moving and non-moving collectors, provides "constant-time" interface method calls (in fact, there is no time difference between a virtual method call and an interface method call at runtime). SableVM's whole source code is currently < 60K lines, yet it provides properly guarded native JNI method transition, so that garbage collection does not have to wait for a runaway native thread to call back in the jvm to be able to do garbage collection. It has many other *robustness* design features, that have been the object of careful design. While SableVM does not currently implement all the different specifications, and has some incomplete parts (e.g. it lacks a bytecode verifier), it has all the structures in place so that the full specifications can be implemented without having to re-engineer the core design. This is not the sort of stuff that is easily visible to an end user, but on the longer term, it will allow SableVM to be an utterly ROBUST (and hopefully complete) jvm for executing Java bytecode. [We do have a SableJIT project, which is a "retargetable" JIT (easily portable to a new platform with minimal effort), that is already capable of compiling hot paths of methods, but it is NOT an optimizing JIT, nor can it fully compete with platform-specific JITs]. SableVM was designed from the ground up to work with GNU Classpath, and solely use the standard JNI interface as native interface (it has no other native interface). It is extremely portable (porting to Debian/hppa took only 25 minutes)! Usually, you can expect SableVM to be ~5 times slower than a high-performance, state-of-the art JIT (including Kaffe's JIT3). Yet, SableVM's interpreter is in average ~4-5 times faster than Kaffe's *interpreter* (which was not designed with performance in head; to be fair). The big difference is: simplicity (size and understandability of code) and portability (porting an optimizing JIT takes months), and robustness (debugging an interpreter is easy; debugging a JIT can be a nightmare). Oh, yes! SableVM is licensed under the LGPL, so there are no worry to have about linking with applications, or even extending SableVM to provide specific features, and link proprietary, or GPL-incompatible applications to it. Please refer to recent thread of discussion on Debian-legal for a better understanding of the potential pro
Re: Eclipse keeps crashing
Hallo Jan, * Jan Tvorup wrote: >I'm attempting to run eclipse, but it keeps crashing after the Splash >Screen is shown (which is sometimes twice) The two times isn't a problem. The below stack traces are :( I haen'T seen them so far, but it seems that some classes are missing. >eclipse has been installed using apt-get and the following packages are >installed: >eclipse-platform (2.1.1-7) >eclipse-javac (2.1.1-7) If thats the only packages of eclipse, that we have the problem :) Please send the output of [EMAIL PROTECTED]:~$ dpkg -l |grep "eclipse" ii eclipse-javac 2.1.2-1Eclipse Java compiler and ant plug-in ii eclipse-jdt2.1.2-1Java Development Tools plug-ins for Eclipse ii eclipse-pde2.1.2-1Plug-in Development Environment to develop E ii eclipse-platfo 2.1.2-1Eclipse platform without plug-ins to develop ii eclipse-sdk2.1.2-1Extensible Tool Platform and Java IDE ii eclipse-source 2.1.2-1Eclipse source code plug-ins ii eclipse-webdav 2.1.2-1Eclipse FTP and WebDAV Support [EMAIL PROTECTED]:~$ dpkg -l |grep "swt" ii libswt2.1-gtk2 2.1.2-1Fast and rich GUI toolkit for Java, gtk2 ver ii libswt2.1-moti 2.1.2-1Fast and rich GUI toolkit for Java, motif ve [EMAIL PROTECTED]:~$ [if anybody knows how to get grep accepting ".*(eclipse|swt).*"...] >missing or disabled prerequisite plug-in "org.junit". Ouhu, another one never yet seen :( Is your /usr/share/eclipse/plugins/org.junit.../*jar link broken? >java.lang.NoSuchMethodError: >org.eclipse.core.runtime.Platform.getJobManager()Lorg/eclipse/core/runtime/jobs/IJobManager; Are you sure, that you ar eruning the 2.1 version? My version of that class has no such method. AFAIK, this methods (or better 'Jobs') were introduced in 3.0 Stream, so 2.1 shouldn't know about it at all... Jan -- Jan Schulz [EMAIL PROTECTED] "Wer nicht fragt, bleibt dumm." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse problems
Hallo Mariano, * Mariano García wrote: >java.lang.NoClassDefFoundError: org/eclipse/swt/widgets/Control >why does eclipse crash now??? It doesn't find the SWT implementation. Please compare what your * $HOME/.eclipse/eclipsrc -> WS="..." * update-alternatives --display libswt2.1-java says and whether both (one, if only one of the SWT packages are installed) links are actually there (if not, then it would be a bug). The problem with this feature is, that it seems that this problem is a little too common and I should write some test code to check, whether a requested version is actually installed by he package manager. This feature (changing the SWT implemantation on the fly) is debian (and now JPackage.org -> Java RPM packages) specific and NOT supported by upstream. Seems that I was too optimistic about the 'fail quote'. Jan -- Jan Schulz [EMAIL PROTECTED] "Wer nicht fragt, bleibt dumm." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse crash
Hallo Bear, * Bear Giles wrote: >I can't help you because eclipse is crashing every time I run it - >I get a "NoClassDefFoundError: org/eclipse/swt/widgets/Control" >thrown. I'm not sure what to make of this since I have >libswt2.1-motif-java installed. $HOME/.eclipse/eclipsrc -> s/gtk/motif/ ? Jan -- Jan Schulz [EMAIL PROTECTED] "Wer nicht fragt, bleibt dumm." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Free Java (Was: Trouble with VM?)
My equally biased response ... Etienne Gagnon wrote: GCJ is mainly a GCC extension, targeting static compilation of Java to native code and/or bytecode. GCJ aims to be a complete full-featured Free Java implementation. It includes a minimal, but incomplete interpreter (gij). Gij may have bugs, and we certainly make no claim that the bytecode verifier or security is robust enough to make it suitable for running possibly hostile code. However, as far as I know it is "complete". We would be happy to integrate a JIT into GIJ, as an option. > Its main native interface is CNI (Cygnus Native Interface) I think officially it's now the "Compiled Native Interface". which is convenient for linking with C++ code, And an order of magnitude faster. but which is non standard (incompatible with JNI) which is why GCJ also implements JNI and is also incompatible with precise and moving garbage collectors. I don't believe it is incompatible with a precise collector. (Emacs uses a precise collector.) Nor is it *inherently* incompatible with a copying collector - you just have to teach the C++ compiler to emit the necessary tables so the collector can update all the pointers. That is a very hard problem. Furthermore, it has been claimed that JNI also in practice requires a conservative collector. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
