Catch Exception
Although we had try { } catch block ,and throw
statement ,it is possible we can miss some of the
(fatal ,for example ) exception.if it is how do we
eliminate or find some way to catch it ?
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Catch Exception
Be verbose. Show us what the actual try...catch statement is. If you do:
try { ... }
catch (Throwable t) { ... }
you should catch all but real signals. There is a way to catch signals as well,
a package that offers this functionality has come by a while ago on this list.
GreetinX++, Ernst
LAIKOK wrote:
>
> Although we had try { } catch block ,and throw
> statement ,it is possible we can miss some of the
> (fatal ,for example ) exception.if it is how do we
> eliminate or find some way to catch it ?
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
Ernst "Elvis" de Haan
Tector BV i.o.
"Come to me all who are weary and burdened"
-- Jesus Christ
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how many threads are too much?
> Java doesn't multitask threads very effectively Two problems with this statement: "Java" doesn't multitask efficiently? At best, "the JDK" or "currently available JDK's", because I haven't seen anything in the JLS or JVM spec that would hamper efficient multithreading. Second, what's wrong with native threads at the moment? It seems to me to work just fine. Is your statement not related to green threads? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
KVM
Hi, this might be off-topic, but I do not know a better place (and given that the geek factor of palm pilots and linux is almost the same...): Does anybody of you guys attending JavaOne have had a chance to get a copy of the KVM for the Palm? I would really like to have a look at it, but it seems that the only chance would be to be in California... How different from Java 2 is the micro edition? Is there something like AWT? Thanks, Ulli PS: If anybody of you knows a better mailing list, please give me a hint. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Calling Java objects from C++
Hi, I'm looking for a way to call Java objects from C++. Is this possible using JNI? Naoki -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic] stop bashing!
Jeff Galyan wrote: > Actually, you don't need to modify the .java files, and in fact, modifying the .java >files is strictly prohibited in the license (as such modifications could potentially >be misconstrued by the licensee as permission to change the apis). The license does >permit personal use of your own port. If you are a company doing the port for your >company's use, rather than you as an individual porting for your own personal use, >then you are correct in your interpretation of the license. You would be required to >pass the JCK and pay a license fee, etc. As an individual, you would not have to do >this unless you intended to release your port over the Internet, on CDROM, or >otherwise "distribute" it. Actually u do have to change the '.java' files ( simply for practicable convience ). Having extensive experience in porting sun's JDK, I find it rather difficult to store 64bits into a 32bit java int. Maybe u can review the java-linux-porting diffs of their 1.2 port. I'd like to know, for example, how the solaris printer 'queue' switches was changed to be compatable with linux printer 'queue' commands. There are many ways in which u can program in order to not change the '.java' files. There are also many ways u can program so u dont have to change the '.c'/'c++'/'.s' files. To an extreme, u dont even have to do a port, just build an i86 emulator, or a solaris emulator. Cant imagine why anyone would attempt to bother to port to a foreign machine, just so u can use it at home. Probably along the same reasons as why one would write a book, and only publish it just for yourself, for ur own personal reading. > > > Now, I'm not a lawyer, nor am I in charge of licenses for Sun, but I'm sure they >would be willing to work out a fair license fee for an individual who wanted to >distribute their port. You would still be required to pass the JCK before you could >distribute, though. I believe thats what they do now. Jck not so free, and distribution not so free, as i stated twice before. What would a fair license fee be, if u dont mind me asking, for my Linux/Redhat/Alpha of the Sun JDK port be ? And what if it become an impossible port because the JCK is skewed towards 32bit excentricity's ( as per JCK, u may not change it at all ) > > > Back to modifying the .java files - the only modifications you should ever need to >make (even for the .java files that call native methods) is in the .c, .cpp and .s >(asm) files. The header files for the native VM code is where you would want to make >your changes for internal type representation (i.e., is a long a 64-bit value, or is >an int a 64-bit value kinds of things). Any mapping between native types and Java >types is handled by jni_md.h for purposes of JNI. If you can think of good reasons >why you would absolutely have to change the .java files, then you may want to bring >that up to Sun. I personally can't think of any reason to change the .java files at >all unless you were adding new methods or otherwise changing the apis - which results >in a version of the Java core apis which depends on one specific port of the VM. >Again, that is strictly prohibited by the license. Say take the address of an X window, X gives back a long/64bit address/reference value. u pass it back to '.java' . ur unmodifiable '.java' expects an int which is 32 bits. This mapping is for 'like' types. Getting truncated longs, is just a part of java life on an alpha. There is no reason to change the API's, if they are not system/os specific. Having to change/alter the API's on a per OS would also violate the notion of write once, run everywhere concept. There is a set of win32 '.java" files to interface to the win32 native functions. There is also a set of solaris "unix" '.java' files to interface to the solaris unix native functions. Porting would mean altering the solaris unix '.java' files to be linux unix '.java' files, and the same for os specific native functions. My heart also goes out to ibm's as400 porting folks who have 48 byte ( i thinks its bytes ) addresses. I reported the problems of 64bit addresses to the bug list, as well as this one that IBM has submitted. > > > So, the "free for personal use" hasn't been thrown out the window. I believe it effectively has been thrown out the window. Ur not allowed to share (distribute ) ur personal efforts with others for personal uses. With the Non-commercial licence, one was able to 'restrictivly' distribute ur efforts. This is still true with JDK1.1.x, but no longer with JDK 1.2.x. > It's just that the language of the license is a little obtuse (but lawyers tend to >write that way -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how many threads are too much?
>> Java doesn't multitask threads very effectively >Two problems with this statement: "Java" doesn't multitask >efficiently? At best, "the JDK" or "currently available JDK's", >because I haven't seen anything in the JLS or JVM spec that would >hamper efficient multithreading. Sorry, this is a pet topic of mine. I didn't say "efficient", I said "effective". The Java threading model, as specified, is quite weak. There is no way to stop a thread. There's barely any way to manage relative thread priorities (the mechanism that's there does not work very well). There's not even a guarantee of preemptive multitasking. >Second, what's wrong with native threads at the moment? It seems to >me to work just fine. Is your statement not related to green threads? Native threads on Linux take care of the preemption problems. But you're relying on behaviour that's outside of spec. Green threads work reasonably well, too, probably better if you're using lots of threads. All of this was advice to someone doing a multi-agent system in Java. I've been doing one myself for the past 18 months. It works OK, but it would work a lot better if I had more control over threading. With apologies for the peripherally Linux related post, Nelson [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Location of any Java plugin
I am aware that the Java 1.2 plugin is not going to available for a while yet, but can anyone point me to the location of a Linux i386 Java 1.1 plugin in the interim? Peter Harbo email: [EMAIL PROTECTED] OR Smithsonian Astrophysical Observatory [EMAIL PROTECTED] 60 Garden St, MS 81 Cambridge MA 02138 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how many threads are too much?
[EMAIL PROTECTED] said: > Sorry, this is a pet topic of mine. I didn't say "efficient", I said > "effective". The Java threading model, as specified, is quite weak. > There is no way to stop a thread. Yep. Some prices have to be paid for WORA. Personally, I don't think it's a very big price. > (the mechanism that's there does not work very well) I'm curious: "does not work very well" (current implementations) or "can not work very well" (the standard has problems) ? -- Cees de Groot http://www.cdegroot.com <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [off-topic] stop bashing!
Uncle George: >Actually u do have to change the '.java' files ( simply for practicable >convience ). Having extensive experience in porting sun's JDK, I find >it rather difficult to store 64bits into a 32bit java int. Maybe u can >review the java-linux-porting diffs of their 1.2 port. I'd like to know, >for example, how the solaris printer 'queue' switches was changed to be >compatable with linux printer 'queue' commands. Where do 32/64bit differences on the platform bubble up to the java.* level that you would need to change this? If there are such locations, these should be reported as bugs because on the java level you shouldn't be able to determine the native wordsize of the underlying platform. Changing the wordsize of standard API level interfaces during a port would completely defeat the purpose of the virtual machine, and I for one are very glad that Sun wouldn't allow this. If your Alpha port has changed ints and longs in API .java files it's just as much Java as Microsoft's stuff is... -- Cees de Groot http://www.cdegroot.com <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how many threads are too much?
Warning Could not process message with given Content-Type: multipart/signed; boundary=VkVuOCYP9O7H3CXI; micalg=pgp-md5;protocol="application/pgp-signature"
Re: [off-topic] stop bashing!
> Cees de Groot writes: Cees> Uncle George: >> Actually u do have to change the '.java' files ( simply for >> practicable convience ). Having extensive experience in porting >> sun's JDK, I find it rather difficult to store 64bits into a >> 32bit java int. Maybe u can review the java-linux-porting >> diffs of their 1.2 port. I'd like to know, for example, how >> the solaris printer 'queue' switches was changed to be >> compatable with linux printer 'queue' commands. Cees> Where do 32/64bit differences on the platform bubble up to Cees> the java.* level that you would need to change this? If Cees> there are such locations, these should be reported as bugs Cees> because on the java level you shouldn't be able to determine Cees> the native wordsize of the underlying platform. I'll agree with you on that, but not all of the java code in the JDK source code is platform independent and there are situations where the Solaris specific java source code (these are the .java files Uncle George is talking about) has be changed for Linux ports (even for 32bit ports). Note that this does not affect the public java.* APIs/classes. The printer 'queue' commands are one example where a Solaris-specific java file has to be changed in order to work on Linux. Cees> Changing the wordsize of standard API level interfaces Cees> during a port would completely defeat the purpose of the Cees> virtual machine, and I for one are very glad that Sun Cees> wouldn't allow this. If your Alpha port has changed ints and Cees> longs in API .java files it's just as much Java as Cees> Microsoft's stuff is... As long as he doesn't change java files in the platform independent source code everything should be OK. This is one of the reason why nobody should use the sun.* classes. Juergen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how many threads are too much?
Cees de Groot says: >>The Java threading model, as specified, is quite weak. >Yep. Some prices have to be paid for WORA. Personally, I don't think >it's a very big price. It depends on what you're doing. In the current system, you can't even really do applets correctly, because there's no way to stop them. You basically can't control the thread behavior of any code, trusted or untrusted. I run a mailing list to work on these issues, taking a resource accounting and control approach. http://gee.cs.oswego.edu/dl/javares/ [on priorities] >>(the mechanism that's there does not work very well) >I'm curious: "does not work very well" (current implementations) or >"can not work very well" (the standard has problems) ? Can not work very well. Priorities don't really mean anything in the Java spec - it's not clear there's even a guarantee that a thread of higher priority will execute preferentially to a thread of lower priority. In practice this isn't a problem for me, but it seems really weak. Peter Schuller says: >What about implementing a little scheduler in Java? There's some nice examples of doing that, and it is an interesting solution. It's a lot of work, though, and you still have the fundamental limitations of the threading model. If you get something working, release it open source and we'll all use it! [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how many threads are too much?
> What about implementing a little scheduler in Java? I mean, Java *does* > pre-emt even green threads if there's another threads of *higher* priority > running. > > So, as I believe has been mentioned before, it would be possible to use the > three thread priorities to implement a green-threads scheduler. > > Has anyone done this? I guess it's not much code involved. so I guess I'll > be trying it anyway, but what about the performance loss? Is it large? Yes, we have done this on AutO, a distributed system of autonomous objects. The system executes code supplied by many different users and we had to take precautions against code which does not voluntarily release the CPU. We have a daemon thread running at Thread.MAX_PRIORITY which sleeps 100ms in an endless loop. We did not try to tune this time slice, but we didn't experience any slowdown during normal operation. CU, Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Compile OK but not Run
After an installation de jdk1.2 on Linux RedHat 6 I can Compile with javac in Xterm windows and i get one file.class When i would run this file.class i use "java file.class" and it return this error : at java.lang.NoClassDefFoundError. Could you help me Thanks Olivier TINLAND French
Re: Compile OK but not Run
try "java file" not "java file.class" On Fri, 18 Jun 1999, tinland wrote: > After an installation de jdk1.2 on Linux RedHat 6 > > I can Compile with javac in Xterm windows and i get one file.class > > When i would run this file.class i use "java file.class" and it return this error : > at java.lang.NoClassDefFoundError. > > Could you help me > > Thanks > > Olivier TINLAND > [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compile OK but not Run
try adding . to your classpath ~ Yohans Mendoza [EMAIL PROTECTED] Sirius Images Inc. Unix Administrator http://www2.utep.edu/~yohans ~ On Fri, 18 Jun 1999, tinland wrote: > After an installation de jdk1.2 on Linux RedHat 6 > > I can Compile with javac in Xterm windows and i get one file.class > > When i would run this file.class i use "java file.class" and it return this error : > at java.lang.NoClassDefFoundError. > > Could you help me > > Thanks > > Olivier TINLAND > French > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Display an image
Hi,
I knew that getImage() could
load an image file from the
network and paint() could
display it.
However, I don't know how can I
get an image which is a local
file. I tried
Image i = getImage( String filename )
It can not be compiled and the
compiler said:
Incompatible type for method. Can't convert java.lang.String to java.net.URL.
i = getImage("houses.gif");
--Simmy
--
Yuet Sim Lee
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
